From 3f3fa589eb16f05d89b5b99d4569bdc3dca71efe Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Mon, 17 Nov 2025 20:07:49 +0100
Subject: [PATCH 01/57] Adjust headings in generated API reports

---
 .../java/org/junit/api/tools/AbstractApiReportWriter.java | 8 ++++----
 .../java/org/junit/api/tools/AsciidocApiReportWriter.java | 8 ++++----
 .../java/org/junit/api/tools/HtmlApiReportWriter.java     | 8 ++++----
 .../java/org/junit/api/tools/MarkdownApiReportWriter.java | 8 ++++----
 4 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/documentation/src/tools/java/org/junit/api/tools/AbstractApiReportWriter.java b/documentation/src/tools/java/org/junit/api/tools/AbstractApiReportWriter.java
index 5d2526b03f49..1943b3e7865f 100644
--- a/documentation/src/tools/java/org/junit/api/tools/AbstractApiReportWriter.java
+++ b/documentation/src/tools/java/org/junit/api/tools/AbstractApiReportWriter.java
@@ -60,12 +60,12 @@ protected void printDeclarationSection(Set<Status> statuses, Status status, List
 			return;
 		}
 		declarationsByModule.forEach((moduleName, moduleDeclarations) -> {
-			out.println(h4("Module " + moduleName));
+			out.println(h3("Module " + moduleName));
 			out.println();
 			moduleDeclarations.stream() //
 					.collect(groupingBy(Declaration::packageName, TreeMap::new, toList())) //
 					.forEach((packageName, packageDeclarations) -> {
-						out.println(h5("Package " + packageName));
+						out.println(h4("Package " + packageName));
 						out.println();
 						printDeclarationTableHeader(out);
 						packageDeclarations.forEach(it -> printDeclarationTableRow(it, out));
@@ -92,9 +92,9 @@ protected void printDeclarationSectionHeader(Set<Status> statuses, Status status
 
 	protected abstract String h2(String header);
 
-	protected abstract String h4(String header);
+	protected abstract String h3(String header);
 
-	protected abstract String h5(String header);
+	protected abstract String h4(String header);
 
 	protected abstract String code(String element);
 
diff --git a/documentation/src/tools/java/org/junit/api/tools/AsciidocApiReportWriter.java b/documentation/src/tools/java/org/junit/api/tools/AsciidocApiReportWriter.java
index 0a285d3ffdea..59fe54b90154 100644
--- a/documentation/src/tools/java/org/junit/api/tools/AsciidocApiReportWriter.java
+++ b/documentation/src/tools/java/org/junit/api/tools/AsciidocApiReportWriter.java
@@ -34,13 +34,13 @@ protected String h2(String header) {
 	}
 
 	@Override
-	protected String h4(String header) {
-		return "[discrete]%n==== %s".formatted(header);
+	protected String h3(String header) {
+		return "%n=== %s".formatted(header);
 	}
 
 	@Override
-	protected String h5(String header) {
-		return "[discrete]%n===== %s".formatted(header);
+	protected String h4(String header) {
+		return "%n==== %s".formatted(header);
 	}
 
 	@Override
diff --git a/documentation/src/tools/java/org/junit/api/tools/HtmlApiReportWriter.java b/documentation/src/tools/java/org/junit/api/tools/HtmlApiReportWriter.java
index c0f5a237b00a..8b2cfc5870ea 100644
--- a/documentation/src/tools/java/org/junit/api/tools/HtmlApiReportWriter.java
+++ b/documentation/src/tools/java/org/junit/api/tools/HtmlApiReportWriter.java
@@ -35,13 +35,13 @@ protected String h2(String header) {
 	}
 
 	@Override
-	protected String h4(String header) {
-		return "<h4>" + header + "</h4>";
+	protected String h3(String header) {
+		return "<h3>" + header + "</h3>";
 	}
 
 	@Override
-	protected String h5(String header) {
-		return "<h5>" + header + "</h5>";
+	protected String h4(String header) {
+		return "<h4>" + header + "</h4>";
 	}
 
 	@Override
diff --git a/documentation/src/tools/java/org/junit/api/tools/MarkdownApiReportWriter.java b/documentation/src/tools/java/org/junit/api/tools/MarkdownApiReportWriter.java
index 458d6c721e8a..26ff3c38e4d5 100644
--- a/documentation/src/tools/java/org/junit/api/tools/MarkdownApiReportWriter.java
+++ b/documentation/src/tools/java/org/junit/api/tools/MarkdownApiReportWriter.java
@@ -35,13 +35,13 @@ protected String h2(String header) {
 	}
 
 	@Override
-	protected String h4(String header) {
-		return "#### " + header;
+	protected String h3(String header) {
+		return "### " + header;
 	}
 
 	@Override
-	protected String h5(String header) {
-		return "##### " + header;
+	protected String h4(String header) {
+		return "#### " + header;
 	}
 
 	@Override

From 1b4b92ed71738229f0fa3c2d6d75162b62c3b60e Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Mon, 17 Nov 2025 20:12:00 +0100
Subject: [PATCH 02/57] Set up Antora module

---
 documentation/antora.yml               | 24 ++++++++++++++++++++++
 documentation/documentation.gradle.kts | 28 ++++++++++++++++++++++++--
 documentation/modules/ROOT/nav.adoc    |  0
 gradle/libs.versions.toml              |  1 +
 4 files changed, 51 insertions(+), 2 deletions(-)
 create mode 100644 documentation/antora.yml
 create mode 100644 documentation/modules/ROOT/nav.adoc

diff --git a/documentation/antora.yml b/documentation/antora.yml
new file mode 100644
index 000000000000..5abd0da10059
--- /dev/null
+++ b/documentation/antora.yml
@@ -0,0 +1,24 @@
+name: junit
+version: null
+title: JUnit
+nav:
+  - modules/ROOT/nav.adoc
+ext:
+  collector:
+    run:
+      command: gradlew --quiet :documentation:generateAntoraResources
+      local: true
+    scan:
+    - dir: ./build/generated-antora-resources
+      clean: true
+    - dir: ./build/docs/fixedJavadoc
+      clean: true
+      into: modules/ROOT/attachments/api
+    - dir: ./src/test
+      into: modules/ROOT/examples
+    - dir: ./build/generated/asciidoc
+      clean: true
+      into: modules/ROOT/partials
+    - dir: ./build/plantuml
+      clean: true
+      into: modules/ROOT/images
diff --git a/documentation/documentation.gradle.kts b/documentation/documentation.gradle.kts
index 5697d44144eb..77e48ec7b6c7 100644
--- a/documentation/documentation.gradle.kts
+++ b/documentation/documentation.gradle.kts
@@ -15,6 +15,7 @@ plugins {
 	alias(libs.plugins.asciidoctorPdf)
 	alias(libs.plugins.gitPublish)
 	alias(libs.plugins.plantuml)
+	alias(libs.plugins.spring.antora)
 	id("junitbuild.build-parameters")
 	id("junitbuild.kotlin-library-conventions")
 	id("junitbuild.testing-conventions")
@@ -270,8 +271,8 @@ tasks {
 
 	val plantUmlOutputDirectory = plantUml.flatMap { it.outputDirectory }
 
-	withType<AbstractAsciidoctorTask>().configureEach {
-		inputs.files(
+	val generateAsciidocInputs by registering {
+		dependsOn(
 			generateConsoleLauncherOptions,
 			generateConsoleLauncherDiscoverOptions,
 			generateConsoleLauncherExecuteOptions,
@@ -280,6 +281,10 @@ tasks {
 			generateStandaloneConsoleLauncherShadowedArtifactsFile,
 			plantUmlOutputDirectory
 		)
+	}
+
+	withType<AbstractAsciidoctorTask>().configureEach {
+		dependsOn(generateAsciidocInputs)
 
 		resources {
 			from(sourceDir) {
@@ -550,4 +555,23 @@ tasks {
 		into(layout.buildDirectory.dir("attestation"))
 		rename("(.*)-SNAPSHOT.jar", "$1-SNAPSHOT+${buildRevision.substring(0, 7)}.jar")
 	}
+
+	generateAntoraYml {
+		asciidocAttributes.putAll(provider {
+			mapOf(
+				"version" to project.version,
+				"junit4-version" to libs.versions.junit4.get(),
+				"apiguardian-version" to libs.versions.apiguardian.get(),
+				"ota4j-version" to libs.versions.opentest4j.get(),
+				"surefire-version" to libs.versions.surefire.get(),
+				"release-branch" to releaseBranch,
+				"docs-version" to docsVersion,
+				"jdk-javadoc-base-url" to jdkJavadocBaseUrl
+			)
+		})
+	}
+
+	register("generateAntoraResources") {
+		dependsOn(generateAntoraYml, generateAsciidocInputs, fixJavadoc)
+	}
 }
diff --git a/documentation/modules/ROOT/nav.adoc b/documentation/modules/ROOT/nav.adoc
new file mode 100644
index 000000000000..e69de29bb2d1
diff --git a/gradle/libs.versions.toml b/gradle/libs.versions.toml
index 9a9c2814afe1..0e14db1aa89f 100644
--- a/gradle/libs.versions.toml
+++ b/gradle/libs.versions.toml
@@ -111,3 +111,4 @@ nullaway = { id = "net.ltgt.nullaway", version = "2.3.0" }
 plantuml = { id = "io.freefair.plantuml", version = "9.1.0" }
 shadow = { id = "com.gradleup.shadow", version = "9.3.0" }
 spotless = { id = "com.diffplug.spotless", version = "8.1.0" }
+spring-antora = { id = "io.spring.antora.generate-antora-yml", version = "0.0.1" }

From 58b94a4d550e31504d0cc2c87e433cf1c7c21fea Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 23 Nov 2025 19:04:06 +0100
Subject: [PATCH 03/57] Add task to build Antora site locally

---
 .gitignore                                    |  3 ++
 documentation/antora-playbook.yml             | 26 +++++++++++++
 documentation/documentation.gradle.kts        | 38 +++++++++++++++++++
 documentation/package.json                    | 12 ++++++
 gradle/libs.versions.toml                     |  1 +
 .../junitbuild.checkstyle-nohttp.gradle.kts   |  1 +
 settings.gradle.kts                           |  1 -
 7 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 documentation/antora-playbook.yml
 create mode 100644 documentation/package.json

diff --git a/.gitignore b/.gitignore
index 2ff2b321ef5c..2f03fe1f2adc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -38,3 +38,6 @@ checksums*
 # snapshot-tests
 *.snapshot_actual
 *.snapshot_raw
+
+# Antora
+/documentation/node_modules/
diff --git a/documentation/antora-playbook.yml b/documentation/antora-playbook.yml
new file mode 100644
index 000000000000..f371bf92c6f2
--- /dev/null
+++ b/documentation/antora-playbook.yml
@@ -0,0 +1,26 @@
+antora:
+  extensions:
+  - '@antora/collector-extension'
+  - '@antora/lunr-extension'
+  - require: '@springio/antora-extensions/root-component-extension'
+    root_component_name: junit
+  - require: '@springio/antora-extensions/root-attachments-extension'
+site:
+  title: JUnit User Guide
+  url: https://docs.junit.org
+content:
+  sources:
+  - url: @GIT_REPO_ROOT@
+    branches: @GIT_BRANCH_NAME@
+    start_path: documentation
+    worktrees: true
+asciidoc:
+  attributes:
+    attribute-missing: warn
+runtime:
+  log:
+    failure_level: warn
+ui:
+  bundle:
+    url: https://gitlab.com/antora/antora-ui-default/-/jobs/artifacts/HEAD/raw/build/ui-bundle.zip?job=bundle-stable
+    snapshot: true
diff --git a/documentation/documentation.gradle.kts b/documentation/documentation.gradle.kts
index 77e48ec7b6c7..4a14b7d2d257 100644
--- a/documentation/documentation.gradle.kts
+++ b/documentation/documentation.gradle.kts
@@ -11,6 +11,7 @@ import org.gradle.api.tasks.PathSensitivity.RELATIVE
 import org.ysb33r.grolifant.api.core.jvm.ExecutionMode.JAVA_EXEC
 
 plugins {
+	alias(libs.plugins.antora)
 	alias(libs.plugins.asciidoctorConvert)
 	alias(libs.plugins.asciidoctorPdf)
 	alias(libs.plugins.gitPublish)
@@ -149,6 +150,15 @@ require(externalModulesWithoutModularJavadoc.values.all { it.endsWith("/") }) {
 	"all base URLs must end with a trailing slash: $externalModulesWithoutModularJavadoc"
 }
 
+repositories {
+	// Redefined here because the Node.js plugin adds a repo
+	mavenCentral()
+}
+
+antora {
+	setOptions(mapOf("clean" to true, "stacktrace" to true, "fetch" to true))
+}
+
 tasks {
 
 	val consoleLauncherTestReportsDir = project.layout.buildDirectory.dir("console-launcher-test-results")
@@ -574,4 +584,32 @@ tasks {
 	register("generateAntoraResources") {
 		dependsOn(generateAntoraYml, generateAsciidocInputs, fixJavadoc)
 	}
+
+	val generateAntoraPlaybook by registering(Copy::class) {
+
+		val gitRepoRoot = providers.exec {
+			commandLine("git", "worktree", "list", "--porcelain", "-z")
+		}.standardOutput.asText.map { it.substringBefore('\u0000').substringAfter(' ') }
+
+		val gitBranchName = providers.exec {
+			commandLine("git", "rev-parse", "--abbrev-ref", "HEAD")
+		}.standardOutput.asText.map { it.trim() }
+
+		from(layout.projectDirectory.file("antora-playbook.yml").asFile)
+		filter { line ->
+			var result = line
+			if (line.contains("@GIT_REPO_ROOT@")) {
+				result = result.replace("@GIT_REPO_ROOT@", gitRepoRoot.get())
+			}
+			if (line.contains("@GIT_BRANCH_NAME@")) {
+				result = result.replace("@GIT_BRANCH_NAME@", gitBranchName.get())
+			}
+			return@filter result
+		}
+		into(layout.buildDirectory.dir("antora"))
+	}
+
+	project.antora {
+		playbook = generateAntoraPlaybook.map { it.rootSpec.destinationDir.resolve("antora-playbook.yml") }
+	}
 }
diff --git a/documentation/package.json b/documentation/package.json
new file mode 100644
index 000000000000..9960fe42e116
--- /dev/null
+++ b/documentation/package.json
@@ -0,0 +1,12 @@
+{
+  "devDependencies": {
+    "@antora/cli": "3.1.14",
+    "@antora/site-generator": "3.1.14"
+  },
+  "dependencies": {
+    "@antora/collector-extension": "1.0.2",
+    "@antora/lunr-extension": "1.0.0-alpha.10",
+    "@springio/antora-extensions": "1.14.7",
+    "highlight.js": "11.11.1"
+  }
+}
diff --git a/gradle/libs.versions.toml b/gradle/libs.versions.toml
index 0e14db1aa89f..3f91c4f0bf69 100644
--- a/gradle/libs.versions.toml
+++ b/gradle/libs.versions.toml
@@ -93,6 +93,7 @@ log4j = ["log4j-core", "log4j-jul"]
 xmlunit = ["xmlunit-assertj", "xmlunit-placeholders", "xmlunit-jakarta-jaxb-impl", "jaxb-api", "jaxb-runtime"]
 
 [plugins]
+antora = { id = "org.antora", version = "1.0.0" }
 asciidoctorConvert = { id = "org.asciidoctor.jvm.convert", version.ref = "asciidoctor-plugins" }
 asciidoctorPdf = { id = "org.asciidoctor.jvm.pdf", version.ref = "asciidoctor-plugins" }
 bnd = { id = "biz.aQute.bnd", version.ref = "bnd" }
diff --git a/gradle/plugins/common/src/main/kotlin/junitbuild.checkstyle-nohttp.gradle.kts b/gradle/plugins/common/src/main/kotlin/junitbuild.checkstyle-nohttp.gradle.kts
index 74af245a3d47..2a2dc620c443 100644
--- a/gradle/plugins/common/src/main/kotlin/junitbuild.checkstyle-nohttp.gradle.kts
+++ b/gradle/plugins/common/src/main/kotlin/junitbuild.checkstyle-nohttp.gradle.kts
@@ -37,5 +37,6 @@ tasks.register<Checkstyle>("checkstyleNohttp") {
 		exclude("**/*.jks")
 		exclude("**/build/**")
 		exclude("**/.kotlin")
+		exclude("**/node_modules/**")
 	}
 }
diff --git a/settings.gradle.kts b/settings.gradle.kts
index 22cff4977cde..590103aa62c4 100644
--- a/settings.gradle.kts
+++ b/settings.gradle.kts
@@ -17,7 +17,6 @@ dependencyResolutionManagement {
 	repositories {
 		mavenCentral()
 	}
-	repositoriesMode = FAIL_ON_PROJECT_REPOS
 }
 
 val buildParameters = the<BuildParametersExtension>()

From 843f074bbe3dae44ee25cc5f148dfea6656bdebc Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 23 Nov 2025 19:18:52 +0100
Subject: [PATCH 04/57] Extract conventions plugin

---
 documentation/documentation.gradle.kts        | 44 ++-----------------
 gradle/libs.versions.toml                     |  1 +
 gradle/plugins/antora/build.gradle.kts        | 23 ++++++++++
 .../junitbuild.antora-conventions.gradle.kts  | 44 +++++++++++++++++++
 gradle/plugins/settings.gradle.kts            |  1 +
 5 files changed, 72 insertions(+), 41 deletions(-)
 create mode 100644 gradle/plugins/antora/build.gradle.kts
 create mode 100644 gradle/plugins/antora/src/main/kotlin/junitbuild.antora-conventions.gradle.kts

diff --git a/documentation/documentation.gradle.kts b/documentation/documentation.gradle.kts
index 4a14b7d2d257..df85ee2979f0 100644
--- a/documentation/documentation.gradle.kts
+++ b/documentation/documentation.gradle.kts
@@ -11,12 +11,11 @@ import org.gradle.api.tasks.PathSensitivity.RELATIVE
 import org.ysb33r.grolifant.api.core.jvm.ExecutionMode.JAVA_EXEC
 
 plugins {
-	alias(libs.plugins.antora)
 	alias(libs.plugins.asciidoctorConvert)
 	alias(libs.plugins.asciidoctorPdf)
 	alias(libs.plugins.gitPublish)
 	alias(libs.plugins.plantuml)
-	alias(libs.plugins.spring.antora)
+	id("junitbuild.antora-conventions")
 	id("junitbuild.build-parameters")
 	id("junitbuild.kotlin-library-conventions")
 	id("junitbuild.testing-conventions")
@@ -150,15 +149,6 @@ require(externalModulesWithoutModularJavadoc.values.all { it.endsWith("/") }) {
 	"all base URLs must end with a trailing slash: $externalModulesWithoutModularJavadoc"
 }
 
-repositories {
-	// Redefined here because the Node.js plugin adds a repo
-	mavenCentral()
-}
-
-antora {
-	setOptions(mapOf("clean" to true, "stacktrace" to true, "fetch" to true))
-}
-
 tasks {
 
 	val consoleLauncherTestReportsDir = project.layout.buildDirectory.dir("console-launcher-test-results")
@@ -581,35 +571,7 @@ tasks {
 		})
 	}
 
-	register("generateAntoraResources") {
-		dependsOn(generateAntoraYml, generateAsciidocInputs, fixJavadoc)
-	}
-
-	val generateAntoraPlaybook by registering(Copy::class) {
-
-		val gitRepoRoot = providers.exec {
-			commandLine("git", "worktree", "list", "--porcelain", "-z")
-		}.standardOutput.asText.map { it.substringBefore('\u0000').substringAfter(' ') }
-
-		val gitBranchName = providers.exec {
-			commandLine("git", "rev-parse", "--abbrev-ref", "HEAD")
-		}.standardOutput.asText.map { it.trim() }
-
-		from(layout.projectDirectory.file("antora-playbook.yml").asFile)
-		filter { line ->
-			var result = line
-			if (line.contains("@GIT_REPO_ROOT@")) {
-				result = result.replace("@GIT_REPO_ROOT@", gitRepoRoot.get())
-			}
-			if (line.contains("@GIT_BRANCH_NAME@")) {
-				result = result.replace("@GIT_BRANCH_NAME@", gitBranchName.get())
-			}
-			return@filter result
-		}
-		into(layout.buildDirectory.dir("antora"))
-	}
-
-	project.antora {
-		playbook = generateAntoraPlaybook.map { it.rootSpec.destinationDir.resolve("antora-playbook.yml") }
+	generateAntoraResources {
+		dependsOn(generateAsciidocInputs, fixJavadoc)
 	}
 }
diff --git a/gradle/libs.versions.toml b/gradle/libs.versions.toml
index 3f91c4f0bf69..e647c6cbc855 100644
--- a/gradle/libs.versions.toml
+++ b/gradle/libs.versions.toml
@@ -108,6 +108,7 @@ jmh = { id = "me.champeau.jmh", version = "0.7.3" }
 jreleaser = { id = "org.jreleaser", version = "1.21.0" }
 # check if workaround in gradle.properties can be removed when updating
 kotlin = { id = "org.jetbrains.kotlin.jvm", version = "2.2.21" }
+node = { id = "com.github.node-gradle.node", version = "5.0.0" }
 nullaway = { id = "net.ltgt.nullaway", version = "2.3.0" }
 plantuml = { id = "io.freefair.plantuml", version = "9.1.0" }
 shadow = { id = "com.gradleup.shadow", version = "9.3.0" }
diff --git a/gradle/plugins/antora/build.gradle.kts b/gradle/plugins/antora/build.gradle.kts
new file mode 100644
index 000000000000..f6d134a2104d
--- /dev/null
+++ b/gradle/plugins/antora/build.gradle.kts
@@ -0,0 +1,23 @@
+import junitbuild.extensions.markerCoordinates
+import org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_21
+
+plugins {
+	`kotlin-dsl`
+}
+
+dependencies {
+	implementation(libs.plugins.antora.markerCoordinates)
+	implementation(libs.plugins.node.markerCoordinates)
+	implementation(libs.plugins.spring.antora.markerCoordinates)
+}
+
+tasks.compileJava {
+	options.release = 21
+}
+
+kotlin {
+	compilerOptions {
+		jvmTarget = JVM_21
+		freeCompilerArgs.add("-Xjdk-release=21")
+	}
+}
diff --git a/gradle/plugins/antora/src/main/kotlin/junitbuild.antora-conventions.gradle.kts b/gradle/plugins/antora/src/main/kotlin/junitbuild.antora-conventions.gradle.kts
new file mode 100644
index 000000000000..969a50f1dc3c
--- /dev/null
+++ b/gradle/plugins/antora/src/main/kotlin/junitbuild.antora-conventions.gradle.kts
@@ -0,0 +1,44 @@
+import org.antora.gradle.AntoraExtension
+
+plugins {
+	id("org.antora")
+	id("io.spring.antora.generate-antora-yml")
+}
+
+repositories {
+	// Redefined here because the Node.js plugin adds a repo
+	mavenCentral()
+}
+
+tasks.register("generateAntoraResources") {
+	dependsOn("generateAntoraYml")
+}
+
+val generateAntoraPlaybook by tasks.registering(Copy::class) {
+
+	val gitRepoRoot = providers.exec {
+		commandLine("git", "worktree", "list", "--porcelain", "-z")
+	}.standardOutput.asText.map { it.substringBefore('\u0000').substringAfter(' ') }
+
+	val gitBranchName = providers.exec {
+		commandLine("git", "rev-parse", "--abbrev-ref", "HEAD")
+	}.standardOutput.asText.map { it.trim() }
+
+	from(layout.projectDirectory.file("antora-playbook.yml").asFile)
+	filter { line ->
+		var result = line
+		if (line.contains("@GIT_REPO_ROOT@")) {
+			result = result.replace("@GIT_REPO_ROOT@", gitRepoRoot.get())
+		}
+		if (line.contains("@GIT_BRANCH_NAME@")) {
+			result = result.replace("@GIT_BRANCH_NAME@", gitBranchName.get())
+		}
+		return@filter result
+	}
+	into(layout.buildDirectory.dir("antora"))
+}
+
+the<AntoraExtension>().apply {
+	setOptions(mapOf("clean" to true, "stacktrace" to true, "fetch" to true))
+	playbook = generateAntoraPlaybook.map { it.rootSpec.destinationDir.resolve("antora-playbook.yml") }
+}
diff --git a/gradle/plugins/settings.gradle.kts b/gradle/plugins/settings.gradle.kts
index b2ae97139041..2399fe456afc 100644
--- a/gradle/plugins/settings.gradle.kts
+++ b/gradle/plugins/settings.gradle.kts
@@ -19,6 +19,7 @@ dependencyResolutionManagement {
 
 rootProject.name = "plugins"
 
+include("antora")
 include("backward-compatibility")
 include("build-parameters")
 include("common")

From 74a2d7ed026514bc1df10cf4c47557ae8df7929a Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 23 Nov 2025 19:37:01 +0100
Subject: [PATCH 05/57] Update README to reference Antora

---
 documentation/README.md | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/documentation/README.md b/documentation/README.md
index acb46649d9d5..c0254882da92 100644
--- a/documentation/README.md
+++ b/documentation/README.md
@@ -1,10 +1,10 @@
 # JUnit User Guide
 
-This subproject contains the AsciiDoc sources for the JUnit User Guide.
+This subproject contains the Antora/AsciiDoc sources for the JUnit User Guide.
 
 ## Structure
 
-- `src/docs/asciidoc`: AsciiDoc files
+- `modules/ROOT/pages`: AsciiDoc files
 - `src/test/java`: Java test source code that can be included in the AsciiDoc files
 - `src/test/kotlin`: Kotlin test source code that can be included in the AsciiDoc files
 - `src/test/resources`: Classpath resources that can be included in the AsciiDoc files or
@@ -12,23 +12,14 @@ This subproject contains the AsciiDoc sources for the JUnit User Guide.
 
 ## Usage
 
-### Generate AsciiDoc
+### Generate Antora site
 
 This following Gradle command generates the HTML version of the User Guide as
-`build/docs/asciidoc/user-guide/index.html`.
+`build/antora/build/site`.
 
 ```
-./gradlew asciidoctor
+./gradlew antora
 ```
 
 On Linux operating systems, the `graphviz` package providing `/usr/bin/dot` must be
-installed in order to generate the User Guide.
-
-### Generate AsciiDocPdf
-
-This following Gradle command generates the PDF version of the User Guide to
-`build/docs/asciidocPdf/user-guide/index.pdf`.
-
-```
-./gradlew asciidoctorPdf
-```
+installed in order to generate the PlantUML images used in the User Guide.

From a586b4eb8c50ba43a260b01399f04a1f21dfde43 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 23 Nov 2025 19:40:55 +0100
Subject: [PATCH 06/57] Remove Asciidoctor plugins

---
 documentation/documentation.gradle.kts | 123 -------------------------
 gradle/libs.versions.toml              |   7 --
 2 files changed, 130 deletions(-)

diff --git a/documentation/documentation.gradle.kts b/documentation/documentation.gradle.kts
index df85ee2979f0..fe3cd839c39d 100644
--- a/documentation/documentation.gradle.kts
+++ b/documentation/documentation.gradle.kts
@@ -5,14 +5,9 @@ import junitbuild.exec.RunConsoleLauncher
 import junitbuild.extensions.isSnapshot
 import junitbuild.extensions.javaModuleName
 import junitbuild.javadoc.ModuleSpecificJavadocFileOption
-import org.asciidoctor.gradle.base.AsciidoctorAttributeProvider
-import org.asciidoctor.gradle.jvm.AbstractAsciidoctorTask
 import org.gradle.api.tasks.PathSensitivity.RELATIVE
-import org.ysb33r.grolifant.api.core.jvm.ExecutionMode.JAVA_EXEC
 
 plugins {
-	alias(libs.plugins.asciidoctorConvert)
-	alias(libs.plugins.asciidoctorPdf)
 	alias(libs.plugins.gitPublish)
 	alias(libs.plugins.plantuml)
 	id("junitbuild.antora-conventions")
@@ -85,14 +80,6 @@ dependencies {
 	standaloneConsoleLauncher(projects.junitPlatformConsoleStandalone)
 }
 
-asciidoctorj {
-	setJrubyVersion(libs.versions.jruby)
-	modules {
-		pdf.version(libs.versions.asciidoctorj.pdf)
-	}
-	requires(file("src/docs/asciidoc/resources/themes/rouge_junit.rb"))
-}
-
 val buildRevision: String by rootProject.extra
 val snapshot = version.isSnapshot()
 val docsVersion = if (snapshot) "snapshot" else version
@@ -283,104 +270,6 @@ tasks {
 		)
 	}
 
-	withType<AbstractAsciidoctorTask>().configureEach {
-		dependsOn(generateAsciidocInputs)
-
-		resources {
-			from(sourceDir) {
-				include("**/images/**/*.png")
-				include("**/images/**/*.svg")
-			}
-			from(plantUmlOutputDirectory) {
-				into("user-guide/images")
-			}
-		}
-
-		// Temporary workaround for https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/599
-		inputs.dir(sourceDir).withPropertyName("sourceDir").withPathSensitivity(RELATIVE)
-
-		attributeProviders += AsciidoctorAttributeProvider {
-			mapOf(
-				"version" to version,
-				"junit4-version" to libs.versions.junit4.get(),
-				"apiguardian-version" to libs.versions.apiguardian.get(),
-				"ota4j-version" to libs.versions.opentest4j.get(),
-				"surefire-version" to libs.versions.surefire.get(),
-				"release-branch" to releaseBranch,
-				"docs-version" to docsVersion,
-				"revnumber" to version,
-				"consoleLauncherOptionsFile" to consoleLauncherOptionsFile.get(),
-				"consoleLauncherDiscoverOptionsFile" to consoleLauncherDiscoverOptionsFile.get(),
-				"consoleLauncherExecuteOptionsFile" to consoleLauncherExecuteOptionsFile.get(),
-				"consoleLauncherEnginesOptionsFile" to consoleLauncherEnginesOptionsFile.get(),
-				"experimentalApisTableFile" to experimentalApisTableFile.get(),
-				"deprecatedApisTableFile" to deprecatedApisTableFile.get(),
-				"standaloneConsoleLauncherShadowedArtifactsFile" to standaloneConsoleLauncherShadowedArtifactsFile.get(),
-				"outdir" to outputDir.absolutePath,
-				"source-highlighter" to "rouge",
-				"rouge-style" to "junit",
-				"tabsize" to "4",
-				"toc" to "left",
-				"icons" to "font",
-				"sectanchors" to true,
-				"idprefix" to "",
-				"idseparator" to "-",
-				"jdk-javadoc-base-url" to jdkJavadocBaseUrl
-			)
-		}
-
-		sourceSets["test"].apply {
-			attributes(mapOf(
-					"testDir" to java.srcDirs.first(),
-					"testResourcesDir" to resources.srcDirs.first()
-			))
-			inputs.dir(java.srcDirs.first())
-			inputs.dir(resources.srcDirs.first())
-			attributes(mapOf("kotlinTestDir" to kotlin.srcDirs.first()))
-			inputs.dir(kotlin.srcDirs.first())
-		}
-
-		jvm {
-			// To avoid warning, see https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/597
-			jvmArgs(
-				"--add-opens", "java.base/sun.nio.ch=ALL-UNNAMED",
-				"--add-opens", "java.base/java.io=ALL-UNNAMED"
-			)
-		}
-
-		notCompatibleWithConfigurationCache("https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/564")
-	}
-
-	asciidoctor {
-		sources {
-			include("**/index.adoc")
-		}
-		resources {
-			from(sourceDir) {
-				include("tocbot-*/**")
-			}
-		}
-		attributes(mapOf(
-				"linkToPdf" to uploadPdfs,
-				"userGuidePdfFileName" to userGuidePdfFileName,
-				"releaseNotesUrl" to "../release-notes/index.html#release-notes"
-		))
-	}
-
-	asciidoctorPdf {
-		// Avoid classpath conflicts with other Gradle plugins (e.g. JReleaser)
-		// Avoid propagating apparent memory leaks in Asciidoctor/JRuby to Gradle daemon.
-		setExecutionMode(JAVA_EXEC)
-		jvm {
-			maxHeapSize = "512M"
-		}
-		sources {
-			include("user-guide/index.adoc")
-		}
-		copyAllResources()
-		attributes(mapOf("releaseNotesUrl" to "https://docs.junit.org/$docsVersion/release-notes/"))
-	}
-
 	val downloadJavadocElementLists by registering {
 		outputs.cacheIf { true }
 		outputs.dir(elementListsDir).withPropertyName("elementListsDir")
@@ -502,20 +391,8 @@ tasks {
 	}
 
 	val prepareDocsForUploadToGhPages by registering(Copy::class) {
-		dependsOn(fixJavadoc, asciidoctor, asciidoctorPdf)
 		outputs.dir(docsDir)
 
-		from(asciidoctor.map { it.outputDir }) {
-			include("user-guide/**")
-			include("release-notes/**")
-			include("tocbot-*/**")
-		}
-		if (uploadPdfs) {
-			from(asciidoctorPdf.map { it.outputDir }) {
-				include("**/*.pdf")
-				rename { userGuidePdfFileName }
-			}
-		}
 		from(fixJavadoc.map { it.destinationDir }) {
 			into("api")
 		}
diff --git a/gradle/libs.versions.toml b/gradle/libs.versions.toml
index e647c6cbc855..6fd166447ed1 100644
--- a/gradle/libs.versions.toml
+++ b/gradle/libs.versions.toml
@@ -1,8 +1,6 @@
 [versions]
 ant = "1.10.15"
 apiguardian = "1.1.2"
-asciidoctorj-pdf = "2.3.23"
-asciidoctor-plugins = "4.0.5" # Check if workaround in documentation.gradle.kts can be removed when upgrading
 assertj = "3.27.6"
 bnd = "7.1.0"
 checkstyle = "12.2.0"
@@ -10,7 +8,6 @@ eclipse = "4.37.0"
 jackson = "2.20.1"
 jacoco = "0.8.14"
 jmh = "1.37"
-jruby = "9.4.14.0"
 junit4 = "4.13.2"
 junit4Min = "4.12"
 ktlint = "1.8.0"
@@ -79,10 +76,8 @@ testingAnnotations = { module = "com.gradle:develocity-testing-annotations", ver
 woodstox = { module = "com.fasterxml.woodstox:woodstox-core", version = "7.1.1" }
 
 # Only declared here so Dependabot knows when to update the referenced versions
-asciidoctorj-pdf = { module = "org.asciidoctor:asciidoctorj-pdf", version.ref = "asciidoctorj-pdf" }
 eclipse-platform = { module = "org.eclipse.platform:org.eclipse.platform", version.ref = "eclipse" }
 jacoco = { module = "org.jacoco:jacoco", version.ref = "jacoco" }
-jruby = { module = "org.jruby:jruby", version.ref = "jruby" }
 junit4-latest = { module = "junit:junit", version.ref = "junit4" }
 junit4-bundle = { module = "org.apache.servicemix.bundles:org.apache.servicemix.bundles.junit", version = "4.13.2_1" }
 ktlint-cli = { module = "com.pinterest.ktlint:ktlint-cli", version.ref = "ktlint" }
@@ -94,8 +89,6 @@ xmlunit = ["xmlunit-assertj", "xmlunit-placeholders", "xmlunit-jakarta-jaxb-impl
 
 [plugins]
 antora = { id = "org.antora", version = "1.0.0" }
-asciidoctorConvert = { id = "org.asciidoctor.jvm.convert", version.ref = "asciidoctor-plugins" }
-asciidoctorPdf = { id = "org.asciidoctor.jvm.pdf", version.ref = "asciidoctor-plugins" }
 bnd = { id = "biz.aQute.bnd", version.ref = "bnd" }
 buildParameters = { id = "org.gradlex.build-parameters", version = "1.4.4" }
 commonCustomUserData = { id = "com.gradle.common-custom-user-data-gradle-plugin", version = "2.4.0" }

From c76c6ab62d6ab53ad27d99fc7a321752b76eca32 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 23 Nov 2025 19:46:19 +0100
Subject: [PATCH 07/57] Remove git-publish plugin and corresponding GitHub
 Action steps

---
 .github/workflows/main.yml             | 18 +-------
 documentation/documentation.gradle.kts | 62 --------------------------
 gradle/libs.versions.toml              |  1 -
 3 files changed, 1 insertion(+), 80 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index bf4d92714ec6..076d64c040af 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -127,21 +127,5 @@ jobs:
       with:
         encryptionKey: ${{ secrets.GRADLE_ENCRYPTION_KEY }}
         arguments: |
-          prepareDocsForUploadToGhPages \
+          antora \
           -Dscan.tag.Documentation
-    - name: Configure Git
-      shell: bash
-      run: |
-        git config --global user.name "JUnit Team"
-        git config --global user.email "team@junit.org"
-    - name: Upload Documentation
-      if: github.event_name == 'push' && github.repository == 'junit-team/junit-framework' && github.ref == 'refs/heads/main'
-      uses: ./.github/actions/run-gradle
-      with:
-        encryptionKey: ${{ secrets.GRADLE_ENCRYPTION_KEY }}
-        arguments: |
-          gitPublishPush \
-          -Dscan.tag.Documentation
-      env:
-        GIT_USERNAME: git
-        GIT_PASSWORD: ${{ secrets.JUNIT_BUILDS_GITHUB_TOKEN_DOCS_REPO }}
diff --git a/documentation/documentation.gradle.kts b/documentation/documentation.gradle.kts
index fe3cd839c39d..46348e9c5b01 100644
--- a/documentation/documentation.gradle.kts
+++ b/documentation/documentation.gradle.kts
@@ -8,7 +8,6 @@ import junitbuild.javadoc.ModuleSpecificJavadocFileOption
 import org.gradle.api.tasks.PathSensitivity.RELATIVE
 
 plugins {
-	alias(libs.plugins.gitPublish)
 	alias(libs.plugins.plantuml)
 	id("junitbuild.antora-conventions")
 	id("junitbuild.build-parameters")
@@ -91,30 +90,6 @@ val userGuidePdfFileName = "junit-user-guide-${version}.pdf"
 val ota4jDocVersion = libs.versions.opentest4j.map { if (it.isSnapshot()) "snapshot" else it }.get()
 val apiGuardianDocVersion = libs.versions.apiguardian.map { if (it.isSnapshot()) "snapshot" else it }.get()
 
-gitPublish {
-	repoUri = "https://github.com/junit-team/docs.junit.org.git"
-
-	branch = "main"
-	sign = false
-	fetchDepth = 1
-
-	username = providers.environmentVariable("GIT_USERNAME")
-	password = providers.environmentVariable("GIT_PASSWORD")
-
-	contents {
-		from(docsDir)
-		into(".")
-	}
-
-	preserve {
-		include("**/*")
-		exclude("$docsVersion/**")
-		if (replaceCurrentDocs) {
-			exclude("current/**")
-		}
-	}
-}
-
 val generatedAsciiDocPath = layout.buildDirectory.dir("generated/asciidoc")
 val consoleLauncherOptionsFile = generatedAsciiDocPath.map { it.file("console-launcher-options.txt") }
 val consoleLauncherDiscoverOptionsFile = generatedAsciiDocPath.map { it.file("console-launcher-discover-options.txt") }
@@ -390,43 +365,6 @@ tasks {
 		into(layout.buildDirectory.dir("docs/fixedJavadoc"))
 	}
 
-	val prepareDocsForUploadToGhPages by registering(Copy::class) {
-		outputs.dir(docsDir)
-
-		from(fixJavadoc.map { it.destinationDir }) {
-			into("api")
-		}
-		into(docsDir.map { it.dir(docsVersion.toString()) })
-		includeEmptyDirs = false
-	}
-
-	val createCurrentDocsFolder by registering(Copy::class) {
-		dependsOn(prepareDocsForUploadToGhPages)
-		onlyIf { replaceCurrentDocs }
-
-		from(docsDir.map { it.dir(docsVersion.toString()) })
-		into(docsDir.map { it.dir("current") })
-	}
-
-	val configureGitAuthor by registering {
-		dependsOn(gitPublishReset)
-		doFirst {
-			File(gitPublish.repoDir.get().asFile, ".git/config").appendText("""
-				[user]
-					name = JUnit Team
-					email = team@junit.org
-			""".trimIndent())
-		}
-	}
-
-	gitPublishCopy {
-		dependsOn(prepareDocsForUploadToGhPages, createCurrentDocsFolder)
-	}
-
-	gitPublishCommit {
-		dependsOn(configureGitAuthor)
-	}
-
 	val prepareGitHubAttestation by registering(Sync::class) {
 		from(attestationClasspath)
 		into(layout.buildDirectory.dir("attestation"))
diff --git a/gradle/libs.versions.toml b/gradle/libs.versions.toml
index 6fd166447ed1..abe0b88fd124 100644
--- a/gradle/libs.versions.toml
+++ b/gradle/libs.versions.toml
@@ -96,7 +96,6 @@ develocity = { id = "com.gradle.develocity", version = "4.2.2" }
 download = { id = "de.undercouch.download", version = "5.6.0" }
 errorProne = { id = "net.ltgt.errorprone", version = "4.3.0" }
 foojayResolver = { id = "org.gradle.toolchains.foojay-resolver", version = "1.0.0" }
-gitPublish = { id = "org.ajoberstar.git-publish", version = "5.1.3" }
 jmh = { id = "me.champeau.jmh", version = "0.7.3" }
 jreleaser = { id = "org.jreleaser", version = "1.21.0" }
 # check if workaround in gradle.properties can be removed when updating

From fd01ffa00526486c316247cb303fed75e7c90c84 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 16:39:47 +0100
Subject: [PATCH 08/57] Use Node.js plugin directly

---
 documentation/.tool-versions                  |  1 +
 gradle/libs.versions.toml                     |  3 +-
 gradle/plugins/antora/build.gradle.kts        |  2 +-
 .../junitbuild.antora-conventions.gradle.kts  | 42 ++++++++++++++++---
 .../plugins/build-parameters/build.gradle.kts |  6 +++
 5 files changed, 45 insertions(+), 9 deletions(-)
 create mode 100644 documentation/.tool-versions

diff --git a/documentation/.tool-versions b/documentation/.tool-versions
new file mode 100644
index 000000000000..9d709112585c
--- /dev/null
+++ b/documentation/.tool-versions
@@ -0,0 +1 @@
+nodejs 24.11.1
diff --git a/gradle/libs.versions.toml b/gradle/libs.versions.toml
index abe0b88fd124..6f06005720c2 100644
--- a/gradle/libs.versions.toml
+++ b/gradle/libs.versions.toml
@@ -88,7 +88,6 @@ log4j = ["log4j-core", "log4j-jul"]
 xmlunit = ["xmlunit-assertj", "xmlunit-placeholders", "xmlunit-jakarta-jaxb-impl", "jaxb-api", "jaxb-runtime"]
 
 [plugins]
-antora = { id = "org.antora", version = "1.0.0" }
 bnd = { id = "biz.aQute.bnd", version.ref = "bnd" }
 buildParameters = { id = "org.gradlex.build-parameters", version = "1.4.4" }
 commonCustomUserData = { id = "com.gradle.common-custom-user-data-gradle-plugin", version = "2.4.0" }
@@ -100,7 +99,7 @@ jmh = { id = "me.champeau.jmh", version = "0.7.3" }
 jreleaser = { id = "org.jreleaser", version = "1.21.0" }
 # check if workaround in gradle.properties can be removed when updating
 kotlin = { id = "org.jetbrains.kotlin.jvm", version = "2.2.21" }
-node = { id = "com.github.node-gradle.node", version = "5.0.0" }
+node = { id = "com.github.node-gradle.node", version = "7.1.0" }
 nullaway = { id = "net.ltgt.nullaway", version = "2.3.0" }
 plantuml = { id = "io.freefair.plantuml", version = "9.1.0" }
 shadow = { id = "com.gradleup.shadow", version = "9.3.0" }
diff --git a/gradle/plugins/antora/build.gradle.kts b/gradle/plugins/antora/build.gradle.kts
index f6d134a2104d..1e1dab1109c6 100644
--- a/gradle/plugins/antora/build.gradle.kts
+++ b/gradle/plugins/antora/build.gradle.kts
@@ -6,7 +6,7 @@ plugins {
 }
 
 dependencies {
-	implementation(libs.plugins.antora.markerCoordinates)
+	implementation(projects.buildParameters)
 	implementation(libs.plugins.node.markerCoordinates)
 	implementation(libs.plugins.spring.antora.markerCoordinates)
 }
diff --git a/gradle/plugins/antora/src/main/kotlin/junitbuild.antora-conventions.gradle.kts b/gradle/plugins/antora/src/main/kotlin/junitbuild.antora-conventions.gradle.kts
index 969a50f1dc3c..6cf648dcfef3 100644
--- a/gradle/plugins/antora/src/main/kotlin/junitbuild.antora-conventions.gradle.kts
+++ b/gradle/plugins/antora/src/main/kotlin/junitbuild.antora-conventions.gradle.kts
@@ -1,8 +1,9 @@
-import org.antora.gradle.AntoraExtension
+import com.github.gradle.node.npm.task.NpxTask
 
 plugins {
-	id("org.antora")
+	id("com.github.node-gradle.node")
 	id("io.spring.antora.generate-antora-yml")
+	id("junitbuild.build-parameters")
 }
 
 repositories {
@@ -35,10 +36,39 @@ val generateAntoraPlaybook by tasks.registering(Copy::class) {
 		}
 		return@filter result
 	}
-	into(layout.buildDirectory.dir("antora"))
+	into(layout.buildDirectory.dir("antora-playbook"))
 }
 
-the<AntoraExtension>().apply {
-	setOptions(mapOf("clean" to true, "stacktrace" to true, "fetch" to true))
-	playbook = generateAntoraPlaybook.map { it.rootSpec.destinationDir.resolve("antora-playbook.yml") }
+node {
+	download = buildParameters.antora.downloadNode
+	version = providers.fileContents(layout.projectDirectory.file(".tool-versions")).asText.map {
+		it.substringAfter("nodejs").trim()
+	}
+}
+
+tasks.npmInstall {
+	args.addAll("--no-audit", "--no-package-lock", "--no-fund")
+}
+
+tasks.register<NpxTask>("antora") {
+	dependsOn(tasks.npmInstall)
+	description = "Runs Antora to generate a documentation site described by the playbook file."
+
+	command = "antora"
+	args.addAll("--clean", "--stacktrace", "--fetch")
+
+	args.add("--to-dir")
+	val outputDir = layout.buildDirectory.dir("antora-site")
+	args.add(outputDir.map { it.asFile.toRelativeString(layout.projectDirectory.asFile) })
+	outputs.dir(outputDir)
+
+	outputs.upToDateWhen { false } // not all inputs are tracked
+
+	val playbook = generateAntoraPlaybook.map { it.rootSpec.destinationDir.resolve("antora-playbook.yml") }
+	args.add(playbook.map { it.toRelativeString(layout.projectDirectory.asFile) })
+	inputs.file(playbook)
+
+	doLast {
+		println("Antora site built in ${outputDir.get().asFile.absoluteFile}")
+	}
 }
diff --git a/gradle/plugins/build-parameters/build.gradle.kts b/gradle/plugins/build-parameters/build.gradle.kts
index 8cdab340d4c3..da78534d2750 100644
--- a/gradle/plugins/build-parameters/build.gradle.kts
+++ b/gradle/plugins/build-parameters/build.gradle.kts
@@ -114,4 +114,10 @@ buildParameters {
 			description = "Overrides the value of the 'Created-By' jar manifest entry"
 		}
 	}
+	group("antora") {
+		bool("downloadNode") {
+			description = "Whether to download Node.js from the Gradle build"
+			defaultValue = true
+		}
+	}
 }

From b915c80f7957c237a4024c5e30297ce818d5e280 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:02:34 +0100
Subject: [PATCH 09/57] Install Node.js via GitHub Action

---
 .github/workflows/main.yml | 5 +++++
 .github/zizmor.yml         | 5 +++++
 2 files changed, 10 insertions(+)
 create mode 100644 .github/zizmor.yml

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 076d64c040af..e8dd8512ae8c 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -122,10 +122,15 @@ jobs:
       run: |
         sudo apt-get update
         sudo apt-get install graphviz
+    - name: Install Node.js
+      uses: actions/setup-node@395ad3262231945c25e8478fd5baf05154b1d79f # v6.1.0
+      with:
+        node-version-file: documentation/.tool-versions
     - name: Build Documentation
       uses: ./.github/actions/run-gradle
       with:
         encryptionKey: ${{ secrets.GRADLE_ENCRYPTION_KEY }}
         arguments: |
           antora \
+          -Pantora.downloadNode=false \
           -Dscan.tag.Documentation
diff --git a/.github/zizmor.yml b/.github/zizmor.yml
new file mode 100644
index 000000000000..a646ea1727c0
--- /dev/null
+++ b/.github/zizmor.yml
@@ -0,0 +1,5 @@
+rules:
+  cache-poisoning:
+    ignore:
+      # reports issues for setup-node which isn't used while releasing
+      - main.yml

From 6f770d0efd313133767720159f0fccc8272b311b Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:06 +0100
Subject: [PATCH 10/57] Move images to Antora module

---
 .../extensions_BrokenLifecycleMethodConfigDemo.png  | Bin
 .../extensions_BrokenLifecycleMethodConfigDemo.txt  |   0
 .../ROOT}/images/extensions_DatabaseTestsDemo.png   | Bin
 .../ROOT}/images/extensions_DatabaseTestsDemo.txt   |   0
 .../ROOT}/images/extensions_StoreHierarchy.svg      |   0
 .../ROOT}/images/extensions_lifecycle.png           | Bin
 .../ROOT}/images/extensions_lifecycle_source.docx   | Bin
 .../ROOT}/images/writing-tests_execution_mode.svg   |   0
 .../ROOT}/images/writing-tests_nested_test_ide.png  | Bin
 gradle/config/checkstyle/suppressions.xml           |   2 +-
 10 files changed, 1 insertion(+), 1 deletion(-)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT}/images/extensions_BrokenLifecycleMethodConfigDemo.png (100%)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT}/images/extensions_BrokenLifecycleMethodConfigDemo.txt (100%)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT}/images/extensions_DatabaseTestsDemo.png (100%)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT}/images/extensions_DatabaseTestsDemo.txt (100%)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT}/images/extensions_StoreHierarchy.svg (100%)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT}/images/extensions_lifecycle.png (100%)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT}/images/extensions_lifecycle_source.docx (100%)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT}/images/writing-tests_execution_mode.svg (100%)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT}/images/writing-tests_nested_test_ide.png (100%)

diff --git a/documentation/src/docs/asciidoc/user-guide/images/extensions_BrokenLifecycleMethodConfigDemo.png b/documentation/modules/ROOT/images/extensions_BrokenLifecycleMethodConfigDemo.png
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/images/extensions_BrokenLifecycleMethodConfigDemo.png
rename to documentation/modules/ROOT/images/extensions_BrokenLifecycleMethodConfigDemo.png
diff --git a/documentation/src/docs/asciidoc/user-guide/images/extensions_BrokenLifecycleMethodConfigDemo.txt b/documentation/modules/ROOT/images/extensions_BrokenLifecycleMethodConfigDemo.txt
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/images/extensions_BrokenLifecycleMethodConfigDemo.txt
rename to documentation/modules/ROOT/images/extensions_BrokenLifecycleMethodConfigDemo.txt
diff --git a/documentation/src/docs/asciidoc/user-guide/images/extensions_DatabaseTestsDemo.png b/documentation/modules/ROOT/images/extensions_DatabaseTestsDemo.png
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/images/extensions_DatabaseTestsDemo.png
rename to documentation/modules/ROOT/images/extensions_DatabaseTestsDemo.png
diff --git a/documentation/src/docs/asciidoc/user-guide/images/extensions_DatabaseTestsDemo.txt b/documentation/modules/ROOT/images/extensions_DatabaseTestsDemo.txt
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/images/extensions_DatabaseTestsDemo.txt
rename to documentation/modules/ROOT/images/extensions_DatabaseTestsDemo.txt
diff --git a/documentation/src/docs/asciidoc/user-guide/images/extensions_StoreHierarchy.svg b/documentation/modules/ROOT/images/extensions_StoreHierarchy.svg
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/images/extensions_StoreHierarchy.svg
rename to documentation/modules/ROOT/images/extensions_StoreHierarchy.svg
diff --git a/documentation/src/docs/asciidoc/user-guide/images/extensions_lifecycle.png b/documentation/modules/ROOT/images/extensions_lifecycle.png
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/images/extensions_lifecycle.png
rename to documentation/modules/ROOT/images/extensions_lifecycle.png
diff --git a/documentation/src/docs/asciidoc/user-guide/images/extensions_lifecycle_source.docx b/documentation/modules/ROOT/images/extensions_lifecycle_source.docx
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/images/extensions_lifecycle_source.docx
rename to documentation/modules/ROOT/images/extensions_lifecycle_source.docx
diff --git a/documentation/src/docs/asciidoc/user-guide/images/writing-tests_execution_mode.svg b/documentation/modules/ROOT/images/writing-tests_execution_mode.svg
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/images/writing-tests_execution_mode.svg
rename to documentation/modules/ROOT/images/writing-tests_execution_mode.svg
diff --git a/documentation/src/docs/asciidoc/user-guide/images/writing-tests_nested_test_ide.png b/documentation/modules/ROOT/images/writing-tests_nested_test_ide.png
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/images/writing-tests_nested_test_ide.png
rename to documentation/modules/ROOT/images/writing-tests_nested_test_ide.png
diff --git a/gradle/config/checkstyle/suppressions.xml b/gradle/config/checkstyle/suppressions.xml
index 7572f8b1a4d6..092a2a2dadc9 100644
--- a/gradle/config/checkstyle/suppressions.xml
+++ b/gradle/config/checkstyle/suppressions.xml
@@ -3,5 +3,5 @@
 	<suppress checks="JavadocPackage"
 		files="junit-jupiter-api[\\/]build[\\/]generated[\\/]sources[\\/]jte[\\/]main[\\/]org[\\/]junit[\\/]jupiter[\\/]api[\\/]condition[\\/]*"/>
 	<suppress checks="NoHttp"
-		files="documentation[\\/]src[\\/]docs[\\/]asciidoc[\\/]user-guide[\\/]images[\\/]extensions_StoreHierarchy.svg"/>
+		files="documentation[\\/]modules[\\/]ROOT[\\/]images[\\/]extensions_StoreHierarchy.svg"/>
 </suppressions>

From 566beecc43fa0eba2a17ad8c1f372a48e4c27b23 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:06 +0100
Subject: [PATCH 11/57] Migrate link attributes to antora.yml

---
 documentation/antora.yml                      | 271 +++++++++++++++++
 .../src/docs/asciidoc/link-attributes.adoc    | 272 ------------------
 2 files changed, 271 insertions(+), 272 deletions(-)
 delete mode 100644 documentation/src/docs/asciidoc/link-attributes.adoc

diff --git a/documentation/antora.yml b/documentation/antora.yml
index 5abd0da10059..9afb0753ee7f 100644
--- a/documentation/antora.yml
+++ b/documentation/antora.yml
@@ -22,3 +22,274 @@ ext:
     - dir: ./build/plantuml
       clean: true
       into: modules/ROOT/images
+asciidoc:
+  attributes:
+    javadoc-root: "xref:attachment$api/"
+    # Snapshot Repository
+    snapshot-repo: 'https://central.sonatype.com/service/rest/repository/browse/maven-snapshots'
+    # Base Links
+    junit-team: 'https://github.com/junit-team'
+    junit-framework-repo: '{junit-team}/junit-framework'
+    current-branch: '{junit-framework-repo}/tree/{release-branch}'
+    # Platform Commons
+    junit-platform-support-package: '{javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/support/package-summary.html[org.junit.platform.commons.support]'
+    AnnotationSupport: '{javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/support/AnnotationSupport.html[AnnotationSupport]'
+    ClassSupport: '{javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/support/ClassSupport.html[ClassSupport]'
+    ConversionSupport: '{javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/support/conversion/ConversionSupport.html[ConversionSupport]'
+    ModifierSupport: '{javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/support/ModifierSupport.html[ModifierSupport]'
+    ReflectionSupport: '{javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/support/ReflectionSupport.html[ReflectionSupport]'
+    Testable: '{javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/annotation/Testable.html[@Testable]'
+    # Platform Console Launcher
+    junit-platform-console: '{javadoc-root}/org.junit.platform.console/org/junit/platform/console/package-summary.html[junit-platform-console]'
+    ConsoleLauncher: '{javadoc-root}/org.junit.platform.console/org/junit/platform/console/ConsoleLauncher.html[ConsoleLauncher]'
+    # Platform Engine
+    junit-platform-engine: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/package-summary.html[junit-platform-engine]'
+    junit-platform-engine-support-discovery: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/support/discovery/package-summary.html[org.junit.platform.engine.support.discovery]'
+    CancellationToken: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/CancellationToken.html[CancellationToken]'
+    ClasspathResourceSelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/ClasspathResourceSelector.html[ClasspathResourceSelector]'
+    ClasspathRootSelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/ClasspathRootSelector.html[ClasspathRootSelector]'
+    ClassSelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/ClassSelector.html[ClassSelector]'
+    DiscoveryIssue: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/DiscoveryIssue.html[DiscoveryIssue]'
+    DiscoveryIssueReporter: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/support/discovery/DiscoveryIssueReporter.html[DiscoveryIssueReporter]'
+    DirectorySelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DirectorySelector.html[DirectorySelector]'
+    DiscoverySelectors: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html[DiscoverySelectors]'
+    DiscoverySelectors_selectClasspathResource: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectClasspathResource(java.lang.String)[selectClasspathResource]'
+    DiscoverySelectors_selectClasspathRoots: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectClasspathRoots(java.util.Set)[selectClasspathRoots]'
+    DiscoverySelectors_selectClass: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectClass(java.lang.String)[selectClass]'
+    DiscoverySelectors_selectDirectory: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectDirectory(java.lang.String)[selectDirectory]'
+    DiscoverySelectors_selectFile: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectFile(java.lang.String)[selectFile]'
+    DiscoverySelectors_selectIteration: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectIteration(org.junit.platform.engine.DiscoverySelector,int\...)[selectIteration]'
+    DiscoverySelectors_selectMethod: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectMethod(java.lang.String)[selectMethod]'
+    DiscoverySelectors_selectModule: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectModule(java.lang.String)[selectModule]'
+    DiscoverySelectors_selectNestedClass: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectNestedClass(java.util.List,java.lang.Class)[selectNestedClass]'
+    DiscoverySelectors_selectNestedMethod: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectNestedMethod(java.util.List,java.lang.Class,java.lang.String)[selectNestedMethod]'
+    DiscoverySelectors_selectPackage: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectPackage(java.lang.String)[selectPackage]'
+    DiscoverySelectors_selectUniqueId: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectUniqueId(java.lang.String)[selectUniqueId]'
+    DiscoverySelectors_selectUri: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectUri(java.lang.String)[selectUri]'
+    EngineDiscoveryListener: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/EngineDiscoveryListener.html[EngineDiscoveryListener]'
+    EngineDiscoveryRequest: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/EngineDiscoveryRequest.html[EngineDiscoveryRequest]'
+    FileSelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/FileSelector.html[FileSelector]'
+    HierarchicalTestEngine: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/support/hierarchical/HierarchicalTestEngine.html[HierarchicalTestEngine]'
+    IterationSelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/IterationSelector.html[IterationSelector]'
+    MethodSelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/MethodSelector.html[MethodSelector]'
+    ModuleSelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/ModuleSelector.html[ModuleSelector]'
+    NamespacedHierarchicalStore: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/support/store/NamespacedHierarchicalStore.html[NamespacedHierarchicalStore]'
+    NestedClassSelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/NestedClassSelector.html[NestedClassSelector]'
+    NestedMethodSelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/NestedMethodSelector.html[NestedMethodSelector]'
+    OutputDirectoryCreator: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/OutputDirectoryCreator.html[OutputDirectoryCreator]'
+    PackageSelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/PackageSelector.html[PackageSelector]'
+    ParallelExecutionConfigurationStrategy: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/support/hierarchical/ParallelExecutionConfigurationStrategy.html[ParallelExecutionConfigurationStrategy]'
+    UniqueIdSelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/UniqueIdSelector.html[UniqueIdSelector]'
+    UriSelector: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/UriSelector.html[UriSelector]'
+    TestEngine: '{javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/TestEngine.html[TestEngine]'
+    # Platform Launcher API
+    junit-platform-launcher: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/package-summary.html[junit-platform-launcher]'
+    DiscoveryIssueException: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/core/DiscoveryIssueException.html[DiscoveryIssueException]'
+    Launcher: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/Launcher.html[Launcher]'
+    LauncherConfig: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/core/LauncherConfig.html[LauncherConfig]'
+    LauncherDiscoveryListener: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/LauncherDiscoveryListener.html[LauncherDiscoveryListener]'
+    LauncherDiscoveryRequest: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/LauncherDiscoveryRequest.html[LauncherDiscoveryRequest]'
+    LauncherDiscoveryRequestBuilder: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/core/LauncherDiscoveryRequestBuilder.html[LauncherDiscoveryRequestBuilder]'
+    LauncherExecutionRequest: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/LauncherExecutionRequest.html[LauncherExecutionRequest]'
+    LauncherExecutionRequestBuilder: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/core/LauncherExecutionRequestBuilder.html[LauncherExecutionRequestBuilder]'
+    LauncherFactory: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/core/LauncherFactory.html[LauncherFactory]'
+    LauncherInterceptor: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/LauncherInterceptor.html[LauncherInterceptor]'
+    LauncherSession: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/LauncherSession.html[LauncherSession]'
+    LauncherSessionListener: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/LauncherSessionListener.html[LauncherSessionListener]'
+    LoggingListener: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/listeners/LoggingListener.html[LoggingListener]'
+    PostDiscoveryFilter: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/PostDiscoveryFilter.html[PostDiscoveryFilter]'
+    SummaryGeneratingListener: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/listeners/SummaryGeneratingListener.html[SummaryGeneratingListener]'
+    TestExecutionListener: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/TestExecutionListener.html[TestExecutionListener]'
+    TestPlan: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/TestPlan.html[TestPlan]'
+    UniqueIdTrackingListener: '{javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/listeners/UniqueIdTrackingListener.html[UniqueIdTrackingListener]'
+    # Platform Reporting
+    LegacyXmlReportGeneratingListener: '{javadoc-root}/org.junit.platform.reporting/org/junit/platform/reporting/legacy/xml/LegacyXmlReportGeneratingListener.html[LegacyXmlReportGeneratingListener]'
+    OpenTestReportGeneratingListener: '{javadoc-root}/org.junit.platform.reporting/org/junit/platform/reporting/open/xml/OpenTestReportGeneratingListener.html[OpenTestReportGeneratingListener]'
+    # Platform Suite
+    suite-api-package: '{javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/package-summary.html[org.junit.platform.suite.api]'
+    junit-platform-suite-engine: '{javadoc-root}/org.junit.platform.suite.engine/org/junit/platform/suite/engine/package-summary.html[junit-platform-suite-engine]'
+    Select: '{javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/Select.html[@Select]'
+    SelectClasspathResource: '{javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectClasspathResource.html[@SelectClasspathResource]'
+    SelectClasses: '{javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectClasses.html[@SelectClasses]'
+    SelectDirectories: '{javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectDirectories.html[@SelectDirectories]'
+    SelectFile: '{javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectFile.html[@SelectFile]'
+    SelectMethod: '{javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectMethod.html[@SelectMethod]'
+    SelectModules: '{javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectModules.html[@SelectModules]'
+    SelectPackages: '{javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectPackages.html[@SelectPackages]'
+    SelectUris: '{javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectUris.html[@SelectUris]'
+    # Platform Test Kit
+    testkit-engine-package: '{javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/package-summary.html[org.junit.platform.testkit.engine]'
+    EngineExecutionResults: '{javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/EngineExecutionResults.html[EngineExecutionResults]'
+    EngineTestKit: '{javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/EngineTestKit.html[EngineTestKit]'
+    Event: '{javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/Event.html[Event]'
+    EventConditions: '{javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/EventConditions.html[EventConditions]'
+    Events: '{javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/Events.html[Events]'
+    EventStatistics: '{javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/EventStatistics.html[EventStatistics]'
+    EventType: '{javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/EventType.html[EventType]'
+    Executions: '{javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/Executions.html[Executions]'
+    TerminationInfo: '{javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/TerminationInfo.html[TerminationInfo]'
+    TestExecutionResultConditions: '{javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/TestExecutionResultConditions.html[TestExecutionResultConditions]'
+    # Jupiter Core API
+    api-package: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/package-summary.html[org.junit.jupiter.api]'
+    Assertions: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/Assertions.html[org.junit.jupiter.api.Assertions]'
+    Assumptions: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/Assumptions.html[org.junit.jupiter.api.Assumptions]'
+    AutoClose: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/AutoClose.html[@AutoClose]'
+    ClassOrderer_ClassName: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassOrderer.ClassName.html[ClassOrderer.ClassName]'
+    ClassOrderer_Default: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassOrderer.Default.html[ClassOrderer.Default]'
+    ClassOrderer_DisplayName: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassOrderer.DisplayName.html[ClassOrderer.DisplayName]'
+    ClassOrderer_OrderAnnotation: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassOrderer.OrderAnnotation.html[ClassOrderer.OrderAnnotation]'
+    ClassOrderer_Random: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassOrderer.Random.html[ClassOrderer.Random]'
+    ClassOrderer: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassOrderer.html[ClassOrderer]'
+    ClassTemplate: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassTemplate.html[@ClassTemplate]'
+    Disabled: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/Disabled.html[@Disabled]'
+    MethodOrderer_Default: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/MethodOrderer.Default.html[MethodOrderer.Default]'
+    MethodOrderer_DisplayName: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/MethodOrderer.DisplayName.html[MethodOrderer.DisplayName]'
+    MethodOrderer_MethodName: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/MethodOrderer.MethodName.html[MethodOrderer.MethodName]'
+    MethodOrderer_OrderAnnotation: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/MethodOrderer.OrderAnnotation.html[MethodOrderer.OrderAnnotation]'
+    MethodOrderer_Random: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/MethodOrderer.Random.html[MethodOrderer.Random]'
+    MethodOrderer: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/MethodOrderer.html[MethodOrderer]'
+    Named: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/Named.html[Named]'
+    Order: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/Order.html[@Order]'
+    RepetitionInfo: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/RepetitionInfo.html[RepetitionInfo]'
+    TestInfo: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/TestInfo.html[TestInfo]'
+    TestClassOrder: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/TestClassOrder.html[@TestClassOrder]'
+    TestMethodOrder: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/TestMethodOrder.html[@TestMethodOrder]'
+    TestReporter: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/TestReporter.html[TestReporter]'
+    TestTemplate: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/TestTemplate.html[@TestTemplate]'
+    # @DefaultLocale and @DefaultTimeZone
+    DefaultLocale: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/DefaultLocale.html[@DefaultLocale]'
+    DefaultTimeZone: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/DefaultTimeZone.html[@DefaultTimeZone]'
+    LocaleProvider: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/LocaleProvider.html[LocaleProvider]'
+    TimeZoneProvider: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/TimeZoneProvider.html[TimeZoneProvider]'
+    ReadsDefaultLocale: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/ReadsDefaultLocale.html[@ReadsDefaultLocale]'
+    ReadsDefaultTimeZone: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/ReadsDefaultTimeZone.html[@ReadsDefaultTimeZone]'
+    WritesDefaultLocale: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/WritesDefaultLocale.html[@WritesDefaultLocale]'
+    WritesDefaultTimeZone: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/WritesDefaultTimeZone.html[@WritesDefaultTimeZone]'
+    # Jupiter Parallel API
+    Execution: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/parallel/Execution.html[@Execution]'
+    Isolated: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/parallel/Isolated.html[@Isolated]'
+    ResourceLock: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/parallel/ResourceLock.html[@ResourceLock]'
+    ResourceLockTarget: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/parallel/ResourceLockTarget.html[ResourceLockTarget]'
+    ResourceLocksProvider: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/parallel/ResourceLocksProvider.html[ResourceLocksProvider]'
+    Resources: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/parallel/Resources.html[Resources]'
+    # Jupiter Extension APIs
+    extension-api-package: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/package-summary.html[org.junit.jupiter.api.extension]'
+    AfterAllCallback: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/AfterAllCallback.html[AfterAllCallback]'
+    AfterClassTemplateInvocationCallback: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/AfterClassTemplateInvocationCallback.html[AfterClassTemplateInvocationCallback]'
+    AfterEachCallback: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/AfterEachCallback.html[AfterEachCallback]'
+    AfterTestExecutionCallback: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/AfterTestExecutionCallback.html[AfterTestExecutionCallback]'
+    ParameterContext: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ParameterContext.html[ParameterContext]'
+    BeforeAllCallback: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/BeforeAllCallback.html[BeforeAllCallback]'
+    BeforeClassTemplateInvocationCallback: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/BeforeClassTemplateInvocationCallback.html[BeforeClassTemplateInvocationCallback]'
+    BeforeEachCallback: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/BeforeEachCallback.html[BeforeEachCallback]'
+    BeforeTestExecutionCallback: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/BeforeTestExecutionCallback.html[BeforeTestExecutionCallback]'
+    ClassTemplateInvocationContext: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ClassTemplateInvocationContext.html[ClassTemplateInvocationContext]'
+    ClassTemplateInvocationContextProvider: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ClassTemplateInvocationContextProvider.html[ClassTemplateInvocationContextProvider]'
+    ExecutableInvoker: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ExecutableInvoker.html[ExecutableInvoker]'
+    ExecutionCondition: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ExecutionCondition.html[ExecutionCondition]'
+    ExtendWith: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ExtendWith.html[@ExtendWith]'
+    ExtensionContext: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ExtensionContext.html[ExtensionContext]'
+    ExtensionContext_Store: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ExtensionContext.Store.html[Store]'
+    ExtensionContext_StoreScope: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ExtensionContext.StoreScope.html[StoreScope]'
+    InvocationInterceptor: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/InvocationInterceptor.html[InvocationInterceptor]'
+    LifecycleMethodExecutionExceptionHandler: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/LifecycleMethodExecutionExceptionHandler.html[LifecycleMethodExecutionExceptionHandler]'
+    ParameterResolver: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ParameterResolver.html[ParameterResolver]'
+    RegisterExtension: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/RegisterExtension.html[@RegisterExtension]'
+    TestExecutionExceptionHandler: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestExecutionExceptionHandler.html[TestExecutionExceptionHandler]'
+    TestInstanceFactory: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestInstanceFactory.html[TestInstanceFactory]'
+    TestInstancePostProcessor: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestInstancePostProcessor.html[TestInstancePostProcessor]'
+    TestInstancePreConstructCallback: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestInstancePreConstructCallback.html[TestInstancePreConstructCallback]'
+    TestInstancePreDestroyCallback: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestInstancePreDestroyCallback.html[TestInstancePreDestroyCallback]'
+    TestTemplateInvocationContext: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestTemplateInvocationContext.html[TestTemplateInvocationContext]'
+    TestTemplateInvocationContextProvider: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestTemplateInvocationContextProvider.html[TestTemplateInvocationContextProvider]'
+    TestWatcher: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestWatcher.html[TestWatcher]'
+    PreInterruptCallback: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/PreInterruptCallback.html[PreInterruptCallback]'
+    # Jupiter Conditions
+    DisabledForJreRange: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledForJreRange.html[@DisabledForJreRange]'
+    DisabledIf: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledIf.html[@DisabledIf]'
+    DisabledIfEnvironmentVariable: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledIfEnvironmentVariable.html[@DisabledIfEnvironmentVariable]'
+    DisabledIfSystemProperty: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledIfSystemProperty.html[@DisabledIfSystemProperty]'
+    DisabledInNativeImage: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledInNativeImage.html[@DisabledInNativeImage]'
+    DisabledOnJre: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledOnJre.html[@DisabledOnJre]'
+    DisabledOnOs: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledOnOs.html[@DisabledOnOs]'
+    EnabledForJreRange: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledForJreRange.html[@EnabledForJreRange]'
+    EnabledIf: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledIf.html[@EnabledIf]'
+    EnabledIfEnvironmentVariable: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledIfEnvironmentVariable.html[@EnabledIfEnvironmentVariable]'
+    EnabledIfSystemProperty: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledIfSystemProperty.html[@EnabledIfSystemProperty]'
+    EnabledInNativeImage: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledInNativeImage.html[@EnabledInNativeImage]'
+    EnabledOnJre: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledOnJre.html[@EnabledOnJre]'
+    EnabledOnOs: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledOnOs.html[@EnabledOnOs]'
+    JRE: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/JRE.html[JRE]'
+    # Jupiter I/O
+    TempDir: '{javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/io/TempDir.html[@TempDir]'
+    # Jupiter Params
+    params-provider-package: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/package-summary.html[org.junit.jupiter.params.provider]'
+    AfterParameterizedClassInvocation: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/AfterParameterizedClassInvocation.html[@AfterParameterizedClassInvocation]'
+    AnnotationBasedArgumentConverter: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/converter/AnnotationBasedArgumentConverter.html[AnnotationBasedArgumentConverter]'
+    AnnotationBasedArgumentsProvider: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/AnnotationBasedArgumentsProvider.html[AnnotationBasedArgumentsProvider]'
+    AggregateWith: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/aggregator/AggregateWith.html[@AggregateWith]'
+    Arguments: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/Arguments.html[Arguments]'
+    ArgumentsProvider: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/ArgumentsProvider.html[ArgumentsProvider]'
+    ArgumentsAccessor: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/aggregator/ArgumentsAccessor.html[ArgumentsAccessor]'
+    ArgumentsAggregator: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/aggregator/ArgumentsAggregator.html[ArgumentsAggregator]'
+    BeforeParameterizedClassInvocation: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/BeforeParameterizedClassInvocation.html[@BeforeParameterizedClassInvocation]'
+    CsvArgumentsProvider: '{junit-framework-repo}/blob/main/junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/CsvArgumentsProvider.java[CsvArgumentsProvider]'
+    EmptySource: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/EmptySource.html[@EmptySource]'
+    FieldSource: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/FieldSource.html[@FieldSource]'
+    MethodSource: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/MethodSource.html[@MethodSource]'
+    NullAndEmptySource: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/NullAndEmptySource.html[@NullAndEmptySource]'
+    NullSource: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/NullSource.html[@NullSource]'
+    Parameter: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/Parameter.html[@Parameter]'
+    ParameterizedClass: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/ParameterizedClass.html[@ParameterizedClass]'
+    ParameterizedTest: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/ParameterizedTest.html[@ParameterizedTest]'
+    ParameterInfo: '{javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/support/ParameterInfo.html[ParameterInfo]'
+    ValueArgumentsProvider: '{junit-framework-repo}/blob/main/junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/ValueArgumentsProvider.java[ValueArgumentsProvider]'
+    # Jupiter Engine
+    junit-jupiter-engine: '{javadoc-root}/org.junit.jupiter.engine/org/junit/jupiter/engine/package-summary.html[junit-jupiter-engine]'
+    # Jupiter Extension Implementations
+    AutoCloseExtension: '{current-branch}/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/AutoCloseExtension.java[AutoCloseExtension]'
+    DisabledCondition: '{current-branch}/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/DisabledCondition.java[DisabledCondition]'
+    RepetitionExtension: '{current-branch}/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/RepetitionExtension.java[RepetitionExtension]'
+    TempDirectory: '{current-branch}/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/TempDirectory.java[TempDirectory]'
+    TestInfoParameterResolver: '{current-branch}/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/TestInfoParameterResolver.java[TestInfoParameterResolver]'
+    TestReporterParameterResolver: '{current-branch}/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/TestReporterParameterResolver.java[TestReporterParameterResolver]'
+    TypeBasedParameterResolver: '{current-branch}/junit-jupiter-api/src/main/java/org/junit/jupiter/api/extension/support/TypeBasedParameterResolver.java[TypeBasedParameterResolver]'
+    # Jupiter Examples
+    CustomAnnotationParameterResolver: '{current-branch}/jupiter-tests/src/test/java/org/junit/jupiter/engine/execution/injection/sample/CustomAnnotationParameterResolver.java[CustomAnnotationParameterResolver]'
+    CustomTypeParameterResolver: '{current-branch}/jupiter-tests/src/test/java/org/junit/jupiter/engine/execution/injection/sample/CustomTypeParameterResolver.java[CustomTypeParameterResolver]'
+    MapOfListsTypeBasedParameterResolver: '{current-branch}/jupiter-tests/src/test/java/org/junit/jupiter/engine/execution/injection/sample/MapOfListsTypeBasedParameterResolver.java[MapOfListsTypeBasedParameterResolver]'
+    # Jupiter Migration Support
+    EnableJUnit4MigrationSupport: '{javadoc-root}/org.junit.jupiter.migrationsupport/org/junit/jupiter/migrationsupport/EnableJUnit4MigrationSupport.html[@EnableJUnit4MigrationSupport]'
+    EnableRuleMigrationSupport: '{javadoc-root}/org.junit.jupiter.migrationsupport/org/junit/jupiter/migrationsupport/rules/EnableRuleMigrationSupport.html[@EnableRuleMigrationSupport]'
+    # JUnit Start
+    JUnit: '{javadoc-root}/org.junit.start/org/junit/start/JUnit.html[JUnit]'
+    # Vintage
+    junit-vintage-engine: '{javadoc-root}/org.junit.vintage.engine/org/junit/vintage/engine/package-summary.html[junit-vintage-engine]'
+    # Examples Repository
+    junit-examples-repo: '{junit-team}/junit-examples'
+    junit-jupiter-starter-ant: '{junit-examples-repo}/tree/{release-branch}/junit-jupiter-starter-ant[junit-jupiter-starter-ant]'
+    junit-jupiter-starter-gradle-groovy: '{junit-examples-repo}/tree/{release-branch}/junit-jupiter-starter-gradle-groovy[junit-jupiter-starter-gradle-groovy]'
+    junit-jupiter-starter-gradle-kotlin: '{junit-examples-repo}/tree/{release-branch}/junit-jupiter-starter-gradle-kotlin[junit-jupiter-starter-gradle-kotlin]'
+    junit-jupiter-starter-gradle: '{junit-examples-repo}/tree/{release-branch}/junit-jupiter-starter-gradle[junit-jupiter-starter-gradle]'
+    junit-jupiter-starter-maven: '{junit-examples-repo}/tree/{release-branch}/junit-jupiter-starter-maven[junit-jupiter-starter-maven]'
+    RandomParametersExtension: '{junit-examples-repo}/tree/{release-branch}/junit-jupiter-extensions/src/main/java/com/example/random/RandomParametersExtension.java[RandomParametersExtension]'
+    # Third-party Links
+    API: 'https://apiguardian-team.github.io/apiguardian/docs/current/api/[@API]'
+    API_Guardian: 'https://github.com/apiguardian-team/apiguardian[@API Guardian]'
+    AssertJ: 'https://assertj.github.io/doc/[AssertJ]'
+    Checkstyle: 'https://checkstyle.sourceforge.io[Checkstyle]'
+    DiscussionsQA: 'https://github.com/junit-team/junit-framework/discussions/categories/q-a[Q&A category on GitHub Discussions]'
+    Hamcrest: 'https://hamcrest.org/JavaHamcrest/[Hamcrest]'
+    Jimfs: 'https://google.github.io/jimfs/[Jimfs]'
+    Log4j: 'https://logging.apache.org/log4j/2.x/[Log4j]'
+    Log4j_JDK_Logging_Adapter: 'https://logging.apache.org/log4j/2.x/log4j-jul/index.html[Log4j JDK Logging Adapter]'
+    Logback: 'https://logback.qos.ch/[Logback]'
+    LogManager: 'https://docs.oracle.com/en/java/javase/17/docs/api/java.logging/java/util/logging/LogManager.html[LogManager]'
+    Maven_Central: 'https://central.sonatype.com/[Maven Central]'
+    MockitoExtension: 'https://github.com/mockito/mockito/blob/release/2.x/subprojects/junit-jupiter/src/main/java/org/mockito/junit/jupiter/MockitoExtension.java[MockitoExtension]'
+    ServiceLoader: '{jdk-javadoc-base-url}/java.base/java/util/ServiceLoader.html[ServiceLoader]'
+    SpringExtension: 'https://github.com/spring-projects/spring-framework/tree/HEAD/spring-test/src/main/java/org/springframework/test/context/junit/jupiter/SpringExtension.java[SpringExtension]'
+    StackOverflow: 'https://stackoverflow.com/questions/tagged/junit5[Stack Overflow]'
+    Truth: 'https://truth.dev/[Truth]'
+    OpenTestReporting: 'https://github.com/ota4j-team/open-test-reporting[Open Test Reporting]'
+    OpenTestReportingCliTool: 'https://github.com/ota4j-team/open-test-reporting#cli-tool-for-validation-and-format-conversion[Open Test Reporting CLI Tool]'
diff --git a/documentation/src/docs/asciidoc/link-attributes.adoc b/documentation/src/docs/asciidoc/link-attributes.adoc
deleted file mode 100644
index 649b7d2e847d..000000000000
--- a/documentation/src/docs/asciidoc/link-attributes.adoc
+++ /dev/null
@@ -1,272 +0,0 @@
-:javadoc-root:                               link:../api
-ifdef::backend-pdf[]
-:javadoc-root:                               https://docs.junit.org/{docs-version}/api
-endif::[]
-// Snapshot Repository
-:snapshot-repo:                              https://central.sonatype.com/service/rest/repository/browse/maven-snapshots
-// Base Links
-:junit-team:                                 https://github.com/junit-team
-:junit-framework-repo:                       {junit-team}/junit-framework
-:current-branch:                             {junit-framework-repo}/tree/{release-branch}
-// Platform Commons
-:junit-platform-support-package:             {javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/support/package-summary.html[org.junit.platform.commons.support]
-:AnnotationSupport:                          {javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/support/AnnotationSupport.html[AnnotationSupport]
-:ClassSupport:                               {javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/support/ClassSupport.html[ClassSupport]
-:ConversionSupport:                          {javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/support/conversion/ConversionSupport.html[ConversionSupport]
-:ModifierSupport:                            {javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/support/ModifierSupport.html[ModifierSupport]
-:ReflectionSupport:                          {javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/support/ReflectionSupport.html[ReflectionSupport]
-:Testable:                                   {javadoc-root}/org.junit.platform.commons/org/junit/platform/commons/annotation/Testable.html[@Testable]
-// Platform Console Launcher
-:junit-platform-console:                     {javadoc-root}/org.junit.platform.console/org/junit/platform/console/package-summary.html[junit-platform-console]
-:ConsoleLauncher:                            {javadoc-root}/org.junit.platform.console/org/junit/platform/console/ConsoleLauncher.html[ConsoleLauncher]
-// Platform Engine
-:junit-platform-engine:                      {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/package-summary.html[junit-platform-engine]
-:junit-platform-engine-support-discovery:    {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/support/discovery/package-summary.html[org.junit.platform.engine.support.discovery]
-:CancellationToken:                          {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/CancellationToken.html[CancellationToken]
-:ClasspathResourceSelector:                  {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/ClasspathResourceSelector.html[ClasspathResourceSelector]
-:ClasspathRootSelector:                      {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/ClasspathRootSelector.html[ClasspathRootSelector]
-:ClassSelector:                              {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/ClassSelector.html[ClassSelector]
-:DiscoveryIssue:                             {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/DiscoveryIssue.html[DiscoveryIssue]
-:DiscoveryIssueReporter:                     {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/support/discovery/DiscoveryIssueReporter.html[DiscoveryIssueReporter]
-:DirectorySelector:                          {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DirectorySelector.html[DirectorySelector]
-:DiscoverySelectors:                         {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html[DiscoverySelectors]
-:DiscoverySelectors_selectClasspathResource: {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectClasspathResource(java.lang.String)[selectClasspathResource]
-:DiscoverySelectors_selectClasspathRoots:    {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectClasspathRoots(java.util.Set)[selectClasspathRoots]
-:DiscoverySelectors_selectClass:             {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectClass(java.lang.String)[selectClass]
-:DiscoverySelectors_selectDirectory:         {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectDirectory(java.lang.String)[selectDirectory]
-:DiscoverySelectors_selectFile:              {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectFile(java.lang.String)[selectFile]
-:DiscoverySelectors_selectIteration:         {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectIteration(org.junit.platform.engine.DiscoverySelector,int\...)[selectIteration]
-:DiscoverySelectors_selectMethod:            {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectMethod(java.lang.String)[selectMethod]
-:DiscoverySelectors_selectModule:            {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectModule(java.lang.String)[selectModule]
-:DiscoverySelectors_selectNestedClass:       {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectNestedClass(java.util.List,java.lang.Class)[selectNestedClass]
-:DiscoverySelectors_selectNestedMethod:      {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectNestedMethod(java.util.List,java.lang.Class,java.lang.String)[selectNestedMethod]
-:DiscoverySelectors_selectPackage:           {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectPackage(java.lang.String)[selectPackage]
-:DiscoverySelectors_selectUniqueId:          {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectUniqueId(java.lang.String)[selectUniqueId]
-:DiscoverySelectors_selectUri:               {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/DiscoverySelectors.html#selectUri(java.lang.String)[selectUri]
-:EngineDiscoveryListener:                    {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/EngineDiscoveryListener.html[EngineDiscoveryListener]
-:EngineDiscoveryRequest:                     {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/EngineDiscoveryRequest.html[EngineDiscoveryRequest]
-:FileSelector:                               {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/FileSelector.html[FileSelector]
-:HierarchicalTestEngine:                     {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/support/hierarchical/HierarchicalTestEngine.html[HierarchicalTestEngine]
-:IterationSelector:                          {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/IterationSelector.html[IterationSelector]
-:MethodSelector:                             {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/MethodSelector.html[MethodSelector]
-:ModuleSelector:                             {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/ModuleSelector.html[ModuleSelector]
-:NamespacedHierarchicalStore:                {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/support/store/NamespacedHierarchicalStore.html[NamespacedHierarchicalStore]
-:NestedClassSelector:                        {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/NestedClassSelector.html[NestedClassSelector]
-:NestedMethodSelector:                       {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/NestedMethodSelector.html[NestedMethodSelector]
-:OutputDirectoryCreator:                     {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/OutputDirectoryCreator.html[OutputDirectoryCreator]
-:PackageSelector:                            {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/PackageSelector.html[PackageSelector]
-:ParallelExecutionConfigurationStrategy:     {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/support/hierarchical/ParallelExecutionConfigurationStrategy.html[ParallelExecutionConfigurationStrategy]
-:UniqueIdSelector:                           {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/UniqueIdSelector.html[UniqueIdSelector]
-:UriSelector:                                {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/discovery/UriSelector.html[UriSelector]
-:TestEngine:                                 {javadoc-root}/org.junit.platform.engine/org/junit/platform/engine/TestEngine.html[TestEngine]
-// Platform Launcher API
-:junit-platform-launcher:                    {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/package-summary.html[junit-platform-launcher]
-:DiscoveryIssueException:                    {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/core/DiscoveryIssueException.html[DiscoveryIssueException]
-:Launcher:                                   {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/Launcher.html[Launcher]
-:LauncherConfig:                             {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/core/LauncherConfig.html[LauncherConfig]
-:LauncherDiscoveryListener:                  {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/LauncherDiscoveryListener.html[LauncherDiscoveryListener]
-:LauncherDiscoveryRequest:                   {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/LauncherDiscoveryRequest.html[LauncherDiscoveryRequest]
-:LauncherDiscoveryRequestBuilder:            {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/core/LauncherDiscoveryRequestBuilder.html[LauncherDiscoveryRequestBuilder]
-:LauncherExecutionRequest:                   {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/LauncherExecutionRequest.html[LauncherExecutionRequest]
-:LauncherExecutionRequestBuilder:            {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/core/LauncherExecutionRequestBuilder.html[LauncherExecutionRequestBuilder]
-:LauncherFactory:                            {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/core/LauncherFactory.html[LauncherFactory]
-:LauncherInterceptor:                        {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/LauncherInterceptor.html[LauncherInterceptor]
-:LauncherSession:                            {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/LauncherSession.html[LauncherSession]
-:LauncherSessionListener:                    {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/LauncherSessionListener.html[LauncherSessionListener]
-:LoggingListener:                            {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/listeners/LoggingListener.html[LoggingListener]
-:PostDiscoveryFilter:                        {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/PostDiscoveryFilter.html[PostDiscoveryFilter]
-:SummaryGeneratingListener:                  {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/listeners/SummaryGeneratingListener.html[SummaryGeneratingListener]
-:TestExecutionListener:                      {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/TestExecutionListener.html[TestExecutionListener]
-:TestPlan:                                   {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/TestPlan.html[TestPlan]
-:UniqueIdTrackingListener:                   {javadoc-root}/org.junit.platform.launcher/org/junit/platform/launcher/listeners/UniqueIdTrackingListener.html[UniqueIdTrackingListener]
-// Platform Reporting
-:LegacyXmlReportGeneratingListener:          {javadoc-root}/org.junit.platform.reporting/org/junit/platform/reporting/legacy/xml/LegacyXmlReportGeneratingListener.html[LegacyXmlReportGeneratingListener]
-:OpenTestReportGeneratingListener:           {javadoc-root}/org.junit.platform.reporting/org/junit/platform/reporting/open/xml/OpenTestReportGeneratingListener.html[OpenTestReportGeneratingListener]
-// Platform Suite
-:suite-api-package:                          {javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/package-summary.html[org.junit.platform.suite.api]
-:junit-platform-suite-engine:                {javadoc-root}/org.junit.platform.suite.engine/org/junit/platform/suite/engine/package-summary.html[junit-platform-suite-engine]
-:Select:                                     {javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/Select.html[@Select]
-:SelectClasspathResource:                    {javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectClasspathResource.html[@SelectClasspathResource]
-:SelectClasses:                              {javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectClasses.html[@SelectClasses]
-:SelectDirectories:                          {javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectDirectories.html[@SelectDirectories]
-:SelectFile:                                 {javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectFile.html[@SelectFile]
-:SelectMethod:                               {javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectMethod.html[@SelectMethod]
-:SelectModules:                              {javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectModules.html[@SelectModules]
-:SelectPackages:                             {javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectPackages.html[@SelectPackages]
-:SelectUris:                                 {javadoc-root}/org.junit.platform.suite.api/org/junit/platform/suite/api/SelectUris.html[@SelectUris]
-// Platform Test Kit
-:testkit-engine-package:                     {javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/package-summary.html[org.junit.platform.testkit.engine]
-:EngineExecutionResults:                     {javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/EngineExecutionResults.html[EngineExecutionResults]
-:EngineTestKit:                              {javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/EngineTestKit.html[EngineTestKit]
-:Event:                                      {javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/Event.html[Event]
-:EventConditions:                            {javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/EventConditions.html[EventConditions]
-:Events:                                     {javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/Events.html[Events]
-:EventStatistics:                            {javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/EventStatistics.html[EventStatistics]
-:EventType:                                  {javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/EventType.html[EventType]
-:Executions:                                 {javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/Executions.html[Executions]
-:TerminationInfo:                            {javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/TerminationInfo.html[TerminationInfo]
-:TestExecutionResultConditions:              {javadoc-root}/org.junit.platform.testkit/org/junit/platform/testkit/engine/TestExecutionResultConditions.html[TestExecutionResultConditions]
-// Jupiter Core API
-:api-package:                                {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/package-summary.html[org.junit.jupiter.api]
-:Assertions:                                 {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/Assertions.html[org.junit.jupiter.api.Assertions]
-:Assumptions:                                {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/Assumptions.html[org.junit.jupiter.api.Assumptions]
-:AutoClose:                                  {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/AutoClose.html[@AutoClose]
-:ClassOrderer_ClassName:                     {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassOrderer.ClassName.html[ClassOrderer.ClassName]
-:ClassOrderer_Default:                       {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassOrderer.Default.html[ClassOrderer.Default]
-:ClassOrderer_DisplayName:                   {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassOrderer.DisplayName.html[ClassOrderer.DisplayName]
-:ClassOrderer_OrderAnnotation:               {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassOrderer.OrderAnnotation.html[ClassOrderer.OrderAnnotation]
-:ClassOrderer_Random:                        {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassOrderer.Random.html[ClassOrderer.Random]
-:ClassOrderer:                               {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassOrderer.html[ClassOrderer]
-:ClassTemplate:                              {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/ClassTemplate.html[@ClassTemplate]
-:Disabled:                                   {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/Disabled.html[@Disabled]
-:MethodOrderer_Default:                      {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/MethodOrderer.Default.html[MethodOrderer.Default]
-:MethodOrderer_DisplayName:                  {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/MethodOrderer.DisplayName.html[MethodOrderer.DisplayName]
-:MethodOrderer_MethodName:                   {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/MethodOrderer.MethodName.html[MethodOrderer.MethodName]
-:MethodOrderer_OrderAnnotation:              {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/MethodOrderer.OrderAnnotation.html[MethodOrderer.OrderAnnotation]
-:MethodOrderer_Random:                       {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/MethodOrderer.Random.html[MethodOrderer.Random]
-:MethodOrderer:                              {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/MethodOrderer.html[MethodOrderer]
-:Named:                                      {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/Named.html[Named]
-:Order:                                      {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/Order.html[@Order]
-:RepetitionInfo:                             {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/RepetitionInfo.html[RepetitionInfo]
-:TestInfo:                                   {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/TestInfo.html[TestInfo]
-:TestClassOrder:                             {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/TestClassOrder.html[@TestClassOrder]
-:TestMethodOrder:                            {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/TestMethodOrder.html[@TestMethodOrder]
-:TestReporter:                               {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/TestReporter.html[TestReporter]
-:TestTemplate:                               {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/TestTemplate.html[@TestTemplate]
-// @DefaultLocale and @DefaultTimeZone
-:DefaultLocale:                              {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/DefaultLocale.html[@DefaultLocale]
-:DefaultTimeZone:                            {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/DefaultTimeZone.html[@DefaultTimeZone]
-:LocaleProvider:                             {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/LocaleProvider.html[LocaleProvider]
-:TimeZoneProvider:                           {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/TimeZoneProvider.html[TimeZoneProvider]
-:ReadsDefaultLocale:                         {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/ReadsDefaultLocale.html[@ReadsDefaultLocale]
-:ReadsDefaultTimeZone:                       {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/ReadsDefaultTimeZone.html[@ReadsDefaultTimeZone]
-:WritesDefaultLocale:                        {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/WritesDefaultLocale.html[@WritesDefaultLocale]
-:WritesDefaultTimeZone:                      {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/util/WritesDefaultTimeZone.html[@WritesDefaultTimeZone]
-// Jupiter Parallel API
-:Execution:                                  {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/parallel/Execution.html[@Execution]
-:Isolated:                                   {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/parallel/Isolated.html[@Isolated]
-:ResourceLock:                               {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/parallel/ResourceLock.html[@ResourceLock]
-:ResourceLockTarget:                         {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/parallel/ResourceLockTarget.html[ResourceLockTarget]
-:ResourceLocksProvider:                      {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/parallel/ResourceLocksProvider.html[ResourceLocksProvider]
-:Resources:                                  {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/parallel/Resources.html[Resources]
-// Jupiter Extension APIs
-:extension-api-package:                      {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/package-summary.html[org.junit.jupiter.api.extension]
-:AfterAllCallback:                           {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/AfterAllCallback.html[AfterAllCallback]
-:AfterClassTemplateInvocationCallback:       {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/AfterClassTemplateInvocationCallback.html[AfterClassTemplateInvocationCallback]
-:AfterEachCallback:                          {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/AfterEachCallback.html[AfterEachCallback]
-:AfterTestExecutionCallback:                 {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/AfterTestExecutionCallback.html[AfterTestExecutionCallback]
-:ParameterContext:                           {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ParameterContext.html[ParameterContext]
-:BeforeAllCallback:                          {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/BeforeAllCallback.html[BeforeAllCallback]
-:BeforeClassTemplateInvocationCallback:      {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/BeforeClassTemplateInvocationCallback.html[BeforeClassTemplateInvocationCallback]
-:BeforeEachCallback:                         {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/BeforeEachCallback.html[BeforeEachCallback]
-:BeforeTestExecutionCallback:                {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/BeforeTestExecutionCallback.html[BeforeTestExecutionCallback]
-:ClassTemplateInvocationContext:             {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ClassTemplateInvocationContext.html[ClassTemplateInvocationContext]
-:ClassTemplateInvocationContextProvider:     {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ClassTemplateInvocationContextProvider.html[ClassTemplateInvocationContextProvider]
-:ExecutableInvoker:                          {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ExecutableInvoker.html[ExecutableInvoker]
-:ExecutionCondition:                         {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ExecutionCondition.html[ExecutionCondition]
-:ExtendWith:                                 {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ExtendWith.html[@ExtendWith]
-:ExtensionContext:                           {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ExtensionContext.html[ExtensionContext]
-:ExtensionContext_Store:                     {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ExtensionContext.Store.html[Store]
-:ExtensionContext_StoreScope:                {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ExtensionContext.StoreScope.html[StoreScope]
-:InvocationInterceptor:                      {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/InvocationInterceptor.html[InvocationInterceptor]
-:LifecycleMethodExecutionExceptionHandler:   {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/LifecycleMethodExecutionExceptionHandler.html[LifecycleMethodExecutionExceptionHandler]
-:ParameterResolver:                          {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/ParameterResolver.html[ParameterResolver]
-:RegisterExtension:                          {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/RegisterExtension.html[@RegisterExtension]
-:TestExecutionExceptionHandler:              {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestExecutionExceptionHandler.html[TestExecutionExceptionHandler]
-:TestInstanceFactory:                        {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestInstanceFactory.html[TestInstanceFactory]
-:TestInstancePostProcessor:                  {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestInstancePostProcessor.html[TestInstancePostProcessor]
-:TestInstancePreConstructCallback:           {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestInstancePreConstructCallback.html[TestInstancePreConstructCallback]
-:TestInstancePreDestroyCallback:             {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestInstancePreDestroyCallback.html[TestInstancePreDestroyCallback]
-:TestTemplateInvocationContext:              {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestTemplateInvocationContext.html[TestTemplateInvocationContext]
-:TestTemplateInvocationContextProvider:      {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestTemplateInvocationContextProvider.html[TestTemplateInvocationContextProvider]
-:TestWatcher:                                {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestWatcher.html[TestWatcher]
-:PreInterruptCallback:                       {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/extension/PreInterruptCallback.html[PreInterruptCallback]
-// Jupiter Conditions
-:DisabledForJreRange:                        {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledForJreRange.html[@DisabledForJreRange]
-:DisabledIf:                                 {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledIf.html[@DisabledIf]
-:DisabledIfEnvironmentVariable:              {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledIfEnvironmentVariable.html[@DisabledIfEnvironmentVariable]
-:DisabledIfSystemProperty:                   {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledIfSystemProperty.html[@DisabledIfSystemProperty]
-:DisabledInNativeImage:                      {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledInNativeImage.html[@DisabledInNativeImage]
-:DisabledOnJre:                              {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledOnJre.html[@DisabledOnJre]
-:DisabledOnOs:                               {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/DisabledOnOs.html[@DisabledOnOs]
-:EnabledForJreRange:                         {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledForJreRange.html[@EnabledForJreRange]
-:EnabledIf:                                  {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledIf.html[@EnabledIf]
-:EnabledIfEnvironmentVariable:               {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledIfEnvironmentVariable.html[@EnabledIfEnvironmentVariable]
-:EnabledIfSystemProperty:                    {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledIfSystemProperty.html[@EnabledIfSystemProperty]
-:EnabledInNativeImage:                       {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledInNativeImage.html[@EnabledInNativeImage]
-:EnabledOnJre:                               {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledOnJre.html[@EnabledOnJre]
-:EnabledOnOs:                                {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/EnabledOnOs.html[@EnabledOnOs]
-:JRE:                                        {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/condition/JRE.html[JRE]
-// Jupiter I/O
-:TempDir:                                    {javadoc-root}/org.junit.jupiter.api/org/junit/jupiter/api/io/TempDir.html[@TempDir]
-// Jupiter Params
-:params-provider-package:                    {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/package-summary.html[org.junit.jupiter.params.provider]
-:AfterParameterizedClassInvocation:          {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/AfterParameterizedClassInvocation.html[@AfterParameterizedClassInvocation]
-:AnnotationBasedArgumentConverter:           {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/converter/AnnotationBasedArgumentConverter.html[AnnotationBasedArgumentConverter]
-:AnnotationBasedArgumentsProvider:           {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/AnnotationBasedArgumentsProvider.html[AnnotationBasedArgumentsProvider]
-:AggregateWith:                              {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/aggregator/AggregateWith.html[@AggregateWith]
-:Arguments:                                  {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/Arguments.html[Arguments]
-:ArgumentsProvider:                          {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/ArgumentsProvider.html[ArgumentsProvider]
-:ArgumentsAccessor:                          {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/aggregator/ArgumentsAccessor.html[ArgumentsAccessor]
-:ArgumentsAggregator:                        {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/aggregator/ArgumentsAggregator.html[ArgumentsAggregator]
-:BeforeParameterizedClassInvocation:         {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/BeforeParameterizedClassInvocation.html[@BeforeParameterizedClassInvocation]
-:CsvArgumentsProvider:                       {junit-framework-repo}/blob/main/junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/CsvArgumentsProvider.java[CsvArgumentsProvider]
-:EmptySource:                                {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/EmptySource.html[@EmptySource]
-:FieldSource:                                {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/FieldSource.html[@FieldSource]
-:MethodSource:                               {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/MethodSource.html[@MethodSource]
-:NullAndEmptySource:                         {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/NullAndEmptySource.html[@NullAndEmptySource]
-:NullSource:                                 {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/provider/NullSource.html[@NullSource]
-:Parameter:                                  {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/Parameter.html[@Parameter]
-:ParameterizedClass:                         {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/ParameterizedClass.html[@ParameterizedClass]
-:ParameterizedTest:                          {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/ParameterizedTest.html[@ParameterizedTest]
-:ParameterInfo:                              {javadoc-root}/org.junit.jupiter.params/org/junit/jupiter/params/support/ParameterInfo.html[ParameterInfo]
-:ValueArgumentsProvider:                     {junit-framework-repo}/blob/main/junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/ValueArgumentsProvider.java[ValueArgumentsProvider]
-// Jupiter Engine
-:junit-jupiter-engine:                       {javadoc-root}/org.junit.jupiter.engine/org/junit/jupiter/engine/package-summary.html[junit-jupiter-engine]
-// Jupiter Extension Implementations
-:AutoCloseExtension:                         {current-branch}/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/AutoCloseExtension.java[AutoCloseExtension]
-:DisabledCondition:                          {current-branch}/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/DisabledCondition.java[DisabledCondition]
-:RepetitionExtension:                        {current-branch}/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/RepetitionExtension.java[RepetitionExtension]
-:TempDirectory:                              {current-branch}/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/TempDirectory.java[TempDirectory]
-:TestInfoParameterResolver:                  {current-branch}/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/TestInfoParameterResolver.java[TestInfoParameterResolver]
-:TestReporterParameterResolver:              {current-branch}/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/TestReporterParameterResolver.java[TestReporterParameterResolver]
-:TypeBasedParameterResolver:                 {current-branch}/junit-jupiter-api/src/main/java/org/junit/jupiter/api/extension/support/TypeBasedParameterResolver.java[TypeBasedParameterResolver]
-// Jupiter Examples
-:CustomAnnotationParameterResolver:          {current-branch}/jupiter-tests/src/test/java/org/junit/jupiter/engine/execution/injection/sample/CustomAnnotationParameterResolver.java[CustomAnnotationParameterResolver]
-:CustomTypeParameterResolver:                {current-branch}/jupiter-tests/src/test/java/org/junit/jupiter/engine/execution/injection/sample/CustomTypeParameterResolver.java[CustomTypeParameterResolver]
-:MapOfListsTypeBasedParameterResolver:       {current-branch}/jupiter-tests/src/test/java/org/junit/jupiter/engine/execution/injection/sample/MapOfListsTypeBasedParameterResolver.java[MapOfListsTypeBasedParameterResolver]
-// Jupiter Migration Support
-:EnableJUnit4MigrationSupport:               {javadoc-root}/org.junit.jupiter.migrationsupport/org/junit/jupiter/migrationsupport/EnableJUnit4MigrationSupport.html[@EnableJUnit4MigrationSupport]
-:EnableRuleMigrationSupport:                 {javadoc-root}/org.junit.jupiter.migrationsupport/org/junit/jupiter/migrationsupport/rules/EnableRuleMigrationSupport.html[@EnableRuleMigrationSupport]
-// JUnit Start
-:JUnit:                                      {javadoc-root}/org.junit.start/org/junit/start/JUnit.html[JUnit]
-// Vintage
-:junit-vintage-engine:                       {javadoc-root}/org.junit.vintage.engine/org/junit/vintage/engine/package-summary.html[junit-vintage-engine]
-// Examples Repository
-:junit-examples-repo:                        {junit-team}/junit-examples
-:junit-jupiter-starter-ant:                  {junit-examples-repo}/tree/{release-branch}/junit-jupiter-starter-ant[junit-jupiter-starter-ant]
-:junit-jupiter-starter-gradle-groovy:        {junit-examples-repo}/tree/{release-branch}/junit-jupiter-starter-gradle-groovy[junit-jupiter-starter-gradle-groovy]
-:junit-jupiter-starter-gradle-kotlin:        {junit-examples-repo}/tree/{release-branch}/junit-jupiter-starter-gradle-kotlin[junit-jupiter-starter-gradle-kotlin]
-:junit-jupiter-starter-gradle:               {junit-examples-repo}/tree/{release-branch}/junit-jupiter-starter-gradle[junit-jupiter-starter-gradle]
-:junit-jupiter-starter-maven:                {junit-examples-repo}/tree/{release-branch}/junit-jupiter-starter-maven[junit-jupiter-starter-maven]
-:RandomParametersExtension:                  {junit-examples-repo}/tree/{release-branch}/junit-jupiter-extensions/src/main/java/com/example/random/RandomParametersExtension.java[RandomParametersExtension]
-// Third-party Links
-:API:                                        https://apiguardian-team.github.io/apiguardian/docs/current/api/[@API]
-:API_Guardian:                               https://github.com/apiguardian-team/apiguardian[@API Guardian]
-:AssertJ:                                    https://assertj.github.io/doc/[AssertJ]
-:Checkstyle:                                 https://checkstyle.sourceforge.io[Checkstyle]
-:DiscussionsQA:                              https://github.com/junit-team/junit-framework/discussions/categories/q-a[Q&A category on GitHub Discussions]
-:Hamcrest:                                   https://hamcrest.org/JavaHamcrest/[Hamcrest]
-:Jimfs:                                      https://google.github.io/jimfs/[Jimfs]
-:Log4j:                                      https://logging.apache.org/log4j/2.x/[Log4j]
-:Log4j_JDK_Logging_Adapter:                  https://logging.apache.org/log4j/2.x/log4j-jul/index.html[Log4j JDK Logging Adapter]
-:Logback:                                    https://logback.qos.ch/[Logback]
-:LogManager:                                 https://docs.oracle.com/en/java/javase/17/docs/api/java.logging/java/util/logging/LogManager.html[LogManager]
-:Maven_Central:                              https://central.sonatype.com/[Maven Central]
-:MockitoExtension:                           https://github.com/mockito/mockito/blob/release/2.x/subprojects/junit-jupiter/src/main/java/org/mockito/junit/jupiter/MockitoExtension.java[MockitoExtension]
-:ServiceLoader:                              {jdk-javadoc-base-url}/java.base/java/util/ServiceLoader.html[ServiceLoader]
-:SpringExtension:                            https://github.com/spring-projects/spring-framework/tree/HEAD/spring-test/src/main/java/org/springframework/test/context/junit/jupiter/SpringExtension.java[SpringExtension]
-:StackOverflow:                              https://stackoverflow.com/questions/tagged/junit5[Stack Overflow]
-:Truth:                                      https://truth.dev/[Truth]
-:OpenTestReporting:                          https://github.com/ota4j-team/open-test-reporting[Open Test Reporting]
-:OpenTestReportingCliTool:                   https://github.com/ota4j-team/open-test-reporting#cli-tool-for-validation-and-format-conversion[Open Test Reporting CLI Tool]

From 06c3ee70ad35472090c5a0fd5109960bb2102e9b Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:06 +0100
Subject: [PATCH 12/57] Remove Asciidoctor User Guide main document

---
 .../src/docs/asciidoc/user-guide/index.adoc   | 46 -------------------
 1 file changed, 46 deletions(-)
 delete mode 100644 documentation/src/docs/asciidoc/user-guide/index.adoc

diff --git a/documentation/src/docs/asciidoc/user-guide/index.adoc b/documentation/src/docs/asciidoc/user-guide/index.adoc
deleted file mode 100644
index cd35b456e2ee..000000000000
--- a/documentation/src/docs/asciidoc/user-guide/index.adoc
+++ /dev/null
@@ -1,46 +0,0 @@
-[[user-guide]]
-= JUnit User Guide
-Stefan Bechtold; Sam Brannen; Johannes Link; Matthias Merdes; Marc Philipp; Juliette de Rancourt; Christian Stein
-:basedir: {includedir}/user-guide
-:pdf-fontsdir: GEM_FONTS_DIR;{includedir}/resources/fonts
-:pdf-theme: {includedir}/resources/themes/junit-pdf-theme.yml
-:imagesdir: images
-:imagesoutdir: {outdir}/user-guide/images
-//
-:docinfodir: {includedir}/docinfos
-:docinfo2:
-//
-ifdef::backend-pdf[:imagesdir: {imagesoutdir}]
-//
-// Blank lines are not permitted in the doc-header: https://asciidoctor.org/docs/user-manual/#doc-header
-//
-:sectnums:
-:toclevels: 4
-:last-update-label!:
-:figure-caption!:
-//
-
-include::{includedir}/link-attributes.adoc[]
-
-include::{basedir}/overview.adoc[]
-
-include::{basedir}/writing-tests.adoc[]
-
-include::{basedir}/migration-from-junit4.adoc[]
-
-include::{basedir}/running-tests.adoc[]
-
-include::{basedir}/extensions.adoc[]
-
-include::{basedir}/advanced-topics.adoc[]
-
-include::{basedir}/api-evolution.adoc[]
-
-include::{basedir}/contributors.adoc[]
-
-[[release-notes]]
-== Release Notes
-
-The release notes are available link:{releaseNotesUrl}[here].
-
-include::{basedir}/appendix.adoc[]

From 502839ecfee6c34edeed1fbdaff7d45f620aa6cc Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:07 +0100
Subject: [PATCH 13/57] Move overview.adoc to Antora module

---
 .../docs/asciidoc/user-guide => modules/ROOT/pages}/overview.adoc | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT/pages}/overview.adoc (100%)

diff --git a/documentation/src/docs/asciidoc/user-guide/overview.adoc b/documentation/modules/ROOT/pages/overview.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/overview.adoc
rename to documentation/modules/ROOT/pages/overview.adoc

From af16b074b0152867036fd15a6f981482661a30ac Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:07 +0100
Subject: [PATCH 14/57] Migrate overview.adoc to Antora syntax

---
 documentation/modules/ROOT/pages/overview.adoc | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/documentation/modules/ROOT/pages/overview.adoc b/documentation/modules/ROOT/pages/overview.adoc
index d1e19b48962e..a5f27923123c 100644
--- a/documentation/modules/ROOT/pages/overview.adoc
+++ b/documentation/modules/ROOT/pages/overview.adoc
@@ -1,5 +1,5 @@
-[[overview]]
-== Overview
+= Overview
+:page-aliases: user-guide/index.adoc
 
 The goal of this document is to provide comprehensive reference documentation for
 programmers writing tests, extension authors, and engine authors as well as build tool
@@ -12,7 +12,7 @@ endif::linkToPdf[]
 endif::backend-html5[]
 
 [[overview-what-is-junit]]
-=== What is JUnit?
+== What is JUnit?
 
 JUnit is composed of several different modules from three different sub-projects.
 
@@ -40,28 +40,28 @@ temporarily while migrating tests to JUnit Jupiter or another testing framework
 native JUnit Platform support.
 
 [[overview-java-versions]]
-=== Supported Java Versions
+== Supported Java Versions
 
 JUnit requires Java 17 (or higher) at runtime. However, you can still test code that
 has been compiled with previous versions of the JDK.
 
 [[overview-getting-help]]
-=== Getting Help
+== Getting Help
 
 Ask JUnit-related questions on {StackOverflow} or use the {DiscussionsQA}.
 
 [[overview-getting-started]]
-=== Getting Started
+== Getting Started
 
 [[overview-getting-started-junit-artifacts]]
-==== Downloading JUnit Artifacts
+=== Downloading JUnit Artifacts
 
 To find out what artifacts are available for download and inclusion in your project, refer
 to <<dependency-metadata>>. To set up dependency management for your build, refer to
 <<running-tests-build>> and the <<overview-getting-started-example-projects>>.
 
 [[overview-getting-started-features]]
-==== JUnit Features
+=== JUnit Features
 
 To find out what features are available in JUnit {version} and how to use them, read the
 corresponding sections of this User Guide, organized by topic.
@@ -75,7 +75,7 @@ corresponding sections of this User Guide, organized by topic.
   - <<testkit>>
 
 [[overview-getting-started-example-projects]]
-==== Example Projects
+=== Example Projects
 
 To see complete, working examples of projects that you can copy and experiment with, the
 {junit-examples-repo}[`junit-examples`] repository is a good place to start. The

From c5c89a1102d1ce6578bb59bd3c42b539f6e52991 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:07 +0100
Subject: [PATCH 15/57] Add overview.adoc to navigation

---
 documentation/modules/ROOT/nav.adoc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/documentation/modules/ROOT/nav.adoc b/documentation/modules/ROOT/nav.adoc
index e69de29bb2d1..1daff8e619ee 100644
--- a/documentation/modules/ROOT/nav.adoc
+++ b/documentation/modules/ROOT/nav.adoc
@@ -0,0 +1 @@
+* xref:overview.adoc[]

From fab5ec028089f474b21e4b0d041bb872d1d03b0a Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:08 +0100
Subject: [PATCH 16/57] Move writing-tests.adoc to Antora module

---
 .../pages/writing-tests/annotations.adoc}     |    0
 .../ROOT/pages/writing-tests/assertions.adoc  | 3940 +++++++++++++++++
 .../ROOT/pages/writing-tests/assumptions.adoc | 3940 +++++++++++++++++
 .../writing-tests/built-in-extensions.adoc    | 3940 +++++++++++++++++
 .../pages/writing-tests/class-templates.adoc  | 3940 +++++++++++++++++
 .../conditional-test-execution.adoc           | 3940 +++++++++++++++++
 .../ROOT/pages/writing-tests/definitions.adoc | 3940 +++++++++++++++++
 ...njection-for-constructors-and-methods.adoc | 3940 +++++++++++++++++
 .../pages/writing-tests/disabling-tests.adoc  | 3940 +++++++++++++++++
 .../pages/writing-tests/display-names.adoc    | 3940 +++++++++++++++++
 .../pages/writing-tests/dynamic-tests.adoc    | 3940 +++++++++++++++++
 .../writing-tests/exception-handling.adoc     | 3940 +++++++++++++++++
 .../ROOT/pages/writing-tests/intro.adoc       | 3940 +++++++++++++++++
 .../pages/writing-tests/nested-tests.adoc     | 3940 +++++++++++++++++
 .../writing-tests/parallel-execution.adoc     | 3940 +++++++++++++++++
 .../parameterized-classes-and-tests.adoc      | 3940 +++++++++++++++++
 .../pages/writing-tests/repeated-tests.adoc   | 3940 +++++++++++++++++
 .../writing-tests/tagging-and-filtering.adoc  | 3940 +++++++++++++++++
 .../test-classes-and-methods.adoc             | 3940 +++++++++++++++++
 .../writing-tests/test-execution-order.adoc   | 3940 +++++++++++++++++
 .../test-instance-lifecycle.adoc              | 3940 +++++++++++++++++
 .../test-interfaces-and-default-methods.adoc  | 3940 +++++++++++++++++
 .../pages/writing-tests/test-templates.adoc   | 3940 +++++++++++++++++
 .../ROOT/pages/writing-tests/timeouts.adoc    | 3940 +++++++++++++++++
 24 files changed, 90620 insertions(+)
 rename documentation/{src/docs/asciidoc/user-guide/writing-tests.adoc => modules/ROOT/pages/writing-tests/annotations.adoc} (100%)
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/assertions.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/assumptions.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/class-templates.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/definitions.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/display-names.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/intro.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/test-templates.adoc
 create mode 100644 documentation/modules/ROOT/pages/writing-tests/timeouts.adoc

diff --git a/documentation/src/docs/asciidoc/user-guide/writing-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/annotations.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/writing-tests.adoc
rename to documentation/modules/ROOT/pages/writing-tests/annotations.adoc
diff --git a/documentation/modules/ROOT/pages/writing-tests/assertions.adoc b/documentation/modules/ROOT/pages/writing-tests/assertions.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/assertions.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/assumptions.adoc b/documentation/modules/ROOT/pages/writing-tests/assumptions.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/assumptions.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc b/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc b/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc b/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/definitions.adoc b/documentation/modules/ROOT/pages/writing-tests/definitions.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/definitions.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc b/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/display-names.adoc b/documentation/modules/ROOT/pages/writing-tests/display-names.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/display-names.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc b/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/intro.adoc b/documentation/modules/ROOT/pages/writing-tests/intro.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/intro.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc b/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc b/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc b/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc b/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc b/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc b/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc b/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc b/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc
new file mode 100644
index 000000000000..18eddfd55b43
--- /dev/null
+++ b/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc
@@ -0,0 +1,3940 @@
+:testDir: ../../../../src/test/java
+:testResourcesDir: ../../../../src/test/resources
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[writing-tests]]
+== Writing Tests
+
+The following example provides a glimpse at the minimum requirements for writing a test in
+JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
+available features.
+
+[source,java,indent=0]
+.A first test case
+----
+include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+----
+
+[[writing-tests-annotations]]
+=== Annotations
+
+JUnit Jupiter supports the following annotations for configuring tests and extending the
+framework.
+
+Unless otherwise stated, all core annotations are located in the `{api-package}` package
+in the `junit-jupiter-api` module.
+
+`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
+this annotation does not declare any attributes, since test extensions in JUnit Jupiter
+operate based on their own dedicated annotations. Such methods are inherited unless they
+are overridden.
+
+`*@ParameterizedTest*`:: Denotes that a method is a
+<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+unless they are overridden.
+
+`*@RepeatedTest*`:: Denotes that a method is a test template for a
+<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+are overridden.
+
+`*@TestFactory*`:: Denotes that a method is a test factory for
+<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestTemplate*`:: Denotes that a method is a
+<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+times depending on the number of invocation contexts returned by the registered
+<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+overridden.
+
+`*@TestClassOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+test classes in the annotated test class. Such annotations are inherited.
+
+`*@TestMethodOrder*`:: Used to configure the
+<<writing-tests-test-execution-order-methods, test method execution order>> for the
+annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
+inherited.
+
+`*@TestInstance*`:: Used to configure the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+class. Such annotations are inherited.
+
+`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+test class or test method. Such annotations are not inherited.
+
+`*@DisplayNameGeneration*`:: Declares a custom
+<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+annotations are inherited.
+
+`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
+overridden.
+
+`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
+class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
+overridden.
+
+`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
+top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
+inherited unless they are overridden and must be `static` unless the "per-class"
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+
+`*@ParameterizedClass*`:: Denotes that the annotated class is a
+<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+inherited.
+
+`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _before_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
+executed once _after_ each invocation of a
+<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+unless they are overridden.
+
+`*@ClassTemplate*`:: Denotes that the annotated class is a
+<<writing-tests-class-templates, template for a test class>> designed to be executed
+multiple times depending on the number of invocation contexts returned by the registered
+<<extensions-class-templates, providers>>. Such annotations are inherited.
+
+`*@Nested*`:: Denotes that the annotated class is a non-static
+<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+
+`*@Tag*`:: Used to declare
+<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
+annotations are inherited at the class level but not at the method level.
+
+`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
+
+`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
+<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+execution. Such fields are inherited.
+
+`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
+its execution exceeds a given duration. Such annotations are inherited.
+
+`*@TempDir*`:: Used to supply a
+<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+injection or parameter injection in a test class constructor, lifecycle method, or test
+method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
+
+`*@ExtendWith*`:: Used to
+<<extensions-registration-declarative, register extensions declaratively>>. Such
+annotations are inherited.
+
+`*@RegisterExtension*`:: Used to
+<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+Such fields are inherited.
+
+WARNING: Some annotations may currently be _experimental_. Consult the table in
+<<api-evolution-experimental-apis>> for details.
+
+[[writing-tests-meta-annotations]]
+==== Meta-Annotations and Composed Annotations
+
+JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
+define your own _composed annotation_ that will automatically _inherit_ the semantics of
+its meta-annotations.
+
+For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
+<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
+`@Tag("fast")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/Fast.java[tags=user_guide]
+----
+
+The following `@Test` method demonstrates usage of the `@Fast` annotation.
+
+[source,java,indent=0]
+----
+@Fast
+@Test
+void myFastTest() {
+    // ...
+}
+----
+
+You can even take that one step further by introducing a custom `@FastTest` annotation
+that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/FastTest.java[tags=user_guide]
+----
+
+JUnit automatically recognizes the following as a `@Test` method that is tagged with
+"fast".
+
+[source,java,indent=0]
+----
+@FastTest
+void myFastTest() {
+    // ...
+}
+----
+
+[[writing-tests-definitions]]
+=== Definitions
+
+.Platform Concepts
+****
+Container::
+a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
+
+Test::
+a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
+****
+
+.Jupiter Concepts
+****
+Lifecycle Method::
+any method that is directly annotated or meta-annotated with
+`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+
+Test Class::
+any top-level class, `static` member class, or <<writing-tests-nested,
+`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+Test classes must not be `abstract` and must have a single constructor.
+Java `record` classes are supported as well.
+
+Test Method::
+any instance method that is directly annotated or meta-annotated with
+`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
+With the exception of `@Test`, these create a _container_ in the test tree that groups
+_tests_ or, potentially (for `@TestFactory`), other _containers_.
+****
+
+[[writing-tests-classes-and-methods]]
+=== Test Classes and Methods
+
+Test methods and lifecycle methods may be declared locally within the current test class,
+inherited from superclasses, or inherited from interfaces (see
+<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
+methods which are required to return a value).
+
+[NOTE]
+.Class and method visibility
+====
+Test classes, test methods, and lifecycle methods are not required to be `public`, but
+they must _not_ be `private`.
+
+It is generally recommended to omit the `public` modifier for test classes, test methods,
+and lifecycle methods unless there is a technical reason for doing so – for example, when
+a test class is extended by a test class in another package. Another technical reason for
+making classes and methods `public` is to simplify testing on the module path when using
+the Java Module System.
+====
+
+[NOTE]
+.Field and method inheritance
+====
+Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
+will always be applied in a subclass.
+
+Test methods and lifecycle methods are inherited unless they are overridden according to
+the visibility rules of the Java language. For example, a `@Test` method from a superclass
+will always be applied in a subclass unless the subclass explicitly overrides the method.
+Similarly, if a package-private `@Test` method is declared in a superclass that resides in
+a different package than the subclass, that `@Test` method will always be applied in the
+subclass since the subclass cannot override a package-private method from a superclass in
+a different package.
+
+See also: <<extensions-supported-utilities-search-semantics>>
+====
+
+The following test class demonstrates the use of `@Test` methods and all supported
+lifecycle methods. For further information on runtime semantics, see
+<<writing-tests-test-execution-order>> and
+<<extensions-execution-order-wrapping-behavior>>.
+
+[source,java,indent=0]
+.A standard Java test class
+----
+include::{testDir}/example/StandardTests.java[tags=user_guide]
+----
+
+It is also possible to use Java `record` classes as test classes as illustrated by the
+following example.
+
+[source,java,indent=0]
+.A test class written as a Java record
+----
+include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+----
+
+Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
+keyword for testing code using coroutines.
+
+[source,kotlin]
+.A test class written in Kotlin
+----
+include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+----
+
+NOTE: Using suspending functions as test or lifecycle methods requires
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
+https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
+and
+https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
+to be present on the classpath or module path.
+
+[[writing-tests-display-names]]
+=== Display Names
+
+Test classes and test methods can declare custom display names via `@DisplayName` -- with
+spaces, special characters, and even emojis -- that will be displayed in test reports and
+by test runners and IDEs.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+----
+
+[NOTE]
+====
+Control characters in text-based arguments in display names for parameterized tests are
+escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+for details.
+
+Any remaining ISO control characters in a display name will be replaced as follows.
+
+[cols="25%,15%,60%"]
+|===
+| Original | Replacement | Description
+
+| ```\r```
+| ```<CR>```
+| Textual representation of a carriage return
+
+| ```\n```
+| ```<LF>```
+| Textual representation of a line feed
+
+| Other control character
+| ```�```
+| Unicode replacement character (U+FFFD)
+|===
+====
+
+[[writing-tests-display-name-generator]]
+==== Display Name Generators
+
+JUnit Jupiter supports custom display name generators that can be configured via the
+`@DisplayNameGeneration` annotation.
+
+Generators can be created by implementing the `DisplayNameGenerator` API. The following
+table lists the default display name generators available in Jupiter.
+
+[cols="20,80"]
+|===
+| DisplayNameGenerator   | Behavior
+
+| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
+| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
+| `ReplaceUnderscores`  | Replaces underscores with spaces.
+| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
+|===
+
+NOTE: Values provided via `@DisplayName` annotations always take precedence over display
+names generated by a `DisplayNameGenerator`.
+
+======
+The following example demonstrates the use of the `ReplaceUnderscores` display name
+generator.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is not supported ✔
+├─ if it is zero ✔
+└─ A negative value for year is not supported by the leap year computation. ✔
+   ├─ For example, year -1 is not supported. ✔
+   └─ For example, year -4 is not supported. ✔
+```
+======
+
+======
+With the `IndicativeSentences` display name generator, you can customize the separator and
+the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year -> if it is one of the following years ✔
+   ├─ Year 2016 is a leap year. ✔
+   ├─ Year 2020 is a leap year. ✔
+   └─ Year 2048 is a leap year. ✔
+```
+======
+
+======
+With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
+`@SentenceFragment` annotation as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+----
+
+Running the above test class results in the following display names.
+
+```
+A year is a leap year ✔
+├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
+└─ A year is a leap year, if it is one of the following years ✔
+   ├─ 2016 ✔
+   ├─ 2020 ✔
+   └─ 2048 ✔
+```
+======
+
+
+[[writing-tests-display-name-generator-default]]
+==== Setting the Default Display Name Generator
+
+You can use the `junit.jupiter.displayname.generator.default`
+<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+class name of the `DisplayNameGenerator` you would like to use by default. Just like for
+display name generators configured via the `@DisplayNameGeneration` annotation, the
+supplied class has to implement the `DisplayNameGenerator` interface. The default display
+name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
+is present on an enclosing test class or test interface. Values provided via
+`@DisplayName` annotations always take precedence over display names generated by a
+`DisplayNameGenerator`.
+
+For example, to use the `ReplaceUnderscores` display name generator by default, you should
+set the configuration parameter to the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.displayname.generator.default = \
+    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`DisplayNameGenerator`.
+
+[[writing-tests-display-name-generator-precedence-rules]]
+In summary, the display name for a test class or method is determined according to the
+following precedence rules:
+
+1. value of the `@DisplayName` annotation, if present
+2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
+   annotation, if present
+3. by calling the default `DisplayNameGenerator` configured via the configuration
+   parameter, if present
+4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
+
+[[writing-tests-assertions]]
+=== Assertions
+
+JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
+that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
+are `static` methods in the `{Assertions}` class.
+
+Assertion methods optionally accept the assertion message as their third parameter, which
+can be either a `String` or a `Supplier<String>`.
+
+When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
+lazily. This can provide a performance benefit, especially if message construction is
+complex or time-consuming, as it is only evaluated when the assertion fails.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-assertions-preemptive-timeouts]]
+[WARNING]
+.Preemptive Timeouts with `assertTimeoutPreemptively()`
+====
+The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
+the provided `executable` or `supplier` in a different thread than that of the calling
+code. This behavior can lead to undesirable side effects if the code that is executed
+within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
+
+One common example of this is the transactional testing support in the Spring Framework.
+Specifically, Spring's testing support binds transaction state to the current thread (via
+a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
+`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
+that participate in transactions, any actions taken by those components will not be rolled
+back with the test-managed transaction. On the contrary, such actions will be committed to
+the persistent store (e.g., relational database) even though the test-managed transaction
+is rolled back.
+
+Similar side effects may be encountered with other frameworks that rely on
+`ThreadLocal` storage.
+====
+
+[[writing-tests-assertions-kotlin]]
+==== Kotlin Assertion Support
+
+JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
+used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
+functions in the `org.junit.jupiter.api` package.
+
+[source,kotlin,indent=0]
+----
+include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+----
+
+[[writing-tests-assertions-third-party]]
+==== Third-party Assertion Libraries
+
+Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
+testing scenarios, there are times when more power and additional functionality are
+desired or required. In such cases, the JUnit team recommends the use of third-party
+assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
+free to use the assertion library of their choice.
+
+For example, the following demonstrates how to use the `assertThat()` support from AssertJ
+in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
+you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
+from `org.assertj.core.api.Assertions` and then use them in tests like in the
+`assertWithAssertJ()` method below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+----
+
+[TIP]
+.Excluding Jupiter’s Assertions From a Project’s Classpath
+====
+If you would like to enforce that all your tests use a certain third-party assertion
+library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
+analysis tool that fails the build if Jupiter's `Assertions` class is used.
+
+[source,xml]
+----
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
+<module name="Checker">
+	<property name="severity" value="error" />
+	<module name="TreeWalker">
+    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
+			<property name="id" value="jupiterAssertions"/>
+			<property name="maximum" value="0"/>
+			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
+			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
+			<property name="ignoreComments" value="true"/>
+		</module>
+	</module>
+</module>
+----
+====
+
+[[writing-tests-assumptions]]
+=== Assumptions
+
+Assumptions are typically used whenever it does not make sense to continue execution of a
+given test — for example, if the test depends on something that does not exist in the
+current runtime environment.
+
+* When an assumption is valid, the assumption method does not throw an exception, and
+  execution of the test continues as usual.
+* When an assumption is invalid, the assumption method throws an exception of type
+  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
+  of marked as a failure.
+
+JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
+adds a few that lend themselves well to being used with Java lambda expressions and method
+references.
+
+All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+----
+
+NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
+assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
+to signal that a test should be aborted instead of marked as a failure.
+
+TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
+To do so, you can statically import the `assumeThat()` method from
+`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
+assumptions.
+
+[[writing-tests-exceptions]]
+=== Exception Handling
+
+JUnit Jupiter provides robust support for handling test exceptions. This includes the
+built-in mechanisms for managing test failures due to exceptions, the role of exceptions
+in implementing assertions and assumptions, and how to specifically assert non-throwing
+conditions in code.
+
+[[writing-tests-exceptions-uncaught]]
+==== Uncaught Exceptions
+
+In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
+extension and not caught within that test method, lifecycle method, or extension, the
+framework will mark the test or test class as failed.
+
+[TIP]
+====
+Failed assumptions deviate from this general rule.
+
+In contrast to failed assertions, failed assumptions do not result in a test failure;
+rather, a failed assumption results in a test being aborted.
+
+See <<writing-tests-assumptions>> for further details and examples.
+====
+
+In the following example, the `failsDueToUncaughtException()` method throws an
+`ArithmeticException`. Since the exception is not caught within the test method, JUnit
+Jupiter will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+----
+
+NOTE: It's important to note that specifying a `throws` clause in the test method has
+no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
+as an expectation or assertion about what exceptions the test method should throw. A test
+fails only if an exception is thrown unexpectedly or if an assertion fails.
+
+[[writing-tests-exceptions-failed-assertions]]
+==== Failed Assertions
+
+Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
+of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
+`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
+handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+further information about JUnit Jupiter's assertion support.
+
+NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
+failed assertion; however, they may also choose to throw different types of exceptions to
+signal failures. See also: <<writing-tests-assertions-third-party>>.
+
+TIP: JUnit Jupiter itself does not differentiate between failed assertions
+(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
+failure. However, Integrated Development Environments (IDEs) and other tools may
+distinguish between these two types of failures by checking whether the thrown exception
+is an instance of `AssertionError`.
+
+In the following example, the `failsDueToUncaughtAssertionError()` method throws an
+`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
+will mark the test as failed.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected]]
+==== Asserting Expected Exceptions
+
+JUnit Jupiter offers specialized assertions for testing that specific exceptions are
+thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
+assertions are critical tools for validating that your code responds correctly to error
+conditions by throwing the appropriate exceptions.
+
+[[writing-tests-exceptions-expected-assertThrows]]
+===== Using `assertThrows()`
+
+The `assertThrows()` method is used to verify that a particular type of exception is
+thrown during the execution of a provided executable block. It not only checks for the
+type of the thrown exception but also its subclasses, making it suitable for more
+generalized exception handling tests. The `assertThrows()` assertion method returns the
+thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-expected-assertThrowsExactly]]
+===== Using `assertThrowsExactly()`
+
+The `assertThrowsExactly()` method is used when you need to assert that the exception
+thrown is exactly of a specific type, not allowing for subclasses of the expected
+exception type. This is useful when precise exception handling behavior needs to be
+validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
+returns the thrown exception object to allow performing additional assertions on it.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+----
+
+[[writing-tests-exceptions-not-expected]]
+==== Asserting That no Exception is Expected
+
+Although any exception thrown from a test method will cause the test to fail, there are
+certain use cases where it can be beneficial to explicitly assert that an exception is
+_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
+assertion can be used when you want to verify that a particular piece of code does not
+throw any exceptions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+----
+
+NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
+has `assertThatNoException().isThrownBy(() -> ...)`. See also:
+<<writing-tests-assertions-third-party>>.
+
+[[writing-tests-disabling]]
+=== Disabling Tests
+
+Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
+annotation, via one of the annotations discussed in
+<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
+`ExecutionCondition`>>.
+
+When `@Disabled` is applied at the class level, all test methods within that class are
+automatically disabled as well.
+
+If a test method is disabled via `@Disabled`, that prevents execution of the test method
+and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
+and corresponding extension APIs. However, that does not prevent the test class from being
+instantiated, and it does not prevent the execution of class-level lifecycle callbacks
+such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
+
+Here's a `@Disabled` test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+----
+
+And here's a test class that contains a `@Disabled` test method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+----
+
+[TIP]
+====
+`@Disabled` may be declared without providing a _reason_; however, the JUnit team
+recommends that developers provide a short explanation for why a test class or test
+method has been disabled. Consequently, the above examples both show the use of a reason
+-- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
+teams even require the presence of issue tracking numbers in the _reason_ for automated
+traceability, etc.
+====
+
+[NOTE]
+====
+`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
+superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
+====
+
+
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
+
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
+
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
+
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
+
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
+
+[TIP]
+.Composed Annotations
+====
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
+====
+
+[NOTE]
+====
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
+====
+
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
+
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
+
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
+
+[[writing-tests-conditional-execution-os-demo]]
+[source,java,indent=0]
+.Conditional execution based on operating system
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+----
+
+[[writing-tests-conditional-execution-architectures-demo]]
+[source,java,indent=0]
+.Conditional execution based on architecture
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+----
+
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
+
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
+
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+----
+
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
+
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+----
+
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
+
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+----
+
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
+
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+----
+
+[TIP]
+====
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
+
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+----
+
+[TIP]
+====
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
+====
+
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
+
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
+
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+----
+
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
+
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
+
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
+
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
+
+[TIP]
+====
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
+
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
+
+[source,java,indent=0]
+----
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
+----
+====
+
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
+
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+----
+
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
+
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
+
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
+
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
+
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
+
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
+
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
+
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
+
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
+
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
+----
+
+Similarly, you can specify the fully qualified name of any custom class that implements
+`MethodOrderer`.
+
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
+
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
+
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
+
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
+
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
+
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
+
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
+
+[source,properties,indent=0]
+----
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
+----
+
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
+
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
+
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
+
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+----
+
+[[writing-tests-test-instance-lifecycle]]
+=== Test Instance Lifecycle
+
+In order to allow individual test methods to be executed in isolation and to avoid
+unexpected side effects due to mutable test instance state, JUnit creates a new instance
+of each test class before executing each _test method_ (see
+<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
+
+NOTE: Please note that the test class will still be instantiated if a given _test method_
+is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
+
+If you would prefer that JUnit Jupiter execute all test methods on the same test
+instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
+this mode, a new test instance will be created once per test class. Thus, if your test
+methods rely on state stored in instance variables, you may need to reset that state in
+`@BeforeEach` or `@AfterEach` methods.
+
+The "per-class" mode has some additional benefits over the default "per-method" mode.
+Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
+`@AfterAll` on non-static methods as well as on interface `default` methods.
+
+If you are authoring tests using the Kotlin programming language, you may also find it
+easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
+`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
+mode.
+
+[[writing-tests-test-instance-lifecycle-changing-default]]
+==== Changing the Default Test Instance Lifecycle
+
+If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
+will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
+however, it is possible to change the _default_ for the execution of an entire test plan.
+To change the default test instance lifecycle mode, set the
+`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
+an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
+as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
+you can start your JVM with the following system property.
+
+`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
+
+Note, however, that setting the default test instance lifecycle mode via the JUnit
+Platform configuration file is a more robust solution since the configuration file can be
+checked into a version control system along with your project and can therefore be used
+within IDEs and your build software.
+
+To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
+Platform configuration file, create a file named `junit-platform.properties` in the root
+of the class path (e.g., `src/test/resources`) with the following content.
+
+`junit.jupiter.testinstance.lifecycle.default = per_class`
+
+WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
+results and fragile builds if not applied consistently. For example, if the build
+configures "per-class" semantics as the default but tests in the IDE are executed using
+"per-method" semantics, that can make it difficult to debug errors that occur on the
+build server. It is therefore recommended to change the default in the JUnit Platform
+configuration file instead of via a JVM system property.
+
+[[writing-tests-nested]]
+=== Nested Tests
+
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
+
+[source,java,indent=0]
+.Nested test suite for testing a stack
+----
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+----
+
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
+
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
+
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
+
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
+
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
+
+[[writing-tests-nested-interoperability]]
+==== Interoperability
+
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
+
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+----
+
+Executing the above test class yields the following output:
+
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
+
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
+
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
+
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
+
+There are currently three built-in resolvers that are registered automatically.
+
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+----
+
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+----
+
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
+
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
+
+[source,java,indent=0]
+----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
+
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
+
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
+
+}
+----
+
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
+
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
+
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+----
+
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+----
+
+In your test class you can then implement these test interfaces to have them applied.
+
+[source,java]
+----
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+----
+
+Running the `TestInterfaceDemo` results in output similar to the following:
+
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
+
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+----
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+----
+
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
+
+[source,java]
+----
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+----
+
+NOTE: The above tests are merely meant as examples and therefore not complete.
+
+
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
+
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
+
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
+
+[source,java]
+----
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
+----
+
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
+
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
+
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
+
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
+
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
+
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
+
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
+
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
+
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
+
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
+
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
+
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
+
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
+
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
+
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
+
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
+
+[source,java]
+----
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+----
+
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
+
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
+
+
+[[writing-tests-parameterized-tests]]
+=== Parameterized Classes and Tests
+
+_Parameterized tests_ make it possible to run a test method multiple times with different
+arguments. They are declared just like regular `@Test` methods but use the
+`{ParameterizedTest}` annotation instead.
+
+_Parameterized classes_ make it possible to run _all_ tests in a test class, including
+<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+like regular test classes and may contain any supported test method type (including
+`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
+
+WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+Regardless of whether you are parameterizing a test method or a test class, you must
+declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+provide the arguments for each invocation and then
+<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+parameterized method or class, respectively.
+
+The following example demonstrates a parameterized test that uses the `@ValueSource`
+annotation to specify a `String` array as the source of arguments.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test method, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+palindromes(String) ✔
+├─ [1] candidate = "racecar" ✔
+├─ [2] candidate = "radar" ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+....
+
+The same `@ValueSource` annotation can be used to specify the source of arguments for a
+`@ParameterizedClass`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+----
+
+When executing the above parameterized test class, each invocation will be reported
+separately. For instance, the `ConsoleLauncher` will print output similar to the
+following.
+
+....
+PalindromeTests ✔
+├─ [1] candidate = "racecar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+├─ [2] candidate = "radar" ✔
+│  ├─ palindrome() ✔
+│  └─ reversePalindrome() ✔
+└─ [3] candidate = "able was I ere I saw elba" ✔
+   ├─ palindrome() ✔
+   └─ reversePalindrome() ✔
+....
+
+[[writing-tests-parameterized-tests-setup]]
+==== Required Setup
+
+In order to use parameterized classes or tests you need to add a dependency on the
+`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+
+[[writing-tests-parameterized-tests-consuming-arguments]]
+==== Consuming Arguments
+
+[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+===== Parameterized Tests
+
+Parameterized test methods _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+argument source index and method parameter index (see examples in
+<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+method may also choose to _aggregate_ arguments from the source into a single object
+passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
+instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
+must declare formal parameters according to the following rules.
+
+* Zero or more _indexed parameters_ must be declared first.
+* Zero or more _aggregators_ must be declared next.
+* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
+parameterized method at the same index in the method's formal parameter list. An
+_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
+with `{AggregateWith}`.
+
+[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+===== Parameterized Classes
+
+Parameterized classes _consume_ arguments directly from the configured source (see
+<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
+or one of its superclasses, field injection will be used. Otherwise, constructor injection
+will be used.
+
+[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+====== Constructor Injection
+
+WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
+<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+with the `PER_CLASS` mode instead.
+
+For constructor injection, the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+above. In the following example, two arguments are injected into the constructor of the
+test class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+----
+
+You may use _records_ to implement parameterized classes that avoid the boilerplate code
+of declaring a test class constructor.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+----
+
+[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+====== Field Injection
+
+For field injection, the following rules apply for fields annotated with `@Parameter`.
+
+* Zero or more _indexed parameters_ may be declared; each must have a unique index
+  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
+  only one indexed parameter. If there are at least two indexed parameter declarations,
+  there must be declarations for all indexes from 0 to the largest declared index.
+* Zero or more _aggregators_ may be declared; each without specifying an index in its
+  `@Parameter` annotation.
+* Zero or more other fields may be declared as usual as long as they're not annotated with
+  `@Parameter`.
+
+In this context, an _indexed parameter_ is an argument for a given index in the
+`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
+with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
+{ArgumentsAccessor} or any field annotated with {AggregateWith}.
+
+The following example demonstrates how to use field injection to consume multiple
+arguments in a parameterized class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+----
+
+If field injection is used, no constructor parameters will be resolved with arguments from
+the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+may resolve constructor parameters as usual, though.
+
+[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+====== Lifecycle Methods
+
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
+be used to consume arguments if their `injectArguments` attribute is set to `true` (the
+default). If so, their method signatures must follow the same rules apply as defined for
+<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+additionally use the same parameter types as the _indexed parameters_ of the parameterized
+test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
+`{AfterParameterizedClassInvocation}` for details and to the
+<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+example.
+
+[NOTE]
+.AutoCloseable arguments
+====
+Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
+`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
+test invocation.
+
+To prevent this from happening, set the `autoCloseArguments` attribute in
+`@ParameterizedTest` to `false`. Specifically, if an argument that implements
+`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
+method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
+`{ParameterizedTest}` annotation to ensure that the argument is not closed between
+invocations.
+====
+
+[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+===== Other Extensions
+
+Other extensions can access the parameters and resolved arguments of a parameterized test
+or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
+Please refer to the Javadoc of `{ParameterInfo}` for details.
+
+[[writing-tests-parameterized-tests-sources]]
+==== Sources of Arguments
+
+Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
+following subsections provides a brief overview and an example for each of them. Please
+refer to the Javadoc in the `{params-provider-package}` package for additional
+information.
+
+TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
+and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
+show how to use them with `{ParameterizedTest}` methods.
+
+[[writing-tests-parameterized-tests-sources-ValueSource]]
+===== @ValueSource
+
+`@ValueSource` is one of the simplest possible sources. It lets you specify a single
+array of literal values and can only be used for providing a single argument per
+parameterized test invocation.
+
+The following types of literal values are supported by `@ValueSource`.
+
+- `short`
+- `byte`
+- `int`
+- `long`
+- `float`
+- `double`
+- `char`
+- `boolean`
+- `java.lang.String`
+- `java.lang.Class`
+
+For example, the following `@ParameterizedTest` method will be invoked three times, with
+the values `1`, `2`, and `3` respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-null-and-empty]]
+===== Null and Empty Sources
+
+In order to check corner cases and verify proper behavior of our software when it is
+supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
+parameterized tests. The following annotations serve as sources of `null` and empty values
+for parameterized tests that accept a single argument.
+
+* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
+   or `@ParameterizedTest`.
+   - `@NullSource` cannot be used for a parameter that has a primitive type.
+* `{EmptySource}`: provides a single _empty_ argument to the annotated
+  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
+  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
+  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
+  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
+  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
+* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
+  `@NullSource` and `@EmptySource`.
+
+If you need to supply multiple varying types of _blank_ strings to a parameterized
+class or test, you can achieve that using
+<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
+
+You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
+range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
+achieve this for strings.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+----
+
+Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
+follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+----
+
+NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
+result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
+blank strings supplied via `@ValueSource`.
+
+[[writing-tests-parameterized-tests-sources-EnumSource]]
+===== @EnumSource
+
+`@EnumSource` provides a convenient way to use `Enum` constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+----
+
+The annotation's `value` attribute is optional. When omitted, the declared type of the
+first parameter is used. The test will fail if it does not reference an enum type.
+Thus, the `value` attribute is required in the above example because the method parameter
+is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
+an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
+explicit enum type from the annotation as follows.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+----
+
+The annotation provides an optional `names` attribute that lets you specify which
+constants shall be used, like in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+----
+
+In addition to `names`, you can use the `from` and `to` attributes to specify a range of
+constants. The range starts from the constant specified in the `from` attribute and
+includes all subsequent constants up to and including the one specified in the `to`
+attribute, based on the natural order of the enum constants.
+
+If `from` and `to` attributes are omitted, they default to the first and last constants
+in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
+all constants will be used. The following example demonstrates how to specify a range of
+constants.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+----
+
+The `@EnumSource` annotation also provides an optional `mode` attribute that enables
+fine-grained control over which constants are passed to the test method. For example, you
+can exclude names from the enum constant pool or specify regular expressions as in the
+following examples.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+----
+
+You can also combine `mode` with the `from`, `to` and `names` attributes to define a
+range of constants while excluding specific values from that range as shown below.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+----
+
+[[writing-tests-parameterized-tests-sources-MethodSource]]
+===== @MethodSource
+
+`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
+or external classes.
+
+Factory methods within the test class must be `static` unless the test class is annotated
+with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
+must always be `static`.
+
+Each factory method must generate a _stream_ of _arguments_, and each set of arguments
+within the stream will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
+translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
+concrete return type can take on many forms. In this context, a "stream" is anything that
+JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
+`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
+primitives, or any type that provides an `iterator(): Iterator` method (such as, for
+example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
+as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
+if the parameterized class or test method accepts a single argument.
+
+If the return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+If you only need a single parameter, you can return a `Stream` of instances of the
+parameter type as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+----
+
+For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
+mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
+name, JUnit Jupiter will search for a _factory_ method with the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+----
+
+Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
+supported as demonstrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+----
+
+If a parameterized class or test method declares multiple parameters, you need to return a
+collection, stream, or array of `Arguments` instances or object arrays as shown below (see
+the Javadoc for `{MethodSource}` for further details on supported return types). Note that
+`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
+addition, `Arguments.of(Object...)` may be used as an alternative to
+`arguments(Object...)`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+----
+
+An external, `static` _factory_ method can be referenced by providing its _fully qualified
+method name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+package example;
+
+include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+----
+
+Factory methods can declare parameters, which will be provided by registered
+implementations of the `ParameterResolver` extension API. In the following example, the
+factory method is referenced by its name since there is only one such method in the test
+class. If there are several local methods with the same name, parameters can also be
+provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
+`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
+can be referenced by its fully qualified method name, e.g.
+`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-FieldSource]]
+===== @FieldSource
+
+`{FieldSource}` allows you to refer to one or more fields of the test class or external
+classes.
+
+Fields within the test class must be `static` unless the test class is annotated with
+`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
+`static`.
+
+Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
+within the "stream" will be provided as the physical arguments for individual invocations
+of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
+
+In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
+however, the actual concrete field type can take on many forms. Generally speaking this
+translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
+`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
+objects or primitives, or any type that provides an `iterator(): Iterator` method (such
+as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
+"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
+`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
+a single argument.
+
+[WARNING]
+====
+In contrast to the supported return types for
+<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
+`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
+are _consumed_ the first time they are processed. However, if you wish to use one of
+these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
+====
+
+If the `Supplier` return type is `Stream` or one of the primitive streams,
+JUnit will properly close it by calling `BaseStream.close()`,
+making it safe to use a resource such as `Files.lines()`.
+
+Please note that a one-dimensional array of objects supplied as a set of "arguments" will
+be handled differently than other types of arguments. Specifically, all the elements of a
+one-dimensional array of objects will be passed as individual physical arguments to the
+`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
+further details.
+
+For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
+`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
+search in the test class for a field that has the same name as the current
+`@ParameterizedTest` method by convention. This is demonstrated in the following example.
+This parameterized test method will be invoked twice: with the values `"apple"` and
+`"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide a single explicit field name via
+`@FieldSource`. This parameterized test method will be invoked twice: with the values
+`"apple"` and `"banana"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+----
+
+The following example demonstrates how to provide multiple explicit field names via
+`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
+well as the `additionalFruits` field. Consequently, this parameterized test method will
+be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
+`"dewberry"`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+----
+
+It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
+`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
+iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
+how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
+method will be invoked twice: with the values `"apple"` and `"banana"` and with display
+names `"Apple"` and `"Banana"`, respectively.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+If a parameterized class or test method declares multiple parameters, the corresponding
+`@FieldSource` field must be able to provide a collection, stream supplier, or array of
+`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
+for further details on supported types).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+----
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+An external, `static` `@FieldSource` field can be referenced by providing its
+_fully qualified field name_ as demonstrated in the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+----
+
+[[writing-tests-parameterized-tests-sources-CsvSource]]
+===== @CsvSource
+
+`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
+`String` literals). Each string provided via the `value` attribute in `@CsvSource`
+represents a CSV record and results in one invocation of the parameterized class or
+test. The first record may optionally be used to supply CSV headers (see the Javadoc for
+the `useHeadersInDisplayName` attribute for details and an example).
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+----
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
+changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
+above and in the table below. An empty, quoted value (`''`) results in an empty `String`
+unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
+interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
+can be interpreted as a `null` reference (see the `NIL` example in the table below). An
+`ArgumentConversionException` is thrown if the target type of a `null` reference is a
+primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[cols="50,50"]
+|===
+| Example Input                                                                           | Resulting Argument List
+
+| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
+| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
+| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
+| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
+| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
+| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
+|===
+
+If the programming language you are using supports Java _text blocks_  or equivalent
+multi-line string literals, you can alternatively use the `textBlock` attribute of
+`@CsvSource`. Each record within a text block represents a CSV record and results in one
+invocation of the parameterized class or test. The first record may optionally be used to
+supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
+example below.
+
+Using a text block, the previous example can be implemented as follows.
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(useHeadersInDisplayName = true, textBlock = """
+	FRUIT,         RANK
+	apple,         1
+	banana,        2
+	'lemon, lime', 0xF1
+	strawberry,    700_000
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+The generated display names for the previous example include the CSV header names.
+
+----
+[1] FRUIT = "apple", RANK = "1"
+[2] FRUIT = "banana", RANK = "2"
+[3] FRUIT = "lemon, lime", RANK = "0xF1"
+[4] FRUIT = "strawberry", RANK = "700_000"
+----
+
+In contrast to CSV records supplied via the `value` attribute, a text block can contain
+comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be treated as a comment and ignored. Note that there is one exception
+to this rule: if the comment character appears within a quoted field, it loses
+its special meaning.
+
+The comment character must be the first character on the line without any leading
+whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
+be placed either at the end of the last line of input or on the following line,
+left aligned with the rest of the input (as can be seen in the example below which
+demonstrates formatting similar to a table).
+
+[source,java,indent=0]
+----
+@ParameterizedTest
+@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
+	#-----------------------------
+	#    FRUIT     |     RANK
+	#-----------------------------
+	     apple     |      1
+	#-----------------------------
+	     banana    |      2
+	#-----------------------------
+	  "lemon lime" |     0xF1
+	#-----------------------------
+	   strawberry  |    700_000
+	#-----------------------------
+	""")
+void testWithCsvSource(String fruit, int rank) {
+	// ...
+}
+----
+
+[NOTE]
+====
+Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
+feature automatically removes _incidental whitespace_ when the code is compiled.
+However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
+programming language other than Java and your text block contains comments or new lines
+within quoted strings, you will need to ensure that there is no leading whitespace within
+your text block.
+====
+
+[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+===== @CsvFileSource
+
+`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
+local file system. Each record from a CSV file results in one invocation of the
+parameterized class or test. The first record may optionally be used to supply CSV
+headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
+If you would like for the headers to be used in the display names, you can set the
+`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
+`numLinesToSkip` and `useHeadersInDisplayName`.
+
+The default delimiter is a comma (`,`), but you can use another character by setting the
+`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
+`String` delimiter instead of a single character. However, both delimiter attributes
+cannot be set simultaneously.
+
+.Comments in CSV files
+NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
+by default) will be interpreted as a comment and will be ignored.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+----
+
+[source,csv,indent=0]
+.two-column.csv
+----
+include::{testResourcesDir}/two-column.csv[]
+----
+
+The following listing shows the generated display names for the first two parameterized
+test methods above.
+
+----
+[1] country = "Sweden", reference = "1"
+[2] country = "Poland", reference = "2"
+[3] country = "United States of America", reference = "3"
+[4] country = "France", reference = "700_000"
+----
+
+The following listing shows the generated display names for the last parameterized test
+method above that uses CSV header names.
+
+----
+[1] COUNTRY = "Sweden", REFERENCE = "1"
+[2] COUNTRY = "Poland", REFERENCE = "2"
+[3] COUNTRY = "United States of America", REFERENCE = "3"
+[4] COUNTRY = "France", REFERENCE = "700_000"
+----
+
+In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
+quote (`+++"+++`) as the quote character by default, but this can be changed via the
+`quoteCharacter` attribute. See the `"United States of America"` value in the example
+above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
+`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
+`null` reference. By specifying one or more `nullValues`, a custom value can be
+interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
+target type of a `null` reference is a primitive type.
+
+NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
+of any custom values configured via the `nullValues` attribute.
+
+Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
+by default. This behavior can be changed by setting the
+`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
+
+[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+===== @ArgumentsSource
+
+`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
+that an implementation of `ArgumentsProvider` must be declared as either a top-level
+class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+----
+
+If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
+(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
+you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
+
+Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
+they need to be resolved by a registered `ParameterResolver` as demonstrated in the
+following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+----
+
+[[writing-tests-parameterized-repeatable-sources]]
+===== Multiple sources using repeatable annotations
+
+Repeatable annotations provide a convenient way to specify multiple sources from
+different providers.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+----
+
+Following the above parameterized test, a test case will run for each argument:
+
+----
+[1] foo
+[2] bar
+----
+
+The following annotations are repeatable:
+
+* `@ValueSource`
+* `@EnumSource`
+* `@MethodSource`
+* `@FieldSource`
+* `@CsvSource`
+* `@CsvFileSource`
+* `@ArgumentsSource`
+
+[[writing-tests-parameterized-tests-argument-count-validation]]
+==== Argument Count Validation
+
+By default, when an arguments source provides more arguments than the test method needs,
+those additional arguments are ignored and the test executes as usual.
+This can lead to bugs where arguments are never passed to the parameterized class or
+method.
+
+To prevent this, you can set argument count validation to 'strict'.
+Then, any additional arguments will cause an error instead.
+
+To change this behavior for all tests, set the
+`junit.jupiter.params.argumentCountValidation`
+<<running-tests-config-params, configuration parameter>> to `strict`.
+To change this behavior for a single parameterized class or test method,
+use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
+`@ParameterizedTest` annotation:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion]]
+==== Argument Conversion
+
+[[writing-tests-parameterized-tests-argument-conversion-widening]]
+===== Widening Conversion
+
+JUnit Jupiter supports
+https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
+Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
+For example, a parameterized class or test method annotated with
+`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
+`int` but also an argument of type `long`, `float`, or `double`.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+===== Implicit Conversion
+
+To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
+implicit type converters. The conversion process depends on the declared type of each
+method parameter.
+
+For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
+of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
+string will be automatically converted into the corresponding `TimeUnit` enum constant.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+----
+
+`String` instances are implicitly converted to the following target types.
+
+NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
+integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[cols="10,90"]
+|===
+| Target Type | Example
+
+| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
+| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
+| `char`/`Character`         | `"o"`                                    -> `'o'`
+| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
+| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
+| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
+| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
+| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
+| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
+| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
+| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
+| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
+| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
+| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
+| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
+| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
+| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
+| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
+| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
+| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
+| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
+| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
+| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
+| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
+| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
+| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
+| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
+| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
+| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
+| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
+| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
+| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
+| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
+| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
+|===
+
+[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+====== Fallback String-to-Object Conversion
+
+In addition to implicit conversion from strings to the target types listed in the above
+table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
+`String` to a given target type if the target type declares exactly one suitable _factory
+method_ or a _factory constructor_ as defined below.
+
+- __factory method__: a non-private, `static` method declared in the target type that
+  accepts either a single `String` argument or a single `CharSequence` argument and
+  returns an instance of the target type. The name of the method can be arbitrary and need
+  not follow any particular convention.
+- __factory constructor__: a non-private constructor in the target type that accepts a
+  either a single `String` argument or a single `CharSequence` argument. Note that the
+  target type must be declared as either a top-level class or as a `static` nested class.
+
+NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
+method_ and a _factory constructor_ are discovered, the factory method will be used
+instead of the constructor.
+
+For example, in the following `@ParameterizedTest` method, the `Book` argument will be
+created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
+as the title of the book.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+----
+
+[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+===== Explicit Conversion
+
+Instead of relying on implicit argument conversion, you may explicitly specify an
+`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
+like in the following example. Note that an implementation of `ArgumentConverter` must be
+declared as either a top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+----
+
+If the converter is only meant to convert one type to another, you can extend
+`TypedArgumentConverter` to avoid boilerplate type checks.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+----
+
+Explicit argument converters are meant to be implemented by test and extension authors.
+Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
+also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
+composed annotation `JavaTimeConversionPattern`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+----
+
+If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
+(like `JavaTimeArgumentConverter`), you have the possibility to extend the
+`{AnnotationBasedArgumentConverter}` class.
+
+[[writing-tests-parameterized-tests-argument-aggregation]]
+==== Argument Aggregation
+
+By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
+corresponds to a single method parameter. Consequently, argument sources which are
+expected to supply a large number of arguments can lead to large constructor or method
+signatures, respectively.
+
+In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
+this API, you can access the provided arguments through a single argument passed to your
+test method. In addition, type conversion is supported as discussed in
+<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+
+Besides, you can retrieve the current test invocation index with
+`ArgumentsAccessor.getInvocationIndex()`.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+----
+
+_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
+`ArgumentsAccessor`._
+
+[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+===== Custom Aggregators
+
+Apart from direct access to the arguments of a `@ParameterizedClass` or
+`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
+of custom, reusable _aggregators_.
+
+To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
+it via the `@AggregateWith` annotation on a compatible parameter of the
+`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
+provided as an argument for the corresponding parameter when the parameterized test is
+invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
+top-level class or as a `static` nested class.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+----
+
+If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
+multiple parameterized classes or methods across your codebase, you may wish to create a
+custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
+`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
+action with a custom `@CsvToPerson` annotation.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+----
+
+
+[[writing-tests-parameterized-tests-display-names]]
+==== Customizing Display Names
+
+By default, the display name of a parameterized class or test invocation contains the
+invocation index and a comma-separated list of the `String` representations of all
+arguments for that specific invocation. If parameter names are present in the bytecode,
+each argument will be preceded by its parameter name and an equals sign (unless the
+argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
+example, `firstName = "Jane"`.
+
+[TIP]
+====
+To ensure that parameter names are present in the bytecode, test code must be compiled
+with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
+for Kotlin.
+====
+
+However, you can customize invocation display names via the `name` attribute of the
+`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+Display name of container ✔
+├─ 1 ==> the rank of "apple" is "1" ✔
+├─ 2 ==> the rank of "banana" is "2" ✔
+└─ 3 ==> the rank of "lemon, lime" is "3" ✔
+....
+======
+
+[NOTE]
+====
+Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
+be represented as a doubled single quote (`''`) in order to be displayed.
+====
+
+The following placeholders are supported within custom display names.
+
+[cols="20,80"]
+|===
+| Placeholder                              | Description
+
+| `\{displayName}`                         | the display name of the method
+| `\{index}`                               | the current invocation index (1-based)
+| `\{arguments}`                           | the complete, comma-separated arguments list
+| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
+| `\{argumentSetName}`                     | the name of the argument set
+| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
+| `\{0}`, `\{1}`, ...                      | an individual argument
+|===
+
+NOTE: When including arguments in display names, their string representations are truncated
+if they exceed the configured maximum length. The limit is configurable via the
+`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
+to 512 characters.
+
+When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
+names for individual arguments or custom names for entire sets of arguments.
+
+Use the `{Named}` API to provide a custom name for an individual argument, and the custom
+name will be used if the argument is included in the invocation display name, like in the
+example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named arguments ✔
+├─ 1: An important file ✔
+└─ 2: Another file ✔
+....
+======
+
+[NOTE]
+====
+Note that `arguments(Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+
+Similarly, `named(String, Object)` is a static factory method defined in the
+`org.junit.jupiter.api.Named` interface.
+====
+
+Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
+the custom name will be used as the display name, like in the example below.
+
+======
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+----
+
+When executing the above method using the `ConsoleLauncher` you will see output similar to
+the following.
+
+....
+A parameterized test with named argument sets ✔
+├─ [1] Important files ✔
+└─ [2] Other files ✔
+....
+======
+
+[NOTE]
+====
+Note that `argumentSet(String, Object...)` is a static factory method defined in the
+`org.junit.jupiter.params.provider.Arguments` interface.
+====
+
+[[writing-tests-parameterized-tests-display-names-quoted-text]]
+===== Quoted Text-based Arguments
+
+As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
+quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
+is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
+is wrapped in single quotes (`'`).
+
+Special characters will be escaped in the quoted text. For example, carriage returns and
+line feeds will be escaped as `\\r` and `\\n`, respectively.
+
+[TIP]
+====
+This feature can be disabled by setting the `quoteTextArguments` attributes in
+`@ParameterizedClass` and `@ParameterizedTest` to `false`.
+====
+
+For example, given a string argument `"line 1\nline 2"`, the physical representation in
+the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
+Similarly, given a string argument `"\t"`, the physical representation in the display name
+will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
+character. The same applies for a character argument `'\t'`, whose physical representation
+in the display name would be `"'\\t'"` which is printed as `'\t'`.
+
+For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
+parameterized test method from the
+<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+display names are generated.
+
+----
+[1] text = null
+[2] text = ""
+[3] text = " "
+[4] text = "   "
+[5] text = "\t"
+[6] text = "\n"
+----
+
+If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
+from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+following display names are generated.
+
+----
+[1] fruit = "apple", rank = "1"
+[2] fruit = "banana", rank = "2"
+[3] fruit = "lemon, lime", rank = "0xF1"
+[4] fruit = "strawberry", rank = "700_000"
+----
+
+[NOTE]
+====
+The original source arguments are quoted when generating a display name, and this occurs
+before any implicit or explicit argument conversion is performed.
+
+For example, if a parameterized test accepts `3.14` as a `float` argument that was
+converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
+instead of `3.14`. You can see the effect of this with the `rank` values in the above
+example.
+====
+
+[[writing-tests-parameterized-tests-display-names-default-pattern]]
+===== Default Display Name Pattern
+
+If you'd like to set a default name pattern for all parameterized classes and tests in
+your project, you can declare the `junit.jupiter.params.displayname.default` configuration
+parameter in the `junit-platform.properties` file as demonstrated in the following example (see
+<<running-tests-config-params>> for other options).
+
+[source,properties,indent=0]
+----
+junit.jupiter.params.displayname.default = {index}
+----
+
+[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+===== Precedence Rules
+
+The display name for a parameterized class or test is determined according to the
+following precedence rules:
+
+1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
+2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
+3. `DEFAULT_DISPLAY_NAME` constant defined in
+   `org.junit.jupiter.params.ParameterizedInvocationConstants`
+
+[[writing-tests-parameterized-tests-lifecycle-interop]]
+==== Lifecycle and Interoperability
+
+[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+===== Parameterized Tests
+
+Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
+method. For example, `@BeforeEach` methods will be executed before each invocation.
+Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
+methods within the same test class.
+
+You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
+method parameters that are resolved by argument sources need to come first in the
+parameter list. Since a test class may contain regular tests as well as parameterized
+tests with different parameter lists, values from argument sources are not resolved for
+lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+----
+
+[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+===== Parameterized Classes
+
+Each invocation of a parameterized class has the same lifecycle as a regular test class.
+For example, `@BeforeAll` methods will be executed _once_ before all invocations and
+`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
+<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+IDE.
+
+You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
+However, if constructor injection is used, constructor parameters that are resolved by
+argument sources need to come first in the parameter list. Values from argument sources
+are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
+
+In addition to regular lifecycle methods, parameterized classes may declare
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
+methods that are called once before/after each invocation of the parameterized class.
+These methods must be `static` unless the parameterized class is configured to use
+`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+
+These lifecycle methods may optionally declare parameters that are resolved depending on
+the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
+parameters must be resolved by other registered {ParameterResolver} extensions. If the
+attribute is set to `true` (the default), the method may declare parameters that match the
+arguments of the parameterized class (see the Javadoc of
+`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
+details). This may, for example, be used to initialize the used arguments as demonstrated
+by the following example.
+
+[source,java,indent=0]
+.Using parameterized class lifecycle methods
+----
+include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+----
+<1> Initialization of the argument _before_ each invocation of the parameterized class
+<2> Usage of the previously initialized argument in a test method
+<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
+    class
+
+[[writing-tests-class-templates]]
+=== Class Templates
+
+A `{ClassTemplate}` is not a regular test class but rather a template for the contained
+test cases. As such, it is designed to be invoked multiple times depending on invocation
+contexts returned by the registered providers. Thus, it must be used in conjunction with a
+registered `{ClassTemplateInvocationContextProvider}` extension.
+Each invocation of a class template behaves like the execution of a regular test class
+with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-class-templates>> for usage examples.
+
+NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+specialization of class templates.
+
+[[writing-tests-test-templates]]
+=== Test Templates
+
+A `{TestTemplate}` method is not a regular test case but rather a template for a test
+case. As such, it is designed to be invoked multiple times depending on the number of
+invocation contexts returned by the registered providers. Thus, it must be used in
+conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
+invocation of a test template method behaves like the execution of a regular `@Test`
+method with full support for the same lifecycle callbacks and extensions. Please refer to
+<<extensions-test-templates>> for usage examples.
+
+NOTE: <<writing-tests-repeated-tests>> and
+<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+test templates.
+
+[[writing-tests-dynamic-tests]]
+=== Dynamic Tests
+
+The standard `@Test` annotation in JUnit Jupiter described in
+<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+describe methods that implement test cases. These test cases are static in the sense that
+they are fully specified at compile time, and their behavior cannot be changed by
+anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
+are intentionally rather limited in their expressiveness._
+
+In addition to these standard tests a completely new kind of test programming model has
+been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
+generated at runtime by a factory method that is annotated with `@TestFactory`.
+
+In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
+rather a factory for test cases. Thus, a dynamic test is the product of a factory.
+Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
+_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
+is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
+`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
+`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
+
+Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
+`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
+nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
+`DynamicTest` instances will be executed lazily, enabling dynamic and even
+non-deterministic generation of test cases.
+
+Any `Stream` returned by a `@TestFactory` will be properly closed by calling
+`stream.close()`, making it safe to use a resource such as `Files.lines()`.
+
+As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
+optionally declare parameters to be resolved by `ParameterResolvers`.
+
+A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
+and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
+implementations of dynamic tests can be provided as _lambda expressions_ or _method
+references_.
+
+.Dynamic Test Lifecycle
+WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
+standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
+dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
+corresponding extension callbacks are executed for the `@TestFactory` method but not for
+each _dynamic test_. In other words, if you access fields from the test instance within a
+lambda expression for a dynamic test, those fields will not be reset by callback methods
+or extensions between the execution of individual dynamic tests generated by the same
+`@TestFactory` method.
+
+[[writing-tests-dynamic-tests-examples]]
+==== Dynamic Test Examples
+
+The following `DynamicTestsDemo` class demonstrates several examples of test factories
+and dynamic tests.
+
+The first method returns an invalid return type and will cause a warning to be reported by
+JUnit during test discovery. Such methods are not executed.
+
+The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
+array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
+exhibit dynamic behavior but merely demonstrate the supported return types in principle.
+However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
+generate dynamic tests for a given set of strings or a range of input numbers.
+
+The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
+`Iterator` that generates random numbers, a display name generator, and a test executor
+and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
+behavior of `generateRandomNumberOfTests()` is of course in conflict with test
+repeatability and should thus be used with care, it serves to demonstrate the
+expressiveness and power of dynamic tests.
+
+The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
+however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
+an existing `Stream` via the `DynamicTest.stream()` factory method.
+
+For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
+`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
+a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-named-support]]
+==== Dynamic Tests and Named
+
+In some cases, it can be more natural to specify inputs together with a descriptive name
+using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
+shown in the first example below. The second example takes it one step further and allows
+to provide the code block that should be executed by implementing the `Executable`
+interface along with `Named` via the `NamedExecutable` base class.
+
+[source,java]
+----
+include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+----
+
+[[writing-tests-dynamic-tests-uri-test-source]]
+==== URI Test Sources for Dynamic Tests
+
+The JUnit Platform provides `TestSource`, a representation of the source of a test or
+container used to navigate to its location by IDEs and build tools.
+
+The `TestSource` for a dynamic test or dynamic container can be constructed from a
+`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
+Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
+respectively. The `URI` will be converted to one of the following `TestSource`
+implementations.
+
+`ClasspathResourceSource` ::
+  If the `URI` contains the `classpath` scheme -- for example,
+  `classpath:/test/foo.xml?line=20,column=2`.
+
+`DirectorySource` ::
+  If the `URI` represents a directory present in the file system.
+
+`FileSource` ::
+  If the `URI` represents a file present in the file system.
+
+`MethodSource` ::
+  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
+  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
+  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
+  supported formats for a FQMN.
+
+`ClassSource` ::
+  If the `URI` contains the `class` scheme and the fully qualified class name --
+  for example, `class:org.junit.Foo?line=42`.
+
+`UriSource` ::
+  If none of the above `TestSource` implementations are applicable.
+
+[[writing-tests-dynamic-tests-parallel-execution]]
+==== Parallel Execution
+
+Dynamic tests and containers support
+<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
+factory methods as illustrated by the following example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+----
+
+Executing the above test factory method results in the following test tree and execution
+modes:
+
+* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
+** Container A -- `CONCURRENT` (from `@Execution` annotation)
+*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
+*** properties -- `CONCURRENT` (from `@Execution` annotation)
+**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
+**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
+** ... (same for "Container B" and "Container C")
+
+[[writing-tests-declarative-timeouts]]
+=== Timeouts
+
+The `@Timeout` annotation allows one to declare that a test, test factory, test template,
+or lifecycle method should fail if its execution time exceeds a given duration. The time
+unit for the duration defaults to seconds but is configurable.
+
+The following example shows how `@Timeout` is applied to lifecycle and test methods.
+
+[source,java]
+----
+include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+----
+
+To apply the same timeout to all test methods within a test class and all of its `@Nested`
+classes, you can declare the `@Timeout` annotation at the class level. It will then be
+applied to all test, test factory, and test template methods within that class and its
+`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
+`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
+not applied to lifecycle methods.
+
+Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
+within the specified duration but does not verify the execution time of each individual
+`DynamicTest` generated by the factory. Please use
+`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
+
+If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
+`@ParameterizedTest` — each invocation will have the given timeout applied to it.
+
+[[writing-tests-declarative-timeouts-thread-mode]]
+==== Thread mode
+
+The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
+`SEPARATE_THREAD`, or `INFERRED`.
+
+When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
+thread of the test. If the timeout is exceeded, the main thread is interrupted from
+another thread. This is done to ensure interoperability with frameworks such as Spring
+that make use of mechanisms that are sensitive to the currently running thread — for
+example, `ThreadLocal` transaction management.
+
+On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
+assertion, the execution of the annotated method proceeds in a separate thread, this
+can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+
+When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
+`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
+provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
+fallback.
+
+[[writing-tests-declarative-timeouts-default-timeouts]]
+==== Default Timeouts
+
+The following <<running-tests-config-params, configuration parameters>> can be used to
+specify default timeouts for all methods of a certain category unless they or an enclosing
+test class is annotated with `@Timeout`:
+
+`junit.jupiter.execution.timeout.default`::
+    Default timeout for all testable and lifecycle methods
+`junit.jupiter.execution.timeout.testable.method.default`::
+    Default timeout for all testable methods
+`junit.jupiter.execution.timeout.test.method.default`::
+    Default timeout for `@Test` methods
+`junit.jupiter.execution.timeout.testtemplate.method.default`::
+    Default timeout for `@TestTemplate` methods
+`junit.jupiter.execution.timeout.testfactory.method.default`::
+    Default timeout for `@TestFactory` methods
+`junit.jupiter.execution.timeout.lifecycle.method.default`::
+    Default timeout for all lifecycle methods
+`junit.jupiter.execution.timeout.beforeall.method.default`::
+    Default timeout for `@BeforeAll` methods
+`junit.jupiter.execution.timeout.beforeeach.method.default`::
+    Default timeout for `@BeforeEach` methods
+`junit.jupiter.execution.timeout.aftereach.method.default`::
+    Default timeout for `@AfterEach` methods
+`junit.jupiter.execution.timeout.afterall.method.default`::
+    Default timeout for `@AfterAll` methods
+
+More specific configuration parameters override less specific ones. For example,
+`junit.jupiter.execution.timeout.test.method.default` overrides
+`junit.jupiter.execution.timeout.testable.method.default` which overrides
+`junit.jupiter.execution.timeout.default`.
+
+The values of such configuration parameters must be in the following, case-insensitive
+format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
+omitted. Specifying no unit is equivalent to using seconds.
+
+.Example timeout configuration parameter values
+[cols="20,80"]
+|===
+| Parameter value | Equivalent annotation
+
+| `42`            | `@Timeout(42)`
+| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
+| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
+| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
+| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
+| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
+| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
+| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
+|===
+
+
+[[writing-tests-declarative-timeouts-polling]]
+==== Using @Timeout for Polling Tests
+
+When dealing with asynchronous code, it is common to write tests that poll while waiting
+for something to happen before performing any assertions. In some cases you can rewrite
+the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
+that is not possible — for example, if the subject under test sends a message to a channel
+in an external message broker and assertions cannot be performed until the message has
+been successfully sent through the channel. Asynchronous tests like these require some
+form of timeout to ensure they don't hang the test suite by executing indefinitely, as
+would be the case if an asynchronous message never gets successfully delivered.
+
+By configuring a timeout for an asynchronous test that polls, you can ensure that the test
+does not execute indefinitely. The following example demonstrates how to achieve this with
+JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
+until" logic very easily.
+
+[source,java]
+----
+include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+----
+
+NOTE: If you need more control over polling intervals and greater flexibility with
+asynchronous tests, consider using a dedicated library such as
+link:https://github.com/awaitility/awaitility[Awaitility].
+
+
+[[writing-tests-declarative-timeouts-debugging]]
+==== Debugging Timeouts
+
+Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
+inspect the application state and output additional information that might be helpful for
+diagnosing the cause of a timeout.
+
+
+[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+===== Thread Dump on Timeout
+
+JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+extension point that dumps the stacks of all threads to `System.out` if enabled by setting
+the `junit.jupiter.execution.timeout.threaddump.enabled`
+<<running-tests-config-params, configuration parameter>> to `true`.
+
+
+[[writing-tests-declarative-timeouts-mode]]
+==== Disable @Timeout Globally
+
+When stepping through your code in a debug session, a fixed timeout limit may influence
+the result of the test, e.g. mark the test as failed although all assertions were met.
+
+JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
+to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
+and `disabled_on_debug`. The default mode is `enabled`.
+A VM runtime is considered to run in debug mode when one of its input parameters starts
+with `-agentlib:jdwp` or `-Xrunjdwp`.
+This heuristic is queried by the `disabled_on_debug` mode.
+
+
+[[writing-tests-parallel-execution]]
+=== Parallel Execution
+
+By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
+tests in parallel -- for example, to speed up execution -- is available as an opt-in
+feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
+configuration parameter to `true` -- for example, in `junit-platform.properties` (see
+<<running-tests-config-params>> for other options).
+
+Please note that enabling this property is only the first step required to execute tests
+in parallel. If enabled, test classes and methods will still be executed sequentially by
+default. Whether or not a node in the test tree is executed concurrently is controlled by
+its execution mode. The following two modes are available.
+
+`SAME_THREAD`::
+  Force execution in the same thread used by the parent. For example, when used on a test
+  method, the test method will be executed in the same thread as any `@BeforeAll` or
+  `@AfterAll` methods of the containing test class.
+
+`CONCURRENT`::
+  Execute concurrently unless a resource lock forces execution in the same thread.
+
+By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
+the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
+parameter. Alternatively, you can use the `{Execution}` annotation to change the
+execution mode for the annotated element and its subelements (if any) which allows you to
+activate parallel execution for individual test classes, one by one.
+
+[source,properties]
+.Configuration parameters to execute all tests in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+----
+
+The default execution mode is applied to all nodes of the test tree with a few notable
+exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
+`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
+thread-safe; in the latter, concurrent execution might conflict with the configured
+execution order. Thus, in both cases, test methods in such test classes are only executed
+concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
+method.
+
+You can use the `@Execution` annotation to explicitly configure the execution mode for a
+test class or method:
+
+[source,java]
+----
+include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+----
+
+This allows test classes or methods to opt in or out of concurrent execution regardless of
+the globally configured default.
+
+When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
+<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+initially be sorted accordingly and scheduled in that order. However, they are not
+guaranteed to be started in exactly that order since the threads they are executed on are
+not controlled directly by JUnit.
+
+All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
+be executed fully in parallel according to the provided
+<<writing-tests-parallel-execution-config, configuration>> while observing the
+declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
+mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+separately.
+
+In addition, you can configure the default execution mode for top-level classes by setting
+the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
+combining both configuration parameters, you can configure classes to run in parallel but
+their methods in the same thread:
+
+[source,properties]
+.Configuration parameters to execute top-level classes in parallel but methods in same thread
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = same_thread
+junit.jupiter.execution.parallel.mode.classes.default = concurrent
+----
+
+The opposite combination will run all methods within one class in parallel, but top-level
+classes will run sequentially:
+
+[source,properties]
+.Configuration parameters to execute top-level classes sequentially but their methods in parallel
+----
+junit.jupiter.execution.parallel.enabled = true
+junit.jupiter.execution.parallel.mode.default = concurrent
+junit.jupiter.execution.parallel.mode.classes.default = same_thread
+----
+
+The following diagram illustrates how the execution of two top-level test classes `A` and
+`B` with two test methods per class behaves for all four combinations of
+`junit.jupiter.execution.parallel.mode.default` and
+`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
+
+////
+Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
+
+---
+displayMode: compact
+---
+
+gantt
+    dateFormat X
+    axisFormat %s
+    tickInterval 1
+    title ↓ threads | time →
+
+    section (same_thread, same_thread)
+    A.test1() :ass1, 0, 1
+    A.test2() :ass2, after ass1, 2
+    B.test1() :bss1, after ass2, 3
+    B.test2() :bss2, after bss1, 4
+
+    section (same_thread, concurrent)
+    A.test1() :asc1, 0, 1
+    A.test2() :asc2, after asc1, 2
+    B.test1() :bsc1, 0, 1
+    B.test2() :bsc2, after bsc1, 2
+
+    section (concurrent, same_thread)
+    A.test1() :acs1, 0, 1
+    A.test2() :acs2, 0, 1
+    B.test1() :bcs1, after acs1, 2
+    B.test2() :bcs2, after acs2, 2
+
+    section (concurrent, concurrent)
+    A.test1() :acc1, 0, 1
+    A.test2() :acc2, 0, 1
+    B.test1() :bcc1, 0, 1
+    B.test2() :bcc2, 0, 1
+
+////
+image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
+
+If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
+not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
+used instead.
+
+[[writing-tests-parallel-execution-config]]
+==== Configuration
+
+[[writing-tests-parallel-execution-config-executor-service]]
+===== Executor Service
+
+If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
+concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
+is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
+configuration parameter to one of the following options:
+
+`fork_join_pool` (default)::
+Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
+tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
+`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
+number of concurrently executing tests to increase. To avoid this situation, please use
+`worker_thread_pool`.
+
+`worker_thread_pool` (experimental)::
+Use an executor service that is backed by a regular thread pool and does not create
+additional threads if test or production code uses `ForkJoinPool` or calls a blocking
+API in the JDK.
+
+WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
+to give it a try and provide feedback to the JUnit team so they can improve and eventually
+<<api-evolution, promote>> this feature.
+
+[[writing-tests-parallel-execution-config-strategies]]
+===== Strategies
+
+Properties such as the desired parallelism and the maximum pool size can be configured
+using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
+implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
+`custom` strategy.
+
+To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
+configuration parameter to one of the following options.
+
+`dynamic`::
+  Computes the desired parallelism based on the number of available processors/cores
+  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
+  configuration parameter (defaults to `1`).
+  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`fixed`::
+  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
+  configuration parameter as the desired parallelism.
+  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
+  configuration parameter can be used to limit the maximum number of threads.
+
+`custom`::
+  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
+  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
+  configuration parameter to determine the desired configuration.
+
+If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
+strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
+number of available processors/cores.
+
+.Parallelism alone does not imply maximum number of concurrent threads
+NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
+execute test will not exceed the configured parallelism. For example, when using one
+of the synchronization mechanisms described in the next section, the executor service
+implementation may spawn additional threads to ensure execution continues with sufficient
+parallelism. If you require such guarantees, it is possible to limit the maximum number of
+threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
+strategies.
+
+[[writing-tests-parallel-execution-config-properties]]
+===== Relevant properties
+
+The following table lists relevant properties for configuring parallel execution. See
+<<running-tests-config-params>> for details on how to set such properties.
+
+====== General
+
+`junit.jupiter.execution.parallel.enabled=true|false`::
+  Enable/disable parallel test execution (defaults to `false`).
+
+`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
+  Default execution mode of nodes in the test tree (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
+  Default execution mode of top-level classes (defaults to `same_thread`).
+
+`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
+  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
+  `fork_join_pool`).
+
+`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
+  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
+
+====== Dynamic strategy
+
+`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores to determine the
+  desired parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number (defaults to `1.0`).
+
+`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
+  Factor to be multiplied by the number of available processors/cores and the value of
+  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
+  parallelism for the ```dynamic``` configuration strategy.
+  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
+  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
+  number of available processors/cores)
+
+`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Fixed strategy
+
+`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
+  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
+  be a positive integer.
+
+`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
+  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
+  configuration strategy. Must be a positive integer greater than or equal to
+  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
+  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
+
+`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
+  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
+  configuration strategy (defaults to `true`). Only used if
+  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
+
+====== Custom strategy
+
+`junit.jupiter.execution.parallel.config.custom.class=classname`::
+  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
+  for the ```custom``` configuration strategy (no default value).
+
+[[writing-tests-parallel-execution-synchronization]]
+==== Synchronization
+
+In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
+Jupiter provides another annotation-based declarative synchronization mechanism. The
+`{ResourceLock}` annotation allows you to declare that a test class or method uses a
+specific shared resource that requires synchronized access to ensure reliable test
+execution. The shared resource is identified by a unique name which is a `String`. The
+name can be user-defined or one of the predefined constants in `{Resources}`:
+`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
+
+In addition to declaring these shared resources statically, the `{ResourceLock}`
+annotation has a `providers` attribute that allows registering implementations of the
+`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
+Note that resources declared statically with `{ResourceLock}` annotation are combined with
+resources added dynamically by `{ResourceLocksProvider}` implementations.
+
+If the tests in the following example were run in parallel _without_ the use of
+`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
+would fail due to the inherent race condition of writing and then reading the same JVM
+System Property.
+
+When access to shared resources is declared using the `{ResourceLock}` annotation, the
+JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
+parallel. This guarantee extends to lifecycle methods of a test class or method. For
+example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
+be acquired before any `@BeforeEach` methods are executed and released after all
+`@AfterEach` methods have been executed.
+
+[NOTE]
+.Running tests in isolation
+====
+If most of your test classes can be run in parallel without any synchronization but you
+have some test classes that need to run in isolation, you can mark the latter with the
+`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
+tests running at the same time.
+====
+
+In addition to the `String` that uniquely identifies the shared resource, you may specify
+an access mode. Two tests that require `READ` access to a shared resource may run in
+parallel with each other but not while any other test that requires `READ_WRITE` access
+to the same shared resource is running.
+
+[source,java]
+.Declaring shared resources "statically" with `{ResourceLock}` annotation
+----
+include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+----
+
+[source,java]
+.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
+----
+include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+----
+
+Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
+attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
+the `{ResourceLockTarget}` enum.
+
+Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
+has the same semantics as adding an annotation with the same `value` and `mode`
+to each test method and nested test class declared in this class.
+
+This may improve parallelization when a test class declares a `READ` lock,
+but only a few methods hold a `READ_WRITE` lock.
+
+Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
+didn't have `target = CHILDREN`. This is because the test class declares a `READ`
+shared resource, but one test method holds a `READ_WRITE` lock,
+which would force the `SAME_THREAD` execution mode for all the test methods.
+
+[source,java]
+.Declaring shared resources for child nodes with `target` attribute
+----
+include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+----
+
+
+[[writing-tests-built-in-extensions]]
+=== Built-in Extensions
+
+While the JUnit team encourages reusable extensions to be packaged and maintained in
+separate libraries, JUnit Jupiter includes a few user-facing extension implementations
+that are considered so generally useful that users shouldn't have to add another
+dependency.
+
+[[writing-tests-built-in-extensions-TempDirectory]]
+==== The @TempDir Extension
+
+The built-in `{TempDirectory}` extension is used to create and clean up a temporary
+directory for an individual test or all tests in a test class. It is registered by
+default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
+`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
+`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
+test method.
+
+For example, the following test declares a parameter annotated with `@TempDir` for a
+single test method, creates and writes to a file in the temporary directory, and checks
+its content.
+
+[source,java,indent=0]
+.A test method that requires a temporary directory
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+----
+
+You can inject multiple temporary directories by specifying multiple annotated parameters.
+
+[source,java,indent=0]
+.A test method that requires multiple temporary directories
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+----
+
+The following example stores a _shared_ temporary directory in a `static` field. This
+allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
+the test class. For better isolation, you should use an instance field or constructor
+injection so that each test method uses a separate directory.
+
+[source,java,indent=0]
+.A test class that shares a temporary directory across test methods
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+----
+
+The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
+`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
+directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
+temporary directory will only be deleted after the test if the test completed successfully.
+
+The default cleanup mode is `ALWAYS`. You can use the
+`junit.jupiter.tempdir.cleanup.mode.default`
+<<running-tests-config-params, configuration parameter>> to override this default.
+
+[source,java,indent=0]
+.A test class with a temporary directory that doesn't get cleaned up
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+----
+
+`@TempDir` supports the programmatic creation of temporary directories via the optional
+`factory` attribute. This is typically used to gain control over the temporary directory
+creation, like defining the parent directory or the file system that should be used.
+
+Factories can be created by implementing `TempDirFactory`. Implementations must provide a
+no-args constructor and should not make any assumptions regarding when and how many times
+they are instantiated, but they can assume that their `createTempDirectory(...)` and
+`close()` methods will both be called once per instance, in this order, and from the same
+thread.
+
+The default implementation available in Jupiter delegates directory creation to
+`java.nio.file.Files::createTempDirectory` which uses the default file system and the
+system's temporary directory as the parent directory. It passes `junit-` as the prefix
+string of the generated directory name to help identify it as a created by JUnit.
+
+The following example defines a factory that uses the test name as the directory name
+prefix instead of the `junit` constant value.
+
+[source,java,indent=0]
+.A test class with a temporary directory having the test name as the directory name prefix
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+----
+
+It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
+temporary directory. The following example demonstrates how to achieve that.
+
+[source,java,indent=0]
+.A test class with a temporary directory created with the Jimfs in-memory file system
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+----
+
+`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
+annotation that can be used as a drop-in replacement for
+`@TempDir(factory = JimfsTempDirFactory.class)`.
+
+[source,java,indent=0]
+.A custom annotation meta-annotated with `@TempDir`
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+----
+
+The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
+
+[source,java,indent=0]
+.A test class using the custom annotation
+----
+include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+----
+
+Meta-annotations or additional annotations on the field or parameter the `TempDir`
+annotation is declared on might expose additional attributes to configure the factory.
+Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
+parameter of the `createTempDirectory(...)` method.
+
+You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`TempDirFactory` you would like to use by default. Just like for factories configured via
+the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
+the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
+annotations unless the `factory` attribute of the annotation specifies a different factory.
+
+In summary, the factory for a temporary directory is determined according to the following
+precedence rules:
+
+1. The `factory` attribute of the `@TempDir` annotation, if present
+2. The default `TempDirFactory` configured via the configuration
+parameter, if present
+3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
+
+[[writing-tests-built-in-extensions-AutoClose]]
+==== The @AutoClose Extension
+
+The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
+It is registered by default. To use it, annotate a field in a test class with
+`{AutoClose}`.
+
+`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
+field is `null` when it is evaluated the field will be ignored, but a warning message will
+be logged to inform you.
+
+By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
+method that will be invoked to close the resource. However, developers can customize the
+name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
+instructs JUnit to look for a `shutdown()` method to close the resource.
+
+`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
+subclasses will be closed before `@AutoClose` fields in superclasses.
+
+When multiple `@AutoClose` fields exist within a given test class, the order in which the
+resources are closed depends on an algorithm that is deterministic but intentionally
+nonobvious. This ensures that subsequent runs of a test suite close resources in the same
+order, thereby allowing for repeatable builds.
+
+The `AutoCloseExtension` implements the `AfterAllCallback` and
+`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
+field will be closed after all tests in the current test class have completed, effectively
+after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
+field will be closed before the current test class instance is destroyed. Specifically, if
+the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
+non-static `@AutoClose` field will be closed after the execution of each test method, test
+factory method, or test template method. However, if the test class is configured with
+`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
+be closed until the current test class instance is no longer needed, which means after
+`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
+
+The following example demonstrates how to annotate an instance field with `@AutoClose` so
+that the resource is automatically closed after test execution. In this example, we assume
+that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
+
+[source,java,indent=0]
+.A test class using `@AutoClose` to close a resource
+----
+include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+----
+<1> Annotate an instance field with `@AutoClose`.
+<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
+    will be invoked after each `@Test` method.
+
+[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+==== The @DefaultLocale and @DefaultTimeZone Extensions
+
+The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
+returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
+often used implicitly when no specific locale or time zone is chosen. Both annotations
+work on the test class level and on the test method level, and are inherited from
+higher-level containers. After the annotated element has been executed, the initial
+default value is restored.
+
+[[writing-tests-built-in-extensions-DefaultLocale]]
+===== @DefaultLocale
+
+The default `Locale` can be specified using an
+{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+----
+
+Alternatively, the default `Locale` can be created using the following attributes from
+which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
+can create an instance:
+
+* `language` or
+* `language` and `country` or
+* `language`, `country`, and `variant`
+
+NOTE: The variant needs to be a string which follows the
+https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+----
+
+Mixing language tag configuration (via the annotation's `value` attributed) and
+attributed-based configuration will cause an exception to be thrown. Furthermore, a
+`variant` can only be specified if `country` is also specified. Otherwise, an exception
+will be thrown.
+
+Any method-level `@DefaultLocale` configurations will override class-level configurations.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+----
+
+NOTE: A class-level configuration means that the specified locale is set before and reset
+after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+[[writing-tests-built-in-extensions-DefaultTimeZone]]
+===== @DefaultTimeZone
+
+The default `TimeZone` is specified according to the
+{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
+method.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+----
+
+Any method level `@DefaultTimeZone` configurations will override class level configurations:
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+----
+
+NOTE: A class-level configuration means that the specified time zone is set before and
+reset after each individual test in the annotated class.
+
+If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+----
+
+NOTE: The provider implementation must have a no-args (or the default) constructor.
+
+===== Thread Safety
+
+Since the default locale and time zone are global state, reading and writing them during
+<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
+prepared for that and tests annotated with them will never execute in parallel (thanks to
+`{ResourceLock}`) to guarantee correct test results.
+
+However, this does not cover all possible cases. Tested code that reads or writes default
+locale and time zone _independently_ of the extensions can still run in parallel to them
+and may thus behave erratically when, for example, it unexpectedly reads a locale set by
+the extension in another thread. Tests that cover code that reads or writes the default
+locale or time zone need to be annotated with the respective annotation:
+
+* `{ReadsDefaultLocale}`
+* `{ReadsDefaultTimeZone}`
+* `{WritesDefaultLocale}`
+* `{WritesDefaultTimeZone}`
+
+Tests annotated in this way will never execute in parallel with tests annotated with
+`@DefaultLocale` or `@DefaultTimeZone`.

From 5c4e125c08320f9b0552e5d8e19b4f9ab8546ef6 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:09 +0100
Subject: [PATCH 17/57] Migrate writing-tests.adoc sections to Antora

---
 .../ROOT/pages/writing-tests/annotations.adoc | 3766 ---------------
 .../ROOT/pages/writing-tests/assertions.adoc  | 3841 ----------------
 .../ROOT/pages/writing-tests/assumptions.adoc | 3907 ----------------
 .../writing-tests/built-in-extensions.adoc    | 3644 ---------------
 .../pages/writing-tests/class-templates.adoc  | 3926 ----------------
 .../conditional-test-execution.adoc           | 3998 +---------------
 .../ROOT/pages/writing-tests/definitions.adoc | 3909 ----------------
 ...njection-for-constructors-and-methods.adoc | 3980 +---------------
 .../pages/writing-tests/disabling-tests.adoc  | 3892 ----------------
 .../pages/writing-tests/display-names.adoc    | 3779 ---------------
 .../pages/writing-tests/dynamic-tests.adoc    | 3783 ---------------
 .../writing-tests/exception-handling.adoc     | 3819 ----------------
 .../ROOT/pages/writing-tests/intro.adoc       | 3923 ----------------
 .../pages/writing-tests/nested-tests.adoc     | 3973 +---------------
 .../writing-tests/parallel-execution.adoc     | 3586 ---------------
 .../parameterized-classes-and-tests.adoc      | 2624 -----------
 .../pages/writing-tests/repeated-tests.adoc   | 4059 +----------------
 .../writing-tests/tagging-and-filtering.adoc  | 3942 +---------------
 .../test-classes-and-methods.adoc             | 3865 ----------------
 .../writing-tests/test-execution-order.adoc   | 3999 +---------------
 .../test-instance-lifecycle.adoc              | 3876 ----------------
 .../test-interfaces-and-default-methods.adoc  | 3936 +---------------
 .../pages/writing-tests/test-templates.adoc   | 3925 ----------------
 .../ROOT/pages/writing-tests/timeouts.adoc    | 3778 ---------------
 24 files changed, 555 insertions(+), 91175 deletions(-)

diff --git a/documentation/modules/ROOT/pages/writing-tests/annotations.adoc b/documentation/modules/ROOT/pages/writing-tests/annotations.adoc
index 18eddfd55b43..7760a11d372a 100644
--- a/documentation/modules/ROOT/pages/writing-tests/annotations.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/annotations.adoc
@@ -1,20 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
 [[writing-tests-annotations]]
 === Annotations
 
@@ -189,3752 +172,3 @@ void myFastTest() {
 }
 ----
 
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/assertions.adoc b/documentation/modules/ROOT/pages/writing-tests/assertions.adoc
index 18eddfd55b43..71345d429bd0 100644
--- a/documentation/modules/ROOT/pages/writing-tests/assertions.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/assertions.adoc
@@ -1,461 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
 [[writing-tests-assertions]]
 === Assertions
 
@@ -555,3386 +97,3 @@ analysis tool that fails the build if Jupiter's `Assertions` class is used.
 ----
 ====
 
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/assumptions.adoc b/documentation/modules/ROOT/pages/writing-tests/assumptions.adoc
index 18eddfd55b43..ccf7be42d671 100644
--- a/documentation/modules/ROOT/pages/writing-tests/assumptions.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/assumptions.adoc
@@ -1,560 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
 [[writing-tests-assumptions]]
 === Assumptions
 
@@ -588,3353 +31,3 @@ To do so, you can statically import the `assumeThat()` method from
 `org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
 assumptions.
 
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc b/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc
index 18eddfd55b43..7dfa2ee9e328 100644
--- a/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc
@@ -1,3647 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
 [[writing-tests-built-in-extensions]]
 === Built-in Extensions
 
diff --git a/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc b/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc
index 18eddfd55b43..e6abf92bf6ba 100644
--- a/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc
@@ -1,2945 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
 [[writing-tests-class-templates]]
 === Class Templates
 
@@ -2954,987 +12,3 @@ with full support for the same lifecycle callbacks and extensions. Please refer
 NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
 specialization of class templates.
 
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc b/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc
index 18eddfd55b43..068f8db579ae 100644
--- a/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc
@@ -1,3940 +1,224 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
+[[writing-tests-conditional-execution]]
+=== Conditional Test Execution
 
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
+The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+developers to either _enable_ or _disable_ a test class or test method based on certain
+conditions _programmatically_. The simplest example of such a condition is the built-in
+`{DisabledCondition}` which supports the `{Disabled}` annotation (see
+<<writing-tests-disabling>>).
 
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
+In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
+conditions in the `org.junit.jupiter.api.condition` package that allow developers to
+enable or disable test classes and test methods _declaratively_. If you wish to provide
+details about why they might be disabled, every annotation associated with these built-in
+conditions has a `disabledReason` attribute available for that purpose.
 
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
+When multiple `ExecutionCondition` extensions are registered, a test class or test method
+is disabled as soon as one of the conditions returns _disabled_. If a test class is
+disabled, all test methods within that class are automatically disabled as well. If a test
+method is disabled, that prevents execution of the test method and method-level lifecycle
+callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
+APIs. However, that does not prevent the test class from being instantiated, and it does
+not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
+`@AfterAll` methods, and corresponding extension APIs.
 
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
+See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+details.
 
-[NOTE]
-.Class and method visibility
+[TIP]
+.Composed Annotations
 ====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
+Note that any of the _conditional_ annotations listed in the following sections may also
+be used as a meta-annotation in order to create a custom _composed annotation_. For
+example, the `@TestOnMac` annotation in the
+<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
 ====
 
 [NOTE]
-.Field and method inheritance
 ====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
+_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
+to apply the same semantics to subclasses, each conditional annotation must be redeclared
+on each subclass.
 ====
 
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
+[WARNING]
+====
+Unless otherwise stated, each of the _conditional_ annotations listed in the following
+sections can only be declared once on a given test interface, test class, or test method.
+If a conditional annotation is directly present, indirectly present, or meta-present
+multiple times on a given element, only the first such annotation discovered by JUnit will
+be used; any additional declarations will be silently ignored. Note, however, that each
+conditional annotation may be used in conjunction with other conditional annotations in
+the `org.junit.jupiter.api.condition` package.
+====
 
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
+[[writing-tests-conditional-execution-os]]
+==== Operating System and Architecture Conditions
 
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
+A container or test may be enabled or disabled on a particular operating system,
+architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
+annotations.
 
+[[writing-tests-conditional-execution-os-demo]]
 [source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
+.Conditional execution based on operating system
 ----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
 ----
 
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
+[[writing-tests-conditional-execution-architectures-demo]]
 [source,java,indent=0]
+.Conditional execution based on architecture
 ----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
 ----
 
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
+[[writing-tests-conditional-execution-jre]]
+==== Java Runtime Environment Conditions
 
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
+A container or test may be enabled or disabled on particular versions of the Java Runtime
+Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
+particular range of versions of the JRE via the `{EnabledForJreRange}` and
+`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
+lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
 
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
+The following listing demonstrates the use of these annotations with predefined {JRE} enum
+constants.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
 ----
 
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
+Since the enum constants defined in {JRE} are static for any given JUnit release, you
+might find that you need to configure a Java version that is not supported by the `JRE`
+enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
+as the highest supported Java version. However, you may wish to run your tests against
+later versions of Java. To support such use cases, you can specify arbitrary Java versions
+via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
+`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
+`@DisabledForJreRange`.
 
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
+The following listing demonstrates the use of these annotations with arbitrary Java
+versions.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
 ----
 
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
+[[writing-tests-conditional-execution-native]]
+==== Native Image Conditions
 
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
+A container or test may be enabled or disabled within a
+https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
+`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
+typically used when running tests within a native image using the Gradle and Maven
+plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
+Build Tools] project.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
 ----
 
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
+[[writing-tests-conditional-execution-system-properties]]
+==== System Property Conditions
 
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
+A container or test may be enabled or disabled based on the value of the `named` JVM
+system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
+annotations. The value supplied via the `matches` attribute will be interpreted as a
+regular expression.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
 ----
 
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
+[TIP]
 ====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
+`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
+Consequently, these annotations may be declared multiple times on a test interface, test
+class, or test method. Specifically, these annotations will be found if they are directly
+present, indirectly present, or meta-present on a given element.
 ====
 
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
+[[writing-tests-conditional-execution-environment-variables]]
+==== Environment Variable Conditions
 
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
+A container or test may be enabled or disabled based on the value of the `named`
+environment variable from the underlying operating system via the
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
+value supplied via the `matches` attribute will be interpreted as a regular expression.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
 ----
 
 [TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
 ====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
+`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
+annotations_. Consequently, these annotations may be declared multiple times on a test
+interface, test class, or test method. Specifically, these annotations will be found if
+they are directly present, indirectly present, or meta-present on a given element.
 ====
 
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
+[[writing-tests-conditional-execution-custom]]
+==== Custom Conditions
 
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
+As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+container or test may be enabled or disabled based on a _condition method_ configured via
+the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
+return type and may accept either no arguments or a single `ExtensionContext` argument.
 
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+The following test class demonstrates how to configure a local method named
+`customCondition` via `@EnabledIf` and `@DisabledIf`.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
 ----
 
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
+Alternatively, the condition method can be located outside the test class. In this case,
+it must be referenced by its _fully qualified name_ as demonstrated in the following
+example.
 
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
+[source,java,indent=0]
+----
+package example;
 
-[[writing-tests-exceptions]]
-=== Exception Handling
+include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+----
 
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
+[NOTE]
+====
+There are several cases where a condition method would need to be `static`:
 
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
+- when `@EnabledIf` or `@DisabledIf` is used at class level
+- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
+  `@TestTemplate` method
+- when the condition method is located in an external class
 
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
+In any other case, you can use either static methods or instance methods as condition
+methods.
+====
 
 [TIP]
 ====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
+It is often the case that you can use an existing static method in a utility class as a
+custom condition.
 
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
+For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
+method that can be used to determine if the current environment does not support a
+graphical display. Thus, if you have a test that depends on graphical support you can
+disable it when such support is unavailable as follows.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
+@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
+	disabledReason = "headless environment")
 ----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
 ====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
 
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/definitions.adoc b/documentation/modules/ROOT/pages/writing-tests/definitions.adoc
index 18eddfd55b43..b572ec559b06 100644
--- a/documentation/modules/ROOT/pages/writing-tests/definitions.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/definitions.adoc
@@ -1,194 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
 [[writing-tests-definitions]]
 === Definitions
 
@@ -220,3721 +29,3 @@ With the exception of `@Test`, these create a _container_ in the test tree that
 _tests_ or, potentially (for `@TestFactory`), other _containers_.
 ****
 
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc b/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc
index 18eddfd55b43..963d1b2f6df0 100644
--- a/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc
@@ -1,3940 +1,92 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
+[[writing-tests-dependency-injection]]
+=== Dependency Injection for Constructors and Methods
 
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+In all prior JUnit versions, test constructors or methods were not allowed to have
+parameters (at least not with the standard `Runner` implementations). As one of the major
+changes in JUnit Jupiter, both test constructors and methods are now permitted to have
+parameters. This allows for greater flexibility and enables _Dependency Injection_ for
+constructors and methods.
 
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
+`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
+resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
+_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+must be resolved at runtime by a registered `ParameterResolver`.
 
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
+There are currently three built-in resolvers that are registered automatically.
 
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
+* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
+  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
+  corresponding to the current container or test as the value for the parameter. The
+  `TestInfo` can then be used to retrieve information about the current container or test
+  such as the display name, the test class, the test method, and associated tags. The
+  display name is either a technical name, such as the name of the test class or test
+  method, or a custom name configured via `@DisplayName`.
++
+`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
+following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
+class constructor, `@BeforeEach` method, and `@Test` method.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
 ----
 
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
+* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
+  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
+  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
+  information about the current repetition, the total number of repetitions, the number of
+  repetitions that have failed, and the failure threshold for the corresponding
+  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
+  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
 
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
+  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
+  `TestReporter`. The `TestReporter` can be used to publish additional data about the
+  current test run or attach files to it. The data can be consumed in a
+  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
+  method, respectively. This allows them to be viewed in IDEs or included in reports.
++
+In JUnit Jupiter you should use `TestReporter` where you used to print information to
+`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
+them in the user interface for test results.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
 ----
 
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
+NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
+<<extensions,extensions>> via `@ExtendWith`.
 
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
+Check out the `{RandomParametersExtension}` for an example of a custom
+`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
+simplicity and expressiveness of both the extension model and the parameter resolution
+process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
+methods.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
+@ExtendWith(RandomParametersExtension.class)
+class MyRandomParametersTest {
 
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
+	@Test
+	void injectsInteger(@Random int i, @Random int j) {
+		assertNotEquals(i, j);
+	}
 
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+	@Test
+	void injectsDouble(@Random double d) {
+		assertEquals(0.0, d, 1.0);
+	}
 
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+}
 ----
 
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
+For real-world use cases, check out the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
 
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
+When the type of the parameter to inject is the only condition for your
+`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
+The `supportsParameters` method is implemented behind the scenes and supports
+parameterized types.
 
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc
index 18eddfd55b43..cf8460955594 100644
--- a/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc
@@ -1,714 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
 [[writing-tests-disabling]]
 === Disabling Tests
 
@@ -757,3184 +46,3 @@ superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
 ====
 
 
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/display-names.adoc b/documentation/modules/ROOT/pages/writing-tests/display-names.adoc
index 18eddfd55b43..2346875b83a8 100644
--- a/documentation/modules/ROOT/pages/writing-tests/display-names.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/display-names.adoc
@@ -1,300 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
 [[writing-tests-display-names]]
 === Display Names
 
@@ -456,3485 +159,3 @@ following precedence rules:
    parameter, if present
 4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
 
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc
index 18eddfd55b43..92c3ae99ffbd 100644
--- a/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc
@@ -1,2974 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
 [[writing-tests-dynamic-tests]]
 === Dynamic Tests
 
@@ -3126,815 +155,3 @@ modes:
 **** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
 ** ... (same for "Container B" and "Container C")
 
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc b/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc
index 18eddfd55b43..23d17f93f422 100644
--- a/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc
@@ -1,593 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
 [[writing-tests-exceptions]]
 === Exception Handling
 
@@ -709,3232 +119,3 @@ NOTE: Third-party assertion libraries often provide similar support. For example
 has `assertThatNoException().isThrownBy(() -> ...)`. See also:
 <<writing-tests-assertions-third-party>>.
 
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/intro.adoc b/documentation/modules/ROOT/pages/writing-tests/intro.adoc
index 18eddfd55b43..1b6b9b38b953 100644
--- a/documentation/modules/ROOT/pages/writing-tests/intro.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/intro.adoc
@@ -15,3926 +15,3 @@ available features.
 include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
 ----
 
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc
index 18eddfd55b43..9fa0ed86d4b9 100644
--- a/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc
@@ -1,3940 +1,73 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
+[[writing-tests-nested]]
+=== Nested Tests
 
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+`@Nested` tests give the test writer more capabilities to express the relationship among
+several groups of tests. Such nested tests make use of Java's nested classes and
+facilitate hierarchical thinking about the test structure. Here's an elaborate example,
+both as source code and as a screenshot of the execution within an IDE.
 
 [source,java,indent=0]
+.Nested test suite for testing a stack
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
 ----
 
-NOTE: The provider implementation must have a no-args (or the default) constructor.
+When executing this example in an IDE, the test execution tree in the GUI will look
+similar to the following image.
 
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
+image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
 
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
+In this example, preconditions from outer tests are used in inner tests by defining
+hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
+`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
+in all levels in the nesting tree below the class in which it is defined.
 
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
+The fact that setup code from outer tests is run before inner tests are executed gives you
+the ability to run all tests independently. You can even run inner tests alone without
+running the outer tests, because the setup code from the outer tests is always executed.
 
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
+NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
+classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
+lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
 
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
+[[writing-tests-nested-interoperability]]
+==== Interoperability
 
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
+`@Nested` may be combined with
+<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+class is parameterized.
 
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
+`@ParameterizedTest`.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
 ----
 
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
+Executing the above test class yields the following output:
 
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
+....
+FruitTests ✔
+├─ [1] fruit = "apple" ✔
+│  └─ QuantityTests ✔
+│     ├─ [1] quantity = 23 ✔
+│     │  └─ test(Duration) ✔
+│     │     ├─ [1] duration = "PT1H" ✔
+│     │     └─ [2] duration = "PT2H" ✔
+│     └─ [2] quantity = 42 ✔
+│        └─ test(Duration) ✔
+│           ├─ [1] duration = "PT1H" ✔
+│           └─ [2] duration = "PT2H" ✔
+└─ [2] fruit = "banana" ✔
+   └─ QuantityTests ✔
+      ├─ [1] quantity = 23 ✔
+      │  └─ test(Duration) ✔
+      │     ├─ [1] duration = "PT1H" ✔
+      │     └─ [2] duration = "PT2H" ✔
+      └─ [2] quantity = 42 ✔
+         └─ test(Duration) ✔
+            ├─ [1] duration = "PT1H" ✔
+            └─ [2] duration = "PT2H" ✔
+....
 
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc b/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc
index 18eddfd55b43..dba5c7e15b82 100644
--- a/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc
@@ -1,3293 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
 [[writing-tests-parallel-execution]]
 === Parallel Execution
 
@@ -3642,299 +352,3 @@ include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags
 ----
 
 
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc
index 18eddfd55b43..70484f86cf21 100644
--- a/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc
@@ -1,1629 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
 [[writing-tests-parameterized-tests]]
 === Parameterized Classes and Tests
 
@@ -2940,1001 +1314,3 @@ include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
 <3> Validation and cleanup of the argument _after_ each invocation of the parameterized
     class
 
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc
index 18eddfd55b43..c0e4eeb7544b 100644
--- a/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc
@@ -1,3940 +1,177 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
+[[writing-tests-repeated-tests]]
+=== Repeated Tests
 
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
+JUnit Jupiter provides the ability to repeat a test a specified number of times by
+annotating a method with `@RepeatedTest` and specifying the total number of repetitions
+desired. Each invocation of a repeated test behaves like the execution of a regular
+`@Test` method with full support for the same lifecycle callbacks and extensions.
 
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
+The following example demonstrates how to declare a test named `repeatedTest()` that
+will be automatically repeated 10 times.
 
 [source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
 ----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+@RepeatedTest(10)
+void repeatedTest() {
+	// ...
+}
 ----
 
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
+`@RepeatedTest` can be configured with a failure threshold which signifies the number of
+failures after which remaining repetitions will be automatically skipped. Set the
+`failureThreshold` attribute to a positive number less than the total number of
+repetitions in order to skip the invocations of remaining repetitions after the specified
+number of failures has been encountered.
 
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
+For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
+to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
+there is no need to invoke the remaining repetitions. To support that specific use case,
+set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
+than 1 depending on your use case.
 
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
+By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
+no failure threshold will be applied, which effectively means that the specified number of
+repetitions will be invoked regardless of whether any repetitions fail.
 
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
+WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
+guarantees can be made regarding the failure threshold. It is therefore recommended that a
+`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
+is configured. See <<writing-tests-parallel-execution>> for further details.
 
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
+In addition to specifying the number of repetitions and failure threshold, a custom
+display name can be configured for each repetition via the `name` attribute of the
+`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
+combination of static text and dynamic placeholders. The following placeholders are
+currently supported.
 
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
+- `+{displayName}+`: display name of the `@RepeatedTest` method
+- `+{currentRepetition}+`: the current repetition count
+- `+{totalRepetitions}+`: the total number of repetitions
 
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
+The default display name for a given repetition is generated based on the following
+pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
+names for individual repetitions of the previous `repeatedTest()` example would be:
+`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
+the `@RepeatedTest` method included in the name of each repetition, you can define your
+own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
+latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
++{totalRepetitions}+"` which results in display names for individual repetitions like
+`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
 
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
+In order to retrieve information about the current repetition, the total number of
+repetitions, the number of repetitions that have failed, and the failure threshold, a
+developer can choose to have an instance of `{RepetitionInfo}` injected into a
+`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
 
-NOTE: The provider implementation must have a no-args (or the default) constructor.
+[[writing-tests-repeated-tests-examples]]
+==== Repeated Test Examples
 
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
+The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
+repeated tests.
 
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
+The `repeatedTest()` method is identical to the example from the previous section; whereas,
+`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
+`RepetitionInfo` injected into a test to access the total number of repetitions for the
+current repeated test.
 
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
+`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
+simulates an unexpected failure for every second repetition.The resulting behavior can be
+viewed in the `ConsoleLauncher` output at the end of this section.
 
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
+The next two methods demonstrate how to include a custom `@DisplayName` for the
+`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
+combines a custom display name with a custom pattern and then uses `TestInfo` to verify
+the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
+from the `@DisplayName` declaration, and `1/1` comes from
+`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
+`customDisplayNameWithLongPattern()` uses the aforementioned predefined
+`RepeatedTest.LONG_DISPLAY_NAME` pattern.
 
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
+`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
+tests into foreign languages -- in this case German, resulting in names for individual
+repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
 
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
+Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
+before each repetition of each repeated test. By having the `TestInfo` and
+`RepetitionInfo` injected into the method, we see that it's possible to obtain
+information about the currently executing repeated test. Executing `RepeatedTestsDemo`
+with the `INFO` log level enabled results in the following output.
 
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+....
+INFO: About to execute repetition 1 of 10 for repeatedTest
+INFO: About to execute repetition 2 of 10 for repeatedTest
+INFO: About to execute repetition 3 of 10 for repeatedTest
+INFO: About to execute repetition 4 of 10 for repeatedTest
+INFO: About to execute repetition 5 of 10 for repeatedTest
+INFO: About to execute repetition 6 of 10 for repeatedTest
+INFO: About to execute repetition 7 of 10 for repeatedTest
+INFO: About to execute repetition 8 of 10 for repeatedTest
+INFO: About to execute repetition 9 of 10 for repeatedTest
+INFO: About to execute repetition 10 of 10 for repeatedTest
+INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
+INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
+INFO: About to execute repetition 1 of 1 for customDisplayName
+INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
+INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
+INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
+....
 
-[source,java,indent=0]
+[source,java]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
 ----
 
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
+When using the `ConsoleLauncher` with the unicode theme enabled, execution of
+`RepeatedTestsDemo` results in the following output to the console.
 
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
+....
+├─ RepeatedTestsDemo ✔
+│  ├─ repeatedTest() ✔
+│  │  ├─ repetition 1 of 10 ✔
+│  │  ├─ repetition 2 of 10 ✔
+│  │  ├─ repetition 3 of 10 ✔
+│  │  ├─ repetition 4 of 10 ✔
+│  │  ├─ repetition 5 of 10 ✔
+│  │  ├─ repetition 6 of 10 ✔
+│  │  ├─ repetition 7 of 10 ✔
+│  │  ├─ repetition 8 of 10 ✔
+│  │  ├─ repetition 9 of 10 ✔
+│  │  └─ repetition 10 of 10 ✔
+│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 5 ✔
+│  │  ├─ repetition 2 of 5 ✔
+│  │  ├─ repetition 3 of 5 ✔
+│  │  ├─ repetition 4 of 5 ✔
+│  │  └─ repetition 5 of 5 ✔
+│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
+│  │  ├─ repetition 1 of 8 ✔
+│  │  ├─ repetition 2 of 8 ✘ Boom!
+│  │  ├─ repetition 3 of 8 ✔
+│  │  ├─ repetition 4 of 8 ✘ Boom!
+│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
+│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
+│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
+│  ├─ Repeat! ✔
+│  │  └─ Repeat! 1/1 ✔
+│  ├─ Details... ✔
+│  │  └─ Details... :: repetition 1 of 1 ✔
+│  └─ repeatedTestInGerman() ✔
+│     ├─ Wiederholung 1 von 5 ✔
+│     ├─ Wiederholung 2 von 5 ✔
+│     ├─ Wiederholung 3 von 5 ✔
+│     ├─ Wiederholung 4 von 5 ✔
+│     └─ Wiederholung 5 von 5 ✔
+....
 
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
 
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc b/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc
index 18eddfd55b43..5023e0971ea4 100644
--- a/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc
@@ -1,3940 +1,16 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
+[[writing-tests-tagging-and-filtering]]
+=== Tagging and Filtering
 
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
+Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
+used to filter <<running-tests, test discovery and execution>>. Please refer to the
+<<running-tests-tags>> section for more information about tag support in the JUnit
+Platform.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+include::{testDir}/example/TaggingDemo.java[tags=user_guide]
 ----
 
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
+TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+custom annotations for tags.
 
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc b/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc
index 18eddfd55b43..69ee0ea0a894 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc
@@ -1,225 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
 [[writing-tests-classes-and-methods]]
 === Test Classes and Methods
 
@@ -295,3646 +73,3 @@ and
 https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
 to be present on the classpath or module path.
 
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc b/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc
index 18eddfd55b43..13150a3a2485 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc
@@ -1,3940 +1,141 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
+[[writing-tests-test-execution-order]]
+=== Test Execution Order
 
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
+By default, test classes and methods will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute test classes and test methods in the same order, thereby allowing for
+repeatable builds.
 
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
+NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
 
-Running the above test class results in the following display names.
+[[writing-tests-test-execution-order-methods]]
+==== Method Order
 
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
+Although true _unit tests_ typically should not rely on the order in which they are
+executed, there are times when it is necessary to enforce a specific test method execution
+order -- for example, when writing _integration tests_ or _functional tests_ where the
+sequence of the tests is important, especially in conjunction with
+`@TestInstance(Lifecycle.PER_CLASS)`.
 
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
+To control the order in which test methods are executed, annotate your test class or test
+interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
+implementation. You can implement your own custom `MethodOrderer` or use one of the
+following built-in `MethodOrderer` implementations.
 
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
+* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
+  and formal parameter lists
+* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
+  configuration of a custom _seed_
 
-Running the above test class results in the following display names.
+The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
+it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
+`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
+with `{TestMethodOrder}`.
 
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
+NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
 
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
+The following example demonstrates how to guarantee that test methods are executed in the
+order specified via the `@Order` annotation.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
 ----
 
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
+[[writing-tests-test-execution-order-methods-default]]
+===== Setting the Default Method Orderer
 
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
+You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
+configuration parameter>> to specify the fully qualified class name of the
+`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
+via the `{TestMethodOrder}` annotation, the supplied class has to implement the
+`MethodOrderer` interface. The default orderer will be used for all tests unless the
+`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
 
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
+For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
+should set the configuration parameter to the corresponding fully qualified class name
+(e.g., in `src/test/resources/junit-platform.properties`):
 
 [source,properties,indent=0]
 ----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
+junit.jupiter.testmethod.order.default = \
+    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
 ----
 
 Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
+`MethodOrderer`.
 
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
+[[writing-tests-test-execution-order-classes]]
+==== Class Order
 
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
+Although test classes typically should not rely on the order in which they are executed,
+there are times when it is desirable to enforce a specific test class execution order. You
+may wish to execute test classes in a random order to ensure there are no accidental
+dependencies between test classes, or you may wish to order test classes to optimize build
+time as outlined in the following scenarios.
 
-[[writing-tests-assumptions]]
-=== Assumptions
+* Run previously failing tests and faster tests first: "fail fast" mode
+* With parallel execution enabled, schedule longer tests first: "shortest test plan
+  execution duration" mode
+* Various other use cases
 
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
+To configure test class execution order _globally_ for the entire test suite, use the
+`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
+parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+like to use. The supplied class must implement the `ClassOrderer` interface.
 
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
+You can implement your own custom `ClassOrderer` or use one of the following built-in
+`ClassOrderer` implementations.
 
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
+* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
+  qualified class names
+* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
+  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
+  generation precedence rules>>)
+* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
+  specified via the `{Order}` annotation
+* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
+  configuration of a custom _seed_
 
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
+For example, for the `@Order` annotation to be honored on _test classes_, you should
+configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
+parameter with the corresponding fully qualified class name (e.g., in
+`src/test/resources/junit-platform.properties`):
 
-[source,java,indent=0]
+[source,properties,indent=0]
 ----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+junit.jupiter.testclass.order.default = \
+    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
 ----
 
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
+The configured `ClassOrderer` will be applied to all top-level test classes (including
+`static` nested test classes) and `@Nested` test classes.
 
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
+NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
+test classes will be ordered relative to other `@Nested` test classes sharing the same
+_enclosing class_.
 
-See <<writing-tests-assumptions>> for further details and examples.
-====
+To configure test class execution order _locally_ for `@Nested` test classes, declare the
+`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
+want to order, and supply a class reference to the `ClassOrderer` implementation you would
+like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
+will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
+If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
+enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
+Note that a local `@TestClassOrder` declaration always overrides an inherited
+`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
+`junit.jupiter.testclass.order.default` configuration parameter.
 
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
+The following example demonstrates how to guarantee that `@Nested` test classes are
+executed in the order specified via the `@Order` annotation.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
 ----
 
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc b/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc
index 18eddfd55b43..b92bf55f492e 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc
@@ -1,1143 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
 [[writing-tests-test-instance-lifecycle]]
 === Test Instance Lifecycle
 
@@ -1202,2739 +62,3 @@ configures "per-class" semantics as the default but tests in the IDE are execute
 build server. It is therefore recommended to change the default in the JUnit Platform
 configuration file instead of via a JVM system property.
 
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc b/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc
index 18eddfd55b43..2a7468bcbcc3 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc
@@ -1,3940 +1,80 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
+[[writing-tests-test-interfaces-and-default-methods]]
+=== Test Interfaces and Default Methods
 
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
+JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
+`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
+methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
+test interface or on interface `default` methods _if_ the test interface or test class is
+annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
+<<writing-tests-test-instance-lifecycle>>). Here are some examples.
 
 [source,java]
 ----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
 ----
 
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
 [source,java]
 ----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
 ----
 
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
+`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
+implement the interface automatically inherit its tags and extensions. See
+<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
+<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
 
 [source,java]
 ----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
 ----
 
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
+In your test class you can then implement these test interfaces to have them applied.
 
 [source,java]
 ----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
 ----
 
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
+Running the `TestInterfaceDemo` results in output similar to the following:
 
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
+....
+INFO  example.TestLifecycleLogger - Before all tests
+INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
+INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
+INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
+INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
+INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
+INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
+INFO  example.TestLifecycleLogger - After all tests
+....
 
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
+Another possible application of this feature is to write tests for interface contracts.
+For example, you can write tests for how implementations of `Object.equals` or
+`Comparable.compareTo` should behave as follows.
 
 [source,java]
 ----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
+include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
 ----
 
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
 [source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
 ----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
 ----
 
 [source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
 ----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
 ----
 
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
+In your test class you can then implement both contract interfaces thereby inheriting the
+corresponding tests. Of course you'll have to implement the abstract methods.
 
 [source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
 ----
 
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
+NOTE: The above tests are merely meant as examples and therefore not complete.
 
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
 
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc b/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc
index 18eddfd55b43..9c8bc506957a 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc
@@ -1,2959 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
 [[writing-tests-test-templates]]
 === Test Templates
 
@@ -2969,972 +13,3 @@ NOTE: <<writing-tests-repeated-tests>> and
 <<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
 test templates.
 
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
-
-The `@Timeout` annotation allows one to declare that a test, test factory, test template,
-or lifecycle method should fail if its execution time exceeds a given duration. The time
-unit for the duration defaults to seconds but is configurable.
-
-The following example shows how `@Timeout` is applied to lifecycle and test methods.
-
-[source,java]
-----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
-----
-
-To apply the same timeout to all test methods within a test class and all of its `@Nested`
-classes, you can declare the `@Timeout` annotation at the class level. It will then be
-applied to all test, test factory, and test template methods within that class and its
-`@Nested` classes unless overridden by a `@Timeout` annotation on a specific method or
-`@Nested` class. Please note that `@Timeout` annotations declared at the class level are
-not applied to lifecycle methods.
-
-Declaring `@Timeout` on a `@TestFactory` method checks that the factory method returns
-within the specified duration but does not verify the execution time of each individual
-`DynamicTest` generated by the factory. Please use
-`assertTimeout()` or `assertTimeoutPreemptively()` for that purpose.
-
-If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
-`@ParameterizedTest` — each invocation will have the given timeout applied to it.
-
-[[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
-
-The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
-`SEPARATE_THREAD`, or `INFERRED`.
-
-When `SAME_THREAD` is used, the execution of the annotated method proceeds in the main
-thread of the test. If the timeout is exceeded, the main thread is interrupted from
-another thread. This is done to ensure interoperability with frameworks such as Spring
-that make use of mechanisms that are sensitive to the currently running thread — for
-example, `ThreadLocal` transaction management.
-
-On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
-assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
-
-When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
-`junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
-provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
-fallback.
-
-[[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
-
-The following <<running-tests-config-params, configuration parameters>> can be used to
-specify default timeouts for all methods of a certain category unless they or an enclosing
-test class is annotated with `@Timeout`:
-
-`junit.jupiter.execution.timeout.default`::
-    Default timeout for all testable and lifecycle methods
-`junit.jupiter.execution.timeout.testable.method.default`::
-    Default timeout for all testable methods
-`junit.jupiter.execution.timeout.test.method.default`::
-    Default timeout for `@Test` methods
-`junit.jupiter.execution.timeout.testtemplate.method.default`::
-    Default timeout for `@TestTemplate` methods
-`junit.jupiter.execution.timeout.testfactory.method.default`::
-    Default timeout for `@TestFactory` methods
-`junit.jupiter.execution.timeout.lifecycle.method.default`::
-    Default timeout for all lifecycle methods
-`junit.jupiter.execution.timeout.beforeall.method.default`::
-    Default timeout for `@BeforeAll` methods
-`junit.jupiter.execution.timeout.beforeeach.method.default`::
-    Default timeout for `@BeforeEach` methods
-`junit.jupiter.execution.timeout.aftereach.method.default`::
-    Default timeout for `@AfterEach` methods
-`junit.jupiter.execution.timeout.afterall.method.default`::
-    Default timeout for `@AfterAll` methods
-
-More specific configuration parameters override less specific ones. For example,
-`junit.jupiter.execution.timeout.test.method.default` overrides
-`junit.jupiter.execution.timeout.testable.method.default` which overrides
-`junit.jupiter.execution.timeout.default`.
-
-The values of such configuration parameters must be in the following, case-insensitive
-format: `<number> [ns|μs|ms|s|m|h|d]`. The space between the number and the unit may be
-omitted. Specifying no unit is equivalent to using seconds.
-
-.Example timeout configuration parameter values
-[cols="20,80"]
-|===
-| Parameter value | Equivalent annotation
-
-| `42`            | `@Timeout(42)`
-| `42 ns`         | `@Timeout(value = 42, unit = NANOSECONDS)`
-| `42 μs`         | `@Timeout(value = 42, unit = MICROSECONDS)`
-| `42 ms`         | `@Timeout(value = 42, unit = MILLISECONDS)`
-| `42 s`          | `@Timeout(value = 42, unit = SECONDS)`
-| `42 m`          | `@Timeout(value = 42, unit = MINUTES)`
-| `42 h`          | `@Timeout(value = 42, unit = HOURS)`
-| `42 d`          | `@Timeout(value = 42, unit = DAYS)`
-|===
-
-
-[[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
-
-When dealing with asynchronous code, it is common to write tests that poll while waiting
-for something to happen before performing any assertions. In some cases you can rewrite
-the logic to use a `CountDownLatch` or another synchronization mechanism, but sometimes
-that is not possible — for example, if the subject under test sends a message to a channel
-in an external message broker and assertions cannot be performed until the message has
-been successfully sent through the channel. Asynchronous tests like these require some
-form of timeout to ensure they don't hang the test suite by executing indefinitely, as
-would be the case if an asynchronous message never gets successfully delivered.
-
-By configuring a timeout for an asynchronous test that polls, you can ensure that the test
-does not execute indefinitely. The following example demonstrates how to achieve this with
-JUnit Jupiter's `@Timeout` annotation. This technique can be used to implement "poll
-until" logic very easily.
-
-[source,java]
-----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
-----
-
-NOTE: If you need more control over polling intervals and greater flexibility with
-asynchronous tests, consider using a dedicated library such as
-link:https://github.com/awaitility/awaitility[Awaitility].
-
-
-[[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
-
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
-`Thread.interrupt()` on the thread that is executing the timed out method. This allows to
-inspect the application state and output additional information that might be helpful for
-diagnosing the cause of a timeout.
-
-
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
-
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
-extension point that dumps the stacks of all threads to `System.out` if enabled by setting
-the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
-
-
-[[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
-
-When stepping through your code in a debug session, a fixed timeout limit may influence
-the result of the test, e.g. mark the test as failed although all assertions were met.
-
-JUnit Jupiter supports the `junit.jupiter.execution.timeout.mode` configuration parameter
-to configure when timeouts are applied. There are three modes: `enabled`, `disabled`,
-and `disabled_on_debug`. The default mode is `enabled`.
-A VM runtime is considered to run in debug mode when one of its input parameters starts
-with `-agentlib:jdwp` or `-Xrunjdwp`.
-This heuristic is queried by the `disabled_on_debug` mode.
-
-
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.
diff --git a/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc b/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc
index 18eddfd55b43..2cabb0284124 100644
--- a/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc
@@ -1,3131 +1,3 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
-
-The following example provides a glimpse at the minimum requirements for writing a test in
-JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
-available features.
-
-[source,java,indent=0]
-.A first test case
-----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
-----
-
-[[writing-tests-annotations]]
-=== Annotations
-
-JUnit Jupiter supports the following annotations for configuring tests and extending the
-framework.
-
-Unless otherwise stated, all core annotations are located in the `{api-package}` package
-in the `junit-jupiter-api` module.
-
-`*@Test*`:: Denotes that a method is a test method. Unlike JUnit 4's `@Test` annotation,
-this annotation does not declare any attributes, since test extensions in JUnit Jupiter
-operate based on their own dedicated annotations. Such methods are inherited unless they
-are overridden.
-
-`*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
-unless they are overridden.
-
-`*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
-are overridden.
-
-`*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
-times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
-overridden.
-
-`*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
-test classes in the annotated test class. Such annotations are inherited.
-
-`*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
-annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
-inherited.
-
-`*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
-class. Such annotations are inherited.
-
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
-test class or test method. Such annotations are not inherited.
-
-`*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
-annotations are inherited.
-
-`*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@Before`. Such methods are inherited unless they are
-overridden.
-
-`*@AfterEach*`:: Denotes that the annotated method should be executed _after_ *each*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, or `@TestFactory` method in the current
-class; analogous to JUnit 4's `@After`. Such methods are inherited unless they are
-overridden.
-
-`*@BeforeAll*`:: Denotes that the annotated method should be executed _before_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
-top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
-inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
-
-`*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
-inherited.
-
-`*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
-executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
-unless they are overridden.
-
-`*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
-multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
-
-`*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
-
-`*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
-method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
-annotations are inherited at the class level but not at the method level.
-
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
-analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
-
-`*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
-execution. Such fields are inherited.
-
-`*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
-its execution exceeds a given duration. Such annotations are inherited.
-
-`*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
-injection or parameter injection in a test class constructor, lifecycle method, or test
-method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
-
-`*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
-annotations are inherited.
-
-`*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
-Such fields are inherited.
-
-WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
-
-[[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
-
-JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
-define your own _composed annotation_ that will automatically _inherit_ the semantics of
-its meta-annotations.
-
-For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
-named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
-`@Tag("fast")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/Fast.java[tags=user_guide]
-----
-
-The following `@Test` method demonstrates usage of the `@Fast` annotation.
-
-[source,java,indent=0]
-----
-@Fast
-@Test
-void myFastTest() {
-    // ...
-}
-----
-
-You can even take that one step further by introducing a custom `@FastTest` annotation
-that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/FastTest.java[tags=user_guide]
-----
-
-JUnit automatically recognizes the following as a `@Test` method that is tagged with
-"fast".
-
-[source,java,indent=0]
-----
-@FastTest
-void myFastTest() {
-    // ...
-}
-----
-
-[[writing-tests-definitions]]
-=== Definitions
-
-.Platform Concepts
-****
-Container::
-a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
-
-Test::
-a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
-
-.Jupiter Concepts
-****
-Lifecycle Method::
-any method that is directly annotated or meta-annotated with
-`@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
-
-Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
-Test classes must not be `abstract` and must have a single constructor.
-Java `record` classes are supported as well.
-
-Test Method::
-any instance method that is directly annotated or meta-annotated with
-`@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
-With the exception of `@Test`, these create a _container_ in the test tree that groups
-_tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
-
-Test methods and lifecycle methods may be declared locally within the current test class,
-inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
-lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
-methods which are required to return a value).
-
-[NOTE]
-.Class and method visibility
-====
-Test classes, test methods, and lifecycle methods are not required to be `public`, but
-they must _not_ be `private`.
-
-It is generally recommended to omit the `public` modifier for test classes, test methods,
-and lifecycle methods unless there is a technical reason for doing so – for example, when
-a test class is extended by a test class in another package. Another technical reason for
-making classes and methods `public` is to simplify testing on the module path when using
-the Java Module System.
-====
-
-[NOTE]
-.Field and method inheritance
-====
-Fields in test classes are inherited. For example, a `@TempDir` field from a superclass
-will always be applied in a subclass.
-
-Test methods and lifecycle methods are inherited unless they are overridden according to
-the visibility rules of the Java language. For example, a `@Test` method from a superclass
-will always be applied in a subclass unless the subclass explicitly overrides the method.
-Similarly, if a package-private `@Test` method is declared in a superclass that resides in
-a different package than the subclass, that `@Test` method will always be applied in the
-subclass since the subclass cannot override a package-private method from a superclass in
-a different package.
-
-See also: <<extensions-supported-utilities-search-semantics>>
-====
-
-The following test class demonstrates the use of `@Test` methods and all supported
-lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
-
-[source,java,indent=0]
-.A standard Java test class
-----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
-----
-
-It is also possible to use Java `record` classes as test classes as illustrated by the
-following example.
-
-[source,java,indent=0]
-.A test class written as a Java record
-----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
-----
-
-Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
-keyword for testing code using coroutines.
-
-[source,kotlin]
-.A test class written in Kotlin
-----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
-----
-
-NOTE: Using suspending functions as test or lifecycle methods requires
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib[`kotlin-stdlib`],
-https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotlin-reflect`],
-and
-https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
-to be present on the classpath or module path.
-
-[[writing-tests-display-names]]
-=== Display Names
-
-Test classes and test methods can declare custom display names via `@DisplayName` -- with
-spaces, special characters, and even emojis -- that will be displayed in test reports and
-by test runners and IDEs.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
-----
-
-[NOTE]
-====
-Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
-for details.
-
-Any remaining ISO control characters in a display name will be replaced as follows.
-
-[cols="25%,15%,60%"]
-|===
-| Original | Replacement | Description
-
-| ```\r```
-| ```<CR>```
-| Textual representation of a carriage return
-
-| ```\n```
-| ```<LF>```
-| Textual representation of a line feed
-
-| Other control character
-| ```�```
-| Unicode replacement character (U+FFFD)
-|===
-====
-
-[[writing-tests-display-name-generator]]
-==== Display Name Generators
-
-JUnit Jupiter supports custom display name generators that can be configured via the
-`@DisplayNameGeneration` annotation.
-
-Generators can be created by implementing the `DisplayNameGenerator` API. The following
-table lists the default display name generators available in Jupiter.
-
-[cols="20,80"]
-|===
-| DisplayNameGenerator   | Behavior
-
-| `Standard`            | Matches the standard display name generation behavior in place since JUnit Jupiter was introduced.
-| `Simple`              | Extends the functionality of `Standard` by removing trailing parentheses for methods with no parameters.
-| `ReplaceUnderscores`  | Replaces underscores with spaces.
-| `IndicativeSentences` | Generates complete sentences by concatenating the names of the test and the enclosing classes.
-|===
-
-NOTE: Values provided via `@DisplayName` annotations always take precedence over display
-names generated by a `DisplayNameGenerator`.
-
-======
-The following example demonstrates the use of the `ReplaceUnderscores` display name
-generator.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is not supported ✔
-├─ if it is zero ✔
-└─ A negative value for year is not supported by the leap year computation. ✔
-   ├─ For example, year -1 is not supported. ✔
-   └─ For example, year -4 is not supported. ✔
-```
-======
-
-======
-With the `IndicativeSentences` display name generator, you can customize the separator and
-the underlying generator by using `@IndicativeSentencesGeneration` as shown in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year -> if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year -> if it is one of the following years ✔
-   ├─ Year 2016 is a leap year. ✔
-   ├─ Year 2020 is a leap year. ✔
-   └─ Year 2048 is a leap year. ✔
-```
-======
-
-======
-With `IndicativeSentences`, you can optionally specify custom sentence fragments via the
-`@SentenceFragment` annotation as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
-----
-
-Running the above test class results in the following display names.
-
-```
-A year is a leap year ✔
-├─ A year is a leap year, if it is divisible by 4 but not by 100 ✔
-└─ A year is a leap year, if it is one of the following years ✔
-   ├─ 2016 ✔
-   ├─ 2020 ✔
-   └─ 2048 ✔
-```
-======
-
-
-[[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
-
-You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
-class name of the `DisplayNameGenerator` you would like to use by default. Just like for
-display name generators configured via the `@DisplayNameGeneration` annotation, the
-supplied class has to implement the `DisplayNameGenerator` interface. The default display
-name generator will be used for all tests unless the `@DisplayNameGeneration` annotation
-is present on an enclosing test class or test interface. Values provided via
-`@DisplayName` annotations always take precedence over display names generated by a
-`DisplayNameGenerator`.
-
-For example, to use the `ReplaceUnderscores` display name generator by default, you should
-set the configuration parameter to the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.displayname.generator.default = \
-    org.junit.jupiter.api.DisplayNameGenerator$ReplaceUnderscores
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`DisplayNameGenerator`.
-
-[[writing-tests-display-name-generator-precedence-rules]]
-In summary, the display name for a test class or method is determined according to the
-following precedence rules:
-
-1. value of the `@DisplayName` annotation, if present
-2. by calling the `DisplayNameGenerator` specified in the `@DisplayNameGeneration`
-   annotation, if present
-3. by calling the default `DisplayNameGenerator` configured via the configuration
-   parameter, if present
-4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
-[[writing-tests-assertions]]
-=== Assertions
-
-JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
-that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
-are `static` methods in the `{Assertions}` class.
-
-Assertion methods optionally accept the assertion message as their third parameter, which
-can be either a `String` or a `Supplier<String>`.
-
-When using a `Supplier<String>` (e.g., a lambda expression), the message is evaluated
-lazily. This can provide a performance benefit, especially if message construction is
-complex or time-consuming, as it is only evaluated when the assertion fails.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-assertions-preemptive-timeouts]]
-[WARNING]
-.Preemptive Timeouts with `assertTimeoutPreemptively()`
-====
-The various `assertTimeoutPreemptively()` methods in the `Assertions` class execute
-the provided `executable` or `supplier` in a different thread than that of the calling
-code. This behavior can lead to undesirable side effects if the code that is executed
-within the `executable` or `supplier` relies on `java.lang.ThreadLocal` storage.
-
-One common example of this is the transactional testing support in the Spring Framework.
-Specifically, Spring's testing support binds transaction state to the current thread (via
-a `ThreadLocal`) before a test method is invoked. Consequently, if an `executable` or
-`supplier` provided to `assertTimeoutPreemptively()` invokes Spring-managed components
-that participate in transactions, any actions taken by those components will not be rolled
-back with the test-managed transaction. On the contrary, such actions will be committed to
-the persistent store (e.g., relational database) even though the test-managed transaction
-is rolled back.
-
-Similar side effects may be encountered with other frameworks that rely on
-`ThreadLocal` storage.
-====
-
-[[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
-
-JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
-used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
-functions in the `org.junit.jupiter.api` package.
-
-[source,kotlin,indent=0]
-----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
-----
-
-[[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
-
-Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
-testing scenarios, there are times when more power and additional functionality are
-desired or required. In such cases, the JUnit team recommends the use of third-party
-assertion libraries such as {AssertJ}, {Hamcrest}, {Truth}, etc. Developers are therefore
-free to use the assertion library of their choice.
-
-For example, the following demonstrates how to use the `assertThat()` support from AssertJ
-in a JUnit Jupiter test. As long as the AssertJ library has been added to the classpath,
-you can statically import methods such as `assertThat()`, `assertThatException()`, etc.
-from `org.assertj.core.api.Assertions` and then use them in tests like in the
-`assertWithAssertJ()` method below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
-----
-
-[TIP]
-.Excluding Jupiter’s Assertions From a Project’s Classpath
-====
-If you would like to enforce that all your tests use a certain third-party assertion
-library instead of Jupiter's, you can set up a rule using {Checkstyle} or another static
-analysis tool that fails the build if Jupiter's `Assertions` class is used.
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN" "https://checkstyle.org/dtds/configuration_1_3.dtd">
-<module name="Checker">
-	<property name="severity" value="error" />
-	<module name="TreeWalker">
-    <module name="com.puppycrawl.tools.checkstyle.checks.regexp.RegexpSinglelineJavaCheck">
-			<property name="id" value="jupiterAssertions"/>
-			<property name="maximum" value="0"/>
-			<property name="format" value="org\.junit\.jupiter\.api\.(Assertions|Assumptions)\."/>
-			<property name="message" value="Jupiter Assertions/Assumptions should not be used in this project. Please use ... instead."/>
-			<property name="ignoreComments" value="true"/>
-		</module>
-	</module>
-</module>
-----
-====
-
-[[writing-tests-assumptions]]
-=== Assumptions
-
-Assumptions are typically used whenever it does not make sense to continue execution of a
-given test — for example, if the test depends on something that does not exist in the
-current runtime environment.
-
-* When an assumption is valid, the assumption method does not throw an exception, and
-  execution of the test continues as usual.
-* When an assumption is invalid, the assumption method throws an exception of type
-  `org.opentest4j.TestAbortedException` to signal that the test should be aborted instead
-  of marked as a failure.
-
-JUnit Jupiter comes with a subset of the _assumption_ methods that JUnit 4 provides and
-adds a few that lend themselves well to being used with Java lambda expressions and method
-references.
-
-All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
-----
-
-NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
-assumptions. Specifically, JUnit Jupiter supports JUnit 4's `AssumptionViolatedException`
-to signal that a test should be aborted instead of marked as a failure.
-
-TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for assumptions.
-To do so, you can statically import the `assumeThat()` method from
-`org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
-assumptions.
-
-[[writing-tests-exceptions]]
-=== Exception Handling
-
-JUnit Jupiter provides robust support for handling test exceptions. This includes the
-built-in mechanisms for managing test failures due to exceptions, the role of exceptions
-in implementing assertions and assumptions, and how to specifically assert non-throwing
-conditions in code.
-
-[[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
-
-In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
-extension and not caught within that test method, lifecycle method, or extension, the
-framework will mark the test or test class as failed.
-
-[TIP]
-====
-Failed assumptions deviate from this general rule.
-
-In contrast to failed assertions, failed assumptions do not result in a test failure;
-rather, a failed assumption results in a test being aborted.
-
-See <<writing-tests-assumptions>> for further details and examples.
-====
-
-In the following example, the `failsDueToUncaughtException()` method throws an
-`ArithmeticException`. Since the exception is not caught within the test method, JUnit
-Jupiter will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
-----
-
-NOTE: It's important to note that specifying a `throws` clause in the test method has
-no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws` clause
-as an expectation or assertion about what exceptions the test method should throw. A test
-fails only if an exception is thrown unexpectedly or if an assertion fails.
-
-[[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
-
-Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
-of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
-`AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
-further information about JUnit Jupiter's assertion support.
-
-NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
-failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
-
-TIP: JUnit Jupiter itself does not differentiate between failed assertions
-(`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
-failure. However, Integrated Development Environments (IDEs) and other tools may
-distinguish between these two types of failures by checking whether the thrown exception
-is an instance of `AssertionError`.
-
-In the following example, the `failsDueToUncaughtAssertionError()` method throws an
-`AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
-will mark the test as failed.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
-
-JUnit Jupiter offers specialized assertions for testing that specific exceptions are
-thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
-assertions are critical tools for validating that your code responds correctly to error
-conditions by throwing the appropriate exceptions.
-
-[[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
-
-The `assertThrows()` method is used to verify that a particular type of exception is
-thrown during the execution of a provided executable block. It not only checks for the
-type of the thrown exception but also its subclasses, making it suitable for more
-generalized exception handling tests. The `assertThrows()` assertion method returns the
-thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
-
-The `assertThrowsExactly()` method is used when you need to assert that the exception
-thrown is exactly of a specific type, not allowing for subclasses of the expected
-exception type. This is useful when precise exception handling behavior needs to be
-validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
-returns the thrown exception object to allow performing additional assertions on it.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
-----
-
-[[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
-
-Although any exception thrown from a test method will cause the test to fail, there are
-certain use cases where it can be beneficial to explicitly assert that an exception is
-_not_ thrown for a given code block within a test method. The `assertDoesNotThrow()`
-assertion can be used when you want to verify that a particular piece of code does not
-throw any exceptions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
-----
-
-NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
-has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
-
-[[writing-tests-disabling]]
-=== Disabling Tests
-
-Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
-annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
-
-When `@Disabled` is applied at the class level, all test methods within that class are
-automatically disabled as well.
-
-If a test method is disabled via `@Disabled`, that prevents execution of the test method
-and method-level lifecycle callbacks such as `@BeforeEach` methods, `@AfterEach` methods,
-and corresponding extension APIs. However, that does not prevent the test class from being
-instantiated, and it does not prevent the execution of class-level lifecycle callbacks
-such as `@BeforeAll` methods, `@AfterAll` methods, and corresponding extension APIs.
-
-Here's a `@Disabled` test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
-----
-
-And here's a test class that contains a `@Disabled` test method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
-----
-
-[TIP]
-====
-`@Disabled` may be declared without providing a _reason_; however, the JUnit team
-recommends that developers provide a short explanation for why a test class or test
-method has been disabled. Consequently, the above examples both show the use of a reason
--- for example, `@Disabled("Disabled until bug #42 has been resolved")`. Some development
-teams even require the presence of issue tracking numbers in the _reason_ for automated
-traceability, etc.
-====
-
-[NOTE]
-====
-`@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
-superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
-====
-
-
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
-
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
-developers to either _enable_ or _disable_ a test class or test method based on certain
-conditions _programmatically_. The simplest example of such a condition is the built-in
-`{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
-
-In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
-conditions in the `org.junit.jupiter.api.condition` package that allow developers to
-enable or disable test classes and test methods _declaratively_. If you wish to provide
-details about why they might be disabled, every annotation associated with these built-in
-conditions has a `disabledReason` attribute available for that purpose.
-
-When multiple `ExecutionCondition` extensions are registered, a test class or test method
-is disabled as soon as one of the conditions returns _disabled_. If a test class is
-disabled, all test methods within that class are automatically disabled as well. If a test
-method is disabled, that prevents execution of the test method and method-level lifecycle
-callbacks such as `@BeforeEach` methods, `@AfterEach` methods, and corresponding extension
-APIs. However, that does not prevent the test class from being instantiated, and it does
-not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
-`@AfterAll` methods, and corresponding extension APIs.
-
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
-details.
-
-[TIP]
-.Composed Annotations
-====
-Note that any of the _conditional_ annotations listed in the following sections may also
-be used as a meta-annotation in order to create a custom _composed annotation_. For
-example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
-combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
-====
-
-[NOTE]
-====
-_Conditional_ annotations in JUnit Jupiter are not `@Inherited`. Consequently, if you wish
-to apply the same semantics to subclasses, each conditional annotation must be redeclared
-on each subclass.
-====
-
-[WARNING]
-====
-Unless otherwise stated, each of the _conditional_ annotations listed in the following
-sections can only be declared once on a given test interface, test class, or test method.
-If a conditional annotation is directly present, indirectly present, or meta-present
-multiple times on a given element, only the first such annotation discovered by JUnit will
-be used; any additional declarations will be silently ignored. Note, however, that each
-conditional annotation may be used in conjunction with other conditional annotations in
-the `org.junit.jupiter.api.condition` package.
-====
-
-[[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
-
-A container or test may be enabled or disabled on a particular operating system,
-architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
-annotations.
-
-[[writing-tests-conditional-execution-os-demo]]
-[source,java,indent=0]
-.Conditional execution based on operating system
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
-----
-
-[[writing-tests-conditional-execution-architectures-demo]]
-[source,java,indent=0]
-.Conditional execution based on architecture
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
-----
-
-[[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
-
-A container or test may be enabled or disabled on particular versions of the Java Runtime
-Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
-particular range of versions of the JRE via the `{EnabledForJreRange}` and
-`{DisabledForJreRange}` annotations. The range effectively defaults to `JRE.JAVA_8` as the
-lower bound and `JRE.OTHER` as the upper bound, which allows usage of half open ranges.
-
-The following listing demonstrates the use of these annotations with predefined {JRE} enum
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
-----
-
-Since the enum constants defined in {JRE} are static for any given JUnit release, you
-might find that you need to configure a Java version that is not supported by the `JRE`
-enum. For example, when JUnit Jupiter 5.12 was released the `JRE` enum defined `JAVA_25`
-as the highest supported Java version. However, you may wish to run your tests against
-later versions of Java. To support such use cases, you can specify arbitrary Java versions
-via the `versions` attributes in `@EnabledOnJre` and `@DisabledOnJre` and via the
-`minVersion` and `maxVersion` attributes in `@EnabledForJreRange` and
-`@DisabledForJreRange`.
-
-The following listing demonstrates the use of these annotations with arbitrary Java
-versions.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
-----
-
-[[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
-
-A container or test may be enabled or disabled within a
-https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
-`{EnabledInNativeImage}` and `{DisabledInNativeImage}` annotations. These annotations are
-typically used when running tests within a native image using the Gradle and Maven
-plug-ins from the GraalVM https://graalvm.github.io/native-build-tools/latest/[Native
-Build Tools] project.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
-----
-
-[[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
-
-A container or test may be enabled or disabled based on the value of the `named` JVM
-system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
-annotations. The value supplied via the `matches` attribute will be interpreted as a
-regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
-----
-
-[TIP]
-====
-`{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}` are _repeatable annotations_.
-Consequently, these annotations may be declared multiple times on a test interface, test
-class, or test method. Specifically, these annotations will be found if they are directly
-present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
-
-A container or test may be enabled or disabled based on the value of the `named`
-environment variable from the underlying operating system via the
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` annotations. The
-value supplied via the `matches` attribute will be interpreted as a regular expression.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
-----
-
-[TIP]
-====
-`{EnabledIfEnvironmentVariable}` and `{DisabledIfEnvironmentVariable}` are _repeatable
-annotations_. Consequently, these annotations may be declared multiple times on a test
-interface, test class, or test method. Specifically, these annotations will be found if
-they are directly present, indirectly present, or meta-present on a given element.
-====
-
-[[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
-
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
-container or test may be enabled or disabled based on a _condition method_ configured via
-the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
-return type and may accept either no arguments or a single `ExtensionContext` argument.
-
-The following test class demonstrates how to configure a local method named
-`customCondition` via `@EnabledIf` and `@DisabledIf`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
-----
-
-Alternatively, the condition method can be located outside the test class. In this case,
-it must be referenced by its _fully qualified name_ as demonstrated in the following
-example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
-----
-
-[NOTE]
-====
-There are several cases where a condition method would need to be `static`:
-
-- when `@EnabledIf` or `@DisabledIf` is used at class level
-- when `@EnabledIf` or `@DisabledIf` is used on a `@ParameterizedTest` or a
-  `@TestTemplate` method
-- when the condition method is located in an external class
-
-In any other case, you can use either static methods or instance methods as condition
-methods.
-====
-
-[TIP]
-====
-It is often the case that you can use an existing static method in a utility class as a
-custom condition.
-
-For example, `java.awt.GraphicsEnvironment` provides a `public static boolean isHeadless()`
-method that can be used to determine if the current environment does not support a
-graphical display. Thus, if you have a test that depends on graphical support you can
-disable it when such support is unavailable as follows.
-
-[source,java,indent=0]
-----
-@DisabledIf(value = "java.awt.GraphicsEnvironment#isHeadless",
-	disabledReason = "headless environment")
-----
-====
-
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
-
-Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
-Platform.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
-----
-
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
-custom annotations for tags.
-
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
-
-By default, test classes and methods will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute test classes and test methods in the same order, thereby allowing for
-repeatable builds.
-
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
-
-[[writing-tests-test-execution-order-methods]]
-==== Method Order
-
-Although true _unit tests_ typically should not rely on the order in which they are
-executed, there are times when it is necessary to enforce a specific test method execution
-order -- for example, when writing _integration tests_ or _functional tests_ where the
-sequence of the tests is important, especially in conjunction with
-`@TestInstance(Lifecycle.PER_CLASS)`.
-
-To control the order in which test methods are executed, annotate your test class or test
-interface with `{TestMethodOrder}` and specify the desired `{MethodOrderer}`
-implementation. You can implement your own custom `MethodOrderer` or use one of the
-following built-in `MethodOrderer` implementations.
-
-* `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
-  and formal parameter lists
-* `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{MethodOrderer_Random}`: orders test methods _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-The `MethodOrderer` configured on a test class is inherited by the `@Nested` test classes
-it contains, recursively. If you want to avoid that a `@Nested` test class uses the same
-`MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
-with `{TestMethodOrder}`.
-
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
-
-The following example demonstrates how to guarantee that test methods are executed in the
-order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
-
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`{MethodOrderer}` you would like to use by default. Just like for the orderer configured
-via the `{TestMethodOrder}` annotation, the supplied class has to implement the
-`MethodOrderer` interface. The default orderer will be used for all tests unless the
-`@TestMethodOrder` annotation is present on an enclosing test class or test interface.
-
-For example, to use the `{MethodOrderer_OrderAnnotation}` method orderer by default, you
-should set the configuration parameter to the corresponding fully qualified class name
-(e.g., in `src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testmethod.order.default = \
-    org.junit.jupiter.api.MethodOrderer$OrderAnnotation
-----
-
-Similarly, you can specify the fully qualified name of any custom class that implements
-`MethodOrderer`.
-
-[[writing-tests-test-execution-order-classes]]
-==== Class Order
-
-Although test classes typically should not rely on the order in which they are executed,
-there are times when it is desirable to enforce a specific test class execution order. You
-may wish to execute test classes in a random order to ensure there are no accidental
-dependencies between test classes, or you may wish to order test classes to optimize build
-time as outlined in the following scenarios.
-
-* Run previously failing tests and faster tests first: "fail fast" mode
-* With parallel execution enabled, schedule longer tests first: "shortest test plan
-  execution duration" mode
-* Various other use cases
-
-To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
-like to use. The supplied class must implement the `ClassOrderer` interface.
-
-You can implement your own custom `ClassOrderer` or use one of the following built-in
-`ClassOrderer` implementations.
-
-* `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
-  qualified class names
-* `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
-* `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
-  specified via the `{Order}` annotation
-* `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
-  configuration of a custom _seed_
-
-For example, for the `@Order` annotation to be honored on _test classes_, you should
-configure the `{ClassOrderer_OrderAnnotation}` class orderer using the configuration
-parameter with the corresponding fully qualified class name (e.g., in
-`src/test/resources/junit-platform.properties`):
-
-[source,properties,indent=0]
-----
-junit.jupiter.testclass.order.default = \
-    org.junit.jupiter.api.ClassOrderer$OrderAnnotation
-----
-
-The configured `ClassOrderer` will be applied to all top-level test classes (including
-`static` nested test classes) and `@Nested` test classes.
-
-NOTE: Top-level test classes will be ordered relative to each other; whereas, `@Nested`
-test classes will be ordered relative to other `@Nested` test classes sharing the same
-_enclosing class_.
-
-To configure test class execution order _locally_ for `@Nested` test classes, declare the
-`{TestClassOrder}` annotation on the enclosing class for the `@Nested` test classes you
-want to order, and supply a class reference to the `ClassOrderer` implementation you would
-like to use directly in the `@TestClassOrder` annotation. The configured `ClassOrderer`
-will be applied recursively to `@Nested` test classes and their `@Nested` test classes.
-If you want to avoid that a `@Nested` test class uses the same `ClassOrderer` as its
-enclosing class, you can specify `{ClassOrderer_Default}` together with `@TestClassOrder`.
-Note that a local `@TestClassOrder` declaration always overrides an inherited
-`@TestClassOrder` declaration or a `ClassOrderer` configured globally via the
-`junit.jupiter.testclass.order.default` configuration parameter.
-
-The following example demonstrates how to guarantee that `@Nested` test classes are
-executed in the order specified via the `@Order` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
-----
-
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
-
-In order to allow individual test methods to be executed in isolation and to avoid
-unexpected side effects due to mutable test instance state, JUnit creates a new instance
-of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
-behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
-
-NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
-`@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
-
-If you would prefer that JUnit Jupiter execute all test methods on the same test
-instance, annotate your test class with `@TestInstance(Lifecycle.PER_CLASS)`. When using
-this mode, a new test instance will be created once per test class. Thus, if your test
-methods rely on state stored in instance variables, you may need to reset that state in
-`@BeforeEach` or `@AfterEach` methods.
-
-The "per-class" mode has some additional benefits over the default "per-method" mode.
-Specifically, with the "per-class" mode it becomes possible to declare `@BeforeAll` and
-`@AfterAll` on non-static methods as well as on interface `default` methods.
-
-If you are authoring tests using the Kotlin programming language, you may also find it
-easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as well as
-`@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
-mode.
-
-[[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
-
-If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
-will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
-however, it is possible to change the _default_ for the execution of an entire test plan.
-To change the default test instance lifecycle mode, set the
-`junit.jupiter.testinstance.lifecycle.default` _configuration parameter_ to the name of
-an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
-as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
-you can start your JVM with the following system property.
-
-`-Djunit.jupiter.testinstance.lifecycle.default=per_class`
-
-Note, however, that setting the default test instance lifecycle mode via the JUnit
-Platform configuration file is a more robust solution since the configuration file can be
-checked into a version control system along with your project and can therefore be used
-within IDEs and your build software.
-
-To set the default test instance lifecycle mode to `Lifecycle.PER_CLASS` via the JUnit
-Platform configuration file, create a file named `junit-platform.properties` in the root
-of the class path (e.g., `src/test/resources`) with the following content.
-
-`junit.jupiter.testinstance.lifecycle.default = per_class`
-
-WARNING: Changing the _default_ test instance lifecycle mode can lead to unpredictable
-results and fragile builds if not applied consistently. For example, if the build
-configures "per-class" semantics as the default but tests in the IDE are executed using
-"per-method" semantics, that can make it difficult to debug errors that occur on the
-build server. It is therefore recommended to change the default in the JUnit Platform
-configuration file instead of via a JVM system property.
-
-[[writing-tests-nested]]
-=== Nested Tests
-
-`@Nested` tests give the test writer more capabilities to express the relationship among
-several groups of tests. Such nested tests make use of Java's nested classes and
-facilitate hierarchical thinking about the test structure. Here's an elaborate example,
-both as source code and as a screenshot of the execution within an IDE.
-
-[source,java,indent=0]
-.Nested test suite for testing a stack
-----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
-----
-
-When executing this example in an IDE, the test execution tree in the GUI will look
-similar to the following image.
-
-image::writing-tests_nested_test_ide.png[caption='',title='Executing a nested test in an IDE']
-
-In this example, preconditions from outer tests are used in inner tests by defining
-hierarchical lifecycle methods for the setup code. For example, `createNewStack()` is a
-`@BeforeEach` lifecycle method that is used in the test class in which it is defined and
-in all levels in the nesting tree below the class in which it is defined.
-
-The fact that setup code from outer tests is run before inner tests are executed gives you
-the ability to run all tests independently. You can even run inner tests alone without
-running the outer tests, because the setup code from the outer tests is always executed.
-
-NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nested` test
-classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
-lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
-
-[[writing-tests-nested-interoperability]]
-==== Interoperability
-
-`@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
-class is parameterized.
-
-The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
-`@ParameterizedTest`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
-----
-
-Executing the above test class yields the following output:
-
-....
-FruitTests ✔
-├─ [1] fruit = "apple" ✔
-│  └─ QuantityTests ✔
-│     ├─ [1] quantity = 23 ✔
-│     │  └─ test(Duration) ✔
-│     │     ├─ [1] duration = "PT1H" ✔
-│     │     └─ [2] duration = "PT2H" ✔
-│     └─ [2] quantity = 42 ✔
-│        └─ test(Duration) ✔
-│           ├─ [1] duration = "PT1H" ✔
-│           └─ [2] duration = "PT2H" ✔
-└─ [2] fruit = "banana" ✔
-   └─ QuantityTests ✔
-      ├─ [1] quantity = 23 ✔
-      │  └─ test(Duration) ✔
-      │     ├─ [1] duration = "PT1H" ✔
-      │     └─ [2] duration = "PT2H" ✔
-      └─ [2] quantity = 42 ✔
-         └─ test(Duration) ✔
-            ├─ [1] duration = "PT1H" ✔
-            └─ [2] duration = "PT2H" ✔
-....
-
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
-
-In all prior JUnit versions, test constructors or methods were not allowed to have
-parameters (at least not with the standard `Runner` implementations). As one of the major
-changes in JUnit Jupiter, both test constructors and methods are now permitted to have
-parameters. This allows for greater flexibility and enables _Dependency Injection_ for
-constructors and methods.
-
-`{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
-resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
-must be resolved at runtime by a registered `ParameterResolver`.
-
-There are currently three built-in resolvers that are registered automatically.
-
-* `{TestInfoParameterResolver}`: if a constructor or method parameter is of type
-  `{TestInfo}`, the `TestInfoParameterResolver` will supply an instance of `TestInfo`
-  corresponding to the current container or test as the value for the parameter. The
-  `TestInfo` can then be used to retrieve information about the current container or test
-  such as the display name, the test class, the test method, and associated tags. The
-  display name is either a technical name, such as the name of the test class or test
-  method, or a custom name configured via `@DisplayName`.
-+
-`{TestInfo}` acts as a drop-in replacement for the `TestName` rule from JUnit 4. The
-following demonstrates how to have `TestInfo` injected into a `@BeforeAll` method, test
-class constructor, `@BeforeEach` method, and `@Test` method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
-----
-
-* `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
-  `@AfterEach` method is of type `{RepetitionInfo}`, the `RepetitionExtension` will supply
-  an instance of `RepetitionInfo`. `RepetitionInfo` can then be used to retrieve
-  information about the current repetition, the total number of repetitions, the number of
-  repetitions that have failed, and the failure threshold for the corresponding
-  `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
-
-* `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
-  `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
-  `TestReporter`. The `TestReporter` can be used to publish additional data about the
-  current test run or attach files to it. The data can be consumed in a
-  `{TestExecutionListener}` via the `reportingEntryPublished()` or `fileEntryPublished()`
-  method, respectively. This allows them to be viewed in IDEs or included in reports.
-+
-In JUnit Jupiter you should use `TestReporter` where you used to print information to
-`stdout` or `stderr` in JUnit 4. Some IDEs print report entries to `stdout` or display
-them in the user interface for test results.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
-----
-
-NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
-
-Check out the `{RandomParametersExtension}` for an example of a custom
-`{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
-simplicity and expressiveness of both the extension model and the parameter resolution
-process. `MyRandomParametersTest` demonstrates how to inject random values into `@Test`
-methods.
-
-[source,java,indent=0]
-----
-@ExtendWith(RandomParametersExtension.class)
-class MyRandomParametersTest {
-
-	@Test
-	void injectsInteger(@Random int i, @Random int j) {
-		assertNotEquals(i, j);
-	}
-
-	@Test
-	void injectsDouble(@Random double d) {
-		assertEquals(0.0, d, 1.0);
-	}
-
-}
-----
-
-For real-world use cases, check out the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-When the type of the parameter to inject is the only condition for your
-`{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
-The `supportsParameters` method is implemented behind the scenes and supports
-parameterized types.
-
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
-
-JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
-`@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
-methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
-test interface or on interface `default` methods _if_ the test interface or test class is
-annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
-----
-
-`@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
-implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
-----
-
-In your test class you can then implement these test interfaces to have them applied.
-
-[source,java]
-----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
-----
-
-Running the `TestInterfaceDemo` results in output similar to the following:
-
-....
-INFO  example.TestLifecycleLogger - Before all tests
-INFO  example.TestLifecycleLogger - About to execute [dynamicTestsForPalindromes()]
-INFO  example.TimingExtension - Method [dynamicTestsForPalindromes] took 19 ms.
-INFO  example.TestLifecycleLogger - Finished executing [dynamicTestsForPalindromes()]
-INFO  example.TestLifecycleLogger - About to execute [isEqualValue()]
-INFO  example.TimingExtension - Method [isEqualValue] took 1 ms.
-INFO  example.TestLifecycleLogger - Finished executing [isEqualValue()]
-INFO  example.TestLifecycleLogger - After all tests
-....
-
-Another possible application of this feature is to write tests for interface contracts.
-For example, you can write tests for how implementations of `Object.equals` or
-`Comparable.compareTo` should behave as follows.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
-----
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
-----
-
-In your test class you can then implement both contract interfaces thereby inheriting the
-corresponding tests. Of course you'll have to implement the abstract methods.
-
-[source,java]
-----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
-----
-
-NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
-
-JUnit Jupiter provides the ability to repeat a test a specified number of times by
-annotating a method with `@RepeatedTest` and specifying the total number of repetitions
-desired. Each invocation of a repeated test behaves like the execution of a regular
-`@Test` method with full support for the same lifecycle callbacks and extensions.
-
-The following example demonstrates how to declare a test named `repeatedTest()` that
-will be automatically repeated 10 times.
-
-[source,java]
-----
-@RepeatedTest(10)
-void repeatedTest() {
-	// ...
-}
-----
-
-`@RepeatedTest` can be configured with a failure threshold which signifies the number of
-failures after which remaining repetitions will be automatically skipped. Set the
-`failureThreshold` attribute to a positive number less than the total number of
-repetitions in order to skip the invocations of remaining repetitions after the specified
-number of failures has been encountered.
-
-For example, if you are using `@RepeatedTest` to repeatedly invoke a test that you suspect
-to be _flaky_, a single failure is sufficient to demonstrate that the test is flaky, and
-there is no need to invoke the remaining repetitions. To support that specific use case,
-set `failureThreshold = 1`. You can alternatively set the threshold to a number greater
-than 1 depending on your use case.
-
-By default, the `failureThreshold` attribute is set to `Integer.MAX_VALUE`, signaling that
-no failure threshold will be applied, which effectively means that the specified number of
-repetitions will be invoked regardless of whether any repetitions fail.
-
-WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
-guarantees can be made regarding the failure threshold. It is therefore recommended that a
-`@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
-
-In addition to specifying the number of repetitions and failure threshold, a custom
-display name can be configured for each repetition via the `name` attribute of the
-`@RepeatedTest` annotation. Furthermore, the display name can be a pattern composed of a
-combination of static text and dynamic placeholders. The following placeholders are
-currently supported.
-
-- `+{displayName}+`: display name of the `@RepeatedTest` method
-- `+{currentRepetition}+`: the current repetition count
-- `+{totalRepetitions}+`: the total number of repetitions
-
-The default display name for a given repetition is generated based on the following
-pattern: `"repetition +{currentRepetition}+ of +{totalRepetitions}+"`.Thus, the display
-names for individual repetitions of the previous `repeatedTest()` example would be:
-`repetition 1 of 10`, `repetition 2 of 10`, etc.If you would like the display name of
-the `@RepeatedTest` method included in the name of each repetition, you can define your
-own custom pattern or use the predefined `RepeatedTest.LONG_DISPLAY_NAME` pattern.The
-latter is equal to `"+{displayName}+ :: repetition +{currentRepetition}+ of
-+{totalRepetitions}+"` which results in display names for individual repetitions like
-`repeatedTest() :: repetition 1 of 10`, `repeatedTest() :: repetition 2 of 10`, etc.
-
-In order to retrieve information about the current repetition, the total number of
-repetitions, the number of repetitions that have failed, and the failure threshold, a
-developer can choose to have an instance of `{RepetitionInfo}` injected into a
-`@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
-
-[[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
-
-The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
-repeated tests.
-
-The `repeatedTest()` method is identical to the example from the previous section; whereas,
-`repeatedTestWithRepetitionInfo()` demonstrates how to have an instance of
-`RepetitionInfo` injected into a test to access the total number of repetitions for the
-current repeated test.
-
-`repeatedTestWithFailureThreshold()` demonstrates how to set a failure threshold and
-simulates an unexpected failure for every second repetition.The resulting behavior can be
-viewed in the `ConsoleLauncher` output at the end of this section.
-
-The next two methods demonstrate how to include a custom `@DisplayName` for the
-`@RepeatedTest` method in the display name of each repetition. `customDisplayName()`
-combines a custom display name with a custom pattern and then uses `TestInfo` to verify
-the format of the generated display name. `Repeat!` is the `+{displayName}+` which comes
-from the `@DisplayName` declaration, and `1/1` comes from
-`+{currentRepetition}+/+{totalRepetitions}+`.In contrast,
-`customDisplayNameWithLongPattern()` uses the aforementioned predefined
-`RepeatedTest.LONG_DISPLAY_NAME` pattern.
-
-`repeatedTestInGerman()` demonstrates the ability to translate display names of repeated
-tests into foreign languages -- in this case German, resulting in names for individual
-repetitions such as: `Wiederholung 1 von 5`, `Wiederholung 2 von 5`, etc.
-
-Since the `beforeEach()` method is annotated with `@BeforeEach` it will get executed
-before each repetition of each repeated test. By having the `TestInfo` and
-`RepetitionInfo` injected into the method, we see that it's possible to obtain
-information about the currently executing repeated test. Executing `RepeatedTestsDemo`
-with the `INFO` log level enabled results in the following output.
-
-....
-INFO: About to execute repetition 1 of 10 for repeatedTest
-INFO: About to execute repetition 2 of 10 for repeatedTest
-INFO: About to execute repetition 3 of 10 for repeatedTest
-INFO: About to execute repetition 4 of 10 for repeatedTest
-INFO: About to execute repetition 5 of 10 for repeatedTest
-INFO: About to execute repetition 6 of 10 for repeatedTest
-INFO: About to execute repetition 7 of 10 for repeatedTest
-INFO: About to execute repetition 8 of 10 for repeatedTest
-INFO: About to execute repetition 9 of 10 for repeatedTest
-INFO: About to execute repetition 10 of 10 for repeatedTest
-INFO: About to execute repetition 1 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 2 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 3 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 4 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 5 of 5 for repeatedTestWithRepetitionInfo
-INFO: About to execute repetition 1 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 2 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 3 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 4 of 8 for repeatedTestWithFailureThreshold
-INFO: About to execute repetition 1 of 1 for customDisplayName
-INFO: About to execute repetition 1 of 1 for customDisplayNameWithLongPattern
-INFO: About to execute repetition 1 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 2 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 3 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
-INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
-....
-
-[source,java]
-----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
-----
-
-When using the `ConsoleLauncher` with the unicode theme enabled, execution of
-`RepeatedTestsDemo` results in the following output to the console.
-
-....
-├─ RepeatedTestsDemo ✔
-│  ├─ repeatedTest() ✔
-│  │  ├─ repetition 1 of 10 ✔
-│  │  ├─ repetition 2 of 10 ✔
-│  │  ├─ repetition 3 of 10 ✔
-│  │  ├─ repetition 4 of 10 ✔
-│  │  ├─ repetition 5 of 10 ✔
-│  │  ├─ repetition 6 of 10 ✔
-│  │  ├─ repetition 7 of 10 ✔
-│  │  ├─ repetition 8 of 10 ✔
-│  │  ├─ repetition 9 of 10 ✔
-│  │  └─ repetition 10 of 10 ✔
-│  ├─ repeatedTestWithRepetitionInfo(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 5 ✔
-│  │  ├─ repetition 2 of 5 ✔
-│  │  ├─ repetition 3 of 5 ✔
-│  │  ├─ repetition 4 of 5 ✔
-│  │  └─ repetition 5 of 5 ✔
-│  ├─ repeatedTestWithFailureThreshold(RepetitionInfo) ✔
-│  │  ├─ repetition 1 of 8 ✔
-│  │  ├─ repetition 2 of 8 ✘ Boom!
-│  │  ├─ repetition 3 of 8 ✔
-│  │  ├─ repetition 4 of 8 ✘ Boom!
-│  │  ├─ repetition 5 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 6 of 8 ↷ Failure threshold [2] exceeded
-│  │  ├─ repetition 7 of 8 ↷ Failure threshold [2] exceeded
-│  │  └─ repetition 8 of 8 ↷ Failure threshold [2] exceeded
-│  ├─ Repeat! ✔
-│  │  └─ Repeat! 1/1 ✔
-│  ├─ Details... ✔
-│  │  └─ Details... :: repetition 1 of 1 ✔
-│  └─ repeatedTestInGerman() ✔
-│     ├─ Wiederholung 1 von 5 ✔
-│     ├─ Wiederholung 2 von 5 ✔
-│     ├─ Wiederholung 3 von 5 ✔
-│     ├─ Wiederholung 4 von 5 ✔
-│     └─ Wiederholung 5 von 5 ✔
-....
-
-
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
-
-_Parameterized tests_ make it possible to run a test method multiple times with different
-arguments. They are declared just like regular `@Test` methods but use the
-`{ParameterizedTest}` annotation instead.
-
-_Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
-like regular test classes and may contain any supported test method type (including
-`@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
-
-WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
-provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
-parameterized method or class, respectively.
-
-The following example demonstrates a parameterized test that uses the `@ValueSource`
-annotation to specify a `String` array as the source of arguments.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test method, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-palindromes(String) ✔
-├─ [1] candidate = "racecar" ✔
-├─ [2] candidate = "radar" ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-....
-
-The same `@ValueSource` annotation can be used to specify the source of arguments for a
-`@ParameterizedClass`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
-----
-
-When executing the above parameterized test class, each invocation will be reported
-separately. For instance, the `ConsoleLauncher` will print output similar to the
-following.
-
-....
-PalindromeTests ✔
-├─ [1] candidate = "racecar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-├─ [2] candidate = "radar" ✔
-│  ├─ palindrome() ✔
-│  └─ reversePalindrome() ✔
-└─ [3] candidate = "able was I ere I saw elba" ✔
-   ├─ palindrome() ✔
-   └─ reversePalindrome() ✔
-....
-
-[[writing-tests-parameterized-tests-setup]]
-==== Required Setup
-
-In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
-
-[[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
-
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
-
-Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
-argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
-method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
-Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
-instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
-must declare formal parameters according to the following rules.
-
-* Zero or more _indexed parameters_ must be declared first.
-* Zero or more _aggregators_ must be declared next.
-* Zero or more arguments supplied by a `ParameterResolver` must be declared last.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is passed as an argument to the
-parameterized method at the same index in the method's formal parameter list. An
-_aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
-with `{AggregateWith}`.
-
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
-
-Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
-field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
-or one of its superclasses, field injection will be used. Otherwise, constructor injection
-will be used.
-
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
-
-WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
-with the `PER_CLASS` mode instead.
-
-For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
-above. In the following example, two arguments are injected into the constructor of the
-test class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
-----
-
-You may use _records_ to implement parameterized classes that avoid the boilerplate code
-of declaring a test class constructor.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
-----
-
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
-
-For field injection, the following rules apply for fields annotated with `@Parameter`.
-
-* Zero or more _indexed parameters_ may be declared; each must have a unique index
-  specified in its `@Parameter(index)` annotation. The index may be omitted if there is
-  only one indexed parameter. If there are at least two indexed parameter declarations,
-  there must be declarations for all indexes from 0 to the largest declared index.
-* Zero or more _aggregators_ may be declared; each without specifying an index in its
-  `@Parameter` annotation.
-* Zero or more other fields may be declared as usual as long as they're not annotated with
-  `@Parameter`.
-
-In this context, an _indexed parameter_ is an argument for a given index in the
-`{Arguments}` provided by an `{ArgumentsProvider}` that is injected into a field annotated
-with `@Parameter(index)`. An _aggregator_ is any `@Parameter`-annotated field of type
-{ArgumentsAccessor} or any field annotated with {AggregateWith}.
-
-The following example demonstrates how to use field injection to consume multiple
-arguments in a parameterized class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
-----
-
-If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
-may resolve constructor parameters as usual, though.
-
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
-
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
-be used to consume arguments if their `injectArguments` attribute is set to `true` (the
-default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
-additionally use the same parameter types as the _indexed parameters_ of the parameterized
-test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
-`{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
-example.
-
-[NOTE]
-.AutoCloseable arguments
-====
-Arguments that implement `java.lang.AutoCloseable` (or `java.io.Closeable` which extends
-`java.lang.AutoCloseable`) will be automatically closed after the parameterized class or
-test invocation.
-
-To prevent this from happening, set the `autoCloseArguments` attribute in
-`@ParameterizedTest` to `false`. Specifically, if an argument that implements
-`AutoCloseable` is reused for multiple invocations of the same parameterized class or test
-method, you must specify the `autoCloseArguments = false` on the `{ParameterizedClass}` or
-`{ParameterizedTest}` annotation to ensure that the argument is not closed between
-invocations.
-====
-
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
-
-Other extensions can access the parameters and resolved arguments of a parameterized test
-or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
-Please refer to the Javadoc of `{ParameterInfo}` for details.
-
-[[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
-
-Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
-following subsections provides a brief overview and an example for each of them. Please
-refer to the Javadoc in the `{params-provider-package}` package for additional
-information.
-
-TIP: All source annotations in this section are applicable to both `{ParameterizedClass}`
-and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
-show how to use them with `{ParameterizedTest}` methods.
-
-[[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
-
-`@ValueSource` is one of the simplest possible sources. It lets you specify a single
-array of literal values and can only be used for providing a single argument per
-parameterized test invocation.
-
-The following types of literal values are supported by `@ValueSource`.
-
-- `short`
-- `byte`
-- `int`
-- `long`
-- `float`
-- `double`
-- `char`
-- `boolean`
-- `java.lang.String`
-- `java.lang.Class`
-
-For example, the following `@ParameterizedTest` method will be invoked three times, with
-the values `1`, `2`, and `3` respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
-
-In order to check corner cases and verify proper behavior of our software when it is
-supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
-parameterized tests. The following annotations serve as sources of `null` and empty values
-for parameterized tests that accept a single argument.
-
-* `{NullSource}`: provides a single `null` argument to the annotated `@ParameterizedClass`
-   or `@ParameterizedTest`.
-   - `@NullSource` cannot be used for a parameter that has a primitive type.
-* `{EmptySource}`: provides a single _empty_ argument to the annotated
-  `@ParameterizedClass` or `@ParameterizedTest` for parameters of the following types:
-  `java.lang.String`, `java.util.Collection` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.List`, `java.util.Set`, `java.util.SortedSet`,
-  `java.util.NavigableSet`, `java.util.Map` (and concrete subtypes with a `public` no-arg
-  constructor), `java.util.SortedMap`, `java.util.NavigableMap`, primitive arrays (e.g.,
-  `int[]`, `char[][]`, etc.), object arrays (e.g., `String[]`, `Integer[][]`, etc.).
-* `{NullAndEmptySource}`: a _composed annotation_ that combines the functionality of
-  `@NullSource` and `@EmptySource`.
-
-If you need to supply multiple varying types of _blank_ strings to a parameterized
-class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
-`@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
-
-You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
-range of `null`, _empty_, and _blank_ input. The following example demonstrates how to
-achieve this for strings.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
-----
-
-Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
-follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
-----
-
-NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
-result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
-blank strings supplied via `@ValueSource`.
-
-[[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
-
-`@EnumSource` provides a convenient way to use `Enum` constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
-----
-
-The annotation's `value` attribute is optional. When omitted, the declared type of the
-first parameter is used. The test will fail if it does not reference an enum type.
-Thus, the `value` attribute is required in the above example because the method parameter
-is declared as `TemporalUnit`, i.e. the interface implemented by `ChronoUnit`, which isn't
-an enum type. Changing the method parameter type to `ChronoUnit` allows you to omit the
-explicit enum type from the annotation as follows.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
-----
-
-The annotation provides an optional `names` attribute that lets you specify which
-constants shall be used, like in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
-----
-
-In addition to `names`, you can use the `from` and `to` attributes to specify a range of
-constants. The range starts from the constant specified in the `from` attribute and
-includes all subsequent constants up to and including the one specified in the `to`
-attribute, based on the natural order of the enum constants.
-
-If `from` and `to` attributes are omitted, they default to the first and last constants
-in the enum type, respectively. If all `names`, `from`, and `to` attributes are omitted,
-all constants will be used. The following example demonstrates how to specify a range of
-constants.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
-----
-
-The `@EnumSource` annotation also provides an optional `mode` attribute that enables
-fine-grained control over which constants are passed to the test method. For example, you
-can exclude names from the enum constant pool or specify regular expressions as in the
-following examples.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
-----
-
-You can also combine `mode` with the `from`, `to` and `names` attributes to define a
-range of constants while excluding specific values from that range as shown below.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
-----
-
-[[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
-
-`{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
-or external classes.
-
-Factory methods within the test class must be `static` unless the test class is annotated
-with `@TestInstance(Lifecycle.PER_CLASS)`; whereas, factory methods in external classes
-must always be `static`.
-
-Each factory method must generate a _stream_ of _arguments_, and each set of arguments
-within the stream will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`. Generally speaking this
-translates to a `Stream` of `Arguments` (i.e., `Stream<Arguments>`); however, the actual
-concrete return type can take on many forms. In this context, a "stream" is anything that
-JUnit can reliably convert into a `Stream`, such as `Stream`, `DoubleStream`,
-`LongStream`, `IntStream`, `Collection`, `Iterator`, `Iterable`, an array of objects or
-primitives, or any type that provides an `iterator(): Iterator` method (such as, for
-example, a `kotlin.sequences.Sequence`). The "arguments" within the stream can be supplied
-as an instance of `Arguments`, an array of objects (e.g., `Object[]`), or a single value
-if the parameterized class or test method accepts a single argument.
-
-If the return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-If you only need a single parameter, you can return a `Stream` of instances of the
-parameter type as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
-----
-
-For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
-mandatory. For a `@ParameterizedTest`, if you do not explicitly provide a factory method
-name, JUnit Jupiter will search for a _factory_ method with the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
-----
-
-Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
-supported as demonstrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
-----
-
-If a parameterized class or test method declares multiple parameters, you need to return a
-collection, stream, or array of `Arguments` instances or object arrays as shown below (see
-the Javadoc for `{MethodSource}` for further details on supported return types). Note that
-`arguments(Object...)` is a static factory method defined in the `Arguments` interface. In
-addition, `Arguments.of(Object...)` may be used as an alternative to
-`arguments(Object...)`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
-----
-
-An external, `static` _factory_ method can be referenced by providing its _fully qualified
-method name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-package example;
-
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
-----
-
-Factory methods can declare parameters, which will be provided by registered
-implementations of the `ParameterResolver` extension API. In the following example, the
-factory method is referenced by its name since there is only one such method in the test
-class. If there are several local methods with the same name, parameters can also be
-provided to differentiate them – for example, `@MethodSource("factoryMethod()")` or
-`@MethodSource("factoryMethod(java.lang.String)")`. Alternatively, the factory method
-can be referenced by its fully qualified method name, e.g.
-`@MethodSource("example.MyTests#factoryMethod(java.lang.String)")`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
-
-`{FieldSource}` allows you to refer to one or more fields of the test class or external
-classes.
-
-Fields within the test class must be `static` unless the test class is annotated with
-`@TestInstance(Lifecycle.PER_CLASS)`; whereas, fields in external classes must always be
-`static`.
-
-Each field must be able to supply a _stream_ of arguments, and each set of "arguments"
-within the "stream" will be provided as the physical arguments for individual invocations
-of the annotated `@ParameterizedClass` or `@ParameterizedTest`.
-
-In this context, a "stream" is anything that JUnit can reliably convert to a `Stream`;
-however, the actual concrete field type can take on many forms. Generally speaking this
-translates to a `Collection`, an `Iterable`, a `Supplier` of a stream (`Stream`,
-`DoubleStream`, `LongStream`, or `IntStream`), a `Supplier` of an `Iterator`, an array of
-objects or primitives, or any type that provides an `iterator(): Iterator` method (such
-as, for example, a `kotlin.sequences.Sequence`). Each set of "arguments" within the
-"stream" can be supplied as an instance of `Arguments`, an array of objects (for example,
-`Object[]`, `String[]`, etc.), or a single value if the parameterized class or test method accepts
-a single argument.
-
-[WARNING]
-====
-In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
-methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
-`DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
-are _consumed_ the first time they are processed. However, if you wish to use one of
-these types, you can wrap it in a `Supplier` — for example, `Supplier<IntStream>`.
-====
-
-If the `Supplier` return type is `Stream` or one of the primitive streams,
-JUnit will properly close it by calling `BaseStream.close()`,
-making it safe to use a resource such as `Files.lines()`.
-
-Please note that a one-dimensional array of objects supplied as a set of "arguments" will
-be handled differently than other types of arguments. Specifically, all the elements of a
-one-dimensional array of objects will be passed as individual physical arguments to the
-`@ParameterizedClass` or `@ParameterizedTest`. See the Javadoc for `{FieldSource}` for
-further details.
-
-For a `@ParameterizedClass`, providing a field name via `@FieldSource` is mandatory. For a
-`@ParameterizedTest`, if you do not explicitly provide a field name, JUnit Jupiter will
-search in the test class for a field that has the same name as the current
-`@ParameterizedTest` method by convention. This is demonstrated in the following example.
-This parameterized test method will be invoked twice: with the values `"apple"` and
-`"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide a single explicit field name via
-`@FieldSource`. This parameterized test method will be invoked twice: with the values
-`"apple"` and `"banana"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
-----
-
-The following example demonstrates how to provide multiple explicit field names via
-`@FieldSource`. This example uses the `listOfFruits` field from the previous example as
-well as the `additionalFruits` field. Consequently, this parameterized test method will
-be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
-`"dewberry"`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
-----
-
-It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
-`Iterator` as the source of arguments via a `@FieldSource` field as long as the stream or
-iterator is wrapped in a `java.util.function.Supplier`. The following example demonstrates
-how to provide a `Supplier` of a `Stream` of named arguments. This parameterized test
-method will be invoked twice: with the values `"apple"` and `"banana"` and with display
-names `"Apple"` and `"Banana"`, respectively.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-If a parameterized class or test method declares multiple parameters, the corresponding
-`@FieldSource` field must be able to provide a collection, stream supplier, or array of
-`Arguments` instances or object arrays as shown below (see the Javadoc for `{FieldSource}`
-for further details on supported types).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
-----
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-An external, `static` `@FieldSource` field can be referenced by providing its
-_fully qualified field name_ as demonstrated in the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
-----
-
-[[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
-
-`@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
-`String` literals). Each string provided via the `value` attribute in `@CsvSource`
-represents a CSV record and results in one invocation of the parameterized class or
-test. The first record may optionally be used to supply CSV headers (see the Javadoc for
-the `useHeadersInDisplayName` attribute for details and an example).
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
-----
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-By default, `@CsvSource` uses a single quote (`'`) as its quote character, but this can be
-changed via the `quoteCharacter` attribute. See the `'lemon, lime'` value in the example
-above and in the table below. An empty, quoted value (`''`) results in an empty `String`
-unless the `emptyValue` attribute is set; whereas, an entirely _empty_ value is
-interpreted as a `null` reference. By specifying one or more `nullValues`, a custom value
-can be interpreted as a `null` reference (see the `NIL` example in the table below). An
-`ArgumentConversionException` is thrown if the target type of a `null` reference is a
-primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[cols="50,50"]
-|===
-| Example Input                                                                           | Resulting Argument List
-
-| `@CsvSource({ "apple, banana" })`                                                       | `"apple"`, `"banana"`
-| `@CsvSource({ "apple, 'lemon, lime'" })`                                                | `"apple"`, `"lemon, lime"`
-| `@CsvSource({ "apple, ''" })`                                                           | `"apple"`, `""`
-| `@CsvSource({ "apple, " })`                                                             | `"apple"`, `null`
-| `@CsvSource(value = { "apple, banana, NIL" }, nullValues = "NIL")`                      | `"apple"`, `"banana"`, `null`
-| `@CsvSource(value = { " apple , banana" }, ignoreLeadingAndTrailingWhitespace = false)` | `" apple "`, `" banana"`
-|===
-
-If the programming language you are using supports Java _text blocks_  or equivalent
-multi-line string literals, you can alternatively use the `textBlock` attribute of
-`@CsvSource`. Each record within a text block represents a CSV record and results in one
-invocation of the parameterized class or test. The first record may optionally be used to
-supply CSV headers by setting the `useHeadersInDisplayName` attribute to `true` as in the
-example below.
-
-Using a text block, the previous example can be implemented as follows.
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(useHeadersInDisplayName = true, textBlock = """
-	FRUIT,         RANK
-	apple,         1
-	banana,        2
-	'lemon, lime', 0xF1
-	strawberry,    700_000
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-The generated display names for the previous example include the CSV header names.
-
-----
-[1] FRUIT = "apple", RANK = "1"
-[2] FRUIT = "banana", RANK = "2"
-[3] FRUIT = "lemon, lime", RANK = "0xF1"
-[4] FRUIT = "strawberry", RANK = "700_000"
-----
-
-In contrast to CSV records supplied via the `value` attribute, a text block can contain
-comments. Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be treated as a comment and ignored. Note that there is one exception
-to this rule: if the comment character appears within a quoted field, it loses
-its special meaning.
-
-The comment character must be the first character on the line without any leading
-whitespace. It is therefore recommended that the closing text block delimiter (`"""`)
-be placed either at the end of the last line of input or on the following line,
-left aligned with the rest of the input (as can be seen in the example below which
-demonstrates formatting similar to a table).
-
-[source,java,indent=0]
-----
-@ParameterizedTest
-@CsvSource(delimiter = '|', quoteCharacter = '"', textBlock = """
-	#-----------------------------
-	#    FRUIT     |     RANK
-	#-----------------------------
-	     apple     |      1
-	#-----------------------------
-	     banana    |      2
-	#-----------------------------
-	  "lemon lime" |     0xF1
-	#-----------------------------
-	   strawberry  |    700_000
-	#-----------------------------
-	""")
-void testWithCsvSource(String fruit, int rank) {
-	// ...
-}
-----
-
-[NOTE]
-====
-Java's https://docs.oracle.com/en/java/javase/17/text-blocks/index.html[text block]
-feature automatically removes _incidental whitespace_ when the code is compiled.
-However other JVM languages such as Groovy and Kotlin do not. Thus, if you are using a
-programming language other than Java and your text block contains comments or new lines
-within quoted strings, you will need to ensure that there is no leading whitespace within
-your text block.
-====
-
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
-
-`@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
-local file system. Each record from a CSV file results in one invocation of the
-parameterized class or test. The first record may optionally be used to supply CSV
-headers. You can instruct JUnit to ignore the headers via the `numLinesToSkip` attribute.
-If you would like for the headers to be used in the display names, you can set the
-`useHeadersInDisplayName` attribute to `true`. The examples below demonstrate the use of
-`numLinesToSkip` and `useHeadersInDisplayName`.
-
-The default delimiter is a comma (`,`), but you can use another character by setting the
-`delimiter` attribute. Alternatively, the `delimiterString` attribute allows you to use a
-`String` delimiter instead of a single character. However, both delimiter attributes
-cannot be set simultaneously.
-
-.Comments in CSV files
-NOTE: Any line beginning with the value of the `commentCharacter` attribute (`+++#+++`
-by default) will be interpreted as a comment and will be ignored.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
-----
-
-[source,csv,indent=0]
-.two-column.csv
-----
-include::{testResourcesDir}/two-column.csv[]
-----
-
-The following listing shows the generated display names for the first two parameterized
-test methods above.
-
-----
-[1] country = "Sweden", reference = "1"
-[2] country = "Poland", reference = "2"
-[3] country = "United States of America", reference = "3"
-[4] country = "France", reference = "700_000"
-----
-
-The following listing shows the generated display names for the last parameterized test
-method above that uses CSV header names.
-
-----
-[1] COUNTRY = "Sweden", REFERENCE = "1"
-[2] COUNTRY = "Poland", REFERENCE = "2"
-[3] COUNTRY = "United States of America", REFERENCE = "3"
-[4] COUNTRY = "France", REFERENCE = "700_000"
-----
-
-In contrast to the default syntax used in `@CsvSource`, `@CsvFileSource` uses a double
-quote (`+++"+++`) as the quote character by default, but this can be changed via the
-`quoteCharacter` attribute. See the `"United States of America"` value in the example
-above. An empty, quoted value (`+++""+++`) results in an empty `String` unless the
-`emptyValue` attribute is set; whereas, an entirely _empty_ value is interpreted as a
-`null` reference. By specifying one or more `nullValues`, a custom value can be
-interpreted as a `null` reference. An `ArgumentConversionException` is thrown if the
-target type of a `null` reference is a primitive type.
-
-NOTE: An _unquoted_ empty value will always be converted to a `null` reference regardless
-of any custom values configured via the `nullValues` attribute.
-
-Except within a quoted string, leading and trailing whitespace in a CSV column is trimmed
-by default. This behavior can be changed by setting the
-`ignoreLeadingAndTrailingWhitespace` attribute to `true`.
-
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
-
-`@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
-that an implementation of `ArgumentsProvider` must be declared as either a top-level
-class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
-----
-
-If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
-(like built-in providers such as `{ValueArgumentsProvider}` or `{CsvArgumentsProvider}`),
-you have the possibility to extend the `{AnnotationBasedArgumentsProvider}` class.
-
-Moreover, `ArgumentsProvider` implementations may declare constructor parameters in case
-they need to be resolved by a registered `ParameterResolver` as demonstrated in the
-following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
-----
-
-[[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
-
-Repeatable annotations provide a convenient way to specify multiple sources from
-different providers.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
-----
-
-Following the above parameterized test, a test case will run for each argument:
-
-----
-[1] foo
-[2] bar
-----
-
-The following annotations are repeatable:
-
-* `@ValueSource`
-* `@EnumSource`
-* `@MethodSource`
-* `@FieldSource`
-* `@CsvSource`
-* `@CsvFileSource`
-* `@ArgumentsSource`
-
-[[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
-
-By default, when an arguments source provides more arguments than the test method needs,
-those additional arguments are ignored and the test executes as usual.
-This can lead to bugs where arguments are never passed to the parameterized class or
-method.
-
-To prevent this, you can set argument count validation to 'strict'.
-Then, any additional arguments will cause an error instead.
-
-To change this behavior for all tests, set the
-`junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
-To change this behavior for a single parameterized class or test method,
-use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
-`@ParameterizedTest` annotation:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
-
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
-
-JUnit Jupiter supports
-https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
-Conversion] for arguments supplied to a `@ParameterizedClass` or `@ParameterizedTest`.
-For example, a parameterized class or test method annotated with
-`@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
-`int` but also an argument of type `long`, `float`, or `double`.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
-
-To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
-implicit type converters. The conversion process depends on the declared type of each
-method parameter.
-
-For example, if a `@ParameterizedClass` or `@ParameterizedTest` declares a parameter
-of type `TimeUnit` and the actual type supplied by the declared source is a `String`, the
-string will be automatically converted into the corresponding `TimeUnit` enum constant.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
-----
-
-`String` instances are implicitly converted to the following target types.
-
-NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
-integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
-[cols="10,90"]
-|===
-| Target Type | Example
-
-| `boolean`/`Boolean`        | `"true"`                                 -> `true` _(only accepts values 'true' or 'false', case-insensitive)_
-| `byte`/`Byte`              | `"15"`, `"0xF"`, or `"017"`              -> `(byte) 15`
-| `char`/`Character`         | `"o"`                                    -> `'o'`
-| `short`/`Short`            | `"15"`, `"0xF"`, or `"017"`              -> `(short) 15`
-| `int`/`Integer`            | `"15"`, `"0xF"`, or `"017"`              -> `15`
-| `long`/`Long`              | `"15"`, `"0xF"`, or `"017"`              -> `15L`
-| `float`/`Float`            | `"1.0"`                                  -> `1.0f`
-| `double`/`Double`          | `"1.0"`                                  -> `1.0d`
-| `Enum` subclass            | `"SECONDS"`                              -> `TimeUnit.SECONDS`
-| `java.io.File`             | `"/path/to/file"`                        -> `new File("/path/to/file")`
-| `java.lang.Class`          | `"java.lang.Integer"`                    -> `java.lang.Integer.class` _(use `$` for nested classes, e.g. `"java.lang.Thread$State"`)_
-| `java.lang.Class`          | `"byte"`                                 -> `byte.class` _(primitive types are supported)_
-| `java.lang.Class`          | `"char[]"`                               -> `char[].class` _(array types are supported)_
-| `java.math.BigDecimal`     | `"123.456e789"`                          -> `new BigDecimal("123.456e789")`
-| `java.math.BigInteger`     | `"1234567890123456789"`                  -> `new BigInteger("1234567890123456789")`
-| `java.net.URI`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/")`
-| `java.net.URL`             | `"https://junit.org/"`                   -> `URI.create("https://junit.org/").toURL()`
-| `java.nio.charset.Charset` | `"UTF-8"`                                -> `Charset.forName("UTF-8")`
-| `java.nio.file.Path`       | `"/path/to/file"`                        -> `Paths.get("/path/to/file")`
-| `java.time.Duration`       | `"PT3S"`                                 -> `Duration.ofSeconds(3)`
-| `java.time.Instant`        | `"1970-01-01T00:00:00Z"`                 -> `Instant.ofEpochMilli(0)`
-| `java.time.LocalDateTime`  | `"2017-03-14T12:34:56.789"`              -> `LocalDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000)`
-| `java.time.LocalDate`      | `"2017-03-14"`                           -> `LocalDate.of(2017, 3, 14)`
-| `java.time.LocalTime`      | `"12:34:56.789"`                         -> `LocalTime.of(12, 34, 56, 789_000_000)`
-| `java.time.MonthDay`       | `"--03-14"`                              -> `MonthDay.of(3, 14)`
-| `java.time.OffsetDateTime` | `"2017-03-14T12:34:56.789Z"`             -> `OffsetDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.OffsetTime`     | `"12:34:56.789Z"`                        -> `OffsetTime.of(12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.Period`         | `"P2M6D"`                                -> `Period.of(0, 2, 6)`
-| `java.time.YearMonth`      | `"2017-03"`                              -> `YearMonth.of(2017, 3)`
-| `java.time.Year`           | `"2017"`                                 -> `Year.of(2017)`
-| `java.time.ZonedDateTime`  | `"2017-03-14T12:34:56.789Z"`             -> `ZonedDateTime.of(2017, 3, 14, 12, 34, 56, 789_000_000, ZoneOffset.UTC)`
-| `java.time.ZoneId`         | `"Europe/Berlin"`                        -> `ZoneId.of("Europe/Berlin")`
-| `java.time.ZoneOffset`     | `"+02:30"`                               -> `ZoneOffset.ofHoursMinutes(2, 30)`
-| `java.util.Currency`       | `"JPY"`                                  -> `Currency.getInstance("JPY")`
-| `java.util.Locale`         | `"en-US"`                                -> `Locale.forLanguageTag("en-US")`
-| `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
-|===
-
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
-
-In addition to implicit conversion from strings to the target types listed in the above
-table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
-`String` to a given target type if the target type declares exactly one suitable _factory
-method_ or a _factory constructor_ as defined below.
-
-- __factory method__: a non-private, `static` method declared in the target type that
-  accepts either a single `String` argument or a single `CharSequence` argument and
-  returns an instance of the target type. The name of the method can be arbitrary and need
-  not follow any particular convention.
-- __factory constructor__: a non-private constructor in the target type that accepts a
-  either a single `String` argument or a single `CharSequence` argument. Note that the
-  target type must be declared as either a top-level class or as a `static` nested class.
-
-NOTE: If multiple _factory methods_ are discovered, they will be ignored. If a _factory
-method_ and a _factory constructor_ are discovered, the factory method will be used
-instead of the constructor.
-
-For example, in the following `@ParameterizedTest` method, the `Book` argument will be
-created by invoking the `Book.fromTitle(String)` factory method and passing `"42 Cats"`
-as the title of the book.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
-----
-
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
-
-Instead of relying on implicit argument conversion, you may explicitly specify an
-`ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
-like in the following example. Note that an implementation of `ArgumentConverter` must be
-declared as either a top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
-----
-
-If the converter is only meant to convert one type to another, you can extend
-`TypedArgumentConverter` to avoid boilerplate type checks.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
-----
-
-Explicit argument converters are meant to be implemented by test and extension authors.
-Thus, `junit-jupiter-params` only provides a single explicit argument converter that may
-also serve as a reference implementation: `JavaTimeArgumentConverter`. It is used via the
-composed annotation `JavaTimeConversionPattern`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
-----
-
-If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
-(like `JavaTimeArgumentConverter`), you have the possibility to extend the
-`{AnnotationBasedArgumentConverter}` class.
-
-[[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
-
-By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
-corresponds to a single method parameter. Consequently, argument sources which are
-expected to supply a large number of arguments can lead to large constructor or method
-signatures, respectively.
-
-In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
-this API, you can access the provided arguments through a single argument passed to your
-test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
-
-Besides, you can retrieve the current test invocation index with
-`ArgumentsAccessor.getInvocationIndex()`.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
-----
-
-_An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
-`ArgumentsAccessor`._
-
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
-
-Apart from direct access to the arguments of a `@ParameterizedClass` or
-`@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
-of custom, reusable _aggregators_.
-
-To use a custom aggregator, implement the `{ArgumentsAggregator}` interface and register
-it via the `@AggregateWith` annotation on a compatible parameter of the
-`@ParameterizedClass` or `@ParameterizedTest`. The result of the aggregation will then be
-provided as an argument for the corresponding parameter when the parameterized test is
-invoked. Note that an implementation of `ArgumentsAggregator` must be declared as either a
-top-level class or as a `static` nested class.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
-----
-
-If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
-multiple parameterized classes or methods across your codebase, you may wish to create a
-custom _composed annotation_ such as `@CsvToMyType` that is meta-annotated with
-`@AggregateWith(MyTypeAggregator.class)`. The following example demonstrates this in
-action with a custom `@CsvToPerson` annotation.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
-----
-
-
-[[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
-
-By default, the display name of a parameterized class or test invocation contains the
-invocation index and a comma-separated list of the `String` representations of all
-arguments for that specific invocation. If parameter names are present in the bytecode,
-each argument will be preceded by its parameter name and an equals sign (unless the
-argument is only available via an `ArgumentsAccessor` or `ArgumentAggregator`) – for
-example, `firstName = "Jane"`.
-
-[TIP]
-====
-To ensure that parameter names are present in the bytecode, test code must be compiled
-with the `-parameters` compiler flag for Java or with the `-java-parameters` compiler flag
-for Kotlin.
-====
-
-However, you can customize invocation display names via the `name` attribute of the
-`@ParameterizedClass` or `@ParameterizedTest` annotation as in the following example.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-Display name of container ✔
-├─ 1 ==> the rank of "apple" is "1" ✔
-├─ 2 ==> the rank of "banana" is "2" ✔
-└─ 3 ==> the rank of "lemon, lime" is "3" ✔
-....
-======
-
-[NOTE]
-====
-Please note that `name` is a `MessageFormat` pattern. Thus, a single quote (`'`) needs to
-be represented as a doubled single quote (`''`) in order to be displayed.
-====
-
-The following placeholders are supported within custom display names.
-
-[cols="20,80"]
-|===
-| Placeholder                              | Description
-
-| `\{displayName}`                         | the display name of the method
-| `\{index}`                               | the current invocation index (1-based)
-| `\{arguments}`                           | the complete, comma-separated arguments list
-| `\{argumentsWithNames}`                  | the complete, comma-separated arguments list with parameter names
-| `\{argumentSetName}`                     | the name of the argument set
-| `\{argumentSetNameOrArgumentsWithNames}` | `\{argumentSetName}` or `\{argumentsWithNames}`, depending on how the arguments are supplied
-| `\{0}`, `\{1}`, ...                      | an individual argument
-|===
-
-NOTE: When including arguments in display names, their string representations are truncated
-if they exceed the configured maximum length. The limit is configurable via the
-`junit.jupiter.params.displayname.argument.maxlength` configuration parameter and defaults
-to 512 characters.
-
-When using `@MethodSource`, `@FieldSource`, or `@ArgumentsSource`, you can provide custom
-names for individual arguments or custom names for entire sets of arguments.
-
-Use the `{Named}` API to provide a custom name for an individual argument, and the custom
-name will be used if the argument is included in the invocation display name, like in the
-example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named arguments ✔
-├─ 1: An important file ✔
-└─ 2: Another file ✔
-....
-======
-
-[NOTE]
-====
-Note that `arguments(Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-
-Similarly, `named(String, Object)` is a static factory method defined in the
-`org.junit.jupiter.api.Named` interface.
-====
-
-Use the `ArgumentSet` API to provide a custom name for the entire set of arguments, and
-the custom name will be used as the display name, like in the example below.
-
-======
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
-----
-
-When executing the above method using the `ConsoleLauncher` you will see output similar to
-the following.
-
-....
-A parameterized test with named argument sets ✔
-├─ [1] Important files ✔
-└─ [2] Other files ✔
-....
-======
-
-[NOTE]
-====
-Note that `argumentSet(String, Object...)` is a static factory method defined in the
-`org.junit.jupiter.params.provider.Arguments` interface.
-====
-
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
-
-As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
-quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
-is considered text. A `CharSequence` is wrapped in double quotes (`"`), and a `Character`
-is wrapped in single quotes (`'`).
-
-Special characters will be escaped in the quoted text. For example, carriage returns and
-line feeds will be escaped as `\\r` and `\\n`, respectively.
-
-[TIP]
-====
-This feature can be disabled by setting the `quoteTextArguments` attributes in
-`@ParameterizedClass` and `@ParameterizedTest` to `false`.
-====
-
-For example, given a string argument `"line 1\nline 2"`, the physical representation in
-the display name will be `"\"line 1\\nline 2\""` which is printed as `"line 1\nline 2"`.
-Similarly, given a string argument `"\t"`, the physical representation in the display name
-will be `"\"\\t\""` which is printed as `"\t"` instead of a blank string or invisible tab
-character. The same applies for a character argument `'\t'`, whose physical representation
-in the display name would be `"'\\t'"` which is printed as `'\t'`.
-
-For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
-parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
-display names are generated.
-
-----
-[1] text = null
-[2] text = ""
-[3] text = " "
-[4] text = "   "
-[5] text = "\t"
-[6] text = "\n"
-----
-
-If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
-following display names are generated.
-
-----
-[1] fruit = "apple", rank = "1"
-[2] fruit = "banana", rank = "2"
-[3] fruit = "lemon, lime", rank = "0xF1"
-[4] fruit = "strawberry", rank = "700_000"
-----
-
-[NOTE]
-====
-The original source arguments are quoted when generating a display name, and this occurs
-before any implicit or explicit argument conversion is performed.
-
-For example, if a parameterized test accepts `3.14` as a `float` argument that was
-converted from `"3.14"` as an input string, `"3.14"` will be present in the display name
-instead of `3.14`. You can see the effect of this with the `rank` values in the above
-example.
-====
-
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
-
-If you'd like to set a default name pattern for all parameterized classes and tests in
-your project, you can declare the `junit.jupiter.params.displayname.default` configuration
-parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
-
-[source,properties,indent=0]
-----
-junit.jupiter.params.displayname.default = {index}
-----
-
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
-
-The display name for a parameterized class or test is determined according to the
-following precedence rules:
-
-1. `name` attribute in `@ParameterizedClass` or `@ParameterizedTest`, if present
-2. value of the `junit.jupiter.params.displayname.default` configuration parameter, if present
-3. `DEFAULT_DISPLAY_NAME` constant defined in
-   `org.junit.jupiter.params.ParameterizedInvocationConstants`
-
-[[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
-
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
-
-Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
-method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
-test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
-methods within the same test class.
-
-You may use `ParameterResolver` extensions with `@ParameterizedTest` methods. However,
-method parameters that are resolved by argument sources need to come first in the
-parameter list. Since a test class may contain regular tests as well as parameterized
-tests with different parameter lists, values from argument sources are not resolved for
-lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
-----
-
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
-
-Each invocation of a parameterized class has the same lifecycle as a regular test class.
-For example, `@BeforeAll` methods will be executed _once_ before all invocations and
-`@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
-IDE.
-
-You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
-However, if constructor injection is used, constructor parameters that are resolved by
-argument sources need to come first in the parameter list. Values from argument sources
-are not resolved for regular lifecycle methods (e.g. `@BeforeEach`).
-
-In addition to regular lifecycle methods, parameterized classes may declare
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
-methods that are called once before/after each invocation of the parameterized class.
-These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
-
-These lifecycle methods may optionally declare parameters that are resolved depending on
-the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
-parameters must be resolved by other registered {ParameterResolver} extensions. If the
-attribute is set to `true` (the default), the method may declare parameters that match the
-arguments of the parameterized class (see the Javadoc of
-`{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` for
-details). This may, for example, be used to initialize the used arguments as demonstrated
-by the following example.
-
-[source,java,indent=0]
-.Using parameterized class lifecycle methods
-----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
-----
-<1> Initialization of the argument _before_ each invocation of the parameterized class
-<2> Usage of the previously initialized argument in a test method
-<3> Validation and cleanup of the argument _after_ each invocation of the parameterized
-    class
-
-[[writing-tests-class-templates]]
-=== Class Templates
-
-A `{ClassTemplate}` is not a regular test class but rather a template for the contained
-test cases. As such, it is designed to be invoked multiple times depending on invocation
-contexts returned by the registered providers. Thus, it must be used in conjunction with a
-registered `{ClassTemplateInvocationContextProvider}` extension.
-Each invocation of a class template behaves like the execution of a regular test class
-with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
-
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
-specialization of class templates.
-
-[[writing-tests-test-templates]]
-=== Test Templates
-
-A `{TestTemplate}` method is not a regular test case but rather a template for a test
-case. As such, it is designed to be invoked multiple times depending on the number of
-invocation contexts returned by the registered providers. Thus, it must be used in
-conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
-invocation of a test template method behaves like the execution of a regular `@Test`
-method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
-
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
-test templates.
-
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
-
-The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
-describe methods that implement test cases. These test cases are static in the sense that
-they are fully specified at compile time, and their behavior cannot be changed by
-anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
-are intentionally rather limited in their expressiveness._
-
-In addition to these standard tests a completely new kind of test programming model has
-been introduced in JUnit Jupiter. This new kind of test is a _dynamic test_ which is
-generated at runtime by a factory method that is annotated with `@TestFactory`.
-
-In contrast to `@Test` methods, a `@TestFactory` method is not itself a test case but
-rather a factory for test cases. Thus, a dynamic test is the product of a factory.
-Technically speaking, a `@TestFactory` method must return a single `DynamicNode` or a
-_stream_ of `DynamicNode` instances or any of its subclasses. In this context, a "stream"
-is anything that JUnit can reliably convert into a `Stream`, such as `Stream`,
-`Collection`, `Iterator`, `Iterable`, an array of objects, or any type that provides an
-`iterator(): Iterator` method (such as, for example, a `kotlin.sequences.Sequence`).
-
-Instantiable subclasses of `DynamicNode` are `DynamicContainer` and `DynamicTest`.
-`DynamicContainer` instances are composed of a _display name_ and a list of dynamic child
-nodes, enabling the creation of arbitrarily nested hierarchies of dynamic nodes.
-`DynamicTest` instances will be executed lazily, enabling dynamic and even
-non-deterministic generation of test cases.
-
-Any `Stream` returned by a `@TestFactory` will be properly closed by calling
-`stream.close()`, making it safe to use a resource such as `Files.lines()`.
-
-As with `@Test` methods, `@TestFactory` methods must not be `private` or `static` and may
-optionally declare parameters to be resolved by `ParameterResolvers`.
-
-A `DynamicTest` is a test case generated at runtime. It is composed of a _display name_
-and an `Executable`. `Executable` is a `@FunctionalInterface` which means that the
-implementations of dynamic tests can be provided as _lambda expressions_ or _method
-references_.
-
-.Dynamic Test Lifecycle
-WARNING: The execution lifecycle of a dynamic test is quite different than it is for a
-standard `@Test` case. Specifically, there are no lifecycle callbacks for individual
-dynamic tests. This means that `@BeforeEach` and `@AfterEach` methods and their
-corresponding extension callbacks are executed for the `@TestFactory` method but not for
-each _dynamic test_. In other words, if you access fields from the test instance within a
-lambda expression for a dynamic test, those fields will not be reset by callback methods
-or extensions between the execution of individual dynamic tests generated by the same
-`@TestFactory` method.
-
-[[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
-
-The following `DynamicTestsDemo` class demonstrates several examples of test factories
-and dynamic tests.
-
-The first method returns an invalid return type and will cause a warning to be reported by
-JUnit during test discovery. Such methods are not executed.
-
-The next six methods demonstrate the generation of a `Collection`, `Iterable`, `Iterator`,
-array, or `Stream` of `DynamicTest` instances. Most of these examples do not really
-exhibit dynamic behavior but merely demonstrate the supported return types in principle.
-However, `dynamicTestsFromStream()` and `dynamicTestsFromIntStream()` demonstrate how to
-generate dynamic tests for a given set of strings or a range of input numbers.
-
-The next method is truly dynamic in nature. `generateRandomNumberOfTests()` implements an
-`Iterator` that generates random numbers, a display name generator, and a test executor
-and then provides all three to `DynamicTest.stream()`. Although the non-deterministic
-behavior of `generateRandomNumberOfTests()` is of course in conflict with test
-repeatability and should thus be used with care, it serves to demonstrate the
-expressiveness and power of dynamic tests.
-
-The next method is similar to `generateRandomNumberOfTests()` in terms of flexibility;
-however, `dynamicTestsFromStreamFactoryMethod()` generates a stream of dynamic tests from
-an existing `Stream` via the `DynamicTest.stream()` factory method.
-
-For demonstration purposes, the `dynamicNodeSingleTest()` method generates a single
-`DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
-a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
-
-In some cases, it can be more natural to specify inputs together with a descriptive name
-using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
-shown in the first example below. The second example takes it one step further and allows
-to provide the code block that should be executed by implementing the `Executable`
-interface along with `Named` via the `NamedExecutable` base class.
-
-[source,java]
-----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
-----
-
-[[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
-
-The JUnit Platform provides `TestSource`, a representation of the source of a test or
-container used to navigate to its location by IDEs and build tools.
-
-The `TestSource` for a dynamic test or dynamic container can be constructed from a
-`java.net.URI` which can be supplied via the `DynamicTest.dynamicTest(String, URI,
-Executable)` or `DynamicContainer.dynamicContainer(String, URI, Stream)` factory method,
-respectively. The `URI` will be converted to one of the following `TestSource`
-implementations.
-
-`ClasspathResourceSource` ::
-  If the `URI` contains the `classpath` scheme -- for example,
-  `classpath:/test/foo.xml?line=20,column=2`.
-
-`DirectorySource` ::
-  If the `URI` represents a directory present in the file system.
-
-`FileSource` ::
-  If the `URI` represents a file present in the file system.
-
-`MethodSource` ::
-  If the `URI` contains the `method` scheme and the fully qualified method name (FQMN) --
-  for example, `method:org.junit.Foo#bar(java.lang.String, java.lang.String[])`. Please
-  refer to the Javadoc for `{DiscoverySelectors}.{DiscoverySelectors_selectMethod}` for the
-  supported formats for a FQMN.
-
-`ClassSource` ::
-  If the `URI` contains the `class` scheme and the fully qualified class name --
-  for example, `class:org.junit.Foo?line=42`.
-
-`UriSource` ::
-  If none of the above `TestSource` implementations are applicable.
-
-[[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
-
-Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
-`ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
-factory methods as illustrated by the following example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
-----
-
-Executing the above test factory method results in the following test tree and execution
-modes:
-
-* dynamicTestsWithConfiguredExecutionMode() -- `CONCURRENT` (from `@Execution` annotation)
-** Container A -- `CONCURRENT` (from `@Execution` annotation)
-*** not null -- `SAME_THREAD` (from `executionMode(...)` call)
-*** properties -- `CONCURRENT` (from `@Execution` annotation)
-**** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
-**** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
-** ... (same for "Container B" and "Container C")
-
 [[writing-tests-declarative-timeouts]]
 === Timeouts
 
@@ -3288,653 +160,3 @@ with `-agentlib:jdwp` or `-Xrunjdwp`.
 This heuristic is queried by the `disabled_on_debug` mode.
 
 
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
-
-By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
-tests in parallel -- for example, to speed up execution -- is available as an opt-in
-feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
-configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
-
-Please note that enabling this property is only the first step required to execute tests
-in parallel. If enabled, test classes and methods will still be executed sequentially by
-default. Whether or not a node in the test tree is executed concurrently is controlled by
-its execution mode. The following two modes are available.
-
-`SAME_THREAD`::
-  Force execution in the same thread used by the parent. For example, when used on a test
-  method, the test method will be executed in the same thread as any `@BeforeAll` or
-  `@AfterAll` methods of the containing test class.
-
-`CONCURRENT`::
-  Execute concurrently unless a resource lock forces execution in the same thread.
-
-By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
-the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
-parameter. Alternatively, you can use the `{Execution}` annotation to change the
-execution mode for the annotated element and its subelements (if any) which allows you to
-activate parallel execution for individual test classes, one by one.
-
-[source,properties]
-.Configuration parameters to execute all tests in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-----
-
-The default execution mode is applied to all nodes of the test tree with a few notable
-exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
-`{MethodOrderer}`. In the former case, test authors have to ensure that the test class is
-thread-safe; in the latter, concurrent execution might conflict with the configured
-execution order. Thus, in both cases, test methods in such test classes are only executed
-concurrently if the `@Execution(CONCURRENT)` annotation is present on the test class or
-method.
-
-You can use the `@Execution` annotation to explicitly configure the execution mode for a
-test class or method:
-
-[source,java]
-----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
-----
-
-This allows test classes or methods to opt in or out of concurrent execution regardless of
-the globally configured default.
-
-When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
-initially be sorted accordingly and scheduled in that order. However, they are not
-guaranteed to be started in exactly that order since the threads they are executed on are
-not controlled directly by JUnit.
-
-All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
-be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
-separately.
-
-In addition, you can configure the default execution mode for top-level classes by setting
-the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter. By
-combining both configuration parameters, you can configure classes to run in parallel but
-their methods in the same thread:
-
-[source,properties]
-.Configuration parameters to execute top-level classes in parallel but methods in same thread
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = same_thread
-junit.jupiter.execution.parallel.mode.classes.default = concurrent
-----
-
-The opposite combination will run all methods within one class in parallel, but top-level
-classes will run sequentially:
-
-[source,properties]
-.Configuration parameters to execute top-level classes sequentially but their methods in parallel
-----
-junit.jupiter.execution.parallel.enabled = true
-junit.jupiter.execution.parallel.mode.default = concurrent
-junit.jupiter.execution.parallel.mode.classes.default = same_thread
-----
-
-The following diagram illustrates how the execution of two top-level test classes `A` and
-`B` with two test methods per class behaves for all four combinations of
-`junit.jupiter.execution.parallel.mode.default` and
-`junit.jupiter.execution.parallel.mode.classes.default` (see labels in first column).
-
-////
-Source: https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqFlE1u2zAQha9CEChio7IQKfVGXfUH_QEatICyKAIBwYQaW0QkUiDHhV3X2x4gvWFPUlKUbTmpEq2kN2-GHx403HKhS-QZn81mhSqlbWvYXDopY0I3LQgqVFcq1BIUuS_mnhIIP2jTALHvQYG1tL3ywgaJpLj7rAjND6hZsteoRvb39x9GlUEoLfvltMZL9_4M77EoSGrFJhYavAm-iA0-psH3Jia0lEymLANrk4idR_tjQintS2nEYOE4WLClwfP22H7b6QeP818MPWnvOcwJ_ldPAwutxMoYVPQ_XjHOKwa8YoT3tP0EUwww-_YHmEey52IV47EKH8dDhEAnBmmKR4mnvScdeNLnMJ8MU4yHKcQ45XiGgy4e8Qbdby1LtyNbby04VdhgwTP3qnBFBuqCR6EUdsSVtmFqwWtc0DcoS6mWXk_TebQv3YL5CK1Xk_ODuDSy_CIV5gRm2DiwuL5PKJdVd9DFUV9oRbn82aElc6_uogHxuzwP0DGBvbvCtcs17tO-6vZyy_yI2QIaWW8ydva1RcVyUPbsdahYNz1L5u2a7VjsSVnst5yRG-a6--sjU1rhqSNTVM1EJetykqqXyfSRueCF2rmwYUU63yjBMzIrjPiq9XfNewlLAw3PFlBbp2IpSZvLcHN1F1jEW1DXWu89u3-YPX1X
-
----
-displayMode: compact
----
-
-gantt
-    dateFormat X
-    axisFormat %s
-    tickInterval 1
-    title ↓ threads | time →
-
-    section (same_thread, same_thread)
-    A.test1() :ass1, 0, 1
-    A.test2() :ass2, after ass1, 2
-    B.test1() :bss1, after ass2, 3
-    B.test2() :bss2, after bss1, 4
-
-    section (same_thread, concurrent)
-    A.test1() :asc1, 0, 1
-    A.test2() :asc2, after asc1, 2
-    B.test1() :bsc1, 0, 1
-    B.test2() :bsc2, after bsc1, 2
-
-    section (concurrent, same_thread)
-    A.test1() :acs1, 0, 1
-    A.test2() :acs2, 0, 1
-    B.test1() :bcs1, after acs1, 2
-    B.test2() :bcs2, after acs2, 2
-
-    section (concurrent, concurrent)
-    A.test1() :acc1, 0, 1
-    A.test2() :acc2, 0, 1
-    B.test1() :bcc1, 0, 1
-    B.test2() :bcc2, 0, 1
-
-////
-image::writing-tests_execution_mode.svg[caption='',title='Default execution mode configuration combinations']
-
-If the `junit.jupiter.execution.parallel.mode.classes.default` configuration parameter is
-not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
-used instead.
-
-[[writing-tests-parallel-execution-config]]
-==== Configuration
-
-[[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
-
-If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
-concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
-is used be setting the `junit.jupiter.execution.parallel.config.executor-service`
-configuration parameter to one of the following options:
-
-`fork_join_pool` (default)::
-Use an executor service that is backed by a `ForkJoinPool` from the JDK. This will cause
-tests to be executed in a `ForkJoinWorkerThread`. In some cases, usages of
-`ForkJoinPool` in test or production code or calls to blocking JDK APIs may cause the
-number of concurrently executing tests to increase. To avoid this situation, please use
-`worker_thread_pool`.
-
-`worker_thread_pool` (experimental)::
-Use an executor service that is backed by a regular thread pool and does not create
-additional threads if test or production code uses `ForkJoinPool` or calls a blocking
-API in the JDK.
-
-WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
-to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
-
-[[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
-
-Properties such as the desired parallelism and the maximum pool size can be configured
-using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
-implementations out of the box: `dynamic` and `fixed`. Alternatively, you may implement a
-`custom` strategy.
-
-To select a strategy, set the `junit.jupiter.execution.parallel.config.strategy`
-configuration parameter to one of the following options.
-
-`dynamic`::
-  Computes the desired parallelism based on the number of available processors/cores
-  multiplied by the `junit.jupiter.execution.parallel.config.dynamic.factor`
-  configuration parameter (defaults to `1`).
-  The optional `junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`fixed`::
-  Uses the mandatory `junit.jupiter.execution.parallel.config.fixed.parallelism`
-  configuration parameter as the desired parallelism.
-  The optional `junit.jupiter.execution.parallel.config.fixed.max-pool-size`
-  configuration parameter can be used to limit the maximum number of threads.
-
-`custom`::
-  Allows you to specify a custom `{ParallelExecutionConfigurationStrategy}`
-  implementation via the mandatory `junit.jupiter.execution.parallel.config.custom.class`
-  configuration parameter to determine the desired configuration.
-
-If no configuration strategy is set, JUnit Jupiter uses the `dynamic` configuration
-strategy with a factor of `1`. Consequently, the desired parallelism will be equal to the
-number of available processors/cores.
-
-.Parallelism alone does not imply maximum number of concurrent threads
-NOTE: By default, JUnit Jupiter does not guarantee that the number of threads used to
-execute test will not exceed the configured parallelism. For example, when using one
-of the synchronization mechanisms described in the next section, the executor service
-implementation may spawn additional threads to ensure execution continues with sufficient
-parallelism. If you require such guarantees, it is possible to limit the maximum number of
-threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
-strategies.
-
-[[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
-
-The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
-
-====== General
-
-`junit.jupiter.execution.parallel.enabled=true|false`::
-  Enable/disable parallel test execution (defaults to `false`).
-
-`junit.jupiter.execution.parallel.mode.default=concurrent|same_thread`::
-  Default execution mode of nodes in the test tree (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.mode.classes.default=concurrent|same_thread`::
-  Default execution mode of top-level classes (defaults to `same_thread`).
-
-`junit.jupiter.execution.parallel.config.executor-service=fork_join_pool|worker_thread_pool`::
-  Type of `HierarchicalTestExecutorService` to use for parallel execution (defaults to
-  `fork_join_pool`).
-
-`junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
-  Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
-
-====== Dynamic strategy
-
-`junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores to determine the
-  desired parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number (defaults to `1.0`).
-
-`junit.jupiter.execution.parallel.config.dynamic.max-pool-size-factor=decimal`::
-  Factor to be multiplied by the number of available processors/cores and the value of
-  `junit.jupiter.execution.parallel.config.dynamic.factor` to determine the desired
-  parallelism for the ```dynamic``` configuration strategy.
-  Must be a positive decimal number greater than or equal to `1.0` (defaults to 256 plus
-  the value of `junit.jupiter.execution.parallel.config.dynamic.factor` multiplied by the
-  number of available processors/cores)
-
-`junit.jupiter.execution.parallel.config.dynamic.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```dynamic```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Fixed strategy
-
-`junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
-  Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
-  be a positive integer.
-
-`junit.jupiter.execution.parallel.config.fixed.max-pool-size=integer`::
-  Desired maximum pool size of the underlying fork-join pool for the ```fixed```
-  configuration strategy. Must be a positive integer greater than or equal to
-  `junit.jupiter.execution.parallel.config.fixed.parallelism` (defaults to 256 plus the
-  value of `junit.jupiter.execution.parallel.config.fixed.parallelism`).
-
-`junit.jupiter.execution.parallel.config.fixed.saturate=true|false`::
-  Enable/disable saturation of the underlying `ForkJoinPool` for the ```fixed```
-  configuration strategy (defaults to `true`). Only used if
-  `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
-
-====== Custom strategy
-
-`junit.jupiter.execution.parallel.config.custom.class=classname`::
-  Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
-  for the ```custom``` configuration strategy (no default value).
-
-[[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
-
-In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
-Jupiter provides another annotation-based declarative synchronization mechanism. The
-`{ResourceLock}` annotation allows you to declare that a test class or method uses a
-specific shared resource that requires synchronized access to ensure reliable test
-execution. The shared resource is identified by a unique name which is a `String`. The
-name can be user-defined or one of the predefined constants in `{Resources}`:
-`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, `SYSTEM_ERR`, `LOCALE`, or `TIME_ZONE`.
-
-In addition to declaring these shared resources statically, the `{ResourceLock}`
-annotation has a `providers` attribute that allows registering implementations of the
-`{ResourceLocksProvider}` interface that can add shared resources dynamically at runtime.
-Note that resources declared statically with `{ResourceLock}` annotation are combined with
-resources added dynamically by `{ResourceLocksProvider}` implementations.
-
-If the tests in the following example were run in parallel _without_ the use of
-`{ResourceLock}`, they would be _flaky_. Sometimes they would pass, and at other times they
-would fail due to the inherent race condition of writing and then reading the same JVM
-System Property.
-
-When access to shared resources is declared using the `{ResourceLock}` annotation, the
-JUnit Jupiter engine uses this information to ensure that no conflicting tests are run in
-parallel. This guarantee extends to lifecycle methods of a test class or method. For
-example, if a test method is annotated with a `{ResourceLock}` annotation, the "lock" will
-be acquired before any `@BeforeEach` methods are executed and released after all
-`@AfterEach` methods have been executed.
-
-[NOTE]
-.Running tests in isolation
-====
-If most of your test classes can be run in parallel without any synchronization but you
-have some test classes that need to run in isolation, you can mark the latter with the
-`{Isolated}` annotation. Tests in such classes are executed sequentially without any other
-tests running at the same time.
-====
-
-In addition to the `String` that uniquely identifies the shared resource, you may specify
-an access mode. Two tests that require `READ` access to a shared resource may run in
-parallel with each other but not while any other test that requires `READ_WRITE` access
-to the same shared resource is running.
-
-[source,java]
-.Declaring shared resources "statically" with `{ResourceLock}` annotation
-----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
-----
-
-[source,java]
-.Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
-----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
-----
-
-Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
-attribute in the `{ResourceLock}` annotation, the attribute accepts a value from
-the `{ResourceLockTarget}` enum.
-
-Specifying `target = CHILDREN` in a class-level `{ResourceLock}` annotation
-has the same semantics as adding an annotation with the same `value` and `mode`
-to each test method and nested test class declared in this class.
-
-This may improve parallelization when a test class declares a `READ` lock,
-but only a few methods hold a `READ_WRITE` lock.
-
-Tests in the following example would run in the `SAME_THREAD` if the `{ResourceLock}`
-didn't have `target = CHILDREN`. This is because the test class declares a `READ`
-shared resource, but one test method holds a `READ_WRITE` lock,
-which would force the `SAME_THREAD` execution mode for all the test methods.
-
-[source,java]
-.Declaring shared resources for child nodes with `target` attribute
-----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
-----
-
-
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
-
-While the JUnit team encourages reusable extensions to be packaged and maintained in
-separate libraries, JUnit Jupiter includes a few user-facing extension implementations
-that are considered so generally useful that users shouldn't have to add another
-dependency.
-
-[[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
-
-The built-in `{TempDirectory}` extension is used to create and clean up a temporary
-directory for an individual test or all tests in a test class. It is registered by
-default. To use it, annotate a non-final, unassigned field of type `java.nio.file.Path` or
-`java.io.File` with `{TempDir}` or add a parameter of type `java.nio.file.Path` or
-`java.io.File` annotated with `@TempDir` to a test class constructor, lifecycle method, or
-test method.
-
-For example, the following test declares a parameter annotated with `@TempDir` for a
-single test method, creates and writes to a file in the temporary directory, and checks
-its content.
-
-[source,java,indent=0]
-.A test method that requires a temporary directory
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
-----
-
-You can inject multiple temporary directories by specifying multiple annotated parameters.
-
-[source,java,indent=0]
-.A test method that requires multiple temporary directories
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
-----
-
-The following example stores a _shared_ temporary directory in a `static` field. This
-allows the same `sharedTempDir` to be used in all lifecycle methods and test methods of
-the test class. For better isolation, you should use an instance field or constructor
-injection so that each test method uses a separate directory.
-
-[source,java,indent=0]
-.A test class that shares a temporary directory across test methods
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
-----
-
-The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
-`NEVER`, `ON_SUCCESS`, or `ALWAYS`. If the cleanup mode is set to `NEVER`, the temporary
-directory will not be deleted after the test completes. If it is set to `ON_SUCCESS`, the
-temporary directory will only be deleted after the test if the test completed successfully.
-
-The default cleanup mode is `ALWAYS`. You can use the
-`junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
-
-[source,java,indent=0]
-.A test class with a temporary directory that doesn't get cleaned up
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
-----
-
-`@TempDir` supports the programmatic creation of temporary directories via the optional
-`factory` attribute. This is typically used to gain control over the temporary directory
-creation, like defining the parent directory or the file system that should be used.
-
-Factories can be created by implementing `TempDirFactory`. Implementations must provide a
-no-args constructor and should not make any assumptions regarding when and how many times
-they are instantiated, but they can assume that their `createTempDirectory(...)` and
-`close()` methods will both be called once per instance, in this order, and from the same
-thread.
-
-The default implementation available in Jupiter delegates directory creation to
-`java.nio.file.Files::createTempDirectory` which uses the default file system and the
-system's temporary directory as the parent directory. It passes `junit-` as the prefix
-string of the generated directory name to help identify it as a created by JUnit.
-
-The following example defines a factory that uses the test name as the directory name
-prefix instead of the `junit` constant value.
-
-[source,java,indent=0]
-.A test class with a temporary directory having the test name as the directory name prefix
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
-----
-
-It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
-temporary directory. The following example demonstrates how to achieve that.
-
-[source,java,indent=0]
-.A test class with a temporary directory created with the Jimfs in-memory file system
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
-----
-
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
-reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
-annotation that can be used as a drop-in replacement for
-`@TempDir(factory = JimfsTempDirFactory.class)`.
-
-[source,java,indent=0]
-.A custom annotation meta-annotated with `@TempDir`
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
-----
-
-The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
-
-[source,java,indent=0]
-.A test class using the custom annotation
-----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
-----
-
-Meta-annotations or additional annotations on the field or parameter the `TempDir`
-annotation is declared on might expose additional attributes to configure the factory.
-Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
-parameter of the `createTempDirectory(...)` method.
-
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
-`TempDirFactory` you would like to use by default. Just like for factories configured via
-the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
-the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
-annotations unless the `factory` attribute of the annotation specifies a different factory.
-
-In summary, the factory for a temporary directory is determined according to the following
-precedence rules:
-
-1. The `factory` attribute of the `@TempDir` annotation, if present
-2. The default `TempDirFactory` configured via the configuration
-parameter, if present
-3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
-
-[[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
-
-The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
-It is registered by default. To use it, annotate a field in a test class with
-`{AutoClose}`.
-
-`@AutoClose` fields may be either `static` or non-static. If the value of an `@AutoClose`
-field is `null` when it is evaluated the field will be ignored, but a warning message will
-be logged to inform you.
-
-By default, `@AutoClose` expects the value of the annotated field to implement a `close()`
-method that will be invoked to close the resource. However, developers can customize the
-name of the close method via the `value` attribute. For example, `@AutoClose("shutdown")`
-instructs JUnit to look for a `shutdown()` method to close the resource.
-
-`@AutoClose` fields are inherited from superclasses. Furthermore, `@AutoClose` fields from
-subclasses will be closed before `@AutoClose` fields in superclasses.
-
-When multiple `@AutoClose` fields exist within a given test class, the order in which the
-resources are closed depends on an algorithm that is deterministic but intentionally
-nonobvious. This ensures that subsequent runs of a test suite close resources in the same
-order, thereby allowing for repeatable builds.
-
-The `AutoCloseExtension` implements the `AfterAllCallback` and
-`TestInstancePreDestroyCallback` extension APIs. Consequently, a `static` `@AutoClose`
-field will be closed after all tests in the current test class have completed, effectively
-after `@AfterAll` methods have executed for the test class. A non-static `@AutoClose`
-field will be closed before the current test class instance is destroyed. Specifically, if
-the test class is configured with `@TestInstance(Lifecycle.PER_METHOD)` semantics, a
-non-static `@AutoClose` field will be closed after the execution of each test method, test
-factory method, or test template method. However, if the test class is configured with
-`@TestInstance(Lifecycle.PER_CLASS)` semantics, a non-static `@AutoClose` field will not
-be closed until the current test class instance is no longer needed, which means after
-`@AfterAll` methods and after all `static` `@AutoClose` fields have been closed.
-
-The following example demonstrates how to annotate an instance field with `@AutoClose` so
-that the resource is automatically closed after test execution. In this example, we assume
-that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
-
-[source,java,indent=0]
-.A test class using `@AutoClose` to close a resource
-----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
-----
-<1> Annotate an instance field with `@AutoClose`.
-<2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
-    will be invoked after each `@Test` method.
-
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
-
-The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
-returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
-often used implicitly when no specific locale or time zone is chosen. Both annotations
-work on the test class level and on the test method level, and are inherited from
-higher-level containers. After the annotated element has been executed, the initial
-default value is restored.
-
-[[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
-
-The default `Locale` can be specified using an
-{jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
-----
-
-Alternatively, the default `Locale` can be created using the following attributes from
-which a {jdk-javadoc-base-url}/java.base/java/util/Locale.Builder.html[`Locale.Builder`]
-can create an instance:
-
-* `language` or
-* `language` and `country` or
-* `language`, `country`, and `variant`
-
-NOTE: The variant needs to be a string which follows the
-https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
-----
-
-Mixing language tag configuration (via the annotation's `value` attributed) and
-attributed-based configuration will cause an exception to be thrown. Furthermore, a
-`variant` can only be specified if `country` is also specified. Otherwise, an exception
-will be thrown.
-
-Any method-level `@DefaultLocale` configurations will override class-level configurations.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
-----
-
-NOTE: A class-level configuration means that the specified locale is set before and reset
-after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{LocaleProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
-
-The default `TimeZone` is specified according to the
-{jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
-method.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
-----
-
-Any method level `@DefaultTimeZone` configurations will override class level configurations:
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
-----
-
-NOTE: A class-level configuration means that the specified time zone is set before and
-reset after each individual test in the annotated class.
-
-If your use case is not covered, you can implement the `{TimeZoneProvider}` interface.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
-----
-
-NOTE: The provider implementation must have a no-args (or the default) constructor.
-
-===== Thread Safety
-
-Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
-results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
-prepared for that and tests annotated with them will never execute in parallel (thanks to
-`{ResourceLock}`) to guarantee correct test results.
-
-However, this does not cover all possible cases. Tested code that reads or writes default
-locale and time zone _independently_ of the extensions can still run in parallel to them
-and may thus behave erratically when, for example, it unexpectedly reads a locale set by
-the extension in another thread. Tests that cover code that reads or writes the default
-locale or time zone need to be annotated with the respective annotation:
-
-* `{ReadsDefaultLocale}`
-* `{ReadsDefaultTimeZone}`
-* `{WritesDefaultLocale}`
-* `{WritesDefaultTimeZone}`
-
-Tests annotated in this way will never execute in parallel with tests annotated with
-`@DefaultLocale` or `@DefaultTimeZone`.

From 4133182ad7cbd3bb8af1f16d9e74900cee6389ce Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:09 +0100
Subject: [PATCH 18/57] Migrate writing-tests sections to Antora syntax

---
 .../ROOT/pages/writing-tests/annotations.adoc |  10 +-
 .../ROOT/pages/writing-tests/assertions.adoc  |  14 +-
 .../ROOT/pages/writing-tests/assumptions.adoc |   6 +-
 .../writing-tests/built-in-extensions.adoc    |  47 +++--
 .../pages/writing-tests/class-templates.adoc  |   4 +-
 .../conditional-test-execution.adoc           |  34 ++--
 .../ROOT/pages/writing-tests/definitions.adoc |  14 +-
 ...njection-for-constructors-and-methods.adoc |   8 +-
 .../pages/writing-tests/disabling-tests.adoc  |   9 +-
 .../pages/writing-tests/display-names.adoc    |  16 +-
 .../pages/writing-tests/dynamic-tests.adoc    |  18 +-
 .../writing-tests/exception-handling.adoc     |  26 ++-
 .../ROOT/pages/writing-tests/intro.adoc       |  10 +-
 .../pages/writing-tests/nested-tests.adoc     |  10 +-
 .../writing-tests/parallel-execution.adoc     |  31 ++--
 .../parameterized-classes-and-tests.adoc      | 174 +++++++++---------
 .../pages/writing-tests/repeated-tests.adoc   |   9 +-
 .../writing-tests/tagging-and-filtering.adoc  |   6 +-
 .../test-classes-and-methods.adoc             |  10 +-
 .../writing-tests/test-execution-order.adoc   |  14 +-
 .../test-instance-lifecycle.adoc              |   6 +-
 .../test-interfaces-and-default-methods.adoc  |  21 +--
 .../pages/writing-tests/test-templates.adoc   |   4 +-
 .../ROOT/pages/writing-tests/timeouts.adoc    |  21 +--
 24 files changed, 232 insertions(+), 290 deletions(-)

diff --git a/documentation/modules/ROOT/pages/writing-tests/annotations.adoc b/documentation/modules/ROOT/pages/writing-tests/annotations.adoc
index 7760a11d372a..90fd500c730f 100644
--- a/documentation/modules/ROOT/pages/writing-tests/annotations.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/annotations.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-annotations]]
-=== Annotations
+= Annotations
 
 JUnit Jupiter supports the following annotations for configuring tests and extending the
 framework.
@@ -126,7 +125,7 @@ WARNING: Some annotations may currently be _experimental_. Consult the table in
 <<api-evolution-experimental-apis>> for details.
 
 [[writing-tests-meta-annotations]]
-==== Meta-Annotations and Composed Annotations
+== Meta-Annotations and Composed Annotations
 
 JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
 define your own _composed annotation_ that will automatically _inherit_ the semantics of
@@ -139,7 +138,7 @@ named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/Fast.java[tags=user_guide]
+include::example$java/example/Fast.java[tags=user_guide]
 ----
 
 The following `@Test` method demonstrates usage of the `@Fast` annotation.
@@ -158,7 +157,7 @@ that can be used as a drop-in replacement for `@Tag("fast")` _and_ `@Test`.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/FastTest.java[tags=user_guide]
+include::example$java/example/FastTest.java[tags=user_guide]
 ----
 
 JUnit automatically recognizes the following as a `@Test` method that is tagged with
@@ -171,4 +170,3 @@ void myFastTest() {
     // ...
 }
 ----
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/assertions.adoc b/documentation/modules/ROOT/pages/writing-tests/assertions.adoc
index 71345d429bd0..6166f3597124 100644
--- a/documentation/modules/ROOT/pages/writing-tests/assertions.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/assertions.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-assertions]]
-=== Assertions
+= Assertions
 
 JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few
 that lend themselves well to being used with Java lambdas. All JUnit Jupiter assertions
@@ -14,7 +13,7 @@ complex or time-consuming, as it is only evaluated when the assertion fails.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/AssertionsDemo.java[tags=user_guide]
+include::example$java/example/AssertionsDemo.java[tags=user_guide]
 ----
 
 [[writing-tests-assertions-preemptive-timeouts]]
@@ -40,7 +39,7 @@ Similar side effects may be encountered with other frameworks that rely on
 ====
 
 [[writing-tests-assertions-kotlin]]
-==== Kotlin Assertion Support
+== Kotlin Assertion Support
 
 JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
 used in https://kotlinlang.org/[Kotlin]. All JUnit Jupiter Kotlin assertions are top-level
@@ -48,11 +47,11 @@ functions in the `org.junit.jupiter.api` package.
 
 [source,kotlin,indent=0]
 ----
-include::{kotlinTestDir}/example/KotlinAssertionsDemo.kt[tags=user_guide]
+include::example$kotlin/example/KotlinAssertionsDemo.kt[tags=user_guide]
 ----
 
 [[writing-tests-assertions-third-party]]
-==== Third-party Assertion Libraries
+== Third-party Assertion Libraries
 
 Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
 testing scenarios, there are times when more power and additional functionality are
@@ -68,7 +67,7 @@ from `org.assertj.core.api.Assertions` and then use them in tests like in the
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/AssertJAssertionsDemo.java[tags=user_guide]
+include::example$java/example/AssertJAssertionsDemo.java[tags=user_guide]
 ----
 
 [TIP]
@@ -96,4 +95,3 @@ analysis tool that fails the build if Jupiter's `Assertions` class is used.
 </module>
 ----
 ====
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/assumptions.adoc b/documentation/modules/ROOT/pages/writing-tests/assumptions.adoc
index ccf7be42d671..59e05de54c0a 100644
--- a/documentation/modules/ROOT/pages/writing-tests/assumptions.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/assumptions.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-assumptions]]
-=== Assumptions
+= Assumptions
 
 Assumptions are typically used whenever it does not make sense to continue execution of a
 given test — for example, if the test depends on something that does not exist in the
@@ -19,7 +18,7 @@ All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/AssumptionsDemo.java[tags=user_guide]
+include::example$java/example/AssumptionsDemo.java[tags=user_guide]
 ----
 
 NOTE: It is also possible to use methods from JUnit 4's `org.junit.Assume` class for
@@ -30,4 +29,3 @@ TIP: If you use AssertJ for assertions, you may also wish to use AssertJ for ass
 To do so, you can statically import the `assumeThat()` method from
 `org.assertj.core.api.Assumptions` and then use AssertJ's fluent API to specify your
 assumptions.
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc b/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc
index 7dfa2ee9e328..67804ac7ed65 100644
--- a/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-built-in-extensions]]
-=== Built-in Extensions
+= Built-in Extensions
 
 While the JUnit team encourages reusable extensions to be packaged and maintained in
 separate libraries, JUnit Jupiter includes a few user-facing extension implementations
@@ -7,7 +6,7 @@ that are considered so generally useful that users shouldn't have to add another
 dependency.
 
 [[writing-tests-built-in-extensions-TempDirectory]]
-==== The @TempDir Extension
+== The @TempDir Extension
 
 The built-in `{TempDirectory}` extension is used to create and clean up a temporary
 directory for an individual test or all tests in a test class. It is registered by
@@ -23,7 +22,7 @@ its content.
 [source,java,indent=0]
 .A test method that requires a temporary directory
 ----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
+include::example$java/example/TempDirectoryDemo.java[tags=user_guide_parameter_injection]
 ----
 
 You can inject multiple temporary directories by specifying multiple annotated parameters.
@@ -31,7 +30,7 @@ You can inject multiple temporary directories by specifying multiple annotated p
 [source,java,indent=0]
 .A test method that requires multiple temporary directories
 ----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
+include::example$java/example/TempDirectoryDemo.java[tags=user_guide_multiple_directories]
 ----
 
 The following example stores a _shared_ temporary directory in a `static` field. This
@@ -42,7 +41,7 @@ injection so that each test method uses a separate directory.
 [source,java,indent=0]
 .A test class that shares a temporary directory across test methods
 ----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
+include::example$java/example/TempDirectoryDemo.java[tags=user_guide_field_injection]
 ----
 
 The `@TempDir` annotation has an optional `cleanup` attribute that can be set to either
@@ -57,7 +56,7 @@ The default cleanup mode is `ALWAYS`. You can use the
 [source,java,indent=0]
 .A test class with a temporary directory that doesn't get cleaned up
 ----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
+include::example$java/example/TempDirectoryDemo.java[tags=user_guide_cleanup_mode]
 ----
 
 `@TempDir` supports the programmatic creation of temporary directories via the optional
@@ -81,7 +80,7 @@ prefix instead of the `junit` constant value.
 [source,java,indent=0]
 .A test class with a temporary directory having the test name as the directory name prefix
 ----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
+include::example$java/example/TempDirectoryDemo.java[tags=user_guide_factory_name_prefix]
 ----
 
 It is also possible to use an in-memory file system like `{Jimfs}` for the creation of the
@@ -90,7 +89,7 @@ temporary directory. The following example demonstrates how to achieve that.
 [source,java,indent=0]
 .A test class with a temporary directory created with the Jimfs in-memory file system
 ----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
+include::example$java/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
 ----
 
 `@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
@@ -101,7 +100,7 @@ annotation that can be used as a drop-in replacement for
 [source,java,indent=0]
 .A custom annotation meta-annotated with `@TempDir`
 ----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
+include::example$java/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation]
 ----
 
 The following example demonstrates how to use the custom `@JimfsTempDir` annotation.
@@ -109,7 +108,7 @@ The following example demonstrates how to use the custom `@JimfsTempDir` annotat
 [source,java,indent=0]
 .A test class using the custom annotation
 ----
-include::{testDir}/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
+include::example$java/example/TempDirectoryDemo.java[tags=user_guide_composed_annotation_usage]
 ----
 
 Meta-annotations or additional annotations on the field or parameter the `TempDir`
@@ -133,7 +132,7 @@ parameter, if present
 3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
 
 [[writing-tests-built-in-extensions-AutoClose]]
-==== The @AutoClose Extension
+== The @AutoClose Extension
 
 The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
 It is registered by default. To use it, annotate a field in a test class with
@@ -175,14 +174,14 @@ that the default `@TestInstance(Lifecycle.PER_METHOD)` semantics apply.
 [source,java,indent=0]
 .A test class using `@AutoClose` to close a resource
 ----
-include::{testDir}/example/AutoCloseDemo.java[tags=user_guide_example]
+include::example$java/example/AutoCloseDemo.java[tags=user_guide_example]
 ----
 <1> Annotate an instance field with `@AutoClose`.
 <2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
     will be invoked after each `@Test` method.
 
 [[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
-==== The @DefaultLocale and @DefaultTimeZone Extensions
+== The @DefaultLocale and @DefaultTimeZone Extensions
 
 The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
 returned from `Locale.getDefault()` and `TimeZone.getDefault()`, respectively, which are
@@ -192,14 +191,14 @@ higher-level containers. After the annotated element has been executed, the init
 default value is restored.
 
 [[writing-tests-built-in-extensions-DefaultLocale]]
-===== @DefaultLocale
+=== @DefaultLocale
 
 The default `Locale` can be specified using an
 {jdk-javadoc-base-url}/java.base/java/util/Locale.html#forLanguageTag-java.lang.String-[IETF BCP 47 language tag string].
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
+include::example$java/example/DefaultLocaleTimezoneExtensionDemo.java[tags=default_locale_language]
 ----
 
 Alternatively, the default `Locale` can be created using the following attributes from
@@ -215,7 +214,7 @@ https://www.rfc-editor.org/rfc/rfc5646.html[IETF BCP 47 / RFC 5646] syntax
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
+include::example$java/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_language_alternatives]
 ----
 
 Mixing language tag configuration (via the annotation's `value` attributed) and
@@ -227,7 +226,7 @@ Any method-level `@DefaultLocale` configurations will override class-level confi
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
+include::example$java/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_class_level]
 ----
 
 NOTE: A class-level configuration means that the specified locale is set before and reset
@@ -237,13 +236,13 @@ If your use case is not covered, you can implement the `{LocaleProvider}` interf
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
+include::example$java/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_locale_with_provider]
 ----
 
 NOTE: The provider implementation must have a no-args (or the default) constructor.
 
 [[writing-tests-built-in-extensions-DefaultTimeZone]]
-===== @DefaultTimeZone
+=== @DefaultTimeZone
 
 The default `TimeZone` is specified according to the
 {jdk-javadoc-base-url}/java.base/java/util/TimeZone.html#getTimeZone(java.lang.String)[TimeZone.getTimeZone(String)]
@@ -251,14 +250,14 @@ method.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
+include::example$java/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_zone]
 ----
 
 Any method level `@DefaultTimeZone` configurations will override class level configurations:
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
+include::example$java/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_timezone_class_level]
 ----
 
 NOTE: A class-level configuration means that the specified time zone is set before and
@@ -268,12 +267,12 @@ If your use case is not covered, you can implement the `{TimeZoneProvider}` inte
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
+include::example$java/example/DefaultLocaleTimezoneExtensionDemo.java[tag=default_time_zone_with_provider]
 ----
 
 NOTE: The provider implementation must have a no-args (or the default) constructor.
 
-===== Thread Safety
+=== Thread Safety
 
 Since the default locale and time zone are global state, reading and writing them during
 <<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
diff --git a/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc b/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc
index e6abf92bf6ba..9159045675f6 100644
--- a/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-class-templates]]
-=== Class Templates
+= Class Templates
 
 A `{ClassTemplate}` is not a regular test class but rather a template for the contained
 test cases. As such, it is designed to be invoked multiple times depending on invocation
@@ -11,4 +10,3 @@ with full support for the same lifecycle callbacks and extensions. Please refer
 
 NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
 specialization of class templates.
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc b/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc
index 068f8db579ae..ab2d5d500fa1 100644
--- a/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-conditional-execution]]
-=== Conditional Test Execution
+= Conditional Test Execution
 
 The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
 developers to either _enable_ or _disable_ a test class or test method based on certain
@@ -54,7 +53,7 @@ the `org.junit.jupiter.api.condition` package.
 ====
 
 [[writing-tests-conditional-execution-os]]
-==== Operating System and Architecture Conditions
+== Operating System and Architecture Conditions
 
 A container or test may be enabled or disabled on a particular operating system,
 architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
@@ -64,18 +63,18 @@ annotations.
 [source,java,indent=0]
 .Conditional execution based on operating system
 ----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
+include::example$java/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
 ----
 
 [[writing-tests-conditional-execution-architectures-demo]]
 [source,java,indent=0]
 .Conditional execution based on architecture
 ----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
+include::example$java/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
 ----
 
 [[writing-tests-conditional-execution-jre]]
-==== Java Runtime Environment Conditions
+== Java Runtime Environment Conditions
 
 A container or test may be enabled or disabled on particular versions of the Java Runtime
 Environment (JRE) via the `{EnabledOnJre}` and `{DisabledOnJre}` annotations or on a
@@ -88,7 +87,7 @@ constants.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
+include::example$java/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre]
 ----
 
 Since the enum constants defined in {JRE} are static for any given JUnit release, you
@@ -105,11 +104,11 @@ versions.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
+include::example$java/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
 ----
 
 [[writing-tests-conditional-execution-native]]
-==== Native Image Conditions
+== Native Image Conditions
 
 A container or test may be enabled or disabled within a
 https://www.graalvm.org/reference-manual/native-image/[GraalVM native image] via the
@@ -120,11 +119,11 @@ Build Tools] project.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
+include::example$java/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
 ----
 
 [[writing-tests-conditional-execution-system-properties]]
-==== System Property Conditions
+== System Property Conditions
 
 A container or test may be enabled or disabled based on the value of the `named` JVM
 system property via the `{EnabledIfSystemProperty}` and `{DisabledIfSystemProperty}`
@@ -133,7 +132,7 @@ regular expression.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
+include::example$java/example/ConditionalTestExecutionDemo.java[tags=user_guide_system_property]
 ----
 
 [TIP]
@@ -145,7 +144,7 @@ present, indirectly present, or meta-present on a given element.
 ====
 
 [[writing-tests-conditional-execution-environment-variables]]
-==== Environment Variable Conditions
+== Environment Variable Conditions
 
 A container or test may be enabled or disabled based on the value of the `named`
 environment variable from the underlying operating system via the
@@ -154,7 +153,7 @@ value supplied via the `matches` attribute will be interpreted as a regular expr
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
+include::example$java/example/ConditionalTestExecutionDemo.java[tags=user_guide_environment_variable]
 ----
 
 [TIP]
@@ -166,7 +165,7 @@ they are directly present, indirectly present, or meta-present on a given elemen
 ====
 
 [[writing-tests-conditional-execution-custom]]
-==== Custom Conditions
+== Custom Conditions
 
 As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
 container or test may be enabled or disabled based on a _condition method_ configured via
@@ -178,7 +177,7 @@ The following test class demonstrates how to configure a local method named
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
+include::example$java/example/ConditionalTestExecutionDemo.java[tags=user_guide_custom]
 ----
 
 Alternatively, the condition method can be located outside the test class. In this case,
@@ -189,7 +188,7 @@ example.
 ----
 package example;
 
-include::{testDir}/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
+include::example$java/example/ExternalCustomConditionDemo.java[tags=user_guide_external_custom_condition]
 ----
 
 [NOTE]
@@ -221,4 +220,3 @@ disable it when such support is unavailable as follows.
 	disabledReason = "headless environment")
 ----
 ====
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/definitions.adoc b/documentation/modules/ROOT/pages/writing-tests/definitions.adoc
index b572ec559b06..86dc2331fd19 100644
--- a/documentation/modules/ROOT/pages/writing-tests/definitions.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/definitions.adoc
@@ -1,17 +1,15 @@
-[[writing-tests-definitions]]
-=== Definitions
+= Definitions
+
+== Platform Concepts
 
-.Platform Concepts
-****
 Container::
 a node in the test tree that contains other containers or tests as its children (e.g. a _test class_).
 
 Test::
 a node in the test tree that verifies expected behavior when executed (e.g. a `@Test` method).
-****
 
-.Jupiter Concepts
-****
+== Jupiter Concepts
+
 Lifecycle Method::
 any method that is directly annotated or meta-annotated with
 `@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
@@ -27,5 +25,3 @@ any instance method that is directly annotated or meta-annotated with
 `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`, or `@TestTemplate`.
 With the exception of `@Test`, these create a _container_ in the test tree that groups
 _tests_ or, potentially (for `@TestFactory`), other _containers_.
-****
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc b/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc
index 963d1b2f6df0..85c0b3d7ecc8 100644
--- a/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-dependency-injection]]
-=== Dependency Injection for Constructors and Methods
+= Dependency Injection for Constructors and Methods
 
 In all prior JUnit versions, test constructors or methods were not allowed to have
 parameters (at least not with the standard `Runner` implementations). As one of the major
@@ -28,7 +27,7 @@ class constructor, `@BeforeEach` method, and `@Test` method.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/TestInfoDemo.java[tags=user_guide]
+include::example$java/example/TestInfoDemo.java[tags=user_guide]
 ----
 
 * `{RepetitionExtension}`: if a method parameter in a `@RepeatedTest`, `@BeforeEach`, or
@@ -52,7 +51,7 @@ them in the user interface for test results.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/TestReporterDemo.java[tags=user_guide]
+include::example$java/example/TestReporterDemo.java[tags=user_guide]
 ----
 
 NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
@@ -89,4 +88,3 @@ When the type of the parameter to inject is the only condition for your
 `{ParameterResolver}`, you can use the generic `{TypeBasedParameterResolver}` base class.
 The `supportsParameters` method is implemented behind the scenes and supports
 parameterized types.
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc
index cf8460955594..981acf5d408d 100644
--- a/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-disabling]]
-=== Disabling Tests
+= Disabling Tests
 
 Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
 annotation, via one of the annotations discussed in
@@ -19,14 +18,14 @@ Here's a `@Disabled` test class.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DisabledClassDemo.java[tags=user_guide]
+include::example$java/example/DisabledClassDemo.java[tags=user_guide]
 ----
 
 And here's a test class that contains a `@Disabled` test method.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DisabledTestsDemo.java[tags=user_guide]
+include::example$java/example/DisabledTestsDemo.java[tags=user_guide]
 ----
 
 [TIP]
@@ -44,5 +43,3 @@ traceability, etc.
 `@Disabled` is not `@Inherited`. Consequently, if you wish to disable a class whose
 superclass is `@Disabled`, you must redeclare `@Disabled` on the subclass.
 ====
-
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/display-names.adoc b/documentation/modules/ROOT/pages/writing-tests/display-names.adoc
index 2346875b83a8..de76247ca321 100644
--- a/documentation/modules/ROOT/pages/writing-tests/display-names.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/display-names.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-display-names]]
-=== Display Names
+= Display Names
 
 Test classes and test methods can declare custom display names via `@DisplayName` -- with
 spaces, special characters, and even emojis -- that will be displayed in test reports and
@@ -7,7 +6,7 @@ by test runners and IDEs.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DisplayNameDemo.java[tags=user_guide]
+include::example$java/example/DisplayNameDemo.java[tags=user_guide]
 ----
 
 [NOTE]
@@ -37,7 +36,7 @@ Any remaining ISO control characters in a display name will be replaced as follo
 ====
 
 [[writing-tests-display-name-generator]]
-==== Display Name Generators
+== Display Name Generators
 
 JUnit Jupiter supports custom display name generators that can be configured via the
 `@DisplayNameGeneration` annotation.
@@ -64,7 +63,7 @@ generator.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
+include::example$java/example/DisplayNameGeneratorDemo.java[tags=user_guide_replace_underscores]
 ----
 
 Running the above test class results in the following display names.
@@ -85,7 +84,7 @@ following example.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
+include::example$java/example/DisplayNameGeneratorDemo.java[tags=user_guide_indicative_sentences]
 ----
 
 Running the above test class results in the following display names.
@@ -106,7 +105,7 @@ With `IndicativeSentences`, you can optionally specify custom sentence fragments
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
+include::example$java/example/DisplayNameGeneratorDemo.java[tags=user_guide_custom_sentence_fragments]
 ----
 
 Running the above test class results in the following display names.
@@ -123,7 +122,7 @@ A year is a leap year ✔
 
 
 [[writing-tests-display-name-generator-default]]
-==== Setting the Default Display Name Generator
+== Setting the Default Display Name Generator
 
 You can use the `junit.jupiter.displayname.generator.default`
 <<running-tests-config-params, configuration parameter>> to specify the fully qualified
@@ -158,4 +157,3 @@ following precedence rules:
 3. by calling the default `DisplayNameGenerator` configured via the configuration
    parameter, if present
 4. by calling `org.junit.jupiter.api.DisplayNameGenerator.Standard`
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc
index 92c3ae99ffbd..5fea6ae2737f 100644
--- a/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-dynamic-tests]]
-=== Dynamic Tests
+= Dynamic Tests
 
 The standard `@Test` annotation in JUnit Jupiter described in
 <<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
@@ -48,7 +47,7 @@ or extensions between the execution of individual dynamic tests generated by the
 `@TestFactory` method.
 
 [[writing-tests-dynamic-tests-examples]]
-==== Dynamic Test Examples
+== Dynamic Test Examples
 
 The following `DynamicTestsDemo` class demonstrates several examples of test factories
 and dynamic tests.
@@ -79,11 +78,11 @@ a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
 
 [source,java]
 ----
-include::{testDir}/example/DynamicTestsDemo.java[tags=user_guide]
+include::example$java/example/DynamicTestsDemo.java[tags=user_guide]
 ----
 
 [[writing-tests-dynamic-tests-named-support]]
-==== Dynamic Tests and Named
+== Dynamic Tests and Named
 
 In some cases, it can be more natural to specify inputs together with a descriptive name
 using the {Named} API and the corresponding `stream()` factory methods on `DynamicTest` as
@@ -93,11 +92,11 @@ interface along with `Named` via the `NamedExecutable` base class.
 
 [source,java]
 ----
-include::{testDir}/example/DynamicTestsNamedDemo.java[tags=user_guide]
+include::example$java/example/DynamicTestsNamedDemo.java[tags=user_guide]
 ----
 
 [[writing-tests-dynamic-tests-uri-test-source]]
-==== URI Test Sources for Dynamic Tests
+== URI Test Sources for Dynamic Tests
 
 The JUnit Platform provides `TestSource`, a representation of the source of a test or
 container used to navigate to its location by IDEs and build tools.
@@ -132,7 +131,7 @@ implementations.
   If none of the above `TestSource` implementations are applicable.
 
 [[writing-tests-dynamic-tests-parallel-execution]]
-==== Parallel Execution
+== Parallel Execution
 
 Dynamic tests and containers support
 <<writing-tests-parallel-execution, parallel execution>>. You can configure their
@@ -141,7 +140,7 @@ factory methods as illustrated by the following example.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/DynamicTestsDemo.java[tags=execution_mode]
+include::example$java/example/DynamicTestsDemo.java[tags=execution_mode]
 ----
 
 Executing the above test factory method results in the following test tree and execution
@@ -154,4 +153,3 @@ modes:
 **** length > 0 -- `CONCURRENT` (from `executionMode(...)` call)
 **** not empty -- `SAME_THREAD` (from `childExecutionMode(...)` call)
 ** ... (same for "Container B" and "Container C")
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc b/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc
index 23d17f93f422..d71bea1c10a9 100644
--- a/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-exceptions]]
-=== Exception Handling
+= Exception Handling
 
 JUnit Jupiter provides robust support for handling test exceptions. This includes the
 built-in mechanisms for managing test failures due to exceptions, the role of exceptions
@@ -7,7 +6,7 @@ in implementing assertions and assumptions, and how to specifically assert non-t
 conditions in code.
 
 [[writing-tests-exceptions-uncaught]]
-==== Uncaught Exceptions
+== Uncaught Exceptions
 
 In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
 extension and not caught within that test method, lifecycle method, or extension, the
@@ -29,7 +28,7 @@ Jupiter will mark the test as failed.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
+include::example$java/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
 ----
 
 NOTE: It's important to note that specifying a `throws` clause in the test method has
@@ -38,7 +37,7 @@ as an expectation or assertion about what exceptions the test method should thro
 fails only if an exception is thrown unexpectedly or if an assertion fails.
 
 [[writing-tests-exceptions-failed-assertions]]
-==== Failed Assertions
+== Failed Assertions
 
 Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
 of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
@@ -62,11 +61,11 @@ will mark the test as failed.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/exception/FailedAssertionDemo.java[tags=user_guide]
+include::example$java/example/exception/FailedAssertionDemo.java[tags=user_guide]
 ----
 
 [[writing-tests-exceptions-expected]]
-==== Asserting Expected Exceptions
+== Asserting Expected Exceptions
 
 JUnit Jupiter offers specialized assertions for testing that specific exceptions are
 thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly()`
@@ -74,7 +73,7 @@ assertions are critical tools for validating that your code responds correctly t
 conditions by throwing the appropriate exceptions.
 
 [[writing-tests-exceptions-expected-assertThrows]]
-===== Using `assertThrows()`
+=== Using `assertThrows()`
 
 The `assertThrows()` method is used to verify that a particular type of exception is
 thrown during the execution of a provided executable block. It not only checks for the
@@ -84,11 +83,11 @@ thrown exception object to allow performing additional assertions on it.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
+include::example$java/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
 ----
 
 [[writing-tests-exceptions-expected-assertThrowsExactly]]
-===== Using `assertThrowsExactly()`
+=== Using `assertThrowsExactly()`
 
 The `assertThrowsExactly()` method is used when you need to assert that the exception
 thrown is exactly of a specific type, not allowing for subclasses of the expected
@@ -98,11 +97,11 @@ returns the thrown exception object to allow performing additional assertions on
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
+include::example$java/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
 ----
 
 [[writing-tests-exceptions-not-expected]]
-==== Asserting That no Exception is Expected
+== Asserting That no Exception is Expected
 
 Although any exception thrown from a test method will cause the test to fail, there are
 certain use cases where it can be beneficial to explicitly assert that an exception is
@@ -112,10 +111,9 @@ throw any exceptions.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
+include::example$java/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
 ----
 
 NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
 has `assertThatNoException().isThrownBy(() -> ...)`. See also:
 <<writing-tests-assertions-third-party>>.
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/intro.adoc b/documentation/modules/ROOT/pages/writing-tests/intro.adoc
index 1b6b9b38b953..6f7155423113 100644
--- a/documentation/modules/ROOT/pages/writing-tests/intro.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/intro.adoc
@@ -1,9 +1,4 @@
-:testDir: ../../../../src/test/java
-:testResourcesDir: ../../../../src/test/resources
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[writing-tests]]
-== Writing Tests
+= Writing Tests
 
 The following example provides a glimpse at the minimum requirements for writing a test in
 JUnit Jupiter. Subsequent sections of this chapter will provide further details on all
@@ -12,6 +7,5 @@ available features.
 [source,java,indent=0]
 .A first test case
 ----
-include::{testDir}/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
+include::example$java/example/MyFirstJUnitJupiterTests.java[tags=user_guide]
 ----
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc
index 9fa0ed86d4b9..7f1ac2e85542 100644
--- a/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-nested]]
-=== Nested Tests
+= Nested Tests
 
 `@Nested` tests give the test writer more capabilities to express the relationship among
 several groups of tests. Such nested tests make use of Java's nested classes and
@@ -9,7 +8,7 @@ both as source code and as a screenshot of the execution within an IDE.
 [source,java,indent=0]
 .Nested test suite for testing a stack
 ----
-include::{testDir}/example/TestingAStackDemo.java[tags=user_guide]
+include::example$java/example/TestingAStackDemo.java[tags=user_guide]
 ----
 
 When executing this example in an IDE, the test execution tree in the GUI will look
@@ -31,7 +30,7 @@ classes. Nesting can be arbitrarily deep, and those inner classes are subject to
 lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
 
 [[writing-tests-nested-interoperability]]
-==== Interoperability
+== Interoperability
 
 `@Nested` may be combined with
 <<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
@@ -42,7 +41,7 @@ The following example illustrates how to combine `@Nested` with `@ParameterizedC
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=nested]
+include::example$java/example/ParameterizedClassDemo.java[tags=nested]
 ----
 
 Executing the above test class yields the following output:
@@ -70,4 +69,3 @@ FruitTests ✔
             ├─ [1] duration = "PT1H" ✔
             └─ [2] duration = "PT2H" ✔
 ....
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc b/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc
index dba5c7e15b82..5460dfa5df82 100644
--- a/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-parallel-execution]]
-=== Parallel Execution
+= Parallel Execution
 
 By default, JUnit Jupiter tests are run sequentially in a single thread; however, running
 tests in parallel -- for example, to speed up execution -- is available as an opt-in
@@ -46,7 +45,7 @@ test class or method:
 
 [source,java]
 ----
-include::{testDir}/example/ExplicitExecutionModeDemo.java[tags=user_guide]
+include::example$java/example/ExplicitExecutionModeDemo.java[tags=user_guide]
 ----
 
 This allows test classes or methods to opt in or out of concurrent execution regardless of
@@ -139,10 +138,10 @@ not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default
 used instead.
 
 [[writing-tests-parallel-execution-config]]
-==== Configuration
+== Configuration
 
 [[writing-tests-parallel-execution-config-executor-service]]
-===== Executor Service
+=== Executor Service
 
 If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
 concurrently. You can configure which implementation of `HierarchicalTestExecutorService`
@@ -166,7 +165,7 @@ to give it a try and provide feedback to the JUnit team so they can improve and
 <<api-evolution, promote>> this feature.
 
 [[writing-tests-parallel-execution-config-strategies]]
-===== Strategies
+=== Strategies
 
 Properties such as the desired parallelism and the maximum pool size can be configured
 using a `{ParallelExecutionConfigurationStrategy}`. The JUnit Platform provides two
@@ -208,12 +207,12 @@ threads by configuring the maximum pool size of the `dynamic`, `fixed` and `cust
 strategies.
 
 [[writing-tests-parallel-execution-config-properties]]
-===== Relevant properties
+=== Relevant properties
 
 The following table lists relevant properties for configuring parallel execution. See
 <<running-tests-config-params>> for details on how to set such properties.
 
-====== General
+==== General
 
 `junit.jupiter.execution.parallel.enabled=true|false`::
   Enable/disable parallel test execution (defaults to `false`).
@@ -231,7 +230,7 @@ The following table lists relevant properties for configuring parallel execution
 `junit.jupiter.execution.parallel.config.strategy=dynamic|fixed|custom`::
   Execution strategy for desired parallelism, maximum pool size, etc. (defaults to `dynamic`).
 
-====== Dynamic strategy
+==== Dynamic strategy
 
 `junit.jupiter.execution.parallel.config.dynamic.factor=decimal`::
   Factor to be multiplied by the number of available processors/cores to determine the
@@ -251,7 +250,7 @@ The following table lists relevant properties for configuring parallel execution
   configuration strategy (defaults to `true`). Only used if
   `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
 
-====== Fixed strategy
+==== Fixed strategy
 
 `junit.jupiter.execution.parallel.config.fixed.parallelism=integer`::
   Desired parallelism for the ```fixed``` configuration strategy (no default value). Must
@@ -268,14 +267,14 @@ The following table lists relevant properties for configuring parallel execution
   configuration strategy (defaults to `true`). Only used if
   `junit.jupiter.execution.parallel.config.executor-service` is set to `fork_join_pool`.
 
-====== Custom strategy
+==== Custom strategy
 
 `junit.jupiter.execution.parallel.config.custom.class=classname`::
   Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
   for the ```custom``` configuration strategy (no default value).
 
 [[writing-tests-parallel-execution-synchronization]]
-==== Synchronization
+== Synchronization
 
 In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
 Jupiter provides another annotation-based declarative synchronization mechanism. The
@@ -320,13 +319,13 @@ to the same shared resource is running.
 [source,java]
 .Declaring shared resources "statically" with `{ResourceLock}` annotation
 ----
-include::{testDir}/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
+include::example$java/example/sharedresources/StaticSharedResourcesDemo.java[tags=user_guide]
 ----
 
 [source,java]
 .Adding shared resources "dynamically" with `{ResourceLocksProvider}` implementation
 ----
-include::{testDir}/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
+include::example$java/example/sharedresources/DynamicSharedResourcesDemo.java[tags=user_guide]
 ----
 
 Also, "static" shared resources can be declared for _direct_ child nodes via the `target`
@@ -348,7 +347,5 @@ which would force the `SAME_THREAD` execution mode for all the test methods.
 [source,java]
 .Declaring shared resources for child nodes with `target` attribute
 ----
-include::{testDir}/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
+include::example$java/example/sharedresources/ChildrenSharedResourcesDemo.java[tags=user_guide]
 ----
-
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc
index 70484f86cf21..075beac659dc 100644
--- a/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-parameterized-tests]]
-=== Parameterized Classes and Tests
+= Parameterized Classes and Tests
 
 _Parameterized tests_ make it possible to run a test method multiple times with different
 arguments. They are declared just like regular `@Test` methods but use the
@@ -25,7 +24,7 @@ annotation to specify a `String` array as the source of arguments.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=first_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=first_example]
 ----
 
 When executing the above parameterized test method, each invocation will be reported
@@ -44,7 +43,7 @@ The same `@ValueSource` annotation can be used to specify the source of argument
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=first_example]
+include::example$java/example/ParameterizedClassDemo.java[tags=first_example]
 ----
 
 When executing the above parameterized test class, each invocation will be reported
@@ -65,16 +64,16 @@ PalindromeTests ✔
 ....
 
 [[writing-tests-parameterized-tests-setup]]
-==== Required Setup
+== Required Setup
 
 In order to use parameterized classes or tests you need to add a dependency on the
 `junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
 
 [[writing-tests-parameterized-tests-consuming-arguments]]
-==== Consuming Arguments
+== Consuming Arguments
 
 [[writing-tests-parameterized-tests-consuming-arguments-methods]]
-===== Parameterized Tests
+=== Parameterized Tests
 
 Parameterized test methods _consume_ arguments directly from the configured source (see
 <<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
@@ -97,7 +96,7 @@ _aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter ann
 with `{AggregateWith}`.
 
 [[writing-tests-parameterized-tests-consuming-arguments-classes]]
-===== Parameterized Classes
+=== Parameterized Classes
 
 Parameterized classes _consume_ arguments directly from the configured source (see
 <<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
@@ -106,7 +105,7 @@ or one of its superclasses, field injection will be used. Otherwise, constructor
 will be used.
 
 [[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
-====== Constructor Injection
+==== Constructor Injection
 
 WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
 <<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
@@ -120,7 +119,7 @@ test class.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=constructor_injection]
+include::example$java/example/ParameterizedClassDemo.java[tags=constructor_injection]
 ----
 
 You may use _records_ to implement parameterized classes that avoid the boilerplate code
@@ -128,11 +127,11 @@ of declaring a test class constructor.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedRecordDemo.java[tags=example]
+include::example$java/example/ParameterizedRecordDemo.java[tags=example]
 ----
 
 [[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
-====== Field Injection
+==== Field Injection
 
 For field injection, the following rules apply for fields annotated with `@Parameter`.
 
@@ -155,7 +154,7 @@ arguments in a parameterized class.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedClassDemo.java[tags=field_injection]
+include::example$java/example/ParameterizedClassDemo.java[tags=field_injection]
 ----
 
 If field injection is used, no constructor parameters will be resolved with arguments from
@@ -163,7 +162,7 @@ the source. Other <<writing-tests-dependency-injection, `ParameterResolver` exte
 may resolve constructor parameters as usual, though.
 
 [[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
-====== Lifecycle Methods
+==== Lifecycle Methods
 
 `{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
 be used to consume arguments if their `injectArguments` attribute is set to `true` (the
@@ -191,14 +190,14 @@ invocations.
 ====
 
 [[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
-===== Other Extensions
+=== Other Extensions
 
 Other extensions can access the parameters and resolved arguments of a parameterized test
 or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
 Please refer to the Javadoc of `{ParameterInfo}` for details.
 
 [[writing-tests-parameterized-tests-sources]]
-==== Sources of Arguments
+== Sources of Arguments
 
 Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
 following subsections provides a brief overview and an example for each of them. Please
@@ -210,7 +209,7 @@ and `{ParameterizedTest}`. For the sake of brevity, the examples in this section
 show how to use them with `{ParameterizedTest}` methods.
 
 [[writing-tests-parameterized-tests-sources-ValueSource]]
-===== @ValueSource
+=== @ValueSource
 
 `@ValueSource` is one of the simplest possible sources. It lets you specify a single
 array of literal values and can only be used for providing a single argument per
@@ -234,11 +233,11 @@ the values `1`, `2`, and `3` respectively.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ValueSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=ValueSource_example]
 ----
 
 [[writing-tests-parameterized-tests-sources-null-and-empty]]
-===== Null and Empty Sources
+=== Null and Empty Sources
 
 In order to check corner cases and verify proper behavior of our software when it is
 supplied _bad input_, it can be useful to have `null` and _empty_ values supplied to our
@@ -269,7 +268,7 @@ achieve this for strings.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
+include::example$java/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example1]
 ----
 
 Making use of the composed `@NullAndEmptySource` annotation simplifies the above as
@@ -277,7 +276,7 @@ follows.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
+include::example$java/example/ParameterizedTestDemo.java[tags=NullAndEmptySource_example2]
 ----
 
 NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test method
@@ -285,13 +284,13 @@ result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the e
 blank strings supplied via `@ValueSource`.
 
 [[writing-tests-parameterized-tests-sources-EnumSource]]
-===== @EnumSource
+=== @EnumSource
 
 `@EnumSource` provides a convenient way to use `Enum` constants.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=EnumSource_example]
 ----
 
 The annotation's `value` attribute is optional. When omitted, the declared type of the
@@ -303,7 +302,7 @@ explicit enum type from the annotation as follows.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
+include::example$java/example/ParameterizedTestDemo.java[tags=EnumSource_example_autodetection]
 ----
 
 The annotation provides an optional `names` attribute that lets you specify which
@@ -311,7 +310,7 @@ constants shall be used, like in the following example.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=EnumSource_include_example]
 ----
 
 In addition to `names`, you can use the `from` and `to` attributes to specify a range of
@@ -326,7 +325,7 @@ constants.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=EnumSource_range_example]
 ----
 
 The `@EnumSource` annotation also provides an optional `mode` attribute that enables
@@ -336,12 +335,12 @@ following examples.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=EnumSource_exclude_example]
 ----
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=EnumSource_regex_example]
 ----
 
 You can also combine `mode` with the `from`, `to` and `names` attributes to define a
@@ -349,11 +348,11 @@ range of constants while excluding specific values from that range as shown belo
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
 ----
 
 [[writing-tests-parameterized-tests-sources-MethodSource]]
-===== @MethodSource
+=== @MethodSource
 
 `{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
 or external classes.
@@ -383,7 +382,7 @@ parameter type as demonstrated in the following example.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=simple_MethodSource_example]
 ----
 
 For a `@ParameterizedClass`, providing a factory method name via `@MethodSource` is
@@ -393,7 +392,7 @@ name, JUnit Jupiter will search for a _factory_ method with the same name as the
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=simple_MethodSource_without_value_example]
 ----
 
 Streams for primitive types (`DoubleStream`, `IntStream`, and `LongStream`) are also
@@ -401,7 +400,7 @@ supported as demonstrated by the following example.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=primitive_MethodSource_example]
 ----
 
 If a parameterized class or test method declares multiple parameters, you need to return a
@@ -413,7 +412,7 @@ addition, `Arguments.of(Object...)` may be used as an alternative to
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=multi_arg_MethodSource_example]
 ----
 
 An external, `static` _factory_ method can be referenced by providing its _fully qualified
@@ -423,7 +422,7 @@ method name_ as demonstrated in the following example.
 ----
 package example;
 
-include::{testDir}/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
+include::example$java/example/ExternalMethodSourceDemo.java[tags=external_MethodSource_example]
 ----
 
 Factory methods can declare parameters, which will be provided by registered
@@ -437,11 +436,11 @@ can be referenced by its fully qualified method name, e.g.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
+include::example$java/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
 ----
 
 [[writing-tests-parameterized-tests-sources-FieldSource]]
-===== @FieldSource
+=== @FieldSource
 
 `{FieldSource}` allows you to refer to one or more fields of the test class or external
 classes.
@@ -493,7 +492,7 @@ This parameterized test method will be invoked twice: with the values `"apple"`
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=default_field_FieldSource_example]
 ----
 
 The following example demonstrates how to provide a single explicit field name via
@@ -502,7 +501,7 @@ The following example demonstrates how to provide a single explicit field name v
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=explicit_field_FieldSource_example]
 ----
 
 The following example demonstrates how to provide multiple explicit field names via
@@ -513,7 +512,7 @@ be invoked four times: with the values `"apple"`, `"banana"`, `"cherry"`, and
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=multiple_fields_FieldSource_example]
 ----
 
 It is also possible to provide a `Stream`, `DoubleStream`, `IntStream`, `LongStream`, or
@@ -525,7 +524,7 @@ names `"Apple"` and `"Banana"`, respectively.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=named_arguments_FieldSource_example]
 ----
 
 [NOTE]
@@ -544,7 +543,7 @@ for further details on supported types).
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=multi_arg_FieldSource_example]
 ----
 
 [NOTE]
@@ -558,11 +557,11 @@ _fully qualified field name_ as demonstrated in the following example.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
+include::example$java/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
 ----
 
 [[writing-tests-parameterized-tests-sources-CsvSource]]
-===== @CsvSource
+=== @CsvSource
 
 `@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
 `String` literals). Each string provided via the `value` attribute in `@CsvSource`
@@ -572,7 +571,7 @@ the `useHeadersInDisplayName` attribute for details and an example).
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=CsvSource_example]
 ----
 
 The default delimiter is a comma (`,`), but you can use another character by setting the
@@ -685,7 +684,7 @@ your text block.
 ====
 
 [[writing-tests-parameterized-tests-sources-CsvFileSource]]
-===== @CsvFileSource
+=== @CsvFileSource
 
 `@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
 local file system. Each record from a CSV file results in one invocation of the
@@ -706,13 +705,13 @@ by default) will be interpreted as a comment and will be ignored.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=CsvFileSource_example]
 ----
 
 [source,csv,indent=0]
 .two-column.csv
 ----
-include::{testResourcesDir}/two-column.csv[]
+include::example$resources/two-column.csv[]
 ----
 
 The following listing shows the generated display names for the first two parameterized
@@ -752,7 +751,7 @@ by default. This behavior can be changed by setting the
 `ignoreLeadingAndTrailingWhitespace` attribute to `true`.
 
 [[writing-tests-parameterized-tests-sources-ArgumentsSource]]
-===== @ArgumentsSource
+=== @ArgumentsSource
 
 `@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
 that an implementation of `ArgumentsProvider` must be declared as either a top-level
@@ -760,12 +759,12 @@ class or as a `static` nested class.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=ArgumentsSource_example]
 ----
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=ArgumentsProvider_example]
 ----
 
 If you wish to implement a custom `ArgumentsProvider` that also consumes an annotation
@@ -778,18 +777,18 @@ following example.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
 ----
 
 [[writing-tests-parameterized-repeatable-sources]]
-===== Multiple sources using repeatable annotations
+=== Multiple sources using repeatable annotations
 
 Repeatable annotations provide a convenient way to specify multiple sources from
 different providers.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
+include::example$java/example/ParameterizedTestDemo.java[tags=repeatable_annotations]
 ----
 
 Following the above parameterized test, a test case will run for each argument:
@@ -810,7 +809,7 @@ The following annotations are repeatable:
 * `@ArgumentsSource`
 
 [[writing-tests-parameterized-tests-argument-count-validation]]
-==== Argument Count Validation
+== Argument Count Validation
 
 By default, when an arguments source provides more arguments than the test method needs,
 those additional arguments are ignored and the test executes as usual.
@@ -829,14 +828,14 @@ use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=argument_count_validation]
+include::example$java/example/ParameterizedTestDemo.java[tags=argument_count_validation]
 ----
 
 [[writing-tests-parameterized-tests-argument-conversion]]
-==== Argument Conversion
+== Argument Conversion
 
 [[writing-tests-parameterized-tests-argument-conversion-widening]]
-===== Widening Conversion
+=== Widening Conversion
 
 JUnit Jupiter supports
 https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2[Widening Primitive
@@ -846,7 +845,7 @@ For example, a parameterized class or test method annotated with
 `int` but also an argument of type `long`, `float`, or `double`.
 
 [[writing-tests-parameterized-tests-argument-conversion-implicit]]
-===== Implicit Conversion
+=== Implicit Conversion
 
 To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
 implicit type converters. The conversion process depends on the declared type of each
@@ -858,7 +857,7 @@ string will be automatically converted into the corresponding `TimeUnit` enum co
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=implicit_conversion_example]
 ----
 
 `String` instances are implicitly converted to the following target types.
@@ -910,7 +909,7 @@ integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
 |===
 
 [[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
-====== Fallback String-to-Object Conversion
+==== Fallback String-to-Object Conversion
 
 In addition to implicit conversion from strings to the target types listed in the above
 table, JUnit Jupiter also provides a fallback mechanism for automatic conversion from a
@@ -935,16 +934,16 @@ as the title of the book.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example]
 ----
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
+include::example$java/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
 ----
 
 [[writing-tests-parameterized-tests-argument-conversion-explicit]]
-===== Explicit Conversion
+=== Explicit Conversion
 
 Instead of relying on implicit argument conversion, you may explicitly specify an
 `ArgumentConverter` to use for a certain parameter using the `@ConvertWith` annotation
@@ -953,12 +952,12 @@ declared as either a top-level class or as a `static` nested class.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=explicit_conversion_example]
 ----
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
+include::example$java/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_ToStringArgumentConverter]
 ----
 
 If the converter is only meant to convert one type to another, you can extend
@@ -966,7 +965,7 @@ If the converter is only meant to convert one type to another, you can extend
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
+include::example$java/example/ParameterizedTestDemo.java[tags=explicit_conversion_example_TypedArgumentConverter]
 ----
 
 Explicit argument converters are meant to be implemented by test and extension authors.
@@ -976,7 +975,7 @@ composed annotation `JavaTimeConversionPattern`.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
+include::example$java/example/ParameterizedTestDemo.java[tags=explicit_java_time_converter]
 ----
 
 If you wish to implement a custom `ArgumentConverter` that also consumes an annotation
@@ -984,7 +983,7 @@ If you wish to implement a custom `ArgumentConverter` that also consumes an anno
 `{AnnotationBasedArgumentConverter}` class.
 
 [[writing-tests-parameterized-tests-argument-aggregation]]
-==== Argument Aggregation
+== Argument Aggregation
 
 By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
 corresponds to a single method parameter. Consequently, argument sources which are
@@ -1001,14 +1000,14 @@ Besides, you can retrieve the current test invocation index with
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_example]
 ----
 
 _An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
 `ArgumentsAccessor`._
 
 [[writing-tests-parameterized-tests-argument-aggregation-custom]]
-===== Custom Aggregators
+=== Custom Aggregators
 
 Apart from direct access to the arguments of a `@ParameterizedClass` or
 `@ParameterizedTest` using an `ArgumentsAccessor`, JUnit Jupiter also supports the usage
@@ -1023,12 +1022,12 @@ top-level class or as a `static` nested class.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example]
 ----
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
+include::example$java/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_example_PersonAggregator]
 ----
 
 If you find yourself repeatedly declaring `@AggregateWith(MyTypeAggregator.class)` for
@@ -1039,17 +1038,17 @@ action with a custom `@CsvToPerson` annotation.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example]
 ----
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
+include::example$java/example/ParameterizedTestDemo.java[tags=ArgumentsAggregator_with_custom_annotation_example_CsvToPerson]
 ----
 
 
 [[writing-tests-parameterized-tests-display-names]]
-==== Customizing Display Names
+== Customizing Display Names
 
 By default, the display name of a parameterized class or test invocation contains the
 invocation index and a comma-separated list of the `String` representations of all
@@ -1071,7 +1070,7 @@ However, you can customize invocation display names via the `name` attribute of
 ======
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=custom_display_names]
+include::example$java/example/ParameterizedTestDemo.java[tags=custom_display_names]
 ----
 
 When executing the above method using the `ConsoleLauncher` you will see output similar to
@@ -1121,7 +1120,7 @@ example below.
 ======
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_arguments]
+include::example$java/example/ParameterizedTestDemo.java[tags=named_arguments]
 ----
 
 When executing the above method using the `ConsoleLauncher` you will see output similar to
@@ -1149,7 +1148,7 @@ the custom name will be used as the display name, like in the example below.
 ======
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=named_argument_set]
+include::example$java/example/ParameterizedTestDemo.java[tags=named_argument_set]
 ----
 
 When executing the above method using the `ConsoleLauncher` you will see output similar to
@@ -1169,7 +1168,7 @@ Note that `argumentSet(String, Object...)` is a static factory method defined in
 ====
 
 [[writing-tests-parameterized-tests-display-names-quoted-text]]
-===== Quoted Text-based Arguments
+=== Quoted Text-based Arguments
 
 As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
 quoted by default. In this context, any `CharSequence` (such as a `String`) or `Character`
@@ -1229,7 +1228,7 @@ example.
 ====
 
 [[writing-tests-parameterized-tests-display-names-default-pattern]]
-===== Default Display Name Pattern
+=== Default Display Name Pattern
 
 If you'd like to set a default name pattern for all parameterized classes and tests in
 your project, you can declare the `junit.jupiter.params.displayname.default` configuration
@@ -1242,7 +1241,7 @@ junit.jupiter.params.displayname.default = {index}
 ----
 
 [[writing-tests-parameterized-tests-display-names-precedence-rules]]
-===== Precedence Rules
+=== Precedence Rules
 
 The display name for a parameterized class or test is determined according to the
 following precedence rules:
@@ -1253,10 +1252,10 @@ following precedence rules:
    `org.junit.jupiter.params.ParameterizedInvocationConstants`
 
 [[writing-tests-parameterized-tests-lifecycle-interop]]
-==== Lifecycle and Interoperability
+== Lifecycle and Interoperability
 
 [[writing-tests-parameterized-tests-lifecycle-interop-methods]]
-===== Parameterized Tests
+=== Parameterized Tests
 
 Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
 method. For example, `@BeforeEach` methods will be executed before each invocation.
@@ -1272,11 +1271,11 @@ lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
+include::example$java/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
 ----
 
 [[writing-tests-parameterized-tests-lifecycle-interop-classes]]
-===== Parameterized Classes
+=== Parameterized Classes
 
 Each invocation of a parameterized class has the same lifecycle as a regular test class.
 For example, `@BeforeAll` methods will be executed _once_ before all invocations and
@@ -1307,10 +1306,9 @@ by the following example.
 [source,java,indent=0]
 .Using parameterized class lifecycle methods
 ----
-include::{testDir}/example/ParameterizedLifecycleDemo.java[tags=example]
+include::example$java/example/ParameterizedLifecycleDemo.java[tags=example]
 ----
 <1> Initialization of the argument _before_ each invocation of the parameterized class
 <2> Usage of the previously initialized argument in a test method
 <3> Validation and cleanup of the argument _after_ each invocation of the parameterized
     class
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc
index c0e4eeb7544b..90e35cb9f477 100644
--- a/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-repeated-tests]]
-=== Repeated Tests
+= Repeated Tests
 
 JUnit Jupiter provides the ability to repeat a test a specified number of times by
 annotating a method with `@RepeatedTest` and specifying the total number of repetitions
@@ -64,7 +63,7 @@ developer can choose to have an instance of `{RepetitionInfo}` injected into a
 `@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
 
 [[writing-tests-repeated-tests-examples]]
-==== Repeated Test Examples
+== Repeated Test Examples
 
 The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
 repeated tests.
@@ -128,7 +127,7 @@ INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
 
 [source,java]
 ----
-include::{testDir}/example/RepeatedTestsDemo.java[tags=user_guide]
+include::example$java/example/RepeatedTestsDemo.java[tags=user_guide]
 ----
 
 When using the `ConsoleLauncher` with the unicode theme enabled, execution of
@@ -173,5 +172,3 @@ When using the `ConsoleLauncher` with the unicode theme enabled, execution of
 │     ├─ Wiederholung 4 von 5 ✔
 │     └─ Wiederholung 5 von 5 ✔
 ....
-
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc b/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc
index 5023e0971ea4..b38ffbb75bb9 100644
--- a/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-tagging-and-filtering]]
-=== Tagging and Filtering
+= Tagging and Filtering
 
 Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
 used to filter <<running-tests, test discovery and execution>>. Please refer to the
@@ -8,9 +7,8 @@ Platform.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/TaggingDemo.java[tags=user_guide]
+include::example$java/example/TaggingDemo.java[tags=user_guide]
 ----
 
 TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
 custom annotations for tags.
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc b/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc
index 69ee0ea0a894..aeb1b1d552d0 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-classes-and-methods]]
-=== Test Classes and Methods
+= Test Classes and Methods
 
 Test methods and lifecycle methods may be declared locally within the current test class,
 inherited from superclasses, or inherited from interfaces (see
@@ -45,7 +44,7 @@ lifecycle methods. For further information on runtime semantics, see
 [source,java,indent=0]
 .A standard Java test class
 ----
-include::{testDir}/example/StandardTests.java[tags=user_guide]
+include::example$java/example/StandardTests.java[tags=user_guide]
 ----
 
 It is also possible to use Java `record` classes as test classes as illustrated by the
@@ -54,7 +53,7 @@ following example.
 [source,java,indent=0]
 .A test class written as a Java record
 ----
-include::{testDir}/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
+include::example$java/example/MyFirstJUnitJupiterRecordTests.java[tags=user_guide]
 ----
 
 Test and lifecycle methods may be written in Kotlin and may optionally use the `suspend`
@@ -63,7 +62,7 @@ keyword for testing code using coroutines.
 [source,kotlin]
 .A test class written in Kotlin
 ----
-include::{kotlinTestDir}/example/KotlinCoroutinesDemo.kt[tags=user_guide]
+include::example$kotlin/example/KotlinCoroutinesDemo.kt[tags=user_guide]
 ----
 
 NOTE: Using suspending functions as test or lifecycle methods requires
@@ -72,4 +71,3 @@ https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-reflect[`kotli
 and
 https://central.sonatype.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core[`kotlinx-coroutines-core`]
 to be present on the classpath or module path.
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc b/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc
index 13150a3a2485..83b38d41fc97 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-test-execution-order]]
-=== Test Execution Order
+= Test Execution Order
 
 By default, test classes and methods will be ordered using an algorithm that is
 deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
@@ -9,7 +8,7 @@ repeatable builds.
 NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
 
 [[writing-tests-test-execution-order-methods]]
-==== Method Order
+== Method Order
 
 Although true _unit tests_ typically should not rely on the order in which they are
 executed, there are times when it is necessary to enforce a specific test method execution
@@ -44,11 +43,11 @@ order specified via the `@Order` annotation.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/OrderedTestsDemo.java[tags=user_guide]
+include::example$java/example/OrderedTestsDemo.java[tags=user_guide]
 ----
 
 [[writing-tests-test-execution-order-methods-default]]
-===== Setting the Default Method Orderer
+=== Setting the Default Method Orderer
 
 You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
 configuration parameter>> to specify the fully qualified class name of the
@@ -71,7 +70,7 @@ Similarly, you can specify the fully qualified name of any custom class that imp
 `MethodOrderer`.
 
 [[writing-tests-test-execution-order-classes]]
-==== Class Order
+== Class Order
 
 Although test classes typically should not rely on the order in which they are executed,
 there are times when it is desirable to enforce a specific test class execution order. You
@@ -136,6 +135,5 @@ executed in the order specified via the `@Order` annotation.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
+include::example$java/example/OrderedNestedTestClassesDemo.java[tags=user_guide]
 ----
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc b/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc
index b92bf55f492e..be2479032530 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-test-instance-lifecycle]]
-=== Test Instance Lifecycle
+= Test Instance Lifecycle
 
 In order to allow individual test methods to be executed in isolation and to avoid
 unexpected side effects due to mutable test instance state, JUnit creates a new instance
@@ -27,7 +26,7 @@ easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as
 mode.
 
 [[writing-tests-test-instance-lifecycle-changing-default]]
-==== Changing the Default Test Instance Lifecycle
+== Changing the Default Test Instance Lifecycle
 
 If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
 will use a _default_ lifecycle mode. The standard _default_ mode is `PER_METHOD`;
@@ -61,4 +60,3 @@ configures "per-class" semantics as the default but tests in the IDE are execute
 "per-method" semantics, that can make it difficult to debug errors that occur on the
 build server. It is therefore recommended to change the default in the JUnit Platform
 configuration file instead of via a JVM system property.
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc b/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc
index 2a7468bcbcc3..81151f883771 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-test-interfaces-and-default-methods]]
-=== Test Interfaces and Default Methods
+= Test Interfaces and Default Methods
 
 JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFactory`,
 `@TestTemplate`, `@BeforeEach`, and `@AfterEach` to be declared on interface `default`
@@ -10,12 +9,12 @@ annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
 
 [source,java]
 ----
-include::{testDir}/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
+include::example$java/example/testinterface/TestLifecycleLogger.java[tags=user_guide]
 ----
 
 [source,java]
 ----
-include::{testDir}/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
+include::example$java/example/testinterface/TestInterfaceDynamicTestsDemo.java[tags=user_guide]
 ----
 
 `@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
@@ -25,14 +24,14 @@ implement the interface automatically inherit its tags and extensions. See
 
 [source,java]
 ----
-include::{testDir}/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
+include::example$java/example/testinterface/TimeExecutionLogger.java[tags=user_guide]
 ----
 
 In your test class you can then implement these test interfaces to have them applied.
 
 [source,java]
 ----
-include::{testDir}/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
+include::example$java/example/testinterface/TestInterfaceDemo.java[tags=user_guide]
 ----
 
 Running the `TestInterfaceDemo` results in output similar to the following:
@@ -54,17 +53,17 @@ For example, you can write tests for how implementations of `Object.equals` or
 
 [source,java]
 ----
-include::{testDir}/example/defaultmethods/Testable.java[tags=user_guide]
+include::example$java/example/defaultmethods/Testable.java[tags=user_guide]
 ----
 
 [source,java]
 ----
-include::{testDir}/example/defaultmethods/EqualsContract.java[tags=user_guide]
+include::example$java/example/defaultmethods/EqualsContract.java[tags=user_guide]
 ----
 
 [source,java]
 ----
-include::{testDir}/example/defaultmethods/ComparableContract.java[tags=user_guide]
+include::example$java/example/defaultmethods/ComparableContract.java[tags=user_guide]
 ----
 
 In your test class you can then implement both contract interfaces thereby inheriting the
@@ -72,9 +71,7 @@ corresponding tests. Of course you'll have to implement the abstract methods.
 
 [source,java]
 ----
-include::{testDir}/example/defaultmethods/StringTests.java[tags=user_guide]
+include::example$java/example/defaultmethods/StringTests.java[tags=user_guide]
 ----
 
 NOTE: The above tests are merely meant as examples and therefore not complete.
-
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc b/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc
index 9c8bc506957a..9afe87e2c9be 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-test-templates]]
-=== Test Templates
+= Test Templates
 
 A `{TestTemplate}` method is not a regular test case but rather a template for a test
 case. As such, it is designed to be invoked multiple times depending on the number of
@@ -12,4 +11,3 @@ method with full support for the same lifecycle callbacks and extensions. Please
 NOTE: <<writing-tests-repeated-tests>> and
 <<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
 test templates.
-
diff --git a/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc b/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc
index 2cabb0284124..51fb4e18e371 100644
--- a/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc
@@ -1,5 +1,4 @@
-[[writing-tests-declarative-timeouts]]
-=== Timeouts
+= Timeouts
 
 The `@Timeout` annotation allows one to declare that a test, test factory, test template,
 or lifecycle method should fail if its execution time exceeds a given duration. The time
@@ -9,7 +8,7 @@ The following example shows how `@Timeout` is applied to lifecycle and test meth
 
 [source,java]
 ----
-include::{testDir}/example/TimeoutDemo.java[tags=user_guide]
+include::example$java/example/TimeoutDemo.java[tags=user_guide]
 ----
 
 To apply the same timeout to all test methods within a test class and all of its `@Nested`
@@ -28,7 +27,7 @@ If `@Timeout` is present on a `@TestTemplate` method — for example, a `@Repeat
 `@ParameterizedTest` — each invocation will have the given timeout applied to it.
 
 [[writing-tests-declarative-timeouts-thread-mode]]
-==== Thread mode
+== Thread mode
 
 The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
 `SEPARATE_THREAD`, or `INFERRED`.
@@ -49,7 +48,7 @@ provided configuration parameter is invalid or not present then `SAME_THREAD` is
 fallback.
 
 [[writing-tests-declarative-timeouts-default-timeouts]]
-==== Default Timeouts
+== Default Timeouts
 
 The following <<running-tests-config-params, configuration parameters>> can be used to
 specify default timeouts for all methods of a certain category unless they or an enclosing
@@ -102,7 +101,7 @@ omitted. Specifying no unit is equivalent to using seconds.
 
 
 [[writing-tests-declarative-timeouts-polling]]
-==== Using @Timeout for Polling Tests
+== Using @Timeout for Polling Tests
 
 When dealing with asynchronous code, it is common to write tests that poll while waiting
 for something to happen before performing any assertions. In some cases you can rewrite
@@ -120,7 +119,7 @@ until" logic very easily.
 
 [source,java]
 ----
-include::{testDir}/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
+include::example$java/example/PollingTimeoutDemo.java[tags=user_guide,indent=0]
 ----
 
 NOTE: If you need more control over polling intervals and greater flexibility with
@@ -129,7 +128,7 @@ link:https://github.com/awaitility/awaitility[Awaitility].
 
 
 [[writing-tests-declarative-timeouts-debugging]]
-==== Debugging Timeouts
+== Debugging Timeouts
 
 Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
 `Thread.interrupt()` on the thread that is executing the timed out method. This allows to
@@ -138,7 +137,7 @@ diagnosing the cause of a timeout.
 
 
 [[writing-tests-declarative-timeouts-debugging-thread-dump]]
-===== Thread Dump on Timeout
+=== Thread Dump on Timeout
 
 JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
 extension point that dumps the stacks of all threads to `System.out` if enabled by setting
@@ -147,7 +146,7 @@ the `junit.jupiter.execution.timeout.threaddump.enabled`
 
 
 [[writing-tests-declarative-timeouts-mode]]
-==== Disable @Timeout Globally
+== Disable @Timeout Globally
 
 When stepping through your code in a debug session, a fixed timeout limit may influence
 the result of the test, e.g. mark the test as failed although all assertions were met.
@@ -158,5 +157,3 @@ and `disabled_on_debug`. The default mode is `enabled`.
 A VM runtime is considered to run in debug mode when one of its input parameters starts
 with `-agentlib:jdwp` or `-Xrunjdwp`.
 This heuristic is queried by the `disabled_on_debug` mode.
-
-

From b6185b478fc85a11116ebafe58c54c854d8552e5 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:09 +0100
Subject: [PATCH 19/57] Add writing-tests sections to navigation

---
 documentation/modules/ROOT/nav.adoc | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/documentation/modules/ROOT/nav.adoc b/documentation/modules/ROOT/nav.adoc
index 1daff8e619ee..aa54c0dd07b0 100644
--- a/documentation/modules/ROOT/nav.adoc
+++ b/documentation/modules/ROOT/nav.adoc
@@ -1 +1,25 @@
 * xref:overview.adoc[]
+* xref:writing-tests/intro.adoc[]
+** xref:writing-tests/annotations.adoc[]
+** xref:writing-tests/definitions.adoc[]
+** xref:writing-tests/test-classes-and-methods.adoc[]
+** xref:writing-tests/display-names.adoc[]
+** xref:writing-tests/assertions.adoc[]
+** xref:writing-tests/assumptions.adoc[]
+** xref:writing-tests/exception-handling.adoc[]
+** xref:writing-tests/disabling-tests.adoc[]
+** xref:writing-tests/conditional-test-execution.adoc[]
+** xref:writing-tests/tagging-and-filtering.adoc[]
+** xref:writing-tests/test-execution-order.adoc[]
+** xref:writing-tests/test-instance-lifecycle.adoc[]
+** xref:writing-tests/nested-tests.adoc[]
+** xref:writing-tests/dependency-injection-for-constructors-and-methods.adoc[]
+** xref:writing-tests/test-interfaces-and-default-methods.adoc[]
+** xref:writing-tests/repeated-tests.adoc[]
+** xref:writing-tests/parameterized-classes-and-tests.adoc[]
+** xref:writing-tests/class-templates.adoc[]
+** xref:writing-tests/test-templates.adoc[]
+** xref:writing-tests/dynamic-tests.adoc[]
+** xref:writing-tests/timeouts.adoc[]
+** xref:writing-tests/parallel-execution.adoc[]
+** xref:writing-tests/built-in-extensions.adoc[]

From 7b6e4d60b7f807fde5c6cc0671c5e54d70e1dbe3 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:10 +0100
Subject: [PATCH 20/57] Move migrating-from-junit4.adoc to Antora module

---
 .../ROOT/pages/migrating-from-junit4.adoc}                        | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename documentation/{src/docs/asciidoc/user-guide/migration-from-junit4.adoc => modules/ROOT/pages/migrating-from-junit4.adoc} (100%)

diff --git a/documentation/src/docs/asciidoc/user-guide/migration-from-junit4.adoc b/documentation/modules/ROOT/pages/migrating-from-junit4.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/migration-from-junit4.adoc
rename to documentation/modules/ROOT/pages/migrating-from-junit4.adoc

From cb87b3158b43d13eedcd252ed6e587496e9259c2 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:10 +0100
Subject: [PATCH 21/57] Migrate migrating-from-junit4.adoc to Antora syntax

---
 .../ROOT/pages/migrating-from-junit4.adoc     | 37 +++++++++----------
 1 file changed, 17 insertions(+), 20 deletions(-)

diff --git a/documentation/modules/ROOT/pages/migrating-from-junit4.adoc b/documentation/modules/ROOT/pages/migrating-from-junit4.adoc
index 099b875bdd12..b0442759aad1 100644
--- a/documentation/modules/ROOT/pages/migrating-from-junit4.adoc
+++ b/documentation/modules/ROOT/pages/migrating-from-junit4.adoc
@@ -1,7 +1,4 @@
-:testDir: ../../../../src/test/java
-
-[[migrating-from-junit4]]
-== Migrating from JUnit 4
+= Migrating from JUnit 4
 
 Although the JUnit Jupiter programming model and extension model do not support JUnit 4
 features such as `Rules` and `Runners` natively, it is not expected that source code
@@ -17,7 +14,7 @@ classpath does not lead to any conflicts. It is therefore safe to maintain exist
 
 
 [[migrating-from-junit4-running]]
-=== Running JUnit 4 Tests on the JUnit Platform
+== Running JUnit 4 Tests on the JUnit Platform
 
 [WARNING]
 ====
@@ -40,7 +37,7 @@ See the example projects in the {junit-examples-repo}[`junit-examples`] reposito
 find out how this is done with Gradle and Maven.
 
 [[migrating-from-junit4-categories-support]]
-==== Categories Support
+=== Categories Support
 
 For test classes or methods that are annotated with `@Category`, the _JUnit Vintage test
 engine_ exposes the category's fully qualified class name as a <<running-tests-tags, tag>>
@@ -50,7 +47,7 @@ Similar to the `Categories` runner in JUnit 4, this information can be used to f
 discovered tests before executing them (see <<running-tests>> for details).
 
 [[migrating-from-junit4-parallel-execution]]
-=== Parallel Execution
+== Parallel Execution
 
 The JUnit Vintage test engine supports parallel execution of top-level test classes and test methods,
 allowing existing JUnit 3 and JUnit 4 tests to benefit from improved performance through
@@ -72,7 +69,7 @@ concurrent test execution. It can be enabled and configured using the following
   number of available processors is used.
 
 [[migrating-from-junit4-parallel-execution-class-level]]
-==== Parallelization at Class Level
+=== Parallelization at Class Level
 
 Let's assume we have two test classes `FooTest` and `BarTest` with each class containing
 three unit tests. Now, let's enable parallel execution of test classes:
@@ -97,7 +94,7 @@ ForkJoinPool-1-worker-2 - FooTest::test3
 ----
 
 [[migrating-from-junit4-parallel-execution-method-level]]
-==== Parallelization at Method Level
+=== Parallelization at Method Level
 
 Alternatively, we can enable parallel test execution at a method level,
 rather than the class level:
@@ -123,7 +120,7 @@ ForkJoinPool-1-worker-1 - FooTest::test3
 ----
 
 [[migrating-from-junit4-parallel-execution-class-and-method-level]]
-==== Full Parallelization
+=== Full Parallelization
 
 Finally, we can also enable parallelization at both class and method level:
 
@@ -148,7 +145,7 @@ ForkJoinPool-1-worker-4 - BarTest::test1
 ----
 
 [[migrating-from-junit4-parallel-execution-pool-size]]
-==== Configuring the Pool Size
+=== Configuring the Pool Size
 
 The default thread pool size is equal to the number of available processors. However, we
 can also configure the pool size explicitly:
@@ -180,7 +177,7 @@ used in this case. This happens because the pool adjusts the number of active th
 based on workload and system needs.
 
 [[migrating-from-junit4-parallel-execution-disabled]]
-==== Sequential Execution
+=== Sequential Execution
 
 On the other hand, if we disable parallel execution, the `VintageTestEngine`
 will execute all tests sequentially, regardless of the other properties:
@@ -196,7 +193,7 @@ Similarly, tests will be executed sequentially if you enable parallel execution
 but enable neither class-level nor method-level parallelization.
 
 [[migrating-from-junit4-tips]]
-=== Migration Tips
+== Migration Tips
 
 The following are topics that you should be aware of when migrating existing JUnit 4
 tests to JUnit Jupiter.
@@ -232,7 +229,7 @@ tests to JUnit Jupiter.
   - See <<migrating-from-junit4-failure-message-arguments>> for details.
 
 [[migrating-from-junit4-tips-parameterized]]
-==== Parameterized test classes
+=== Parameterized test classes
 
 Unless `@UseParametersRunnerFactory` is used, a JUnit 4 parameterized test class can be
 converted into a JUnit Jupiter
@@ -254,18 +251,18 @@ converted into a JUnit Jupiter
 [source,java,indent=0]
 .Before
 ----
-include::{testDir}/example/ParameterizedMigrationDemo.java[tags=before]
+include::example$java/example/ParameterizedMigrationDemo.java[tags=before]
 ----
 
 [source,java,indent=0]
 .After
 ----
-include::{testDir}/example/ParameterizedMigrationDemo.java[tags=after]
+include::example$java/example/ParameterizedMigrationDemo.java[tags=after]
 ----
 ====
 
 [[migrating-from-junit4-rule-support]]
-=== Limited JUnit 4 Rule Support
+== Limited JUnit 4 Rule Support
 
 WARNING: _JUnit 4 rule support_ is deprecated for removal since version 6.0.0. Please
 migrate to the corresponding APIs and extensions provided by JUnit Jupiter.
@@ -302,7 +299,7 @@ extension model of JUnit Jupiter instead of the rule-based model of JUnit 4.
 
 
 [[migrating-from-junit4-ignore-annotation-support]]
-=== JUnit 4 @Ignore Support
+== JUnit 4 @Ignore Support
 
 WARNING: _JUnit 4 `@Ignore` support_ is deprecated for removal since version 6.0.0. Please
 use JUnit Jupiter's `@Disabled` annotation instead.
@@ -321,12 +318,12 @@ automatically registers the `IgnoreCondition` along with
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/IgnoredTestsDemo.java[tags=user_guide]
+include::example$java/example/IgnoredTestsDemo.java[tags=user_guide]
 ----
 
 
 [[migrating-from-junit4-failure-message-arguments]]
-=== Failure Message Arguments
+== Failure Message Arguments
 
 The `Assumptions` and `Assertions` classes in JUnit Jupiter declare arguments in a
 different order than in JUnit 4. In JUnit 4 assertion and assumption methods accept the

From ba9bc1cbf82912a56a2c1fd36e3ed8617ffeb5cd Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:10 +0100
Subject: [PATCH 22/57] Add migrating-from-junit4.adoc to navigation

---
 documentation/modules/ROOT/nav.adoc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/documentation/modules/ROOT/nav.adoc b/documentation/modules/ROOT/nav.adoc
index aa54c0dd07b0..96c84890418b 100644
--- a/documentation/modules/ROOT/nav.adoc
+++ b/documentation/modules/ROOT/nav.adoc
@@ -23,3 +23,4 @@
 ** xref:writing-tests/timeouts.adoc[]
 ** xref:writing-tests/parallel-execution.adoc[]
 ** xref:writing-tests/built-in-extensions.adoc[]
+* xref:migrating-from-junit4.adoc[]

From 4b21791dd3429080d7e4bc1f6726d6bd4848ecd9 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:11 +0100
Subject: [PATCH 23/57] Move running-tests.adoc to Antora module

---
 .../pages/running-tests/build-support.adoc}   |    0
 .../capturing-standard-output-error.adoc      | 1216 +++++++++++++++++
 .../configuration-parameters.adoc             | 1216 +++++++++++++++++
 .../pages/running-tests/console-launcher.adoc | 1216 +++++++++++++++++
 .../pages/running-tests/discovery-issues.adoc | 1216 +++++++++++++++++
 .../running-tests/discovery-selectors.adoc    | 1216 +++++++++++++++++
 .../ROOT/pages/running-tests/ide-support.adoc | 1216 +++++++++++++++++
 .../ROOT/pages/running-tests/intro.adoc       | 1216 +++++++++++++++++
 .../pages/running-tests/source-launcher.adoc  | 1216 +++++++++++++++++
 .../running-tests/stack-trace-pruning.adoc    | 1216 +++++++++++++++++
 .../ROOT/pages/running-tests/tags.adoc        | 1216 +++++++++++++++++
 .../using-listeners-and-interceptors.adoc     | 1216 +++++++++++++++++
 12 files changed, 13376 insertions(+)
 rename documentation/{src/docs/asciidoc/user-guide/running-tests.adoc => modules/ROOT/pages/running-tests/build-support.adoc} (100%)
 create mode 100644 documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc
 create mode 100644 documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc
 create mode 100644 documentation/modules/ROOT/pages/running-tests/console-launcher.adoc
 create mode 100644 documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc
 create mode 100644 documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc
 create mode 100644 documentation/modules/ROOT/pages/running-tests/ide-support.adoc
 create mode 100644 documentation/modules/ROOT/pages/running-tests/intro.adoc
 create mode 100644 documentation/modules/ROOT/pages/running-tests/source-launcher.adoc
 create mode 100644 documentation/modules/ROOT/pages/running-tests/stack-trace-pruning.adoc
 create mode 100644 documentation/modules/ROOT/pages/running-tests/tags.adoc
 create mode 100644 documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc

diff --git a/documentation/src/docs/asciidoc/user-guide/running-tests.adoc b/documentation/modules/ROOT/pages/running-tests/build-support.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/running-tests.adoc
rename to documentation/modules/ROOT/pages/running-tests/build-support.adoc
diff --git a/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc b/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc
new file mode 100644
index 000000000000..3099a146c2b4
--- /dev/null
+++ b/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc
@@ -0,0 +1,1216 @@
+[[running-tests]]
+== Running Tests
+
+[[running-tests-ide]]
+=== IDE Support
+
+[[running-tests-ide-intellij-idea]]
+==== IntelliJ IDEA
+
+IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
+information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
+however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
+IDEA download the following JARs automatically based on the API version used in the
+project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
+
+In order to use a different JUnit version (e.g., {version}), you may need to
+include the corresponding versions of the `junit-platform-launcher`,
+`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
+
+.Additional Gradle Dependencies
+[source,groovy]
+[subs=attributes+]
+----
+testImplementation(platform("org.junit:junit-bom:{version}"))
+testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
+testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
+----
+
+.Additional Maven Dependencies
+[source,xml]
+[subs=attributes+]
+----
+<!-- ... -->
+<dependencies>
+	<dependency>
+		<groupId>org.junit.platform</groupId>
+		<artifactId>junit-platform-launcher</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.jupiter</groupId>
+		<artifactId>junit-jupiter-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.vintage</groupId>
+		<artifactId>junit-vintage-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+</dependencies>
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+[[running-tests-ide-eclipse]]
+==== Eclipse
+
+Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
+release.
+
+For more information on using JUnit Platform in Eclipse consult the official _Eclipse
+support for JUnit 5_ section of the
+https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
+(4.7.1a) - New and Noteworthy] documentation.
+
+[[running-tests-ide-netbeans]]
+==== NetBeans
+
+NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
+https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
+
+For more information consult the JUnit 5 section of the
+https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
+release notes].
+
+[[running-tests-ide-vscode]]
+==== Visual Studio Code
+
+https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
+Platform via the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
+Runner] extension which is installed by default as part of the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
+Extension Pack].
+
+For more information consult the _Testing_ section of the
+https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
+documentation.
+
+[[running-tests-ide-other]]
+==== Other IDEs
+
+If you are using an editor or IDE other than one of those listed in the previous sections,
+and it doesn't support running tests on the JUnit Platform, you can use the
+<<running-tests-console-launcher>> to run them from the command line.
+
+[[running-tests-build]]
+=== Build Support
+
+[[running-tests-build-gradle]]
+==== Gradle
+
+Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
+https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
+for executing tests on the JUnit Platform. To enable it, you need to specify
+`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform()
+}
+----
+
+Filtering by <<running-tests-tags, tags>>,
+<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform {
+		includeTags("fast", "smoke & feature-a")
+		// excludeTags("slow", "ci")
+		includeEngines("junit-jupiter")
+		// excludeEngines("junit-vintage")
+	}
+}
+----
+
+Please refer to the
+https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
+for a comprehensive list of options.
+
+[[running-tests-build-gradle-bom]]
+===== Aligning dependency versions
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Explicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation(platform("org.junit:junit-bom:{version}"))
+	testImplementation("org.junit.jupiter:junit-jupiter")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+Since all JUnit artifacts declare a
+https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
+you usually don't need to declare an explicit dependency on it yourself. Instead, it's
+sufficient to declare _one_ regular dependency that includes a version number. Gradle will
+then pull in the BOM automatically so you can omit the version for all other JUnit
+artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Implicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
+}
+----
+<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
+<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
+
+[WARNING]
+.Declaring a dependency on junit-platform-launcher
+====
+Even though pre-8.0 versions of Gradle don't require declaring an explicit
+dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
+of JUnit artifacts on the test runtime classpath are aligned.
+
+Moreover, doing so is recommended and in some cases even required when importing the
+project into an IDE like <<running-tests-ide-eclipse>> or
+<<running-tests-ide-intellij-idea>>.
+====
+
+[[running-tests-build-gradle-engines-configure]]
+===== Configuring Test Engines
+
+In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
+
+To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
+on the dependency-aggregating JUnit Jupiter artifact similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Alternatively, you can use Gradle's
+https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
+support.
+
+[source,kotlin,indent=0]
+[subs=attributes+]
+.Kotlin DSL
+----
+testing {
+	suites {
+		named<JvmTestSuite>("test") {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Groovy DSL
+----
+testing {
+	suites {
+		test {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
+dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
+implementation similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("junit:junit:{junit4-version}")
+	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+[[running-tests-build-gradle-config-params]]
+===== Configuration Parameters
+
+The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
+Platform <<running-tests-config-params, configuration parameters>> to influence test
+discovery and execution. However, you can provide configuration parameters within the
+build script via system properties (as shown below) or via the
+`junit-platform.properties` file.
+
+[source,groovy,indent=0]
+----
+test {
+	// ...
+	systemProperty("junit.jupiter.conditions.deactivate", "*")
+	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
+	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
+	// ...
+}
+----
+
+[[running-tests-build-gradle-logging]]
+===== Configuring Logging (optional)
+
+JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
+emit warnings and debug information. Please refer to the official documentation of
+`{LogManager}` for configuration options.
+
+Alternatively, it's possible to redirect log messages to other logging frameworks such as
+{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
+`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
+qualified class name_ of the `{LogManager}` implementation to use. The example below
+demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
+details).
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
+	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
+	systemProperty("log4j2.disableJmx", "true")
+}
+----
+
+Other logging frameworks provide different means to redirect messages logged using
+`java.util.logging`. For example, for {Logback} you can use the
+https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
+dependency to the test runtime classpath.
+
+[[running-tests-build-maven]]
+==== Maven
+
+Maven Surefire and Maven Failsafe provide
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
+for executing tests on the JUnit Platform. The `pom.xml` file in the
+`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
+and can serve as a starting point for configuring your Maven build.
+
+[WARNING]
+.Minimum required version of Maven Surefire/Failsafe
+====
+As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
+====
+
+[[running-tests-build-maven-bom]]
+===== Aligning dependency versions
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+[[running-tests-build-maven-engines-configure]]
+===== Configuring Test Engines
+
+In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
+`TestEngine` implementation must be added to the test classpath.
+
+To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
+on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
+following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>org.junit.jupiter</groupId>
+			<artifactId>junit-jupiter</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
+long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
+`TestEngine` implementation similar to the following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>junit</groupId>
+			<artifactId>junit</artifactId>
+			<version>{junit4-version}</version>
+			<scope>test</scope>
+		</dependency>
+		<dependency>
+			<groupId>org.junit.vintage</groupId>
+			<artifactId>junit-vintage-engine</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-filter-test-class-names]]
+===== Filtering by Test Class Names
+
+The Maven Surefire Plugin will scan for test classes whose fully qualified names match
+the following patterns.
+
+- `+++**/Test*.java+++`
+- `+++**/*Test.java+++`
+- `+++**/*Tests.java+++`
+- `+++**/*TestCase.java+++`
+
+Moreover, it will exclude all nested classes (including static member classes) by default.
+
+Note, however, that you can override this default behavior by configuring explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
+from excluding static member classes, you can override its exclude rules as follows.
+
+[source,xml,indent=0]
+[subs=attributes+]
+.Overriding exclude rules of Maven Surefire
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<excludes>
+						<exclude/>
+					</excludes>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Please see the
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
+documentation for Maven Surefire for details.
+
+[[running-tests-build-maven-filter-tags]]
+===== Filtering by Tags
+
+You can filter tests by <<running-tests-tags, tags>> or
+<<running-tests-tag-expressions, tag expressions>> using the following configuration
+properties.
+
+- to include _tags_ or _tag expressions_, use `groups`.
+- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<groups>acceptance | !feature-a</groups>
+					<excludedGroups>integration, regression</excludedGroups>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-config-params]]
+===== Configuration Parameters
+
+You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
+influence test discovery and execution by declaring the `configurationParameters`
+property and providing key-value pairs using the Java `Properties` file syntax (as shown
+below) or via the `junit-platform.properties` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<properties>
+						<configurationParameters>
+							junit.jupiter.conditions.deactivate = *
+							junit.jupiter.extensions.autodetection.enabled = true
+							junit.jupiter.testinstance.lifecycle.default = per_class
+						</configurationParameters>
+					</properties>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-ant]]
+==== Ant
+
+Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
+provides native support for launching tests on the JUnit Platform. The `junitlauncher`
+task is solely responsible for launching the JUnit Platform and passing it the selected
+collection of tests. The JUnit Platform then delegates to registered test engines to
+discover and execute the tests.
+
+The `junitlauncher` task attempts to align as closely as possible with native Ant
+constructs such as
+link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
+for allowing users to select the tests that they want executed by test engines. This gives
+the task a consistent and natural feel when compared to many other core Ant tasks.
+
+Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
+
+The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
+the task and can serve as a starting point.
+
+===== Basic Usage
+
+The following example demonstrates how to configure the `junitlauncher` task to select a
+single test class (i.e., `com.example.project.CalculatorTests`).
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+
+	<!-- ... -->
+
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<test name="com.example.project.CalculatorTests" />
+	</junitlauncher>
+----
+
+The `test` element allows you to specify a single test class that you want to be selected
+and executed. The `classpath` element allows you to specify the classpath to be used to
+launch the JUnit Platform. This classpath will also be used to locate test classes that
+are part of the execution.
+
+The following example demonstrates how to configure the `junitlauncher` task to select
+test classes from multiple locations.
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+	<!-- ... -->
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<testclasses outputdir="${output.dir}">
+			<fileset dir="${build.classes.dir}">
+				<include name="org/example/**/demo/**/" />
+			</fileset>
+			<fileset dir="${some.other.dir}">
+				<include name="org/myapp/**/" />
+			</fileset>
+		</testclasses>
+	</junitlauncher>
+----
+
+In the above example, the `testclasses` element allows you to select multiple test
+classes that reside in different locations.
+
+For further details on usage and configuration options please refer to the official Ant
+documentation for the
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
+
+[[running-tests-build-spring-boot]]
+==== Spring Boot
+
+link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
+managing the version of JUnit used in your project. In addition, the
+`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
+Jupiter, AssertJ, Mockito, etc.
+
+If your build relies on dependency management support from Spring Boot, you should not
+import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
+result in duplicate (and potentially conflicting) management of JUnit dependencies.
+
+If you need to override the version of a dependency used in your Spring Boot application,
+you have to override the exact name of the
+link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
+defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
+Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
+changing a dependency version is documented for both
+link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
+and
+link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
+
+With Gradle you can override the JUnit Jupiter version by including the following in your
+`build.gradle` file.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+	ext['junit-jupiter.version'] = '{version}'
+----
+
+With Maven you can override the JUnit Jupiter version by including the following in your
+`pom.xml` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<properties>
+		<junit-jupiter.version>{version}</junit-jupiter.version>
+	</properties>
+----
+
+[[running-tests-console-launcher]]
+=== Console Launcher
+
+The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
+Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
+Jupiter tests and print test execution results to the console.
+
+An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
+contains the contents of all of its dependencies is published in the {Maven_Central}
+repository under the
+https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
+directory. It contains the contents of the following artifacts:
+
+include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
+
+[NOTE]
+====
+Since the `junit-platform-console-standalone` JAR contains the contents of all of its
+dependencies, its Maven POM does not declare any dependencies.
+
+Furthermore, it is not very likely that you would need to include a dependency on the
+`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
+script. On the contrary, the executable `junit-platform-console-standalone` JAR is
+typically invoked directly from the command line or a shell script without a build script.
+
+If you need to declare dependencies in your build script on some of the artifacts
+contained in the `junit-platform-console-standalone` artifact, you should declare
+dependencies only on the JUnit artifacts that are used in your project. To simplify
+dependency management of JUnit artifacts in your build, you may wish to use the
+`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
+details.
+====
+
+You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
+standalone `ConsoleLauncher` as shown below.
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
+
+├─ JUnit Vintage
+│  └─ example.JUnit4Tests
+│     └─ standardJUnit4Test ✔
+└─ JUnit Jupiter
+   ├─ StandardTests
+   │  ├─ succeedingTest() ✔
+   │  └─ skippedTest() ↷ for demonstration purposes
+   └─ A special test case
+      ├─ Custom test name containing spaces ✔
+      ├─ ╯°□°)╯ ✔
+      └─ 😱 ✔
+
+Test run finished after 64 ms
+[         5 containers found      ]
+[         0 containers skipped    ]
+[         5 containers started    ]
+[         0 containers aborted    ]
+[         5 containers successful ]
+[         0 containers failed     ]
+[         6 tests found           ]
+[         1 tests skipped         ]
+[         5 tests started         ]
+[         0 tests aborted         ]
+[         5 tests successful      ]
+[         0 tests failed          ]
+----
+
+You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
+all jars in a directory):
+
+[source,console,subs=attributes+]
+----
+$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
+----
+
+[[running-tests-console-launcher-options]]
+==== Subcommands and Options
+
+The `{ConsoleLauncher}` provides the following subcommands:
+
+----
+include::{consoleLauncherOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-discovering-tests]]
+===== Discovering tests
+
+----
+include::{consoleLauncherDiscoverOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-executing-tests]]
+===== Executing tests
+
+.Exit Code
+NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
+All non-zero codes indicate an error of some sort. For example, status code `1`
+is returned if any containers or tests failed. If no tests are discovered and the
+`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
+with a status code of `2`. Unexpected or invalid user input yields a status code
+of `3`. An exit code of `-1` indicates an unspecified error condition.
+
+----
+include::{consoleLauncherExecuteOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-listing-test-engines]]
+===== Listing test engines
+
+----
+include::{consoleLauncherEnginesOptionsFile}[]
+----
+
+[[running-tests-console-launcher-argument-files]]
+==== Argument Files (@-files)
+
+On some platforms you may run into system limitations on the length of a command line when
+creating a command line with lots of options or with long arguments.
+
+The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
+are files that themselves contain arguments to be passed to the command. When the
+underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
+argument beginning with the character `@`, it expands the contents of that file into the
+argument list.
+
+The arguments within a file can be separated by spaces or newlines. If an argument
+contains embedded whitespace, the whole argument should be wrapped in double or single
+quotes -- for example, `"-f=My Files/Stuff.java"`.
+
+If the argument file does not exist or cannot be read, the argument will be treated
+literally and will not be removed. This will likely result in an "unmatched argument"
+error message. You can troubleshoot such errors by executing the command with the
+`picocli.trace` system property set to `DEBUG`.
+
+Multiple _@-files_ may be specified on the command line. The specified path may be
+relative to the current directory or absolute.
+
+You can pass a real parameter with an initial `@` character by escaping it with an
+additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
+subject to expansion.
+
+[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
+==== Redirecting Standard Output/Error to Files
+
+You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
+files using the `--redirect-stdout` and `--redirect-stderr` options:
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
+  --redirect-stdout=stdout.txt \
+  --redirect-stderr=stderr.txt
+----
+
+[NOTE]
+====
+If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
+output streams will be redirected to that file.
+
+The default charset is used for writing to the files.
+====
+
+[[running-tests-console-launcher-color-customization]]
+==== Color Customization
+
+The colors used in the output of the `{ConsoleLauncher}` can be customized.
+The option `--single-color` will apply a built-in monochrome style, while
+`--color-palette` will accept a properties file to override the
+https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
+The properties file below demonstrates the default style:
+
+[source,properties,indent=0]
+----
+SUCCESSFUL = 32
+ABORTED = 33
+FAILED = 31
+SKIPPED = 35
+CONTAINER = 35
+TEST = 34
+DYNAMIC = 35
+REPORTED = 37
+----
+
+[[running-tests-source-launcher]]
+=== Source Launcher
+
+Starting with Java 25 it is possible to write minimal source code test programs
+using the `org.junit.start` module. For example, like in a `HelloTests.java`
+file reading:
+
+```java
+import module org.junit.start;
+
+void main() {
+  JUnit.run();
+}
+
+@Test
+void stringLength() {
+  Assertions.assertEquals(11, "Hello JUnit".length());
+}
+```
+With all required modular JAR files available in a local `lib/` directory, the
+following Java 25+ command will discover and execute tests using the JUnit Platform.
+It will also print the result tree to the console.
+
+```shell
+java --module-path lib --add-modules org.junit.start HelloTests.java
+╷
+└─ JUnit Jupiter ✔
+   └─ HelloTests ✔
+      └─ stringLength() ✔
+```
+
+Find JUnit's class API documentation here: {JUnit}
+
+[[running-tests-discovery-selectors]]
+=== Discovery Selectors
+
+The JUnit Platform provides a rich set of discovery selectors that can be used to specify
+which tests should be discovered or executed.
+
+Discovery selectors can be created programmatically using the factory methods in the
+`{DiscoverySelectors}` class, specified declaratively via annotations when using the
+<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
+generically as strings via their identifiers.
+
+The following discovery selectors are provided out of the box:
+
+|===
+| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
+
+| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
+| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
+| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
+| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
+| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
+| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
+| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
+| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
+| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
+| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
+| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
+| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
+| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
+|===
+
+
+[[running-tests-config-params]]
+=== Configuration Parameters
+
+In addition to instructing the platform which test classes and test engines to include,
+which packages to scan, etc., it is sometimes necessary to provide additional custom
+configuration parameters that are specific to a particular test engine, listener, or
+registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
+parameters_ for the following use cases.
+
+- <<writing-tests-test-instance-lifecycle-changing-default>>
+- <<extensions-registration-automatic-enabling>>
+- <<extensions-conditions-deactivation>>
+- <<writing-tests-display-name-generator-default>>
+
+_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
+engines running on the JUnit Platform via one of the following mechanisms.
+
+1. The `configurationParameter()` and `configurationParameters()` methods in
+   `LauncherDiscoveryRequestBuilder` which
+   is used to build a request supplied to the <<launcher-api, Launcher API>>.
+    +
+   When running tests via one of the tools provided by the JUnit Platform you can specify
+   configuration parameters as follows:
+   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
+     option.
+   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
+     `systemProperties` DSL.
+   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
+     `configurationParameters` property.
+2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
+    +
+   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
+   specify custom configuration files using the `--config-resource` command-line option.
+3. JVM system properties.
+4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
+   in the root of the class path that follows the syntax rules for Java `Properties`
+   files.
+
+NOTE: Configuration parameters are looked up in the exact order defined above.
+Consequently, configuration parameters supplied directly to the `Launcher` take
+precedence over those supplied via custom configuration files, system properties, and the
+default configuration file. Similarly, configuration parameters supplied via system
+properties take precedence over those supplied via the default configuration file.
+
+[[running-tests-config-params-deactivation-pattern]]
+==== Pattern Matching Syntax
+
+This section describes the pattern matching syntax that is applied to the _configuration
+parameters_ used for the following features.
+
+- <<extensions-conditions-deactivation>>
+- <<launcher-api-listeners-custom-deactivation>>
+- <<stacktrace-pruning>>
+- <<extensions-registration-automatic-filtering>>
+
+If the value for the given _configuration parameter_ consists solely of an asterisk
+(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
+will be treated as a comma-separated list of patterns where each pattern will be matched
+against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
+a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
+(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
+pattern will be matched one-to-one against a FQCN.
+
+Examples:
+
+- `+++*+++`: matches all candidate classes.
+- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
+  any of its subpackages.
+- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
+  `MyCustomImpl`.
+- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
+- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
+  `System` or `Unit`.
+- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
+  `org.example.MyCustomImpl`.
+- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
+  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
+
+[[running-tests-tags]]
+=== Tags
+
+Tags are a JUnit Platform concept for marking and filtering tests. The programming model
+for adding tags to containers and tests is defined by the testing framework. For example,
+in JUnit Jupiter based tests, the `@Tag` annotation (see
+<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
+Vintage engine maps `@Category` annotations to tags (see
+<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
+own annotation or other means for users to specify tags.
+
+[[running-tests-tag-syntax-rules]]
+==== Syntax Rules for Tags
+
+Regardless how a tag is specified, the JUnit Platform enforces the following rules:
+
+* A tag must not be `null` or _blank_.
+* A _stripped_ tag must not contain whitespace.
+* A _stripped_ tag must not contain ISO control characters.
+* A _stripped_ tag must not contain any of the following _reserved characters_.
+- `,`: _comma_
+- `(`: _left parenthesis_
+- `)`: _right parenthesis_
+- `&`: _ampersand_
+- `|`: _vertical bar_
+- `!`: _exclamation point_
+
+NOTE: In the above context, "stripped" means that leading and trailing whitespace
+characters have been removed using `java.lang.String.strip()`.
+
+[[running-tests-tag-expressions]]
+==== Tag Expressions
+
+Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
+`(` and `)` can be used to adjust for operator precedence.
+
+Two special expressions are supported, `any()` and `none()`, which select all tests _with_
+any tags at all, and all tests _without_ any tags, respectively.
+These special expressions may be combined with other expressions just like normal tags.
+
+.Operators (in descending order of precedence)
+|===
+| Operator | Meaning | Associativity
+
+| `!`      | not     | right
+| `&`      | and     | left
+| `\|`     | or      | left
+|===
+
+If you are tagging your tests across multiple dimensions, tag expressions help you to
+select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
+_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
+expressions can be useful.
+
+[%header,cols="40,60"]
+|===
+| Tag Expression
+| Selection
+
+| `+++product+++`
+| all tests for *product*
+
+| `+++catalog \| shipping+++`
+| all tests for *catalog* plus all tests for *shipping*
+
+| `+++catalog &amp; shipping+++`
+| all tests for the intersection between *catalog* and *shipping*
+
+| `+++product &amp; !end-to-end+++`
+| all tests for *product*, but not the _end-to-end_ tests
+
+| `+++(micro \| integration) &amp; (product \| shipping)+++`
+| all _micro_ or _integration_ tests for *product* or *shipping*
+|===
+
+[[running-tests-capturing-output]]
+=== Capturing Standard Output/Error
+
+The JUnit Platform provides opt-in support for capturing output printed to `System.out`
+and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
+`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
+parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
+to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
+
+If enabled, the JUnit Platform captures the corresponding output and publishes it as a
+report entry using the `stdout` or `stderr` keys to all registered
+`{TestExecutionListener}` instances immediately before reporting the test or container as
+finished.
+
+Please note that the captured output will only contain output emitted by the thread that
+was used to execute a container or test. Any output by other threads will be omitted
+because particularly when
+<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
+to attribute it to a specific test or container.
+
+[[running-tests-listeners]]
+=== Using Listeners and Interceptors
+
+The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
+and custom user code to react to events fired at various points during the discovery and
+execution of a `TestPlan`.
+
+* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
+  closed.
+* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
+  `LauncherSession`.
+* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
+* `{TestExecutionListener}`: receives events that occur during test execution.
+
+The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
+registered automatically for you in order to support some feature of the build tool or IDE.
+
+The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
+order to produce some form of report or to display a graphical representation of the test
+plan in an IDE. Such listeners may be implemented and automatically registered by a build
+tool or IDE, or they may be included in a third-party library – potentially registered
+for you automatically. You can also implement and register your own listeners.
+
+For details on registering and configuring listeners, see the following sections of this
+guide.
+
+* <<launcher-api-launcher-session-listeners-custom>>
+* <<launcher-api-launcher-interceptors-custom>>
+* <<launcher-api-launcher-discovery-listeners-custom>>
+* <<launcher-api-listeners-custom>>
+* <<launcher-api-listeners-config>>
+* <<launcher-api-listeners-custom-deactivation>>
+
+The JUnit Platform provides the following listeners which you may wish to use with your
+test suite.
+
+<<junit-platform-reporting>> ::
+  `{LegacyXmlReportGeneratingListener}` can be used via the
+  <<running-tests-console-launcher>> or registered manually to generate XML reports
+  compatible with the de facto standard for JUnit 4 based test reports.
++
+`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
+specified by {OpenTestReporting}. It is auto-registered and can be enabled and
+configured via <<running-tests-config-params>>.
++
+See <<junit-platform-reporting>> for details.
+
+<<running-tests-listeners-flight-recorder>> ::
+  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
+  Java Flight Recorder events during test discovery and execution.
+
+`{LoggingListener}` ::
+  `TestExecutionListener` for logging informational messages for all events via a
+  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
+
+`{SummaryGeneratingListener}` ::
+  `TestExecutionListener` that generates a summary of the test execution which can be
+  printed via a `PrintWriter`.
+
+`{UniqueIdTrackingListener}` ::
+  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
+  or executed during the execution of the `TestPlan` and generates a file containing the
+  unique IDs once execution of the `TestPlan` has finished.
+
+[[running-tests-listeners-flight-recorder]]
+==== Flight Recorder Support
+
+The JUnit Platform provides opt-in support for generating Flight Recorder events.
+https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
+follows.
+
+> Flight Recorder records events originating from applications, the JVM, and the OS.
+Events are stored in a single file that can be attached to bug reports and examined by
+support engineers, allowing after-the-fact analysis of issues in the period leading up
+to a problem.
+
+In order to record Flight Recorder events generated while running tests, you need to
+start flight recording when launching a test suite via the following java command line
+option.
+
+   -XX:StartFlightRecording:filename=...
+
+Please consult the manual of your build tool for the appropriate commands.
+
+To analyze the recorded events, use the
+https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
+command line tool shipped with recent JDKs or open the recording file with
+https://jdk.java.net/jmc/[JDK Mission Control].
+
+[[stacktrace-pruning]]
+=== Stack Trace Pruning
+
+The JUnit Platform provides built-in support for pruning stack traces produced by failing
+tests. This feature is enabled by default but can be disabled by setting the
+`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
+
+When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
+packages are removed from the stack trace, unless the calls occur after the test itself
+or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
+never be excluded.
+
+In addition, all elements prior to and including the first call from the JUnit Platform
+`Launcher` will be removed.
+
+[[running-tests-discovery-issues]]
+=== Discovery Issues
+
+Test engines may encounter issues during test discovery. For example, the declaration of a
+test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
+Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
+report them with different severity levels:
+
+INFO::
+Indicates that the engine encountered something that could be potentially problematic, but
+could also happen due to a valid setup or configuration.
+
+WARNING::
+Indicates that the engine encountered something that is problematic and might lead to
+unexpected behavior or will be removed or changed in a future release.
+
+ERROR::
+Indicates that the engine encountered something that is definitely problematic and will
+lead to unexpected behavior.
+
+If an engine reports an issue with a severity equal to or higher than a configurable
+_critical_ severity, its tests will not be executed. Instead, the engine will be reported
+as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
+Non-critical issues will be logged but will not prevent the engine from executing its
+tests. The `junit.platform.discovery.issue.severity.critical`
+<<running-tests-config-params, configuration parameter>> can be used to set the critical
+severity level. Currently, the default value is `ERROR` but it may be changed in a future
+release.
+
+TIP: To surface all discovery issues in your project, it is recommended to set the
+`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
+
+In addition, registered `{LauncherDiscoveryListener}` implementations can receive
+discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
+report issues to the user in a more user-friendly way. For example, IDEs may choose to
+display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc b/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc
new file mode 100644
index 000000000000..3099a146c2b4
--- /dev/null
+++ b/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc
@@ -0,0 +1,1216 @@
+[[running-tests]]
+== Running Tests
+
+[[running-tests-ide]]
+=== IDE Support
+
+[[running-tests-ide-intellij-idea]]
+==== IntelliJ IDEA
+
+IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
+information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
+however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
+IDEA download the following JARs automatically based on the API version used in the
+project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
+
+In order to use a different JUnit version (e.g., {version}), you may need to
+include the corresponding versions of the `junit-platform-launcher`,
+`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
+
+.Additional Gradle Dependencies
+[source,groovy]
+[subs=attributes+]
+----
+testImplementation(platform("org.junit:junit-bom:{version}"))
+testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
+testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
+----
+
+.Additional Maven Dependencies
+[source,xml]
+[subs=attributes+]
+----
+<!-- ... -->
+<dependencies>
+	<dependency>
+		<groupId>org.junit.platform</groupId>
+		<artifactId>junit-platform-launcher</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.jupiter</groupId>
+		<artifactId>junit-jupiter-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.vintage</groupId>
+		<artifactId>junit-vintage-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+</dependencies>
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+[[running-tests-ide-eclipse]]
+==== Eclipse
+
+Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
+release.
+
+For more information on using JUnit Platform in Eclipse consult the official _Eclipse
+support for JUnit 5_ section of the
+https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
+(4.7.1a) - New and Noteworthy] documentation.
+
+[[running-tests-ide-netbeans]]
+==== NetBeans
+
+NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
+https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
+
+For more information consult the JUnit 5 section of the
+https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
+release notes].
+
+[[running-tests-ide-vscode]]
+==== Visual Studio Code
+
+https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
+Platform via the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
+Runner] extension which is installed by default as part of the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
+Extension Pack].
+
+For more information consult the _Testing_ section of the
+https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
+documentation.
+
+[[running-tests-ide-other]]
+==== Other IDEs
+
+If you are using an editor or IDE other than one of those listed in the previous sections,
+and it doesn't support running tests on the JUnit Platform, you can use the
+<<running-tests-console-launcher>> to run them from the command line.
+
+[[running-tests-build]]
+=== Build Support
+
+[[running-tests-build-gradle]]
+==== Gradle
+
+Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
+https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
+for executing tests on the JUnit Platform. To enable it, you need to specify
+`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform()
+}
+----
+
+Filtering by <<running-tests-tags, tags>>,
+<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform {
+		includeTags("fast", "smoke & feature-a")
+		// excludeTags("slow", "ci")
+		includeEngines("junit-jupiter")
+		// excludeEngines("junit-vintage")
+	}
+}
+----
+
+Please refer to the
+https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
+for a comprehensive list of options.
+
+[[running-tests-build-gradle-bom]]
+===== Aligning dependency versions
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Explicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation(platform("org.junit:junit-bom:{version}"))
+	testImplementation("org.junit.jupiter:junit-jupiter")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+Since all JUnit artifacts declare a
+https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
+you usually don't need to declare an explicit dependency on it yourself. Instead, it's
+sufficient to declare _one_ regular dependency that includes a version number. Gradle will
+then pull in the BOM automatically so you can omit the version for all other JUnit
+artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Implicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
+}
+----
+<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
+<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
+
+[WARNING]
+.Declaring a dependency on junit-platform-launcher
+====
+Even though pre-8.0 versions of Gradle don't require declaring an explicit
+dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
+of JUnit artifacts on the test runtime classpath are aligned.
+
+Moreover, doing so is recommended and in some cases even required when importing the
+project into an IDE like <<running-tests-ide-eclipse>> or
+<<running-tests-ide-intellij-idea>>.
+====
+
+[[running-tests-build-gradle-engines-configure]]
+===== Configuring Test Engines
+
+In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
+
+To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
+on the dependency-aggregating JUnit Jupiter artifact similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Alternatively, you can use Gradle's
+https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
+support.
+
+[source,kotlin,indent=0]
+[subs=attributes+]
+.Kotlin DSL
+----
+testing {
+	suites {
+		named<JvmTestSuite>("test") {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Groovy DSL
+----
+testing {
+	suites {
+		test {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
+dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
+implementation similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("junit:junit:{junit4-version}")
+	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+[[running-tests-build-gradle-config-params]]
+===== Configuration Parameters
+
+The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
+Platform <<running-tests-config-params, configuration parameters>> to influence test
+discovery and execution. However, you can provide configuration parameters within the
+build script via system properties (as shown below) or via the
+`junit-platform.properties` file.
+
+[source,groovy,indent=0]
+----
+test {
+	// ...
+	systemProperty("junit.jupiter.conditions.deactivate", "*")
+	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
+	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
+	// ...
+}
+----
+
+[[running-tests-build-gradle-logging]]
+===== Configuring Logging (optional)
+
+JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
+emit warnings and debug information. Please refer to the official documentation of
+`{LogManager}` for configuration options.
+
+Alternatively, it's possible to redirect log messages to other logging frameworks such as
+{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
+`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
+qualified class name_ of the `{LogManager}` implementation to use. The example below
+demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
+details).
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
+	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
+	systemProperty("log4j2.disableJmx", "true")
+}
+----
+
+Other logging frameworks provide different means to redirect messages logged using
+`java.util.logging`. For example, for {Logback} you can use the
+https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
+dependency to the test runtime classpath.
+
+[[running-tests-build-maven]]
+==== Maven
+
+Maven Surefire and Maven Failsafe provide
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
+for executing tests on the JUnit Platform. The `pom.xml` file in the
+`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
+and can serve as a starting point for configuring your Maven build.
+
+[WARNING]
+.Minimum required version of Maven Surefire/Failsafe
+====
+As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
+====
+
+[[running-tests-build-maven-bom]]
+===== Aligning dependency versions
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+[[running-tests-build-maven-engines-configure]]
+===== Configuring Test Engines
+
+In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
+`TestEngine` implementation must be added to the test classpath.
+
+To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
+on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
+following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>org.junit.jupiter</groupId>
+			<artifactId>junit-jupiter</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
+long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
+`TestEngine` implementation similar to the following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>junit</groupId>
+			<artifactId>junit</artifactId>
+			<version>{junit4-version}</version>
+			<scope>test</scope>
+		</dependency>
+		<dependency>
+			<groupId>org.junit.vintage</groupId>
+			<artifactId>junit-vintage-engine</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-filter-test-class-names]]
+===== Filtering by Test Class Names
+
+The Maven Surefire Plugin will scan for test classes whose fully qualified names match
+the following patterns.
+
+- `+++**/Test*.java+++`
+- `+++**/*Test.java+++`
+- `+++**/*Tests.java+++`
+- `+++**/*TestCase.java+++`
+
+Moreover, it will exclude all nested classes (including static member classes) by default.
+
+Note, however, that you can override this default behavior by configuring explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
+from excluding static member classes, you can override its exclude rules as follows.
+
+[source,xml,indent=0]
+[subs=attributes+]
+.Overriding exclude rules of Maven Surefire
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<excludes>
+						<exclude/>
+					</excludes>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Please see the
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
+documentation for Maven Surefire for details.
+
+[[running-tests-build-maven-filter-tags]]
+===== Filtering by Tags
+
+You can filter tests by <<running-tests-tags, tags>> or
+<<running-tests-tag-expressions, tag expressions>> using the following configuration
+properties.
+
+- to include _tags_ or _tag expressions_, use `groups`.
+- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<groups>acceptance | !feature-a</groups>
+					<excludedGroups>integration, regression</excludedGroups>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-config-params]]
+===== Configuration Parameters
+
+You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
+influence test discovery and execution by declaring the `configurationParameters`
+property and providing key-value pairs using the Java `Properties` file syntax (as shown
+below) or via the `junit-platform.properties` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<properties>
+						<configurationParameters>
+							junit.jupiter.conditions.deactivate = *
+							junit.jupiter.extensions.autodetection.enabled = true
+							junit.jupiter.testinstance.lifecycle.default = per_class
+						</configurationParameters>
+					</properties>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-ant]]
+==== Ant
+
+Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
+provides native support for launching tests on the JUnit Platform. The `junitlauncher`
+task is solely responsible for launching the JUnit Platform and passing it the selected
+collection of tests. The JUnit Platform then delegates to registered test engines to
+discover and execute the tests.
+
+The `junitlauncher` task attempts to align as closely as possible with native Ant
+constructs such as
+link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
+for allowing users to select the tests that they want executed by test engines. This gives
+the task a consistent and natural feel when compared to many other core Ant tasks.
+
+Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
+
+The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
+the task and can serve as a starting point.
+
+===== Basic Usage
+
+The following example demonstrates how to configure the `junitlauncher` task to select a
+single test class (i.e., `com.example.project.CalculatorTests`).
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+
+	<!-- ... -->
+
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<test name="com.example.project.CalculatorTests" />
+	</junitlauncher>
+----
+
+The `test` element allows you to specify a single test class that you want to be selected
+and executed. The `classpath` element allows you to specify the classpath to be used to
+launch the JUnit Platform. This classpath will also be used to locate test classes that
+are part of the execution.
+
+The following example demonstrates how to configure the `junitlauncher` task to select
+test classes from multiple locations.
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+	<!-- ... -->
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<testclasses outputdir="${output.dir}">
+			<fileset dir="${build.classes.dir}">
+				<include name="org/example/**/demo/**/" />
+			</fileset>
+			<fileset dir="${some.other.dir}">
+				<include name="org/myapp/**/" />
+			</fileset>
+		</testclasses>
+	</junitlauncher>
+----
+
+In the above example, the `testclasses` element allows you to select multiple test
+classes that reside in different locations.
+
+For further details on usage and configuration options please refer to the official Ant
+documentation for the
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
+
+[[running-tests-build-spring-boot]]
+==== Spring Boot
+
+link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
+managing the version of JUnit used in your project. In addition, the
+`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
+Jupiter, AssertJ, Mockito, etc.
+
+If your build relies on dependency management support from Spring Boot, you should not
+import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
+result in duplicate (and potentially conflicting) management of JUnit dependencies.
+
+If you need to override the version of a dependency used in your Spring Boot application,
+you have to override the exact name of the
+link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
+defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
+Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
+changing a dependency version is documented for both
+link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
+and
+link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
+
+With Gradle you can override the JUnit Jupiter version by including the following in your
+`build.gradle` file.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+	ext['junit-jupiter.version'] = '{version}'
+----
+
+With Maven you can override the JUnit Jupiter version by including the following in your
+`pom.xml` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<properties>
+		<junit-jupiter.version>{version}</junit-jupiter.version>
+	</properties>
+----
+
+[[running-tests-console-launcher]]
+=== Console Launcher
+
+The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
+Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
+Jupiter tests and print test execution results to the console.
+
+An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
+contains the contents of all of its dependencies is published in the {Maven_Central}
+repository under the
+https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
+directory. It contains the contents of the following artifacts:
+
+include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
+
+[NOTE]
+====
+Since the `junit-platform-console-standalone` JAR contains the contents of all of its
+dependencies, its Maven POM does not declare any dependencies.
+
+Furthermore, it is not very likely that you would need to include a dependency on the
+`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
+script. On the contrary, the executable `junit-platform-console-standalone` JAR is
+typically invoked directly from the command line or a shell script without a build script.
+
+If you need to declare dependencies in your build script on some of the artifacts
+contained in the `junit-platform-console-standalone` artifact, you should declare
+dependencies only on the JUnit artifacts that are used in your project. To simplify
+dependency management of JUnit artifacts in your build, you may wish to use the
+`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
+details.
+====
+
+You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
+standalone `ConsoleLauncher` as shown below.
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
+
+├─ JUnit Vintage
+│  └─ example.JUnit4Tests
+│     └─ standardJUnit4Test ✔
+└─ JUnit Jupiter
+   ├─ StandardTests
+   │  ├─ succeedingTest() ✔
+   │  └─ skippedTest() ↷ for demonstration purposes
+   └─ A special test case
+      ├─ Custom test name containing spaces ✔
+      ├─ ╯°□°)╯ ✔
+      └─ 😱 ✔
+
+Test run finished after 64 ms
+[         5 containers found      ]
+[         0 containers skipped    ]
+[         5 containers started    ]
+[         0 containers aborted    ]
+[         5 containers successful ]
+[         0 containers failed     ]
+[         6 tests found           ]
+[         1 tests skipped         ]
+[         5 tests started         ]
+[         0 tests aborted         ]
+[         5 tests successful      ]
+[         0 tests failed          ]
+----
+
+You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
+all jars in a directory):
+
+[source,console,subs=attributes+]
+----
+$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
+----
+
+[[running-tests-console-launcher-options]]
+==== Subcommands and Options
+
+The `{ConsoleLauncher}` provides the following subcommands:
+
+----
+include::{consoleLauncherOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-discovering-tests]]
+===== Discovering tests
+
+----
+include::{consoleLauncherDiscoverOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-executing-tests]]
+===== Executing tests
+
+.Exit Code
+NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
+All non-zero codes indicate an error of some sort. For example, status code `1`
+is returned if any containers or tests failed. If no tests are discovered and the
+`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
+with a status code of `2`. Unexpected or invalid user input yields a status code
+of `3`. An exit code of `-1` indicates an unspecified error condition.
+
+----
+include::{consoleLauncherExecuteOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-listing-test-engines]]
+===== Listing test engines
+
+----
+include::{consoleLauncherEnginesOptionsFile}[]
+----
+
+[[running-tests-console-launcher-argument-files]]
+==== Argument Files (@-files)
+
+On some platforms you may run into system limitations on the length of a command line when
+creating a command line with lots of options or with long arguments.
+
+The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
+are files that themselves contain arguments to be passed to the command. When the
+underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
+argument beginning with the character `@`, it expands the contents of that file into the
+argument list.
+
+The arguments within a file can be separated by spaces or newlines. If an argument
+contains embedded whitespace, the whole argument should be wrapped in double or single
+quotes -- for example, `"-f=My Files/Stuff.java"`.
+
+If the argument file does not exist or cannot be read, the argument will be treated
+literally and will not be removed. This will likely result in an "unmatched argument"
+error message. You can troubleshoot such errors by executing the command with the
+`picocli.trace` system property set to `DEBUG`.
+
+Multiple _@-files_ may be specified on the command line. The specified path may be
+relative to the current directory or absolute.
+
+You can pass a real parameter with an initial `@` character by escaping it with an
+additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
+subject to expansion.
+
+[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
+==== Redirecting Standard Output/Error to Files
+
+You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
+files using the `--redirect-stdout` and `--redirect-stderr` options:
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
+  --redirect-stdout=stdout.txt \
+  --redirect-stderr=stderr.txt
+----
+
+[NOTE]
+====
+If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
+output streams will be redirected to that file.
+
+The default charset is used for writing to the files.
+====
+
+[[running-tests-console-launcher-color-customization]]
+==== Color Customization
+
+The colors used in the output of the `{ConsoleLauncher}` can be customized.
+The option `--single-color` will apply a built-in monochrome style, while
+`--color-palette` will accept a properties file to override the
+https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
+The properties file below demonstrates the default style:
+
+[source,properties,indent=0]
+----
+SUCCESSFUL = 32
+ABORTED = 33
+FAILED = 31
+SKIPPED = 35
+CONTAINER = 35
+TEST = 34
+DYNAMIC = 35
+REPORTED = 37
+----
+
+[[running-tests-source-launcher]]
+=== Source Launcher
+
+Starting with Java 25 it is possible to write minimal source code test programs
+using the `org.junit.start` module. For example, like in a `HelloTests.java`
+file reading:
+
+```java
+import module org.junit.start;
+
+void main() {
+  JUnit.run();
+}
+
+@Test
+void stringLength() {
+  Assertions.assertEquals(11, "Hello JUnit".length());
+}
+```
+With all required modular JAR files available in a local `lib/` directory, the
+following Java 25+ command will discover and execute tests using the JUnit Platform.
+It will also print the result tree to the console.
+
+```shell
+java --module-path lib --add-modules org.junit.start HelloTests.java
+╷
+└─ JUnit Jupiter ✔
+   └─ HelloTests ✔
+      └─ stringLength() ✔
+```
+
+Find JUnit's class API documentation here: {JUnit}
+
+[[running-tests-discovery-selectors]]
+=== Discovery Selectors
+
+The JUnit Platform provides a rich set of discovery selectors that can be used to specify
+which tests should be discovered or executed.
+
+Discovery selectors can be created programmatically using the factory methods in the
+`{DiscoverySelectors}` class, specified declaratively via annotations when using the
+<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
+generically as strings via their identifiers.
+
+The following discovery selectors are provided out of the box:
+
+|===
+| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
+
+| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
+| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
+| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
+| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
+| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
+| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
+| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
+| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
+| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
+| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
+| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
+| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
+| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
+|===
+
+
+[[running-tests-config-params]]
+=== Configuration Parameters
+
+In addition to instructing the platform which test classes and test engines to include,
+which packages to scan, etc., it is sometimes necessary to provide additional custom
+configuration parameters that are specific to a particular test engine, listener, or
+registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
+parameters_ for the following use cases.
+
+- <<writing-tests-test-instance-lifecycle-changing-default>>
+- <<extensions-registration-automatic-enabling>>
+- <<extensions-conditions-deactivation>>
+- <<writing-tests-display-name-generator-default>>
+
+_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
+engines running on the JUnit Platform via one of the following mechanisms.
+
+1. The `configurationParameter()` and `configurationParameters()` methods in
+   `LauncherDiscoveryRequestBuilder` which
+   is used to build a request supplied to the <<launcher-api, Launcher API>>.
+    +
+   When running tests via one of the tools provided by the JUnit Platform you can specify
+   configuration parameters as follows:
+   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
+     option.
+   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
+     `systemProperties` DSL.
+   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
+     `configurationParameters` property.
+2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
+    +
+   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
+   specify custom configuration files using the `--config-resource` command-line option.
+3. JVM system properties.
+4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
+   in the root of the class path that follows the syntax rules for Java `Properties`
+   files.
+
+NOTE: Configuration parameters are looked up in the exact order defined above.
+Consequently, configuration parameters supplied directly to the `Launcher` take
+precedence over those supplied via custom configuration files, system properties, and the
+default configuration file. Similarly, configuration parameters supplied via system
+properties take precedence over those supplied via the default configuration file.
+
+[[running-tests-config-params-deactivation-pattern]]
+==== Pattern Matching Syntax
+
+This section describes the pattern matching syntax that is applied to the _configuration
+parameters_ used for the following features.
+
+- <<extensions-conditions-deactivation>>
+- <<launcher-api-listeners-custom-deactivation>>
+- <<stacktrace-pruning>>
+- <<extensions-registration-automatic-filtering>>
+
+If the value for the given _configuration parameter_ consists solely of an asterisk
+(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
+will be treated as a comma-separated list of patterns where each pattern will be matched
+against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
+a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
+(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
+pattern will be matched one-to-one against a FQCN.
+
+Examples:
+
+- `+++*+++`: matches all candidate classes.
+- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
+  any of its subpackages.
+- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
+  `MyCustomImpl`.
+- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
+- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
+  `System` or `Unit`.
+- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
+  `org.example.MyCustomImpl`.
+- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
+  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
+
+[[running-tests-tags]]
+=== Tags
+
+Tags are a JUnit Platform concept for marking and filtering tests. The programming model
+for adding tags to containers and tests is defined by the testing framework. For example,
+in JUnit Jupiter based tests, the `@Tag` annotation (see
+<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
+Vintage engine maps `@Category` annotations to tags (see
+<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
+own annotation or other means for users to specify tags.
+
+[[running-tests-tag-syntax-rules]]
+==== Syntax Rules for Tags
+
+Regardless how a tag is specified, the JUnit Platform enforces the following rules:
+
+* A tag must not be `null` or _blank_.
+* A _stripped_ tag must not contain whitespace.
+* A _stripped_ tag must not contain ISO control characters.
+* A _stripped_ tag must not contain any of the following _reserved characters_.
+- `,`: _comma_
+- `(`: _left parenthesis_
+- `)`: _right parenthesis_
+- `&`: _ampersand_
+- `|`: _vertical bar_
+- `!`: _exclamation point_
+
+NOTE: In the above context, "stripped" means that leading and trailing whitespace
+characters have been removed using `java.lang.String.strip()`.
+
+[[running-tests-tag-expressions]]
+==== Tag Expressions
+
+Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
+`(` and `)` can be used to adjust for operator precedence.
+
+Two special expressions are supported, `any()` and `none()`, which select all tests _with_
+any tags at all, and all tests _without_ any tags, respectively.
+These special expressions may be combined with other expressions just like normal tags.
+
+.Operators (in descending order of precedence)
+|===
+| Operator | Meaning | Associativity
+
+| `!`      | not     | right
+| `&`      | and     | left
+| `\|`     | or      | left
+|===
+
+If you are tagging your tests across multiple dimensions, tag expressions help you to
+select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
+_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
+expressions can be useful.
+
+[%header,cols="40,60"]
+|===
+| Tag Expression
+| Selection
+
+| `+++product+++`
+| all tests for *product*
+
+| `+++catalog \| shipping+++`
+| all tests for *catalog* plus all tests for *shipping*
+
+| `+++catalog &amp; shipping+++`
+| all tests for the intersection between *catalog* and *shipping*
+
+| `+++product &amp; !end-to-end+++`
+| all tests for *product*, but not the _end-to-end_ tests
+
+| `+++(micro \| integration) &amp; (product \| shipping)+++`
+| all _micro_ or _integration_ tests for *product* or *shipping*
+|===
+
+[[running-tests-capturing-output]]
+=== Capturing Standard Output/Error
+
+The JUnit Platform provides opt-in support for capturing output printed to `System.out`
+and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
+`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
+parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
+to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
+
+If enabled, the JUnit Platform captures the corresponding output and publishes it as a
+report entry using the `stdout` or `stderr` keys to all registered
+`{TestExecutionListener}` instances immediately before reporting the test or container as
+finished.
+
+Please note that the captured output will only contain output emitted by the thread that
+was used to execute a container or test. Any output by other threads will be omitted
+because particularly when
+<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
+to attribute it to a specific test or container.
+
+[[running-tests-listeners]]
+=== Using Listeners and Interceptors
+
+The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
+and custom user code to react to events fired at various points during the discovery and
+execution of a `TestPlan`.
+
+* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
+  closed.
+* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
+  `LauncherSession`.
+* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
+* `{TestExecutionListener}`: receives events that occur during test execution.
+
+The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
+registered automatically for you in order to support some feature of the build tool or IDE.
+
+The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
+order to produce some form of report or to display a graphical representation of the test
+plan in an IDE. Such listeners may be implemented and automatically registered by a build
+tool or IDE, or they may be included in a third-party library – potentially registered
+for you automatically. You can also implement and register your own listeners.
+
+For details on registering and configuring listeners, see the following sections of this
+guide.
+
+* <<launcher-api-launcher-session-listeners-custom>>
+* <<launcher-api-launcher-interceptors-custom>>
+* <<launcher-api-launcher-discovery-listeners-custom>>
+* <<launcher-api-listeners-custom>>
+* <<launcher-api-listeners-config>>
+* <<launcher-api-listeners-custom-deactivation>>
+
+The JUnit Platform provides the following listeners which you may wish to use with your
+test suite.
+
+<<junit-platform-reporting>> ::
+  `{LegacyXmlReportGeneratingListener}` can be used via the
+  <<running-tests-console-launcher>> or registered manually to generate XML reports
+  compatible with the de facto standard for JUnit 4 based test reports.
++
+`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
+specified by {OpenTestReporting}. It is auto-registered and can be enabled and
+configured via <<running-tests-config-params>>.
++
+See <<junit-platform-reporting>> for details.
+
+<<running-tests-listeners-flight-recorder>> ::
+  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
+  Java Flight Recorder events during test discovery and execution.
+
+`{LoggingListener}` ::
+  `TestExecutionListener` for logging informational messages for all events via a
+  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
+
+`{SummaryGeneratingListener}` ::
+  `TestExecutionListener` that generates a summary of the test execution which can be
+  printed via a `PrintWriter`.
+
+`{UniqueIdTrackingListener}` ::
+  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
+  or executed during the execution of the `TestPlan` and generates a file containing the
+  unique IDs once execution of the `TestPlan` has finished.
+
+[[running-tests-listeners-flight-recorder]]
+==== Flight Recorder Support
+
+The JUnit Platform provides opt-in support for generating Flight Recorder events.
+https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
+follows.
+
+> Flight Recorder records events originating from applications, the JVM, and the OS.
+Events are stored in a single file that can be attached to bug reports and examined by
+support engineers, allowing after-the-fact analysis of issues in the period leading up
+to a problem.
+
+In order to record Flight Recorder events generated while running tests, you need to
+start flight recording when launching a test suite via the following java command line
+option.
+
+   -XX:StartFlightRecording:filename=...
+
+Please consult the manual of your build tool for the appropriate commands.
+
+To analyze the recorded events, use the
+https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
+command line tool shipped with recent JDKs or open the recording file with
+https://jdk.java.net/jmc/[JDK Mission Control].
+
+[[stacktrace-pruning]]
+=== Stack Trace Pruning
+
+The JUnit Platform provides built-in support for pruning stack traces produced by failing
+tests. This feature is enabled by default but can be disabled by setting the
+`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
+
+When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
+packages are removed from the stack trace, unless the calls occur after the test itself
+or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
+never be excluded.
+
+In addition, all elements prior to and including the first call from the JUnit Platform
+`Launcher` will be removed.
+
+[[running-tests-discovery-issues]]
+=== Discovery Issues
+
+Test engines may encounter issues during test discovery. For example, the declaration of a
+test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
+Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
+report them with different severity levels:
+
+INFO::
+Indicates that the engine encountered something that could be potentially problematic, but
+could also happen due to a valid setup or configuration.
+
+WARNING::
+Indicates that the engine encountered something that is problematic and might lead to
+unexpected behavior or will be removed or changed in a future release.
+
+ERROR::
+Indicates that the engine encountered something that is definitely problematic and will
+lead to unexpected behavior.
+
+If an engine reports an issue with a severity equal to or higher than a configurable
+_critical_ severity, its tests will not be executed. Instead, the engine will be reported
+as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
+Non-critical issues will be logged but will not prevent the engine from executing its
+tests. The `junit.platform.discovery.issue.severity.critical`
+<<running-tests-config-params, configuration parameter>> can be used to set the critical
+severity level. Currently, the default value is `ERROR` but it may be changed in a future
+release.
+
+TIP: To surface all discovery issues in your project, it is recommended to set the
+`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
+
+In addition, registered `{LauncherDiscoveryListener}` implementations can receive
+discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
+report issues to the user in a more user-friendly way. For example, IDEs may choose to
+display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc b/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc
new file mode 100644
index 000000000000..3099a146c2b4
--- /dev/null
+++ b/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc
@@ -0,0 +1,1216 @@
+[[running-tests]]
+== Running Tests
+
+[[running-tests-ide]]
+=== IDE Support
+
+[[running-tests-ide-intellij-idea]]
+==== IntelliJ IDEA
+
+IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
+information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
+however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
+IDEA download the following JARs automatically based on the API version used in the
+project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
+
+In order to use a different JUnit version (e.g., {version}), you may need to
+include the corresponding versions of the `junit-platform-launcher`,
+`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
+
+.Additional Gradle Dependencies
+[source,groovy]
+[subs=attributes+]
+----
+testImplementation(platform("org.junit:junit-bom:{version}"))
+testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
+testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
+----
+
+.Additional Maven Dependencies
+[source,xml]
+[subs=attributes+]
+----
+<!-- ... -->
+<dependencies>
+	<dependency>
+		<groupId>org.junit.platform</groupId>
+		<artifactId>junit-platform-launcher</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.jupiter</groupId>
+		<artifactId>junit-jupiter-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.vintage</groupId>
+		<artifactId>junit-vintage-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+</dependencies>
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+[[running-tests-ide-eclipse]]
+==== Eclipse
+
+Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
+release.
+
+For more information on using JUnit Platform in Eclipse consult the official _Eclipse
+support for JUnit 5_ section of the
+https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
+(4.7.1a) - New and Noteworthy] documentation.
+
+[[running-tests-ide-netbeans]]
+==== NetBeans
+
+NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
+https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
+
+For more information consult the JUnit 5 section of the
+https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
+release notes].
+
+[[running-tests-ide-vscode]]
+==== Visual Studio Code
+
+https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
+Platform via the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
+Runner] extension which is installed by default as part of the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
+Extension Pack].
+
+For more information consult the _Testing_ section of the
+https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
+documentation.
+
+[[running-tests-ide-other]]
+==== Other IDEs
+
+If you are using an editor or IDE other than one of those listed in the previous sections,
+and it doesn't support running tests on the JUnit Platform, you can use the
+<<running-tests-console-launcher>> to run them from the command line.
+
+[[running-tests-build]]
+=== Build Support
+
+[[running-tests-build-gradle]]
+==== Gradle
+
+Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
+https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
+for executing tests on the JUnit Platform. To enable it, you need to specify
+`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform()
+}
+----
+
+Filtering by <<running-tests-tags, tags>>,
+<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform {
+		includeTags("fast", "smoke & feature-a")
+		// excludeTags("slow", "ci")
+		includeEngines("junit-jupiter")
+		// excludeEngines("junit-vintage")
+	}
+}
+----
+
+Please refer to the
+https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
+for a comprehensive list of options.
+
+[[running-tests-build-gradle-bom]]
+===== Aligning dependency versions
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Explicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation(platform("org.junit:junit-bom:{version}"))
+	testImplementation("org.junit.jupiter:junit-jupiter")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+Since all JUnit artifacts declare a
+https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
+you usually don't need to declare an explicit dependency on it yourself. Instead, it's
+sufficient to declare _one_ regular dependency that includes a version number. Gradle will
+then pull in the BOM automatically so you can omit the version for all other JUnit
+artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Implicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
+}
+----
+<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
+<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
+
+[WARNING]
+.Declaring a dependency on junit-platform-launcher
+====
+Even though pre-8.0 versions of Gradle don't require declaring an explicit
+dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
+of JUnit artifacts on the test runtime classpath are aligned.
+
+Moreover, doing so is recommended and in some cases even required when importing the
+project into an IDE like <<running-tests-ide-eclipse>> or
+<<running-tests-ide-intellij-idea>>.
+====
+
+[[running-tests-build-gradle-engines-configure]]
+===== Configuring Test Engines
+
+In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
+
+To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
+on the dependency-aggregating JUnit Jupiter artifact similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Alternatively, you can use Gradle's
+https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
+support.
+
+[source,kotlin,indent=0]
+[subs=attributes+]
+.Kotlin DSL
+----
+testing {
+	suites {
+		named<JvmTestSuite>("test") {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Groovy DSL
+----
+testing {
+	suites {
+		test {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
+dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
+implementation similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("junit:junit:{junit4-version}")
+	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+[[running-tests-build-gradle-config-params]]
+===== Configuration Parameters
+
+The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
+Platform <<running-tests-config-params, configuration parameters>> to influence test
+discovery and execution. However, you can provide configuration parameters within the
+build script via system properties (as shown below) or via the
+`junit-platform.properties` file.
+
+[source,groovy,indent=0]
+----
+test {
+	// ...
+	systemProperty("junit.jupiter.conditions.deactivate", "*")
+	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
+	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
+	// ...
+}
+----
+
+[[running-tests-build-gradle-logging]]
+===== Configuring Logging (optional)
+
+JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
+emit warnings and debug information. Please refer to the official documentation of
+`{LogManager}` for configuration options.
+
+Alternatively, it's possible to redirect log messages to other logging frameworks such as
+{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
+`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
+qualified class name_ of the `{LogManager}` implementation to use. The example below
+demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
+details).
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
+	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
+	systemProperty("log4j2.disableJmx", "true")
+}
+----
+
+Other logging frameworks provide different means to redirect messages logged using
+`java.util.logging`. For example, for {Logback} you can use the
+https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
+dependency to the test runtime classpath.
+
+[[running-tests-build-maven]]
+==== Maven
+
+Maven Surefire and Maven Failsafe provide
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
+for executing tests on the JUnit Platform. The `pom.xml` file in the
+`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
+and can serve as a starting point for configuring your Maven build.
+
+[WARNING]
+.Minimum required version of Maven Surefire/Failsafe
+====
+As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
+====
+
+[[running-tests-build-maven-bom]]
+===== Aligning dependency versions
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+[[running-tests-build-maven-engines-configure]]
+===== Configuring Test Engines
+
+In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
+`TestEngine` implementation must be added to the test classpath.
+
+To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
+on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
+following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>org.junit.jupiter</groupId>
+			<artifactId>junit-jupiter</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
+long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
+`TestEngine` implementation similar to the following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>junit</groupId>
+			<artifactId>junit</artifactId>
+			<version>{junit4-version}</version>
+			<scope>test</scope>
+		</dependency>
+		<dependency>
+			<groupId>org.junit.vintage</groupId>
+			<artifactId>junit-vintage-engine</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-filter-test-class-names]]
+===== Filtering by Test Class Names
+
+The Maven Surefire Plugin will scan for test classes whose fully qualified names match
+the following patterns.
+
+- `+++**/Test*.java+++`
+- `+++**/*Test.java+++`
+- `+++**/*Tests.java+++`
+- `+++**/*TestCase.java+++`
+
+Moreover, it will exclude all nested classes (including static member classes) by default.
+
+Note, however, that you can override this default behavior by configuring explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
+from excluding static member classes, you can override its exclude rules as follows.
+
+[source,xml,indent=0]
+[subs=attributes+]
+.Overriding exclude rules of Maven Surefire
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<excludes>
+						<exclude/>
+					</excludes>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Please see the
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
+documentation for Maven Surefire for details.
+
+[[running-tests-build-maven-filter-tags]]
+===== Filtering by Tags
+
+You can filter tests by <<running-tests-tags, tags>> or
+<<running-tests-tag-expressions, tag expressions>> using the following configuration
+properties.
+
+- to include _tags_ or _tag expressions_, use `groups`.
+- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<groups>acceptance | !feature-a</groups>
+					<excludedGroups>integration, regression</excludedGroups>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-config-params]]
+===== Configuration Parameters
+
+You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
+influence test discovery and execution by declaring the `configurationParameters`
+property and providing key-value pairs using the Java `Properties` file syntax (as shown
+below) or via the `junit-platform.properties` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<properties>
+						<configurationParameters>
+							junit.jupiter.conditions.deactivate = *
+							junit.jupiter.extensions.autodetection.enabled = true
+							junit.jupiter.testinstance.lifecycle.default = per_class
+						</configurationParameters>
+					</properties>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-ant]]
+==== Ant
+
+Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
+provides native support for launching tests on the JUnit Platform. The `junitlauncher`
+task is solely responsible for launching the JUnit Platform and passing it the selected
+collection of tests. The JUnit Platform then delegates to registered test engines to
+discover and execute the tests.
+
+The `junitlauncher` task attempts to align as closely as possible with native Ant
+constructs such as
+link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
+for allowing users to select the tests that they want executed by test engines. This gives
+the task a consistent and natural feel when compared to many other core Ant tasks.
+
+Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
+
+The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
+the task and can serve as a starting point.
+
+===== Basic Usage
+
+The following example demonstrates how to configure the `junitlauncher` task to select a
+single test class (i.e., `com.example.project.CalculatorTests`).
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+
+	<!-- ... -->
+
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<test name="com.example.project.CalculatorTests" />
+	</junitlauncher>
+----
+
+The `test` element allows you to specify a single test class that you want to be selected
+and executed. The `classpath` element allows you to specify the classpath to be used to
+launch the JUnit Platform. This classpath will also be used to locate test classes that
+are part of the execution.
+
+The following example demonstrates how to configure the `junitlauncher` task to select
+test classes from multiple locations.
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+	<!-- ... -->
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<testclasses outputdir="${output.dir}">
+			<fileset dir="${build.classes.dir}">
+				<include name="org/example/**/demo/**/" />
+			</fileset>
+			<fileset dir="${some.other.dir}">
+				<include name="org/myapp/**/" />
+			</fileset>
+		</testclasses>
+	</junitlauncher>
+----
+
+In the above example, the `testclasses` element allows you to select multiple test
+classes that reside in different locations.
+
+For further details on usage and configuration options please refer to the official Ant
+documentation for the
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
+
+[[running-tests-build-spring-boot]]
+==== Spring Boot
+
+link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
+managing the version of JUnit used in your project. In addition, the
+`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
+Jupiter, AssertJ, Mockito, etc.
+
+If your build relies on dependency management support from Spring Boot, you should not
+import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
+result in duplicate (and potentially conflicting) management of JUnit dependencies.
+
+If you need to override the version of a dependency used in your Spring Boot application,
+you have to override the exact name of the
+link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
+defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
+Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
+changing a dependency version is documented for both
+link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
+and
+link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
+
+With Gradle you can override the JUnit Jupiter version by including the following in your
+`build.gradle` file.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+	ext['junit-jupiter.version'] = '{version}'
+----
+
+With Maven you can override the JUnit Jupiter version by including the following in your
+`pom.xml` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<properties>
+		<junit-jupiter.version>{version}</junit-jupiter.version>
+	</properties>
+----
+
+[[running-tests-console-launcher]]
+=== Console Launcher
+
+The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
+Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
+Jupiter tests and print test execution results to the console.
+
+An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
+contains the contents of all of its dependencies is published in the {Maven_Central}
+repository under the
+https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
+directory. It contains the contents of the following artifacts:
+
+include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
+
+[NOTE]
+====
+Since the `junit-platform-console-standalone` JAR contains the contents of all of its
+dependencies, its Maven POM does not declare any dependencies.
+
+Furthermore, it is not very likely that you would need to include a dependency on the
+`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
+script. On the contrary, the executable `junit-platform-console-standalone` JAR is
+typically invoked directly from the command line or a shell script without a build script.
+
+If you need to declare dependencies in your build script on some of the artifacts
+contained in the `junit-platform-console-standalone` artifact, you should declare
+dependencies only on the JUnit artifacts that are used in your project. To simplify
+dependency management of JUnit artifacts in your build, you may wish to use the
+`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
+details.
+====
+
+You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
+standalone `ConsoleLauncher` as shown below.
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
+
+├─ JUnit Vintage
+│  └─ example.JUnit4Tests
+│     └─ standardJUnit4Test ✔
+└─ JUnit Jupiter
+   ├─ StandardTests
+   │  ├─ succeedingTest() ✔
+   │  └─ skippedTest() ↷ for demonstration purposes
+   └─ A special test case
+      ├─ Custom test name containing spaces ✔
+      ├─ ╯°□°)╯ ✔
+      └─ 😱 ✔
+
+Test run finished after 64 ms
+[         5 containers found      ]
+[         0 containers skipped    ]
+[         5 containers started    ]
+[         0 containers aborted    ]
+[         5 containers successful ]
+[         0 containers failed     ]
+[         6 tests found           ]
+[         1 tests skipped         ]
+[         5 tests started         ]
+[         0 tests aborted         ]
+[         5 tests successful      ]
+[         0 tests failed          ]
+----
+
+You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
+all jars in a directory):
+
+[source,console,subs=attributes+]
+----
+$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
+----
+
+[[running-tests-console-launcher-options]]
+==== Subcommands and Options
+
+The `{ConsoleLauncher}` provides the following subcommands:
+
+----
+include::{consoleLauncherOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-discovering-tests]]
+===== Discovering tests
+
+----
+include::{consoleLauncherDiscoverOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-executing-tests]]
+===== Executing tests
+
+.Exit Code
+NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
+All non-zero codes indicate an error of some sort. For example, status code `1`
+is returned if any containers or tests failed. If no tests are discovered and the
+`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
+with a status code of `2`. Unexpected or invalid user input yields a status code
+of `3`. An exit code of `-1` indicates an unspecified error condition.
+
+----
+include::{consoleLauncherExecuteOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-listing-test-engines]]
+===== Listing test engines
+
+----
+include::{consoleLauncherEnginesOptionsFile}[]
+----
+
+[[running-tests-console-launcher-argument-files]]
+==== Argument Files (@-files)
+
+On some platforms you may run into system limitations on the length of a command line when
+creating a command line with lots of options or with long arguments.
+
+The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
+are files that themselves contain arguments to be passed to the command. When the
+underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
+argument beginning with the character `@`, it expands the contents of that file into the
+argument list.
+
+The arguments within a file can be separated by spaces or newlines. If an argument
+contains embedded whitespace, the whole argument should be wrapped in double or single
+quotes -- for example, `"-f=My Files/Stuff.java"`.
+
+If the argument file does not exist or cannot be read, the argument will be treated
+literally and will not be removed. This will likely result in an "unmatched argument"
+error message. You can troubleshoot such errors by executing the command with the
+`picocli.trace` system property set to `DEBUG`.
+
+Multiple _@-files_ may be specified on the command line. The specified path may be
+relative to the current directory or absolute.
+
+You can pass a real parameter with an initial `@` character by escaping it with an
+additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
+subject to expansion.
+
+[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
+==== Redirecting Standard Output/Error to Files
+
+You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
+files using the `--redirect-stdout` and `--redirect-stderr` options:
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
+  --redirect-stdout=stdout.txt \
+  --redirect-stderr=stderr.txt
+----
+
+[NOTE]
+====
+If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
+output streams will be redirected to that file.
+
+The default charset is used for writing to the files.
+====
+
+[[running-tests-console-launcher-color-customization]]
+==== Color Customization
+
+The colors used in the output of the `{ConsoleLauncher}` can be customized.
+The option `--single-color` will apply a built-in monochrome style, while
+`--color-palette` will accept a properties file to override the
+https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
+The properties file below demonstrates the default style:
+
+[source,properties,indent=0]
+----
+SUCCESSFUL = 32
+ABORTED = 33
+FAILED = 31
+SKIPPED = 35
+CONTAINER = 35
+TEST = 34
+DYNAMIC = 35
+REPORTED = 37
+----
+
+[[running-tests-source-launcher]]
+=== Source Launcher
+
+Starting with Java 25 it is possible to write minimal source code test programs
+using the `org.junit.start` module. For example, like in a `HelloTests.java`
+file reading:
+
+```java
+import module org.junit.start;
+
+void main() {
+  JUnit.run();
+}
+
+@Test
+void stringLength() {
+  Assertions.assertEquals(11, "Hello JUnit".length());
+}
+```
+With all required modular JAR files available in a local `lib/` directory, the
+following Java 25+ command will discover and execute tests using the JUnit Platform.
+It will also print the result tree to the console.
+
+```shell
+java --module-path lib --add-modules org.junit.start HelloTests.java
+╷
+└─ JUnit Jupiter ✔
+   └─ HelloTests ✔
+      └─ stringLength() ✔
+```
+
+Find JUnit's class API documentation here: {JUnit}
+
+[[running-tests-discovery-selectors]]
+=== Discovery Selectors
+
+The JUnit Platform provides a rich set of discovery selectors that can be used to specify
+which tests should be discovered or executed.
+
+Discovery selectors can be created programmatically using the factory methods in the
+`{DiscoverySelectors}` class, specified declaratively via annotations when using the
+<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
+generically as strings via their identifiers.
+
+The following discovery selectors are provided out of the box:
+
+|===
+| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
+
+| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
+| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
+| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
+| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
+| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
+| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
+| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
+| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
+| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
+| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
+| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
+| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
+| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
+|===
+
+
+[[running-tests-config-params]]
+=== Configuration Parameters
+
+In addition to instructing the platform which test classes and test engines to include,
+which packages to scan, etc., it is sometimes necessary to provide additional custom
+configuration parameters that are specific to a particular test engine, listener, or
+registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
+parameters_ for the following use cases.
+
+- <<writing-tests-test-instance-lifecycle-changing-default>>
+- <<extensions-registration-automatic-enabling>>
+- <<extensions-conditions-deactivation>>
+- <<writing-tests-display-name-generator-default>>
+
+_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
+engines running on the JUnit Platform via one of the following mechanisms.
+
+1. The `configurationParameter()` and `configurationParameters()` methods in
+   `LauncherDiscoveryRequestBuilder` which
+   is used to build a request supplied to the <<launcher-api, Launcher API>>.
+    +
+   When running tests via one of the tools provided by the JUnit Platform you can specify
+   configuration parameters as follows:
+   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
+     option.
+   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
+     `systemProperties` DSL.
+   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
+     `configurationParameters` property.
+2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
+    +
+   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
+   specify custom configuration files using the `--config-resource` command-line option.
+3. JVM system properties.
+4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
+   in the root of the class path that follows the syntax rules for Java `Properties`
+   files.
+
+NOTE: Configuration parameters are looked up in the exact order defined above.
+Consequently, configuration parameters supplied directly to the `Launcher` take
+precedence over those supplied via custom configuration files, system properties, and the
+default configuration file. Similarly, configuration parameters supplied via system
+properties take precedence over those supplied via the default configuration file.
+
+[[running-tests-config-params-deactivation-pattern]]
+==== Pattern Matching Syntax
+
+This section describes the pattern matching syntax that is applied to the _configuration
+parameters_ used for the following features.
+
+- <<extensions-conditions-deactivation>>
+- <<launcher-api-listeners-custom-deactivation>>
+- <<stacktrace-pruning>>
+- <<extensions-registration-automatic-filtering>>
+
+If the value for the given _configuration parameter_ consists solely of an asterisk
+(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
+will be treated as a comma-separated list of patterns where each pattern will be matched
+against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
+a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
+(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
+pattern will be matched one-to-one against a FQCN.
+
+Examples:
+
+- `+++*+++`: matches all candidate classes.
+- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
+  any of its subpackages.
+- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
+  `MyCustomImpl`.
+- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
+- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
+  `System` or `Unit`.
+- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
+  `org.example.MyCustomImpl`.
+- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
+  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
+
+[[running-tests-tags]]
+=== Tags
+
+Tags are a JUnit Platform concept for marking and filtering tests. The programming model
+for adding tags to containers and tests is defined by the testing framework. For example,
+in JUnit Jupiter based tests, the `@Tag` annotation (see
+<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
+Vintage engine maps `@Category` annotations to tags (see
+<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
+own annotation or other means for users to specify tags.
+
+[[running-tests-tag-syntax-rules]]
+==== Syntax Rules for Tags
+
+Regardless how a tag is specified, the JUnit Platform enforces the following rules:
+
+* A tag must not be `null` or _blank_.
+* A _stripped_ tag must not contain whitespace.
+* A _stripped_ tag must not contain ISO control characters.
+* A _stripped_ tag must not contain any of the following _reserved characters_.
+- `,`: _comma_
+- `(`: _left parenthesis_
+- `)`: _right parenthesis_
+- `&`: _ampersand_
+- `|`: _vertical bar_
+- `!`: _exclamation point_
+
+NOTE: In the above context, "stripped" means that leading and trailing whitespace
+characters have been removed using `java.lang.String.strip()`.
+
+[[running-tests-tag-expressions]]
+==== Tag Expressions
+
+Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
+`(` and `)` can be used to adjust for operator precedence.
+
+Two special expressions are supported, `any()` and `none()`, which select all tests _with_
+any tags at all, and all tests _without_ any tags, respectively.
+These special expressions may be combined with other expressions just like normal tags.
+
+.Operators (in descending order of precedence)
+|===
+| Operator | Meaning | Associativity
+
+| `!`      | not     | right
+| `&`      | and     | left
+| `\|`     | or      | left
+|===
+
+If you are tagging your tests across multiple dimensions, tag expressions help you to
+select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
+_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
+expressions can be useful.
+
+[%header,cols="40,60"]
+|===
+| Tag Expression
+| Selection
+
+| `+++product+++`
+| all tests for *product*
+
+| `+++catalog \| shipping+++`
+| all tests for *catalog* plus all tests for *shipping*
+
+| `+++catalog &amp; shipping+++`
+| all tests for the intersection between *catalog* and *shipping*
+
+| `+++product &amp; !end-to-end+++`
+| all tests for *product*, but not the _end-to-end_ tests
+
+| `+++(micro \| integration) &amp; (product \| shipping)+++`
+| all _micro_ or _integration_ tests for *product* or *shipping*
+|===
+
+[[running-tests-capturing-output]]
+=== Capturing Standard Output/Error
+
+The JUnit Platform provides opt-in support for capturing output printed to `System.out`
+and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
+`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
+parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
+to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
+
+If enabled, the JUnit Platform captures the corresponding output and publishes it as a
+report entry using the `stdout` or `stderr` keys to all registered
+`{TestExecutionListener}` instances immediately before reporting the test or container as
+finished.
+
+Please note that the captured output will only contain output emitted by the thread that
+was used to execute a container or test. Any output by other threads will be omitted
+because particularly when
+<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
+to attribute it to a specific test or container.
+
+[[running-tests-listeners]]
+=== Using Listeners and Interceptors
+
+The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
+and custom user code to react to events fired at various points during the discovery and
+execution of a `TestPlan`.
+
+* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
+  closed.
+* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
+  `LauncherSession`.
+* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
+* `{TestExecutionListener}`: receives events that occur during test execution.
+
+The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
+registered automatically for you in order to support some feature of the build tool or IDE.
+
+The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
+order to produce some form of report or to display a graphical representation of the test
+plan in an IDE. Such listeners may be implemented and automatically registered by a build
+tool or IDE, or they may be included in a third-party library – potentially registered
+for you automatically. You can also implement and register your own listeners.
+
+For details on registering and configuring listeners, see the following sections of this
+guide.
+
+* <<launcher-api-launcher-session-listeners-custom>>
+* <<launcher-api-launcher-interceptors-custom>>
+* <<launcher-api-launcher-discovery-listeners-custom>>
+* <<launcher-api-listeners-custom>>
+* <<launcher-api-listeners-config>>
+* <<launcher-api-listeners-custom-deactivation>>
+
+The JUnit Platform provides the following listeners which you may wish to use with your
+test suite.
+
+<<junit-platform-reporting>> ::
+  `{LegacyXmlReportGeneratingListener}` can be used via the
+  <<running-tests-console-launcher>> or registered manually to generate XML reports
+  compatible with the de facto standard for JUnit 4 based test reports.
++
+`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
+specified by {OpenTestReporting}. It is auto-registered and can be enabled and
+configured via <<running-tests-config-params>>.
++
+See <<junit-platform-reporting>> for details.
+
+<<running-tests-listeners-flight-recorder>> ::
+  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
+  Java Flight Recorder events during test discovery and execution.
+
+`{LoggingListener}` ::
+  `TestExecutionListener` for logging informational messages for all events via a
+  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
+
+`{SummaryGeneratingListener}` ::
+  `TestExecutionListener` that generates a summary of the test execution which can be
+  printed via a `PrintWriter`.
+
+`{UniqueIdTrackingListener}` ::
+  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
+  or executed during the execution of the `TestPlan` and generates a file containing the
+  unique IDs once execution of the `TestPlan` has finished.
+
+[[running-tests-listeners-flight-recorder]]
+==== Flight Recorder Support
+
+The JUnit Platform provides opt-in support for generating Flight Recorder events.
+https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
+follows.
+
+> Flight Recorder records events originating from applications, the JVM, and the OS.
+Events are stored in a single file that can be attached to bug reports and examined by
+support engineers, allowing after-the-fact analysis of issues in the period leading up
+to a problem.
+
+In order to record Flight Recorder events generated while running tests, you need to
+start flight recording when launching a test suite via the following java command line
+option.
+
+   -XX:StartFlightRecording:filename=...
+
+Please consult the manual of your build tool for the appropriate commands.
+
+To analyze the recorded events, use the
+https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
+command line tool shipped with recent JDKs or open the recording file with
+https://jdk.java.net/jmc/[JDK Mission Control].
+
+[[stacktrace-pruning]]
+=== Stack Trace Pruning
+
+The JUnit Platform provides built-in support for pruning stack traces produced by failing
+tests. This feature is enabled by default but can be disabled by setting the
+`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
+
+When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
+packages are removed from the stack trace, unless the calls occur after the test itself
+or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
+never be excluded.
+
+In addition, all elements prior to and including the first call from the JUnit Platform
+`Launcher` will be removed.
+
+[[running-tests-discovery-issues]]
+=== Discovery Issues
+
+Test engines may encounter issues during test discovery. For example, the declaration of a
+test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
+Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
+report them with different severity levels:
+
+INFO::
+Indicates that the engine encountered something that could be potentially problematic, but
+could also happen due to a valid setup or configuration.
+
+WARNING::
+Indicates that the engine encountered something that is problematic and might lead to
+unexpected behavior or will be removed or changed in a future release.
+
+ERROR::
+Indicates that the engine encountered something that is definitely problematic and will
+lead to unexpected behavior.
+
+If an engine reports an issue with a severity equal to or higher than a configurable
+_critical_ severity, its tests will not be executed. Instead, the engine will be reported
+as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
+Non-critical issues will be logged but will not prevent the engine from executing its
+tests. The `junit.platform.discovery.issue.severity.critical`
+<<running-tests-config-params, configuration parameter>> can be used to set the critical
+severity level. Currently, the default value is `ERROR` but it may be changed in a future
+release.
+
+TIP: To surface all discovery issues in your project, it is recommended to set the
+`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
+
+In addition, registered `{LauncherDiscoveryListener}` implementations can receive
+discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
+report issues to the user in a more user-friendly way. For example, IDEs may choose to
+display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc b/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc
new file mode 100644
index 000000000000..3099a146c2b4
--- /dev/null
+++ b/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc
@@ -0,0 +1,1216 @@
+[[running-tests]]
+== Running Tests
+
+[[running-tests-ide]]
+=== IDE Support
+
+[[running-tests-ide-intellij-idea]]
+==== IntelliJ IDEA
+
+IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
+information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
+however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
+IDEA download the following JARs automatically based on the API version used in the
+project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
+
+In order to use a different JUnit version (e.g., {version}), you may need to
+include the corresponding versions of the `junit-platform-launcher`,
+`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
+
+.Additional Gradle Dependencies
+[source,groovy]
+[subs=attributes+]
+----
+testImplementation(platform("org.junit:junit-bom:{version}"))
+testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
+testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
+----
+
+.Additional Maven Dependencies
+[source,xml]
+[subs=attributes+]
+----
+<!-- ... -->
+<dependencies>
+	<dependency>
+		<groupId>org.junit.platform</groupId>
+		<artifactId>junit-platform-launcher</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.jupiter</groupId>
+		<artifactId>junit-jupiter-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.vintage</groupId>
+		<artifactId>junit-vintage-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+</dependencies>
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+[[running-tests-ide-eclipse]]
+==== Eclipse
+
+Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
+release.
+
+For more information on using JUnit Platform in Eclipse consult the official _Eclipse
+support for JUnit 5_ section of the
+https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
+(4.7.1a) - New and Noteworthy] documentation.
+
+[[running-tests-ide-netbeans]]
+==== NetBeans
+
+NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
+https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
+
+For more information consult the JUnit 5 section of the
+https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
+release notes].
+
+[[running-tests-ide-vscode]]
+==== Visual Studio Code
+
+https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
+Platform via the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
+Runner] extension which is installed by default as part of the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
+Extension Pack].
+
+For more information consult the _Testing_ section of the
+https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
+documentation.
+
+[[running-tests-ide-other]]
+==== Other IDEs
+
+If you are using an editor or IDE other than one of those listed in the previous sections,
+and it doesn't support running tests on the JUnit Platform, you can use the
+<<running-tests-console-launcher>> to run them from the command line.
+
+[[running-tests-build]]
+=== Build Support
+
+[[running-tests-build-gradle]]
+==== Gradle
+
+Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
+https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
+for executing tests on the JUnit Platform. To enable it, you need to specify
+`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform()
+}
+----
+
+Filtering by <<running-tests-tags, tags>>,
+<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform {
+		includeTags("fast", "smoke & feature-a")
+		// excludeTags("slow", "ci")
+		includeEngines("junit-jupiter")
+		// excludeEngines("junit-vintage")
+	}
+}
+----
+
+Please refer to the
+https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
+for a comprehensive list of options.
+
+[[running-tests-build-gradle-bom]]
+===== Aligning dependency versions
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Explicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation(platform("org.junit:junit-bom:{version}"))
+	testImplementation("org.junit.jupiter:junit-jupiter")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+Since all JUnit artifacts declare a
+https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
+you usually don't need to declare an explicit dependency on it yourself. Instead, it's
+sufficient to declare _one_ regular dependency that includes a version number. Gradle will
+then pull in the BOM automatically so you can omit the version for all other JUnit
+artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Implicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
+}
+----
+<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
+<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
+
+[WARNING]
+.Declaring a dependency on junit-platform-launcher
+====
+Even though pre-8.0 versions of Gradle don't require declaring an explicit
+dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
+of JUnit artifacts on the test runtime classpath are aligned.
+
+Moreover, doing so is recommended and in some cases even required when importing the
+project into an IDE like <<running-tests-ide-eclipse>> or
+<<running-tests-ide-intellij-idea>>.
+====
+
+[[running-tests-build-gradle-engines-configure]]
+===== Configuring Test Engines
+
+In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
+
+To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
+on the dependency-aggregating JUnit Jupiter artifact similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Alternatively, you can use Gradle's
+https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
+support.
+
+[source,kotlin,indent=0]
+[subs=attributes+]
+.Kotlin DSL
+----
+testing {
+	suites {
+		named<JvmTestSuite>("test") {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Groovy DSL
+----
+testing {
+	suites {
+		test {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
+dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
+implementation similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("junit:junit:{junit4-version}")
+	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+[[running-tests-build-gradle-config-params]]
+===== Configuration Parameters
+
+The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
+Platform <<running-tests-config-params, configuration parameters>> to influence test
+discovery and execution. However, you can provide configuration parameters within the
+build script via system properties (as shown below) or via the
+`junit-platform.properties` file.
+
+[source,groovy,indent=0]
+----
+test {
+	// ...
+	systemProperty("junit.jupiter.conditions.deactivate", "*")
+	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
+	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
+	// ...
+}
+----
+
+[[running-tests-build-gradle-logging]]
+===== Configuring Logging (optional)
+
+JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
+emit warnings and debug information. Please refer to the official documentation of
+`{LogManager}` for configuration options.
+
+Alternatively, it's possible to redirect log messages to other logging frameworks such as
+{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
+`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
+qualified class name_ of the `{LogManager}` implementation to use. The example below
+demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
+details).
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
+	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
+	systemProperty("log4j2.disableJmx", "true")
+}
+----
+
+Other logging frameworks provide different means to redirect messages logged using
+`java.util.logging`. For example, for {Logback} you can use the
+https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
+dependency to the test runtime classpath.
+
+[[running-tests-build-maven]]
+==== Maven
+
+Maven Surefire and Maven Failsafe provide
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
+for executing tests on the JUnit Platform. The `pom.xml` file in the
+`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
+and can serve as a starting point for configuring your Maven build.
+
+[WARNING]
+.Minimum required version of Maven Surefire/Failsafe
+====
+As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
+====
+
+[[running-tests-build-maven-bom]]
+===== Aligning dependency versions
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+[[running-tests-build-maven-engines-configure]]
+===== Configuring Test Engines
+
+In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
+`TestEngine` implementation must be added to the test classpath.
+
+To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
+on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
+following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>org.junit.jupiter</groupId>
+			<artifactId>junit-jupiter</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
+long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
+`TestEngine` implementation similar to the following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>junit</groupId>
+			<artifactId>junit</artifactId>
+			<version>{junit4-version}</version>
+			<scope>test</scope>
+		</dependency>
+		<dependency>
+			<groupId>org.junit.vintage</groupId>
+			<artifactId>junit-vintage-engine</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-filter-test-class-names]]
+===== Filtering by Test Class Names
+
+The Maven Surefire Plugin will scan for test classes whose fully qualified names match
+the following patterns.
+
+- `+++**/Test*.java+++`
+- `+++**/*Test.java+++`
+- `+++**/*Tests.java+++`
+- `+++**/*TestCase.java+++`
+
+Moreover, it will exclude all nested classes (including static member classes) by default.
+
+Note, however, that you can override this default behavior by configuring explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
+from excluding static member classes, you can override its exclude rules as follows.
+
+[source,xml,indent=0]
+[subs=attributes+]
+.Overriding exclude rules of Maven Surefire
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<excludes>
+						<exclude/>
+					</excludes>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Please see the
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
+documentation for Maven Surefire for details.
+
+[[running-tests-build-maven-filter-tags]]
+===== Filtering by Tags
+
+You can filter tests by <<running-tests-tags, tags>> or
+<<running-tests-tag-expressions, tag expressions>> using the following configuration
+properties.
+
+- to include _tags_ or _tag expressions_, use `groups`.
+- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<groups>acceptance | !feature-a</groups>
+					<excludedGroups>integration, regression</excludedGroups>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-config-params]]
+===== Configuration Parameters
+
+You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
+influence test discovery and execution by declaring the `configurationParameters`
+property and providing key-value pairs using the Java `Properties` file syntax (as shown
+below) or via the `junit-platform.properties` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<properties>
+						<configurationParameters>
+							junit.jupiter.conditions.deactivate = *
+							junit.jupiter.extensions.autodetection.enabled = true
+							junit.jupiter.testinstance.lifecycle.default = per_class
+						</configurationParameters>
+					</properties>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-ant]]
+==== Ant
+
+Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
+provides native support for launching tests on the JUnit Platform. The `junitlauncher`
+task is solely responsible for launching the JUnit Platform and passing it the selected
+collection of tests. The JUnit Platform then delegates to registered test engines to
+discover and execute the tests.
+
+The `junitlauncher` task attempts to align as closely as possible with native Ant
+constructs such as
+link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
+for allowing users to select the tests that they want executed by test engines. This gives
+the task a consistent and natural feel when compared to many other core Ant tasks.
+
+Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
+
+The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
+the task and can serve as a starting point.
+
+===== Basic Usage
+
+The following example demonstrates how to configure the `junitlauncher` task to select a
+single test class (i.e., `com.example.project.CalculatorTests`).
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+
+	<!-- ... -->
+
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<test name="com.example.project.CalculatorTests" />
+	</junitlauncher>
+----
+
+The `test` element allows you to specify a single test class that you want to be selected
+and executed. The `classpath` element allows you to specify the classpath to be used to
+launch the JUnit Platform. This classpath will also be used to locate test classes that
+are part of the execution.
+
+The following example demonstrates how to configure the `junitlauncher` task to select
+test classes from multiple locations.
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+	<!-- ... -->
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<testclasses outputdir="${output.dir}">
+			<fileset dir="${build.classes.dir}">
+				<include name="org/example/**/demo/**/" />
+			</fileset>
+			<fileset dir="${some.other.dir}">
+				<include name="org/myapp/**/" />
+			</fileset>
+		</testclasses>
+	</junitlauncher>
+----
+
+In the above example, the `testclasses` element allows you to select multiple test
+classes that reside in different locations.
+
+For further details on usage and configuration options please refer to the official Ant
+documentation for the
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
+
+[[running-tests-build-spring-boot]]
+==== Spring Boot
+
+link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
+managing the version of JUnit used in your project. In addition, the
+`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
+Jupiter, AssertJ, Mockito, etc.
+
+If your build relies on dependency management support from Spring Boot, you should not
+import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
+result in duplicate (and potentially conflicting) management of JUnit dependencies.
+
+If you need to override the version of a dependency used in your Spring Boot application,
+you have to override the exact name of the
+link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
+defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
+Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
+changing a dependency version is documented for both
+link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
+and
+link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
+
+With Gradle you can override the JUnit Jupiter version by including the following in your
+`build.gradle` file.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+	ext['junit-jupiter.version'] = '{version}'
+----
+
+With Maven you can override the JUnit Jupiter version by including the following in your
+`pom.xml` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<properties>
+		<junit-jupiter.version>{version}</junit-jupiter.version>
+	</properties>
+----
+
+[[running-tests-console-launcher]]
+=== Console Launcher
+
+The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
+Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
+Jupiter tests and print test execution results to the console.
+
+An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
+contains the contents of all of its dependencies is published in the {Maven_Central}
+repository under the
+https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
+directory. It contains the contents of the following artifacts:
+
+include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
+
+[NOTE]
+====
+Since the `junit-platform-console-standalone` JAR contains the contents of all of its
+dependencies, its Maven POM does not declare any dependencies.
+
+Furthermore, it is not very likely that you would need to include a dependency on the
+`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
+script. On the contrary, the executable `junit-platform-console-standalone` JAR is
+typically invoked directly from the command line or a shell script without a build script.
+
+If you need to declare dependencies in your build script on some of the artifacts
+contained in the `junit-platform-console-standalone` artifact, you should declare
+dependencies only on the JUnit artifacts that are used in your project. To simplify
+dependency management of JUnit artifacts in your build, you may wish to use the
+`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
+details.
+====
+
+You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
+standalone `ConsoleLauncher` as shown below.
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
+
+├─ JUnit Vintage
+│  └─ example.JUnit4Tests
+│     └─ standardJUnit4Test ✔
+└─ JUnit Jupiter
+   ├─ StandardTests
+   │  ├─ succeedingTest() ✔
+   │  └─ skippedTest() ↷ for demonstration purposes
+   └─ A special test case
+      ├─ Custom test name containing spaces ✔
+      ├─ ╯°□°)╯ ✔
+      └─ 😱 ✔
+
+Test run finished after 64 ms
+[         5 containers found      ]
+[         0 containers skipped    ]
+[         5 containers started    ]
+[         0 containers aborted    ]
+[         5 containers successful ]
+[         0 containers failed     ]
+[         6 tests found           ]
+[         1 tests skipped         ]
+[         5 tests started         ]
+[         0 tests aborted         ]
+[         5 tests successful      ]
+[         0 tests failed          ]
+----
+
+You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
+all jars in a directory):
+
+[source,console,subs=attributes+]
+----
+$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
+----
+
+[[running-tests-console-launcher-options]]
+==== Subcommands and Options
+
+The `{ConsoleLauncher}` provides the following subcommands:
+
+----
+include::{consoleLauncherOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-discovering-tests]]
+===== Discovering tests
+
+----
+include::{consoleLauncherDiscoverOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-executing-tests]]
+===== Executing tests
+
+.Exit Code
+NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
+All non-zero codes indicate an error of some sort. For example, status code `1`
+is returned if any containers or tests failed. If no tests are discovered and the
+`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
+with a status code of `2`. Unexpected or invalid user input yields a status code
+of `3`. An exit code of `-1` indicates an unspecified error condition.
+
+----
+include::{consoleLauncherExecuteOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-listing-test-engines]]
+===== Listing test engines
+
+----
+include::{consoleLauncherEnginesOptionsFile}[]
+----
+
+[[running-tests-console-launcher-argument-files]]
+==== Argument Files (@-files)
+
+On some platforms you may run into system limitations on the length of a command line when
+creating a command line with lots of options or with long arguments.
+
+The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
+are files that themselves contain arguments to be passed to the command. When the
+underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
+argument beginning with the character `@`, it expands the contents of that file into the
+argument list.
+
+The arguments within a file can be separated by spaces or newlines. If an argument
+contains embedded whitespace, the whole argument should be wrapped in double or single
+quotes -- for example, `"-f=My Files/Stuff.java"`.
+
+If the argument file does not exist or cannot be read, the argument will be treated
+literally and will not be removed. This will likely result in an "unmatched argument"
+error message. You can troubleshoot such errors by executing the command with the
+`picocli.trace` system property set to `DEBUG`.
+
+Multiple _@-files_ may be specified on the command line. The specified path may be
+relative to the current directory or absolute.
+
+You can pass a real parameter with an initial `@` character by escaping it with an
+additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
+subject to expansion.
+
+[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
+==== Redirecting Standard Output/Error to Files
+
+You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
+files using the `--redirect-stdout` and `--redirect-stderr` options:
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
+  --redirect-stdout=stdout.txt \
+  --redirect-stderr=stderr.txt
+----
+
+[NOTE]
+====
+If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
+output streams will be redirected to that file.
+
+The default charset is used for writing to the files.
+====
+
+[[running-tests-console-launcher-color-customization]]
+==== Color Customization
+
+The colors used in the output of the `{ConsoleLauncher}` can be customized.
+The option `--single-color` will apply a built-in monochrome style, while
+`--color-palette` will accept a properties file to override the
+https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
+The properties file below demonstrates the default style:
+
+[source,properties,indent=0]
+----
+SUCCESSFUL = 32
+ABORTED = 33
+FAILED = 31
+SKIPPED = 35
+CONTAINER = 35
+TEST = 34
+DYNAMIC = 35
+REPORTED = 37
+----
+
+[[running-tests-source-launcher]]
+=== Source Launcher
+
+Starting with Java 25 it is possible to write minimal source code test programs
+using the `org.junit.start` module. For example, like in a `HelloTests.java`
+file reading:
+
+```java
+import module org.junit.start;
+
+void main() {
+  JUnit.run();
+}
+
+@Test
+void stringLength() {
+  Assertions.assertEquals(11, "Hello JUnit".length());
+}
+```
+With all required modular JAR files available in a local `lib/` directory, the
+following Java 25+ command will discover and execute tests using the JUnit Platform.
+It will also print the result tree to the console.
+
+```shell
+java --module-path lib --add-modules org.junit.start HelloTests.java
+╷
+└─ JUnit Jupiter ✔
+   └─ HelloTests ✔
+      └─ stringLength() ✔
+```
+
+Find JUnit's class API documentation here: {JUnit}
+
+[[running-tests-discovery-selectors]]
+=== Discovery Selectors
+
+The JUnit Platform provides a rich set of discovery selectors that can be used to specify
+which tests should be discovered or executed.
+
+Discovery selectors can be created programmatically using the factory methods in the
+`{DiscoverySelectors}` class, specified declaratively via annotations when using the
+<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
+generically as strings via their identifiers.
+
+The following discovery selectors are provided out of the box:
+
+|===
+| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
+
+| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
+| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
+| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
+| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
+| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
+| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
+| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
+| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
+| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
+| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
+| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
+| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
+| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
+|===
+
+
+[[running-tests-config-params]]
+=== Configuration Parameters
+
+In addition to instructing the platform which test classes and test engines to include,
+which packages to scan, etc., it is sometimes necessary to provide additional custom
+configuration parameters that are specific to a particular test engine, listener, or
+registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
+parameters_ for the following use cases.
+
+- <<writing-tests-test-instance-lifecycle-changing-default>>
+- <<extensions-registration-automatic-enabling>>
+- <<extensions-conditions-deactivation>>
+- <<writing-tests-display-name-generator-default>>
+
+_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
+engines running on the JUnit Platform via one of the following mechanisms.
+
+1. The `configurationParameter()` and `configurationParameters()` methods in
+   `LauncherDiscoveryRequestBuilder` which
+   is used to build a request supplied to the <<launcher-api, Launcher API>>.
+    +
+   When running tests via one of the tools provided by the JUnit Platform you can specify
+   configuration parameters as follows:
+   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
+     option.
+   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
+     `systemProperties` DSL.
+   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
+     `configurationParameters` property.
+2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
+    +
+   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
+   specify custom configuration files using the `--config-resource` command-line option.
+3. JVM system properties.
+4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
+   in the root of the class path that follows the syntax rules for Java `Properties`
+   files.
+
+NOTE: Configuration parameters are looked up in the exact order defined above.
+Consequently, configuration parameters supplied directly to the `Launcher` take
+precedence over those supplied via custom configuration files, system properties, and the
+default configuration file. Similarly, configuration parameters supplied via system
+properties take precedence over those supplied via the default configuration file.
+
+[[running-tests-config-params-deactivation-pattern]]
+==== Pattern Matching Syntax
+
+This section describes the pattern matching syntax that is applied to the _configuration
+parameters_ used for the following features.
+
+- <<extensions-conditions-deactivation>>
+- <<launcher-api-listeners-custom-deactivation>>
+- <<stacktrace-pruning>>
+- <<extensions-registration-automatic-filtering>>
+
+If the value for the given _configuration parameter_ consists solely of an asterisk
+(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
+will be treated as a comma-separated list of patterns where each pattern will be matched
+against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
+a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
+(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
+pattern will be matched one-to-one against a FQCN.
+
+Examples:
+
+- `+++*+++`: matches all candidate classes.
+- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
+  any of its subpackages.
+- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
+  `MyCustomImpl`.
+- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
+- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
+  `System` or `Unit`.
+- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
+  `org.example.MyCustomImpl`.
+- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
+  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
+
+[[running-tests-tags]]
+=== Tags
+
+Tags are a JUnit Platform concept for marking and filtering tests. The programming model
+for adding tags to containers and tests is defined by the testing framework. For example,
+in JUnit Jupiter based tests, the `@Tag` annotation (see
+<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
+Vintage engine maps `@Category` annotations to tags (see
+<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
+own annotation or other means for users to specify tags.
+
+[[running-tests-tag-syntax-rules]]
+==== Syntax Rules for Tags
+
+Regardless how a tag is specified, the JUnit Platform enforces the following rules:
+
+* A tag must not be `null` or _blank_.
+* A _stripped_ tag must not contain whitespace.
+* A _stripped_ tag must not contain ISO control characters.
+* A _stripped_ tag must not contain any of the following _reserved characters_.
+- `,`: _comma_
+- `(`: _left parenthesis_
+- `)`: _right parenthesis_
+- `&`: _ampersand_
+- `|`: _vertical bar_
+- `!`: _exclamation point_
+
+NOTE: In the above context, "stripped" means that leading and trailing whitespace
+characters have been removed using `java.lang.String.strip()`.
+
+[[running-tests-tag-expressions]]
+==== Tag Expressions
+
+Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
+`(` and `)` can be used to adjust for operator precedence.
+
+Two special expressions are supported, `any()` and `none()`, which select all tests _with_
+any tags at all, and all tests _without_ any tags, respectively.
+These special expressions may be combined with other expressions just like normal tags.
+
+.Operators (in descending order of precedence)
+|===
+| Operator | Meaning | Associativity
+
+| `!`      | not     | right
+| `&`      | and     | left
+| `\|`     | or      | left
+|===
+
+If you are tagging your tests across multiple dimensions, tag expressions help you to
+select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
+_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
+expressions can be useful.
+
+[%header,cols="40,60"]
+|===
+| Tag Expression
+| Selection
+
+| `+++product+++`
+| all tests for *product*
+
+| `+++catalog \| shipping+++`
+| all tests for *catalog* plus all tests for *shipping*
+
+| `+++catalog &amp; shipping+++`
+| all tests for the intersection between *catalog* and *shipping*
+
+| `+++product &amp; !end-to-end+++`
+| all tests for *product*, but not the _end-to-end_ tests
+
+| `+++(micro \| integration) &amp; (product \| shipping)+++`
+| all _micro_ or _integration_ tests for *product* or *shipping*
+|===
+
+[[running-tests-capturing-output]]
+=== Capturing Standard Output/Error
+
+The JUnit Platform provides opt-in support for capturing output printed to `System.out`
+and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
+`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
+parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
+to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
+
+If enabled, the JUnit Platform captures the corresponding output and publishes it as a
+report entry using the `stdout` or `stderr` keys to all registered
+`{TestExecutionListener}` instances immediately before reporting the test or container as
+finished.
+
+Please note that the captured output will only contain output emitted by the thread that
+was used to execute a container or test. Any output by other threads will be omitted
+because particularly when
+<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
+to attribute it to a specific test or container.
+
+[[running-tests-listeners]]
+=== Using Listeners and Interceptors
+
+The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
+and custom user code to react to events fired at various points during the discovery and
+execution of a `TestPlan`.
+
+* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
+  closed.
+* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
+  `LauncherSession`.
+* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
+* `{TestExecutionListener}`: receives events that occur during test execution.
+
+The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
+registered automatically for you in order to support some feature of the build tool or IDE.
+
+The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
+order to produce some form of report or to display a graphical representation of the test
+plan in an IDE. Such listeners may be implemented and automatically registered by a build
+tool or IDE, or they may be included in a third-party library – potentially registered
+for you automatically. You can also implement and register your own listeners.
+
+For details on registering and configuring listeners, see the following sections of this
+guide.
+
+* <<launcher-api-launcher-session-listeners-custom>>
+* <<launcher-api-launcher-interceptors-custom>>
+* <<launcher-api-launcher-discovery-listeners-custom>>
+* <<launcher-api-listeners-custom>>
+* <<launcher-api-listeners-config>>
+* <<launcher-api-listeners-custom-deactivation>>
+
+The JUnit Platform provides the following listeners which you may wish to use with your
+test suite.
+
+<<junit-platform-reporting>> ::
+  `{LegacyXmlReportGeneratingListener}` can be used via the
+  <<running-tests-console-launcher>> or registered manually to generate XML reports
+  compatible with the de facto standard for JUnit 4 based test reports.
++
+`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
+specified by {OpenTestReporting}. It is auto-registered and can be enabled and
+configured via <<running-tests-config-params>>.
++
+See <<junit-platform-reporting>> for details.
+
+<<running-tests-listeners-flight-recorder>> ::
+  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
+  Java Flight Recorder events during test discovery and execution.
+
+`{LoggingListener}` ::
+  `TestExecutionListener` for logging informational messages for all events via a
+  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
+
+`{SummaryGeneratingListener}` ::
+  `TestExecutionListener` that generates a summary of the test execution which can be
+  printed via a `PrintWriter`.
+
+`{UniqueIdTrackingListener}` ::
+  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
+  or executed during the execution of the `TestPlan` and generates a file containing the
+  unique IDs once execution of the `TestPlan` has finished.
+
+[[running-tests-listeners-flight-recorder]]
+==== Flight Recorder Support
+
+The JUnit Platform provides opt-in support for generating Flight Recorder events.
+https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
+follows.
+
+> Flight Recorder records events originating from applications, the JVM, and the OS.
+Events are stored in a single file that can be attached to bug reports and examined by
+support engineers, allowing after-the-fact analysis of issues in the period leading up
+to a problem.
+
+In order to record Flight Recorder events generated while running tests, you need to
+start flight recording when launching a test suite via the following java command line
+option.
+
+   -XX:StartFlightRecording:filename=...
+
+Please consult the manual of your build tool for the appropriate commands.
+
+To analyze the recorded events, use the
+https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
+command line tool shipped with recent JDKs or open the recording file with
+https://jdk.java.net/jmc/[JDK Mission Control].
+
+[[stacktrace-pruning]]
+=== Stack Trace Pruning
+
+The JUnit Platform provides built-in support for pruning stack traces produced by failing
+tests. This feature is enabled by default but can be disabled by setting the
+`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
+
+When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
+packages are removed from the stack trace, unless the calls occur after the test itself
+or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
+never be excluded.
+
+In addition, all elements prior to and including the first call from the JUnit Platform
+`Launcher` will be removed.
+
+[[running-tests-discovery-issues]]
+=== Discovery Issues
+
+Test engines may encounter issues during test discovery. For example, the declaration of a
+test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
+Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
+report them with different severity levels:
+
+INFO::
+Indicates that the engine encountered something that could be potentially problematic, but
+could also happen due to a valid setup or configuration.
+
+WARNING::
+Indicates that the engine encountered something that is problematic and might lead to
+unexpected behavior or will be removed or changed in a future release.
+
+ERROR::
+Indicates that the engine encountered something that is definitely problematic and will
+lead to unexpected behavior.
+
+If an engine reports an issue with a severity equal to or higher than a configurable
+_critical_ severity, its tests will not be executed. Instead, the engine will be reported
+as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
+Non-critical issues will be logged but will not prevent the engine from executing its
+tests. The `junit.platform.discovery.issue.severity.critical`
+<<running-tests-config-params, configuration parameter>> can be used to set the critical
+severity level. Currently, the default value is `ERROR` but it may be changed in a future
+release.
+
+TIP: To surface all discovery issues in your project, it is recommended to set the
+`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
+
+In addition, registered `{LauncherDiscoveryListener}` implementations can receive
+discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
+report issues to the user in a more user-friendly way. For example, IDEs may choose to
+display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc b/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc
new file mode 100644
index 000000000000..3099a146c2b4
--- /dev/null
+++ b/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc
@@ -0,0 +1,1216 @@
+[[running-tests]]
+== Running Tests
+
+[[running-tests-ide]]
+=== IDE Support
+
+[[running-tests-ide-intellij-idea]]
+==== IntelliJ IDEA
+
+IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
+information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
+however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
+IDEA download the following JARs automatically based on the API version used in the
+project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
+
+In order to use a different JUnit version (e.g., {version}), you may need to
+include the corresponding versions of the `junit-platform-launcher`,
+`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
+
+.Additional Gradle Dependencies
+[source,groovy]
+[subs=attributes+]
+----
+testImplementation(platform("org.junit:junit-bom:{version}"))
+testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
+testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
+----
+
+.Additional Maven Dependencies
+[source,xml]
+[subs=attributes+]
+----
+<!-- ... -->
+<dependencies>
+	<dependency>
+		<groupId>org.junit.platform</groupId>
+		<artifactId>junit-platform-launcher</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.jupiter</groupId>
+		<artifactId>junit-jupiter-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.vintage</groupId>
+		<artifactId>junit-vintage-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+</dependencies>
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+[[running-tests-ide-eclipse]]
+==== Eclipse
+
+Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
+release.
+
+For more information on using JUnit Platform in Eclipse consult the official _Eclipse
+support for JUnit 5_ section of the
+https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
+(4.7.1a) - New and Noteworthy] documentation.
+
+[[running-tests-ide-netbeans]]
+==== NetBeans
+
+NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
+https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
+
+For more information consult the JUnit 5 section of the
+https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
+release notes].
+
+[[running-tests-ide-vscode]]
+==== Visual Studio Code
+
+https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
+Platform via the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
+Runner] extension which is installed by default as part of the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
+Extension Pack].
+
+For more information consult the _Testing_ section of the
+https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
+documentation.
+
+[[running-tests-ide-other]]
+==== Other IDEs
+
+If you are using an editor or IDE other than one of those listed in the previous sections,
+and it doesn't support running tests on the JUnit Platform, you can use the
+<<running-tests-console-launcher>> to run them from the command line.
+
+[[running-tests-build]]
+=== Build Support
+
+[[running-tests-build-gradle]]
+==== Gradle
+
+Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
+https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
+for executing tests on the JUnit Platform. To enable it, you need to specify
+`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform()
+}
+----
+
+Filtering by <<running-tests-tags, tags>>,
+<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform {
+		includeTags("fast", "smoke & feature-a")
+		// excludeTags("slow", "ci")
+		includeEngines("junit-jupiter")
+		// excludeEngines("junit-vintage")
+	}
+}
+----
+
+Please refer to the
+https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
+for a comprehensive list of options.
+
+[[running-tests-build-gradle-bom]]
+===== Aligning dependency versions
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Explicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation(platform("org.junit:junit-bom:{version}"))
+	testImplementation("org.junit.jupiter:junit-jupiter")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+Since all JUnit artifacts declare a
+https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
+you usually don't need to declare an explicit dependency on it yourself. Instead, it's
+sufficient to declare _one_ regular dependency that includes a version number. Gradle will
+then pull in the BOM automatically so you can omit the version for all other JUnit
+artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Implicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
+}
+----
+<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
+<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
+
+[WARNING]
+.Declaring a dependency on junit-platform-launcher
+====
+Even though pre-8.0 versions of Gradle don't require declaring an explicit
+dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
+of JUnit artifacts on the test runtime classpath are aligned.
+
+Moreover, doing so is recommended and in some cases even required when importing the
+project into an IDE like <<running-tests-ide-eclipse>> or
+<<running-tests-ide-intellij-idea>>.
+====
+
+[[running-tests-build-gradle-engines-configure]]
+===== Configuring Test Engines
+
+In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
+
+To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
+on the dependency-aggregating JUnit Jupiter artifact similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Alternatively, you can use Gradle's
+https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
+support.
+
+[source,kotlin,indent=0]
+[subs=attributes+]
+.Kotlin DSL
+----
+testing {
+	suites {
+		named<JvmTestSuite>("test") {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Groovy DSL
+----
+testing {
+	suites {
+		test {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
+dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
+implementation similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("junit:junit:{junit4-version}")
+	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+[[running-tests-build-gradle-config-params]]
+===== Configuration Parameters
+
+The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
+Platform <<running-tests-config-params, configuration parameters>> to influence test
+discovery and execution. However, you can provide configuration parameters within the
+build script via system properties (as shown below) or via the
+`junit-platform.properties` file.
+
+[source,groovy,indent=0]
+----
+test {
+	// ...
+	systemProperty("junit.jupiter.conditions.deactivate", "*")
+	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
+	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
+	// ...
+}
+----
+
+[[running-tests-build-gradle-logging]]
+===== Configuring Logging (optional)
+
+JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
+emit warnings and debug information. Please refer to the official documentation of
+`{LogManager}` for configuration options.
+
+Alternatively, it's possible to redirect log messages to other logging frameworks such as
+{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
+`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
+qualified class name_ of the `{LogManager}` implementation to use. The example below
+demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
+details).
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
+	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
+	systemProperty("log4j2.disableJmx", "true")
+}
+----
+
+Other logging frameworks provide different means to redirect messages logged using
+`java.util.logging`. For example, for {Logback} you can use the
+https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
+dependency to the test runtime classpath.
+
+[[running-tests-build-maven]]
+==== Maven
+
+Maven Surefire and Maven Failsafe provide
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
+for executing tests on the JUnit Platform. The `pom.xml` file in the
+`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
+and can serve as a starting point for configuring your Maven build.
+
+[WARNING]
+.Minimum required version of Maven Surefire/Failsafe
+====
+As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
+====
+
+[[running-tests-build-maven-bom]]
+===== Aligning dependency versions
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+[[running-tests-build-maven-engines-configure]]
+===== Configuring Test Engines
+
+In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
+`TestEngine` implementation must be added to the test classpath.
+
+To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
+on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
+following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>org.junit.jupiter</groupId>
+			<artifactId>junit-jupiter</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
+long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
+`TestEngine` implementation similar to the following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>junit</groupId>
+			<artifactId>junit</artifactId>
+			<version>{junit4-version}</version>
+			<scope>test</scope>
+		</dependency>
+		<dependency>
+			<groupId>org.junit.vintage</groupId>
+			<artifactId>junit-vintage-engine</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-filter-test-class-names]]
+===== Filtering by Test Class Names
+
+The Maven Surefire Plugin will scan for test classes whose fully qualified names match
+the following patterns.
+
+- `+++**/Test*.java+++`
+- `+++**/*Test.java+++`
+- `+++**/*Tests.java+++`
+- `+++**/*TestCase.java+++`
+
+Moreover, it will exclude all nested classes (including static member classes) by default.
+
+Note, however, that you can override this default behavior by configuring explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
+from excluding static member classes, you can override its exclude rules as follows.
+
+[source,xml,indent=0]
+[subs=attributes+]
+.Overriding exclude rules of Maven Surefire
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<excludes>
+						<exclude/>
+					</excludes>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Please see the
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
+documentation for Maven Surefire for details.
+
+[[running-tests-build-maven-filter-tags]]
+===== Filtering by Tags
+
+You can filter tests by <<running-tests-tags, tags>> or
+<<running-tests-tag-expressions, tag expressions>> using the following configuration
+properties.
+
+- to include _tags_ or _tag expressions_, use `groups`.
+- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<groups>acceptance | !feature-a</groups>
+					<excludedGroups>integration, regression</excludedGroups>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-config-params]]
+===== Configuration Parameters
+
+You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
+influence test discovery and execution by declaring the `configurationParameters`
+property and providing key-value pairs using the Java `Properties` file syntax (as shown
+below) or via the `junit-platform.properties` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<properties>
+						<configurationParameters>
+							junit.jupiter.conditions.deactivate = *
+							junit.jupiter.extensions.autodetection.enabled = true
+							junit.jupiter.testinstance.lifecycle.default = per_class
+						</configurationParameters>
+					</properties>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-ant]]
+==== Ant
+
+Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
+provides native support for launching tests on the JUnit Platform. The `junitlauncher`
+task is solely responsible for launching the JUnit Platform and passing it the selected
+collection of tests. The JUnit Platform then delegates to registered test engines to
+discover and execute the tests.
+
+The `junitlauncher` task attempts to align as closely as possible with native Ant
+constructs such as
+link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
+for allowing users to select the tests that they want executed by test engines. This gives
+the task a consistent and natural feel when compared to many other core Ant tasks.
+
+Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
+
+The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
+the task and can serve as a starting point.
+
+===== Basic Usage
+
+The following example demonstrates how to configure the `junitlauncher` task to select a
+single test class (i.e., `com.example.project.CalculatorTests`).
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+
+	<!-- ... -->
+
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<test name="com.example.project.CalculatorTests" />
+	</junitlauncher>
+----
+
+The `test` element allows you to specify a single test class that you want to be selected
+and executed. The `classpath` element allows you to specify the classpath to be used to
+launch the JUnit Platform. This classpath will also be used to locate test classes that
+are part of the execution.
+
+The following example demonstrates how to configure the `junitlauncher` task to select
+test classes from multiple locations.
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+	<!-- ... -->
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<testclasses outputdir="${output.dir}">
+			<fileset dir="${build.classes.dir}">
+				<include name="org/example/**/demo/**/" />
+			</fileset>
+			<fileset dir="${some.other.dir}">
+				<include name="org/myapp/**/" />
+			</fileset>
+		</testclasses>
+	</junitlauncher>
+----
+
+In the above example, the `testclasses` element allows you to select multiple test
+classes that reside in different locations.
+
+For further details on usage and configuration options please refer to the official Ant
+documentation for the
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
+
+[[running-tests-build-spring-boot]]
+==== Spring Boot
+
+link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
+managing the version of JUnit used in your project. In addition, the
+`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
+Jupiter, AssertJ, Mockito, etc.
+
+If your build relies on dependency management support from Spring Boot, you should not
+import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
+result in duplicate (and potentially conflicting) management of JUnit dependencies.
+
+If you need to override the version of a dependency used in your Spring Boot application,
+you have to override the exact name of the
+link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
+defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
+Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
+changing a dependency version is documented for both
+link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
+and
+link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
+
+With Gradle you can override the JUnit Jupiter version by including the following in your
+`build.gradle` file.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+	ext['junit-jupiter.version'] = '{version}'
+----
+
+With Maven you can override the JUnit Jupiter version by including the following in your
+`pom.xml` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<properties>
+		<junit-jupiter.version>{version}</junit-jupiter.version>
+	</properties>
+----
+
+[[running-tests-console-launcher]]
+=== Console Launcher
+
+The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
+Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
+Jupiter tests and print test execution results to the console.
+
+An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
+contains the contents of all of its dependencies is published in the {Maven_Central}
+repository under the
+https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
+directory. It contains the contents of the following artifacts:
+
+include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
+
+[NOTE]
+====
+Since the `junit-platform-console-standalone` JAR contains the contents of all of its
+dependencies, its Maven POM does not declare any dependencies.
+
+Furthermore, it is not very likely that you would need to include a dependency on the
+`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
+script. On the contrary, the executable `junit-platform-console-standalone` JAR is
+typically invoked directly from the command line or a shell script without a build script.
+
+If you need to declare dependencies in your build script on some of the artifacts
+contained in the `junit-platform-console-standalone` artifact, you should declare
+dependencies only on the JUnit artifacts that are used in your project. To simplify
+dependency management of JUnit artifacts in your build, you may wish to use the
+`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
+details.
+====
+
+You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
+standalone `ConsoleLauncher` as shown below.
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
+
+├─ JUnit Vintage
+│  └─ example.JUnit4Tests
+│     └─ standardJUnit4Test ✔
+└─ JUnit Jupiter
+   ├─ StandardTests
+   │  ├─ succeedingTest() ✔
+   │  └─ skippedTest() ↷ for demonstration purposes
+   └─ A special test case
+      ├─ Custom test name containing spaces ✔
+      ├─ ╯°□°)╯ ✔
+      └─ 😱 ✔
+
+Test run finished after 64 ms
+[         5 containers found      ]
+[         0 containers skipped    ]
+[         5 containers started    ]
+[         0 containers aborted    ]
+[         5 containers successful ]
+[         0 containers failed     ]
+[         6 tests found           ]
+[         1 tests skipped         ]
+[         5 tests started         ]
+[         0 tests aborted         ]
+[         5 tests successful      ]
+[         0 tests failed          ]
+----
+
+You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
+all jars in a directory):
+
+[source,console,subs=attributes+]
+----
+$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
+----
+
+[[running-tests-console-launcher-options]]
+==== Subcommands and Options
+
+The `{ConsoleLauncher}` provides the following subcommands:
+
+----
+include::{consoleLauncherOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-discovering-tests]]
+===== Discovering tests
+
+----
+include::{consoleLauncherDiscoverOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-executing-tests]]
+===== Executing tests
+
+.Exit Code
+NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
+All non-zero codes indicate an error of some sort. For example, status code `1`
+is returned if any containers or tests failed. If no tests are discovered and the
+`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
+with a status code of `2`. Unexpected or invalid user input yields a status code
+of `3`. An exit code of `-1` indicates an unspecified error condition.
+
+----
+include::{consoleLauncherExecuteOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-listing-test-engines]]
+===== Listing test engines
+
+----
+include::{consoleLauncherEnginesOptionsFile}[]
+----
+
+[[running-tests-console-launcher-argument-files]]
+==== Argument Files (@-files)
+
+On some platforms you may run into system limitations on the length of a command line when
+creating a command line with lots of options or with long arguments.
+
+The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
+are files that themselves contain arguments to be passed to the command. When the
+underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
+argument beginning with the character `@`, it expands the contents of that file into the
+argument list.
+
+The arguments within a file can be separated by spaces or newlines. If an argument
+contains embedded whitespace, the whole argument should be wrapped in double or single
+quotes -- for example, `"-f=My Files/Stuff.java"`.
+
+If the argument file does not exist or cannot be read, the argument will be treated
+literally and will not be removed. This will likely result in an "unmatched argument"
+error message. You can troubleshoot such errors by executing the command with the
+`picocli.trace` system property set to `DEBUG`.
+
+Multiple _@-files_ may be specified on the command line. The specified path may be
+relative to the current directory or absolute.
+
+You can pass a real parameter with an initial `@` character by escaping it with an
+additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
+subject to expansion.
+
+[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
+==== Redirecting Standard Output/Error to Files
+
+You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
+files using the `--redirect-stdout` and `--redirect-stderr` options:
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
+  --redirect-stdout=stdout.txt \
+  --redirect-stderr=stderr.txt
+----
+
+[NOTE]
+====
+If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
+output streams will be redirected to that file.
+
+The default charset is used for writing to the files.
+====
+
+[[running-tests-console-launcher-color-customization]]
+==== Color Customization
+
+The colors used in the output of the `{ConsoleLauncher}` can be customized.
+The option `--single-color` will apply a built-in monochrome style, while
+`--color-palette` will accept a properties file to override the
+https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
+The properties file below demonstrates the default style:
+
+[source,properties,indent=0]
+----
+SUCCESSFUL = 32
+ABORTED = 33
+FAILED = 31
+SKIPPED = 35
+CONTAINER = 35
+TEST = 34
+DYNAMIC = 35
+REPORTED = 37
+----
+
+[[running-tests-source-launcher]]
+=== Source Launcher
+
+Starting with Java 25 it is possible to write minimal source code test programs
+using the `org.junit.start` module. For example, like in a `HelloTests.java`
+file reading:
+
+```java
+import module org.junit.start;
+
+void main() {
+  JUnit.run();
+}
+
+@Test
+void stringLength() {
+  Assertions.assertEquals(11, "Hello JUnit".length());
+}
+```
+With all required modular JAR files available in a local `lib/` directory, the
+following Java 25+ command will discover and execute tests using the JUnit Platform.
+It will also print the result tree to the console.
+
+```shell
+java --module-path lib --add-modules org.junit.start HelloTests.java
+╷
+└─ JUnit Jupiter ✔
+   └─ HelloTests ✔
+      └─ stringLength() ✔
+```
+
+Find JUnit's class API documentation here: {JUnit}
+
+[[running-tests-discovery-selectors]]
+=== Discovery Selectors
+
+The JUnit Platform provides a rich set of discovery selectors that can be used to specify
+which tests should be discovered or executed.
+
+Discovery selectors can be created programmatically using the factory methods in the
+`{DiscoverySelectors}` class, specified declaratively via annotations when using the
+<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
+generically as strings via their identifiers.
+
+The following discovery selectors are provided out of the box:
+
+|===
+| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
+
+| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
+| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
+| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
+| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
+| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
+| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
+| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
+| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
+| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
+| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
+| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
+| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
+| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
+|===
+
+
+[[running-tests-config-params]]
+=== Configuration Parameters
+
+In addition to instructing the platform which test classes and test engines to include,
+which packages to scan, etc., it is sometimes necessary to provide additional custom
+configuration parameters that are specific to a particular test engine, listener, or
+registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
+parameters_ for the following use cases.
+
+- <<writing-tests-test-instance-lifecycle-changing-default>>
+- <<extensions-registration-automatic-enabling>>
+- <<extensions-conditions-deactivation>>
+- <<writing-tests-display-name-generator-default>>
+
+_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
+engines running on the JUnit Platform via one of the following mechanisms.
+
+1. The `configurationParameter()` and `configurationParameters()` methods in
+   `LauncherDiscoveryRequestBuilder` which
+   is used to build a request supplied to the <<launcher-api, Launcher API>>.
+    +
+   When running tests via one of the tools provided by the JUnit Platform you can specify
+   configuration parameters as follows:
+   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
+     option.
+   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
+     `systemProperties` DSL.
+   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
+     `configurationParameters` property.
+2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
+    +
+   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
+   specify custom configuration files using the `--config-resource` command-line option.
+3. JVM system properties.
+4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
+   in the root of the class path that follows the syntax rules for Java `Properties`
+   files.
+
+NOTE: Configuration parameters are looked up in the exact order defined above.
+Consequently, configuration parameters supplied directly to the `Launcher` take
+precedence over those supplied via custom configuration files, system properties, and the
+default configuration file. Similarly, configuration parameters supplied via system
+properties take precedence over those supplied via the default configuration file.
+
+[[running-tests-config-params-deactivation-pattern]]
+==== Pattern Matching Syntax
+
+This section describes the pattern matching syntax that is applied to the _configuration
+parameters_ used for the following features.
+
+- <<extensions-conditions-deactivation>>
+- <<launcher-api-listeners-custom-deactivation>>
+- <<stacktrace-pruning>>
+- <<extensions-registration-automatic-filtering>>
+
+If the value for the given _configuration parameter_ consists solely of an asterisk
+(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
+will be treated as a comma-separated list of patterns where each pattern will be matched
+against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
+a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
+(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
+pattern will be matched one-to-one against a FQCN.
+
+Examples:
+
+- `+++*+++`: matches all candidate classes.
+- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
+  any of its subpackages.
+- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
+  `MyCustomImpl`.
+- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
+- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
+  `System` or `Unit`.
+- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
+  `org.example.MyCustomImpl`.
+- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
+  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
+
+[[running-tests-tags]]
+=== Tags
+
+Tags are a JUnit Platform concept for marking and filtering tests. The programming model
+for adding tags to containers and tests is defined by the testing framework. For example,
+in JUnit Jupiter based tests, the `@Tag` annotation (see
+<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
+Vintage engine maps `@Category` annotations to tags (see
+<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
+own annotation or other means for users to specify tags.
+
+[[running-tests-tag-syntax-rules]]
+==== Syntax Rules for Tags
+
+Regardless how a tag is specified, the JUnit Platform enforces the following rules:
+
+* A tag must not be `null` or _blank_.
+* A _stripped_ tag must not contain whitespace.
+* A _stripped_ tag must not contain ISO control characters.
+* A _stripped_ tag must not contain any of the following _reserved characters_.
+- `,`: _comma_
+- `(`: _left parenthesis_
+- `)`: _right parenthesis_
+- `&`: _ampersand_
+- `|`: _vertical bar_
+- `!`: _exclamation point_
+
+NOTE: In the above context, "stripped" means that leading and trailing whitespace
+characters have been removed using `java.lang.String.strip()`.
+
+[[running-tests-tag-expressions]]
+==== Tag Expressions
+
+Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
+`(` and `)` can be used to adjust for operator precedence.
+
+Two special expressions are supported, `any()` and `none()`, which select all tests _with_
+any tags at all, and all tests _without_ any tags, respectively.
+These special expressions may be combined with other expressions just like normal tags.
+
+.Operators (in descending order of precedence)
+|===
+| Operator | Meaning | Associativity
+
+| `!`      | not     | right
+| `&`      | and     | left
+| `\|`     | or      | left
+|===
+
+If you are tagging your tests across multiple dimensions, tag expressions help you to
+select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
+_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
+expressions can be useful.
+
+[%header,cols="40,60"]
+|===
+| Tag Expression
+| Selection
+
+| `+++product+++`
+| all tests for *product*
+
+| `+++catalog \| shipping+++`
+| all tests for *catalog* plus all tests for *shipping*
+
+| `+++catalog &amp; shipping+++`
+| all tests for the intersection between *catalog* and *shipping*
+
+| `+++product &amp; !end-to-end+++`
+| all tests for *product*, but not the _end-to-end_ tests
+
+| `+++(micro \| integration) &amp; (product \| shipping)+++`
+| all _micro_ or _integration_ tests for *product* or *shipping*
+|===
+
+[[running-tests-capturing-output]]
+=== Capturing Standard Output/Error
+
+The JUnit Platform provides opt-in support for capturing output printed to `System.out`
+and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
+`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
+parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
+to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
+
+If enabled, the JUnit Platform captures the corresponding output and publishes it as a
+report entry using the `stdout` or `stderr` keys to all registered
+`{TestExecutionListener}` instances immediately before reporting the test or container as
+finished.
+
+Please note that the captured output will only contain output emitted by the thread that
+was used to execute a container or test. Any output by other threads will be omitted
+because particularly when
+<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
+to attribute it to a specific test or container.
+
+[[running-tests-listeners]]
+=== Using Listeners and Interceptors
+
+The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
+and custom user code to react to events fired at various points during the discovery and
+execution of a `TestPlan`.
+
+* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
+  closed.
+* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
+  `LauncherSession`.
+* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
+* `{TestExecutionListener}`: receives events that occur during test execution.
+
+The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
+registered automatically for you in order to support some feature of the build tool or IDE.
+
+The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
+order to produce some form of report or to display a graphical representation of the test
+plan in an IDE. Such listeners may be implemented and automatically registered by a build
+tool or IDE, or they may be included in a third-party library – potentially registered
+for you automatically. You can also implement and register your own listeners.
+
+For details on registering and configuring listeners, see the following sections of this
+guide.
+
+* <<launcher-api-launcher-session-listeners-custom>>
+* <<launcher-api-launcher-interceptors-custom>>
+* <<launcher-api-launcher-discovery-listeners-custom>>
+* <<launcher-api-listeners-custom>>
+* <<launcher-api-listeners-config>>
+* <<launcher-api-listeners-custom-deactivation>>
+
+The JUnit Platform provides the following listeners which you may wish to use with your
+test suite.
+
+<<junit-platform-reporting>> ::
+  `{LegacyXmlReportGeneratingListener}` can be used via the
+  <<running-tests-console-launcher>> or registered manually to generate XML reports
+  compatible with the de facto standard for JUnit 4 based test reports.
++
+`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
+specified by {OpenTestReporting}. It is auto-registered and can be enabled and
+configured via <<running-tests-config-params>>.
++
+See <<junit-platform-reporting>> for details.
+
+<<running-tests-listeners-flight-recorder>> ::
+  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
+  Java Flight Recorder events during test discovery and execution.
+
+`{LoggingListener}` ::
+  `TestExecutionListener` for logging informational messages for all events via a
+  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
+
+`{SummaryGeneratingListener}` ::
+  `TestExecutionListener` that generates a summary of the test execution which can be
+  printed via a `PrintWriter`.
+
+`{UniqueIdTrackingListener}` ::
+  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
+  or executed during the execution of the `TestPlan` and generates a file containing the
+  unique IDs once execution of the `TestPlan` has finished.
+
+[[running-tests-listeners-flight-recorder]]
+==== Flight Recorder Support
+
+The JUnit Platform provides opt-in support for generating Flight Recorder events.
+https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
+follows.
+
+> Flight Recorder records events originating from applications, the JVM, and the OS.
+Events are stored in a single file that can be attached to bug reports and examined by
+support engineers, allowing after-the-fact analysis of issues in the period leading up
+to a problem.
+
+In order to record Flight Recorder events generated while running tests, you need to
+start flight recording when launching a test suite via the following java command line
+option.
+
+   -XX:StartFlightRecording:filename=...
+
+Please consult the manual of your build tool for the appropriate commands.
+
+To analyze the recorded events, use the
+https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
+command line tool shipped with recent JDKs or open the recording file with
+https://jdk.java.net/jmc/[JDK Mission Control].
+
+[[stacktrace-pruning]]
+=== Stack Trace Pruning
+
+The JUnit Platform provides built-in support for pruning stack traces produced by failing
+tests. This feature is enabled by default but can be disabled by setting the
+`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
+
+When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
+packages are removed from the stack trace, unless the calls occur after the test itself
+or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
+never be excluded.
+
+In addition, all elements prior to and including the first call from the JUnit Platform
+`Launcher` will be removed.
+
+[[running-tests-discovery-issues]]
+=== Discovery Issues
+
+Test engines may encounter issues during test discovery. For example, the declaration of a
+test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
+Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
+report them with different severity levels:
+
+INFO::
+Indicates that the engine encountered something that could be potentially problematic, but
+could also happen due to a valid setup or configuration.
+
+WARNING::
+Indicates that the engine encountered something that is problematic and might lead to
+unexpected behavior or will be removed or changed in a future release.
+
+ERROR::
+Indicates that the engine encountered something that is definitely problematic and will
+lead to unexpected behavior.
+
+If an engine reports an issue with a severity equal to or higher than a configurable
+_critical_ severity, its tests will not be executed. Instead, the engine will be reported
+as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
+Non-critical issues will be logged but will not prevent the engine from executing its
+tests. The `junit.platform.discovery.issue.severity.critical`
+<<running-tests-config-params, configuration parameter>> can be used to set the critical
+severity level. Currently, the default value is `ERROR` but it may be changed in a future
+release.
+
+TIP: To surface all discovery issues in your project, it is recommended to set the
+`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
+
+In addition, registered `{LauncherDiscoveryListener}` implementations can receive
+discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
+report issues to the user in a more user-friendly way. For example, IDEs may choose to
+display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/ide-support.adoc b/documentation/modules/ROOT/pages/running-tests/ide-support.adoc
new file mode 100644
index 000000000000..3099a146c2b4
--- /dev/null
+++ b/documentation/modules/ROOT/pages/running-tests/ide-support.adoc
@@ -0,0 +1,1216 @@
+[[running-tests]]
+== Running Tests
+
+[[running-tests-ide]]
+=== IDE Support
+
+[[running-tests-ide-intellij-idea]]
+==== IntelliJ IDEA
+
+IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
+information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
+however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
+IDEA download the following JARs automatically based on the API version used in the
+project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
+
+In order to use a different JUnit version (e.g., {version}), you may need to
+include the corresponding versions of the `junit-platform-launcher`,
+`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
+
+.Additional Gradle Dependencies
+[source,groovy]
+[subs=attributes+]
+----
+testImplementation(platform("org.junit:junit-bom:{version}"))
+testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
+testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
+----
+
+.Additional Maven Dependencies
+[source,xml]
+[subs=attributes+]
+----
+<!-- ... -->
+<dependencies>
+	<dependency>
+		<groupId>org.junit.platform</groupId>
+		<artifactId>junit-platform-launcher</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.jupiter</groupId>
+		<artifactId>junit-jupiter-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.vintage</groupId>
+		<artifactId>junit-vintage-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+</dependencies>
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+[[running-tests-ide-eclipse]]
+==== Eclipse
+
+Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
+release.
+
+For more information on using JUnit Platform in Eclipse consult the official _Eclipse
+support for JUnit 5_ section of the
+https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
+(4.7.1a) - New and Noteworthy] documentation.
+
+[[running-tests-ide-netbeans]]
+==== NetBeans
+
+NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
+https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
+
+For more information consult the JUnit 5 section of the
+https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
+release notes].
+
+[[running-tests-ide-vscode]]
+==== Visual Studio Code
+
+https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
+Platform via the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
+Runner] extension which is installed by default as part of the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
+Extension Pack].
+
+For more information consult the _Testing_ section of the
+https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
+documentation.
+
+[[running-tests-ide-other]]
+==== Other IDEs
+
+If you are using an editor or IDE other than one of those listed in the previous sections,
+and it doesn't support running tests on the JUnit Platform, you can use the
+<<running-tests-console-launcher>> to run them from the command line.
+
+[[running-tests-build]]
+=== Build Support
+
+[[running-tests-build-gradle]]
+==== Gradle
+
+Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
+https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
+for executing tests on the JUnit Platform. To enable it, you need to specify
+`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform()
+}
+----
+
+Filtering by <<running-tests-tags, tags>>,
+<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform {
+		includeTags("fast", "smoke & feature-a")
+		// excludeTags("slow", "ci")
+		includeEngines("junit-jupiter")
+		// excludeEngines("junit-vintage")
+	}
+}
+----
+
+Please refer to the
+https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
+for a comprehensive list of options.
+
+[[running-tests-build-gradle-bom]]
+===== Aligning dependency versions
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Explicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation(platform("org.junit:junit-bom:{version}"))
+	testImplementation("org.junit.jupiter:junit-jupiter")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+Since all JUnit artifacts declare a
+https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
+you usually don't need to declare an explicit dependency on it yourself. Instead, it's
+sufficient to declare _one_ regular dependency that includes a version number. Gradle will
+then pull in the BOM automatically so you can omit the version for all other JUnit
+artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Implicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
+}
+----
+<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
+<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
+
+[WARNING]
+.Declaring a dependency on junit-platform-launcher
+====
+Even though pre-8.0 versions of Gradle don't require declaring an explicit
+dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
+of JUnit artifacts on the test runtime classpath are aligned.
+
+Moreover, doing so is recommended and in some cases even required when importing the
+project into an IDE like <<running-tests-ide-eclipse>> or
+<<running-tests-ide-intellij-idea>>.
+====
+
+[[running-tests-build-gradle-engines-configure]]
+===== Configuring Test Engines
+
+In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
+
+To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
+on the dependency-aggregating JUnit Jupiter artifact similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Alternatively, you can use Gradle's
+https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
+support.
+
+[source,kotlin,indent=0]
+[subs=attributes+]
+.Kotlin DSL
+----
+testing {
+	suites {
+		named<JvmTestSuite>("test") {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Groovy DSL
+----
+testing {
+	suites {
+		test {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
+dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
+implementation similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("junit:junit:{junit4-version}")
+	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+[[running-tests-build-gradle-config-params]]
+===== Configuration Parameters
+
+The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
+Platform <<running-tests-config-params, configuration parameters>> to influence test
+discovery and execution. However, you can provide configuration parameters within the
+build script via system properties (as shown below) or via the
+`junit-platform.properties` file.
+
+[source,groovy,indent=0]
+----
+test {
+	// ...
+	systemProperty("junit.jupiter.conditions.deactivate", "*")
+	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
+	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
+	// ...
+}
+----
+
+[[running-tests-build-gradle-logging]]
+===== Configuring Logging (optional)
+
+JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
+emit warnings and debug information. Please refer to the official documentation of
+`{LogManager}` for configuration options.
+
+Alternatively, it's possible to redirect log messages to other logging frameworks such as
+{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
+`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
+qualified class name_ of the `{LogManager}` implementation to use. The example below
+demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
+details).
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
+	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
+	systemProperty("log4j2.disableJmx", "true")
+}
+----
+
+Other logging frameworks provide different means to redirect messages logged using
+`java.util.logging`. For example, for {Logback} you can use the
+https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
+dependency to the test runtime classpath.
+
+[[running-tests-build-maven]]
+==== Maven
+
+Maven Surefire and Maven Failsafe provide
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
+for executing tests on the JUnit Platform. The `pom.xml` file in the
+`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
+and can serve as a starting point for configuring your Maven build.
+
+[WARNING]
+.Minimum required version of Maven Surefire/Failsafe
+====
+As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
+====
+
+[[running-tests-build-maven-bom]]
+===== Aligning dependency versions
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+[[running-tests-build-maven-engines-configure]]
+===== Configuring Test Engines
+
+In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
+`TestEngine` implementation must be added to the test classpath.
+
+To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
+on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
+following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>org.junit.jupiter</groupId>
+			<artifactId>junit-jupiter</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
+long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
+`TestEngine` implementation similar to the following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>junit</groupId>
+			<artifactId>junit</artifactId>
+			<version>{junit4-version}</version>
+			<scope>test</scope>
+		</dependency>
+		<dependency>
+			<groupId>org.junit.vintage</groupId>
+			<artifactId>junit-vintage-engine</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-filter-test-class-names]]
+===== Filtering by Test Class Names
+
+The Maven Surefire Plugin will scan for test classes whose fully qualified names match
+the following patterns.
+
+- `+++**/Test*.java+++`
+- `+++**/*Test.java+++`
+- `+++**/*Tests.java+++`
+- `+++**/*TestCase.java+++`
+
+Moreover, it will exclude all nested classes (including static member classes) by default.
+
+Note, however, that you can override this default behavior by configuring explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
+from excluding static member classes, you can override its exclude rules as follows.
+
+[source,xml,indent=0]
+[subs=attributes+]
+.Overriding exclude rules of Maven Surefire
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<excludes>
+						<exclude/>
+					</excludes>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Please see the
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
+documentation for Maven Surefire for details.
+
+[[running-tests-build-maven-filter-tags]]
+===== Filtering by Tags
+
+You can filter tests by <<running-tests-tags, tags>> or
+<<running-tests-tag-expressions, tag expressions>> using the following configuration
+properties.
+
+- to include _tags_ or _tag expressions_, use `groups`.
+- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<groups>acceptance | !feature-a</groups>
+					<excludedGroups>integration, regression</excludedGroups>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-config-params]]
+===== Configuration Parameters
+
+You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
+influence test discovery and execution by declaring the `configurationParameters`
+property and providing key-value pairs using the Java `Properties` file syntax (as shown
+below) or via the `junit-platform.properties` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<properties>
+						<configurationParameters>
+							junit.jupiter.conditions.deactivate = *
+							junit.jupiter.extensions.autodetection.enabled = true
+							junit.jupiter.testinstance.lifecycle.default = per_class
+						</configurationParameters>
+					</properties>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-ant]]
+==== Ant
+
+Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
+provides native support for launching tests on the JUnit Platform. The `junitlauncher`
+task is solely responsible for launching the JUnit Platform and passing it the selected
+collection of tests. The JUnit Platform then delegates to registered test engines to
+discover and execute the tests.
+
+The `junitlauncher` task attempts to align as closely as possible with native Ant
+constructs such as
+link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
+for allowing users to select the tests that they want executed by test engines. This gives
+the task a consistent and natural feel when compared to many other core Ant tasks.
+
+Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
+
+The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
+the task and can serve as a starting point.
+
+===== Basic Usage
+
+The following example demonstrates how to configure the `junitlauncher` task to select a
+single test class (i.e., `com.example.project.CalculatorTests`).
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+
+	<!-- ... -->
+
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<test name="com.example.project.CalculatorTests" />
+	</junitlauncher>
+----
+
+The `test` element allows you to specify a single test class that you want to be selected
+and executed. The `classpath` element allows you to specify the classpath to be used to
+launch the JUnit Platform. This classpath will also be used to locate test classes that
+are part of the execution.
+
+The following example demonstrates how to configure the `junitlauncher` task to select
+test classes from multiple locations.
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+	<!-- ... -->
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<testclasses outputdir="${output.dir}">
+			<fileset dir="${build.classes.dir}">
+				<include name="org/example/**/demo/**/" />
+			</fileset>
+			<fileset dir="${some.other.dir}">
+				<include name="org/myapp/**/" />
+			</fileset>
+		</testclasses>
+	</junitlauncher>
+----
+
+In the above example, the `testclasses` element allows you to select multiple test
+classes that reside in different locations.
+
+For further details on usage and configuration options please refer to the official Ant
+documentation for the
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
+
+[[running-tests-build-spring-boot]]
+==== Spring Boot
+
+link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
+managing the version of JUnit used in your project. In addition, the
+`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
+Jupiter, AssertJ, Mockito, etc.
+
+If your build relies on dependency management support from Spring Boot, you should not
+import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
+result in duplicate (and potentially conflicting) management of JUnit dependencies.
+
+If you need to override the version of a dependency used in your Spring Boot application,
+you have to override the exact name of the
+link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
+defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
+Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
+changing a dependency version is documented for both
+link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
+and
+link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
+
+With Gradle you can override the JUnit Jupiter version by including the following in your
+`build.gradle` file.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+	ext['junit-jupiter.version'] = '{version}'
+----
+
+With Maven you can override the JUnit Jupiter version by including the following in your
+`pom.xml` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<properties>
+		<junit-jupiter.version>{version}</junit-jupiter.version>
+	</properties>
+----
+
+[[running-tests-console-launcher]]
+=== Console Launcher
+
+The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
+Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
+Jupiter tests and print test execution results to the console.
+
+An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
+contains the contents of all of its dependencies is published in the {Maven_Central}
+repository under the
+https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
+directory. It contains the contents of the following artifacts:
+
+include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
+
+[NOTE]
+====
+Since the `junit-platform-console-standalone` JAR contains the contents of all of its
+dependencies, its Maven POM does not declare any dependencies.
+
+Furthermore, it is not very likely that you would need to include a dependency on the
+`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
+script. On the contrary, the executable `junit-platform-console-standalone` JAR is
+typically invoked directly from the command line or a shell script without a build script.
+
+If you need to declare dependencies in your build script on some of the artifacts
+contained in the `junit-platform-console-standalone` artifact, you should declare
+dependencies only on the JUnit artifacts that are used in your project. To simplify
+dependency management of JUnit artifacts in your build, you may wish to use the
+`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
+details.
+====
+
+You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
+standalone `ConsoleLauncher` as shown below.
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
+
+├─ JUnit Vintage
+│  └─ example.JUnit4Tests
+│     └─ standardJUnit4Test ✔
+└─ JUnit Jupiter
+   ├─ StandardTests
+   │  ├─ succeedingTest() ✔
+   │  └─ skippedTest() ↷ for demonstration purposes
+   └─ A special test case
+      ├─ Custom test name containing spaces ✔
+      ├─ ╯°□°)╯ ✔
+      └─ 😱 ✔
+
+Test run finished after 64 ms
+[         5 containers found      ]
+[         0 containers skipped    ]
+[         5 containers started    ]
+[         0 containers aborted    ]
+[         5 containers successful ]
+[         0 containers failed     ]
+[         6 tests found           ]
+[         1 tests skipped         ]
+[         5 tests started         ]
+[         0 tests aborted         ]
+[         5 tests successful      ]
+[         0 tests failed          ]
+----
+
+You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
+all jars in a directory):
+
+[source,console,subs=attributes+]
+----
+$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
+----
+
+[[running-tests-console-launcher-options]]
+==== Subcommands and Options
+
+The `{ConsoleLauncher}` provides the following subcommands:
+
+----
+include::{consoleLauncherOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-discovering-tests]]
+===== Discovering tests
+
+----
+include::{consoleLauncherDiscoverOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-executing-tests]]
+===== Executing tests
+
+.Exit Code
+NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
+All non-zero codes indicate an error of some sort. For example, status code `1`
+is returned if any containers or tests failed. If no tests are discovered and the
+`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
+with a status code of `2`. Unexpected or invalid user input yields a status code
+of `3`. An exit code of `-1` indicates an unspecified error condition.
+
+----
+include::{consoleLauncherExecuteOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-listing-test-engines]]
+===== Listing test engines
+
+----
+include::{consoleLauncherEnginesOptionsFile}[]
+----
+
+[[running-tests-console-launcher-argument-files]]
+==== Argument Files (@-files)
+
+On some platforms you may run into system limitations on the length of a command line when
+creating a command line with lots of options or with long arguments.
+
+The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
+are files that themselves contain arguments to be passed to the command. When the
+underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
+argument beginning with the character `@`, it expands the contents of that file into the
+argument list.
+
+The arguments within a file can be separated by spaces or newlines. If an argument
+contains embedded whitespace, the whole argument should be wrapped in double or single
+quotes -- for example, `"-f=My Files/Stuff.java"`.
+
+If the argument file does not exist or cannot be read, the argument will be treated
+literally and will not be removed. This will likely result in an "unmatched argument"
+error message. You can troubleshoot such errors by executing the command with the
+`picocli.trace` system property set to `DEBUG`.
+
+Multiple _@-files_ may be specified on the command line. The specified path may be
+relative to the current directory or absolute.
+
+You can pass a real parameter with an initial `@` character by escaping it with an
+additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
+subject to expansion.
+
+[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
+==== Redirecting Standard Output/Error to Files
+
+You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
+files using the `--redirect-stdout` and `--redirect-stderr` options:
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
+  --redirect-stdout=stdout.txt \
+  --redirect-stderr=stderr.txt
+----
+
+[NOTE]
+====
+If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
+output streams will be redirected to that file.
+
+The default charset is used for writing to the files.
+====
+
+[[running-tests-console-launcher-color-customization]]
+==== Color Customization
+
+The colors used in the output of the `{ConsoleLauncher}` can be customized.
+The option `--single-color` will apply a built-in monochrome style, while
+`--color-palette` will accept a properties file to override the
+https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
+The properties file below demonstrates the default style:
+
+[source,properties,indent=0]
+----
+SUCCESSFUL = 32
+ABORTED = 33
+FAILED = 31
+SKIPPED = 35
+CONTAINER = 35
+TEST = 34
+DYNAMIC = 35
+REPORTED = 37
+----
+
+[[running-tests-source-launcher]]
+=== Source Launcher
+
+Starting with Java 25 it is possible to write minimal source code test programs
+using the `org.junit.start` module. For example, like in a `HelloTests.java`
+file reading:
+
+```java
+import module org.junit.start;
+
+void main() {
+  JUnit.run();
+}
+
+@Test
+void stringLength() {
+  Assertions.assertEquals(11, "Hello JUnit".length());
+}
+```
+With all required modular JAR files available in a local `lib/` directory, the
+following Java 25+ command will discover and execute tests using the JUnit Platform.
+It will also print the result tree to the console.
+
+```shell
+java --module-path lib --add-modules org.junit.start HelloTests.java
+╷
+└─ JUnit Jupiter ✔
+   └─ HelloTests ✔
+      └─ stringLength() ✔
+```
+
+Find JUnit's class API documentation here: {JUnit}
+
+[[running-tests-discovery-selectors]]
+=== Discovery Selectors
+
+The JUnit Platform provides a rich set of discovery selectors that can be used to specify
+which tests should be discovered or executed.
+
+Discovery selectors can be created programmatically using the factory methods in the
+`{DiscoverySelectors}` class, specified declaratively via annotations when using the
+<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
+generically as strings via their identifiers.
+
+The following discovery selectors are provided out of the box:
+
+|===
+| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
+
+| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
+| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
+| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
+| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
+| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
+| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
+| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
+| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
+| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
+| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
+| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
+| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
+| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
+|===
+
+
+[[running-tests-config-params]]
+=== Configuration Parameters
+
+In addition to instructing the platform which test classes and test engines to include,
+which packages to scan, etc., it is sometimes necessary to provide additional custom
+configuration parameters that are specific to a particular test engine, listener, or
+registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
+parameters_ for the following use cases.
+
+- <<writing-tests-test-instance-lifecycle-changing-default>>
+- <<extensions-registration-automatic-enabling>>
+- <<extensions-conditions-deactivation>>
+- <<writing-tests-display-name-generator-default>>
+
+_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
+engines running on the JUnit Platform via one of the following mechanisms.
+
+1. The `configurationParameter()` and `configurationParameters()` methods in
+   `LauncherDiscoveryRequestBuilder` which
+   is used to build a request supplied to the <<launcher-api, Launcher API>>.
+    +
+   When running tests via one of the tools provided by the JUnit Platform you can specify
+   configuration parameters as follows:
+   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
+     option.
+   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
+     `systemProperties` DSL.
+   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
+     `configurationParameters` property.
+2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
+    +
+   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
+   specify custom configuration files using the `--config-resource` command-line option.
+3. JVM system properties.
+4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
+   in the root of the class path that follows the syntax rules for Java `Properties`
+   files.
+
+NOTE: Configuration parameters are looked up in the exact order defined above.
+Consequently, configuration parameters supplied directly to the `Launcher` take
+precedence over those supplied via custom configuration files, system properties, and the
+default configuration file. Similarly, configuration parameters supplied via system
+properties take precedence over those supplied via the default configuration file.
+
+[[running-tests-config-params-deactivation-pattern]]
+==== Pattern Matching Syntax
+
+This section describes the pattern matching syntax that is applied to the _configuration
+parameters_ used for the following features.
+
+- <<extensions-conditions-deactivation>>
+- <<launcher-api-listeners-custom-deactivation>>
+- <<stacktrace-pruning>>
+- <<extensions-registration-automatic-filtering>>
+
+If the value for the given _configuration parameter_ consists solely of an asterisk
+(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
+will be treated as a comma-separated list of patterns where each pattern will be matched
+against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
+a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
+(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
+pattern will be matched one-to-one against a FQCN.
+
+Examples:
+
+- `+++*+++`: matches all candidate classes.
+- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
+  any of its subpackages.
+- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
+  `MyCustomImpl`.
+- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
+- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
+  `System` or `Unit`.
+- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
+  `org.example.MyCustomImpl`.
+- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
+  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
+
+[[running-tests-tags]]
+=== Tags
+
+Tags are a JUnit Platform concept for marking and filtering tests. The programming model
+for adding tags to containers and tests is defined by the testing framework. For example,
+in JUnit Jupiter based tests, the `@Tag` annotation (see
+<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
+Vintage engine maps `@Category` annotations to tags (see
+<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
+own annotation or other means for users to specify tags.
+
+[[running-tests-tag-syntax-rules]]
+==== Syntax Rules for Tags
+
+Regardless how a tag is specified, the JUnit Platform enforces the following rules:
+
+* A tag must not be `null` or _blank_.
+* A _stripped_ tag must not contain whitespace.
+* A _stripped_ tag must not contain ISO control characters.
+* A _stripped_ tag must not contain any of the following _reserved characters_.
+- `,`: _comma_
+- `(`: _left parenthesis_
+- `)`: _right parenthesis_
+- `&`: _ampersand_
+- `|`: _vertical bar_
+- `!`: _exclamation point_
+
+NOTE: In the above context, "stripped" means that leading and trailing whitespace
+characters have been removed using `java.lang.String.strip()`.
+
+[[running-tests-tag-expressions]]
+==== Tag Expressions
+
+Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
+`(` and `)` can be used to adjust for operator precedence.
+
+Two special expressions are supported, `any()` and `none()`, which select all tests _with_
+any tags at all, and all tests _without_ any tags, respectively.
+These special expressions may be combined with other expressions just like normal tags.
+
+.Operators (in descending order of precedence)
+|===
+| Operator | Meaning | Associativity
+
+| `!`      | not     | right
+| `&`      | and     | left
+| `\|`     | or      | left
+|===
+
+If you are tagging your tests across multiple dimensions, tag expressions help you to
+select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
+_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
+expressions can be useful.
+
+[%header,cols="40,60"]
+|===
+| Tag Expression
+| Selection
+
+| `+++product+++`
+| all tests for *product*
+
+| `+++catalog \| shipping+++`
+| all tests for *catalog* plus all tests for *shipping*
+
+| `+++catalog &amp; shipping+++`
+| all tests for the intersection between *catalog* and *shipping*
+
+| `+++product &amp; !end-to-end+++`
+| all tests for *product*, but not the _end-to-end_ tests
+
+| `+++(micro \| integration) &amp; (product \| shipping)+++`
+| all _micro_ or _integration_ tests for *product* or *shipping*
+|===
+
+[[running-tests-capturing-output]]
+=== Capturing Standard Output/Error
+
+The JUnit Platform provides opt-in support for capturing output printed to `System.out`
+and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
+`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
+parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
+to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
+
+If enabled, the JUnit Platform captures the corresponding output and publishes it as a
+report entry using the `stdout` or `stderr` keys to all registered
+`{TestExecutionListener}` instances immediately before reporting the test or container as
+finished.
+
+Please note that the captured output will only contain output emitted by the thread that
+was used to execute a container or test. Any output by other threads will be omitted
+because particularly when
+<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
+to attribute it to a specific test or container.
+
+[[running-tests-listeners]]
+=== Using Listeners and Interceptors
+
+The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
+and custom user code to react to events fired at various points during the discovery and
+execution of a `TestPlan`.
+
+* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
+  closed.
+* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
+  `LauncherSession`.
+* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
+* `{TestExecutionListener}`: receives events that occur during test execution.
+
+The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
+registered automatically for you in order to support some feature of the build tool or IDE.
+
+The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
+order to produce some form of report or to display a graphical representation of the test
+plan in an IDE. Such listeners may be implemented and automatically registered by a build
+tool or IDE, or they may be included in a third-party library – potentially registered
+for you automatically. You can also implement and register your own listeners.
+
+For details on registering and configuring listeners, see the following sections of this
+guide.
+
+* <<launcher-api-launcher-session-listeners-custom>>
+* <<launcher-api-launcher-interceptors-custom>>
+* <<launcher-api-launcher-discovery-listeners-custom>>
+* <<launcher-api-listeners-custom>>
+* <<launcher-api-listeners-config>>
+* <<launcher-api-listeners-custom-deactivation>>
+
+The JUnit Platform provides the following listeners which you may wish to use with your
+test suite.
+
+<<junit-platform-reporting>> ::
+  `{LegacyXmlReportGeneratingListener}` can be used via the
+  <<running-tests-console-launcher>> or registered manually to generate XML reports
+  compatible with the de facto standard for JUnit 4 based test reports.
++
+`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
+specified by {OpenTestReporting}. It is auto-registered and can be enabled and
+configured via <<running-tests-config-params>>.
++
+See <<junit-platform-reporting>> for details.
+
+<<running-tests-listeners-flight-recorder>> ::
+  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
+  Java Flight Recorder events during test discovery and execution.
+
+`{LoggingListener}` ::
+  `TestExecutionListener` for logging informational messages for all events via a
+  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
+
+`{SummaryGeneratingListener}` ::
+  `TestExecutionListener` that generates a summary of the test execution which can be
+  printed via a `PrintWriter`.
+
+`{UniqueIdTrackingListener}` ::
+  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
+  or executed during the execution of the `TestPlan` and generates a file containing the
+  unique IDs once execution of the `TestPlan` has finished.
+
+[[running-tests-listeners-flight-recorder]]
+==== Flight Recorder Support
+
+The JUnit Platform provides opt-in support for generating Flight Recorder events.
+https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
+follows.
+
+> Flight Recorder records events originating from applications, the JVM, and the OS.
+Events are stored in a single file that can be attached to bug reports and examined by
+support engineers, allowing after-the-fact analysis of issues in the period leading up
+to a problem.
+
+In order to record Flight Recorder events generated while running tests, you need to
+start flight recording when launching a test suite via the following java command line
+option.
+
+   -XX:StartFlightRecording:filename=...
+
+Please consult the manual of your build tool for the appropriate commands.
+
+To analyze the recorded events, use the
+https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
+command line tool shipped with recent JDKs or open the recording file with
+https://jdk.java.net/jmc/[JDK Mission Control].
+
+[[stacktrace-pruning]]
+=== Stack Trace Pruning
+
+The JUnit Platform provides built-in support for pruning stack traces produced by failing
+tests. This feature is enabled by default but can be disabled by setting the
+`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
+
+When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
+packages are removed from the stack trace, unless the calls occur after the test itself
+or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
+never be excluded.
+
+In addition, all elements prior to and including the first call from the JUnit Platform
+`Launcher` will be removed.
+
+[[running-tests-discovery-issues]]
+=== Discovery Issues
+
+Test engines may encounter issues during test discovery. For example, the declaration of a
+test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
+Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
+report them with different severity levels:
+
+INFO::
+Indicates that the engine encountered something that could be potentially problematic, but
+could also happen due to a valid setup or configuration.
+
+WARNING::
+Indicates that the engine encountered something that is problematic and might lead to
+unexpected behavior or will be removed or changed in a future release.
+
+ERROR::
+Indicates that the engine encountered something that is definitely problematic and will
+lead to unexpected behavior.
+
+If an engine reports an issue with a severity equal to or higher than a configurable
+_critical_ severity, its tests will not be executed. Instead, the engine will be reported
+as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
+Non-critical issues will be logged but will not prevent the engine from executing its
+tests. The `junit.platform.discovery.issue.severity.critical`
+<<running-tests-config-params, configuration parameter>> can be used to set the critical
+severity level. Currently, the default value is `ERROR` but it may be changed in a future
+release.
+
+TIP: To surface all discovery issues in your project, it is recommended to set the
+`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
+
+In addition, registered `{LauncherDiscoveryListener}` implementations can receive
+discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
+report issues to the user in a more user-friendly way. For example, IDEs may choose to
+display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/intro.adoc b/documentation/modules/ROOT/pages/running-tests/intro.adoc
new file mode 100644
index 000000000000..3099a146c2b4
--- /dev/null
+++ b/documentation/modules/ROOT/pages/running-tests/intro.adoc
@@ -0,0 +1,1216 @@
+[[running-tests]]
+== Running Tests
+
+[[running-tests-ide]]
+=== IDE Support
+
+[[running-tests-ide-intellij-idea]]
+==== IntelliJ IDEA
+
+IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
+information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
+however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
+IDEA download the following JARs automatically based on the API version used in the
+project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
+
+In order to use a different JUnit version (e.g., {version}), you may need to
+include the corresponding versions of the `junit-platform-launcher`,
+`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
+
+.Additional Gradle Dependencies
+[source,groovy]
+[subs=attributes+]
+----
+testImplementation(platform("org.junit:junit-bom:{version}"))
+testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
+testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
+----
+
+.Additional Maven Dependencies
+[source,xml]
+[subs=attributes+]
+----
+<!-- ... -->
+<dependencies>
+	<dependency>
+		<groupId>org.junit.platform</groupId>
+		<artifactId>junit-platform-launcher</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.jupiter</groupId>
+		<artifactId>junit-jupiter-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.vintage</groupId>
+		<artifactId>junit-vintage-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+</dependencies>
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+[[running-tests-ide-eclipse]]
+==== Eclipse
+
+Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
+release.
+
+For more information on using JUnit Platform in Eclipse consult the official _Eclipse
+support for JUnit 5_ section of the
+https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
+(4.7.1a) - New and Noteworthy] documentation.
+
+[[running-tests-ide-netbeans]]
+==== NetBeans
+
+NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
+https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
+
+For more information consult the JUnit 5 section of the
+https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
+release notes].
+
+[[running-tests-ide-vscode]]
+==== Visual Studio Code
+
+https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
+Platform via the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
+Runner] extension which is installed by default as part of the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
+Extension Pack].
+
+For more information consult the _Testing_ section of the
+https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
+documentation.
+
+[[running-tests-ide-other]]
+==== Other IDEs
+
+If you are using an editor or IDE other than one of those listed in the previous sections,
+and it doesn't support running tests on the JUnit Platform, you can use the
+<<running-tests-console-launcher>> to run them from the command line.
+
+[[running-tests-build]]
+=== Build Support
+
+[[running-tests-build-gradle]]
+==== Gradle
+
+Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
+https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
+for executing tests on the JUnit Platform. To enable it, you need to specify
+`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform()
+}
+----
+
+Filtering by <<running-tests-tags, tags>>,
+<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform {
+		includeTags("fast", "smoke & feature-a")
+		// excludeTags("slow", "ci")
+		includeEngines("junit-jupiter")
+		// excludeEngines("junit-vintage")
+	}
+}
+----
+
+Please refer to the
+https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
+for a comprehensive list of options.
+
+[[running-tests-build-gradle-bom]]
+===== Aligning dependency versions
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Explicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation(platform("org.junit:junit-bom:{version}"))
+	testImplementation("org.junit.jupiter:junit-jupiter")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+Since all JUnit artifacts declare a
+https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
+you usually don't need to declare an explicit dependency on it yourself. Instead, it's
+sufficient to declare _one_ regular dependency that includes a version number. Gradle will
+then pull in the BOM automatically so you can omit the version for all other JUnit
+artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Implicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
+}
+----
+<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
+<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
+
+[WARNING]
+.Declaring a dependency on junit-platform-launcher
+====
+Even though pre-8.0 versions of Gradle don't require declaring an explicit
+dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
+of JUnit artifacts on the test runtime classpath are aligned.
+
+Moreover, doing so is recommended and in some cases even required when importing the
+project into an IDE like <<running-tests-ide-eclipse>> or
+<<running-tests-ide-intellij-idea>>.
+====
+
+[[running-tests-build-gradle-engines-configure]]
+===== Configuring Test Engines
+
+In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
+
+To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
+on the dependency-aggregating JUnit Jupiter artifact similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Alternatively, you can use Gradle's
+https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
+support.
+
+[source,kotlin,indent=0]
+[subs=attributes+]
+.Kotlin DSL
+----
+testing {
+	suites {
+		named<JvmTestSuite>("test") {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Groovy DSL
+----
+testing {
+	suites {
+		test {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
+dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
+implementation similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("junit:junit:{junit4-version}")
+	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+[[running-tests-build-gradle-config-params]]
+===== Configuration Parameters
+
+The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
+Platform <<running-tests-config-params, configuration parameters>> to influence test
+discovery and execution. However, you can provide configuration parameters within the
+build script via system properties (as shown below) or via the
+`junit-platform.properties` file.
+
+[source,groovy,indent=0]
+----
+test {
+	// ...
+	systemProperty("junit.jupiter.conditions.deactivate", "*")
+	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
+	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
+	// ...
+}
+----
+
+[[running-tests-build-gradle-logging]]
+===== Configuring Logging (optional)
+
+JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
+emit warnings and debug information. Please refer to the official documentation of
+`{LogManager}` for configuration options.
+
+Alternatively, it's possible to redirect log messages to other logging frameworks such as
+{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
+`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
+qualified class name_ of the `{LogManager}` implementation to use. The example below
+demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
+details).
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
+	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
+	systemProperty("log4j2.disableJmx", "true")
+}
+----
+
+Other logging frameworks provide different means to redirect messages logged using
+`java.util.logging`. For example, for {Logback} you can use the
+https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
+dependency to the test runtime classpath.
+
+[[running-tests-build-maven]]
+==== Maven
+
+Maven Surefire and Maven Failsafe provide
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
+for executing tests on the JUnit Platform. The `pom.xml` file in the
+`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
+and can serve as a starting point for configuring your Maven build.
+
+[WARNING]
+.Minimum required version of Maven Surefire/Failsafe
+====
+As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
+====
+
+[[running-tests-build-maven-bom]]
+===== Aligning dependency versions
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+[[running-tests-build-maven-engines-configure]]
+===== Configuring Test Engines
+
+In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
+`TestEngine` implementation must be added to the test classpath.
+
+To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
+on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
+following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>org.junit.jupiter</groupId>
+			<artifactId>junit-jupiter</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
+long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
+`TestEngine` implementation similar to the following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>junit</groupId>
+			<artifactId>junit</artifactId>
+			<version>{junit4-version}</version>
+			<scope>test</scope>
+		</dependency>
+		<dependency>
+			<groupId>org.junit.vintage</groupId>
+			<artifactId>junit-vintage-engine</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-filter-test-class-names]]
+===== Filtering by Test Class Names
+
+The Maven Surefire Plugin will scan for test classes whose fully qualified names match
+the following patterns.
+
+- `+++**/Test*.java+++`
+- `+++**/*Test.java+++`
+- `+++**/*Tests.java+++`
+- `+++**/*TestCase.java+++`
+
+Moreover, it will exclude all nested classes (including static member classes) by default.
+
+Note, however, that you can override this default behavior by configuring explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
+from excluding static member classes, you can override its exclude rules as follows.
+
+[source,xml,indent=0]
+[subs=attributes+]
+.Overriding exclude rules of Maven Surefire
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<excludes>
+						<exclude/>
+					</excludes>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Please see the
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
+documentation for Maven Surefire for details.
+
+[[running-tests-build-maven-filter-tags]]
+===== Filtering by Tags
+
+You can filter tests by <<running-tests-tags, tags>> or
+<<running-tests-tag-expressions, tag expressions>> using the following configuration
+properties.
+
+- to include _tags_ or _tag expressions_, use `groups`.
+- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<groups>acceptance | !feature-a</groups>
+					<excludedGroups>integration, regression</excludedGroups>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-config-params]]
+===== Configuration Parameters
+
+You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
+influence test discovery and execution by declaring the `configurationParameters`
+property and providing key-value pairs using the Java `Properties` file syntax (as shown
+below) or via the `junit-platform.properties` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<properties>
+						<configurationParameters>
+							junit.jupiter.conditions.deactivate = *
+							junit.jupiter.extensions.autodetection.enabled = true
+							junit.jupiter.testinstance.lifecycle.default = per_class
+						</configurationParameters>
+					</properties>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-ant]]
+==== Ant
+
+Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
+provides native support for launching tests on the JUnit Platform. The `junitlauncher`
+task is solely responsible for launching the JUnit Platform and passing it the selected
+collection of tests. The JUnit Platform then delegates to registered test engines to
+discover and execute the tests.
+
+The `junitlauncher` task attempts to align as closely as possible with native Ant
+constructs such as
+link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
+for allowing users to select the tests that they want executed by test engines. This gives
+the task a consistent and natural feel when compared to many other core Ant tasks.
+
+Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
+
+The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
+the task and can serve as a starting point.
+
+===== Basic Usage
+
+The following example demonstrates how to configure the `junitlauncher` task to select a
+single test class (i.e., `com.example.project.CalculatorTests`).
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+
+	<!-- ... -->
+
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<test name="com.example.project.CalculatorTests" />
+	</junitlauncher>
+----
+
+The `test` element allows you to specify a single test class that you want to be selected
+and executed. The `classpath` element allows you to specify the classpath to be used to
+launch the JUnit Platform. This classpath will also be used to locate test classes that
+are part of the execution.
+
+The following example demonstrates how to configure the `junitlauncher` task to select
+test classes from multiple locations.
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+	<!-- ... -->
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<testclasses outputdir="${output.dir}">
+			<fileset dir="${build.classes.dir}">
+				<include name="org/example/**/demo/**/" />
+			</fileset>
+			<fileset dir="${some.other.dir}">
+				<include name="org/myapp/**/" />
+			</fileset>
+		</testclasses>
+	</junitlauncher>
+----
+
+In the above example, the `testclasses` element allows you to select multiple test
+classes that reside in different locations.
+
+For further details on usage and configuration options please refer to the official Ant
+documentation for the
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
+
+[[running-tests-build-spring-boot]]
+==== Spring Boot
+
+link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
+managing the version of JUnit used in your project. In addition, the
+`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
+Jupiter, AssertJ, Mockito, etc.
+
+If your build relies on dependency management support from Spring Boot, you should not
+import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
+result in duplicate (and potentially conflicting) management of JUnit dependencies.
+
+If you need to override the version of a dependency used in your Spring Boot application,
+you have to override the exact name of the
+link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
+defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
+Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
+changing a dependency version is documented for both
+link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
+and
+link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
+
+With Gradle you can override the JUnit Jupiter version by including the following in your
+`build.gradle` file.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+	ext['junit-jupiter.version'] = '{version}'
+----
+
+With Maven you can override the JUnit Jupiter version by including the following in your
+`pom.xml` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<properties>
+		<junit-jupiter.version>{version}</junit-jupiter.version>
+	</properties>
+----
+
+[[running-tests-console-launcher]]
+=== Console Launcher
+
+The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
+Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
+Jupiter tests and print test execution results to the console.
+
+An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
+contains the contents of all of its dependencies is published in the {Maven_Central}
+repository under the
+https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
+directory. It contains the contents of the following artifacts:
+
+include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
+
+[NOTE]
+====
+Since the `junit-platform-console-standalone` JAR contains the contents of all of its
+dependencies, its Maven POM does not declare any dependencies.
+
+Furthermore, it is not very likely that you would need to include a dependency on the
+`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
+script. On the contrary, the executable `junit-platform-console-standalone` JAR is
+typically invoked directly from the command line or a shell script without a build script.
+
+If you need to declare dependencies in your build script on some of the artifacts
+contained in the `junit-platform-console-standalone` artifact, you should declare
+dependencies only on the JUnit artifacts that are used in your project. To simplify
+dependency management of JUnit artifacts in your build, you may wish to use the
+`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
+details.
+====
+
+You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
+standalone `ConsoleLauncher` as shown below.
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
+
+├─ JUnit Vintage
+│  └─ example.JUnit4Tests
+│     └─ standardJUnit4Test ✔
+└─ JUnit Jupiter
+   ├─ StandardTests
+   │  ├─ succeedingTest() ✔
+   │  └─ skippedTest() ↷ for demonstration purposes
+   └─ A special test case
+      ├─ Custom test name containing spaces ✔
+      ├─ ╯°□°)╯ ✔
+      └─ 😱 ✔
+
+Test run finished after 64 ms
+[         5 containers found      ]
+[         0 containers skipped    ]
+[         5 containers started    ]
+[         0 containers aborted    ]
+[         5 containers successful ]
+[         0 containers failed     ]
+[         6 tests found           ]
+[         1 tests skipped         ]
+[         5 tests started         ]
+[         0 tests aborted         ]
+[         5 tests successful      ]
+[         0 tests failed          ]
+----
+
+You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
+all jars in a directory):
+
+[source,console,subs=attributes+]
+----
+$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
+----
+
+[[running-tests-console-launcher-options]]
+==== Subcommands and Options
+
+The `{ConsoleLauncher}` provides the following subcommands:
+
+----
+include::{consoleLauncherOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-discovering-tests]]
+===== Discovering tests
+
+----
+include::{consoleLauncherDiscoverOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-executing-tests]]
+===== Executing tests
+
+.Exit Code
+NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
+All non-zero codes indicate an error of some sort. For example, status code `1`
+is returned if any containers or tests failed. If no tests are discovered and the
+`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
+with a status code of `2`. Unexpected or invalid user input yields a status code
+of `3`. An exit code of `-1` indicates an unspecified error condition.
+
+----
+include::{consoleLauncherExecuteOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-listing-test-engines]]
+===== Listing test engines
+
+----
+include::{consoleLauncherEnginesOptionsFile}[]
+----
+
+[[running-tests-console-launcher-argument-files]]
+==== Argument Files (@-files)
+
+On some platforms you may run into system limitations on the length of a command line when
+creating a command line with lots of options or with long arguments.
+
+The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
+are files that themselves contain arguments to be passed to the command. When the
+underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
+argument beginning with the character `@`, it expands the contents of that file into the
+argument list.
+
+The arguments within a file can be separated by spaces or newlines. If an argument
+contains embedded whitespace, the whole argument should be wrapped in double or single
+quotes -- for example, `"-f=My Files/Stuff.java"`.
+
+If the argument file does not exist or cannot be read, the argument will be treated
+literally and will not be removed. This will likely result in an "unmatched argument"
+error message. You can troubleshoot such errors by executing the command with the
+`picocli.trace` system property set to `DEBUG`.
+
+Multiple _@-files_ may be specified on the command line. The specified path may be
+relative to the current directory or absolute.
+
+You can pass a real parameter with an initial `@` character by escaping it with an
+additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
+subject to expansion.
+
+[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
+==== Redirecting Standard Output/Error to Files
+
+You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
+files using the `--redirect-stdout` and `--redirect-stderr` options:
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
+  --redirect-stdout=stdout.txt \
+  --redirect-stderr=stderr.txt
+----
+
+[NOTE]
+====
+If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
+output streams will be redirected to that file.
+
+The default charset is used for writing to the files.
+====
+
+[[running-tests-console-launcher-color-customization]]
+==== Color Customization
+
+The colors used in the output of the `{ConsoleLauncher}` can be customized.
+The option `--single-color` will apply a built-in monochrome style, while
+`--color-palette` will accept a properties file to override the
+https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
+The properties file below demonstrates the default style:
+
+[source,properties,indent=0]
+----
+SUCCESSFUL = 32
+ABORTED = 33
+FAILED = 31
+SKIPPED = 35
+CONTAINER = 35
+TEST = 34
+DYNAMIC = 35
+REPORTED = 37
+----
+
+[[running-tests-source-launcher]]
+=== Source Launcher
+
+Starting with Java 25 it is possible to write minimal source code test programs
+using the `org.junit.start` module. For example, like in a `HelloTests.java`
+file reading:
+
+```java
+import module org.junit.start;
+
+void main() {
+  JUnit.run();
+}
+
+@Test
+void stringLength() {
+  Assertions.assertEquals(11, "Hello JUnit".length());
+}
+```
+With all required modular JAR files available in a local `lib/` directory, the
+following Java 25+ command will discover and execute tests using the JUnit Platform.
+It will also print the result tree to the console.
+
+```shell
+java --module-path lib --add-modules org.junit.start HelloTests.java
+╷
+└─ JUnit Jupiter ✔
+   └─ HelloTests ✔
+      └─ stringLength() ✔
+```
+
+Find JUnit's class API documentation here: {JUnit}
+
+[[running-tests-discovery-selectors]]
+=== Discovery Selectors
+
+The JUnit Platform provides a rich set of discovery selectors that can be used to specify
+which tests should be discovered or executed.
+
+Discovery selectors can be created programmatically using the factory methods in the
+`{DiscoverySelectors}` class, specified declaratively via annotations when using the
+<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
+generically as strings via their identifiers.
+
+The following discovery selectors are provided out of the box:
+
+|===
+| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
+
+| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
+| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
+| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
+| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
+| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
+| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
+| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
+| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
+| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
+| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
+| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
+| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
+| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
+|===
+
+
+[[running-tests-config-params]]
+=== Configuration Parameters
+
+In addition to instructing the platform which test classes and test engines to include,
+which packages to scan, etc., it is sometimes necessary to provide additional custom
+configuration parameters that are specific to a particular test engine, listener, or
+registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
+parameters_ for the following use cases.
+
+- <<writing-tests-test-instance-lifecycle-changing-default>>
+- <<extensions-registration-automatic-enabling>>
+- <<extensions-conditions-deactivation>>
+- <<writing-tests-display-name-generator-default>>
+
+_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
+engines running on the JUnit Platform via one of the following mechanisms.
+
+1. The `configurationParameter()` and `configurationParameters()` methods in
+   `LauncherDiscoveryRequestBuilder` which
+   is used to build a request supplied to the <<launcher-api, Launcher API>>.
+    +
+   When running tests via one of the tools provided by the JUnit Platform you can specify
+   configuration parameters as follows:
+   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
+     option.
+   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
+     `systemProperties` DSL.
+   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
+     `configurationParameters` property.
+2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
+    +
+   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
+   specify custom configuration files using the `--config-resource` command-line option.
+3. JVM system properties.
+4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
+   in the root of the class path that follows the syntax rules for Java `Properties`
+   files.
+
+NOTE: Configuration parameters are looked up in the exact order defined above.
+Consequently, configuration parameters supplied directly to the `Launcher` take
+precedence over those supplied via custom configuration files, system properties, and the
+default configuration file. Similarly, configuration parameters supplied via system
+properties take precedence over those supplied via the default configuration file.
+
+[[running-tests-config-params-deactivation-pattern]]
+==== Pattern Matching Syntax
+
+This section describes the pattern matching syntax that is applied to the _configuration
+parameters_ used for the following features.
+
+- <<extensions-conditions-deactivation>>
+- <<launcher-api-listeners-custom-deactivation>>
+- <<stacktrace-pruning>>
+- <<extensions-registration-automatic-filtering>>
+
+If the value for the given _configuration parameter_ consists solely of an asterisk
+(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
+will be treated as a comma-separated list of patterns where each pattern will be matched
+against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
+a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
+(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
+pattern will be matched one-to-one against a FQCN.
+
+Examples:
+
+- `+++*+++`: matches all candidate classes.
+- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
+  any of its subpackages.
+- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
+  `MyCustomImpl`.
+- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
+- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
+  `System` or `Unit`.
+- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
+  `org.example.MyCustomImpl`.
+- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
+  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
+
+[[running-tests-tags]]
+=== Tags
+
+Tags are a JUnit Platform concept for marking and filtering tests. The programming model
+for adding tags to containers and tests is defined by the testing framework. For example,
+in JUnit Jupiter based tests, the `@Tag` annotation (see
+<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
+Vintage engine maps `@Category` annotations to tags (see
+<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
+own annotation or other means for users to specify tags.
+
+[[running-tests-tag-syntax-rules]]
+==== Syntax Rules for Tags
+
+Regardless how a tag is specified, the JUnit Platform enforces the following rules:
+
+* A tag must not be `null` or _blank_.
+* A _stripped_ tag must not contain whitespace.
+* A _stripped_ tag must not contain ISO control characters.
+* A _stripped_ tag must not contain any of the following _reserved characters_.
+- `,`: _comma_
+- `(`: _left parenthesis_
+- `)`: _right parenthesis_
+- `&`: _ampersand_
+- `|`: _vertical bar_
+- `!`: _exclamation point_
+
+NOTE: In the above context, "stripped" means that leading and trailing whitespace
+characters have been removed using `java.lang.String.strip()`.
+
+[[running-tests-tag-expressions]]
+==== Tag Expressions
+
+Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
+`(` and `)` can be used to adjust for operator precedence.
+
+Two special expressions are supported, `any()` and `none()`, which select all tests _with_
+any tags at all, and all tests _without_ any tags, respectively.
+These special expressions may be combined with other expressions just like normal tags.
+
+.Operators (in descending order of precedence)
+|===
+| Operator | Meaning | Associativity
+
+| `!`      | not     | right
+| `&`      | and     | left
+| `\|`     | or      | left
+|===
+
+If you are tagging your tests across multiple dimensions, tag expressions help you to
+select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
+_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
+expressions can be useful.
+
+[%header,cols="40,60"]
+|===
+| Tag Expression
+| Selection
+
+| `+++product+++`
+| all tests for *product*
+
+| `+++catalog \| shipping+++`
+| all tests for *catalog* plus all tests for *shipping*
+
+| `+++catalog &amp; shipping+++`
+| all tests for the intersection between *catalog* and *shipping*
+
+| `+++product &amp; !end-to-end+++`
+| all tests for *product*, but not the _end-to-end_ tests
+
+| `+++(micro \| integration) &amp; (product \| shipping)+++`
+| all _micro_ or _integration_ tests for *product* or *shipping*
+|===
+
+[[running-tests-capturing-output]]
+=== Capturing Standard Output/Error
+
+The JUnit Platform provides opt-in support for capturing output printed to `System.out`
+and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
+`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
+parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
+to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
+
+If enabled, the JUnit Platform captures the corresponding output and publishes it as a
+report entry using the `stdout` or `stderr` keys to all registered
+`{TestExecutionListener}` instances immediately before reporting the test or container as
+finished.
+
+Please note that the captured output will only contain output emitted by the thread that
+was used to execute a container or test. Any output by other threads will be omitted
+because particularly when
+<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
+to attribute it to a specific test or container.
+
+[[running-tests-listeners]]
+=== Using Listeners and Interceptors
+
+The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
+and custom user code to react to events fired at various points during the discovery and
+execution of a `TestPlan`.
+
+* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
+  closed.
+* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
+  `LauncherSession`.
+* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
+* `{TestExecutionListener}`: receives events that occur during test execution.
+
+The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
+registered automatically for you in order to support some feature of the build tool or IDE.
+
+The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
+order to produce some form of report or to display a graphical representation of the test
+plan in an IDE. Such listeners may be implemented and automatically registered by a build
+tool or IDE, or they may be included in a third-party library – potentially registered
+for you automatically. You can also implement and register your own listeners.
+
+For details on registering and configuring listeners, see the following sections of this
+guide.
+
+* <<launcher-api-launcher-session-listeners-custom>>
+* <<launcher-api-launcher-interceptors-custom>>
+* <<launcher-api-launcher-discovery-listeners-custom>>
+* <<launcher-api-listeners-custom>>
+* <<launcher-api-listeners-config>>
+* <<launcher-api-listeners-custom-deactivation>>
+
+The JUnit Platform provides the following listeners which you may wish to use with your
+test suite.
+
+<<junit-platform-reporting>> ::
+  `{LegacyXmlReportGeneratingListener}` can be used via the
+  <<running-tests-console-launcher>> or registered manually to generate XML reports
+  compatible with the de facto standard for JUnit 4 based test reports.
++
+`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
+specified by {OpenTestReporting}. It is auto-registered and can be enabled and
+configured via <<running-tests-config-params>>.
++
+See <<junit-platform-reporting>> for details.
+
+<<running-tests-listeners-flight-recorder>> ::
+  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
+  Java Flight Recorder events during test discovery and execution.
+
+`{LoggingListener}` ::
+  `TestExecutionListener` for logging informational messages for all events via a
+  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
+
+`{SummaryGeneratingListener}` ::
+  `TestExecutionListener` that generates a summary of the test execution which can be
+  printed via a `PrintWriter`.
+
+`{UniqueIdTrackingListener}` ::
+  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
+  or executed during the execution of the `TestPlan` and generates a file containing the
+  unique IDs once execution of the `TestPlan` has finished.
+
+[[running-tests-listeners-flight-recorder]]
+==== Flight Recorder Support
+
+The JUnit Platform provides opt-in support for generating Flight Recorder events.
+https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
+follows.
+
+> Flight Recorder records events originating from applications, the JVM, and the OS.
+Events are stored in a single file that can be attached to bug reports and examined by
+support engineers, allowing after-the-fact analysis of issues in the period leading up
+to a problem.
+
+In order to record Flight Recorder events generated while running tests, you need to
+start flight recording when launching a test suite via the following java command line
+option.
+
+   -XX:StartFlightRecording:filename=...
+
+Please consult the manual of your build tool for the appropriate commands.
+
+To analyze the recorded events, use the
+https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
+command line tool shipped with recent JDKs or open the recording file with
+https://jdk.java.net/jmc/[JDK Mission Control].
+
+[[stacktrace-pruning]]
+=== Stack Trace Pruning
+
+The JUnit Platform provides built-in support for pruning stack traces produced by failing
+tests. This feature is enabled by default but can be disabled by setting the
+`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
+
+When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
+packages are removed from the stack trace, unless the calls occur after the test itself
+or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
+never be excluded.
+
+In addition, all elements prior to and including the first call from the JUnit Platform
+`Launcher` will be removed.
+
+[[running-tests-discovery-issues]]
+=== Discovery Issues
+
+Test engines may encounter issues during test discovery. For example, the declaration of a
+test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
+Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
+report them with different severity levels:
+
+INFO::
+Indicates that the engine encountered something that could be potentially problematic, but
+could also happen due to a valid setup or configuration.
+
+WARNING::
+Indicates that the engine encountered something that is problematic and might lead to
+unexpected behavior or will be removed or changed in a future release.
+
+ERROR::
+Indicates that the engine encountered something that is definitely problematic and will
+lead to unexpected behavior.
+
+If an engine reports an issue with a severity equal to or higher than a configurable
+_critical_ severity, its tests will not be executed. Instead, the engine will be reported
+as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
+Non-critical issues will be logged but will not prevent the engine from executing its
+tests. The `junit.platform.discovery.issue.severity.critical`
+<<running-tests-config-params, configuration parameter>> can be used to set the critical
+severity level. Currently, the default value is `ERROR` but it may be changed in a future
+release.
+
+TIP: To surface all discovery issues in your project, it is recommended to set the
+`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
+
+In addition, registered `{LauncherDiscoveryListener}` implementations can receive
+discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
+report issues to the user in a more user-friendly way. For example, IDEs may choose to
+display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/source-launcher.adoc b/documentation/modules/ROOT/pages/running-tests/source-launcher.adoc
new file mode 100644
index 000000000000..3099a146c2b4
--- /dev/null
+++ b/documentation/modules/ROOT/pages/running-tests/source-launcher.adoc
@@ -0,0 +1,1216 @@
+[[running-tests]]
+== Running Tests
+
+[[running-tests-ide]]
+=== IDE Support
+
+[[running-tests-ide-intellij-idea]]
+==== IntelliJ IDEA
+
+IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
+information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
+however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
+IDEA download the following JARs automatically based on the API version used in the
+project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
+
+In order to use a different JUnit version (e.g., {version}), you may need to
+include the corresponding versions of the `junit-platform-launcher`,
+`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
+
+.Additional Gradle Dependencies
+[source,groovy]
+[subs=attributes+]
+----
+testImplementation(platform("org.junit:junit-bom:{version}"))
+testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
+testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
+----
+
+.Additional Maven Dependencies
+[source,xml]
+[subs=attributes+]
+----
+<!-- ... -->
+<dependencies>
+	<dependency>
+		<groupId>org.junit.platform</groupId>
+		<artifactId>junit-platform-launcher</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.jupiter</groupId>
+		<artifactId>junit-jupiter-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.vintage</groupId>
+		<artifactId>junit-vintage-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+</dependencies>
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+[[running-tests-ide-eclipse]]
+==== Eclipse
+
+Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
+release.
+
+For more information on using JUnit Platform in Eclipse consult the official _Eclipse
+support for JUnit 5_ section of the
+https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
+(4.7.1a) - New and Noteworthy] documentation.
+
+[[running-tests-ide-netbeans]]
+==== NetBeans
+
+NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
+https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
+
+For more information consult the JUnit 5 section of the
+https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
+release notes].
+
+[[running-tests-ide-vscode]]
+==== Visual Studio Code
+
+https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
+Platform via the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
+Runner] extension which is installed by default as part of the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
+Extension Pack].
+
+For more information consult the _Testing_ section of the
+https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
+documentation.
+
+[[running-tests-ide-other]]
+==== Other IDEs
+
+If you are using an editor or IDE other than one of those listed in the previous sections,
+and it doesn't support running tests on the JUnit Platform, you can use the
+<<running-tests-console-launcher>> to run them from the command line.
+
+[[running-tests-build]]
+=== Build Support
+
+[[running-tests-build-gradle]]
+==== Gradle
+
+Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
+https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
+for executing tests on the JUnit Platform. To enable it, you need to specify
+`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform()
+}
+----
+
+Filtering by <<running-tests-tags, tags>>,
+<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform {
+		includeTags("fast", "smoke & feature-a")
+		// excludeTags("slow", "ci")
+		includeEngines("junit-jupiter")
+		// excludeEngines("junit-vintage")
+	}
+}
+----
+
+Please refer to the
+https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
+for a comprehensive list of options.
+
+[[running-tests-build-gradle-bom]]
+===== Aligning dependency versions
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Explicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation(platform("org.junit:junit-bom:{version}"))
+	testImplementation("org.junit.jupiter:junit-jupiter")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+Since all JUnit artifacts declare a
+https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
+you usually don't need to declare an explicit dependency on it yourself. Instead, it's
+sufficient to declare _one_ regular dependency that includes a version number. Gradle will
+then pull in the BOM automatically so you can omit the version for all other JUnit
+artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Implicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
+}
+----
+<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
+<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
+
+[WARNING]
+.Declaring a dependency on junit-platform-launcher
+====
+Even though pre-8.0 versions of Gradle don't require declaring an explicit
+dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
+of JUnit artifacts on the test runtime classpath are aligned.
+
+Moreover, doing so is recommended and in some cases even required when importing the
+project into an IDE like <<running-tests-ide-eclipse>> or
+<<running-tests-ide-intellij-idea>>.
+====
+
+[[running-tests-build-gradle-engines-configure]]
+===== Configuring Test Engines
+
+In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
+
+To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
+on the dependency-aggregating JUnit Jupiter artifact similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Alternatively, you can use Gradle's
+https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
+support.
+
+[source,kotlin,indent=0]
+[subs=attributes+]
+.Kotlin DSL
+----
+testing {
+	suites {
+		named<JvmTestSuite>("test") {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Groovy DSL
+----
+testing {
+	suites {
+		test {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
+dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
+implementation similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("junit:junit:{junit4-version}")
+	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+[[running-tests-build-gradle-config-params]]
+===== Configuration Parameters
+
+The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
+Platform <<running-tests-config-params, configuration parameters>> to influence test
+discovery and execution. However, you can provide configuration parameters within the
+build script via system properties (as shown below) or via the
+`junit-platform.properties` file.
+
+[source,groovy,indent=0]
+----
+test {
+	// ...
+	systemProperty("junit.jupiter.conditions.deactivate", "*")
+	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
+	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
+	// ...
+}
+----
+
+[[running-tests-build-gradle-logging]]
+===== Configuring Logging (optional)
+
+JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
+emit warnings and debug information. Please refer to the official documentation of
+`{LogManager}` for configuration options.
+
+Alternatively, it's possible to redirect log messages to other logging frameworks such as
+{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
+`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
+qualified class name_ of the `{LogManager}` implementation to use. The example below
+demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
+details).
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
+	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
+	systemProperty("log4j2.disableJmx", "true")
+}
+----
+
+Other logging frameworks provide different means to redirect messages logged using
+`java.util.logging`. For example, for {Logback} you can use the
+https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
+dependency to the test runtime classpath.
+
+[[running-tests-build-maven]]
+==== Maven
+
+Maven Surefire and Maven Failsafe provide
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
+for executing tests on the JUnit Platform. The `pom.xml` file in the
+`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
+and can serve as a starting point for configuring your Maven build.
+
+[WARNING]
+.Minimum required version of Maven Surefire/Failsafe
+====
+As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
+====
+
+[[running-tests-build-maven-bom]]
+===== Aligning dependency versions
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+[[running-tests-build-maven-engines-configure]]
+===== Configuring Test Engines
+
+In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
+`TestEngine` implementation must be added to the test classpath.
+
+To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
+on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
+following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>org.junit.jupiter</groupId>
+			<artifactId>junit-jupiter</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
+long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
+`TestEngine` implementation similar to the following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>junit</groupId>
+			<artifactId>junit</artifactId>
+			<version>{junit4-version}</version>
+			<scope>test</scope>
+		</dependency>
+		<dependency>
+			<groupId>org.junit.vintage</groupId>
+			<artifactId>junit-vintage-engine</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-filter-test-class-names]]
+===== Filtering by Test Class Names
+
+The Maven Surefire Plugin will scan for test classes whose fully qualified names match
+the following patterns.
+
+- `+++**/Test*.java+++`
+- `+++**/*Test.java+++`
+- `+++**/*Tests.java+++`
+- `+++**/*TestCase.java+++`
+
+Moreover, it will exclude all nested classes (including static member classes) by default.
+
+Note, however, that you can override this default behavior by configuring explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
+from excluding static member classes, you can override its exclude rules as follows.
+
+[source,xml,indent=0]
+[subs=attributes+]
+.Overriding exclude rules of Maven Surefire
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<excludes>
+						<exclude/>
+					</excludes>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Please see the
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
+documentation for Maven Surefire for details.
+
+[[running-tests-build-maven-filter-tags]]
+===== Filtering by Tags
+
+You can filter tests by <<running-tests-tags, tags>> or
+<<running-tests-tag-expressions, tag expressions>> using the following configuration
+properties.
+
+- to include _tags_ or _tag expressions_, use `groups`.
+- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<groups>acceptance | !feature-a</groups>
+					<excludedGroups>integration, regression</excludedGroups>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-config-params]]
+===== Configuration Parameters
+
+You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
+influence test discovery and execution by declaring the `configurationParameters`
+property and providing key-value pairs using the Java `Properties` file syntax (as shown
+below) or via the `junit-platform.properties` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<properties>
+						<configurationParameters>
+							junit.jupiter.conditions.deactivate = *
+							junit.jupiter.extensions.autodetection.enabled = true
+							junit.jupiter.testinstance.lifecycle.default = per_class
+						</configurationParameters>
+					</properties>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-ant]]
+==== Ant
+
+Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
+provides native support for launching tests on the JUnit Platform. The `junitlauncher`
+task is solely responsible for launching the JUnit Platform and passing it the selected
+collection of tests. The JUnit Platform then delegates to registered test engines to
+discover and execute the tests.
+
+The `junitlauncher` task attempts to align as closely as possible with native Ant
+constructs such as
+link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
+for allowing users to select the tests that they want executed by test engines. This gives
+the task a consistent and natural feel when compared to many other core Ant tasks.
+
+Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
+
+The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
+the task and can serve as a starting point.
+
+===== Basic Usage
+
+The following example demonstrates how to configure the `junitlauncher` task to select a
+single test class (i.e., `com.example.project.CalculatorTests`).
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+
+	<!-- ... -->
+
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<test name="com.example.project.CalculatorTests" />
+	</junitlauncher>
+----
+
+The `test` element allows you to specify a single test class that you want to be selected
+and executed. The `classpath` element allows you to specify the classpath to be used to
+launch the JUnit Platform. This classpath will also be used to locate test classes that
+are part of the execution.
+
+The following example demonstrates how to configure the `junitlauncher` task to select
+test classes from multiple locations.
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+	<!-- ... -->
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<testclasses outputdir="${output.dir}">
+			<fileset dir="${build.classes.dir}">
+				<include name="org/example/**/demo/**/" />
+			</fileset>
+			<fileset dir="${some.other.dir}">
+				<include name="org/myapp/**/" />
+			</fileset>
+		</testclasses>
+	</junitlauncher>
+----
+
+In the above example, the `testclasses` element allows you to select multiple test
+classes that reside in different locations.
+
+For further details on usage and configuration options please refer to the official Ant
+documentation for the
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
+
+[[running-tests-build-spring-boot]]
+==== Spring Boot
+
+link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
+managing the version of JUnit used in your project. In addition, the
+`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
+Jupiter, AssertJ, Mockito, etc.
+
+If your build relies on dependency management support from Spring Boot, you should not
+import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
+result in duplicate (and potentially conflicting) management of JUnit dependencies.
+
+If you need to override the version of a dependency used in your Spring Boot application,
+you have to override the exact name of the
+link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
+defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
+Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
+changing a dependency version is documented for both
+link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
+and
+link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
+
+With Gradle you can override the JUnit Jupiter version by including the following in your
+`build.gradle` file.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+	ext['junit-jupiter.version'] = '{version}'
+----
+
+With Maven you can override the JUnit Jupiter version by including the following in your
+`pom.xml` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<properties>
+		<junit-jupiter.version>{version}</junit-jupiter.version>
+	</properties>
+----
+
+[[running-tests-console-launcher]]
+=== Console Launcher
+
+The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
+Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
+Jupiter tests and print test execution results to the console.
+
+An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
+contains the contents of all of its dependencies is published in the {Maven_Central}
+repository under the
+https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
+directory. It contains the contents of the following artifacts:
+
+include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
+
+[NOTE]
+====
+Since the `junit-platform-console-standalone` JAR contains the contents of all of its
+dependencies, its Maven POM does not declare any dependencies.
+
+Furthermore, it is not very likely that you would need to include a dependency on the
+`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
+script. On the contrary, the executable `junit-platform-console-standalone` JAR is
+typically invoked directly from the command line or a shell script without a build script.
+
+If you need to declare dependencies in your build script on some of the artifacts
+contained in the `junit-platform-console-standalone` artifact, you should declare
+dependencies only on the JUnit artifacts that are used in your project. To simplify
+dependency management of JUnit artifacts in your build, you may wish to use the
+`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
+details.
+====
+
+You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
+standalone `ConsoleLauncher` as shown below.
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
+
+├─ JUnit Vintage
+│  └─ example.JUnit4Tests
+│     └─ standardJUnit4Test ✔
+└─ JUnit Jupiter
+   ├─ StandardTests
+   │  ├─ succeedingTest() ✔
+   │  └─ skippedTest() ↷ for demonstration purposes
+   └─ A special test case
+      ├─ Custom test name containing spaces ✔
+      ├─ ╯°□°)╯ ✔
+      └─ 😱 ✔
+
+Test run finished after 64 ms
+[         5 containers found      ]
+[         0 containers skipped    ]
+[         5 containers started    ]
+[         0 containers aborted    ]
+[         5 containers successful ]
+[         0 containers failed     ]
+[         6 tests found           ]
+[         1 tests skipped         ]
+[         5 tests started         ]
+[         0 tests aborted         ]
+[         5 tests successful      ]
+[         0 tests failed          ]
+----
+
+You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
+all jars in a directory):
+
+[source,console,subs=attributes+]
+----
+$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
+----
+
+[[running-tests-console-launcher-options]]
+==== Subcommands and Options
+
+The `{ConsoleLauncher}` provides the following subcommands:
+
+----
+include::{consoleLauncherOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-discovering-tests]]
+===== Discovering tests
+
+----
+include::{consoleLauncherDiscoverOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-executing-tests]]
+===== Executing tests
+
+.Exit Code
+NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
+All non-zero codes indicate an error of some sort. For example, status code `1`
+is returned if any containers or tests failed. If no tests are discovered and the
+`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
+with a status code of `2`. Unexpected or invalid user input yields a status code
+of `3`. An exit code of `-1` indicates an unspecified error condition.
+
+----
+include::{consoleLauncherExecuteOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-listing-test-engines]]
+===== Listing test engines
+
+----
+include::{consoleLauncherEnginesOptionsFile}[]
+----
+
+[[running-tests-console-launcher-argument-files]]
+==== Argument Files (@-files)
+
+On some platforms you may run into system limitations on the length of a command line when
+creating a command line with lots of options or with long arguments.
+
+The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
+are files that themselves contain arguments to be passed to the command. When the
+underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
+argument beginning with the character `@`, it expands the contents of that file into the
+argument list.
+
+The arguments within a file can be separated by spaces or newlines. If an argument
+contains embedded whitespace, the whole argument should be wrapped in double or single
+quotes -- for example, `"-f=My Files/Stuff.java"`.
+
+If the argument file does not exist or cannot be read, the argument will be treated
+literally and will not be removed. This will likely result in an "unmatched argument"
+error message. You can troubleshoot such errors by executing the command with the
+`picocli.trace` system property set to `DEBUG`.
+
+Multiple _@-files_ may be specified on the command line. The specified path may be
+relative to the current directory or absolute.
+
+You can pass a real parameter with an initial `@` character by escaping it with an
+additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
+subject to expansion.
+
+[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
+==== Redirecting Standard Output/Error to Files
+
+You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
+files using the `--redirect-stdout` and `--redirect-stderr` options:
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
+  --redirect-stdout=stdout.txt \
+  --redirect-stderr=stderr.txt
+----
+
+[NOTE]
+====
+If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
+output streams will be redirected to that file.
+
+The default charset is used for writing to the files.
+====
+
+[[running-tests-console-launcher-color-customization]]
+==== Color Customization
+
+The colors used in the output of the `{ConsoleLauncher}` can be customized.
+The option `--single-color` will apply a built-in monochrome style, while
+`--color-palette` will accept a properties file to override the
+https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
+The properties file below demonstrates the default style:
+
+[source,properties,indent=0]
+----
+SUCCESSFUL = 32
+ABORTED = 33
+FAILED = 31
+SKIPPED = 35
+CONTAINER = 35
+TEST = 34
+DYNAMIC = 35
+REPORTED = 37
+----
+
+[[running-tests-source-launcher]]
+=== Source Launcher
+
+Starting with Java 25 it is possible to write minimal source code test programs
+using the `org.junit.start` module. For example, like in a `HelloTests.java`
+file reading:
+
+```java
+import module org.junit.start;
+
+void main() {
+  JUnit.run();
+}
+
+@Test
+void stringLength() {
+  Assertions.assertEquals(11, "Hello JUnit".length());
+}
+```
+With all required modular JAR files available in a local `lib/` directory, the
+following Java 25+ command will discover and execute tests using the JUnit Platform.
+It will also print the result tree to the console.
+
+```shell
+java --module-path lib --add-modules org.junit.start HelloTests.java
+╷
+└─ JUnit Jupiter ✔
+   └─ HelloTests ✔
+      └─ stringLength() ✔
+```
+
+Find JUnit's class API documentation here: {JUnit}
+
+[[running-tests-discovery-selectors]]
+=== Discovery Selectors
+
+The JUnit Platform provides a rich set of discovery selectors that can be used to specify
+which tests should be discovered or executed.
+
+Discovery selectors can be created programmatically using the factory methods in the
+`{DiscoverySelectors}` class, specified declaratively via annotations when using the
+<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
+generically as strings via their identifiers.
+
+The following discovery selectors are provided out of the box:
+
+|===
+| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
+
+| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
+| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
+| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
+| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
+| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
+| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
+| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
+| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
+| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
+| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
+| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
+| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
+| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
+|===
+
+
+[[running-tests-config-params]]
+=== Configuration Parameters
+
+In addition to instructing the platform which test classes and test engines to include,
+which packages to scan, etc., it is sometimes necessary to provide additional custom
+configuration parameters that are specific to a particular test engine, listener, or
+registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
+parameters_ for the following use cases.
+
+- <<writing-tests-test-instance-lifecycle-changing-default>>
+- <<extensions-registration-automatic-enabling>>
+- <<extensions-conditions-deactivation>>
+- <<writing-tests-display-name-generator-default>>
+
+_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
+engines running on the JUnit Platform via one of the following mechanisms.
+
+1. The `configurationParameter()` and `configurationParameters()` methods in
+   `LauncherDiscoveryRequestBuilder` which
+   is used to build a request supplied to the <<launcher-api, Launcher API>>.
+    +
+   When running tests via one of the tools provided by the JUnit Platform you can specify
+   configuration parameters as follows:
+   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
+     option.
+   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
+     `systemProperties` DSL.
+   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
+     `configurationParameters` property.
+2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
+    +
+   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
+   specify custom configuration files using the `--config-resource` command-line option.
+3. JVM system properties.
+4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
+   in the root of the class path that follows the syntax rules for Java `Properties`
+   files.
+
+NOTE: Configuration parameters are looked up in the exact order defined above.
+Consequently, configuration parameters supplied directly to the `Launcher` take
+precedence over those supplied via custom configuration files, system properties, and the
+default configuration file. Similarly, configuration parameters supplied via system
+properties take precedence over those supplied via the default configuration file.
+
+[[running-tests-config-params-deactivation-pattern]]
+==== Pattern Matching Syntax
+
+This section describes the pattern matching syntax that is applied to the _configuration
+parameters_ used for the following features.
+
+- <<extensions-conditions-deactivation>>
+- <<launcher-api-listeners-custom-deactivation>>
+- <<stacktrace-pruning>>
+- <<extensions-registration-automatic-filtering>>
+
+If the value for the given _configuration parameter_ consists solely of an asterisk
+(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
+will be treated as a comma-separated list of patterns where each pattern will be matched
+against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
+a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
+(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
+pattern will be matched one-to-one against a FQCN.
+
+Examples:
+
+- `+++*+++`: matches all candidate classes.
+- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
+  any of its subpackages.
+- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
+  `MyCustomImpl`.
+- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
+- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
+  `System` or `Unit`.
+- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
+  `org.example.MyCustomImpl`.
+- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
+  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
+
+[[running-tests-tags]]
+=== Tags
+
+Tags are a JUnit Platform concept for marking and filtering tests. The programming model
+for adding tags to containers and tests is defined by the testing framework. For example,
+in JUnit Jupiter based tests, the `@Tag` annotation (see
+<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
+Vintage engine maps `@Category` annotations to tags (see
+<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
+own annotation or other means for users to specify tags.
+
+[[running-tests-tag-syntax-rules]]
+==== Syntax Rules for Tags
+
+Regardless how a tag is specified, the JUnit Platform enforces the following rules:
+
+* A tag must not be `null` or _blank_.
+* A _stripped_ tag must not contain whitespace.
+* A _stripped_ tag must not contain ISO control characters.
+* A _stripped_ tag must not contain any of the following _reserved characters_.
+- `,`: _comma_
+- `(`: _left parenthesis_
+- `)`: _right parenthesis_
+- `&`: _ampersand_
+- `|`: _vertical bar_
+- `!`: _exclamation point_
+
+NOTE: In the above context, "stripped" means that leading and trailing whitespace
+characters have been removed using `java.lang.String.strip()`.
+
+[[running-tests-tag-expressions]]
+==== Tag Expressions
+
+Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
+`(` and `)` can be used to adjust for operator precedence.
+
+Two special expressions are supported, `any()` and `none()`, which select all tests _with_
+any tags at all, and all tests _without_ any tags, respectively.
+These special expressions may be combined with other expressions just like normal tags.
+
+.Operators (in descending order of precedence)
+|===
+| Operator | Meaning | Associativity
+
+| `!`      | not     | right
+| `&`      | and     | left
+| `\|`     | or      | left
+|===
+
+If you are tagging your tests across multiple dimensions, tag expressions help you to
+select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
+_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
+expressions can be useful.
+
+[%header,cols="40,60"]
+|===
+| Tag Expression
+| Selection
+
+| `+++product+++`
+| all tests for *product*
+
+| `+++catalog \| shipping+++`
+| all tests for *catalog* plus all tests for *shipping*
+
+| `+++catalog &amp; shipping+++`
+| all tests for the intersection between *catalog* and *shipping*
+
+| `+++product &amp; !end-to-end+++`
+| all tests for *product*, but not the _end-to-end_ tests
+
+| `+++(micro \| integration) &amp; (product \| shipping)+++`
+| all _micro_ or _integration_ tests for *product* or *shipping*
+|===
+
+[[running-tests-capturing-output]]
+=== Capturing Standard Output/Error
+
+The JUnit Platform provides opt-in support for capturing output printed to `System.out`
+and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
+`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
+parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
+to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
+
+If enabled, the JUnit Platform captures the corresponding output and publishes it as a
+report entry using the `stdout` or `stderr` keys to all registered
+`{TestExecutionListener}` instances immediately before reporting the test or container as
+finished.
+
+Please note that the captured output will only contain output emitted by the thread that
+was used to execute a container or test. Any output by other threads will be omitted
+because particularly when
+<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
+to attribute it to a specific test or container.
+
+[[running-tests-listeners]]
+=== Using Listeners and Interceptors
+
+The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
+and custom user code to react to events fired at various points during the discovery and
+execution of a `TestPlan`.
+
+* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
+  closed.
+* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
+  `LauncherSession`.
+* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
+* `{TestExecutionListener}`: receives events that occur during test execution.
+
+The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
+registered automatically for you in order to support some feature of the build tool or IDE.
+
+The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
+order to produce some form of report or to display a graphical representation of the test
+plan in an IDE. Such listeners may be implemented and automatically registered by a build
+tool or IDE, or they may be included in a third-party library – potentially registered
+for you automatically. You can also implement and register your own listeners.
+
+For details on registering and configuring listeners, see the following sections of this
+guide.
+
+* <<launcher-api-launcher-session-listeners-custom>>
+* <<launcher-api-launcher-interceptors-custom>>
+* <<launcher-api-launcher-discovery-listeners-custom>>
+* <<launcher-api-listeners-custom>>
+* <<launcher-api-listeners-config>>
+* <<launcher-api-listeners-custom-deactivation>>
+
+The JUnit Platform provides the following listeners which you may wish to use with your
+test suite.
+
+<<junit-platform-reporting>> ::
+  `{LegacyXmlReportGeneratingListener}` can be used via the
+  <<running-tests-console-launcher>> or registered manually to generate XML reports
+  compatible with the de facto standard for JUnit 4 based test reports.
++
+`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
+specified by {OpenTestReporting}. It is auto-registered and can be enabled and
+configured via <<running-tests-config-params>>.
++
+See <<junit-platform-reporting>> for details.
+
+<<running-tests-listeners-flight-recorder>> ::
+  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
+  Java Flight Recorder events during test discovery and execution.
+
+`{LoggingListener}` ::
+  `TestExecutionListener` for logging informational messages for all events via a
+  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
+
+`{SummaryGeneratingListener}` ::
+  `TestExecutionListener` that generates a summary of the test execution which can be
+  printed via a `PrintWriter`.
+
+`{UniqueIdTrackingListener}` ::
+  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
+  or executed during the execution of the `TestPlan` and generates a file containing the
+  unique IDs once execution of the `TestPlan` has finished.
+
+[[running-tests-listeners-flight-recorder]]
+==== Flight Recorder Support
+
+The JUnit Platform provides opt-in support for generating Flight Recorder events.
+https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
+follows.
+
+> Flight Recorder records events originating from applications, the JVM, and the OS.
+Events are stored in a single file that can be attached to bug reports and examined by
+support engineers, allowing after-the-fact analysis of issues in the period leading up
+to a problem.
+
+In order to record Flight Recorder events generated while running tests, you need to
+start flight recording when launching a test suite via the following java command line
+option.
+
+   -XX:StartFlightRecording:filename=...
+
+Please consult the manual of your build tool for the appropriate commands.
+
+To analyze the recorded events, use the
+https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
+command line tool shipped with recent JDKs or open the recording file with
+https://jdk.java.net/jmc/[JDK Mission Control].
+
+[[stacktrace-pruning]]
+=== Stack Trace Pruning
+
+The JUnit Platform provides built-in support for pruning stack traces produced by failing
+tests. This feature is enabled by default but can be disabled by setting the
+`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
+
+When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
+packages are removed from the stack trace, unless the calls occur after the test itself
+or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
+never be excluded.
+
+In addition, all elements prior to and including the first call from the JUnit Platform
+`Launcher` will be removed.
+
+[[running-tests-discovery-issues]]
+=== Discovery Issues
+
+Test engines may encounter issues during test discovery. For example, the declaration of a
+test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
+Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
+report them with different severity levels:
+
+INFO::
+Indicates that the engine encountered something that could be potentially problematic, but
+could also happen due to a valid setup or configuration.
+
+WARNING::
+Indicates that the engine encountered something that is problematic and might lead to
+unexpected behavior or will be removed or changed in a future release.
+
+ERROR::
+Indicates that the engine encountered something that is definitely problematic and will
+lead to unexpected behavior.
+
+If an engine reports an issue with a severity equal to or higher than a configurable
+_critical_ severity, its tests will not be executed. Instead, the engine will be reported
+as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
+Non-critical issues will be logged but will not prevent the engine from executing its
+tests. The `junit.platform.discovery.issue.severity.critical`
+<<running-tests-config-params, configuration parameter>> can be used to set the critical
+severity level. Currently, the default value is `ERROR` but it may be changed in a future
+release.
+
+TIP: To surface all discovery issues in your project, it is recommended to set the
+`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
+
+In addition, registered `{LauncherDiscoveryListener}` implementations can receive
+discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
+report issues to the user in a more user-friendly way. For example, IDEs may choose to
+display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/stack-trace-pruning.adoc b/documentation/modules/ROOT/pages/running-tests/stack-trace-pruning.adoc
new file mode 100644
index 000000000000..3099a146c2b4
--- /dev/null
+++ b/documentation/modules/ROOT/pages/running-tests/stack-trace-pruning.adoc
@@ -0,0 +1,1216 @@
+[[running-tests]]
+== Running Tests
+
+[[running-tests-ide]]
+=== IDE Support
+
+[[running-tests-ide-intellij-idea]]
+==== IntelliJ IDEA
+
+IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
+information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
+however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
+IDEA download the following JARs automatically based on the API version used in the
+project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
+
+In order to use a different JUnit version (e.g., {version}), you may need to
+include the corresponding versions of the `junit-platform-launcher`,
+`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
+
+.Additional Gradle Dependencies
+[source,groovy]
+[subs=attributes+]
+----
+testImplementation(platform("org.junit:junit-bom:{version}"))
+testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
+testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
+----
+
+.Additional Maven Dependencies
+[source,xml]
+[subs=attributes+]
+----
+<!-- ... -->
+<dependencies>
+	<dependency>
+		<groupId>org.junit.platform</groupId>
+		<artifactId>junit-platform-launcher</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.jupiter</groupId>
+		<artifactId>junit-jupiter-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.vintage</groupId>
+		<artifactId>junit-vintage-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+</dependencies>
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+[[running-tests-ide-eclipse]]
+==== Eclipse
+
+Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
+release.
+
+For more information on using JUnit Platform in Eclipse consult the official _Eclipse
+support for JUnit 5_ section of the
+https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
+(4.7.1a) - New and Noteworthy] documentation.
+
+[[running-tests-ide-netbeans]]
+==== NetBeans
+
+NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
+https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
+
+For more information consult the JUnit 5 section of the
+https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
+release notes].
+
+[[running-tests-ide-vscode]]
+==== Visual Studio Code
+
+https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
+Platform via the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
+Runner] extension which is installed by default as part of the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
+Extension Pack].
+
+For more information consult the _Testing_ section of the
+https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
+documentation.
+
+[[running-tests-ide-other]]
+==== Other IDEs
+
+If you are using an editor or IDE other than one of those listed in the previous sections,
+and it doesn't support running tests on the JUnit Platform, you can use the
+<<running-tests-console-launcher>> to run them from the command line.
+
+[[running-tests-build]]
+=== Build Support
+
+[[running-tests-build-gradle]]
+==== Gradle
+
+Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
+https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
+for executing tests on the JUnit Platform. To enable it, you need to specify
+`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform()
+}
+----
+
+Filtering by <<running-tests-tags, tags>>,
+<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform {
+		includeTags("fast", "smoke & feature-a")
+		// excludeTags("slow", "ci")
+		includeEngines("junit-jupiter")
+		// excludeEngines("junit-vintage")
+	}
+}
+----
+
+Please refer to the
+https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
+for a comprehensive list of options.
+
+[[running-tests-build-gradle-bom]]
+===== Aligning dependency versions
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Explicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation(platform("org.junit:junit-bom:{version}"))
+	testImplementation("org.junit.jupiter:junit-jupiter")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+Since all JUnit artifacts declare a
+https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
+you usually don't need to declare an explicit dependency on it yourself. Instead, it's
+sufficient to declare _one_ regular dependency that includes a version number. Gradle will
+then pull in the BOM automatically so you can omit the version for all other JUnit
+artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Implicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
+}
+----
+<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
+<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
+
+[WARNING]
+.Declaring a dependency on junit-platform-launcher
+====
+Even though pre-8.0 versions of Gradle don't require declaring an explicit
+dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
+of JUnit artifacts on the test runtime classpath are aligned.
+
+Moreover, doing so is recommended and in some cases even required when importing the
+project into an IDE like <<running-tests-ide-eclipse>> or
+<<running-tests-ide-intellij-idea>>.
+====
+
+[[running-tests-build-gradle-engines-configure]]
+===== Configuring Test Engines
+
+In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
+
+To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
+on the dependency-aggregating JUnit Jupiter artifact similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Alternatively, you can use Gradle's
+https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
+support.
+
+[source,kotlin,indent=0]
+[subs=attributes+]
+.Kotlin DSL
+----
+testing {
+	suites {
+		named<JvmTestSuite>("test") {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Groovy DSL
+----
+testing {
+	suites {
+		test {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
+dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
+implementation similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("junit:junit:{junit4-version}")
+	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+[[running-tests-build-gradle-config-params]]
+===== Configuration Parameters
+
+The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
+Platform <<running-tests-config-params, configuration parameters>> to influence test
+discovery and execution. However, you can provide configuration parameters within the
+build script via system properties (as shown below) or via the
+`junit-platform.properties` file.
+
+[source,groovy,indent=0]
+----
+test {
+	// ...
+	systemProperty("junit.jupiter.conditions.deactivate", "*")
+	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
+	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
+	// ...
+}
+----
+
+[[running-tests-build-gradle-logging]]
+===== Configuring Logging (optional)
+
+JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
+emit warnings and debug information. Please refer to the official documentation of
+`{LogManager}` for configuration options.
+
+Alternatively, it's possible to redirect log messages to other logging frameworks such as
+{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
+`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
+qualified class name_ of the `{LogManager}` implementation to use. The example below
+demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
+details).
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
+	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
+	systemProperty("log4j2.disableJmx", "true")
+}
+----
+
+Other logging frameworks provide different means to redirect messages logged using
+`java.util.logging`. For example, for {Logback} you can use the
+https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
+dependency to the test runtime classpath.
+
+[[running-tests-build-maven]]
+==== Maven
+
+Maven Surefire and Maven Failsafe provide
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
+for executing tests on the JUnit Platform. The `pom.xml` file in the
+`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
+and can serve as a starting point for configuring your Maven build.
+
+[WARNING]
+.Minimum required version of Maven Surefire/Failsafe
+====
+As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
+====
+
+[[running-tests-build-maven-bom]]
+===== Aligning dependency versions
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+[[running-tests-build-maven-engines-configure]]
+===== Configuring Test Engines
+
+In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
+`TestEngine` implementation must be added to the test classpath.
+
+To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
+on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
+following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>org.junit.jupiter</groupId>
+			<artifactId>junit-jupiter</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
+long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
+`TestEngine` implementation similar to the following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>junit</groupId>
+			<artifactId>junit</artifactId>
+			<version>{junit4-version}</version>
+			<scope>test</scope>
+		</dependency>
+		<dependency>
+			<groupId>org.junit.vintage</groupId>
+			<artifactId>junit-vintage-engine</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-filter-test-class-names]]
+===== Filtering by Test Class Names
+
+The Maven Surefire Plugin will scan for test classes whose fully qualified names match
+the following patterns.
+
+- `+++**/Test*.java+++`
+- `+++**/*Test.java+++`
+- `+++**/*Tests.java+++`
+- `+++**/*TestCase.java+++`
+
+Moreover, it will exclude all nested classes (including static member classes) by default.
+
+Note, however, that you can override this default behavior by configuring explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
+from excluding static member classes, you can override its exclude rules as follows.
+
+[source,xml,indent=0]
+[subs=attributes+]
+.Overriding exclude rules of Maven Surefire
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<excludes>
+						<exclude/>
+					</excludes>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Please see the
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
+documentation for Maven Surefire for details.
+
+[[running-tests-build-maven-filter-tags]]
+===== Filtering by Tags
+
+You can filter tests by <<running-tests-tags, tags>> or
+<<running-tests-tag-expressions, tag expressions>> using the following configuration
+properties.
+
+- to include _tags_ or _tag expressions_, use `groups`.
+- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<groups>acceptance | !feature-a</groups>
+					<excludedGroups>integration, regression</excludedGroups>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-config-params]]
+===== Configuration Parameters
+
+You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
+influence test discovery and execution by declaring the `configurationParameters`
+property and providing key-value pairs using the Java `Properties` file syntax (as shown
+below) or via the `junit-platform.properties` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<properties>
+						<configurationParameters>
+							junit.jupiter.conditions.deactivate = *
+							junit.jupiter.extensions.autodetection.enabled = true
+							junit.jupiter.testinstance.lifecycle.default = per_class
+						</configurationParameters>
+					</properties>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-ant]]
+==== Ant
+
+Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
+provides native support for launching tests on the JUnit Platform. The `junitlauncher`
+task is solely responsible for launching the JUnit Platform and passing it the selected
+collection of tests. The JUnit Platform then delegates to registered test engines to
+discover and execute the tests.
+
+The `junitlauncher` task attempts to align as closely as possible with native Ant
+constructs such as
+link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
+for allowing users to select the tests that they want executed by test engines. This gives
+the task a consistent and natural feel when compared to many other core Ant tasks.
+
+Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
+
+The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
+the task and can serve as a starting point.
+
+===== Basic Usage
+
+The following example demonstrates how to configure the `junitlauncher` task to select a
+single test class (i.e., `com.example.project.CalculatorTests`).
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+
+	<!-- ... -->
+
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<test name="com.example.project.CalculatorTests" />
+	</junitlauncher>
+----
+
+The `test` element allows you to specify a single test class that you want to be selected
+and executed. The `classpath` element allows you to specify the classpath to be used to
+launch the JUnit Platform. This classpath will also be used to locate test classes that
+are part of the execution.
+
+The following example demonstrates how to configure the `junitlauncher` task to select
+test classes from multiple locations.
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+	<!-- ... -->
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<testclasses outputdir="${output.dir}">
+			<fileset dir="${build.classes.dir}">
+				<include name="org/example/**/demo/**/" />
+			</fileset>
+			<fileset dir="${some.other.dir}">
+				<include name="org/myapp/**/" />
+			</fileset>
+		</testclasses>
+	</junitlauncher>
+----
+
+In the above example, the `testclasses` element allows you to select multiple test
+classes that reside in different locations.
+
+For further details on usage and configuration options please refer to the official Ant
+documentation for the
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
+
+[[running-tests-build-spring-boot]]
+==== Spring Boot
+
+link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
+managing the version of JUnit used in your project. In addition, the
+`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
+Jupiter, AssertJ, Mockito, etc.
+
+If your build relies on dependency management support from Spring Boot, you should not
+import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
+result in duplicate (and potentially conflicting) management of JUnit dependencies.
+
+If you need to override the version of a dependency used in your Spring Boot application,
+you have to override the exact name of the
+link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
+defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
+Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
+changing a dependency version is documented for both
+link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
+and
+link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
+
+With Gradle you can override the JUnit Jupiter version by including the following in your
+`build.gradle` file.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+	ext['junit-jupiter.version'] = '{version}'
+----
+
+With Maven you can override the JUnit Jupiter version by including the following in your
+`pom.xml` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<properties>
+		<junit-jupiter.version>{version}</junit-jupiter.version>
+	</properties>
+----
+
+[[running-tests-console-launcher]]
+=== Console Launcher
+
+The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
+Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
+Jupiter tests and print test execution results to the console.
+
+An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
+contains the contents of all of its dependencies is published in the {Maven_Central}
+repository under the
+https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
+directory. It contains the contents of the following artifacts:
+
+include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
+
+[NOTE]
+====
+Since the `junit-platform-console-standalone` JAR contains the contents of all of its
+dependencies, its Maven POM does not declare any dependencies.
+
+Furthermore, it is not very likely that you would need to include a dependency on the
+`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
+script. On the contrary, the executable `junit-platform-console-standalone` JAR is
+typically invoked directly from the command line or a shell script without a build script.
+
+If you need to declare dependencies in your build script on some of the artifacts
+contained in the `junit-platform-console-standalone` artifact, you should declare
+dependencies only on the JUnit artifacts that are used in your project. To simplify
+dependency management of JUnit artifacts in your build, you may wish to use the
+`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
+details.
+====
+
+You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
+standalone `ConsoleLauncher` as shown below.
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
+
+├─ JUnit Vintage
+│  └─ example.JUnit4Tests
+│     └─ standardJUnit4Test ✔
+└─ JUnit Jupiter
+   ├─ StandardTests
+   │  ├─ succeedingTest() ✔
+   │  └─ skippedTest() ↷ for demonstration purposes
+   └─ A special test case
+      ├─ Custom test name containing spaces ✔
+      ├─ ╯°□°)╯ ✔
+      └─ 😱 ✔
+
+Test run finished after 64 ms
+[         5 containers found      ]
+[         0 containers skipped    ]
+[         5 containers started    ]
+[         0 containers aborted    ]
+[         5 containers successful ]
+[         0 containers failed     ]
+[         6 tests found           ]
+[         1 tests skipped         ]
+[         5 tests started         ]
+[         0 tests aborted         ]
+[         5 tests successful      ]
+[         0 tests failed          ]
+----
+
+You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
+all jars in a directory):
+
+[source,console,subs=attributes+]
+----
+$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
+----
+
+[[running-tests-console-launcher-options]]
+==== Subcommands and Options
+
+The `{ConsoleLauncher}` provides the following subcommands:
+
+----
+include::{consoleLauncherOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-discovering-tests]]
+===== Discovering tests
+
+----
+include::{consoleLauncherDiscoverOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-executing-tests]]
+===== Executing tests
+
+.Exit Code
+NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
+All non-zero codes indicate an error of some sort. For example, status code `1`
+is returned if any containers or tests failed. If no tests are discovered and the
+`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
+with a status code of `2`. Unexpected or invalid user input yields a status code
+of `3`. An exit code of `-1` indicates an unspecified error condition.
+
+----
+include::{consoleLauncherExecuteOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-listing-test-engines]]
+===== Listing test engines
+
+----
+include::{consoleLauncherEnginesOptionsFile}[]
+----
+
+[[running-tests-console-launcher-argument-files]]
+==== Argument Files (@-files)
+
+On some platforms you may run into system limitations on the length of a command line when
+creating a command line with lots of options or with long arguments.
+
+The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
+are files that themselves contain arguments to be passed to the command. When the
+underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
+argument beginning with the character `@`, it expands the contents of that file into the
+argument list.
+
+The arguments within a file can be separated by spaces or newlines. If an argument
+contains embedded whitespace, the whole argument should be wrapped in double or single
+quotes -- for example, `"-f=My Files/Stuff.java"`.
+
+If the argument file does not exist or cannot be read, the argument will be treated
+literally and will not be removed. This will likely result in an "unmatched argument"
+error message. You can troubleshoot such errors by executing the command with the
+`picocli.trace` system property set to `DEBUG`.
+
+Multiple _@-files_ may be specified on the command line. The specified path may be
+relative to the current directory or absolute.
+
+You can pass a real parameter with an initial `@` character by escaping it with an
+additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
+subject to expansion.
+
+[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
+==== Redirecting Standard Output/Error to Files
+
+You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
+files using the `--redirect-stdout` and `--redirect-stderr` options:
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
+  --redirect-stdout=stdout.txt \
+  --redirect-stderr=stderr.txt
+----
+
+[NOTE]
+====
+If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
+output streams will be redirected to that file.
+
+The default charset is used for writing to the files.
+====
+
+[[running-tests-console-launcher-color-customization]]
+==== Color Customization
+
+The colors used in the output of the `{ConsoleLauncher}` can be customized.
+The option `--single-color` will apply a built-in monochrome style, while
+`--color-palette` will accept a properties file to override the
+https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
+The properties file below demonstrates the default style:
+
+[source,properties,indent=0]
+----
+SUCCESSFUL = 32
+ABORTED = 33
+FAILED = 31
+SKIPPED = 35
+CONTAINER = 35
+TEST = 34
+DYNAMIC = 35
+REPORTED = 37
+----
+
+[[running-tests-source-launcher]]
+=== Source Launcher
+
+Starting with Java 25 it is possible to write minimal source code test programs
+using the `org.junit.start` module. For example, like in a `HelloTests.java`
+file reading:
+
+```java
+import module org.junit.start;
+
+void main() {
+  JUnit.run();
+}
+
+@Test
+void stringLength() {
+  Assertions.assertEquals(11, "Hello JUnit".length());
+}
+```
+With all required modular JAR files available in a local `lib/` directory, the
+following Java 25+ command will discover and execute tests using the JUnit Platform.
+It will also print the result tree to the console.
+
+```shell
+java --module-path lib --add-modules org.junit.start HelloTests.java
+╷
+└─ JUnit Jupiter ✔
+   └─ HelloTests ✔
+      └─ stringLength() ✔
+```
+
+Find JUnit's class API documentation here: {JUnit}
+
+[[running-tests-discovery-selectors]]
+=== Discovery Selectors
+
+The JUnit Platform provides a rich set of discovery selectors that can be used to specify
+which tests should be discovered or executed.
+
+Discovery selectors can be created programmatically using the factory methods in the
+`{DiscoverySelectors}` class, specified declaratively via annotations when using the
+<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
+generically as strings via their identifiers.
+
+The following discovery selectors are provided out of the box:
+
+|===
+| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
+
+| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
+| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
+| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
+| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
+| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
+| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
+| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
+| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
+| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
+| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
+| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
+| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
+| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
+|===
+
+
+[[running-tests-config-params]]
+=== Configuration Parameters
+
+In addition to instructing the platform which test classes and test engines to include,
+which packages to scan, etc., it is sometimes necessary to provide additional custom
+configuration parameters that are specific to a particular test engine, listener, or
+registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
+parameters_ for the following use cases.
+
+- <<writing-tests-test-instance-lifecycle-changing-default>>
+- <<extensions-registration-automatic-enabling>>
+- <<extensions-conditions-deactivation>>
+- <<writing-tests-display-name-generator-default>>
+
+_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
+engines running on the JUnit Platform via one of the following mechanisms.
+
+1. The `configurationParameter()` and `configurationParameters()` methods in
+   `LauncherDiscoveryRequestBuilder` which
+   is used to build a request supplied to the <<launcher-api, Launcher API>>.
+    +
+   When running tests via one of the tools provided by the JUnit Platform you can specify
+   configuration parameters as follows:
+   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
+     option.
+   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
+     `systemProperties` DSL.
+   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
+     `configurationParameters` property.
+2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
+    +
+   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
+   specify custom configuration files using the `--config-resource` command-line option.
+3. JVM system properties.
+4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
+   in the root of the class path that follows the syntax rules for Java `Properties`
+   files.
+
+NOTE: Configuration parameters are looked up in the exact order defined above.
+Consequently, configuration parameters supplied directly to the `Launcher` take
+precedence over those supplied via custom configuration files, system properties, and the
+default configuration file. Similarly, configuration parameters supplied via system
+properties take precedence over those supplied via the default configuration file.
+
+[[running-tests-config-params-deactivation-pattern]]
+==== Pattern Matching Syntax
+
+This section describes the pattern matching syntax that is applied to the _configuration
+parameters_ used for the following features.
+
+- <<extensions-conditions-deactivation>>
+- <<launcher-api-listeners-custom-deactivation>>
+- <<stacktrace-pruning>>
+- <<extensions-registration-automatic-filtering>>
+
+If the value for the given _configuration parameter_ consists solely of an asterisk
+(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
+will be treated as a comma-separated list of patterns where each pattern will be matched
+against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
+a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
+(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
+pattern will be matched one-to-one against a FQCN.
+
+Examples:
+
+- `+++*+++`: matches all candidate classes.
+- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
+  any of its subpackages.
+- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
+  `MyCustomImpl`.
+- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
+- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
+  `System` or `Unit`.
+- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
+  `org.example.MyCustomImpl`.
+- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
+  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
+
+[[running-tests-tags]]
+=== Tags
+
+Tags are a JUnit Platform concept for marking and filtering tests. The programming model
+for adding tags to containers and tests is defined by the testing framework. For example,
+in JUnit Jupiter based tests, the `@Tag` annotation (see
+<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
+Vintage engine maps `@Category` annotations to tags (see
+<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
+own annotation or other means for users to specify tags.
+
+[[running-tests-tag-syntax-rules]]
+==== Syntax Rules for Tags
+
+Regardless how a tag is specified, the JUnit Platform enforces the following rules:
+
+* A tag must not be `null` or _blank_.
+* A _stripped_ tag must not contain whitespace.
+* A _stripped_ tag must not contain ISO control characters.
+* A _stripped_ tag must not contain any of the following _reserved characters_.
+- `,`: _comma_
+- `(`: _left parenthesis_
+- `)`: _right parenthesis_
+- `&`: _ampersand_
+- `|`: _vertical bar_
+- `!`: _exclamation point_
+
+NOTE: In the above context, "stripped" means that leading and trailing whitespace
+characters have been removed using `java.lang.String.strip()`.
+
+[[running-tests-tag-expressions]]
+==== Tag Expressions
+
+Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
+`(` and `)` can be used to adjust for operator precedence.
+
+Two special expressions are supported, `any()` and `none()`, which select all tests _with_
+any tags at all, and all tests _without_ any tags, respectively.
+These special expressions may be combined with other expressions just like normal tags.
+
+.Operators (in descending order of precedence)
+|===
+| Operator | Meaning | Associativity
+
+| `!`      | not     | right
+| `&`      | and     | left
+| `\|`     | or      | left
+|===
+
+If you are tagging your tests across multiple dimensions, tag expressions help you to
+select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
+_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
+expressions can be useful.
+
+[%header,cols="40,60"]
+|===
+| Tag Expression
+| Selection
+
+| `+++product+++`
+| all tests for *product*
+
+| `+++catalog \| shipping+++`
+| all tests for *catalog* plus all tests for *shipping*
+
+| `+++catalog &amp; shipping+++`
+| all tests for the intersection between *catalog* and *shipping*
+
+| `+++product &amp; !end-to-end+++`
+| all tests for *product*, but not the _end-to-end_ tests
+
+| `+++(micro \| integration) &amp; (product \| shipping)+++`
+| all _micro_ or _integration_ tests for *product* or *shipping*
+|===
+
+[[running-tests-capturing-output]]
+=== Capturing Standard Output/Error
+
+The JUnit Platform provides opt-in support for capturing output printed to `System.out`
+and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
+`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
+parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
+to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
+
+If enabled, the JUnit Platform captures the corresponding output and publishes it as a
+report entry using the `stdout` or `stderr` keys to all registered
+`{TestExecutionListener}` instances immediately before reporting the test or container as
+finished.
+
+Please note that the captured output will only contain output emitted by the thread that
+was used to execute a container or test. Any output by other threads will be omitted
+because particularly when
+<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
+to attribute it to a specific test or container.
+
+[[running-tests-listeners]]
+=== Using Listeners and Interceptors
+
+The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
+and custom user code to react to events fired at various points during the discovery and
+execution of a `TestPlan`.
+
+* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
+  closed.
+* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
+  `LauncherSession`.
+* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
+* `{TestExecutionListener}`: receives events that occur during test execution.
+
+The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
+registered automatically for you in order to support some feature of the build tool or IDE.
+
+The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
+order to produce some form of report or to display a graphical representation of the test
+plan in an IDE. Such listeners may be implemented and automatically registered by a build
+tool or IDE, or they may be included in a third-party library – potentially registered
+for you automatically. You can also implement and register your own listeners.
+
+For details on registering and configuring listeners, see the following sections of this
+guide.
+
+* <<launcher-api-launcher-session-listeners-custom>>
+* <<launcher-api-launcher-interceptors-custom>>
+* <<launcher-api-launcher-discovery-listeners-custom>>
+* <<launcher-api-listeners-custom>>
+* <<launcher-api-listeners-config>>
+* <<launcher-api-listeners-custom-deactivation>>
+
+The JUnit Platform provides the following listeners which you may wish to use with your
+test suite.
+
+<<junit-platform-reporting>> ::
+  `{LegacyXmlReportGeneratingListener}` can be used via the
+  <<running-tests-console-launcher>> or registered manually to generate XML reports
+  compatible with the de facto standard for JUnit 4 based test reports.
++
+`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
+specified by {OpenTestReporting}. It is auto-registered and can be enabled and
+configured via <<running-tests-config-params>>.
++
+See <<junit-platform-reporting>> for details.
+
+<<running-tests-listeners-flight-recorder>> ::
+  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
+  Java Flight Recorder events during test discovery and execution.
+
+`{LoggingListener}` ::
+  `TestExecutionListener` for logging informational messages for all events via a
+  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
+
+`{SummaryGeneratingListener}` ::
+  `TestExecutionListener` that generates a summary of the test execution which can be
+  printed via a `PrintWriter`.
+
+`{UniqueIdTrackingListener}` ::
+  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
+  or executed during the execution of the `TestPlan` and generates a file containing the
+  unique IDs once execution of the `TestPlan` has finished.
+
+[[running-tests-listeners-flight-recorder]]
+==== Flight Recorder Support
+
+The JUnit Platform provides opt-in support for generating Flight Recorder events.
+https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
+follows.
+
+> Flight Recorder records events originating from applications, the JVM, and the OS.
+Events are stored in a single file that can be attached to bug reports and examined by
+support engineers, allowing after-the-fact analysis of issues in the period leading up
+to a problem.
+
+In order to record Flight Recorder events generated while running tests, you need to
+start flight recording when launching a test suite via the following java command line
+option.
+
+   -XX:StartFlightRecording:filename=...
+
+Please consult the manual of your build tool for the appropriate commands.
+
+To analyze the recorded events, use the
+https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
+command line tool shipped with recent JDKs or open the recording file with
+https://jdk.java.net/jmc/[JDK Mission Control].
+
+[[stacktrace-pruning]]
+=== Stack Trace Pruning
+
+The JUnit Platform provides built-in support for pruning stack traces produced by failing
+tests. This feature is enabled by default but can be disabled by setting the
+`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
+
+When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
+packages are removed from the stack trace, unless the calls occur after the test itself
+or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
+never be excluded.
+
+In addition, all elements prior to and including the first call from the JUnit Platform
+`Launcher` will be removed.
+
+[[running-tests-discovery-issues]]
+=== Discovery Issues
+
+Test engines may encounter issues during test discovery. For example, the declaration of a
+test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
+Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
+report them with different severity levels:
+
+INFO::
+Indicates that the engine encountered something that could be potentially problematic, but
+could also happen due to a valid setup or configuration.
+
+WARNING::
+Indicates that the engine encountered something that is problematic and might lead to
+unexpected behavior or will be removed or changed in a future release.
+
+ERROR::
+Indicates that the engine encountered something that is definitely problematic and will
+lead to unexpected behavior.
+
+If an engine reports an issue with a severity equal to or higher than a configurable
+_critical_ severity, its tests will not be executed. Instead, the engine will be reported
+as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
+Non-critical issues will be logged but will not prevent the engine from executing its
+tests. The `junit.platform.discovery.issue.severity.critical`
+<<running-tests-config-params, configuration parameter>> can be used to set the critical
+severity level. Currently, the default value is `ERROR` but it may be changed in a future
+release.
+
+TIP: To surface all discovery issues in your project, it is recommended to set the
+`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
+
+In addition, registered `{LauncherDiscoveryListener}` implementations can receive
+discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
+report issues to the user in a more user-friendly way. For example, IDEs may choose to
+display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/tags.adoc b/documentation/modules/ROOT/pages/running-tests/tags.adoc
new file mode 100644
index 000000000000..3099a146c2b4
--- /dev/null
+++ b/documentation/modules/ROOT/pages/running-tests/tags.adoc
@@ -0,0 +1,1216 @@
+[[running-tests]]
+== Running Tests
+
+[[running-tests-ide]]
+=== IDE Support
+
+[[running-tests-ide-intellij-idea]]
+==== IntelliJ IDEA
+
+IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
+information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
+however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
+IDEA download the following JARs automatically based on the API version used in the
+project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
+
+In order to use a different JUnit version (e.g., {version}), you may need to
+include the corresponding versions of the `junit-platform-launcher`,
+`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
+
+.Additional Gradle Dependencies
+[source,groovy]
+[subs=attributes+]
+----
+testImplementation(platform("org.junit:junit-bom:{version}"))
+testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
+testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
+----
+
+.Additional Maven Dependencies
+[source,xml]
+[subs=attributes+]
+----
+<!-- ... -->
+<dependencies>
+	<dependency>
+		<groupId>org.junit.platform</groupId>
+		<artifactId>junit-platform-launcher</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.jupiter</groupId>
+		<artifactId>junit-jupiter-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.vintage</groupId>
+		<artifactId>junit-vintage-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+</dependencies>
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+[[running-tests-ide-eclipse]]
+==== Eclipse
+
+Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
+release.
+
+For more information on using JUnit Platform in Eclipse consult the official _Eclipse
+support for JUnit 5_ section of the
+https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
+(4.7.1a) - New and Noteworthy] documentation.
+
+[[running-tests-ide-netbeans]]
+==== NetBeans
+
+NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
+https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
+
+For more information consult the JUnit 5 section of the
+https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
+release notes].
+
+[[running-tests-ide-vscode]]
+==== Visual Studio Code
+
+https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
+Platform via the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
+Runner] extension which is installed by default as part of the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
+Extension Pack].
+
+For more information consult the _Testing_ section of the
+https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
+documentation.
+
+[[running-tests-ide-other]]
+==== Other IDEs
+
+If you are using an editor or IDE other than one of those listed in the previous sections,
+and it doesn't support running tests on the JUnit Platform, you can use the
+<<running-tests-console-launcher>> to run them from the command line.
+
+[[running-tests-build]]
+=== Build Support
+
+[[running-tests-build-gradle]]
+==== Gradle
+
+Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
+https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
+for executing tests on the JUnit Platform. To enable it, you need to specify
+`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform()
+}
+----
+
+Filtering by <<running-tests-tags, tags>>,
+<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform {
+		includeTags("fast", "smoke & feature-a")
+		// excludeTags("slow", "ci")
+		includeEngines("junit-jupiter")
+		// excludeEngines("junit-vintage")
+	}
+}
+----
+
+Please refer to the
+https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
+for a comprehensive list of options.
+
+[[running-tests-build-gradle-bom]]
+===== Aligning dependency versions
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Explicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation(platform("org.junit:junit-bom:{version}"))
+	testImplementation("org.junit.jupiter:junit-jupiter")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+Since all JUnit artifacts declare a
+https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
+you usually don't need to declare an explicit dependency on it yourself. Instead, it's
+sufficient to declare _one_ regular dependency that includes a version number. Gradle will
+then pull in the BOM automatically so you can omit the version for all other JUnit
+artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Implicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
+}
+----
+<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
+<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
+
+[WARNING]
+.Declaring a dependency on junit-platform-launcher
+====
+Even though pre-8.0 versions of Gradle don't require declaring an explicit
+dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
+of JUnit artifacts on the test runtime classpath are aligned.
+
+Moreover, doing so is recommended and in some cases even required when importing the
+project into an IDE like <<running-tests-ide-eclipse>> or
+<<running-tests-ide-intellij-idea>>.
+====
+
+[[running-tests-build-gradle-engines-configure]]
+===== Configuring Test Engines
+
+In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
+
+To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
+on the dependency-aggregating JUnit Jupiter artifact similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Alternatively, you can use Gradle's
+https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
+support.
+
+[source,kotlin,indent=0]
+[subs=attributes+]
+.Kotlin DSL
+----
+testing {
+	suites {
+		named<JvmTestSuite>("test") {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Groovy DSL
+----
+testing {
+	suites {
+		test {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
+dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
+implementation similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("junit:junit:{junit4-version}")
+	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+[[running-tests-build-gradle-config-params]]
+===== Configuration Parameters
+
+The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
+Platform <<running-tests-config-params, configuration parameters>> to influence test
+discovery and execution. However, you can provide configuration parameters within the
+build script via system properties (as shown below) or via the
+`junit-platform.properties` file.
+
+[source,groovy,indent=0]
+----
+test {
+	// ...
+	systemProperty("junit.jupiter.conditions.deactivate", "*")
+	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
+	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
+	// ...
+}
+----
+
+[[running-tests-build-gradle-logging]]
+===== Configuring Logging (optional)
+
+JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
+emit warnings and debug information. Please refer to the official documentation of
+`{LogManager}` for configuration options.
+
+Alternatively, it's possible to redirect log messages to other logging frameworks such as
+{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
+`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
+qualified class name_ of the `{LogManager}` implementation to use. The example below
+demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
+details).
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
+	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
+	systemProperty("log4j2.disableJmx", "true")
+}
+----
+
+Other logging frameworks provide different means to redirect messages logged using
+`java.util.logging`. For example, for {Logback} you can use the
+https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
+dependency to the test runtime classpath.
+
+[[running-tests-build-maven]]
+==== Maven
+
+Maven Surefire and Maven Failsafe provide
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
+for executing tests on the JUnit Platform. The `pom.xml` file in the
+`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
+and can serve as a starting point for configuring your Maven build.
+
+[WARNING]
+.Minimum required version of Maven Surefire/Failsafe
+====
+As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
+====
+
+[[running-tests-build-maven-bom]]
+===== Aligning dependency versions
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+[[running-tests-build-maven-engines-configure]]
+===== Configuring Test Engines
+
+In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
+`TestEngine` implementation must be added to the test classpath.
+
+To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
+on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
+following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>org.junit.jupiter</groupId>
+			<artifactId>junit-jupiter</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
+long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
+`TestEngine` implementation similar to the following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>junit</groupId>
+			<artifactId>junit</artifactId>
+			<version>{junit4-version}</version>
+			<scope>test</scope>
+		</dependency>
+		<dependency>
+			<groupId>org.junit.vintage</groupId>
+			<artifactId>junit-vintage-engine</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-filter-test-class-names]]
+===== Filtering by Test Class Names
+
+The Maven Surefire Plugin will scan for test classes whose fully qualified names match
+the following patterns.
+
+- `+++**/Test*.java+++`
+- `+++**/*Test.java+++`
+- `+++**/*Tests.java+++`
+- `+++**/*TestCase.java+++`
+
+Moreover, it will exclude all nested classes (including static member classes) by default.
+
+Note, however, that you can override this default behavior by configuring explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
+from excluding static member classes, you can override its exclude rules as follows.
+
+[source,xml,indent=0]
+[subs=attributes+]
+.Overriding exclude rules of Maven Surefire
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<excludes>
+						<exclude/>
+					</excludes>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Please see the
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
+documentation for Maven Surefire for details.
+
+[[running-tests-build-maven-filter-tags]]
+===== Filtering by Tags
+
+You can filter tests by <<running-tests-tags, tags>> or
+<<running-tests-tag-expressions, tag expressions>> using the following configuration
+properties.
+
+- to include _tags_ or _tag expressions_, use `groups`.
+- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<groups>acceptance | !feature-a</groups>
+					<excludedGroups>integration, regression</excludedGroups>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-config-params]]
+===== Configuration Parameters
+
+You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
+influence test discovery and execution by declaring the `configurationParameters`
+property and providing key-value pairs using the Java `Properties` file syntax (as shown
+below) or via the `junit-platform.properties` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<properties>
+						<configurationParameters>
+							junit.jupiter.conditions.deactivate = *
+							junit.jupiter.extensions.autodetection.enabled = true
+							junit.jupiter.testinstance.lifecycle.default = per_class
+						</configurationParameters>
+					</properties>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-ant]]
+==== Ant
+
+Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
+provides native support for launching tests on the JUnit Platform. The `junitlauncher`
+task is solely responsible for launching the JUnit Platform and passing it the selected
+collection of tests. The JUnit Platform then delegates to registered test engines to
+discover and execute the tests.
+
+The `junitlauncher` task attempts to align as closely as possible with native Ant
+constructs such as
+link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
+for allowing users to select the tests that they want executed by test engines. This gives
+the task a consistent and natural feel when compared to many other core Ant tasks.
+
+Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
+
+The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
+the task and can serve as a starting point.
+
+===== Basic Usage
+
+The following example demonstrates how to configure the `junitlauncher` task to select a
+single test class (i.e., `com.example.project.CalculatorTests`).
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+
+	<!-- ... -->
+
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<test name="com.example.project.CalculatorTests" />
+	</junitlauncher>
+----
+
+The `test` element allows you to specify a single test class that you want to be selected
+and executed. The `classpath` element allows you to specify the classpath to be used to
+launch the JUnit Platform. This classpath will also be used to locate test classes that
+are part of the execution.
+
+The following example demonstrates how to configure the `junitlauncher` task to select
+test classes from multiple locations.
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+	<!-- ... -->
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<testclasses outputdir="${output.dir}">
+			<fileset dir="${build.classes.dir}">
+				<include name="org/example/**/demo/**/" />
+			</fileset>
+			<fileset dir="${some.other.dir}">
+				<include name="org/myapp/**/" />
+			</fileset>
+		</testclasses>
+	</junitlauncher>
+----
+
+In the above example, the `testclasses` element allows you to select multiple test
+classes that reside in different locations.
+
+For further details on usage and configuration options please refer to the official Ant
+documentation for the
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
+
+[[running-tests-build-spring-boot]]
+==== Spring Boot
+
+link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
+managing the version of JUnit used in your project. In addition, the
+`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
+Jupiter, AssertJ, Mockito, etc.
+
+If your build relies on dependency management support from Spring Boot, you should not
+import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
+result in duplicate (and potentially conflicting) management of JUnit dependencies.
+
+If you need to override the version of a dependency used in your Spring Boot application,
+you have to override the exact name of the
+link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
+defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
+Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
+changing a dependency version is documented for both
+link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
+and
+link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
+
+With Gradle you can override the JUnit Jupiter version by including the following in your
+`build.gradle` file.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+	ext['junit-jupiter.version'] = '{version}'
+----
+
+With Maven you can override the JUnit Jupiter version by including the following in your
+`pom.xml` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<properties>
+		<junit-jupiter.version>{version}</junit-jupiter.version>
+	</properties>
+----
+
+[[running-tests-console-launcher]]
+=== Console Launcher
+
+The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
+Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
+Jupiter tests and print test execution results to the console.
+
+An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
+contains the contents of all of its dependencies is published in the {Maven_Central}
+repository under the
+https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
+directory. It contains the contents of the following artifacts:
+
+include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
+
+[NOTE]
+====
+Since the `junit-platform-console-standalone` JAR contains the contents of all of its
+dependencies, its Maven POM does not declare any dependencies.
+
+Furthermore, it is not very likely that you would need to include a dependency on the
+`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
+script. On the contrary, the executable `junit-platform-console-standalone` JAR is
+typically invoked directly from the command line or a shell script without a build script.
+
+If you need to declare dependencies in your build script on some of the artifacts
+contained in the `junit-platform-console-standalone` artifact, you should declare
+dependencies only on the JUnit artifacts that are used in your project. To simplify
+dependency management of JUnit artifacts in your build, you may wish to use the
+`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
+details.
+====
+
+You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
+standalone `ConsoleLauncher` as shown below.
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
+
+├─ JUnit Vintage
+│  └─ example.JUnit4Tests
+│     └─ standardJUnit4Test ✔
+└─ JUnit Jupiter
+   ├─ StandardTests
+   │  ├─ succeedingTest() ✔
+   │  └─ skippedTest() ↷ for demonstration purposes
+   └─ A special test case
+      ├─ Custom test name containing spaces ✔
+      ├─ ╯°□°)╯ ✔
+      └─ 😱 ✔
+
+Test run finished after 64 ms
+[         5 containers found      ]
+[         0 containers skipped    ]
+[         5 containers started    ]
+[         0 containers aborted    ]
+[         5 containers successful ]
+[         0 containers failed     ]
+[         6 tests found           ]
+[         1 tests skipped         ]
+[         5 tests started         ]
+[         0 tests aborted         ]
+[         5 tests successful      ]
+[         0 tests failed          ]
+----
+
+You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
+all jars in a directory):
+
+[source,console,subs=attributes+]
+----
+$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
+----
+
+[[running-tests-console-launcher-options]]
+==== Subcommands and Options
+
+The `{ConsoleLauncher}` provides the following subcommands:
+
+----
+include::{consoleLauncherOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-discovering-tests]]
+===== Discovering tests
+
+----
+include::{consoleLauncherDiscoverOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-executing-tests]]
+===== Executing tests
+
+.Exit Code
+NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
+All non-zero codes indicate an error of some sort. For example, status code `1`
+is returned if any containers or tests failed. If no tests are discovered and the
+`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
+with a status code of `2`. Unexpected or invalid user input yields a status code
+of `3`. An exit code of `-1` indicates an unspecified error condition.
+
+----
+include::{consoleLauncherExecuteOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-listing-test-engines]]
+===== Listing test engines
+
+----
+include::{consoleLauncherEnginesOptionsFile}[]
+----
+
+[[running-tests-console-launcher-argument-files]]
+==== Argument Files (@-files)
+
+On some platforms you may run into system limitations on the length of a command line when
+creating a command line with lots of options or with long arguments.
+
+The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
+are files that themselves contain arguments to be passed to the command. When the
+underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
+argument beginning with the character `@`, it expands the contents of that file into the
+argument list.
+
+The arguments within a file can be separated by spaces or newlines. If an argument
+contains embedded whitespace, the whole argument should be wrapped in double or single
+quotes -- for example, `"-f=My Files/Stuff.java"`.
+
+If the argument file does not exist or cannot be read, the argument will be treated
+literally and will not be removed. This will likely result in an "unmatched argument"
+error message. You can troubleshoot such errors by executing the command with the
+`picocli.trace` system property set to `DEBUG`.
+
+Multiple _@-files_ may be specified on the command line. The specified path may be
+relative to the current directory or absolute.
+
+You can pass a real parameter with an initial `@` character by escaping it with an
+additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
+subject to expansion.
+
+[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
+==== Redirecting Standard Output/Error to Files
+
+You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
+files using the `--redirect-stdout` and `--redirect-stderr` options:
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
+  --redirect-stdout=stdout.txt \
+  --redirect-stderr=stderr.txt
+----
+
+[NOTE]
+====
+If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
+output streams will be redirected to that file.
+
+The default charset is used for writing to the files.
+====
+
+[[running-tests-console-launcher-color-customization]]
+==== Color Customization
+
+The colors used in the output of the `{ConsoleLauncher}` can be customized.
+The option `--single-color` will apply a built-in monochrome style, while
+`--color-palette` will accept a properties file to override the
+https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
+The properties file below demonstrates the default style:
+
+[source,properties,indent=0]
+----
+SUCCESSFUL = 32
+ABORTED = 33
+FAILED = 31
+SKIPPED = 35
+CONTAINER = 35
+TEST = 34
+DYNAMIC = 35
+REPORTED = 37
+----
+
+[[running-tests-source-launcher]]
+=== Source Launcher
+
+Starting with Java 25 it is possible to write minimal source code test programs
+using the `org.junit.start` module. For example, like in a `HelloTests.java`
+file reading:
+
+```java
+import module org.junit.start;
+
+void main() {
+  JUnit.run();
+}
+
+@Test
+void stringLength() {
+  Assertions.assertEquals(11, "Hello JUnit".length());
+}
+```
+With all required modular JAR files available in a local `lib/` directory, the
+following Java 25+ command will discover and execute tests using the JUnit Platform.
+It will also print the result tree to the console.
+
+```shell
+java --module-path lib --add-modules org.junit.start HelloTests.java
+╷
+└─ JUnit Jupiter ✔
+   └─ HelloTests ✔
+      └─ stringLength() ✔
+```
+
+Find JUnit's class API documentation here: {JUnit}
+
+[[running-tests-discovery-selectors]]
+=== Discovery Selectors
+
+The JUnit Platform provides a rich set of discovery selectors that can be used to specify
+which tests should be discovered or executed.
+
+Discovery selectors can be created programmatically using the factory methods in the
+`{DiscoverySelectors}` class, specified declaratively via annotations when using the
+<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
+generically as strings via their identifiers.
+
+The following discovery selectors are provided out of the box:
+
+|===
+| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
+
+| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
+| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
+| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
+| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
+| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
+| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
+| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
+| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
+| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
+| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
+| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
+| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
+| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
+|===
+
+
+[[running-tests-config-params]]
+=== Configuration Parameters
+
+In addition to instructing the platform which test classes and test engines to include,
+which packages to scan, etc., it is sometimes necessary to provide additional custom
+configuration parameters that are specific to a particular test engine, listener, or
+registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
+parameters_ for the following use cases.
+
+- <<writing-tests-test-instance-lifecycle-changing-default>>
+- <<extensions-registration-automatic-enabling>>
+- <<extensions-conditions-deactivation>>
+- <<writing-tests-display-name-generator-default>>
+
+_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
+engines running on the JUnit Platform via one of the following mechanisms.
+
+1. The `configurationParameter()` and `configurationParameters()` methods in
+   `LauncherDiscoveryRequestBuilder` which
+   is used to build a request supplied to the <<launcher-api, Launcher API>>.
+    +
+   When running tests via one of the tools provided by the JUnit Platform you can specify
+   configuration parameters as follows:
+   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
+     option.
+   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
+     `systemProperties` DSL.
+   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
+     `configurationParameters` property.
+2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
+    +
+   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
+   specify custom configuration files using the `--config-resource` command-line option.
+3. JVM system properties.
+4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
+   in the root of the class path that follows the syntax rules for Java `Properties`
+   files.
+
+NOTE: Configuration parameters are looked up in the exact order defined above.
+Consequently, configuration parameters supplied directly to the `Launcher` take
+precedence over those supplied via custom configuration files, system properties, and the
+default configuration file. Similarly, configuration parameters supplied via system
+properties take precedence over those supplied via the default configuration file.
+
+[[running-tests-config-params-deactivation-pattern]]
+==== Pattern Matching Syntax
+
+This section describes the pattern matching syntax that is applied to the _configuration
+parameters_ used for the following features.
+
+- <<extensions-conditions-deactivation>>
+- <<launcher-api-listeners-custom-deactivation>>
+- <<stacktrace-pruning>>
+- <<extensions-registration-automatic-filtering>>
+
+If the value for the given _configuration parameter_ consists solely of an asterisk
+(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
+will be treated as a comma-separated list of patterns where each pattern will be matched
+against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
+a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
+(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
+pattern will be matched one-to-one against a FQCN.
+
+Examples:
+
+- `+++*+++`: matches all candidate classes.
+- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
+  any of its subpackages.
+- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
+  `MyCustomImpl`.
+- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
+- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
+  `System` or `Unit`.
+- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
+  `org.example.MyCustomImpl`.
+- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
+  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
+
+[[running-tests-tags]]
+=== Tags
+
+Tags are a JUnit Platform concept for marking and filtering tests. The programming model
+for adding tags to containers and tests is defined by the testing framework. For example,
+in JUnit Jupiter based tests, the `@Tag` annotation (see
+<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
+Vintage engine maps `@Category` annotations to tags (see
+<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
+own annotation or other means for users to specify tags.
+
+[[running-tests-tag-syntax-rules]]
+==== Syntax Rules for Tags
+
+Regardless how a tag is specified, the JUnit Platform enforces the following rules:
+
+* A tag must not be `null` or _blank_.
+* A _stripped_ tag must not contain whitespace.
+* A _stripped_ tag must not contain ISO control characters.
+* A _stripped_ tag must not contain any of the following _reserved characters_.
+- `,`: _comma_
+- `(`: _left parenthesis_
+- `)`: _right parenthesis_
+- `&`: _ampersand_
+- `|`: _vertical bar_
+- `!`: _exclamation point_
+
+NOTE: In the above context, "stripped" means that leading and trailing whitespace
+characters have been removed using `java.lang.String.strip()`.
+
+[[running-tests-tag-expressions]]
+==== Tag Expressions
+
+Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
+`(` and `)` can be used to adjust for operator precedence.
+
+Two special expressions are supported, `any()` and `none()`, which select all tests _with_
+any tags at all, and all tests _without_ any tags, respectively.
+These special expressions may be combined with other expressions just like normal tags.
+
+.Operators (in descending order of precedence)
+|===
+| Operator | Meaning | Associativity
+
+| `!`      | not     | right
+| `&`      | and     | left
+| `\|`     | or      | left
+|===
+
+If you are tagging your tests across multiple dimensions, tag expressions help you to
+select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
+_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
+expressions can be useful.
+
+[%header,cols="40,60"]
+|===
+| Tag Expression
+| Selection
+
+| `+++product+++`
+| all tests for *product*
+
+| `+++catalog \| shipping+++`
+| all tests for *catalog* plus all tests for *shipping*
+
+| `+++catalog &amp; shipping+++`
+| all tests for the intersection between *catalog* and *shipping*
+
+| `+++product &amp; !end-to-end+++`
+| all tests for *product*, but not the _end-to-end_ tests
+
+| `+++(micro \| integration) &amp; (product \| shipping)+++`
+| all _micro_ or _integration_ tests for *product* or *shipping*
+|===
+
+[[running-tests-capturing-output]]
+=== Capturing Standard Output/Error
+
+The JUnit Platform provides opt-in support for capturing output printed to `System.out`
+and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
+`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
+parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
+to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
+
+If enabled, the JUnit Platform captures the corresponding output and publishes it as a
+report entry using the `stdout` or `stderr` keys to all registered
+`{TestExecutionListener}` instances immediately before reporting the test or container as
+finished.
+
+Please note that the captured output will only contain output emitted by the thread that
+was used to execute a container or test. Any output by other threads will be omitted
+because particularly when
+<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
+to attribute it to a specific test or container.
+
+[[running-tests-listeners]]
+=== Using Listeners and Interceptors
+
+The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
+and custom user code to react to events fired at various points during the discovery and
+execution of a `TestPlan`.
+
+* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
+  closed.
+* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
+  `LauncherSession`.
+* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
+* `{TestExecutionListener}`: receives events that occur during test execution.
+
+The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
+registered automatically for you in order to support some feature of the build tool or IDE.
+
+The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
+order to produce some form of report or to display a graphical representation of the test
+plan in an IDE. Such listeners may be implemented and automatically registered by a build
+tool or IDE, or they may be included in a third-party library – potentially registered
+for you automatically. You can also implement and register your own listeners.
+
+For details on registering and configuring listeners, see the following sections of this
+guide.
+
+* <<launcher-api-launcher-session-listeners-custom>>
+* <<launcher-api-launcher-interceptors-custom>>
+* <<launcher-api-launcher-discovery-listeners-custom>>
+* <<launcher-api-listeners-custom>>
+* <<launcher-api-listeners-config>>
+* <<launcher-api-listeners-custom-deactivation>>
+
+The JUnit Platform provides the following listeners which you may wish to use with your
+test suite.
+
+<<junit-platform-reporting>> ::
+  `{LegacyXmlReportGeneratingListener}` can be used via the
+  <<running-tests-console-launcher>> or registered manually to generate XML reports
+  compatible with the de facto standard for JUnit 4 based test reports.
++
+`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
+specified by {OpenTestReporting}. It is auto-registered and can be enabled and
+configured via <<running-tests-config-params>>.
++
+See <<junit-platform-reporting>> for details.
+
+<<running-tests-listeners-flight-recorder>> ::
+  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
+  Java Flight Recorder events during test discovery and execution.
+
+`{LoggingListener}` ::
+  `TestExecutionListener` for logging informational messages for all events via a
+  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
+
+`{SummaryGeneratingListener}` ::
+  `TestExecutionListener` that generates a summary of the test execution which can be
+  printed via a `PrintWriter`.
+
+`{UniqueIdTrackingListener}` ::
+  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
+  or executed during the execution of the `TestPlan` and generates a file containing the
+  unique IDs once execution of the `TestPlan` has finished.
+
+[[running-tests-listeners-flight-recorder]]
+==== Flight Recorder Support
+
+The JUnit Platform provides opt-in support for generating Flight Recorder events.
+https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
+follows.
+
+> Flight Recorder records events originating from applications, the JVM, and the OS.
+Events are stored in a single file that can be attached to bug reports and examined by
+support engineers, allowing after-the-fact analysis of issues in the period leading up
+to a problem.
+
+In order to record Flight Recorder events generated while running tests, you need to
+start flight recording when launching a test suite via the following java command line
+option.
+
+   -XX:StartFlightRecording:filename=...
+
+Please consult the manual of your build tool for the appropriate commands.
+
+To analyze the recorded events, use the
+https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
+command line tool shipped with recent JDKs or open the recording file with
+https://jdk.java.net/jmc/[JDK Mission Control].
+
+[[stacktrace-pruning]]
+=== Stack Trace Pruning
+
+The JUnit Platform provides built-in support for pruning stack traces produced by failing
+tests. This feature is enabled by default but can be disabled by setting the
+`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
+
+When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
+packages are removed from the stack trace, unless the calls occur after the test itself
+or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
+never be excluded.
+
+In addition, all elements prior to and including the first call from the JUnit Platform
+`Launcher` will be removed.
+
+[[running-tests-discovery-issues]]
+=== Discovery Issues
+
+Test engines may encounter issues during test discovery. For example, the declaration of a
+test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
+Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
+report them with different severity levels:
+
+INFO::
+Indicates that the engine encountered something that could be potentially problematic, but
+could also happen due to a valid setup or configuration.
+
+WARNING::
+Indicates that the engine encountered something that is problematic and might lead to
+unexpected behavior or will be removed or changed in a future release.
+
+ERROR::
+Indicates that the engine encountered something that is definitely problematic and will
+lead to unexpected behavior.
+
+If an engine reports an issue with a severity equal to or higher than a configurable
+_critical_ severity, its tests will not be executed. Instead, the engine will be reported
+as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
+Non-critical issues will be logged but will not prevent the engine from executing its
+tests. The `junit.platform.discovery.issue.severity.critical`
+<<running-tests-config-params, configuration parameter>> can be used to set the critical
+severity level. Currently, the default value is `ERROR` but it may be changed in a future
+release.
+
+TIP: To surface all discovery issues in your project, it is recommended to set the
+`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
+
+In addition, registered `{LauncherDiscoveryListener}` implementations can receive
+discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
+report issues to the user in a more user-friendly way. For example, IDEs may choose to
+display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc b/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc
new file mode 100644
index 000000000000..3099a146c2b4
--- /dev/null
+++ b/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc
@@ -0,0 +1,1216 @@
+[[running-tests]]
+== Running Tests
+
+[[running-tests-ide]]
+=== IDE Support
+
+[[running-tests-ide-intellij-idea]]
+==== IntelliJ IDEA
+
+IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
+information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
+however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
+IDEA download the following JARs automatically based on the API version used in the
+project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
+
+In order to use a different JUnit version (e.g., {version}), you may need to
+include the corresponding versions of the `junit-platform-launcher`,
+`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
+
+.Additional Gradle Dependencies
+[source,groovy]
+[subs=attributes+]
+----
+testImplementation(platform("org.junit:junit-bom:{version}"))
+testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
+testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
+----
+
+.Additional Maven Dependencies
+[source,xml]
+[subs=attributes+]
+----
+<!-- ... -->
+<dependencies>
+	<dependency>
+		<groupId>org.junit.platform</groupId>
+		<artifactId>junit-platform-launcher</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.jupiter</groupId>
+		<artifactId>junit-jupiter-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+	<dependency>
+		<groupId>org.junit.vintage</groupId>
+		<artifactId>junit-vintage-engine</artifactId>
+		<scope>test</scope>
+	</dependency>
+</dependencies>
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+[[running-tests-ide-eclipse]]
+==== Eclipse
+
+Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
+release.
+
+For more information on using JUnit Platform in Eclipse consult the official _Eclipse
+support for JUnit 5_ section of the
+https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
+(4.7.1a) - New and Noteworthy] documentation.
+
+[[running-tests-ide-netbeans]]
+==== NetBeans
+
+NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
+https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
+
+For more information consult the JUnit 5 section of the
+https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
+release notes].
+
+[[running-tests-ide-vscode]]
+==== Visual Studio Code
+
+https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
+Platform via the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
+Runner] extension which is installed by default as part of the
+https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
+Extension Pack].
+
+For more information consult the _Testing_ section of the
+https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
+documentation.
+
+[[running-tests-ide-other]]
+==== Other IDEs
+
+If you are using an editor or IDE other than one of those listed in the previous sections,
+and it doesn't support running tests on the JUnit Platform, you can use the
+<<running-tests-console-launcher>> to run them from the command line.
+
+[[running-tests-build]]
+=== Build Support
+
+[[running-tests-build-gradle]]
+==== Gradle
+
+Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
+https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
+for executing tests on the JUnit Platform. To enable it, you need to specify
+`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform()
+}
+----
+
+Filtering by <<running-tests-tags, tags>>,
+<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	useJUnitPlatform {
+		includeTags("fast", "smoke & feature-a")
+		// excludeTags("slow", "ci")
+		includeEngines("junit-jupiter")
+		// excludeEngines("junit-vintage")
+	}
+}
+----
+
+Please refer to the
+https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
+for a comprehensive list of options.
+
+[[running-tests-build-gradle-bom]]
+===== Aligning dependency versions
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Explicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation(platform("org.junit:junit-bom:{version}"))
+	testImplementation("org.junit.jupiter:junit-jupiter")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+Since all JUnit artifacts declare a
+https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
+you usually don't need to declare an explicit dependency on it yourself. Instead, it's
+sufficient to declare _one_ regular dependency that includes a version number. Gradle will
+then pull in the BOM automatically so you can omit the version for all other JUnit
+artifacts.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Implicit platform dependency on the BOM
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
+}
+----
+<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
+<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
+
+[WARNING]
+.Declaring a dependency on junit-platform-launcher
+====
+Even though pre-8.0 versions of Gradle don't require declaring an explicit
+dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
+of JUnit artifacts on the test runtime classpath are aligned.
+
+Moreover, doing so is recommended and in some cases even required when importing the
+project into an IDE like <<running-tests-ide-eclipse>> or
+<<running-tests-ide-intellij-idea>>.
+====
+
+[[running-tests-build-gradle-engines-configure]]
+===== Configuring Test Engines
+
+In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
+
+To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
+on the dependency-aggregating JUnit Jupiter artifact similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+Alternatively, you can use Gradle's
+https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
+support.
+
+[source,kotlin,indent=0]
+[subs=attributes+]
+.Kotlin DSL
+----
+testing {
+	suites {
+		named<JvmTestSuite>("test") {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+[source,groovy,indent=0]
+[subs=attributes+]
+.Groovy DSL
+----
+testing {
+	suites {
+		test {
+			useJUnitJupiter("{version}")
+		}
+	}
+}
+----
+
+The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
+dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
+implementation similar to the following.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+dependencies {
+	testImplementation("junit:junit:{junit4-version}")
+	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
+	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
+}
+----
+
+[[running-tests-build-gradle-config-params]]
+===== Configuration Parameters
+
+The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
+Platform <<running-tests-config-params, configuration parameters>> to influence test
+discovery and execution. However, you can provide configuration parameters within the
+build script via system properties (as shown below) or via the
+`junit-platform.properties` file.
+
+[source,groovy,indent=0]
+----
+test {
+	// ...
+	systemProperty("junit.jupiter.conditions.deactivate", "*")
+	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
+	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
+	// ...
+}
+----
+
+[[running-tests-build-gradle-logging]]
+===== Configuring Logging (optional)
+
+JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
+emit warnings and debug information. Please refer to the official documentation of
+`{LogManager}` for configuration options.
+
+Alternatively, it's possible to redirect log messages to other logging frameworks such as
+{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
+`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
+qualified class name_ of the `{LogManager}` implementation to use. The example below
+demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
+details).
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+test {
+	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
+	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
+	systemProperty("log4j2.disableJmx", "true")
+}
+----
+
+Other logging frameworks provide different means to redirect messages logged using
+`java.util.logging`. For example, for {Logback} you can use the
+https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
+dependency to the test runtime classpath.
+
+[[running-tests-build-maven]]
+==== Maven
+
+Maven Surefire and Maven Failsafe provide
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
+for executing tests on the JUnit Platform. The `pom.xml` file in the
+`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
+and can serve as a starting point for configuring your Maven build.
+
+[WARNING]
+.Minimum required version of Maven Surefire/Failsafe
+====
+As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
+====
+
+[[running-tests-build-maven-bom]]
+===== Aligning dependency versions
+
+Unless you're using Spring Boot which defines its own way of managing dependencies, it is
+recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+versions of all JUnit artifacts.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+<dependencyManagement>
+	<dependencies>
+		<dependency>
+			<groupId>org.junit</groupId>
+			<artifactId>junit-bom</artifactId>
+			<version>{version}</version>
+			<type>pom</type>
+			<scope>import</scope>
+		</dependency>
+	</dependencies>
+</dependencyManagement>
+----
+
+Using the BOM allows you to omit the version when declaring dependencies on all artifacts
+with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
+
+TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+of JUnit used in your Spring Boot application.
+
+[[running-tests-build-maven-engines-configure]]
+===== Configuring Test Engines
+
+In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
+`TestEngine` implementation must be added to the test classpath.
+
+To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
+on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
+following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>org.junit.jupiter</groupId>
+			<artifactId>junit-jupiter</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
+long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
+`TestEngine` implementation similar to the following.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<dependencies>
+		<!-- ... -->
+		<dependency>
+			<groupId>junit</groupId>
+			<artifactId>junit</artifactId>
+			<version>{junit4-version}</version>
+			<scope>test</scope>
+		</dependency>
+		<dependency>
+			<groupId>org.junit.vintage</groupId>
+			<artifactId>junit-vintage-engine</artifactId>
+			<version>{version}</version> <!-- can be omitted when using the BOM -->
+			<scope>test</scope>
+		</dependency>
+		<!-- ... -->
+	</dependencies>
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+			<plugin>
+				<artifactId>maven-failsafe-plugin</artifactId>
+				<version>{surefire-version}</version>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-filter-test-class-names]]
+===== Filtering by Test Class Names
+
+The Maven Surefire Plugin will scan for test classes whose fully qualified names match
+the following patterns.
+
+- `+++**/Test*.java+++`
+- `+++**/*Test.java+++`
+- `+++**/*Tests.java+++`
+- `+++**/*TestCase.java+++`
+
+Moreover, it will exclude all nested classes (including static member classes) by default.
+
+Note, however, that you can override this default behavior by configuring explicit
+`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
+from excluding static member classes, you can override its exclude rules as follows.
+
+[source,xml,indent=0]
+[subs=attributes+]
+.Overriding exclude rules of Maven Surefire
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<excludes>
+						<exclude/>
+					</excludes>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+Please see the
+https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
+documentation for Maven Surefire for details.
+
+[[running-tests-build-maven-filter-tags]]
+===== Filtering by Tags
+
+You can filter tests by <<running-tests-tags, tags>> or
+<<running-tests-tag-expressions, tag expressions>> using the following configuration
+properties.
+
+- to include _tags_ or _tag expressions_, use `groups`.
+- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<groups>acceptance | !feature-a</groups>
+					<excludedGroups>integration, regression</excludedGroups>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-maven-config-params]]
+===== Configuration Parameters
+
+You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
+influence test discovery and execution by declaring the `configurationParameters`
+property and providing key-value pairs using the Java `Properties` file syntax (as shown
+below) or via the `junit-platform.properties` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<!-- ... -->
+	<build>
+		<plugins>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<version>{surefire-version}</version>
+				<configuration>
+					<properties>
+						<configurationParameters>
+							junit.jupiter.conditions.deactivate = *
+							junit.jupiter.extensions.autodetection.enabled = true
+							junit.jupiter.testinstance.lifecycle.default = per_class
+						</configurationParameters>
+					</properties>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+	<!-- ... -->
+----
+
+[[running-tests-build-ant]]
+==== Ant
+
+Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
+provides native support for launching tests on the JUnit Platform. The `junitlauncher`
+task is solely responsible for launching the JUnit Platform and passing it the selected
+collection of tests. The JUnit Platform then delegates to registered test engines to
+discover and execute the tests.
+
+The `junitlauncher` task attempts to align as closely as possible with native Ant
+constructs such as
+link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
+for allowing users to select the tests that they want executed by test engines. This gives
+the task a consistent and natural feel when compared to many other core Ant tasks.
+
+Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
+
+The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
+the task and can serve as a starting point.
+
+===== Basic Usage
+
+The following example demonstrates how to configure the `junitlauncher` task to select a
+single test class (i.e., `com.example.project.CalculatorTests`).
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+
+	<!-- ... -->
+
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<test name="com.example.project.CalculatorTests" />
+	</junitlauncher>
+----
+
+The `test` element allows you to specify a single test class that you want to be selected
+and executed. The `classpath` element allows you to specify the classpath to be used to
+launch the JUnit Platform. This classpath will also be used to locate test classes that
+are part of the execution.
+
+The following example demonstrates how to configure the `junitlauncher` task to select
+test classes from multiple locations.
+
+[source,xml,indent=0]
+----
+	<path id="test.classpath">
+		<!-- The location where you have your compiled classes -->
+		<pathelement location="${build.classes.dir}" />
+	</path>
+	<!-- ... -->
+	<junitlauncher>
+		<classpath refid="test.classpath" />
+		<testclasses outputdir="${output.dir}">
+			<fileset dir="${build.classes.dir}">
+				<include name="org/example/**/demo/**/" />
+			</fileset>
+			<fileset dir="${some.other.dir}">
+				<include name="org/myapp/**/" />
+			</fileset>
+		</testclasses>
+	</junitlauncher>
+----
+
+In the above example, the `testclasses` element allows you to select multiple test
+classes that reside in different locations.
+
+For further details on usage and configuration options please refer to the official Ant
+documentation for the
+link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
+
+[[running-tests-build-spring-boot]]
+==== Spring Boot
+
+link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
+managing the version of JUnit used in your project. In addition, the
+`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
+Jupiter, AssertJ, Mockito, etc.
+
+If your build relies on dependency management support from Spring Boot, you should not
+import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
+result in duplicate (and potentially conflicting) management of JUnit dependencies.
+
+If you need to override the version of a dependency used in your Spring Boot application,
+you have to override the exact name of the
+link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
+defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
+Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
+changing a dependency version is documented for both
+link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
+and
+link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
+
+With Gradle you can override the JUnit Jupiter version by including the following in your
+`build.gradle` file.
+
+[source,groovy,indent=0]
+[subs=attributes+]
+----
+	ext['junit-jupiter.version'] = '{version}'
+----
+
+With Maven you can override the JUnit Jupiter version by including the following in your
+`pom.xml` file.
+
+[source,xml,indent=0]
+[subs=attributes+]
+----
+	<properties>
+		<junit-jupiter.version>{version}</junit-jupiter.version>
+	</properties>
+----
+
+[[running-tests-console-launcher]]
+=== Console Launcher
+
+The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
+Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
+Jupiter tests and print test execution results to the console.
+
+An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
+contains the contents of all of its dependencies is published in the {Maven_Central}
+repository under the
+https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
+directory. It contains the contents of the following artifacts:
+
+include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
+
+[NOTE]
+====
+Since the `junit-platform-console-standalone` JAR contains the contents of all of its
+dependencies, its Maven POM does not declare any dependencies.
+
+Furthermore, it is not very likely that you would need to include a dependency on the
+`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
+script. On the contrary, the executable `junit-platform-console-standalone` JAR is
+typically invoked directly from the command line or a shell script without a build script.
+
+If you need to declare dependencies in your build script on some of the artifacts
+contained in the `junit-platform-console-standalone` artifact, you should declare
+dependencies only on the JUnit artifacts that are used in your project. To simplify
+dependency management of JUnit artifacts in your build, you may wish to use the
+`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
+details.
+====
+
+You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
+standalone `ConsoleLauncher` as shown below.
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
+
+├─ JUnit Vintage
+│  └─ example.JUnit4Tests
+│     └─ standardJUnit4Test ✔
+└─ JUnit Jupiter
+   ├─ StandardTests
+   │  ├─ succeedingTest() ✔
+   │  └─ skippedTest() ↷ for demonstration purposes
+   └─ A special test case
+      ├─ Custom test name containing spaces ✔
+      ├─ ╯°□°)╯ ✔
+      └─ 😱 ✔
+
+Test run finished after 64 ms
+[         5 containers found      ]
+[         0 containers skipped    ]
+[         5 containers started    ]
+[         0 containers aborted    ]
+[         5 containers successful ]
+[         0 containers failed     ]
+[         6 tests found           ]
+[         1 tests skipped         ]
+[         5 tests started         ]
+[         0 tests aborted         ]
+[         5 tests successful      ]
+[         0 tests failed          ]
+----
+
+You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
+all jars in a directory):
+
+[source,console,subs=attributes+]
+----
+$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
+----
+
+[[running-tests-console-launcher-options]]
+==== Subcommands and Options
+
+The `{ConsoleLauncher}` provides the following subcommands:
+
+----
+include::{consoleLauncherOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-discovering-tests]]
+===== Discovering tests
+
+----
+include::{consoleLauncherDiscoverOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-executing-tests]]
+===== Executing tests
+
+.Exit Code
+NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
+All non-zero codes indicate an error of some sort. For example, status code `1`
+is returned if any containers or tests failed. If no tests are discovered and the
+`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
+with a status code of `2`. Unexpected or invalid user input yields a status code
+of `3`. An exit code of `-1` indicates an unspecified error condition.
+
+----
+include::{consoleLauncherExecuteOptionsFile}[]
+----
+
+[[running-tests-console-launcher-options-listing-test-engines]]
+===== Listing test engines
+
+----
+include::{consoleLauncherEnginesOptionsFile}[]
+----
+
+[[running-tests-console-launcher-argument-files]]
+==== Argument Files (@-files)
+
+On some platforms you may run into system limitations on the length of a command line when
+creating a command line with lots of options or with long arguments.
+
+The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
+are files that themselves contain arguments to be passed to the command. When the
+underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
+argument beginning with the character `@`, it expands the contents of that file into the
+argument list.
+
+The arguments within a file can be separated by spaces or newlines. If an argument
+contains embedded whitespace, the whole argument should be wrapped in double or single
+quotes -- for example, `"-f=My Files/Stuff.java"`.
+
+If the argument file does not exist or cannot be read, the argument will be treated
+literally and will not be removed. This will likely result in an "unmatched argument"
+error message. You can troubleshoot such errors by executing the command with the
+`picocli.trace` system property set to `DEBUG`.
+
+Multiple _@-files_ may be specified on the command line. The specified path may be
+relative to the current directory or absolute.
+
+You can pass a real parameter with an initial `@` character by escaping it with an
+additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
+subject to expansion.
+
+[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
+==== Redirecting Standard Output/Error to Files
+
+You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
+files using the `--redirect-stdout` and `--redirect-stderr` options:
+
+[source,console,subs=attributes+]
+----
+$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
+  --redirect-stdout=stdout.txt \
+  --redirect-stderr=stderr.txt
+----
+
+[NOTE]
+====
+If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
+output streams will be redirected to that file.
+
+The default charset is used for writing to the files.
+====
+
+[[running-tests-console-launcher-color-customization]]
+==== Color Customization
+
+The colors used in the output of the `{ConsoleLauncher}` can be customized.
+The option `--single-color` will apply a built-in monochrome style, while
+`--color-palette` will accept a properties file to override the
+https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
+The properties file below demonstrates the default style:
+
+[source,properties,indent=0]
+----
+SUCCESSFUL = 32
+ABORTED = 33
+FAILED = 31
+SKIPPED = 35
+CONTAINER = 35
+TEST = 34
+DYNAMIC = 35
+REPORTED = 37
+----
+
+[[running-tests-source-launcher]]
+=== Source Launcher
+
+Starting with Java 25 it is possible to write minimal source code test programs
+using the `org.junit.start` module. For example, like in a `HelloTests.java`
+file reading:
+
+```java
+import module org.junit.start;
+
+void main() {
+  JUnit.run();
+}
+
+@Test
+void stringLength() {
+  Assertions.assertEquals(11, "Hello JUnit".length());
+}
+```
+With all required modular JAR files available in a local `lib/` directory, the
+following Java 25+ command will discover and execute tests using the JUnit Platform.
+It will also print the result tree to the console.
+
+```shell
+java --module-path lib --add-modules org.junit.start HelloTests.java
+╷
+└─ JUnit Jupiter ✔
+   └─ HelloTests ✔
+      └─ stringLength() ✔
+```
+
+Find JUnit's class API documentation here: {JUnit}
+
+[[running-tests-discovery-selectors]]
+=== Discovery Selectors
+
+The JUnit Platform provides a rich set of discovery selectors that can be used to specify
+which tests should be discovered or executed.
+
+Discovery selectors can be created programmatically using the factory methods in the
+`{DiscoverySelectors}` class, specified declaratively via annotations when using the
+<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
+generically as strings via their identifiers.
+
+The following discovery selectors are provided out of the box:
+
+|===
+| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
+
+| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
+| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
+| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
+| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
+| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
+| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
+| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
+| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
+| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
+| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
+| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
+| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
+| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
+|===
+
+
+[[running-tests-config-params]]
+=== Configuration Parameters
+
+In addition to instructing the platform which test classes and test engines to include,
+which packages to scan, etc., it is sometimes necessary to provide additional custom
+configuration parameters that are specific to a particular test engine, listener, or
+registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
+parameters_ for the following use cases.
+
+- <<writing-tests-test-instance-lifecycle-changing-default>>
+- <<extensions-registration-automatic-enabling>>
+- <<extensions-conditions-deactivation>>
+- <<writing-tests-display-name-generator-default>>
+
+_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
+engines running on the JUnit Platform via one of the following mechanisms.
+
+1. The `configurationParameter()` and `configurationParameters()` methods in
+   `LauncherDiscoveryRequestBuilder` which
+   is used to build a request supplied to the <<launcher-api, Launcher API>>.
+    +
+   When running tests via one of the tools provided by the JUnit Platform you can specify
+   configuration parameters as follows:
+   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
+     option.
+   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
+     `systemProperties` DSL.
+   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
+     `configurationParameters` property.
+2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
+    +
+   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
+   specify custom configuration files using the `--config-resource` command-line option.
+3. JVM system properties.
+4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
+   in the root of the class path that follows the syntax rules for Java `Properties`
+   files.
+
+NOTE: Configuration parameters are looked up in the exact order defined above.
+Consequently, configuration parameters supplied directly to the `Launcher` take
+precedence over those supplied via custom configuration files, system properties, and the
+default configuration file. Similarly, configuration parameters supplied via system
+properties take precedence over those supplied via the default configuration file.
+
+[[running-tests-config-params-deactivation-pattern]]
+==== Pattern Matching Syntax
+
+This section describes the pattern matching syntax that is applied to the _configuration
+parameters_ used for the following features.
+
+- <<extensions-conditions-deactivation>>
+- <<launcher-api-listeners-custom-deactivation>>
+- <<stacktrace-pruning>>
+- <<extensions-registration-automatic-filtering>>
+
+If the value for the given _configuration parameter_ consists solely of an asterisk
+(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
+will be treated as a comma-separated list of patterns where each pattern will be matched
+against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
+a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
+(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
+pattern will be matched one-to-one against a FQCN.
+
+Examples:
+
+- `+++*+++`: matches all candidate classes.
+- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
+  any of its subpackages.
+- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
+  `MyCustomImpl`.
+- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
+- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
+  `System` or `Unit`.
+- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
+  `org.example.MyCustomImpl`.
+- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
+  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
+
+[[running-tests-tags]]
+=== Tags
+
+Tags are a JUnit Platform concept for marking and filtering tests. The programming model
+for adding tags to containers and tests is defined by the testing framework. For example,
+in JUnit Jupiter based tests, the `@Tag` annotation (see
+<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
+Vintage engine maps `@Category` annotations to tags (see
+<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
+own annotation or other means for users to specify tags.
+
+[[running-tests-tag-syntax-rules]]
+==== Syntax Rules for Tags
+
+Regardless how a tag is specified, the JUnit Platform enforces the following rules:
+
+* A tag must not be `null` or _blank_.
+* A _stripped_ tag must not contain whitespace.
+* A _stripped_ tag must not contain ISO control characters.
+* A _stripped_ tag must not contain any of the following _reserved characters_.
+- `,`: _comma_
+- `(`: _left parenthesis_
+- `)`: _right parenthesis_
+- `&`: _ampersand_
+- `|`: _vertical bar_
+- `!`: _exclamation point_
+
+NOTE: In the above context, "stripped" means that leading and trailing whitespace
+characters have been removed using `java.lang.String.strip()`.
+
+[[running-tests-tag-expressions]]
+==== Tag Expressions
+
+Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
+`(` and `)` can be used to adjust for operator precedence.
+
+Two special expressions are supported, `any()` and `none()`, which select all tests _with_
+any tags at all, and all tests _without_ any tags, respectively.
+These special expressions may be combined with other expressions just like normal tags.
+
+.Operators (in descending order of precedence)
+|===
+| Operator | Meaning | Associativity
+
+| `!`      | not     | right
+| `&`      | and     | left
+| `\|`     | or      | left
+|===
+
+If you are tagging your tests across multiple dimensions, tag expressions help you to
+select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
+_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
+expressions can be useful.
+
+[%header,cols="40,60"]
+|===
+| Tag Expression
+| Selection
+
+| `+++product+++`
+| all tests for *product*
+
+| `+++catalog \| shipping+++`
+| all tests for *catalog* plus all tests for *shipping*
+
+| `+++catalog &amp; shipping+++`
+| all tests for the intersection between *catalog* and *shipping*
+
+| `+++product &amp; !end-to-end+++`
+| all tests for *product*, but not the _end-to-end_ tests
+
+| `+++(micro \| integration) &amp; (product \| shipping)+++`
+| all _micro_ or _integration_ tests for *product* or *shipping*
+|===
+
+[[running-tests-capturing-output]]
+=== Capturing Standard Output/Error
+
+The JUnit Platform provides opt-in support for capturing output printed to `System.out`
+and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
+`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
+parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
+to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
+
+If enabled, the JUnit Platform captures the corresponding output and publishes it as a
+report entry using the `stdout` or `stderr` keys to all registered
+`{TestExecutionListener}` instances immediately before reporting the test or container as
+finished.
+
+Please note that the captured output will only contain output emitted by the thread that
+was used to execute a container or test. Any output by other threads will be omitted
+because particularly when
+<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
+to attribute it to a specific test or container.
+
+[[running-tests-listeners]]
+=== Using Listeners and Interceptors
+
+The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
+and custom user code to react to events fired at various points during the discovery and
+execution of a `TestPlan`.
+
+* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
+  closed.
+* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
+  `LauncherSession`.
+* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
+* `{TestExecutionListener}`: receives events that occur during test execution.
+
+The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
+registered automatically for you in order to support some feature of the build tool or IDE.
+
+The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
+order to produce some form of report or to display a graphical representation of the test
+plan in an IDE. Such listeners may be implemented and automatically registered by a build
+tool or IDE, or they may be included in a third-party library – potentially registered
+for you automatically. You can also implement and register your own listeners.
+
+For details on registering and configuring listeners, see the following sections of this
+guide.
+
+* <<launcher-api-launcher-session-listeners-custom>>
+* <<launcher-api-launcher-interceptors-custom>>
+* <<launcher-api-launcher-discovery-listeners-custom>>
+* <<launcher-api-listeners-custom>>
+* <<launcher-api-listeners-config>>
+* <<launcher-api-listeners-custom-deactivation>>
+
+The JUnit Platform provides the following listeners which you may wish to use with your
+test suite.
+
+<<junit-platform-reporting>> ::
+  `{LegacyXmlReportGeneratingListener}` can be used via the
+  <<running-tests-console-launcher>> or registered manually to generate XML reports
+  compatible with the de facto standard for JUnit 4 based test reports.
++
+`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
+specified by {OpenTestReporting}. It is auto-registered and can be enabled and
+configured via <<running-tests-config-params>>.
++
+See <<junit-platform-reporting>> for details.
+
+<<running-tests-listeners-flight-recorder>> ::
+  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
+  Java Flight Recorder events during test discovery and execution.
+
+`{LoggingListener}` ::
+  `TestExecutionListener` for logging informational messages for all events via a
+  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
+
+`{SummaryGeneratingListener}` ::
+  `TestExecutionListener` that generates a summary of the test execution which can be
+  printed via a `PrintWriter`.
+
+`{UniqueIdTrackingListener}` ::
+  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
+  or executed during the execution of the `TestPlan` and generates a file containing the
+  unique IDs once execution of the `TestPlan` has finished.
+
+[[running-tests-listeners-flight-recorder]]
+==== Flight Recorder Support
+
+The JUnit Platform provides opt-in support for generating Flight Recorder events.
+https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
+follows.
+
+> Flight Recorder records events originating from applications, the JVM, and the OS.
+Events are stored in a single file that can be attached to bug reports and examined by
+support engineers, allowing after-the-fact analysis of issues in the period leading up
+to a problem.
+
+In order to record Flight Recorder events generated while running tests, you need to
+start flight recording when launching a test suite via the following java command line
+option.
+
+   -XX:StartFlightRecording:filename=...
+
+Please consult the manual of your build tool for the appropriate commands.
+
+To analyze the recorded events, use the
+https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
+command line tool shipped with recent JDKs or open the recording file with
+https://jdk.java.net/jmc/[JDK Mission Control].
+
+[[stacktrace-pruning]]
+=== Stack Trace Pruning
+
+The JUnit Platform provides built-in support for pruning stack traces produced by failing
+tests. This feature is enabled by default but can be disabled by setting the
+`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
+
+When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
+packages are removed from the stack trace, unless the calls occur after the test itself
+or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
+never be excluded.
+
+In addition, all elements prior to and including the first call from the JUnit Platform
+`Launcher` will be removed.
+
+[[running-tests-discovery-issues]]
+=== Discovery Issues
+
+Test engines may encounter issues during test discovery. For example, the declaration of a
+test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
+Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
+report them with different severity levels:
+
+INFO::
+Indicates that the engine encountered something that could be potentially problematic, but
+could also happen due to a valid setup or configuration.
+
+WARNING::
+Indicates that the engine encountered something that is problematic and might lead to
+unexpected behavior or will be removed or changed in a future release.
+
+ERROR::
+Indicates that the engine encountered something that is definitely problematic and will
+lead to unexpected behavior.
+
+If an engine reports an issue with a severity equal to or higher than a configurable
+_critical_ severity, its tests will not be executed. Instead, the engine will be reported
+as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
+Non-critical issues will be logged but will not prevent the engine from executing its
+tests. The `junit.platform.discovery.issue.severity.critical`
+<<running-tests-config-params, configuration parameter>> can be used to set the critical
+severity level. Currently, the default value is `ERROR` but it may be changed in a future
+release.
+
+TIP: To surface all discovery issues in your project, it is recommended to set the
+`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
+
+In addition, registered `{LauncherDiscoveryListener}` implementations can receive
+discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
+report issues to the user in a more user-friendly way. For example, IDEs may choose to
+display all issues in a list or table.

From ce6b2b844015ce70e11723bfd8d0135ac9ac2f0d Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:11 +0100
Subject: [PATCH 24/57] Migrate running-tests.adoc sections to Antora

---
 .../pages/running-tests/build-support.adoc    |  667 ---------
 .../capturing-standard-output-error.adoc      | 1196 ----------------
 .../configuration-parameters.adoc             | 1138 ----------------
 .../pages/running-tests/console-launcher.adoc | 1033 --------------
 .../pages/running-tests/discovery-issues.adoc | 1180 ----------------
 .../running-tests/discovery-selectors.adoc    | 1184 ----------------
 .../ROOT/pages/running-tests/ide-support.adoc | 1113 ---------------
 .../ROOT/pages/running-tests/intro.adoc       | 1213 -----------------
 .../pages/running-tests/source-launcher.adoc  | 1183 ----------------
 .../running-tests/stack-trace-pruning.adoc    | 1201 ----------------
 .../ROOT/pages/running-tests/tags.adoc        | 1141 ----------------
 .../using-listeners-and-interceptors.adoc     | 1127 ---------------
 12 files changed, 13376 deletions(-)

diff --git a/documentation/modules/ROOT/pages/running-tests/build-support.adoc b/documentation/modules/ROOT/pages/running-tests/build-support.adoc
index 3099a146c2b4..46ab1eebb6d4 100644
--- a/documentation/modules/ROOT/pages/running-tests/build-support.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/build-support.adoc
@@ -1,109 +1,3 @@
-[[running-tests]]
-== Running Tests
-
-[[running-tests-ide]]
-=== IDE Support
-
-[[running-tests-ide-intellij-idea]]
-==== IntelliJ IDEA
-
-IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
-information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
-however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
-IDEA download the following JARs automatically based on the API version used in the
-project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
-
-In order to use a different JUnit version (e.g., {version}), you may need to
-include the corresponding versions of the `junit-platform-launcher`,
-`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
-
-.Additional Gradle Dependencies
-[source,groovy]
-[subs=attributes+]
-----
-testImplementation(platform("org.junit:junit-bom:{version}"))
-testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
-testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
-----
-
-.Additional Maven Dependencies
-[source,xml]
-[subs=attributes+]
-----
-<!-- ... -->
-<dependencies>
-	<dependency>
-		<groupId>org.junit.platform</groupId>
-		<artifactId>junit-platform-launcher</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.jupiter</groupId>
-		<artifactId>junit-jupiter-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.vintage</groupId>
-		<artifactId>junit-vintage-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-</dependencies>
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-[[running-tests-ide-eclipse]]
-==== Eclipse
-
-Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
-release.
-
-For more information on using JUnit Platform in Eclipse consult the official _Eclipse
-support for JUnit 5_ section of the
-https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
-(4.7.1a) - New and Noteworthy] documentation.
-
-[[running-tests-ide-netbeans]]
-==== NetBeans
-
-NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
-https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
-
-For more information consult the JUnit 5 section of the
-https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
-release notes].
-
-[[running-tests-ide-vscode]]
-==== Visual Studio Code
-
-https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
-Platform via the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
-Runner] extension which is installed by default as part of the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
-Extension Pack].
-
-For more information consult the _Testing_ section of the
-https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
-documentation.
-
-[[running-tests-ide-other]]
-==== Other IDEs
-
-If you are using an editor or IDE other than one of those listed in the previous sections,
-and it doesn't support running tests on the JUnit Platform, you can use the
-<<running-tests-console-launcher>> to run them from the command line.
-
 [[running-tests-build]]
 === Build Support
 
@@ -653,564 +547,3 @@ With Maven you can override the JUnit Jupiter version by including the following
 	</properties>
 ----
 
-[[running-tests-console-launcher]]
-=== Console Launcher
-
-The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
-Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
-Jupiter tests and print test execution results to the console.
-
-An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
-contains the contents of all of its dependencies is published in the {Maven_Central}
-repository under the
-https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
-directory. It contains the contents of the following artifacts:
-
-include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
-
-[NOTE]
-====
-Since the `junit-platform-console-standalone` JAR contains the contents of all of its
-dependencies, its Maven POM does not declare any dependencies.
-
-Furthermore, it is not very likely that you would need to include a dependency on the
-`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
-script. On the contrary, the executable `junit-platform-console-standalone` JAR is
-typically invoked directly from the command line or a shell script without a build script.
-
-If you need to declare dependencies in your build script on some of the artifacts
-contained in the `junit-platform-console-standalone` artifact, you should declare
-dependencies only on the JUnit artifacts that are used in your project. To simplify
-dependency management of JUnit artifacts in your build, you may wish to use the
-`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
-details.
-====
-
-You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
-standalone `ConsoleLauncher` as shown below.
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
-
-├─ JUnit Vintage
-│  └─ example.JUnit4Tests
-│     └─ standardJUnit4Test ✔
-└─ JUnit Jupiter
-   ├─ StandardTests
-   │  ├─ succeedingTest() ✔
-   │  └─ skippedTest() ↷ for demonstration purposes
-   └─ A special test case
-      ├─ Custom test name containing spaces ✔
-      ├─ ╯°□°)╯ ✔
-      └─ 😱 ✔
-
-Test run finished after 64 ms
-[         5 containers found      ]
-[         0 containers skipped    ]
-[         5 containers started    ]
-[         0 containers aborted    ]
-[         5 containers successful ]
-[         0 containers failed     ]
-[         6 tests found           ]
-[         1 tests skipped         ]
-[         5 tests started         ]
-[         0 tests aborted         ]
-[         5 tests successful      ]
-[         0 tests failed          ]
-----
-
-You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
-all jars in a directory):
-
-[source,console,subs=attributes+]
-----
-$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
-----
-
-[[running-tests-console-launcher-options]]
-==== Subcommands and Options
-
-The `{ConsoleLauncher}` provides the following subcommands:
-
-----
-include::{consoleLauncherOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-discovering-tests]]
-===== Discovering tests
-
-----
-include::{consoleLauncherDiscoverOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-executing-tests]]
-===== Executing tests
-
-.Exit Code
-NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
-All non-zero codes indicate an error of some sort. For example, status code `1`
-is returned if any containers or tests failed. If no tests are discovered and the
-`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
-with a status code of `2`. Unexpected or invalid user input yields a status code
-of `3`. An exit code of `-1` indicates an unspecified error condition.
-
-----
-include::{consoleLauncherExecuteOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-listing-test-engines]]
-===== Listing test engines
-
-----
-include::{consoleLauncherEnginesOptionsFile}[]
-----
-
-[[running-tests-console-launcher-argument-files]]
-==== Argument Files (@-files)
-
-On some platforms you may run into system limitations on the length of a command line when
-creating a command line with lots of options or with long arguments.
-
-The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
-are files that themselves contain arguments to be passed to the command. When the
-underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
-argument beginning with the character `@`, it expands the contents of that file into the
-argument list.
-
-The arguments within a file can be separated by spaces or newlines. If an argument
-contains embedded whitespace, the whole argument should be wrapped in double or single
-quotes -- for example, `"-f=My Files/Stuff.java"`.
-
-If the argument file does not exist or cannot be read, the argument will be treated
-literally and will not be removed. This will likely result in an "unmatched argument"
-error message. You can troubleshoot such errors by executing the command with the
-`picocli.trace` system property set to `DEBUG`.
-
-Multiple _@-files_ may be specified on the command line. The specified path may be
-relative to the current directory or absolute.
-
-You can pass a real parameter with an initial `@` character by escaping it with an
-additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
-subject to expansion.
-
-[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
-==== Redirecting Standard Output/Error to Files
-
-You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
-files using the `--redirect-stdout` and `--redirect-stderr` options:
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
-  --redirect-stdout=stdout.txt \
-  --redirect-stderr=stderr.txt
-----
-
-[NOTE]
-====
-If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
-output streams will be redirected to that file.
-
-The default charset is used for writing to the files.
-====
-
-[[running-tests-console-launcher-color-customization]]
-==== Color Customization
-
-The colors used in the output of the `{ConsoleLauncher}` can be customized.
-The option `--single-color` will apply a built-in monochrome style, while
-`--color-palette` will accept a properties file to override the
-https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
-The properties file below demonstrates the default style:
-
-[source,properties,indent=0]
-----
-SUCCESSFUL = 32
-ABORTED = 33
-FAILED = 31
-SKIPPED = 35
-CONTAINER = 35
-TEST = 34
-DYNAMIC = 35
-REPORTED = 37
-----
-
-[[running-tests-source-launcher]]
-=== Source Launcher
-
-Starting with Java 25 it is possible to write minimal source code test programs
-using the `org.junit.start` module. For example, like in a `HelloTests.java`
-file reading:
-
-```java
-import module org.junit.start;
-
-void main() {
-  JUnit.run();
-}
-
-@Test
-void stringLength() {
-  Assertions.assertEquals(11, "Hello JUnit".length());
-}
-```
-With all required modular JAR files available in a local `lib/` directory, the
-following Java 25+ command will discover and execute tests using the JUnit Platform.
-It will also print the result tree to the console.
-
-```shell
-java --module-path lib --add-modules org.junit.start HelloTests.java
-╷
-└─ JUnit Jupiter ✔
-   └─ HelloTests ✔
-      └─ stringLength() ✔
-```
-
-Find JUnit's class API documentation here: {JUnit}
-
-[[running-tests-discovery-selectors]]
-=== Discovery Selectors
-
-The JUnit Platform provides a rich set of discovery selectors that can be used to specify
-which tests should be discovered or executed.
-
-Discovery selectors can be created programmatically using the factory methods in the
-`{DiscoverySelectors}` class, specified declaratively via annotations when using the
-<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
-generically as strings via their identifiers.
-
-The following discovery selectors are provided out of the box:
-
-|===
-| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
-
-| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
-| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
-| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
-| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
-| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
-| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
-| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
-| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
-| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
-| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
-| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
-| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
-| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
-|===
-
-
-[[running-tests-config-params]]
-=== Configuration Parameters
-
-In addition to instructing the platform which test classes and test engines to include,
-which packages to scan, etc., it is sometimes necessary to provide additional custom
-configuration parameters that are specific to a particular test engine, listener, or
-registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
-parameters_ for the following use cases.
-
-- <<writing-tests-test-instance-lifecycle-changing-default>>
-- <<extensions-registration-automatic-enabling>>
-- <<extensions-conditions-deactivation>>
-- <<writing-tests-display-name-generator-default>>
-
-_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
-engines running on the JUnit Platform via one of the following mechanisms.
-
-1. The `configurationParameter()` and `configurationParameters()` methods in
-   `LauncherDiscoveryRequestBuilder` which
-   is used to build a request supplied to the <<launcher-api, Launcher API>>.
-    +
-   When running tests via one of the tools provided by the JUnit Platform you can specify
-   configuration parameters as follows:
-   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
-     option.
-   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
-     `systemProperties` DSL.
-   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
-     `configurationParameters` property.
-2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
-    +
-   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
-   specify custom configuration files using the `--config-resource` command-line option.
-3. JVM system properties.
-4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
-   in the root of the class path that follows the syntax rules for Java `Properties`
-   files.
-
-NOTE: Configuration parameters are looked up in the exact order defined above.
-Consequently, configuration parameters supplied directly to the `Launcher` take
-precedence over those supplied via custom configuration files, system properties, and the
-default configuration file. Similarly, configuration parameters supplied via system
-properties take precedence over those supplied via the default configuration file.
-
-[[running-tests-config-params-deactivation-pattern]]
-==== Pattern Matching Syntax
-
-This section describes the pattern matching syntax that is applied to the _configuration
-parameters_ used for the following features.
-
-- <<extensions-conditions-deactivation>>
-- <<launcher-api-listeners-custom-deactivation>>
-- <<stacktrace-pruning>>
-- <<extensions-registration-automatic-filtering>>
-
-If the value for the given _configuration parameter_ consists solely of an asterisk
-(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
-will be treated as a comma-separated list of patterns where each pattern will be matched
-against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
-a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
-(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
-pattern will be matched one-to-one against a FQCN.
-
-Examples:
-
-- `+++*+++`: matches all candidate classes.
-- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
-  any of its subpackages.
-- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
-  `MyCustomImpl`.
-- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
-- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
-  `System` or `Unit`.
-- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
-  `org.example.MyCustomImpl`.
-- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
-  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
-
-[[running-tests-tags]]
-=== Tags
-
-Tags are a JUnit Platform concept for marking and filtering tests. The programming model
-for adding tags to containers and tests is defined by the testing framework. For example,
-in JUnit Jupiter based tests, the `@Tag` annotation (see
-<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
-Vintage engine maps `@Category` annotations to tags (see
-<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
-own annotation or other means for users to specify tags.
-
-[[running-tests-tag-syntax-rules]]
-==== Syntax Rules for Tags
-
-Regardless how a tag is specified, the JUnit Platform enforces the following rules:
-
-* A tag must not be `null` or _blank_.
-* A _stripped_ tag must not contain whitespace.
-* A _stripped_ tag must not contain ISO control characters.
-* A _stripped_ tag must not contain any of the following _reserved characters_.
-- `,`: _comma_
-- `(`: _left parenthesis_
-- `)`: _right parenthesis_
-- `&`: _ampersand_
-- `|`: _vertical bar_
-- `!`: _exclamation point_
-
-NOTE: In the above context, "stripped" means that leading and trailing whitespace
-characters have been removed using `java.lang.String.strip()`.
-
-[[running-tests-tag-expressions]]
-==== Tag Expressions
-
-Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
-`(` and `)` can be used to adjust for operator precedence.
-
-Two special expressions are supported, `any()` and `none()`, which select all tests _with_
-any tags at all, and all tests _without_ any tags, respectively.
-These special expressions may be combined with other expressions just like normal tags.
-
-.Operators (in descending order of precedence)
-|===
-| Operator | Meaning | Associativity
-
-| `!`      | not     | right
-| `&`      | and     | left
-| `\|`     | or      | left
-|===
-
-If you are tagging your tests across multiple dimensions, tag expressions help you to
-select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
-_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
-expressions can be useful.
-
-[%header,cols="40,60"]
-|===
-| Tag Expression
-| Selection
-
-| `+++product+++`
-| all tests for *product*
-
-| `+++catalog \| shipping+++`
-| all tests for *catalog* plus all tests for *shipping*
-
-| `+++catalog &amp; shipping+++`
-| all tests for the intersection between *catalog* and *shipping*
-
-| `+++product &amp; !end-to-end+++`
-| all tests for *product*, but not the _end-to-end_ tests
-
-| `+++(micro \| integration) &amp; (product \| shipping)+++`
-| all _micro_ or _integration_ tests for *product* or *shipping*
-|===
-
-[[running-tests-capturing-output]]
-=== Capturing Standard Output/Error
-
-The JUnit Platform provides opt-in support for capturing output printed to `System.out`
-and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
-`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
-parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
-to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
-
-If enabled, the JUnit Platform captures the corresponding output and publishes it as a
-report entry using the `stdout` or `stderr` keys to all registered
-`{TestExecutionListener}` instances immediately before reporting the test or container as
-finished.
-
-Please note that the captured output will only contain output emitted by the thread that
-was used to execute a container or test. Any output by other threads will be omitted
-because particularly when
-<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
-to attribute it to a specific test or container.
-
-[[running-tests-listeners]]
-=== Using Listeners and Interceptors
-
-The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
-and custom user code to react to events fired at various points during the discovery and
-execution of a `TestPlan`.
-
-* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
-  closed.
-* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
-  `LauncherSession`.
-* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
-* `{TestExecutionListener}`: receives events that occur during test execution.
-
-The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
-registered automatically for you in order to support some feature of the build tool or IDE.
-
-The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
-order to produce some form of report or to display a graphical representation of the test
-plan in an IDE. Such listeners may be implemented and automatically registered by a build
-tool or IDE, or they may be included in a third-party library – potentially registered
-for you automatically. You can also implement and register your own listeners.
-
-For details on registering and configuring listeners, see the following sections of this
-guide.
-
-* <<launcher-api-launcher-session-listeners-custom>>
-* <<launcher-api-launcher-interceptors-custom>>
-* <<launcher-api-launcher-discovery-listeners-custom>>
-* <<launcher-api-listeners-custom>>
-* <<launcher-api-listeners-config>>
-* <<launcher-api-listeners-custom-deactivation>>
-
-The JUnit Platform provides the following listeners which you may wish to use with your
-test suite.
-
-<<junit-platform-reporting>> ::
-  `{LegacyXmlReportGeneratingListener}` can be used via the
-  <<running-tests-console-launcher>> or registered manually to generate XML reports
-  compatible with the de facto standard for JUnit 4 based test reports.
-+
-`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
-specified by {OpenTestReporting}. It is auto-registered and can be enabled and
-configured via <<running-tests-config-params>>.
-+
-See <<junit-platform-reporting>> for details.
-
-<<running-tests-listeners-flight-recorder>> ::
-  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
-  Java Flight Recorder events during test discovery and execution.
-
-`{LoggingListener}` ::
-  `TestExecutionListener` for logging informational messages for all events via a
-  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
-
-`{SummaryGeneratingListener}` ::
-  `TestExecutionListener` that generates a summary of the test execution which can be
-  printed via a `PrintWriter`.
-
-`{UniqueIdTrackingListener}` ::
-  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
-  or executed during the execution of the `TestPlan` and generates a file containing the
-  unique IDs once execution of the `TestPlan` has finished.
-
-[[running-tests-listeners-flight-recorder]]
-==== Flight Recorder Support
-
-The JUnit Platform provides opt-in support for generating Flight Recorder events.
-https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
-follows.
-
-> Flight Recorder records events originating from applications, the JVM, and the OS.
-Events are stored in a single file that can be attached to bug reports and examined by
-support engineers, allowing after-the-fact analysis of issues in the period leading up
-to a problem.
-
-In order to record Flight Recorder events generated while running tests, you need to
-start flight recording when launching a test suite via the following java command line
-option.
-
-   -XX:StartFlightRecording:filename=...
-
-Please consult the manual of your build tool for the appropriate commands.
-
-To analyze the recorded events, use the
-https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
-command line tool shipped with recent JDKs or open the recording file with
-https://jdk.java.net/jmc/[JDK Mission Control].
-
-[[stacktrace-pruning]]
-=== Stack Trace Pruning
-
-The JUnit Platform provides built-in support for pruning stack traces produced by failing
-tests. This feature is enabled by default but can be disabled by setting the
-`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
-
-When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
-packages are removed from the stack trace, unless the calls occur after the test itself
-or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
-never be excluded.
-
-In addition, all elements prior to and including the first call from the JUnit Platform
-`Launcher` will be removed.
-
-[[running-tests-discovery-issues]]
-=== Discovery Issues
-
-Test engines may encounter issues during test discovery. For example, the declaration of a
-test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
-Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
-report them with different severity levels:
-
-INFO::
-Indicates that the engine encountered something that could be potentially problematic, but
-could also happen due to a valid setup or configuration.
-
-WARNING::
-Indicates that the engine encountered something that is problematic and might lead to
-unexpected behavior or will be removed or changed in a future release.
-
-ERROR::
-Indicates that the engine encountered something that is definitely problematic and will
-lead to unexpected behavior.
-
-If an engine reports an issue with a severity equal to or higher than a configurable
-_critical_ severity, its tests will not be executed. Instead, the engine will be reported
-as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
-Non-critical issues will be logged but will not prevent the engine from executing its
-tests. The `junit.platform.discovery.issue.severity.critical`
-<<running-tests-config-params, configuration parameter>> can be used to set the critical
-severity level. Currently, the default value is `ERROR` but it may be changed in a future
-release.
-
-TIP: To surface all discovery issues in your project, it is recommended to set the
-`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
-
-In addition, registered `{LauncherDiscoveryListener}` implementations can receive
-discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
-report issues to the user in a more user-friendly way. For example, IDEs may choose to
-display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc b/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc
index 3099a146c2b4..a74e8fec7b6c 100644
--- a/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc
@@ -1,1059 +1,3 @@
-[[running-tests]]
-== Running Tests
-
-[[running-tests-ide]]
-=== IDE Support
-
-[[running-tests-ide-intellij-idea]]
-==== IntelliJ IDEA
-
-IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
-information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
-however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
-IDEA download the following JARs automatically based on the API version used in the
-project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
-
-In order to use a different JUnit version (e.g., {version}), you may need to
-include the corresponding versions of the `junit-platform-launcher`,
-`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
-
-.Additional Gradle Dependencies
-[source,groovy]
-[subs=attributes+]
-----
-testImplementation(platform("org.junit:junit-bom:{version}"))
-testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
-testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
-----
-
-.Additional Maven Dependencies
-[source,xml]
-[subs=attributes+]
-----
-<!-- ... -->
-<dependencies>
-	<dependency>
-		<groupId>org.junit.platform</groupId>
-		<artifactId>junit-platform-launcher</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.jupiter</groupId>
-		<artifactId>junit-jupiter-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.vintage</groupId>
-		<artifactId>junit-vintage-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-</dependencies>
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-[[running-tests-ide-eclipse]]
-==== Eclipse
-
-Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
-release.
-
-For more information on using JUnit Platform in Eclipse consult the official _Eclipse
-support for JUnit 5_ section of the
-https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
-(4.7.1a) - New and Noteworthy] documentation.
-
-[[running-tests-ide-netbeans]]
-==== NetBeans
-
-NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
-https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
-
-For more information consult the JUnit 5 section of the
-https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
-release notes].
-
-[[running-tests-ide-vscode]]
-==== Visual Studio Code
-
-https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
-Platform via the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
-Runner] extension which is installed by default as part of the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
-Extension Pack].
-
-For more information consult the _Testing_ section of the
-https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
-documentation.
-
-[[running-tests-ide-other]]
-==== Other IDEs
-
-If you are using an editor or IDE other than one of those listed in the previous sections,
-and it doesn't support running tests on the JUnit Platform, you can use the
-<<running-tests-console-launcher>> to run them from the command line.
-
-[[running-tests-build]]
-=== Build Support
-
-[[running-tests-build-gradle]]
-==== Gradle
-
-Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
-https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
-for executing tests on the JUnit Platform. To enable it, you need to specify
-`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform()
-}
-----
-
-Filtering by <<running-tests-tags, tags>>,
-<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform {
-		includeTags("fast", "smoke & feature-a")
-		// excludeTags("slow", "ci")
-		includeEngines("junit-jupiter")
-		// excludeEngines("junit-vintage")
-	}
-}
-----
-
-Please refer to the
-https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
-for a comprehensive list of options.
-
-[[running-tests-build-gradle-bom]]
-===== Aligning dependency versions
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Explicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation(platform("org.junit:junit-bom:{version}"))
-	testImplementation("org.junit.jupiter:junit-jupiter")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-Since all JUnit artifacts declare a
-https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
-you usually don't need to declare an explicit dependency on it yourself. Instead, it's
-sufficient to declare _one_ regular dependency that includes a version number. Gradle will
-then pull in the BOM automatically so you can omit the version for all other JUnit
-artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Implicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
-}
-----
-<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
-<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
-
-[WARNING]
-.Declaring a dependency on junit-platform-launcher
-====
-Even though pre-8.0 versions of Gradle don't require declaring an explicit
-dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
-of JUnit artifacts on the test runtime classpath are aligned.
-
-Moreover, doing so is recommended and in some cases even required when importing the
-project into an IDE like <<running-tests-ide-eclipse>> or
-<<running-tests-ide-intellij-idea>>.
-====
-
-[[running-tests-build-gradle-engines-configure]]
-===== Configuring Test Engines
-
-In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
-
-To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
-on the dependency-aggregating JUnit Jupiter artifact similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Alternatively, you can use Gradle's
-https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
-support.
-
-[source,kotlin,indent=0]
-[subs=attributes+]
-.Kotlin DSL
-----
-testing {
-	suites {
-		named<JvmTestSuite>("test") {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Groovy DSL
-----
-testing {
-	suites {
-		test {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
-dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
-implementation similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("junit:junit:{junit4-version}")
-	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-[[running-tests-build-gradle-config-params]]
-===== Configuration Parameters
-
-The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
-Platform <<running-tests-config-params, configuration parameters>> to influence test
-discovery and execution. However, you can provide configuration parameters within the
-build script via system properties (as shown below) or via the
-`junit-platform.properties` file.
-
-[source,groovy,indent=0]
-----
-test {
-	// ...
-	systemProperty("junit.jupiter.conditions.deactivate", "*")
-	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
-	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
-	// ...
-}
-----
-
-[[running-tests-build-gradle-logging]]
-===== Configuring Logging (optional)
-
-JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
-emit warnings and debug information. Please refer to the official documentation of
-`{LogManager}` for configuration options.
-
-Alternatively, it's possible to redirect log messages to other logging frameworks such as
-{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
-`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
-qualified class name_ of the `{LogManager}` implementation to use. The example below
-demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
-details).
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
-	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
-	systemProperty("log4j2.disableJmx", "true")
-}
-----
-
-Other logging frameworks provide different means to redirect messages logged using
-`java.util.logging`. For example, for {Logback} you can use the
-https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
-dependency to the test runtime classpath.
-
-[[running-tests-build-maven]]
-==== Maven
-
-Maven Surefire and Maven Failsafe provide
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
-for executing tests on the JUnit Platform. The `pom.xml` file in the
-`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
-and can serve as a starting point for configuring your Maven build.
-
-[WARNING]
-.Minimum required version of Maven Surefire/Failsafe
-====
-As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
-====
-
-[[running-tests-build-maven-bom]]
-===== Aligning dependency versions
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-[[running-tests-build-maven-engines-configure]]
-===== Configuring Test Engines
-
-In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
-`TestEngine` implementation must be added to the test classpath.
-
-To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
-on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
-following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>org.junit.jupiter</groupId>
-			<artifactId>junit-jupiter</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
-long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
-`TestEngine` implementation similar to the following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>junit</groupId>
-			<artifactId>junit</artifactId>
-			<version>{junit4-version}</version>
-			<scope>test</scope>
-		</dependency>
-		<dependency>
-			<groupId>org.junit.vintage</groupId>
-			<artifactId>junit-vintage-engine</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-filter-test-class-names]]
-===== Filtering by Test Class Names
-
-The Maven Surefire Plugin will scan for test classes whose fully qualified names match
-the following patterns.
-
-- `+++**/Test*.java+++`
-- `+++**/*Test.java+++`
-- `+++**/*Tests.java+++`
-- `+++**/*TestCase.java+++`
-
-Moreover, it will exclude all nested classes (including static member classes) by default.
-
-Note, however, that you can override this default behavior by configuring explicit
-`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
-from excluding static member classes, you can override its exclude rules as follows.
-
-[source,xml,indent=0]
-[subs=attributes+]
-.Overriding exclude rules of Maven Surefire
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<excludes>
-						<exclude/>
-					</excludes>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Please see the
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
-documentation for Maven Surefire for details.
-
-[[running-tests-build-maven-filter-tags]]
-===== Filtering by Tags
-
-You can filter tests by <<running-tests-tags, tags>> or
-<<running-tests-tag-expressions, tag expressions>> using the following configuration
-properties.
-
-- to include _tags_ or _tag expressions_, use `groups`.
-- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<groups>acceptance | !feature-a</groups>
-					<excludedGroups>integration, regression</excludedGroups>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-config-params]]
-===== Configuration Parameters
-
-You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
-influence test discovery and execution by declaring the `configurationParameters`
-property and providing key-value pairs using the Java `Properties` file syntax (as shown
-below) or via the `junit-platform.properties` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<properties>
-						<configurationParameters>
-							junit.jupiter.conditions.deactivate = *
-							junit.jupiter.extensions.autodetection.enabled = true
-							junit.jupiter.testinstance.lifecycle.default = per_class
-						</configurationParameters>
-					</properties>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-ant]]
-==== Ant
-
-Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
-provides native support for launching tests on the JUnit Platform. The `junitlauncher`
-task is solely responsible for launching the JUnit Platform and passing it the selected
-collection of tests. The JUnit Platform then delegates to registered test engines to
-discover and execute the tests.
-
-The `junitlauncher` task attempts to align as closely as possible with native Ant
-constructs such as
-link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
-for allowing users to select the tests that they want executed by test engines. This gives
-the task a consistent and natural feel when compared to many other core Ant tasks.
-
-Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
-
-The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
-the task and can serve as a starting point.
-
-===== Basic Usage
-
-The following example demonstrates how to configure the `junitlauncher` task to select a
-single test class (i.e., `com.example.project.CalculatorTests`).
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-
-	<!-- ... -->
-
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<test name="com.example.project.CalculatorTests" />
-	</junitlauncher>
-----
-
-The `test` element allows you to specify a single test class that you want to be selected
-and executed. The `classpath` element allows you to specify the classpath to be used to
-launch the JUnit Platform. This classpath will also be used to locate test classes that
-are part of the execution.
-
-The following example demonstrates how to configure the `junitlauncher` task to select
-test classes from multiple locations.
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-	<!-- ... -->
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<testclasses outputdir="${output.dir}">
-			<fileset dir="${build.classes.dir}">
-				<include name="org/example/**/demo/**/" />
-			</fileset>
-			<fileset dir="${some.other.dir}">
-				<include name="org/myapp/**/" />
-			</fileset>
-		</testclasses>
-	</junitlauncher>
-----
-
-In the above example, the `testclasses` element allows you to select multiple test
-classes that reside in different locations.
-
-For further details on usage and configuration options please refer to the official Ant
-documentation for the
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
-
-[[running-tests-build-spring-boot]]
-==== Spring Boot
-
-link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
-managing the version of JUnit used in your project. In addition, the
-`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
-Jupiter, AssertJ, Mockito, etc.
-
-If your build relies on dependency management support from Spring Boot, you should not
-import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
-result in duplicate (and potentially conflicting) management of JUnit dependencies.
-
-If you need to override the version of a dependency used in your Spring Boot application,
-you have to override the exact name of the
-link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
-defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
-Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
-changing a dependency version is documented for both
-link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
-and
-link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
-
-With Gradle you can override the JUnit Jupiter version by including the following in your
-`build.gradle` file.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-	ext['junit-jupiter.version'] = '{version}'
-----
-
-With Maven you can override the JUnit Jupiter version by including the following in your
-`pom.xml` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<properties>
-		<junit-jupiter.version>{version}</junit-jupiter.version>
-	</properties>
-----
-
-[[running-tests-console-launcher]]
-=== Console Launcher
-
-The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
-Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
-Jupiter tests and print test execution results to the console.
-
-An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
-contains the contents of all of its dependencies is published in the {Maven_Central}
-repository under the
-https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
-directory. It contains the contents of the following artifacts:
-
-include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
-
-[NOTE]
-====
-Since the `junit-platform-console-standalone` JAR contains the contents of all of its
-dependencies, its Maven POM does not declare any dependencies.
-
-Furthermore, it is not very likely that you would need to include a dependency on the
-`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
-script. On the contrary, the executable `junit-platform-console-standalone` JAR is
-typically invoked directly from the command line or a shell script without a build script.
-
-If you need to declare dependencies in your build script on some of the artifacts
-contained in the `junit-platform-console-standalone` artifact, you should declare
-dependencies only on the JUnit artifacts that are used in your project. To simplify
-dependency management of JUnit artifacts in your build, you may wish to use the
-`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
-details.
-====
-
-You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
-standalone `ConsoleLauncher` as shown below.
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
-
-├─ JUnit Vintage
-│  └─ example.JUnit4Tests
-│     └─ standardJUnit4Test ✔
-└─ JUnit Jupiter
-   ├─ StandardTests
-   │  ├─ succeedingTest() ✔
-   │  └─ skippedTest() ↷ for demonstration purposes
-   └─ A special test case
-      ├─ Custom test name containing spaces ✔
-      ├─ ╯°□°)╯ ✔
-      └─ 😱 ✔
-
-Test run finished after 64 ms
-[         5 containers found      ]
-[         0 containers skipped    ]
-[         5 containers started    ]
-[         0 containers aborted    ]
-[         5 containers successful ]
-[         0 containers failed     ]
-[         6 tests found           ]
-[         1 tests skipped         ]
-[         5 tests started         ]
-[         0 tests aborted         ]
-[         5 tests successful      ]
-[         0 tests failed          ]
-----
-
-You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
-all jars in a directory):
-
-[source,console,subs=attributes+]
-----
-$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
-----
-
-[[running-tests-console-launcher-options]]
-==== Subcommands and Options
-
-The `{ConsoleLauncher}` provides the following subcommands:
-
-----
-include::{consoleLauncherOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-discovering-tests]]
-===== Discovering tests
-
-----
-include::{consoleLauncherDiscoverOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-executing-tests]]
-===== Executing tests
-
-.Exit Code
-NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
-All non-zero codes indicate an error of some sort. For example, status code `1`
-is returned if any containers or tests failed. If no tests are discovered and the
-`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
-with a status code of `2`. Unexpected or invalid user input yields a status code
-of `3`. An exit code of `-1` indicates an unspecified error condition.
-
-----
-include::{consoleLauncherExecuteOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-listing-test-engines]]
-===== Listing test engines
-
-----
-include::{consoleLauncherEnginesOptionsFile}[]
-----
-
-[[running-tests-console-launcher-argument-files]]
-==== Argument Files (@-files)
-
-On some platforms you may run into system limitations on the length of a command line when
-creating a command line with lots of options or with long arguments.
-
-The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
-are files that themselves contain arguments to be passed to the command. When the
-underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
-argument beginning with the character `@`, it expands the contents of that file into the
-argument list.
-
-The arguments within a file can be separated by spaces or newlines. If an argument
-contains embedded whitespace, the whole argument should be wrapped in double or single
-quotes -- for example, `"-f=My Files/Stuff.java"`.
-
-If the argument file does not exist or cannot be read, the argument will be treated
-literally and will not be removed. This will likely result in an "unmatched argument"
-error message. You can troubleshoot such errors by executing the command with the
-`picocli.trace` system property set to `DEBUG`.
-
-Multiple _@-files_ may be specified on the command line. The specified path may be
-relative to the current directory or absolute.
-
-You can pass a real parameter with an initial `@` character by escaping it with an
-additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
-subject to expansion.
-
-[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
-==== Redirecting Standard Output/Error to Files
-
-You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
-files using the `--redirect-stdout` and `--redirect-stderr` options:
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
-  --redirect-stdout=stdout.txt \
-  --redirect-stderr=stderr.txt
-----
-
-[NOTE]
-====
-If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
-output streams will be redirected to that file.
-
-The default charset is used for writing to the files.
-====
-
-[[running-tests-console-launcher-color-customization]]
-==== Color Customization
-
-The colors used in the output of the `{ConsoleLauncher}` can be customized.
-The option `--single-color` will apply a built-in monochrome style, while
-`--color-palette` will accept a properties file to override the
-https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
-The properties file below demonstrates the default style:
-
-[source,properties,indent=0]
-----
-SUCCESSFUL = 32
-ABORTED = 33
-FAILED = 31
-SKIPPED = 35
-CONTAINER = 35
-TEST = 34
-DYNAMIC = 35
-REPORTED = 37
-----
-
-[[running-tests-source-launcher]]
-=== Source Launcher
-
-Starting with Java 25 it is possible to write minimal source code test programs
-using the `org.junit.start` module. For example, like in a `HelloTests.java`
-file reading:
-
-```java
-import module org.junit.start;
-
-void main() {
-  JUnit.run();
-}
-
-@Test
-void stringLength() {
-  Assertions.assertEquals(11, "Hello JUnit".length());
-}
-```
-With all required modular JAR files available in a local `lib/` directory, the
-following Java 25+ command will discover and execute tests using the JUnit Platform.
-It will also print the result tree to the console.
-
-```shell
-java --module-path lib --add-modules org.junit.start HelloTests.java
-╷
-└─ JUnit Jupiter ✔
-   └─ HelloTests ✔
-      └─ stringLength() ✔
-```
-
-Find JUnit's class API documentation here: {JUnit}
-
-[[running-tests-discovery-selectors]]
-=== Discovery Selectors
-
-The JUnit Platform provides a rich set of discovery selectors that can be used to specify
-which tests should be discovered or executed.
-
-Discovery selectors can be created programmatically using the factory methods in the
-`{DiscoverySelectors}` class, specified declaratively via annotations when using the
-<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
-generically as strings via their identifiers.
-
-The following discovery selectors are provided out of the box:
-
-|===
-| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
-
-| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
-| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
-| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
-| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
-| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
-| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
-| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
-| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
-| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
-| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
-| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
-| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
-| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
-|===
-
-
-[[running-tests-config-params]]
-=== Configuration Parameters
-
-In addition to instructing the platform which test classes and test engines to include,
-which packages to scan, etc., it is sometimes necessary to provide additional custom
-configuration parameters that are specific to a particular test engine, listener, or
-registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
-parameters_ for the following use cases.
-
-- <<writing-tests-test-instance-lifecycle-changing-default>>
-- <<extensions-registration-automatic-enabling>>
-- <<extensions-conditions-deactivation>>
-- <<writing-tests-display-name-generator-default>>
-
-_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
-engines running on the JUnit Platform via one of the following mechanisms.
-
-1. The `configurationParameter()` and `configurationParameters()` methods in
-   `LauncherDiscoveryRequestBuilder` which
-   is used to build a request supplied to the <<launcher-api, Launcher API>>.
-    +
-   When running tests via one of the tools provided by the JUnit Platform you can specify
-   configuration parameters as follows:
-   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
-     option.
-   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
-     `systemProperties` DSL.
-   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
-     `configurationParameters` property.
-2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
-    +
-   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
-   specify custom configuration files using the `--config-resource` command-line option.
-3. JVM system properties.
-4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
-   in the root of the class path that follows the syntax rules for Java `Properties`
-   files.
-
-NOTE: Configuration parameters are looked up in the exact order defined above.
-Consequently, configuration parameters supplied directly to the `Launcher` take
-precedence over those supplied via custom configuration files, system properties, and the
-default configuration file. Similarly, configuration parameters supplied via system
-properties take precedence over those supplied via the default configuration file.
-
-[[running-tests-config-params-deactivation-pattern]]
-==== Pattern Matching Syntax
-
-This section describes the pattern matching syntax that is applied to the _configuration
-parameters_ used for the following features.
-
-- <<extensions-conditions-deactivation>>
-- <<launcher-api-listeners-custom-deactivation>>
-- <<stacktrace-pruning>>
-- <<extensions-registration-automatic-filtering>>
-
-If the value for the given _configuration parameter_ consists solely of an asterisk
-(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
-will be treated as a comma-separated list of patterns where each pattern will be matched
-against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
-a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
-(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
-pattern will be matched one-to-one against a FQCN.
-
-Examples:
-
-- `+++*+++`: matches all candidate classes.
-- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
-  any of its subpackages.
-- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
-  `MyCustomImpl`.
-- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
-- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
-  `System` or `Unit`.
-- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
-  `org.example.MyCustomImpl`.
-- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
-  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
-
-[[running-tests-tags]]
-=== Tags
-
-Tags are a JUnit Platform concept for marking and filtering tests. The programming model
-for adding tags to containers and tests is defined by the testing framework. For example,
-in JUnit Jupiter based tests, the `@Tag` annotation (see
-<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
-Vintage engine maps `@Category` annotations to tags (see
-<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
-own annotation or other means for users to specify tags.
-
-[[running-tests-tag-syntax-rules]]
-==== Syntax Rules for Tags
-
-Regardless how a tag is specified, the JUnit Platform enforces the following rules:
-
-* A tag must not be `null` or _blank_.
-* A _stripped_ tag must not contain whitespace.
-* A _stripped_ tag must not contain ISO control characters.
-* A _stripped_ tag must not contain any of the following _reserved characters_.
-- `,`: _comma_
-- `(`: _left parenthesis_
-- `)`: _right parenthesis_
-- `&`: _ampersand_
-- `|`: _vertical bar_
-- `!`: _exclamation point_
-
-NOTE: In the above context, "stripped" means that leading and trailing whitespace
-characters have been removed using `java.lang.String.strip()`.
-
-[[running-tests-tag-expressions]]
-==== Tag Expressions
-
-Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
-`(` and `)` can be used to adjust for operator precedence.
-
-Two special expressions are supported, `any()` and `none()`, which select all tests _with_
-any tags at all, and all tests _without_ any tags, respectively.
-These special expressions may be combined with other expressions just like normal tags.
-
-.Operators (in descending order of precedence)
-|===
-| Operator | Meaning | Associativity
-
-| `!`      | not     | right
-| `&`      | and     | left
-| `\|`     | or      | left
-|===
-
-If you are tagging your tests across multiple dimensions, tag expressions help you to
-select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
-_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
-expressions can be useful.
-
-[%header,cols="40,60"]
-|===
-| Tag Expression
-| Selection
-
-| `+++product+++`
-| all tests for *product*
-
-| `+++catalog \| shipping+++`
-| all tests for *catalog* plus all tests for *shipping*
-
-| `+++catalog &amp; shipping+++`
-| all tests for the intersection between *catalog* and *shipping*
-
-| `+++product &amp; !end-to-end+++`
-| all tests for *product*, but not the _end-to-end_ tests
-
-| `+++(micro \| integration) &amp; (product \| shipping)+++`
-| all _micro_ or _integration_ tests for *product* or *shipping*
-|===
-
 [[running-tests-capturing-output]]
 === Capturing Standard Output/Error
 
@@ -1074,143 +18,3 @@ because particularly when
 <<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
 to attribute it to a specific test or container.
 
-[[running-tests-listeners]]
-=== Using Listeners and Interceptors
-
-The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
-and custom user code to react to events fired at various points during the discovery and
-execution of a `TestPlan`.
-
-* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
-  closed.
-* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
-  `LauncherSession`.
-* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
-* `{TestExecutionListener}`: receives events that occur during test execution.
-
-The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
-registered automatically for you in order to support some feature of the build tool or IDE.
-
-The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
-order to produce some form of report or to display a graphical representation of the test
-plan in an IDE. Such listeners may be implemented and automatically registered by a build
-tool or IDE, or they may be included in a third-party library – potentially registered
-for you automatically. You can also implement and register your own listeners.
-
-For details on registering and configuring listeners, see the following sections of this
-guide.
-
-* <<launcher-api-launcher-session-listeners-custom>>
-* <<launcher-api-launcher-interceptors-custom>>
-* <<launcher-api-launcher-discovery-listeners-custom>>
-* <<launcher-api-listeners-custom>>
-* <<launcher-api-listeners-config>>
-* <<launcher-api-listeners-custom-deactivation>>
-
-The JUnit Platform provides the following listeners which you may wish to use with your
-test suite.
-
-<<junit-platform-reporting>> ::
-  `{LegacyXmlReportGeneratingListener}` can be used via the
-  <<running-tests-console-launcher>> or registered manually to generate XML reports
-  compatible with the de facto standard for JUnit 4 based test reports.
-+
-`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
-specified by {OpenTestReporting}. It is auto-registered and can be enabled and
-configured via <<running-tests-config-params>>.
-+
-See <<junit-platform-reporting>> for details.
-
-<<running-tests-listeners-flight-recorder>> ::
-  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
-  Java Flight Recorder events during test discovery and execution.
-
-`{LoggingListener}` ::
-  `TestExecutionListener` for logging informational messages for all events via a
-  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
-
-`{SummaryGeneratingListener}` ::
-  `TestExecutionListener` that generates a summary of the test execution which can be
-  printed via a `PrintWriter`.
-
-`{UniqueIdTrackingListener}` ::
-  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
-  or executed during the execution of the `TestPlan` and generates a file containing the
-  unique IDs once execution of the `TestPlan` has finished.
-
-[[running-tests-listeners-flight-recorder]]
-==== Flight Recorder Support
-
-The JUnit Platform provides opt-in support for generating Flight Recorder events.
-https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
-follows.
-
-> Flight Recorder records events originating from applications, the JVM, and the OS.
-Events are stored in a single file that can be attached to bug reports and examined by
-support engineers, allowing after-the-fact analysis of issues in the period leading up
-to a problem.
-
-In order to record Flight Recorder events generated while running tests, you need to
-start flight recording when launching a test suite via the following java command line
-option.
-
-   -XX:StartFlightRecording:filename=...
-
-Please consult the manual of your build tool for the appropriate commands.
-
-To analyze the recorded events, use the
-https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
-command line tool shipped with recent JDKs or open the recording file with
-https://jdk.java.net/jmc/[JDK Mission Control].
-
-[[stacktrace-pruning]]
-=== Stack Trace Pruning
-
-The JUnit Platform provides built-in support for pruning stack traces produced by failing
-tests. This feature is enabled by default but can be disabled by setting the
-`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
-
-When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
-packages are removed from the stack trace, unless the calls occur after the test itself
-or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
-never be excluded.
-
-In addition, all elements prior to and including the first call from the JUnit Platform
-`Launcher` will be removed.
-
-[[running-tests-discovery-issues]]
-=== Discovery Issues
-
-Test engines may encounter issues during test discovery. For example, the declaration of a
-test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
-Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
-report them with different severity levels:
-
-INFO::
-Indicates that the engine encountered something that could be potentially problematic, but
-could also happen due to a valid setup or configuration.
-
-WARNING::
-Indicates that the engine encountered something that is problematic and might lead to
-unexpected behavior or will be removed or changed in a future release.
-
-ERROR::
-Indicates that the engine encountered something that is definitely problematic and will
-lead to unexpected behavior.
-
-If an engine reports an issue with a severity equal to or higher than a configurable
-_critical_ severity, its tests will not be executed. Instead, the engine will be reported
-as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
-Non-critical issues will be logged but will not prevent the engine from executing its
-tests. The `junit.platform.discovery.issue.severity.critical`
-<<running-tests-config-params, configuration parameter>> can be used to set the critical
-severity level. Currently, the default value is `ERROR` but it may be changed in a future
-release.
-
-TIP: To surface all discovery issues in your project, it is recommended to set the
-`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
-
-In addition, registered `{LauncherDiscoveryListener}` implementations can receive
-discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
-report issues to the user in a more user-friendly way. For example, IDEs may choose to
-display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc b/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc
index 3099a146c2b4..92b99db8a69b 100644
--- a/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc
@@ -1,906 +1,3 @@
-[[running-tests]]
-== Running Tests
-
-[[running-tests-ide]]
-=== IDE Support
-
-[[running-tests-ide-intellij-idea]]
-==== IntelliJ IDEA
-
-IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
-information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
-however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
-IDEA download the following JARs automatically based on the API version used in the
-project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
-
-In order to use a different JUnit version (e.g., {version}), you may need to
-include the corresponding versions of the `junit-platform-launcher`,
-`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
-
-.Additional Gradle Dependencies
-[source,groovy]
-[subs=attributes+]
-----
-testImplementation(platform("org.junit:junit-bom:{version}"))
-testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
-testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
-----
-
-.Additional Maven Dependencies
-[source,xml]
-[subs=attributes+]
-----
-<!-- ... -->
-<dependencies>
-	<dependency>
-		<groupId>org.junit.platform</groupId>
-		<artifactId>junit-platform-launcher</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.jupiter</groupId>
-		<artifactId>junit-jupiter-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.vintage</groupId>
-		<artifactId>junit-vintage-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-</dependencies>
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-[[running-tests-ide-eclipse]]
-==== Eclipse
-
-Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
-release.
-
-For more information on using JUnit Platform in Eclipse consult the official _Eclipse
-support for JUnit 5_ section of the
-https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
-(4.7.1a) - New and Noteworthy] documentation.
-
-[[running-tests-ide-netbeans]]
-==== NetBeans
-
-NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
-https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
-
-For more information consult the JUnit 5 section of the
-https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
-release notes].
-
-[[running-tests-ide-vscode]]
-==== Visual Studio Code
-
-https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
-Platform via the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
-Runner] extension which is installed by default as part of the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
-Extension Pack].
-
-For more information consult the _Testing_ section of the
-https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
-documentation.
-
-[[running-tests-ide-other]]
-==== Other IDEs
-
-If you are using an editor or IDE other than one of those listed in the previous sections,
-and it doesn't support running tests on the JUnit Platform, you can use the
-<<running-tests-console-launcher>> to run them from the command line.
-
-[[running-tests-build]]
-=== Build Support
-
-[[running-tests-build-gradle]]
-==== Gradle
-
-Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
-https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
-for executing tests on the JUnit Platform. To enable it, you need to specify
-`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform()
-}
-----
-
-Filtering by <<running-tests-tags, tags>>,
-<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform {
-		includeTags("fast", "smoke & feature-a")
-		// excludeTags("slow", "ci")
-		includeEngines("junit-jupiter")
-		// excludeEngines("junit-vintage")
-	}
-}
-----
-
-Please refer to the
-https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
-for a comprehensive list of options.
-
-[[running-tests-build-gradle-bom]]
-===== Aligning dependency versions
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Explicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation(platform("org.junit:junit-bom:{version}"))
-	testImplementation("org.junit.jupiter:junit-jupiter")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-Since all JUnit artifacts declare a
-https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
-you usually don't need to declare an explicit dependency on it yourself. Instead, it's
-sufficient to declare _one_ regular dependency that includes a version number. Gradle will
-then pull in the BOM automatically so you can omit the version for all other JUnit
-artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Implicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
-}
-----
-<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
-<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
-
-[WARNING]
-.Declaring a dependency on junit-platform-launcher
-====
-Even though pre-8.0 versions of Gradle don't require declaring an explicit
-dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
-of JUnit artifacts on the test runtime classpath are aligned.
-
-Moreover, doing so is recommended and in some cases even required when importing the
-project into an IDE like <<running-tests-ide-eclipse>> or
-<<running-tests-ide-intellij-idea>>.
-====
-
-[[running-tests-build-gradle-engines-configure]]
-===== Configuring Test Engines
-
-In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
-
-To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
-on the dependency-aggregating JUnit Jupiter artifact similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Alternatively, you can use Gradle's
-https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
-support.
-
-[source,kotlin,indent=0]
-[subs=attributes+]
-.Kotlin DSL
-----
-testing {
-	suites {
-		named<JvmTestSuite>("test") {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Groovy DSL
-----
-testing {
-	suites {
-		test {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
-dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
-implementation similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("junit:junit:{junit4-version}")
-	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-[[running-tests-build-gradle-config-params]]
-===== Configuration Parameters
-
-The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
-Platform <<running-tests-config-params, configuration parameters>> to influence test
-discovery and execution. However, you can provide configuration parameters within the
-build script via system properties (as shown below) or via the
-`junit-platform.properties` file.
-
-[source,groovy,indent=0]
-----
-test {
-	// ...
-	systemProperty("junit.jupiter.conditions.deactivate", "*")
-	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
-	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
-	// ...
-}
-----
-
-[[running-tests-build-gradle-logging]]
-===== Configuring Logging (optional)
-
-JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
-emit warnings and debug information. Please refer to the official documentation of
-`{LogManager}` for configuration options.
-
-Alternatively, it's possible to redirect log messages to other logging frameworks such as
-{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
-`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
-qualified class name_ of the `{LogManager}` implementation to use. The example below
-demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
-details).
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
-	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
-	systemProperty("log4j2.disableJmx", "true")
-}
-----
-
-Other logging frameworks provide different means to redirect messages logged using
-`java.util.logging`. For example, for {Logback} you can use the
-https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
-dependency to the test runtime classpath.
-
-[[running-tests-build-maven]]
-==== Maven
-
-Maven Surefire and Maven Failsafe provide
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
-for executing tests on the JUnit Platform. The `pom.xml` file in the
-`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
-and can serve as a starting point for configuring your Maven build.
-
-[WARNING]
-.Minimum required version of Maven Surefire/Failsafe
-====
-As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
-====
-
-[[running-tests-build-maven-bom]]
-===== Aligning dependency versions
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-[[running-tests-build-maven-engines-configure]]
-===== Configuring Test Engines
-
-In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
-`TestEngine` implementation must be added to the test classpath.
-
-To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
-on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
-following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>org.junit.jupiter</groupId>
-			<artifactId>junit-jupiter</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
-long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
-`TestEngine` implementation similar to the following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>junit</groupId>
-			<artifactId>junit</artifactId>
-			<version>{junit4-version}</version>
-			<scope>test</scope>
-		</dependency>
-		<dependency>
-			<groupId>org.junit.vintage</groupId>
-			<artifactId>junit-vintage-engine</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-filter-test-class-names]]
-===== Filtering by Test Class Names
-
-The Maven Surefire Plugin will scan for test classes whose fully qualified names match
-the following patterns.
-
-- `+++**/Test*.java+++`
-- `+++**/*Test.java+++`
-- `+++**/*Tests.java+++`
-- `+++**/*TestCase.java+++`
-
-Moreover, it will exclude all nested classes (including static member classes) by default.
-
-Note, however, that you can override this default behavior by configuring explicit
-`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
-from excluding static member classes, you can override its exclude rules as follows.
-
-[source,xml,indent=0]
-[subs=attributes+]
-.Overriding exclude rules of Maven Surefire
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<excludes>
-						<exclude/>
-					</excludes>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Please see the
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
-documentation for Maven Surefire for details.
-
-[[running-tests-build-maven-filter-tags]]
-===== Filtering by Tags
-
-You can filter tests by <<running-tests-tags, tags>> or
-<<running-tests-tag-expressions, tag expressions>> using the following configuration
-properties.
-
-- to include _tags_ or _tag expressions_, use `groups`.
-- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<groups>acceptance | !feature-a</groups>
-					<excludedGroups>integration, regression</excludedGroups>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-config-params]]
-===== Configuration Parameters
-
-You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
-influence test discovery and execution by declaring the `configurationParameters`
-property and providing key-value pairs using the Java `Properties` file syntax (as shown
-below) or via the `junit-platform.properties` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<properties>
-						<configurationParameters>
-							junit.jupiter.conditions.deactivate = *
-							junit.jupiter.extensions.autodetection.enabled = true
-							junit.jupiter.testinstance.lifecycle.default = per_class
-						</configurationParameters>
-					</properties>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-ant]]
-==== Ant
-
-Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
-provides native support for launching tests on the JUnit Platform. The `junitlauncher`
-task is solely responsible for launching the JUnit Platform and passing it the selected
-collection of tests. The JUnit Platform then delegates to registered test engines to
-discover and execute the tests.
-
-The `junitlauncher` task attempts to align as closely as possible with native Ant
-constructs such as
-link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
-for allowing users to select the tests that they want executed by test engines. This gives
-the task a consistent and natural feel when compared to many other core Ant tasks.
-
-Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
-
-The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
-the task and can serve as a starting point.
-
-===== Basic Usage
-
-The following example demonstrates how to configure the `junitlauncher` task to select a
-single test class (i.e., `com.example.project.CalculatorTests`).
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-
-	<!-- ... -->
-
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<test name="com.example.project.CalculatorTests" />
-	</junitlauncher>
-----
-
-The `test` element allows you to specify a single test class that you want to be selected
-and executed. The `classpath` element allows you to specify the classpath to be used to
-launch the JUnit Platform. This classpath will also be used to locate test classes that
-are part of the execution.
-
-The following example demonstrates how to configure the `junitlauncher` task to select
-test classes from multiple locations.
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-	<!-- ... -->
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<testclasses outputdir="${output.dir}">
-			<fileset dir="${build.classes.dir}">
-				<include name="org/example/**/demo/**/" />
-			</fileset>
-			<fileset dir="${some.other.dir}">
-				<include name="org/myapp/**/" />
-			</fileset>
-		</testclasses>
-	</junitlauncher>
-----
-
-In the above example, the `testclasses` element allows you to select multiple test
-classes that reside in different locations.
-
-For further details on usage and configuration options please refer to the official Ant
-documentation for the
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
-
-[[running-tests-build-spring-boot]]
-==== Spring Boot
-
-link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
-managing the version of JUnit used in your project. In addition, the
-`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
-Jupiter, AssertJ, Mockito, etc.
-
-If your build relies on dependency management support from Spring Boot, you should not
-import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
-result in duplicate (and potentially conflicting) management of JUnit dependencies.
-
-If you need to override the version of a dependency used in your Spring Boot application,
-you have to override the exact name of the
-link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
-defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
-Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
-changing a dependency version is documented for both
-link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
-and
-link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
-
-With Gradle you can override the JUnit Jupiter version by including the following in your
-`build.gradle` file.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-	ext['junit-jupiter.version'] = '{version}'
-----
-
-With Maven you can override the JUnit Jupiter version by including the following in your
-`pom.xml` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<properties>
-		<junit-jupiter.version>{version}</junit-jupiter.version>
-	</properties>
-----
-
-[[running-tests-console-launcher]]
-=== Console Launcher
-
-The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
-Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
-Jupiter tests and print test execution results to the console.
-
-An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
-contains the contents of all of its dependencies is published in the {Maven_Central}
-repository under the
-https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
-directory. It contains the contents of the following artifacts:
-
-include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
-
-[NOTE]
-====
-Since the `junit-platform-console-standalone` JAR contains the contents of all of its
-dependencies, its Maven POM does not declare any dependencies.
-
-Furthermore, it is not very likely that you would need to include a dependency on the
-`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
-script. On the contrary, the executable `junit-platform-console-standalone` JAR is
-typically invoked directly from the command line or a shell script without a build script.
-
-If you need to declare dependencies in your build script on some of the artifacts
-contained in the `junit-platform-console-standalone` artifact, you should declare
-dependencies only on the JUnit artifacts that are used in your project. To simplify
-dependency management of JUnit artifacts in your build, you may wish to use the
-`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
-details.
-====
-
-You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
-standalone `ConsoleLauncher` as shown below.
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
-
-├─ JUnit Vintage
-│  └─ example.JUnit4Tests
-│     └─ standardJUnit4Test ✔
-└─ JUnit Jupiter
-   ├─ StandardTests
-   │  ├─ succeedingTest() ✔
-   │  └─ skippedTest() ↷ for demonstration purposes
-   └─ A special test case
-      ├─ Custom test name containing spaces ✔
-      ├─ ╯°□°)╯ ✔
-      └─ 😱 ✔
-
-Test run finished after 64 ms
-[         5 containers found      ]
-[         0 containers skipped    ]
-[         5 containers started    ]
-[         0 containers aborted    ]
-[         5 containers successful ]
-[         0 containers failed     ]
-[         6 tests found           ]
-[         1 tests skipped         ]
-[         5 tests started         ]
-[         0 tests aborted         ]
-[         5 tests successful      ]
-[         0 tests failed          ]
-----
-
-You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
-all jars in a directory):
-
-[source,console,subs=attributes+]
-----
-$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
-----
-
-[[running-tests-console-launcher-options]]
-==== Subcommands and Options
-
-The `{ConsoleLauncher}` provides the following subcommands:
-
-----
-include::{consoleLauncherOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-discovering-tests]]
-===== Discovering tests
-
-----
-include::{consoleLauncherDiscoverOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-executing-tests]]
-===== Executing tests
-
-.Exit Code
-NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
-All non-zero codes indicate an error of some sort. For example, status code `1`
-is returned if any containers or tests failed. If no tests are discovered and the
-`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
-with a status code of `2`. Unexpected or invalid user input yields a status code
-of `3`. An exit code of `-1` indicates an unspecified error condition.
-
-----
-include::{consoleLauncherExecuteOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-listing-test-engines]]
-===== Listing test engines
-
-----
-include::{consoleLauncherEnginesOptionsFile}[]
-----
-
-[[running-tests-console-launcher-argument-files]]
-==== Argument Files (@-files)
-
-On some platforms you may run into system limitations on the length of a command line when
-creating a command line with lots of options or with long arguments.
-
-The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
-are files that themselves contain arguments to be passed to the command. When the
-underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
-argument beginning with the character `@`, it expands the contents of that file into the
-argument list.
-
-The arguments within a file can be separated by spaces or newlines. If an argument
-contains embedded whitespace, the whole argument should be wrapped in double or single
-quotes -- for example, `"-f=My Files/Stuff.java"`.
-
-If the argument file does not exist or cannot be read, the argument will be treated
-literally and will not be removed. This will likely result in an "unmatched argument"
-error message. You can troubleshoot such errors by executing the command with the
-`picocli.trace` system property set to `DEBUG`.
-
-Multiple _@-files_ may be specified on the command line. The specified path may be
-relative to the current directory or absolute.
-
-You can pass a real parameter with an initial `@` character by escaping it with an
-additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
-subject to expansion.
-
-[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
-==== Redirecting Standard Output/Error to Files
-
-You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
-files using the `--redirect-stdout` and `--redirect-stderr` options:
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
-  --redirect-stdout=stdout.txt \
-  --redirect-stderr=stderr.txt
-----
-
-[NOTE]
-====
-If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
-output streams will be redirected to that file.
-
-The default charset is used for writing to the files.
-====
-
-[[running-tests-console-launcher-color-customization]]
-==== Color Customization
-
-The colors used in the output of the `{ConsoleLauncher}` can be customized.
-The option `--single-color` will apply a built-in monochrome style, while
-`--color-palette` will accept a properties file to override the
-https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
-The properties file below demonstrates the default style:
-
-[source,properties,indent=0]
-----
-SUCCESSFUL = 32
-ABORTED = 33
-FAILED = 31
-SKIPPED = 35
-CONTAINER = 35
-TEST = 34
-DYNAMIC = 35
-REPORTED = 37
-----
-
-[[running-tests-source-launcher]]
-=== Source Launcher
-
-Starting with Java 25 it is possible to write minimal source code test programs
-using the `org.junit.start` module. For example, like in a `HelloTests.java`
-file reading:
-
-```java
-import module org.junit.start;
-
-void main() {
-  JUnit.run();
-}
-
-@Test
-void stringLength() {
-  Assertions.assertEquals(11, "Hello JUnit".length());
-}
-```
-With all required modular JAR files available in a local `lib/` directory, the
-following Java 25+ command will discover and execute tests using the JUnit Platform.
-It will also print the result tree to the console.
-
-```shell
-java --module-path lib --add-modules org.junit.start HelloTests.java
-╷
-└─ JUnit Jupiter ✔
-   └─ HelloTests ✔
-      └─ stringLength() ✔
-```
-
-Find JUnit's class API documentation here: {JUnit}
-
-[[running-tests-discovery-selectors]]
-=== Discovery Selectors
-
-The JUnit Platform provides a rich set of discovery selectors that can be used to specify
-which tests should be discovered or executed.
-
-Discovery selectors can be created programmatically using the factory methods in the
-`{DiscoverySelectors}` class, specified declaratively via annotations when using the
-<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
-generically as strings via their identifiers.
-
-The following discovery selectors are provided out of the box:
-
-|===
-| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
-
-| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
-| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
-| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
-| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
-| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
-| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
-| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
-| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
-| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
-| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
-| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
-| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
-| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
-|===
-
-
 [[running-tests-config-params]]
 === Configuration Parameters
 
@@ -979,238 +76,3 @@ Examples:
 - `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
   FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
 
-[[running-tests-tags]]
-=== Tags
-
-Tags are a JUnit Platform concept for marking and filtering tests. The programming model
-for adding tags to containers and tests is defined by the testing framework. For example,
-in JUnit Jupiter based tests, the `@Tag` annotation (see
-<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
-Vintage engine maps `@Category` annotations to tags (see
-<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
-own annotation or other means for users to specify tags.
-
-[[running-tests-tag-syntax-rules]]
-==== Syntax Rules for Tags
-
-Regardless how a tag is specified, the JUnit Platform enforces the following rules:
-
-* A tag must not be `null` or _blank_.
-* A _stripped_ tag must not contain whitespace.
-* A _stripped_ tag must not contain ISO control characters.
-* A _stripped_ tag must not contain any of the following _reserved characters_.
-- `,`: _comma_
-- `(`: _left parenthesis_
-- `)`: _right parenthesis_
-- `&`: _ampersand_
-- `|`: _vertical bar_
-- `!`: _exclamation point_
-
-NOTE: In the above context, "stripped" means that leading and trailing whitespace
-characters have been removed using `java.lang.String.strip()`.
-
-[[running-tests-tag-expressions]]
-==== Tag Expressions
-
-Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
-`(` and `)` can be used to adjust for operator precedence.
-
-Two special expressions are supported, `any()` and `none()`, which select all tests _with_
-any tags at all, and all tests _without_ any tags, respectively.
-These special expressions may be combined with other expressions just like normal tags.
-
-.Operators (in descending order of precedence)
-|===
-| Operator | Meaning | Associativity
-
-| `!`      | not     | right
-| `&`      | and     | left
-| `\|`     | or      | left
-|===
-
-If you are tagging your tests across multiple dimensions, tag expressions help you to
-select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
-_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
-expressions can be useful.
-
-[%header,cols="40,60"]
-|===
-| Tag Expression
-| Selection
-
-| `+++product+++`
-| all tests for *product*
-
-| `+++catalog \| shipping+++`
-| all tests for *catalog* plus all tests for *shipping*
-
-| `+++catalog &amp; shipping+++`
-| all tests for the intersection between *catalog* and *shipping*
-
-| `+++product &amp; !end-to-end+++`
-| all tests for *product*, but not the _end-to-end_ tests
-
-| `+++(micro \| integration) &amp; (product \| shipping)+++`
-| all _micro_ or _integration_ tests for *product* or *shipping*
-|===
-
-[[running-tests-capturing-output]]
-=== Capturing Standard Output/Error
-
-The JUnit Platform provides opt-in support for capturing output printed to `System.out`
-and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
-`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
-parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
-to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
-
-If enabled, the JUnit Platform captures the corresponding output and publishes it as a
-report entry using the `stdout` or `stderr` keys to all registered
-`{TestExecutionListener}` instances immediately before reporting the test or container as
-finished.
-
-Please note that the captured output will only contain output emitted by the thread that
-was used to execute a container or test. Any output by other threads will be omitted
-because particularly when
-<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
-to attribute it to a specific test or container.
-
-[[running-tests-listeners]]
-=== Using Listeners and Interceptors
-
-The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
-and custom user code to react to events fired at various points during the discovery and
-execution of a `TestPlan`.
-
-* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
-  closed.
-* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
-  `LauncherSession`.
-* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
-* `{TestExecutionListener}`: receives events that occur during test execution.
-
-The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
-registered automatically for you in order to support some feature of the build tool or IDE.
-
-The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
-order to produce some form of report or to display a graphical representation of the test
-plan in an IDE. Such listeners may be implemented and automatically registered by a build
-tool or IDE, or they may be included in a third-party library – potentially registered
-for you automatically. You can also implement and register your own listeners.
-
-For details on registering and configuring listeners, see the following sections of this
-guide.
-
-* <<launcher-api-launcher-session-listeners-custom>>
-* <<launcher-api-launcher-interceptors-custom>>
-* <<launcher-api-launcher-discovery-listeners-custom>>
-* <<launcher-api-listeners-custom>>
-* <<launcher-api-listeners-config>>
-* <<launcher-api-listeners-custom-deactivation>>
-
-The JUnit Platform provides the following listeners which you may wish to use with your
-test suite.
-
-<<junit-platform-reporting>> ::
-  `{LegacyXmlReportGeneratingListener}` can be used via the
-  <<running-tests-console-launcher>> or registered manually to generate XML reports
-  compatible with the de facto standard for JUnit 4 based test reports.
-+
-`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
-specified by {OpenTestReporting}. It is auto-registered and can be enabled and
-configured via <<running-tests-config-params>>.
-+
-See <<junit-platform-reporting>> for details.
-
-<<running-tests-listeners-flight-recorder>> ::
-  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
-  Java Flight Recorder events during test discovery and execution.
-
-`{LoggingListener}` ::
-  `TestExecutionListener` for logging informational messages for all events via a
-  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
-
-`{SummaryGeneratingListener}` ::
-  `TestExecutionListener` that generates a summary of the test execution which can be
-  printed via a `PrintWriter`.
-
-`{UniqueIdTrackingListener}` ::
-  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
-  or executed during the execution of the `TestPlan` and generates a file containing the
-  unique IDs once execution of the `TestPlan` has finished.
-
-[[running-tests-listeners-flight-recorder]]
-==== Flight Recorder Support
-
-The JUnit Platform provides opt-in support for generating Flight Recorder events.
-https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
-follows.
-
-> Flight Recorder records events originating from applications, the JVM, and the OS.
-Events are stored in a single file that can be attached to bug reports and examined by
-support engineers, allowing after-the-fact analysis of issues in the period leading up
-to a problem.
-
-In order to record Flight Recorder events generated while running tests, you need to
-start flight recording when launching a test suite via the following java command line
-option.
-
-   -XX:StartFlightRecording:filename=...
-
-Please consult the manual of your build tool for the appropriate commands.
-
-To analyze the recorded events, use the
-https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
-command line tool shipped with recent JDKs or open the recording file with
-https://jdk.java.net/jmc/[JDK Mission Control].
-
-[[stacktrace-pruning]]
-=== Stack Trace Pruning
-
-The JUnit Platform provides built-in support for pruning stack traces produced by failing
-tests. This feature is enabled by default but can be disabled by setting the
-`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
-
-When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
-packages are removed from the stack trace, unless the calls occur after the test itself
-or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
-never be excluded.
-
-In addition, all elements prior to and including the first call from the JUnit Platform
-`Launcher` will be removed.
-
-[[running-tests-discovery-issues]]
-=== Discovery Issues
-
-Test engines may encounter issues during test discovery. For example, the declaration of a
-test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
-Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
-report them with different severity levels:
-
-INFO::
-Indicates that the engine encountered something that could be potentially problematic, but
-could also happen due to a valid setup or configuration.
-
-WARNING::
-Indicates that the engine encountered something that is problematic and might lead to
-unexpected behavior or will be removed or changed in a future release.
-
-ERROR::
-Indicates that the engine encountered something that is definitely problematic and will
-lead to unexpected behavior.
-
-If an engine reports an issue with a severity equal to or higher than a configurable
-_critical_ severity, its tests will not be executed. Instead, the engine will be reported
-as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
-Non-critical issues will be logged but will not prevent the engine from executing its
-tests. The `junit.platform.discovery.issue.severity.critical`
-<<running-tests-config-params, configuration parameter>> can be used to set the critical
-severity level. Currently, the default value is `ERROR` but it may be changed in a future
-release.
-
-TIP: To surface all discovery issues in your project, it is recommended to set the
-`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
-
-In addition, registered `{LauncherDiscoveryListener}` implementations can receive
-discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
-report issues to the user in a more user-friendly way. For example, IDEs may choose to
-display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc b/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc
index 3099a146c2b4..a09e1b1a0584 100644
--- a/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc
@@ -1,658 +1,3 @@
-[[running-tests]]
-== Running Tests
-
-[[running-tests-ide]]
-=== IDE Support
-
-[[running-tests-ide-intellij-idea]]
-==== IntelliJ IDEA
-
-IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
-information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
-however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
-IDEA download the following JARs automatically based on the API version used in the
-project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
-
-In order to use a different JUnit version (e.g., {version}), you may need to
-include the corresponding versions of the `junit-platform-launcher`,
-`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
-
-.Additional Gradle Dependencies
-[source,groovy]
-[subs=attributes+]
-----
-testImplementation(platform("org.junit:junit-bom:{version}"))
-testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
-testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
-----
-
-.Additional Maven Dependencies
-[source,xml]
-[subs=attributes+]
-----
-<!-- ... -->
-<dependencies>
-	<dependency>
-		<groupId>org.junit.platform</groupId>
-		<artifactId>junit-platform-launcher</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.jupiter</groupId>
-		<artifactId>junit-jupiter-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.vintage</groupId>
-		<artifactId>junit-vintage-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-</dependencies>
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-[[running-tests-ide-eclipse]]
-==== Eclipse
-
-Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
-release.
-
-For more information on using JUnit Platform in Eclipse consult the official _Eclipse
-support for JUnit 5_ section of the
-https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
-(4.7.1a) - New and Noteworthy] documentation.
-
-[[running-tests-ide-netbeans]]
-==== NetBeans
-
-NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
-https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
-
-For more information consult the JUnit 5 section of the
-https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
-release notes].
-
-[[running-tests-ide-vscode]]
-==== Visual Studio Code
-
-https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
-Platform via the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
-Runner] extension which is installed by default as part of the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
-Extension Pack].
-
-For more information consult the _Testing_ section of the
-https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
-documentation.
-
-[[running-tests-ide-other]]
-==== Other IDEs
-
-If you are using an editor or IDE other than one of those listed in the previous sections,
-and it doesn't support running tests on the JUnit Platform, you can use the
-<<running-tests-console-launcher>> to run them from the command line.
-
-[[running-tests-build]]
-=== Build Support
-
-[[running-tests-build-gradle]]
-==== Gradle
-
-Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
-https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
-for executing tests on the JUnit Platform. To enable it, you need to specify
-`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform()
-}
-----
-
-Filtering by <<running-tests-tags, tags>>,
-<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform {
-		includeTags("fast", "smoke & feature-a")
-		// excludeTags("slow", "ci")
-		includeEngines("junit-jupiter")
-		// excludeEngines("junit-vintage")
-	}
-}
-----
-
-Please refer to the
-https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
-for a comprehensive list of options.
-
-[[running-tests-build-gradle-bom]]
-===== Aligning dependency versions
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Explicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation(platform("org.junit:junit-bom:{version}"))
-	testImplementation("org.junit.jupiter:junit-jupiter")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-Since all JUnit artifacts declare a
-https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
-you usually don't need to declare an explicit dependency on it yourself. Instead, it's
-sufficient to declare _one_ regular dependency that includes a version number. Gradle will
-then pull in the BOM automatically so you can omit the version for all other JUnit
-artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Implicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
-}
-----
-<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
-<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
-
-[WARNING]
-.Declaring a dependency on junit-platform-launcher
-====
-Even though pre-8.0 versions of Gradle don't require declaring an explicit
-dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
-of JUnit artifacts on the test runtime classpath are aligned.
-
-Moreover, doing so is recommended and in some cases even required when importing the
-project into an IDE like <<running-tests-ide-eclipse>> or
-<<running-tests-ide-intellij-idea>>.
-====
-
-[[running-tests-build-gradle-engines-configure]]
-===== Configuring Test Engines
-
-In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
-
-To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
-on the dependency-aggregating JUnit Jupiter artifact similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Alternatively, you can use Gradle's
-https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
-support.
-
-[source,kotlin,indent=0]
-[subs=attributes+]
-.Kotlin DSL
-----
-testing {
-	suites {
-		named<JvmTestSuite>("test") {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Groovy DSL
-----
-testing {
-	suites {
-		test {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
-dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
-implementation similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("junit:junit:{junit4-version}")
-	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-[[running-tests-build-gradle-config-params]]
-===== Configuration Parameters
-
-The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
-Platform <<running-tests-config-params, configuration parameters>> to influence test
-discovery and execution. However, you can provide configuration parameters within the
-build script via system properties (as shown below) or via the
-`junit-platform.properties` file.
-
-[source,groovy,indent=0]
-----
-test {
-	// ...
-	systemProperty("junit.jupiter.conditions.deactivate", "*")
-	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
-	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
-	// ...
-}
-----
-
-[[running-tests-build-gradle-logging]]
-===== Configuring Logging (optional)
-
-JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
-emit warnings and debug information. Please refer to the official documentation of
-`{LogManager}` for configuration options.
-
-Alternatively, it's possible to redirect log messages to other logging frameworks such as
-{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
-`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
-qualified class name_ of the `{LogManager}` implementation to use. The example below
-demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
-details).
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
-	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
-	systemProperty("log4j2.disableJmx", "true")
-}
-----
-
-Other logging frameworks provide different means to redirect messages logged using
-`java.util.logging`. For example, for {Logback} you can use the
-https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
-dependency to the test runtime classpath.
-
-[[running-tests-build-maven]]
-==== Maven
-
-Maven Surefire and Maven Failsafe provide
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
-for executing tests on the JUnit Platform. The `pom.xml` file in the
-`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
-and can serve as a starting point for configuring your Maven build.
-
-[WARNING]
-.Minimum required version of Maven Surefire/Failsafe
-====
-As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
-====
-
-[[running-tests-build-maven-bom]]
-===== Aligning dependency versions
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-[[running-tests-build-maven-engines-configure]]
-===== Configuring Test Engines
-
-In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
-`TestEngine` implementation must be added to the test classpath.
-
-To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
-on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
-following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>org.junit.jupiter</groupId>
-			<artifactId>junit-jupiter</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
-long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
-`TestEngine` implementation similar to the following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>junit</groupId>
-			<artifactId>junit</artifactId>
-			<version>{junit4-version}</version>
-			<scope>test</scope>
-		</dependency>
-		<dependency>
-			<groupId>org.junit.vintage</groupId>
-			<artifactId>junit-vintage-engine</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-filter-test-class-names]]
-===== Filtering by Test Class Names
-
-The Maven Surefire Plugin will scan for test classes whose fully qualified names match
-the following patterns.
-
-- `+++**/Test*.java+++`
-- `+++**/*Test.java+++`
-- `+++**/*Tests.java+++`
-- `+++**/*TestCase.java+++`
-
-Moreover, it will exclude all nested classes (including static member classes) by default.
-
-Note, however, that you can override this default behavior by configuring explicit
-`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
-from excluding static member classes, you can override its exclude rules as follows.
-
-[source,xml,indent=0]
-[subs=attributes+]
-.Overriding exclude rules of Maven Surefire
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<excludes>
-						<exclude/>
-					</excludes>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Please see the
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
-documentation for Maven Surefire for details.
-
-[[running-tests-build-maven-filter-tags]]
-===== Filtering by Tags
-
-You can filter tests by <<running-tests-tags, tags>> or
-<<running-tests-tag-expressions, tag expressions>> using the following configuration
-properties.
-
-- to include _tags_ or _tag expressions_, use `groups`.
-- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<groups>acceptance | !feature-a</groups>
-					<excludedGroups>integration, regression</excludedGroups>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-config-params]]
-===== Configuration Parameters
-
-You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
-influence test discovery and execution by declaring the `configurationParameters`
-property and providing key-value pairs using the Java `Properties` file syntax (as shown
-below) or via the `junit-platform.properties` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<properties>
-						<configurationParameters>
-							junit.jupiter.conditions.deactivate = *
-							junit.jupiter.extensions.autodetection.enabled = true
-							junit.jupiter.testinstance.lifecycle.default = per_class
-						</configurationParameters>
-					</properties>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-ant]]
-==== Ant
-
-Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
-provides native support for launching tests on the JUnit Platform. The `junitlauncher`
-task is solely responsible for launching the JUnit Platform and passing it the selected
-collection of tests. The JUnit Platform then delegates to registered test engines to
-discover and execute the tests.
-
-The `junitlauncher` task attempts to align as closely as possible with native Ant
-constructs such as
-link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
-for allowing users to select the tests that they want executed by test engines. This gives
-the task a consistent and natural feel when compared to many other core Ant tasks.
-
-Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
-
-The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
-the task and can serve as a starting point.
-
-===== Basic Usage
-
-The following example demonstrates how to configure the `junitlauncher` task to select a
-single test class (i.e., `com.example.project.CalculatorTests`).
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-
-	<!-- ... -->
-
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<test name="com.example.project.CalculatorTests" />
-	</junitlauncher>
-----
-
-The `test` element allows you to specify a single test class that you want to be selected
-and executed. The `classpath` element allows you to specify the classpath to be used to
-launch the JUnit Platform. This classpath will also be used to locate test classes that
-are part of the execution.
-
-The following example demonstrates how to configure the `junitlauncher` task to select
-test classes from multiple locations.
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-	<!-- ... -->
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<testclasses outputdir="${output.dir}">
-			<fileset dir="${build.classes.dir}">
-				<include name="org/example/**/demo/**/" />
-			</fileset>
-			<fileset dir="${some.other.dir}">
-				<include name="org/myapp/**/" />
-			</fileset>
-		</testclasses>
-	</junitlauncher>
-----
-
-In the above example, the `testclasses` element allows you to select multiple test
-classes that reside in different locations.
-
-For further details on usage and configuration options please refer to the official Ant
-documentation for the
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
-
-[[running-tests-build-spring-boot]]
-==== Spring Boot
-
-link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
-managing the version of JUnit used in your project. In addition, the
-`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
-Jupiter, AssertJ, Mockito, etc.
-
-If your build relies on dependency management support from Spring Boot, you should not
-import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
-result in duplicate (and potentially conflicting) management of JUnit dependencies.
-
-If you need to override the version of a dependency used in your Spring Boot application,
-you have to override the exact name of the
-link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
-defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
-Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
-changing a dependency version is documented for both
-link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
-and
-link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
-
-With Gradle you can override the JUnit Jupiter version by including the following in your
-`build.gradle` file.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-	ext['junit-jupiter.version'] = '{version}'
-----
-
-With Maven you can override the JUnit Jupiter version by including the following in your
-`pom.xml` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<properties>
-		<junit-jupiter.version>{version}</junit-jupiter.version>
-	</properties>
-----
-
 [[running-tests-console-launcher]]
 === Console Launcher
 
@@ -836,381 +181,3 @@ DYNAMIC = 35
 REPORTED = 37
 ----
 
-[[running-tests-source-launcher]]
-=== Source Launcher
-
-Starting with Java 25 it is possible to write minimal source code test programs
-using the `org.junit.start` module. For example, like in a `HelloTests.java`
-file reading:
-
-```java
-import module org.junit.start;
-
-void main() {
-  JUnit.run();
-}
-
-@Test
-void stringLength() {
-  Assertions.assertEquals(11, "Hello JUnit".length());
-}
-```
-With all required modular JAR files available in a local `lib/` directory, the
-following Java 25+ command will discover and execute tests using the JUnit Platform.
-It will also print the result tree to the console.
-
-```shell
-java --module-path lib --add-modules org.junit.start HelloTests.java
-╷
-└─ JUnit Jupiter ✔
-   └─ HelloTests ✔
-      └─ stringLength() ✔
-```
-
-Find JUnit's class API documentation here: {JUnit}
-
-[[running-tests-discovery-selectors]]
-=== Discovery Selectors
-
-The JUnit Platform provides a rich set of discovery selectors that can be used to specify
-which tests should be discovered or executed.
-
-Discovery selectors can be created programmatically using the factory methods in the
-`{DiscoverySelectors}` class, specified declaratively via annotations when using the
-<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
-generically as strings via their identifiers.
-
-The following discovery selectors are provided out of the box:
-
-|===
-| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
-
-| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
-| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
-| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
-| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
-| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
-| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
-| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
-| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
-| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
-| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
-| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
-| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
-| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
-|===
-
-
-[[running-tests-config-params]]
-=== Configuration Parameters
-
-In addition to instructing the platform which test classes and test engines to include,
-which packages to scan, etc., it is sometimes necessary to provide additional custom
-configuration parameters that are specific to a particular test engine, listener, or
-registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
-parameters_ for the following use cases.
-
-- <<writing-tests-test-instance-lifecycle-changing-default>>
-- <<extensions-registration-automatic-enabling>>
-- <<extensions-conditions-deactivation>>
-- <<writing-tests-display-name-generator-default>>
-
-_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
-engines running on the JUnit Platform via one of the following mechanisms.
-
-1. The `configurationParameter()` and `configurationParameters()` methods in
-   `LauncherDiscoveryRequestBuilder` which
-   is used to build a request supplied to the <<launcher-api, Launcher API>>.
-    +
-   When running tests via one of the tools provided by the JUnit Platform you can specify
-   configuration parameters as follows:
-   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
-     option.
-   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
-     `systemProperties` DSL.
-   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
-     `configurationParameters` property.
-2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
-    +
-   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
-   specify custom configuration files using the `--config-resource` command-line option.
-3. JVM system properties.
-4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
-   in the root of the class path that follows the syntax rules for Java `Properties`
-   files.
-
-NOTE: Configuration parameters are looked up in the exact order defined above.
-Consequently, configuration parameters supplied directly to the `Launcher` take
-precedence over those supplied via custom configuration files, system properties, and the
-default configuration file. Similarly, configuration parameters supplied via system
-properties take precedence over those supplied via the default configuration file.
-
-[[running-tests-config-params-deactivation-pattern]]
-==== Pattern Matching Syntax
-
-This section describes the pattern matching syntax that is applied to the _configuration
-parameters_ used for the following features.
-
-- <<extensions-conditions-deactivation>>
-- <<launcher-api-listeners-custom-deactivation>>
-- <<stacktrace-pruning>>
-- <<extensions-registration-automatic-filtering>>
-
-If the value for the given _configuration parameter_ consists solely of an asterisk
-(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
-will be treated as a comma-separated list of patterns where each pattern will be matched
-against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
-a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
-(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
-pattern will be matched one-to-one against a FQCN.
-
-Examples:
-
-- `+++*+++`: matches all candidate classes.
-- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
-  any of its subpackages.
-- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
-  `MyCustomImpl`.
-- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
-- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
-  `System` or `Unit`.
-- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
-  `org.example.MyCustomImpl`.
-- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
-  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
-
-[[running-tests-tags]]
-=== Tags
-
-Tags are a JUnit Platform concept for marking and filtering tests. The programming model
-for adding tags to containers and tests is defined by the testing framework. For example,
-in JUnit Jupiter based tests, the `@Tag` annotation (see
-<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
-Vintage engine maps `@Category` annotations to tags (see
-<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
-own annotation or other means for users to specify tags.
-
-[[running-tests-tag-syntax-rules]]
-==== Syntax Rules for Tags
-
-Regardless how a tag is specified, the JUnit Platform enforces the following rules:
-
-* A tag must not be `null` or _blank_.
-* A _stripped_ tag must not contain whitespace.
-* A _stripped_ tag must not contain ISO control characters.
-* A _stripped_ tag must not contain any of the following _reserved characters_.
-- `,`: _comma_
-- `(`: _left parenthesis_
-- `)`: _right parenthesis_
-- `&`: _ampersand_
-- `|`: _vertical bar_
-- `!`: _exclamation point_
-
-NOTE: In the above context, "stripped" means that leading and trailing whitespace
-characters have been removed using `java.lang.String.strip()`.
-
-[[running-tests-tag-expressions]]
-==== Tag Expressions
-
-Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
-`(` and `)` can be used to adjust for operator precedence.
-
-Two special expressions are supported, `any()` and `none()`, which select all tests _with_
-any tags at all, and all tests _without_ any tags, respectively.
-These special expressions may be combined with other expressions just like normal tags.
-
-.Operators (in descending order of precedence)
-|===
-| Operator | Meaning | Associativity
-
-| `!`      | not     | right
-| `&`      | and     | left
-| `\|`     | or      | left
-|===
-
-If you are tagging your tests across multiple dimensions, tag expressions help you to
-select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
-_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
-expressions can be useful.
-
-[%header,cols="40,60"]
-|===
-| Tag Expression
-| Selection
-
-| `+++product+++`
-| all tests for *product*
-
-| `+++catalog \| shipping+++`
-| all tests for *catalog* plus all tests for *shipping*
-
-| `+++catalog &amp; shipping+++`
-| all tests for the intersection between *catalog* and *shipping*
-
-| `+++product &amp; !end-to-end+++`
-| all tests for *product*, but not the _end-to-end_ tests
-
-| `+++(micro \| integration) &amp; (product \| shipping)+++`
-| all _micro_ or _integration_ tests for *product* or *shipping*
-|===
-
-[[running-tests-capturing-output]]
-=== Capturing Standard Output/Error
-
-The JUnit Platform provides opt-in support for capturing output printed to `System.out`
-and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
-`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
-parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
-to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
-
-If enabled, the JUnit Platform captures the corresponding output and publishes it as a
-report entry using the `stdout` or `stderr` keys to all registered
-`{TestExecutionListener}` instances immediately before reporting the test or container as
-finished.
-
-Please note that the captured output will only contain output emitted by the thread that
-was used to execute a container or test. Any output by other threads will be omitted
-because particularly when
-<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
-to attribute it to a specific test or container.
-
-[[running-tests-listeners]]
-=== Using Listeners and Interceptors
-
-The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
-and custom user code to react to events fired at various points during the discovery and
-execution of a `TestPlan`.
-
-* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
-  closed.
-* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
-  `LauncherSession`.
-* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
-* `{TestExecutionListener}`: receives events that occur during test execution.
-
-The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
-registered automatically for you in order to support some feature of the build tool or IDE.
-
-The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
-order to produce some form of report or to display a graphical representation of the test
-plan in an IDE. Such listeners may be implemented and automatically registered by a build
-tool or IDE, or they may be included in a third-party library – potentially registered
-for you automatically. You can also implement and register your own listeners.
-
-For details on registering and configuring listeners, see the following sections of this
-guide.
-
-* <<launcher-api-launcher-session-listeners-custom>>
-* <<launcher-api-launcher-interceptors-custom>>
-* <<launcher-api-launcher-discovery-listeners-custom>>
-* <<launcher-api-listeners-custom>>
-* <<launcher-api-listeners-config>>
-* <<launcher-api-listeners-custom-deactivation>>
-
-The JUnit Platform provides the following listeners which you may wish to use with your
-test suite.
-
-<<junit-platform-reporting>> ::
-  `{LegacyXmlReportGeneratingListener}` can be used via the
-  <<running-tests-console-launcher>> or registered manually to generate XML reports
-  compatible with the de facto standard for JUnit 4 based test reports.
-+
-`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
-specified by {OpenTestReporting}. It is auto-registered and can be enabled and
-configured via <<running-tests-config-params>>.
-+
-See <<junit-platform-reporting>> for details.
-
-<<running-tests-listeners-flight-recorder>> ::
-  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
-  Java Flight Recorder events during test discovery and execution.
-
-`{LoggingListener}` ::
-  `TestExecutionListener` for logging informational messages for all events via a
-  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
-
-`{SummaryGeneratingListener}` ::
-  `TestExecutionListener` that generates a summary of the test execution which can be
-  printed via a `PrintWriter`.
-
-`{UniqueIdTrackingListener}` ::
-  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
-  or executed during the execution of the `TestPlan` and generates a file containing the
-  unique IDs once execution of the `TestPlan` has finished.
-
-[[running-tests-listeners-flight-recorder]]
-==== Flight Recorder Support
-
-The JUnit Platform provides opt-in support for generating Flight Recorder events.
-https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
-follows.
-
-> Flight Recorder records events originating from applications, the JVM, and the OS.
-Events are stored in a single file that can be attached to bug reports and examined by
-support engineers, allowing after-the-fact analysis of issues in the period leading up
-to a problem.
-
-In order to record Flight Recorder events generated while running tests, you need to
-start flight recording when launching a test suite via the following java command line
-option.
-
-   -XX:StartFlightRecording:filename=...
-
-Please consult the manual of your build tool for the appropriate commands.
-
-To analyze the recorded events, use the
-https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
-command line tool shipped with recent JDKs or open the recording file with
-https://jdk.java.net/jmc/[JDK Mission Control].
-
-[[stacktrace-pruning]]
-=== Stack Trace Pruning
-
-The JUnit Platform provides built-in support for pruning stack traces produced by failing
-tests. This feature is enabled by default but can be disabled by setting the
-`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
-
-When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
-packages are removed from the stack trace, unless the calls occur after the test itself
-or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
-never be excluded.
-
-In addition, all elements prior to and including the first call from the JUnit Platform
-`Launcher` will be removed.
-
-[[running-tests-discovery-issues]]
-=== Discovery Issues
-
-Test engines may encounter issues during test discovery. For example, the declaration of a
-test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
-Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
-report them with different severity levels:
-
-INFO::
-Indicates that the engine encountered something that could be potentially problematic, but
-could also happen due to a valid setup or configuration.
-
-WARNING::
-Indicates that the engine encountered something that is problematic and might lead to
-unexpected behavior or will be removed or changed in a future release.
-
-ERROR::
-Indicates that the engine encountered something that is definitely problematic and will
-lead to unexpected behavior.
-
-If an engine reports an issue with a severity equal to or higher than a configurable
-_critical_ severity, its tests will not be executed. Instead, the engine will be reported
-as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
-Non-critical issues will be logged but will not prevent the engine from executing its
-tests. The `junit.platform.discovery.issue.severity.critical`
-<<running-tests-config-params, configuration parameter>> can be used to set the critical
-severity level. Currently, the default value is `ERROR` but it may be changed in a future
-release.
-
-TIP: To surface all discovery issues in your project, it is recommended to set the
-`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
-
-In addition, registered `{LauncherDiscoveryListener}` implementations can receive
-discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
-report issues to the user in a more user-friendly way. For example, IDEs may choose to
-display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc b/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc
index 3099a146c2b4..32005494d602 100644
--- a/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc
@@ -1,1183 +1,3 @@
-[[running-tests]]
-== Running Tests
-
-[[running-tests-ide]]
-=== IDE Support
-
-[[running-tests-ide-intellij-idea]]
-==== IntelliJ IDEA
-
-IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
-information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
-however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
-IDEA download the following JARs automatically based on the API version used in the
-project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
-
-In order to use a different JUnit version (e.g., {version}), you may need to
-include the corresponding versions of the `junit-platform-launcher`,
-`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
-
-.Additional Gradle Dependencies
-[source,groovy]
-[subs=attributes+]
-----
-testImplementation(platform("org.junit:junit-bom:{version}"))
-testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
-testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
-----
-
-.Additional Maven Dependencies
-[source,xml]
-[subs=attributes+]
-----
-<!-- ... -->
-<dependencies>
-	<dependency>
-		<groupId>org.junit.platform</groupId>
-		<artifactId>junit-platform-launcher</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.jupiter</groupId>
-		<artifactId>junit-jupiter-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.vintage</groupId>
-		<artifactId>junit-vintage-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-</dependencies>
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-[[running-tests-ide-eclipse]]
-==== Eclipse
-
-Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
-release.
-
-For more information on using JUnit Platform in Eclipse consult the official _Eclipse
-support for JUnit 5_ section of the
-https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
-(4.7.1a) - New and Noteworthy] documentation.
-
-[[running-tests-ide-netbeans]]
-==== NetBeans
-
-NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
-https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
-
-For more information consult the JUnit 5 section of the
-https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
-release notes].
-
-[[running-tests-ide-vscode]]
-==== Visual Studio Code
-
-https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
-Platform via the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
-Runner] extension which is installed by default as part of the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
-Extension Pack].
-
-For more information consult the _Testing_ section of the
-https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
-documentation.
-
-[[running-tests-ide-other]]
-==== Other IDEs
-
-If you are using an editor or IDE other than one of those listed in the previous sections,
-and it doesn't support running tests on the JUnit Platform, you can use the
-<<running-tests-console-launcher>> to run them from the command line.
-
-[[running-tests-build]]
-=== Build Support
-
-[[running-tests-build-gradle]]
-==== Gradle
-
-Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
-https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
-for executing tests on the JUnit Platform. To enable it, you need to specify
-`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform()
-}
-----
-
-Filtering by <<running-tests-tags, tags>>,
-<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform {
-		includeTags("fast", "smoke & feature-a")
-		// excludeTags("slow", "ci")
-		includeEngines("junit-jupiter")
-		// excludeEngines("junit-vintage")
-	}
-}
-----
-
-Please refer to the
-https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
-for a comprehensive list of options.
-
-[[running-tests-build-gradle-bom]]
-===== Aligning dependency versions
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Explicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation(platform("org.junit:junit-bom:{version}"))
-	testImplementation("org.junit.jupiter:junit-jupiter")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-Since all JUnit artifacts declare a
-https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
-you usually don't need to declare an explicit dependency on it yourself. Instead, it's
-sufficient to declare _one_ regular dependency that includes a version number. Gradle will
-then pull in the BOM automatically so you can omit the version for all other JUnit
-artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Implicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
-}
-----
-<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
-<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
-
-[WARNING]
-.Declaring a dependency on junit-platform-launcher
-====
-Even though pre-8.0 versions of Gradle don't require declaring an explicit
-dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
-of JUnit artifacts on the test runtime classpath are aligned.
-
-Moreover, doing so is recommended and in some cases even required when importing the
-project into an IDE like <<running-tests-ide-eclipse>> or
-<<running-tests-ide-intellij-idea>>.
-====
-
-[[running-tests-build-gradle-engines-configure]]
-===== Configuring Test Engines
-
-In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
-
-To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
-on the dependency-aggregating JUnit Jupiter artifact similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Alternatively, you can use Gradle's
-https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
-support.
-
-[source,kotlin,indent=0]
-[subs=attributes+]
-.Kotlin DSL
-----
-testing {
-	suites {
-		named<JvmTestSuite>("test") {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Groovy DSL
-----
-testing {
-	suites {
-		test {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
-dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
-implementation similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("junit:junit:{junit4-version}")
-	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-[[running-tests-build-gradle-config-params]]
-===== Configuration Parameters
-
-The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
-Platform <<running-tests-config-params, configuration parameters>> to influence test
-discovery and execution. However, you can provide configuration parameters within the
-build script via system properties (as shown below) or via the
-`junit-platform.properties` file.
-
-[source,groovy,indent=0]
-----
-test {
-	// ...
-	systemProperty("junit.jupiter.conditions.deactivate", "*")
-	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
-	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
-	// ...
-}
-----
-
-[[running-tests-build-gradle-logging]]
-===== Configuring Logging (optional)
-
-JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
-emit warnings and debug information. Please refer to the official documentation of
-`{LogManager}` for configuration options.
-
-Alternatively, it's possible to redirect log messages to other logging frameworks such as
-{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
-`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
-qualified class name_ of the `{LogManager}` implementation to use. The example below
-demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
-details).
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
-	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
-	systemProperty("log4j2.disableJmx", "true")
-}
-----
-
-Other logging frameworks provide different means to redirect messages logged using
-`java.util.logging`. For example, for {Logback} you can use the
-https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
-dependency to the test runtime classpath.
-
-[[running-tests-build-maven]]
-==== Maven
-
-Maven Surefire and Maven Failsafe provide
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
-for executing tests on the JUnit Platform. The `pom.xml` file in the
-`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
-and can serve as a starting point for configuring your Maven build.
-
-[WARNING]
-.Minimum required version of Maven Surefire/Failsafe
-====
-As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
-====
-
-[[running-tests-build-maven-bom]]
-===== Aligning dependency versions
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-[[running-tests-build-maven-engines-configure]]
-===== Configuring Test Engines
-
-In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
-`TestEngine` implementation must be added to the test classpath.
-
-To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
-on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
-following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>org.junit.jupiter</groupId>
-			<artifactId>junit-jupiter</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
-long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
-`TestEngine` implementation similar to the following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>junit</groupId>
-			<artifactId>junit</artifactId>
-			<version>{junit4-version}</version>
-			<scope>test</scope>
-		</dependency>
-		<dependency>
-			<groupId>org.junit.vintage</groupId>
-			<artifactId>junit-vintage-engine</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-filter-test-class-names]]
-===== Filtering by Test Class Names
-
-The Maven Surefire Plugin will scan for test classes whose fully qualified names match
-the following patterns.
-
-- `+++**/Test*.java+++`
-- `+++**/*Test.java+++`
-- `+++**/*Tests.java+++`
-- `+++**/*TestCase.java+++`
-
-Moreover, it will exclude all nested classes (including static member classes) by default.
-
-Note, however, that you can override this default behavior by configuring explicit
-`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
-from excluding static member classes, you can override its exclude rules as follows.
-
-[source,xml,indent=0]
-[subs=attributes+]
-.Overriding exclude rules of Maven Surefire
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<excludes>
-						<exclude/>
-					</excludes>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Please see the
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
-documentation for Maven Surefire for details.
-
-[[running-tests-build-maven-filter-tags]]
-===== Filtering by Tags
-
-You can filter tests by <<running-tests-tags, tags>> or
-<<running-tests-tag-expressions, tag expressions>> using the following configuration
-properties.
-
-- to include _tags_ or _tag expressions_, use `groups`.
-- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<groups>acceptance | !feature-a</groups>
-					<excludedGroups>integration, regression</excludedGroups>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-config-params]]
-===== Configuration Parameters
-
-You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
-influence test discovery and execution by declaring the `configurationParameters`
-property and providing key-value pairs using the Java `Properties` file syntax (as shown
-below) or via the `junit-platform.properties` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<properties>
-						<configurationParameters>
-							junit.jupiter.conditions.deactivate = *
-							junit.jupiter.extensions.autodetection.enabled = true
-							junit.jupiter.testinstance.lifecycle.default = per_class
-						</configurationParameters>
-					</properties>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-ant]]
-==== Ant
-
-Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
-provides native support for launching tests on the JUnit Platform. The `junitlauncher`
-task is solely responsible for launching the JUnit Platform and passing it the selected
-collection of tests. The JUnit Platform then delegates to registered test engines to
-discover and execute the tests.
-
-The `junitlauncher` task attempts to align as closely as possible with native Ant
-constructs such as
-link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
-for allowing users to select the tests that they want executed by test engines. This gives
-the task a consistent and natural feel when compared to many other core Ant tasks.
-
-Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
-
-The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
-the task and can serve as a starting point.
-
-===== Basic Usage
-
-The following example demonstrates how to configure the `junitlauncher` task to select a
-single test class (i.e., `com.example.project.CalculatorTests`).
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-
-	<!-- ... -->
-
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<test name="com.example.project.CalculatorTests" />
-	</junitlauncher>
-----
-
-The `test` element allows you to specify a single test class that you want to be selected
-and executed. The `classpath` element allows you to specify the classpath to be used to
-launch the JUnit Platform. This classpath will also be used to locate test classes that
-are part of the execution.
-
-The following example demonstrates how to configure the `junitlauncher` task to select
-test classes from multiple locations.
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-	<!-- ... -->
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<testclasses outputdir="${output.dir}">
-			<fileset dir="${build.classes.dir}">
-				<include name="org/example/**/demo/**/" />
-			</fileset>
-			<fileset dir="${some.other.dir}">
-				<include name="org/myapp/**/" />
-			</fileset>
-		</testclasses>
-	</junitlauncher>
-----
-
-In the above example, the `testclasses` element allows you to select multiple test
-classes that reside in different locations.
-
-For further details on usage and configuration options please refer to the official Ant
-documentation for the
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
-
-[[running-tests-build-spring-boot]]
-==== Spring Boot
-
-link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
-managing the version of JUnit used in your project. In addition, the
-`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
-Jupiter, AssertJ, Mockito, etc.
-
-If your build relies on dependency management support from Spring Boot, you should not
-import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
-result in duplicate (and potentially conflicting) management of JUnit dependencies.
-
-If you need to override the version of a dependency used in your Spring Boot application,
-you have to override the exact name of the
-link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
-defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
-Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
-changing a dependency version is documented for both
-link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
-and
-link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
-
-With Gradle you can override the JUnit Jupiter version by including the following in your
-`build.gradle` file.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-	ext['junit-jupiter.version'] = '{version}'
-----
-
-With Maven you can override the JUnit Jupiter version by including the following in your
-`pom.xml` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<properties>
-		<junit-jupiter.version>{version}</junit-jupiter.version>
-	</properties>
-----
-
-[[running-tests-console-launcher]]
-=== Console Launcher
-
-The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
-Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
-Jupiter tests and print test execution results to the console.
-
-An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
-contains the contents of all of its dependencies is published in the {Maven_Central}
-repository under the
-https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
-directory. It contains the contents of the following artifacts:
-
-include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
-
-[NOTE]
-====
-Since the `junit-platform-console-standalone` JAR contains the contents of all of its
-dependencies, its Maven POM does not declare any dependencies.
-
-Furthermore, it is not very likely that you would need to include a dependency on the
-`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
-script. On the contrary, the executable `junit-platform-console-standalone` JAR is
-typically invoked directly from the command line or a shell script without a build script.
-
-If you need to declare dependencies in your build script on some of the artifacts
-contained in the `junit-platform-console-standalone` artifact, you should declare
-dependencies only on the JUnit artifacts that are used in your project. To simplify
-dependency management of JUnit artifacts in your build, you may wish to use the
-`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
-details.
-====
-
-You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
-standalone `ConsoleLauncher` as shown below.
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
-
-├─ JUnit Vintage
-│  └─ example.JUnit4Tests
-│     └─ standardJUnit4Test ✔
-└─ JUnit Jupiter
-   ├─ StandardTests
-   │  ├─ succeedingTest() ✔
-   │  └─ skippedTest() ↷ for demonstration purposes
-   └─ A special test case
-      ├─ Custom test name containing spaces ✔
-      ├─ ╯°□°)╯ ✔
-      └─ 😱 ✔
-
-Test run finished after 64 ms
-[         5 containers found      ]
-[         0 containers skipped    ]
-[         5 containers started    ]
-[         0 containers aborted    ]
-[         5 containers successful ]
-[         0 containers failed     ]
-[         6 tests found           ]
-[         1 tests skipped         ]
-[         5 tests started         ]
-[         0 tests aborted         ]
-[         5 tests successful      ]
-[         0 tests failed          ]
-----
-
-You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
-all jars in a directory):
-
-[source,console,subs=attributes+]
-----
-$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
-----
-
-[[running-tests-console-launcher-options]]
-==== Subcommands and Options
-
-The `{ConsoleLauncher}` provides the following subcommands:
-
-----
-include::{consoleLauncherOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-discovering-tests]]
-===== Discovering tests
-
-----
-include::{consoleLauncherDiscoverOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-executing-tests]]
-===== Executing tests
-
-.Exit Code
-NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
-All non-zero codes indicate an error of some sort. For example, status code `1`
-is returned if any containers or tests failed. If no tests are discovered and the
-`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
-with a status code of `2`. Unexpected or invalid user input yields a status code
-of `3`. An exit code of `-1` indicates an unspecified error condition.
-
-----
-include::{consoleLauncherExecuteOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-listing-test-engines]]
-===== Listing test engines
-
-----
-include::{consoleLauncherEnginesOptionsFile}[]
-----
-
-[[running-tests-console-launcher-argument-files]]
-==== Argument Files (@-files)
-
-On some platforms you may run into system limitations on the length of a command line when
-creating a command line with lots of options or with long arguments.
-
-The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
-are files that themselves contain arguments to be passed to the command. When the
-underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
-argument beginning with the character `@`, it expands the contents of that file into the
-argument list.
-
-The arguments within a file can be separated by spaces or newlines. If an argument
-contains embedded whitespace, the whole argument should be wrapped in double or single
-quotes -- for example, `"-f=My Files/Stuff.java"`.
-
-If the argument file does not exist or cannot be read, the argument will be treated
-literally and will not be removed. This will likely result in an "unmatched argument"
-error message. You can troubleshoot such errors by executing the command with the
-`picocli.trace` system property set to `DEBUG`.
-
-Multiple _@-files_ may be specified on the command line. The specified path may be
-relative to the current directory or absolute.
-
-You can pass a real parameter with an initial `@` character by escaping it with an
-additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
-subject to expansion.
-
-[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
-==== Redirecting Standard Output/Error to Files
-
-You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
-files using the `--redirect-stdout` and `--redirect-stderr` options:
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
-  --redirect-stdout=stdout.txt \
-  --redirect-stderr=stderr.txt
-----
-
-[NOTE]
-====
-If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
-output streams will be redirected to that file.
-
-The default charset is used for writing to the files.
-====
-
-[[running-tests-console-launcher-color-customization]]
-==== Color Customization
-
-The colors used in the output of the `{ConsoleLauncher}` can be customized.
-The option `--single-color` will apply a built-in monochrome style, while
-`--color-palette` will accept a properties file to override the
-https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
-The properties file below demonstrates the default style:
-
-[source,properties,indent=0]
-----
-SUCCESSFUL = 32
-ABORTED = 33
-FAILED = 31
-SKIPPED = 35
-CONTAINER = 35
-TEST = 34
-DYNAMIC = 35
-REPORTED = 37
-----
-
-[[running-tests-source-launcher]]
-=== Source Launcher
-
-Starting with Java 25 it is possible to write minimal source code test programs
-using the `org.junit.start` module. For example, like in a `HelloTests.java`
-file reading:
-
-```java
-import module org.junit.start;
-
-void main() {
-  JUnit.run();
-}
-
-@Test
-void stringLength() {
-  Assertions.assertEquals(11, "Hello JUnit".length());
-}
-```
-With all required modular JAR files available in a local `lib/` directory, the
-following Java 25+ command will discover and execute tests using the JUnit Platform.
-It will also print the result tree to the console.
-
-```shell
-java --module-path lib --add-modules org.junit.start HelloTests.java
-╷
-└─ JUnit Jupiter ✔
-   └─ HelloTests ✔
-      └─ stringLength() ✔
-```
-
-Find JUnit's class API documentation here: {JUnit}
-
-[[running-tests-discovery-selectors]]
-=== Discovery Selectors
-
-The JUnit Platform provides a rich set of discovery selectors that can be used to specify
-which tests should be discovered or executed.
-
-Discovery selectors can be created programmatically using the factory methods in the
-`{DiscoverySelectors}` class, specified declaratively via annotations when using the
-<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
-generically as strings via their identifiers.
-
-The following discovery selectors are provided out of the box:
-
-|===
-| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
-
-| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
-| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
-| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
-| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
-| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
-| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
-| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
-| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
-| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
-| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
-| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
-| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
-| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
-|===
-
-
-[[running-tests-config-params]]
-=== Configuration Parameters
-
-In addition to instructing the platform which test classes and test engines to include,
-which packages to scan, etc., it is sometimes necessary to provide additional custom
-configuration parameters that are specific to a particular test engine, listener, or
-registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
-parameters_ for the following use cases.
-
-- <<writing-tests-test-instance-lifecycle-changing-default>>
-- <<extensions-registration-automatic-enabling>>
-- <<extensions-conditions-deactivation>>
-- <<writing-tests-display-name-generator-default>>
-
-_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
-engines running on the JUnit Platform via one of the following mechanisms.
-
-1. The `configurationParameter()` and `configurationParameters()` methods in
-   `LauncherDiscoveryRequestBuilder` which
-   is used to build a request supplied to the <<launcher-api, Launcher API>>.
-    +
-   When running tests via one of the tools provided by the JUnit Platform you can specify
-   configuration parameters as follows:
-   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
-     option.
-   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
-     `systemProperties` DSL.
-   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
-     `configurationParameters` property.
-2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
-    +
-   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
-   specify custom configuration files using the `--config-resource` command-line option.
-3. JVM system properties.
-4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
-   in the root of the class path that follows the syntax rules for Java `Properties`
-   files.
-
-NOTE: Configuration parameters are looked up in the exact order defined above.
-Consequently, configuration parameters supplied directly to the `Launcher` take
-precedence over those supplied via custom configuration files, system properties, and the
-default configuration file. Similarly, configuration parameters supplied via system
-properties take precedence over those supplied via the default configuration file.
-
-[[running-tests-config-params-deactivation-pattern]]
-==== Pattern Matching Syntax
-
-This section describes the pattern matching syntax that is applied to the _configuration
-parameters_ used for the following features.
-
-- <<extensions-conditions-deactivation>>
-- <<launcher-api-listeners-custom-deactivation>>
-- <<stacktrace-pruning>>
-- <<extensions-registration-automatic-filtering>>
-
-If the value for the given _configuration parameter_ consists solely of an asterisk
-(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
-will be treated as a comma-separated list of patterns where each pattern will be matched
-against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
-a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
-(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
-pattern will be matched one-to-one against a FQCN.
-
-Examples:
-
-- `+++*+++`: matches all candidate classes.
-- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
-  any of its subpackages.
-- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
-  `MyCustomImpl`.
-- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
-- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
-  `System` or `Unit`.
-- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
-  `org.example.MyCustomImpl`.
-- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
-  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
-
-[[running-tests-tags]]
-=== Tags
-
-Tags are a JUnit Platform concept for marking and filtering tests. The programming model
-for adding tags to containers and tests is defined by the testing framework. For example,
-in JUnit Jupiter based tests, the `@Tag` annotation (see
-<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
-Vintage engine maps `@Category` annotations to tags (see
-<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
-own annotation or other means for users to specify tags.
-
-[[running-tests-tag-syntax-rules]]
-==== Syntax Rules for Tags
-
-Regardless how a tag is specified, the JUnit Platform enforces the following rules:
-
-* A tag must not be `null` or _blank_.
-* A _stripped_ tag must not contain whitespace.
-* A _stripped_ tag must not contain ISO control characters.
-* A _stripped_ tag must not contain any of the following _reserved characters_.
-- `,`: _comma_
-- `(`: _left parenthesis_
-- `)`: _right parenthesis_
-- `&`: _ampersand_
-- `|`: _vertical bar_
-- `!`: _exclamation point_
-
-NOTE: In the above context, "stripped" means that leading and trailing whitespace
-characters have been removed using `java.lang.String.strip()`.
-
-[[running-tests-tag-expressions]]
-==== Tag Expressions
-
-Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
-`(` and `)` can be used to adjust for operator precedence.
-
-Two special expressions are supported, `any()` and `none()`, which select all tests _with_
-any tags at all, and all tests _without_ any tags, respectively.
-These special expressions may be combined with other expressions just like normal tags.
-
-.Operators (in descending order of precedence)
-|===
-| Operator | Meaning | Associativity
-
-| `!`      | not     | right
-| `&`      | and     | left
-| `\|`     | or      | left
-|===
-
-If you are tagging your tests across multiple dimensions, tag expressions help you to
-select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
-_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
-expressions can be useful.
-
-[%header,cols="40,60"]
-|===
-| Tag Expression
-| Selection
-
-| `+++product+++`
-| all tests for *product*
-
-| `+++catalog \| shipping+++`
-| all tests for *catalog* plus all tests for *shipping*
-
-| `+++catalog &amp; shipping+++`
-| all tests for the intersection between *catalog* and *shipping*
-
-| `+++product &amp; !end-to-end+++`
-| all tests for *product*, but not the _end-to-end_ tests
-
-| `+++(micro \| integration) &amp; (product \| shipping)+++`
-| all _micro_ or _integration_ tests for *product* or *shipping*
-|===
-
-[[running-tests-capturing-output]]
-=== Capturing Standard Output/Error
-
-The JUnit Platform provides opt-in support for capturing output printed to `System.out`
-and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
-`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
-parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
-to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
-
-If enabled, the JUnit Platform captures the corresponding output and publishes it as a
-report entry using the `stdout` or `stderr` keys to all registered
-`{TestExecutionListener}` instances immediately before reporting the test or container as
-finished.
-
-Please note that the captured output will only contain output emitted by the thread that
-was used to execute a container or test. Any output by other threads will be omitted
-because particularly when
-<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
-to attribute it to a specific test or container.
-
-[[running-tests-listeners]]
-=== Using Listeners and Interceptors
-
-The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
-and custom user code to react to events fired at various points during the discovery and
-execution of a `TestPlan`.
-
-* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
-  closed.
-* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
-  `LauncherSession`.
-* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
-* `{TestExecutionListener}`: receives events that occur during test execution.
-
-The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
-registered automatically for you in order to support some feature of the build tool or IDE.
-
-The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
-order to produce some form of report or to display a graphical representation of the test
-plan in an IDE. Such listeners may be implemented and automatically registered by a build
-tool or IDE, or they may be included in a third-party library – potentially registered
-for you automatically. You can also implement and register your own listeners.
-
-For details on registering and configuring listeners, see the following sections of this
-guide.
-
-* <<launcher-api-launcher-session-listeners-custom>>
-* <<launcher-api-launcher-interceptors-custom>>
-* <<launcher-api-launcher-discovery-listeners-custom>>
-* <<launcher-api-listeners-custom>>
-* <<launcher-api-listeners-config>>
-* <<launcher-api-listeners-custom-deactivation>>
-
-The JUnit Platform provides the following listeners which you may wish to use with your
-test suite.
-
-<<junit-platform-reporting>> ::
-  `{LegacyXmlReportGeneratingListener}` can be used via the
-  <<running-tests-console-launcher>> or registered manually to generate XML reports
-  compatible with the de facto standard for JUnit 4 based test reports.
-+
-`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
-specified by {OpenTestReporting}. It is auto-registered and can be enabled and
-configured via <<running-tests-config-params>>.
-+
-See <<junit-platform-reporting>> for details.
-
-<<running-tests-listeners-flight-recorder>> ::
-  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
-  Java Flight Recorder events during test discovery and execution.
-
-`{LoggingListener}` ::
-  `TestExecutionListener` for logging informational messages for all events via a
-  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
-
-`{SummaryGeneratingListener}` ::
-  `TestExecutionListener` that generates a summary of the test execution which can be
-  printed via a `PrintWriter`.
-
-`{UniqueIdTrackingListener}` ::
-  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
-  or executed during the execution of the `TestPlan` and generates a file containing the
-  unique IDs once execution of the `TestPlan` has finished.
-
-[[running-tests-listeners-flight-recorder]]
-==== Flight Recorder Support
-
-The JUnit Platform provides opt-in support for generating Flight Recorder events.
-https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
-follows.
-
-> Flight Recorder records events originating from applications, the JVM, and the OS.
-Events are stored in a single file that can be attached to bug reports and examined by
-support engineers, allowing after-the-fact analysis of issues in the period leading up
-to a problem.
-
-In order to record Flight Recorder events generated while running tests, you need to
-start flight recording when launching a test suite via the following java command line
-option.
-
-   -XX:StartFlightRecording:filename=...
-
-Please consult the manual of your build tool for the appropriate commands.
-
-To analyze the recorded events, use the
-https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
-command line tool shipped with recent JDKs or open the recording file with
-https://jdk.java.net/jmc/[JDK Mission Control].
-
-[[stacktrace-pruning]]
-=== Stack Trace Pruning
-
-The JUnit Platform provides built-in support for pruning stack traces produced by failing
-tests. This feature is enabled by default but can be disabled by setting the
-`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
-
-When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
-packages are removed from the stack trace, unless the calls occur after the test itself
-or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
-never be excluded.
-
-In addition, all elements prior to and including the first call from the JUnit Platform
-`Launcher` will be removed.
-
 [[running-tests-discovery-issues]]
 === Discovery Issues
 
diff --git a/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc b/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc
index 3099a146c2b4..3e912914dd0d 100644
--- a/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc
@@ -1,874 +1,3 @@
-[[running-tests]]
-== Running Tests
-
-[[running-tests-ide]]
-=== IDE Support
-
-[[running-tests-ide-intellij-idea]]
-==== IntelliJ IDEA
-
-IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
-information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
-however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
-IDEA download the following JARs automatically based on the API version used in the
-project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
-
-In order to use a different JUnit version (e.g., {version}), you may need to
-include the corresponding versions of the `junit-platform-launcher`,
-`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
-
-.Additional Gradle Dependencies
-[source,groovy]
-[subs=attributes+]
-----
-testImplementation(platform("org.junit:junit-bom:{version}"))
-testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
-testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
-----
-
-.Additional Maven Dependencies
-[source,xml]
-[subs=attributes+]
-----
-<!-- ... -->
-<dependencies>
-	<dependency>
-		<groupId>org.junit.platform</groupId>
-		<artifactId>junit-platform-launcher</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.jupiter</groupId>
-		<artifactId>junit-jupiter-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.vintage</groupId>
-		<artifactId>junit-vintage-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-</dependencies>
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-[[running-tests-ide-eclipse]]
-==== Eclipse
-
-Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
-release.
-
-For more information on using JUnit Platform in Eclipse consult the official _Eclipse
-support for JUnit 5_ section of the
-https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
-(4.7.1a) - New and Noteworthy] documentation.
-
-[[running-tests-ide-netbeans]]
-==== NetBeans
-
-NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
-https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
-
-For more information consult the JUnit 5 section of the
-https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
-release notes].
-
-[[running-tests-ide-vscode]]
-==== Visual Studio Code
-
-https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
-Platform via the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
-Runner] extension which is installed by default as part of the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
-Extension Pack].
-
-For more information consult the _Testing_ section of the
-https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
-documentation.
-
-[[running-tests-ide-other]]
-==== Other IDEs
-
-If you are using an editor or IDE other than one of those listed in the previous sections,
-and it doesn't support running tests on the JUnit Platform, you can use the
-<<running-tests-console-launcher>> to run them from the command line.
-
-[[running-tests-build]]
-=== Build Support
-
-[[running-tests-build-gradle]]
-==== Gradle
-
-Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
-https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
-for executing tests on the JUnit Platform. To enable it, you need to specify
-`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform()
-}
-----
-
-Filtering by <<running-tests-tags, tags>>,
-<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform {
-		includeTags("fast", "smoke & feature-a")
-		// excludeTags("slow", "ci")
-		includeEngines("junit-jupiter")
-		// excludeEngines("junit-vintage")
-	}
-}
-----
-
-Please refer to the
-https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
-for a comprehensive list of options.
-
-[[running-tests-build-gradle-bom]]
-===== Aligning dependency versions
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Explicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation(platform("org.junit:junit-bom:{version}"))
-	testImplementation("org.junit.jupiter:junit-jupiter")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-Since all JUnit artifacts declare a
-https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
-you usually don't need to declare an explicit dependency on it yourself. Instead, it's
-sufficient to declare _one_ regular dependency that includes a version number. Gradle will
-then pull in the BOM automatically so you can omit the version for all other JUnit
-artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Implicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
-}
-----
-<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
-<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
-
-[WARNING]
-.Declaring a dependency on junit-platform-launcher
-====
-Even though pre-8.0 versions of Gradle don't require declaring an explicit
-dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
-of JUnit artifacts on the test runtime classpath are aligned.
-
-Moreover, doing so is recommended and in some cases even required when importing the
-project into an IDE like <<running-tests-ide-eclipse>> or
-<<running-tests-ide-intellij-idea>>.
-====
-
-[[running-tests-build-gradle-engines-configure]]
-===== Configuring Test Engines
-
-In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
-
-To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
-on the dependency-aggregating JUnit Jupiter artifact similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Alternatively, you can use Gradle's
-https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
-support.
-
-[source,kotlin,indent=0]
-[subs=attributes+]
-.Kotlin DSL
-----
-testing {
-	suites {
-		named<JvmTestSuite>("test") {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Groovy DSL
-----
-testing {
-	suites {
-		test {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
-dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
-implementation similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("junit:junit:{junit4-version}")
-	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-[[running-tests-build-gradle-config-params]]
-===== Configuration Parameters
-
-The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
-Platform <<running-tests-config-params, configuration parameters>> to influence test
-discovery and execution. However, you can provide configuration parameters within the
-build script via system properties (as shown below) or via the
-`junit-platform.properties` file.
-
-[source,groovy,indent=0]
-----
-test {
-	// ...
-	systemProperty("junit.jupiter.conditions.deactivate", "*")
-	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
-	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
-	// ...
-}
-----
-
-[[running-tests-build-gradle-logging]]
-===== Configuring Logging (optional)
-
-JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
-emit warnings and debug information. Please refer to the official documentation of
-`{LogManager}` for configuration options.
-
-Alternatively, it's possible to redirect log messages to other logging frameworks such as
-{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
-`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
-qualified class name_ of the `{LogManager}` implementation to use. The example below
-demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
-details).
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
-	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
-	systemProperty("log4j2.disableJmx", "true")
-}
-----
-
-Other logging frameworks provide different means to redirect messages logged using
-`java.util.logging`. For example, for {Logback} you can use the
-https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
-dependency to the test runtime classpath.
-
-[[running-tests-build-maven]]
-==== Maven
-
-Maven Surefire and Maven Failsafe provide
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
-for executing tests on the JUnit Platform. The `pom.xml` file in the
-`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
-and can serve as a starting point for configuring your Maven build.
-
-[WARNING]
-.Minimum required version of Maven Surefire/Failsafe
-====
-As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
-====
-
-[[running-tests-build-maven-bom]]
-===== Aligning dependency versions
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-[[running-tests-build-maven-engines-configure]]
-===== Configuring Test Engines
-
-In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
-`TestEngine` implementation must be added to the test classpath.
-
-To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
-on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
-following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>org.junit.jupiter</groupId>
-			<artifactId>junit-jupiter</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
-long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
-`TestEngine` implementation similar to the following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>junit</groupId>
-			<artifactId>junit</artifactId>
-			<version>{junit4-version}</version>
-			<scope>test</scope>
-		</dependency>
-		<dependency>
-			<groupId>org.junit.vintage</groupId>
-			<artifactId>junit-vintage-engine</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-filter-test-class-names]]
-===== Filtering by Test Class Names
-
-The Maven Surefire Plugin will scan for test classes whose fully qualified names match
-the following patterns.
-
-- `+++**/Test*.java+++`
-- `+++**/*Test.java+++`
-- `+++**/*Tests.java+++`
-- `+++**/*TestCase.java+++`
-
-Moreover, it will exclude all nested classes (including static member classes) by default.
-
-Note, however, that you can override this default behavior by configuring explicit
-`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
-from excluding static member classes, you can override its exclude rules as follows.
-
-[source,xml,indent=0]
-[subs=attributes+]
-.Overriding exclude rules of Maven Surefire
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<excludes>
-						<exclude/>
-					</excludes>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Please see the
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
-documentation for Maven Surefire for details.
-
-[[running-tests-build-maven-filter-tags]]
-===== Filtering by Tags
-
-You can filter tests by <<running-tests-tags, tags>> or
-<<running-tests-tag-expressions, tag expressions>> using the following configuration
-properties.
-
-- to include _tags_ or _tag expressions_, use `groups`.
-- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<groups>acceptance | !feature-a</groups>
-					<excludedGroups>integration, regression</excludedGroups>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-config-params]]
-===== Configuration Parameters
-
-You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
-influence test discovery and execution by declaring the `configurationParameters`
-property and providing key-value pairs using the Java `Properties` file syntax (as shown
-below) or via the `junit-platform.properties` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<properties>
-						<configurationParameters>
-							junit.jupiter.conditions.deactivate = *
-							junit.jupiter.extensions.autodetection.enabled = true
-							junit.jupiter.testinstance.lifecycle.default = per_class
-						</configurationParameters>
-					</properties>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-ant]]
-==== Ant
-
-Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
-provides native support for launching tests on the JUnit Platform. The `junitlauncher`
-task is solely responsible for launching the JUnit Platform and passing it the selected
-collection of tests. The JUnit Platform then delegates to registered test engines to
-discover and execute the tests.
-
-The `junitlauncher` task attempts to align as closely as possible with native Ant
-constructs such as
-link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
-for allowing users to select the tests that they want executed by test engines. This gives
-the task a consistent and natural feel when compared to many other core Ant tasks.
-
-Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
-
-The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
-the task and can serve as a starting point.
-
-===== Basic Usage
-
-The following example demonstrates how to configure the `junitlauncher` task to select a
-single test class (i.e., `com.example.project.CalculatorTests`).
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-
-	<!-- ... -->
-
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<test name="com.example.project.CalculatorTests" />
-	</junitlauncher>
-----
-
-The `test` element allows you to specify a single test class that you want to be selected
-and executed. The `classpath` element allows you to specify the classpath to be used to
-launch the JUnit Platform. This classpath will also be used to locate test classes that
-are part of the execution.
-
-The following example demonstrates how to configure the `junitlauncher` task to select
-test classes from multiple locations.
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-	<!-- ... -->
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<testclasses outputdir="${output.dir}">
-			<fileset dir="${build.classes.dir}">
-				<include name="org/example/**/demo/**/" />
-			</fileset>
-			<fileset dir="${some.other.dir}">
-				<include name="org/myapp/**/" />
-			</fileset>
-		</testclasses>
-	</junitlauncher>
-----
-
-In the above example, the `testclasses` element allows you to select multiple test
-classes that reside in different locations.
-
-For further details on usage and configuration options please refer to the official Ant
-documentation for the
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
-
-[[running-tests-build-spring-boot]]
-==== Spring Boot
-
-link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
-managing the version of JUnit used in your project. In addition, the
-`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
-Jupiter, AssertJ, Mockito, etc.
-
-If your build relies on dependency management support from Spring Boot, you should not
-import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
-result in duplicate (and potentially conflicting) management of JUnit dependencies.
-
-If you need to override the version of a dependency used in your Spring Boot application,
-you have to override the exact name of the
-link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
-defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
-Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
-changing a dependency version is documented for both
-link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
-and
-link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
-
-With Gradle you can override the JUnit Jupiter version by including the following in your
-`build.gradle` file.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-	ext['junit-jupiter.version'] = '{version}'
-----
-
-With Maven you can override the JUnit Jupiter version by including the following in your
-`pom.xml` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<properties>
-		<junit-jupiter.version>{version}</junit-jupiter.version>
-	</properties>
-----
-
-[[running-tests-console-launcher]]
-=== Console Launcher
-
-The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
-Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
-Jupiter tests and print test execution results to the console.
-
-An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
-contains the contents of all of its dependencies is published in the {Maven_Central}
-repository under the
-https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
-directory. It contains the contents of the following artifacts:
-
-include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
-
-[NOTE]
-====
-Since the `junit-platform-console-standalone` JAR contains the contents of all of its
-dependencies, its Maven POM does not declare any dependencies.
-
-Furthermore, it is not very likely that you would need to include a dependency on the
-`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
-script. On the contrary, the executable `junit-platform-console-standalone` JAR is
-typically invoked directly from the command line or a shell script without a build script.
-
-If you need to declare dependencies in your build script on some of the artifacts
-contained in the `junit-platform-console-standalone` artifact, you should declare
-dependencies only on the JUnit artifacts that are used in your project. To simplify
-dependency management of JUnit artifacts in your build, you may wish to use the
-`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
-details.
-====
-
-You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
-standalone `ConsoleLauncher` as shown below.
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
-
-├─ JUnit Vintage
-│  └─ example.JUnit4Tests
-│     └─ standardJUnit4Test ✔
-└─ JUnit Jupiter
-   ├─ StandardTests
-   │  ├─ succeedingTest() ✔
-   │  └─ skippedTest() ↷ for demonstration purposes
-   └─ A special test case
-      ├─ Custom test name containing spaces ✔
-      ├─ ╯°□°)╯ ✔
-      └─ 😱 ✔
-
-Test run finished after 64 ms
-[         5 containers found      ]
-[         0 containers skipped    ]
-[         5 containers started    ]
-[         0 containers aborted    ]
-[         5 containers successful ]
-[         0 containers failed     ]
-[         6 tests found           ]
-[         1 tests skipped         ]
-[         5 tests started         ]
-[         0 tests aborted         ]
-[         5 tests successful      ]
-[         0 tests failed          ]
-----
-
-You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
-all jars in a directory):
-
-[source,console,subs=attributes+]
-----
-$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
-----
-
-[[running-tests-console-launcher-options]]
-==== Subcommands and Options
-
-The `{ConsoleLauncher}` provides the following subcommands:
-
-----
-include::{consoleLauncherOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-discovering-tests]]
-===== Discovering tests
-
-----
-include::{consoleLauncherDiscoverOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-executing-tests]]
-===== Executing tests
-
-.Exit Code
-NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
-All non-zero codes indicate an error of some sort. For example, status code `1`
-is returned if any containers or tests failed. If no tests are discovered and the
-`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
-with a status code of `2`. Unexpected or invalid user input yields a status code
-of `3`. An exit code of `-1` indicates an unspecified error condition.
-
-----
-include::{consoleLauncherExecuteOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-listing-test-engines]]
-===== Listing test engines
-
-----
-include::{consoleLauncherEnginesOptionsFile}[]
-----
-
-[[running-tests-console-launcher-argument-files]]
-==== Argument Files (@-files)
-
-On some platforms you may run into system limitations on the length of a command line when
-creating a command line with lots of options or with long arguments.
-
-The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
-are files that themselves contain arguments to be passed to the command. When the
-underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
-argument beginning with the character `@`, it expands the contents of that file into the
-argument list.
-
-The arguments within a file can be separated by spaces or newlines. If an argument
-contains embedded whitespace, the whole argument should be wrapped in double or single
-quotes -- for example, `"-f=My Files/Stuff.java"`.
-
-If the argument file does not exist or cannot be read, the argument will be treated
-literally and will not be removed. This will likely result in an "unmatched argument"
-error message. You can troubleshoot such errors by executing the command with the
-`picocli.trace` system property set to `DEBUG`.
-
-Multiple _@-files_ may be specified on the command line. The specified path may be
-relative to the current directory or absolute.
-
-You can pass a real parameter with an initial `@` character by escaping it with an
-additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
-subject to expansion.
-
-[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
-==== Redirecting Standard Output/Error to Files
-
-You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
-files using the `--redirect-stdout` and `--redirect-stderr` options:
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
-  --redirect-stdout=stdout.txt \
-  --redirect-stderr=stderr.txt
-----
-
-[NOTE]
-====
-If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
-output streams will be redirected to that file.
-
-The default charset is used for writing to the files.
-====
-
-[[running-tests-console-launcher-color-customization]]
-==== Color Customization
-
-The colors used in the output of the `{ConsoleLauncher}` can be customized.
-The option `--single-color` will apply a built-in monochrome style, while
-`--color-palette` will accept a properties file to override the
-https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
-The properties file below demonstrates the default style:
-
-[source,properties,indent=0]
-----
-SUCCESSFUL = 32
-ABORTED = 33
-FAILED = 31
-SKIPPED = 35
-CONTAINER = 35
-TEST = 34
-DYNAMIC = 35
-REPORTED = 37
-----
-
-[[running-tests-source-launcher]]
-=== Source Launcher
-
-Starting with Java 25 it is possible to write minimal source code test programs
-using the `org.junit.start` module. For example, like in a `HelloTests.java`
-file reading:
-
-```java
-import module org.junit.start;
-
-void main() {
-  JUnit.run();
-}
-
-@Test
-void stringLength() {
-  Assertions.assertEquals(11, "Hello JUnit".length());
-}
-```
-With all required modular JAR files available in a local `lib/` directory, the
-following Java 25+ command will discover and execute tests using the JUnit Platform.
-It will also print the result tree to the console.
-
-```shell
-java --module-path lib --add-modules org.junit.start HelloTests.java
-╷
-└─ JUnit Jupiter ✔
-   └─ HelloTests ✔
-      └─ stringLength() ✔
-```
-
-Find JUnit's class API documentation here: {JUnit}
-
 [[running-tests-discovery-selectors]]
 === Discovery Selectors
 
@@ -901,316 +30,3 @@ The following discovery selectors are provided out of the box:
 |===
 
 
-[[running-tests-config-params]]
-=== Configuration Parameters
-
-In addition to instructing the platform which test classes and test engines to include,
-which packages to scan, etc., it is sometimes necessary to provide additional custom
-configuration parameters that are specific to a particular test engine, listener, or
-registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
-parameters_ for the following use cases.
-
-- <<writing-tests-test-instance-lifecycle-changing-default>>
-- <<extensions-registration-automatic-enabling>>
-- <<extensions-conditions-deactivation>>
-- <<writing-tests-display-name-generator-default>>
-
-_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
-engines running on the JUnit Platform via one of the following mechanisms.
-
-1. The `configurationParameter()` and `configurationParameters()` methods in
-   `LauncherDiscoveryRequestBuilder` which
-   is used to build a request supplied to the <<launcher-api, Launcher API>>.
-    +
-   When running tests via one of the tools provided by the JUnit Platform you can specify
-   configuration parameters as follows:
-   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
-     option.
-   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
-     `systemProperties` DSL.
-   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
-     `configurationParameters` property.
-2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
-    +
-   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
-   specify custom configuration files using the `--config-resource` command-line option.
-3. JVM system properties.
-4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
-   in the root of the class path that follows the syntax rules for Java `Properties`
-   files.
-
-NOTE: Configuration parameters are looked up in the exact order defined above.
-Consequently, configuration parameters supplied directly to the `Launcher` take
-precedence over those supplied via custom configuration files, system properties, and the
-default configuration file. Similarly, configuration parameters supplied via system
-properties take precedence over those supplied via the default configuration file.
-
-[[running-tests-config-params-deactivation-pattern]]
-==== Pattern Matching Syntax
-
-This section describes the pattern matching syntax that is applied to the _configuration
-parameters_ used for the following features.
-
-- <<extensions-conditions-deactivation>>
-- <<launcher-api-listeners-custom-deactivation>>
-- <<stacktrace-pruning>>
-- <<extensions-registration-automatic-filtering>>
-
-If the value for the given _configuration parameter_ consists solely of an asterisk
-(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
-will be treated as a comma-separated list of patterns where each pattern will be matched
-against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
-a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
-(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
-pattern will be matched one-to-one against a FQCN.
-
-Examples:
-
-- `+++*+++`: matches all candidate classes.
-- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
-  any of its subpackages.
-- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
-  `MyCustomImpl`.
-- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
-- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
-  `System` or `Unit`.
-- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
-  `org.example.MyCustomImpl`.
-- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
-  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
-
-[[running-tests-tags]]
-=== Tags
-
-Tags are a JUnit Platform concept for marking and filtering tests. The programming model
-for adding tags to containers and tests is defined by the testing framework. For example,
-in JUnit Jupiter based tests, the `@Tag` annotation (see
-<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
-Vintage engine maps `@Category` annotations to tags (see
-<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
-own annotation or other means for users to specify tags.
-
-[[running-tests-tag-syntax-rules]]
-==== Syntax Rules for Tags
-
-Regardless how a tag is specified, the JUnit Platform enforces the following rules:
-
-* A tag must not be `null` or _blank_.
-* A _stripped_ tag must not contain whitespace.
-* A _stripped_ tag must not contain ISO control characters.
-* A _stripped_ tag must not contain any of the following _reserved characters_.
-- `,`: _comma_
-- `(`: _left parenthesis_
-- `)`: _right parenthesis_
-- `&`: _ampersand_
-- `|`: _vertical bar_
-- `!`: _exclamation point_
-
-NOTE: In the above context, "stripped" means that leading and trailing whitespace
-characters have been removed using `java.lang.String.strip()`.
-
-[[running-tests-tag-expressions]]
-==== Tag Expressions
-
-Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
-`(` and `)` can be used to adjust for operator precedence.
-
-Two special expressions are supported, `any()` and `none()`, which select all tests _with_
-any tags at all, and all tests _without_ any tags, respectively.
-These special expressions may be combined with other expressions just like normal tags.
-
-.Operators (in descending order of precedence)
-|===
-| Operator | Meaning | Associativity
-
-| `!`      | not     | right
-| `&`      | and     | left
-| `\|`     | or      | left
-|===
-
-If you are tagging your tests across multiple dimensions, tag expressions help you to
-select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
-_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
-expressions can be useful.
-
-[%header,cols="40,60"]
-|===
-| Tag Expression
-| Selection
-
-| `+++product+++`
-| all tests for *product*
-
-| `+++catalog \| shipping+++`
-| all tests for *catalog* plus all tests for *shipping*
-
-| `+++catalog &amp; shipping+++`
-| all tests for the intersection between *catalog* and *shipping*
-
-| `+++product &amp; !end-to-end+++`
-| all tests for *product*, but not the _end-to-end_ tests
-
-| `+++(micro \| integration) &amp; (product \| shipping)+++`
-| all _micro_ or _integration_ tests for *product* or *shipping*
-|===
-
-[[running-tests-capturing-output]]
-=== Capturing Standard Output/Error
-
-The JUnit Platform provides opt-in support for capturing output printed to `System.out`
-and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
-`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
-parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
-to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
-
-If enabled, the JUnit Platform captures the corresponding output and publishes it as a
-report entry using the `stdout` or `stderr` keys to all registered
-`{TestExecutionListener}` instances immediately before reporting the test or container as
-finished.
-
-Please note that the captured output will only contain output emitted by the thread that
-was used to execute a container or test. Any output by other threads will be omitted
-because particularly when
-<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
-to attribute it to a specific test or container.
-
-[[running-tests-listeners]]
-=== Using Listeners and Interceptors
-
-The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
-and custom user code to react to events fired at various points during the discovery and
-execution of a `TestPlan`.
-
-* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
-  closed.
-* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
-  `LauncherSession`.
-* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
-* `{TestExecutionListener}`: receives events that occur during test execution.
-
-The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
-registered automatically for you in order to support some feature of the build tool or IDE.
-
-The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
-order to produce some form of report or to display a graphical representation of the test
-plan in an IDE. Such listeners may be implemented and automatically registered by a build
-tool or IDE, or they may be included in a third-party library – potentially registered
-for you automatically. You can also implement and register your own listeners.
-
-For details on registering and configuring listeners, see the following sections of this
-guide.
-
-* <<launcher-api-launcher-session-listeners-custom>>
-* <<launcher-api-launcher-interceptors-custom>>
-* <<launcher-api-launcher-discovery-listeners-custom>>
-* <<launcher-api-listeners-custom>>
-* <<launcher-api-listeners-config>>
-* <<launcher-api-listeners-custom-deactivation>>
-
-The JUnit Platform provides the following listeners which you may wish to use with your
-test suite.
-
-<<junit-platform-reporting>> ::
-  `{LegacyXmlReportGeneratingListener}` can be used via the
-  <<running-tests-console-launcher>> or registered manually to generate XML reports
-  compatible with the de facto standard for JUnit 4 based test reports.
-+
-`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
-specified by {OpenTestReporting}. It is auto-registered and can be enabled and
-configured via <<running-tests-config-params>>.
-+
-See <<junit-platform-reporting>> for details.
-
-<<running-tests-listeners-flight-recorder>> ::
-  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
-  Java Flight Recorder events during test discovery and execution.
-
-`{LoggingListener}` ::
-  `TestExecutionListener` for logging informational messages for all events via a
-  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
-
-`{SummaryGeneratingListener}` ::
-  `TestExecutionListener` that generates a summary of the test execution which can be
-  printed via a `PrintWriter`.
-
-`{UniqueIdTrackingListener}` ::
-  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
-  or executed during the execution of the `TestPlan` and generates a file containing the
-  unique IDs once execution of the `TestPlan` has finished.
-
-[[running-tests-listeners-flight-recorder]]
-==== Flight Recorder Support
-
-The JUnit Platform provides opt-in support for generating Flight Recorder events.
-https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
-follows.
-
-> Flight Recorder records events originating from applications, the JVM, and the OS.
-Events are stored in a single file that can be attached to bug reports and examined by
-support engineers, allowing after-the-fact analysis of issues in the period leading up
-to a problem.
-
-In order to record Flight Recorder events generated while running tests, you need to
-start flight recording when launching a test suite via the following java command line
-option.
-
-   -XX:StartFlightRecording:filename=...
-
-Please consult the manual of your build tool for the appropriate commands.
-
-To analyze the recorded events, use the
-https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
-command line tool shipped with recent JDKs or open the recording file with
-https://jdk.java.net/jmc/[JDK Mission Control].
-
-[[stacktrace-pruning]]
-=== Stack Trace Pruning
-
-The JUnit Platform provides built-in support for pruning stack traces produced by failing
-tests. This feature is enabled by default but can be disabled by setting the
-`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
-
-When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
-packages are removed from the stack trace, unless the calls occur after the test itself
-or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
-never be excluded.
-
-In addition, all elements prior to and including the first call from the JUnit Platform
-`Launcher` will be removed.
-
-[[running-tests-discovery-issues]]
-=== Discovery Issues
-
-Test engines may encounter issues during test discovery. For example, the declaration of a
-test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
-Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
-report them with different severity levels:
-
-INFO::
-Indicates that the engine encountered something that could be potentially problematic, but
-could also happen due to a valid setup or configuration.
-
-WARNING::
-Indicates that the engine encountered something that is problematic and might lead to
-unexpected behavior or will be removed or changed in a future release.
-
-ERROR::
-Indicates that the engine encountered something that is definitely problematic and will
-lead to unexpected behavior.
-
-If an engine reports an issue with a severity equal to or higher than a configurable
-_critical_ severity, its tests will not be executed. Instead, the engine will be reported
-as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
-Non-critical issues will be logged but will not prevent the engine from executing its
-tests. The `junit.platform.discovery.issue.severity.critical`
-<<running-tests-config-params, configuration parameter>> can be used to set the critical
-severity level. Currently, the default value is `ERROR` but it may be changed in a future
-release.
-
-TIP: To surface all discovery issues in your project, it is recommended to set the
-`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
-
-In addition, registered `{LauncherDiscoveryListener}` implementations can receive
-discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
-report issues to the user in a more user-friendly way. For example, IDEs may choose to
-display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/ide-support.adoc b/documentation/modules/ROOT/pages/running-tests/ide-support.adoc
index 3099a146c2b4..b05f7483572a 100644
--- a/documentation/modules/ROOT/pages/running-tests/ide-support.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/ide-support.adoc
@@ -1,6 +1,3 @@
-[[running-tests]]
-== Running Tests
-
 [[running-tests-ide]]
 === IDE Support
 
@@ -104,1113 +101,3 @@ If you are using an editor or IDE other than one of those listed in the previous
 and it doesn't support running tests on the JUnit Platform, you can use the
 <<running-tests-console-launcher>> to run them from the command line.
 
-[[running-tests-build]]
-=== Build Support
-
-[[running-tests-build-gradle]]
-==== Gradle
-
-Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
-https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
-for executing tests on the JUnit Platform. To enable it, you need to specify
-`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform()
-}
-----
-
-Filtering by <<running-tests-tags, tags>>,
-<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform {
-		includeTags("fast", "smoke & feature-a")
-		// excludeTags("slow", "ci")
-		includeEngines("junit-jupiter")
-		// excludeEngines("junit-vintage")
-	}
-}
-----
-
-Please refer to the
-https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
-for a comprehensive list of options.
-
-[[running-tests-build-gradle-bom]]
-===== Aligning dependency versions
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Explicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation(platform("org.junit:junit-bom:{version}"))
-	testImplementation("org.junit.jupiter:junit-jupiter")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-Since all JUnit artifacts declare a
-https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
-you usually don't need to declare an explicit dependency on it yourself. Instead, it's
-sufficient to declare _one_ regular dependency that includes a version number. Gradle will
-then pull in the BOM automatically so you can omit the version for all other JUnit
-artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Implicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
-}
-----
-<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
-<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
-
-[WARNING]
-.Declaring a dependency on junit-platform-launcher
-====
-Even though pre-8.0 versions of Gradle don't require declaring an explicit
-dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
-of JUnit artifacts on the test runtime classpath are aligned.
-
-Moreover, doing so is recommended and in some cases even required when importing the
-project into an IDE like <<running-tests-ide-eclipse>> or
-<<running-tests-ide-intellij-idea>>.
-====
-
-[[running-tests-build-gradle-engines-configure]]
-===== Configuring Test Engines
-
-In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
-
-To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
-on the dependency-aggregating JUnit Jupiter artifact similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Alternatively, you can use Gradle's
-https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
-support.
-
-[source,kotlin,indent=0]
-[subs=attributes+]
-.Kotlin DSL
-----
-testing {
-	suites {
-		named<JvmTestSuite>("test") {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Groovy DSL
-----
-testing {
-	suites {
-		test {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
-dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
-implementation similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("junit:junit:{junit4-version}")
-	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-[[running-tests-build-gradle-config-params]]
-===== Configuration Parameters
-
-The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
-Platform <<running-tests-config-params, configuration parameters>> to influence test
-discovery and execution. However, you can provide configuration parameters within the
-build script via system properties (as shown below) or via the
-`junit-platform.properties` file.
-
-[source,groovy,indent=0]
-----
-test {
-	// ...
-	systemProperty("junit.jupiter.conditions.deactivate", "*")
-	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
-	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
-	// ...
-}
-----
-
-[[running-tests-build-gradle-logging]]
-===== Configuring Logging (optional)
-
-JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
-emit warnings and debug information. Please refer to the official documentation of
-`{LogManager}` for configuration options.
-
-Alternatively, it's possible to redirect log messages to other logging frameworks such as
-{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
-`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
-qualified class name_ of the `{LogManager}` implementation to use. The example below
-demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
-details).
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
-	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
-	systemProperty("log4j2.disableJmx", "true")
-}
-----
-
-Other logging frameworks provide different means to redirect messages logged using
-`java.util.logging`. For example, for {Logback} you can use the
-https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
-dependency to the test runtime classpath.
-
-[[running-tests-build-maven]]
-==== Maven
-
-Maven Surefire and Maven Failsafe provide
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
-for executing tests on the JUnit Platform. The `pom.xml` file in the
-`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
-and can serve as a starting point for configuring your Maven build.
-
-[WARNING]
-.Minimum required version of Maven Surefire/Failsafe
-====
-As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
-====
-
-[[running-tests-build-maven-bom]]
-===== Aligning dependency versions
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-[[running-tests-build-maven-engines-configure]]
-===== Configuring Test Engines
-
-In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
-`TestEngine` implementation must be added to the test classpath.
-
-To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
-on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
-following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>org.junit.jupiter</groupId>
-			<artifactId>junit-jupiter</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
-long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
-`TestEngine` implementation similar to the following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>junit</groupId>
-			<artifactId>junit</artifactId>
-			<version>{junit4-version}</version>
-			<scope>test</scope>
-		</dependency>
-		<dependency>
-			<groupId>org.junit.vintage</groupId>
-			<artifactId>junit-vintage-engine</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-filter-test-class-names]]
-===== Filtering by Test Class Names
-
-The Maven Surefire Plugin will scan for test classes whose fully qualified names match
-the following patterns.
-
-- `+++**/Test*.java+++`
-- `+++**/*Test.java+++`
-- `+++**/*Tests.java+++`
-- `+++**/*TestCase.java+++`
-
-Moreover, it will exclude all nested classes (including static member classes) by default.
-
-Note, however, that you can override this default behavior by configuring explicit
-`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
-from excluding static member classes, you can override its exclude rules as follows.
-
-[source,xml,indent=0]
-[subs=attributes+]
-.Overriding exclude rules of Maven Surefire
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<excludes>
-						<exclude/>
-					</excludes>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Please see the
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
-documentation for Maven Surefire for details.
-
-[[running-tests-build-maven-filter-tags]]
-===== Filtering by Tags
-
-You can filter tests by <<running-tests-tags, tags>> or
-<<running-tests-tag-expressions, tag expressions>> using the following configuration
-properties.
-
-- to include _tags_ or _tag expressions_, use `groups`.
-- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<groups>acceptance | !feature-a</groups>
-					<excludedGroups>integration, regression</excludedGroups>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-config-params]]
-===== Configuration Parameters
-
-You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
-influence test discovery and execution by declaring the `configurationParameters`
-property and providing key-value pairs using the Java `Properties` file syntax (as shown
-below) or via the `junit-platform.properties` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<properties>
-						<configurationParameters>
-							junit.jupiter.conditions.deactivate = *
-							junit.jupiter.extensions.autodetection.enabled = true
-							junit.jupiter.testinstance.lifecycle.default = per_class
-						</configurationParameters>
-					</properties>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-ant]]
-==== Ant
-
-Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
-provides native support for launching tests on the JUnit Platform. The `junitlauncher`
-task is solely responsible for launching the JUnit Platform and passing it the selected
-collection of tests. The JUnit Platform then delegates to registered test engines to
-discover and execute the tests.
-
-The `junitlauncher` task attempts to align as closely as possible with native Ant
-constructs such as
-link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
-for allowing users to select the tests that they want executed by test engines. This gives
-the task a consistent and natural feel when compared to many other core Ant tasks.
-
-Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
-
-The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
-the task and can serve as a starting point.
-
-===== Basic Usage
-
-The following example demonstrates how to configure the `junitlauncher` task to select a
-single test class (i.e., `com.example.project.CalculatorTests`).
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-
-	<!-- ... -->
-
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<test name="com.example.project.CalculatorTests" />
-	</junitlauncher>
-----
-
-The `test` element allows you to specify a single test class that you want to be selected
-and executed. The `classpath` element allows you to specify the classpath to be used to
-launch the JUnit Platform. This classpath will also be used to locate test classes that
-are part of the execution.
-
-The following example demonstrates how to configure the `junitlauncher` task to select
-test classes from multiple locations.
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-	<!-- ... -->
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<testclasses outputdir="${output.dir}">
-			<fileset dir="${build.classes.dir}">
-				<include name="org/example/**/demo/**/" />
-			</fileset>
-			<fileset dir="${some.other.dir}">
-				<include name="org/myapp/**/" />
-			</fileset>
-		</testclasses>
-	</junitlauncher>
-----
-
-In the above example, the `testclasses` element allows you to select multiple test
-classes that reside in different locations.
-
-For further details on usage and configuration options please refer to the official Ant
-documentation for the
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
-
-[[running-tests-build-spring-boot]]
-==== Spring Boot
-
-link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
-managing the version of JUnit used in your project. In addition, the
-`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
-Jupiter, AssertJ, Mockito, etc.
-
-If your build relies on dependency management support from Spring Boot, you should not
-import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
-result in duplicate (and potentially conflicting) management of JUnit dependencies.
-
-If you need to override the version of a dependency used in your Spring Boot application,
-you have to override the exact name of the
-link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
-defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
-Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
-changing a dependency version is documented for both
-link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
-and
-link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
-
-With Gradle you can override the JUnit Jupiter version by including the following in your
-`build.gradle` file.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-	ext['junit-jupiter.version'] = '{version}'
-----
-
-With Maven you can override the JUnit Jupiter version by including the following in your
-`pom.xml` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<properties>
-		<junit-jupiter.version>{version}</junit-jupiter.version>
-	</properties>
-----
-
-[[running-tests-console-launcher]]
-=== Console Launcher
-
-The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
-Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
-Jupiter tests and print test execution results to the console.
-
-An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
-contains the contents of all of its dependencies is published in the {Maven_Central}
-repository under the
-https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
-directory. It contains the contents of the following artifacts:
-
-include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
-
-[NOTE]
-====
-Since the `junit-platform-console-standalone` JAR contains the contents of all of its
-dependencies, its Maven POM does not declare any dependencies.
-
-Furthermore, it is not very likely that you would need to include a dependency on the
-`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
-script. On the contrary, the executable `junit-platform-console-standalone` JAR is
-typically invoked directly from the command line or a shell script without a build script.
-
-If you need to declare dependencies in your build script on some of the artifacts
-contained in the `junit-platform-console-standalone` artifact, you should declare
-dependencies only on the JUnit artifacts that are used in your project. To simplify
-dependency management of JUnit artifacts in your build, you may wish to use the
-`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
-details.
-====
-
-You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
-standalone `ConsoleLauncher` as shown below.
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
-
-├─ JUnit Vintage
-│  └─ example.JUnit4Tests
-│     └─ standardJUnit4Test ✔
-└─ JUnit Jupiter
-   ├─ StandardTests
-   │  ├─ succeedingTest() ✔
-   │  └─ skippedTest() ↷ for demonstration purposes
-   └─ A special test case
-      ├─ Custom test name containing spaces ✔
-      ├─ ╯°□°)╯ ✔
-      └─ 😱 ✔
-
-Test run finished after 64 ms
-[         5 containers found      ]
-[         0 containers skipped    ]
-[         5 containers started    ]
-[         0 containers aborted    ]
-[         5 containers successful ]
-[         0 containers failed     ]
-[         6 tests found           ]
-[         1 tests skipped         ]
-[         5 tests started         ]
-[         0 tests aborted         ]
-[         5 tests successful      ]
-[         0 tests failed          ]
-----
-
-You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
-all jars in a directory):
-
-[source,console,subs=attributes+]
-----
-$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
-----
-
-[[running-tests-console-launcher-options]]
-==== Subcommands and Options
-
-The `{ConsoleLauncher}` provides the following subcommands:
-
-----
-include::{consoleLauncherOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-discovering-tests]]
-===== Discovering tests
-
-----
-include::{consoleLauncherDiscoverOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-executing-tests]]
-===== Executing tests
-
-.Exit Code
-NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
-All non-zero codes indicate an error of some sort. For example, status code `1`
-is returned if any containers or tests failed. If no tests are discovered and the
-`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
-with a status code of `2`. Unexpected or invalid user input yields a status code
-of `3`. An exit code of `-1` indicates an unspecified error condition.
-
-----
-include::{consoleLauncherExecuteOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-listing-test-engines]]
-===== Listing test engines
-
-----
-include::{consoleLauncherEnginesOptionsFile}[]
-----
-
-[[running-tests-console-launcher-argument-files]]
-==== Argument Files (@-files)
-
-On some platforms you may run into system limitations on the length of a command line when
-creating a command line with lots of options or with long arguments.
-
-The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
-are files that themselves contain arguments to be passed to the command. When the
-underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
-argument beginning with the character `@`, it expands the contents of that file into the
-argument list.
-
-The arguments within a file can be separated by spaces or newlines. If an argument
-contains embedded whitespace, the whole argument should be wrapped in double or single
-quotes -- for example, `"-f=My Files/Stuff.java"`.
-
-If the argument file does not exist or cannot be read, the argument will be treated
-literally and will not be removed. This will likely result in an "unmatched argument"
-error message. You can troubleshoot such errors by executing the command with the
-`picocli.trace` system property set to `DEBUG`.
-
-Multiple _@-files_ may be specified on the command line. The specified path may be
-relative to the current directory or absolute.
-
-You can pass a real parameter with an initial `@` character by escaping it with an
-additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
-subject to expansion.
-
-[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
-==== Redirecting Standard Output/Error to Files
-
-You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
-files using the `--redirect-stdout` and `--redirect-stderr` options:
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
-  --redirect-stdout=stdout.txt \
-  --redirect-stderr=stderr.txt
-----
-
-[NOTE]
-====
-If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
-output streams will be redirected to that file.
-
-The default charset is used for writing to the files.
-====
-
-[[running-tests-console-launcher-color-customization]]
-==== Color Customization
-
-The colors used in the output of the `{ConsoleLauncher}` can be customized.
-The option `--single-color` will apply a built-in monochrome style, while
-`--color-palette` will accept a properties file to override the
-https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
-The properties file below demonstrates the default style:
-
-[source,properties,indent=0]
-----
-SUCCESSFUL = 32
-ABORTED = 33
-FAILED = 31
-SKIPPED = 35
-CONTAINER = 35
-TEST = 34
-DYNAMIC = 35
-REPORTED = 37
-----
-
-[[running-tests-source-launcher]]
-=== Source Launcher
-
-Starting with Java 25 it is possible to write minimal source code test programs
-using the `org.junit.start` module. For example, like in a `HelloTests.java`
-file reading:
-
-```java
-import module org.junit.start;
-
-void main() {
-  JUnit.run();
-}
-
-@Test
-void stringLength() {
-  Assertions.assertEquals(11, "Hello JUnit".length());
-}
-```
-With all required modular JAR files available in a local `lib/` directory, the
-following Java 25+ command will discover and execute tests using the JUnit Platform.
-It will also print the result tree to the console.
-
-```shell
-java --module-path lib --add-modules org.junit.start HelloTests.java
-╷
-└─ JUnit Jupiter ✔
-   └─ HelloTests ✔
-      └─ stringLength() ✔
-```
-
-Find JUnit's class API documentation here: {JUnit}
-
-[[running-tests-discovery-selectors]]
-=== Discovery Selectors
-
-The JUnit Platform provides a rich set of discovery selectors that can be used to specify
-which tests should be discovered or executed.
-
-Discovery selectors can be created programmatically using the factory methods in the
-`{DiscoverySelectors}` class, specified declaratively via annotations when using the
-<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
-generically as strings via their identifiers.
-
-The following discovery selectors are provided out of the box:
-
-|===
-| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
-
-| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
-| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
-| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
-| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
-| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
-| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
-| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
-| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
-| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
-| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
-| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
-| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
-| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
-|===
-
-
-[[running-tests-config-params]]
-=== Configuration Parameters
-
-In addition to instructing the platform which test classes and test engines to include,
-which packages to scan, etc., it is sometimes necessary to provide additional custom
-configuration parameters that are specific to a particular test engine, listener, or
-registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
-parameters_ for the following use cases.
-
-- <<writing-tests-test-instance-lifecycle-changing-default>>
-- <<extensions-registration-automatic-enabling>>
-- <<extensions-conditions-deactivation>>
-- <<writing-tests-display-name-generator-default>>
-
-_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
-engines running on the JUnit Platform via one of the following mechanisms.
-
-1. The `configurationParameter()` and `configurationParameters()` methods in
-   `LauncherDiscoveryRequestBuilder` which
-   is used to build a request supplied to the <<launcher-api, Launcher API>>.
-    +
-   When running tests via one of the tools provided by the JUnit Platform you can specify
-   configuration parameters as follows:
-   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
-     option.
-   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
-     `systemProperties` DSL.
-   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
-     `configurationParameters` property.
-2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
-    +
-   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
-   specify custom configuration files using the `--config-resource` command-line option.
-3. JVM system properties.
-4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
-   in the root of the class path that follows the syntax rules for Java `Properties`
-   files.
-
-NOTE: Configuration parameters are looked up in the exact order defined above.
-Consequently, configuration parameters supplied directly to the `Launcher` take
-precedence over those supplied via custom configuration files, system properties, and the
-default configuration file. Similarly, configuration parameters supplied via system
-properties take precedence over those supplied via the default configuration file.
-
-[[running-tests-config-params-deactivation-pattern]]
-==== Pattern Matching Syntax
-
-This section describes the pattern matching syntax that is applied to the _configuration
-parameters_ used for the following features.
-
-- <<extensions-conditions-deactivation>>
-- <<launcher-api-listeners-custom-deactivation>>
-- <<stacktrace-pruning>>
-- <<extensions-registration-automatic-filtering>>
-
-If the value for the given _configuration parameter_ consists solely of an asterisk
-(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
-will be treated as a comma-separated list of patterns where each pattern will be matched
-against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
-a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
-(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
-pattern will be matched one-to-one against a FQCN.
-
-Examples:
-
-- `+++*+++`: matches all candidate classes.
-- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
-  any of its subpackages.
-- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
-  `MyCustomImpl`.
-- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
-- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
-  `System` or `Unit`.
-- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
-  `org.example.MyCustomImpl`.
-- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
-  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
-
-[[running-tests-tags]]
-=== Tags
-
-Tags are a JUnit Platform concept for marking and filtering tests. The programming model
-for adding tags to containers and tests is defined by the testing framework. For example,
-in JUnit Jupiter based tests, the `@Tag` annotation (see
-<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
-Vintage engine maps `@Category` annotations to tags (see
-<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
-own annotation or other means for users to specify tags.
-
-[[running-tests-tag-syntax-rules]]
-==== Syntax Rules for Tags
-
-Regardless how a tag is specified, the JUnit Platform enforces the following rules:
-
-* A tag must not be `null` or _blank_.
-* A _stripped_ tag must not contain whitespace.
-* A _stripped_ tag must not contain ISO control characters.
-* A _stripped_ tag must not contain any of the following _reserved characters_.
-- `,`: _comma_
-- `(`: _left parenthesis_
-- `)`: _right parenthesis_
-- `&`: _ampersand_
-- `|`: _vertical bar_
-- `!`: _exclamation point_
-
-NOTE: In the above context, "stripped" means that leading and trailing whitespace
-characters have been removed using `java.lang.String.strip()`.
-
-[[running-tests-tag-expressions]]
-==== Tag Expressions
-
-Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
-`(` and `)` can be used to adjust for operator precedence.
-
-Two special expressions are supported, `any()` and `none()`, which select all tests _with_
-any tags at all, and all tests _without_ any tags, respectively.
-These special expressions may be combined with other expressions just like normal tags.
-
-.Operators (in descending order of precedence)
-|===
-| Operator | Meaning | Associativity
-
-| `!`      | not     | right
-| `&`      | and     | left
-| `\|`     | or      | left
-|===
-
-If you are tagging your tests across multiple dimensions, tag expressions help you to
-select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
-_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
-expressions can be useful.
-
-[%header,cols="40,60"]
-|===
-| Tag Expression
-| Selection
-
-| `+++product+++`
-| all tests for *product*
-
-| `+++catalog \| shipping+++`
-| all tests for *catalog* plus all tests for *shipping*
-
-| `+++catalog &amp; shipping+++`
-| all tests for the intersection between *catalog* and *shipping*
-
-| `+++product &amp; !end-to-end+++`
-| all tests for *product*, but not the _end-to-end_ tests
-
-| `+++(micro \| integration) &amp; (product \| shipping)+++`
-| all _micro_ or _integration_ tests for *product* or *shipping*
-|===
-
-[[running-tests-capturing-output]]
-=== Capturing Standard Output/Error
-
-The JUnit Platform provides opt-in support for capturing output printed to `System.out`
-and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
-`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
-parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
-to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
-
-If enabled, the JUnit Platform captures the corresponding output and publishes it as a
-report entry using the `stdout` or `stderr` keys to all registered
-`{TestExecutionListener}` instances immediately before reporting the test or container as
-finished.
-
-Please note that the captured output will only contain output emitted by the thread that
-was used to execute a container or test. Any output by other threads will be omitted
-because particularly when
-<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
-to attribute it to a specific test or container.
-
-[[running-tests-listeners]]
-=== Using Listeners and Interceptors
-
-The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
-and custom user code to react to events fired at various points during the discovery and
-execution of a `TestPlan`.
-
-* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
-  closed.
-* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
-  `LauncherSession`.
-* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
-* `{TestExecutionListener}`: receives events that occur during test execution.
-
-The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
-registered automatically for you in order to support some feature of the build tool or IDE.
-
-The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
-order to produce some form of report or to display a graphical representation of the test
-plan in an IDE. Such listeners may be implemented and automatically registered by a build
-tool or IDE, or they may be included in a third-party library – potentially registered
-for you automatically. You can also implement and register your own listeners.
-
-For details on registering and configuring listeners, see the following sections of this
-guide.
-
-* <<launcher-api-launcher-session-listeners-custom>>
-* <<launcher-api-launcher-interceptors-custom>>
-* <<launcher-api-launcher-discovery-listeners-custom>>
-* <<launcher-api-listeners-custom>>
-* <<launcher-api-listeners-config>>
-* <<launcher-api-listeners-custom-deactivation>>
-
-The JUnit Platform provides the following listeners which you may wish to use with your
-test suite.
-
-<<junit-platform-reporting>> ::
-  `{LegacyXmlReportGeneratingListener}` can be used via the
-  <<running-tests-console-launcher>> or registered manually to generate XML reports
-  compatible with the de facto standard for JUnit 4 based test reports.
-+
-`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
-specified by {OpenTestReporting}. It is auto-registered and can be enabled and
-configured via <<running-tests-config-params>>.
-+
-See <<junit-platform-reporting>> for details.
-
-<<running-tests-listeners-flight-recorder>> ::
-  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
-  Java Flight Recorder events during test discovery and execution.
-
-`{LoggingListener}` ::
-  `TestExecutionListener` for logging informational messages for all events via a
-  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
-
-`{SummaryGeneratingListener}` ::
-  `TestExecutionListener` that generates a summary of the test execution which can be
-  printed via a `PrintWriter`.
-
-`{UniqueIdTrackingListener}` ::
-  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
-  or executed during the execution of the `TestPlan` and generates a file containing the
-  unique IDs once execution of the `TestPlan` has finished.
-
-[[running-tests-listeners-flight-recorder]]
-==== Flight Recorder Support
-
-The JUnit Platform provides opt-in support for generating Flight Recorder events.
-https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
-follows.
-
-> Flight Recorder records events originating from applications, the JVM, and the OS.
-Events are stored in a single file that can be attached to bug reports and examined by
-support engineers, allowing after-the-fact analysis of issues in the period leading up
-to a problem.
-
-In order to record Flight Recorder events generated while running tests, you need to
-start flight recording when launching a test suite via the following java command line
-option.
-
-   -XX:StartFlightRecording:filename=...
-
-Please consult the manual of your build tool for the appropriate commands.
-
-To analyze the recorded events, use the
-https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
-command line tool shipped with recent JDKs or open the recording file with
-https://jdk.java.net/jmc/[JDK Mission Control].
-
-[[stacktrace-pruning]]
-=== Stack Trace Pruning
-
-The JUnit Platform provides built-in support for pruning stack traces produced by failing
-tests. This feature is enabled by default but can be disabled by setting the
-`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
-
-When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
-packages are removed from the stack trace, unless the calls occur after the test itself
-or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
-never be excluded.
-
-In addition, all elements prior to and including the first call from the JUnit Platform
-`Launcher` will be removed.
-
-[[running-tests-discovery-issues]]
-=== Discovery Issues
-
-Test engines may encounter issues during test discovery. For example, the declaration of a
-test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
-Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
-report them with different severity levels:
-
-INFO::
-Indicates that the engine encountered something that could be potentially problematic, but
-could also happen due to a valid setup or configuration.
-
-WARNING::
-Indicates that the engine encountered something that is problematic and might lead to
-unexpected behavior or will be removed or changed in a future release.
-
-ERROR::
-Indicates that the engine encountered something that is definitely problematic and will
-lead to unexpected behavior.
-
-If an engine reports an issue with a severity equal to or higher than a configurable
-_critical_ severity, its tests will not be executed. Instead, the engine will be reported
-as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
-Non-critical issues will be logged but will not prevent the engine from executing its
-tests. The `junit.platform.discovery.issue.severity.critical`
-<<running-tests-config-params, configuration parameter>> can be used to set the critical
-severity level. Currently, the default value is `ERROR` but it may be changed in a future
-release.
-
-TIP: To surface all discovery issues in your project, it is recommended to set the
-`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
-
-In addition, registered `{LauncherDiscoveryListener}` implementations can receive
-discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
-report issues to the user in a more user-friendly way. For example, IDEs may choose to
-display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/intro.adoc b/documentation/modules/ROOT/pages/running-tests/intro.adoc
index 3099a146c2b4..fa0b0d985b0f 100644
--- a/documentation/modules/ROOT/pages/running-tests/intro.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/intro.adoc
@@ -1,1216 +1,3 @@
 [[running-tests]]
 == Running Tests
 
-[[running-tests-ide]]
-=== IDE Support
-
-[[running-tests-ide-intellij-idea]]
-==== IntelliJ IDEA
-
-IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
-information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
-however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
-IDEA download the following JARs automatically based on the API version used in the
-project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
-
-In order to use a different JUnit version (e.g., {version}), you may need to
-include the corresponding versions of the `junit-platform-launcher`,
-`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
-
-.Additional Gradle Dependencies
-[source,groovy]
-[subs=attributes+]
-----
-testImplementation(platform("org.junit:junit-bom:{version}"))
-testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
-testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
-----
-
-.Additional Maven Dependencies
-[source,xml]
-[subs=attributes+]
-----
-<!-- ... -->
-<dependencies>
-	<dependency>
-		<groupId>org.junit.platform</groupId>
-		<artifactId>junit-platform-launcher</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.jupiter</groupId>
-		<artifactId>junit-jupiter-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.vintage</groupId>
-		<artifactId>junit-vintage-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-</dependencies>
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-[[running-tests-ide-eclipse]]
-==== Eclipse
-
-Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
-release.
-
-For more information on using JUnit Platform in Eclipse consult the official _Eclipse
-support for JUnit 5_ section of the
-https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
-(4.7.1a) - New and Noteworthy] documentation.
-
-[[running-tests-ide-netbeans]]
-==== NetBeans
-
-NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
-https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
-
-For more information consult the JUnit 5 section of the
-https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
-release notes].
-
-[[running-tests-ide-vscode]]
-==== Visual Studio Code
-
-https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
-Platform via the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
-Runner] extension which is installed by default as part of the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
-Extension Pack].
-
-For more information consult the _Testing_ section of the
-https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
-documentation.
-
-[[running-tests-ide-other]]
-==== Other IDEs
-
-If you are using an editor or IDE other than one of those listed in the previous sections,
-and it doesn't support running tests on the JUnit Platform, you can use the
-<<running-tests-console-launcher>> to run them from the command line.
-
-[[running-tests-build]]
-=== Build Support
-
-[[running-tests-build-gradle]]
-==== Gradle
-
-Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
-https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
-for executing tests on the JUnit Platform. To enable it, you need to specify
-`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform()
-}
-----
-
-Filtering by <<running-tests-tags, tags>>,
-<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform {
-		includeTags("fast", "smoke & feature-a")
-		// excludeTags("slow", "ci")
-		includeEngines("junit-jupiter")
-		// excludeEngines("junit-vintage")
-	}
-}
-----
-
-Please refer to the
-https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
-for a comprehensive list of options.
-
-[[running-tests-build-gradle-bom]]
-===== Aligning dependency versions
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Explicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation(platform("org.junit:junit-bom:{version}"))
-	testImplementation("org.junit.jupiter:junit-jupiter")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-Since all JUnit artifacts declare a
-https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
-you usually don't need to declare an explicit dependency on it yourself. Instead, it's
-sufficient to declare _one_ regular dependency that includes a version number. Gradle will
-then pull in the BOM automatically so you can omit the version for all other JUnit
-artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Implicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
-}
-----
-<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
-<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
-
-[WARNING]
-.Declaring a dependency on junit-platform-launcher
-====
-Even though pre-8.0 versions of Gradle don't require declaring an explicit
-dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
-of JUnit artifacts on the test runtime classpath are aligned.
-
-Moreover, doing so is recommended and in some cases even required when importing the
-project into an IDE like <<running-tests-ide-eclipse>> or
-<<running-tests-ide-intellij-idea>>.
-====
-
-[[running-tests-build-gradle-engines-configure]]
-===== Configuring Test Engines
-
-In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
-
-To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
-on the dependency-aggregating JUnit Jupiter artifact similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Alternatively, you can use Gradle's
-https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
-support.
-
-[source,kotlin,indent=0]
-[subs=attributes+]
-.Kotlin DSL
-----
-testing {
-	suites {
-		named<JvmTestSuite>("test") {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Groovy DSL
-----
-testing {
-	suites {
-		test {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
-dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
-implementation similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("junit:junit:{junit4-version}")
-	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-[[running-tests-build-gradle-config-params]]
-===== Configuration Parameters
-
-The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
-Platform <<running-tests-config-params, configuration parameters>> to influence test
-discovery and execution. However, you can provide configuration parameters within the
-build script via system properties (as shown below) or via the
-`junit-platform.properties` file.
-
-[source,groovy,indent=0]
-----
-test {
-	// ...
-	systemProperty("junit.jupiter.conditions.deactivate", "*")
-	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
-	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
-	// ...
-}
-----
-
-[[running-tests-build-gradle-logging]]
-===== Configuring Logging (optional)
-
-JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
-emit warnings and debug information. Please refer to the official documentation of
-`{LogManager}` for configuration options.
-
-Alternatively, it's possible to redirect log messages to other logging frameworks such as
-{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
-`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
-qualified class name_ of the `{LogManager}` implementation to use. The example below
-demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
-details).
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
-	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
-	systemProperty("log4j2.disableJmx", "true")
-}
-----
-
-Other logging frameworks provide different means to redirect messages logged using
-`java.util.logging`. For example, for {Logback} you can use the
-https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
-dependency to the test runtime classpath.
-
-[[running-tests-build-maven]]
-==== Maven
-
-Maven Surefire and Maven Failsafe provide
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
-for executing tests on the JUnit Platform. The `pom.xml` file in the
-`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
-and can serve as a starting point for configuring your Maven build.
-
-[WARNING]
-.Minimum required version of Maven Surefire/Failsafe
-====
-As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
-====
-
-[[running-tests-build-maven-bom]]
-===== Aligning dependency versions
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-[[running-tests-build-maven-engines-configure]]
-===== Configuring Test Engines
-
-In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
-`TestEngine` implementation must be added to the test classpath.
-
-To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
-on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
-following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>org.junit.jupiter</groupId>
-			<artifactId>junit-jupiter</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
-long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
-`TestEngine` implementation similar to the following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>junit</groupId>
-			<artifactId>junit</artifactId>
-			<version>{junit4-version}</version>
-			<scope>test</scope>
-		</dependency>
-		<dependency>
-			<groupId>org.junit.vintage</groupId>
-			<artifactId>junit-vintage-engine</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-filter-test-class-names]]
-===== Filtering by Test Class Names
-
-The Maven Surefire Plugin will scan for test classes whose fully qualified names match
-the following patterns.
-
-- `+++**/Test*.java+++`
-- `+++**/*Test.java+++`
-- `+++**/*Tests.java+++`
-- `+++**/*TestCase.java+++`
-
-Moreover, it will exclude all nested classes (including static member classes) by default.
-
-Note, however, that you can override this default behavior by configuring explicit
-`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
-from excluding static member classes, you can override its exclude rules as follows.
-
-[source,xml,indent=0]
-[subs=attributes+]
-.Overriding exclude rules of Maven Surefire
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<excludes>
-						<exclude/>
-					</excludes>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Please see the
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
-documentation for Maven Surefire for details.
-
-[[running-tests-build-maven-filter-tags]]
-===== Filtering by Tags
-
-You can filter tests by <<running-tests-tags, tags>> or
-<<running-tests-tag-expressions, tag expressions>> using the following configuration
-properties.
-
-- to include _tags_ or _tag expressions_, use `groups`.
-- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<groups>acceptance | !feature-a</groups>
-					<excludedGroups>integration, regression</excludedGroups>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-config-params]]
-===== Configuration Parameters
-
-You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
-influence test discovery and execution by declaring the `configurationParameters`
-property and providing key-value pairs using the Java `Properties` file syntax (as shown
-below) or via the `junit-platform.properties` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<properties>
-						<configurationParameters>
-							junit.jupiter.conditions.deactivate = *
-							junit.jupiter.extensions.autodetection.enabled = true
-							junit.jupiter.testinstance.lifecycle.default = per_class
-						</configurationParameters>
-					</properties>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-ant]]
-==== Ant
-
-Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
-provides native support for launching tests on the JUnit Platform. The `junitlauncher`
-task is solely responsible for launching the JUnit Platform and passing it the selected
-collection of tests. The JUnit Platform then delegates to registered test engines to
-discover and execute the tests.
-
-The `junitlauncher` task attempts to align as closely as possible with native Ant
-constructs such as
-link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
-for allowing users to select the tests that they want executed by test engines. This gives
-the task a consistent and natural feel when compared to many other core Ant tasks.
-
-Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
-
-The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
-the task and can serve as a starting point.
-
-===== Basic Usage
-
-The following example demonstrates how to configure the `junitlauncher` task to select a
-single test class (i.e., `com.example.project.CalculatorTests`).
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-
-	<!-- ... -->
-
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<test name="com.example.project.CalculatorTests" />
-	</junitlauncher>
-----
-
-The `test` element allows you to specify a single test class that you want to be selected
-and executed. The `classpath` element allows you to specify the classpath to be used to
-launch the JUnit Platform. This classpath will also be used to locate test classes that
-are part of the execution.
-
-The following example demonstrates how to configure the `junitlauncher` task to select
-test classes from multiple locations.
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-	<!-- ... -->
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<testclasses outputdir="${output.dir}">
-			<fileset dir="${build.classes.dir}">
-				<include name="org/example/**/demo/**/" />
-			</fileset>
-			<fileset dir="${some.other.dir}">
-				<include name="org/myapp/**/" />
-			</fileset>
-		</testclasses>
-	</junitlauncher>
-----
-
-In the above example, the `testclasses` element allows you to select multiple test
-classes that reside in different locations.
-
-For further details on usage and configuration options please refer to the official Ant
-documentation for the
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
-
-[[running-tests-build-spring-boot]]
-==== Spring Boot
-
-link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
-managing the version of JUnit used in your project. In addition, the
-`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
-Jupiter, AssertJ, Mockito, etc.
-
-If your build relies on dependency management support from Spring Boot, you should not
-import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
-result in duplicate (and potentially conflicting) management of JUnit dependencies.
-
-If you need to override the version of a dependency used in your Spring Boot application,
-you have to override the exact name of the
-link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
-defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
-Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
-changing a dependency version is documented for both
-link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
-and
-link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
-
-With Gradle you can override the JUnit Jupiter version by including the following in your
-`build.gradle` file.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-	ext['junit-jupiter.version'] = '{version}'
-----
-
-With Maven you can override the JUnit Jupiter version by including the following in your
-`pom.xml` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<properties>
-		<junit-jupiter.version>{version}</junit-jupiter.version>
-	</properties>
-----
-
-[[running-tests-console-launcher]]
-=== Console Launcher
-
-The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
-Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
-Jupiter tests and print test execution results to the console.
-
-An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
-contains the contents of all of its dependencies is published in the {Maven_Central}
-repository under the
-https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
-directory. It contains the contents of the following artifacts:
-
-include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
-
-[NOTE]
-====
-Since the `junit-platform-console-standalone` JAR contains the contents of all of its
-dependencies, its Maven POM does not declare any dependencies.
-
-Furthermore, it is not very likely that you would need to include a dependency on the
-`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
-script. On the contrary, the executable `junit-platform-console-standalone` JAR is
-typically invoked directly from the command line or a shell script without a build script.
-
-If you need to declare dependencies in your build script on some of the artifacts
-contained in the `junit-platform-console-standalone` artifact, you should declare
-dependencies only on the JUnit artifacts that are used in your project. To simplify
-dependency management of JUnit artifacts in your build, you may wish to use the
-`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
-details.
-====
-
-You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
-standalone `ConsoleLauncher` as shown below.
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
-
-├─ JUnit Vintage
-│  └─ example.JUnit4Tests
-│     └─ standardJUnit4Test ✔
-└─ JUnit Jupiter
-   ├─ StandardTests
-   │  ├─ succeedingTest() ✔
-   │  └─ skippedTest() ↷ for demonstration purposes
-   └─ A special test case
-      ├─ Custom test name containing spaces ✔
-      ├─ ╯°□°)╯ ✔
-      └─ 😱 ✔
-
-Test run finished after 64 ms
-[         5 containers found      ]
-[         0 containers skipped    ]
-[         5 containers started    ]
-[         0 containers aborted    ]
-[         5 containers successful ]
-[         0 containers failed     ]
-[         6 tests found           ]
-[         1 tests skipped         ]
-[         5 tests started         ]
-[         0 tests aborted         ]
-[         5 tests successful      ]
-[         0 tests failed          ]
-----
-
-You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
-all jars in a directory):
-
-[source,console,subs=attributes+]
-----
-$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
-----
-
-[[running-tests-console-launcher-options]]
-==== Subcommands and Options
-
-The `{ConsoleLauncher}` provides the following subcommands:
-
-----
-include::{consoleLauncherOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-discovering-tests]]
-===== Discovering tests
-
-----
-include::{consoleLauncherDiscoverOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-executing-tests]]
-===== Executing tests
-
-.Exit Code
-NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
-All non-zero codes indicate an error of some sort. For example, status code `1`
-is returned if any containers or tests failed. If no tests are discovered and the
-`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
-with a status code of `2`. Unexpected or invalid user input yields a status code
-of `3`. An exit code of `-1` indicates an unspecified error condition.
-
-----
-include::{consoleLauncherExecuteOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-listing-test-engines]]
-===== Listing test engines
-
-----
-include::{consoleLauncherEnginesOptionsFile}[]
-----
-
-[[running-tests-console-launcher-argument-files]]
-==== Argument Files (@-files)
-
-On some platforms you may run into system limitations on the length of a command line when
-creating a command line with lots of options or with long arguments.
-
-The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
-are files that themselves contain arguments to be passed to the command. When the
-underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
-argument beginning with the character `@`, it expands the contents of that file into the
-argument list.
-
-The arguments within a file can be separated by spaces or newlines. If an argument
-contains embedded whitespace, the whole argument should be wrapped in double or single
-quotes -- for example, `"-f=My Files/Stuff.java"`.
-
-If the argument file does not exist or cannot be read, the argument will be treated
-literally and will not be removed. This will likely result in an "unmatched argument"
-error message. You can troubleshoot such errors by executing the command with the
-`picocli.trace` system property set to `DEBUG`.
-
-Multiple _@-files_ may be specified on the command line. The specified path may be
-relative to the current directory or absolute.
-
-You can pass a real parameter with an initial `@` character by escaping it with an
-additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
-subject to expansion.
-
-[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
-==== Redirecting Standard Output/Error to Files
-
-You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
-files using the `--redirect-stdout` and `--redirect-stderr` options:
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
-  --redirect-stdout=stdout.txt \
-  --redirect-stderr=stderr.txt
-----
-
-[NOTE]
-====
-If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
-output streams will be redirected to that file.
-
-The default charset is used for writing to the files.
-====
-
-[[running-tests-console-launcher-color-customization]]
-==== Color Customization
-
-The colors used in the output of the `{ConsoleLauncher}` can be customized.
-The option `--single-color` will apply a built-in monochrome style, while
-`--color-palette` will accept a properties file to override the
-https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
-The properties file below demonstrates the default style:
-
-[source,properties,indent=0]
-----
-SUCCESSFUL = 32
-ABORTED = 33
-FAILED = 31
-SKIPPED = 35
-CONTAINER = 35
-TEST = 34
-DYNAMIC = 35
-REPORTED = 37
-----
-
-[[running-tests-source-launcher]]
-=== Source Launcher
-
-Starting with Java 25 it is possible to write minimal source code test programs
-using the `org.junit.start` module. For example, like in a `HelloTests.java`
-file reading:
-
-```java
-import module org.junit.start;
-
-void main() {
-  JUnit.run();
-}
-
-@Test
-void stringLength() {
-  Assertions.assertEquals(11, "Hello JUnit".length());
-}
-```
-With all required modular JAR files available in a local `lib/` directory, the
-following Java 25+ command will discover and execute tests using the JUnit Platform.
-It will also print the result tree to the console.
-
-```shell
-java --module-path lib --add-modules org.junit.start HelloTests.java
-╷
-└─ JUnit Jupiter ✔
-   └─ HelloTests ✔
-      └─ stringLength() ✔
-```
-
-Find JUnit's class API documentation here: {JUnit}
-
-[[running-tests-discovery-selectors]]
-=== Discovery Selectors
-
-The JUnit Platform provides a rich set of discovery selectors that can be used to specify
-which tests should be discovered or executed.
-
-Discovery selectors can be created programmatically using the factory methods in the
-`{DiscoverySelectors}` class, specified declaratively via annotations when using the
-<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
-generically as strings via their identifiers.
-
-The following discovery selectors are provided out of the box:
-
-|===
-| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
-
-| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
-| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
-| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
-| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
-| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
-| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
-| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
-| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
-| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
-| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
-| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
-| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
-| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
-|===
-
-
-[[running-tests-config-params]]
-=== Configuration Parameters
-
-In addition to instructing the platform which test classes and test engines to include,
-which packages to scan, etc., it is sometimes necessary to provide additional custom
-configuration parameters that are specific to a particular test engine, listener, or
-registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
-parameters_ for the following use cases.
-
-- <<writing-tests-test-instance-lifecycle-changing-default>>
-- <<extensions-registration-automatic-enabling>>
-- <<extensions-conditions-deactivation>>
-- <<writing-tests-display-name-generator-default>>
-
-_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
-engines running on the JUnit Platform via one of the following mechanisms.
-
-1. The `configurationParameter()` and `configurationParameters()` methods in
-   `LauncherDiscoveryRequestBuilder` which
-   is used to build a request supplied to the <<launcher-api, Launcher API>>.
-    +
-   When running tests via one of the tools provided by the JUnit Platform you can specify
-   configuration parameters as follows:
-   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
-     option.
-   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
-     `systemProperties` DSL.
-   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
-     `configurationParameters` property.
-2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
-    +
-   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
-   specify custom configuration files using the `--config-resource` command-line option.
-3. JVM system properties.
-4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
-   in the root of the class path that follows the syntax rules for Java `Properties`
-   files.
-
-NOTE: Configuration parameters are looked up in the exact order defined above.
-Consequently, configuration parameters supplied directly to the `Launcher` take
-precedence over those supplied via custom configuration files, system properties, and the
-default configuration file. Similarly, configuration parameters supplied via system
-properties take precedence over those supplied via the default configuration file.
-
-[[running-tests-config-params-deactivation-pattern]]
-==== Pattern Matching Syntax
-
-This section describes the pattern matching syntax that is applied to the _configuration
-parameters_ used for the following features.
-
-- <<extensions-conditions-deactivation>>
-- <<launcher-api-listeners-custom-deactivation>>
-- <<stacktrace-pruning>>
-- <<extensions-registration-automatic-filtering>>
-
-If the value for the given _configuration parameter_ consists solely of an asterisk
-(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
-will be treated as a comma-separated list of patterns where each pattern will be matched
-against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
-a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
-(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
-pattern will be matched one-to-one against a FQCN.
-
-Examples:
-
-- `+++*+++`: matches all candidate classes.
-- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
-  any of its subpackages.
-- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
-  `MyCustomImpl`.
-- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
-- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
-  `System` or `Unit`.
-- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
-  `org.example.MyCustomImpl`.
-- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
-  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
-
-[[running-tests-tags]]
-=== Tags
-
-Tags are a JUnit Platform concept for marking and filtering tests. The programming model
-for adding tags to containers and tests is defined by the testing framework. For example,
-in JUnit Jupiter based tests, the `@Tag` annotation (see
-<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
-Vintage engine maps `@Category` annotations to tags (see
-<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
-own annotation or other means for users to specify tags.
-
-[[running-tests-tag-syntax-rules]]
-==== Syntax Rules for Tags
-
-Regardless how a tag is specified, the JUnit Platform enforces the following rules:
-
-* A tag must not be `null` or _blank_.
-* A _stripped_ tag must not contain whitespace.
-* A _stripped_ tag must not contain ISO control characters.
-* A _stripped_ tag must not contain any of the following _reserved characters_.
-- `,`: _comma_
-- `(`: _left parenthesis_
-- `)`: _right parenthesis_
-- `&`: _ampersand_
-- `|`: _vertical bar_
-- `!`: _exclamation point_
-
-NOTE: In the above context, "stripped" means that leading and trailing whitespace
-characters have been removed using `java.lang.String.strip()`.
-
-[[running-tests-tag-expressions]]
-==== Tag Expressions
-
-Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
-`(` and `)` can be used to adjust for operator precedence.
-
-Two special expressions are supported, `any()` and `none()`, which select all tests _with_
-any tags at all, and all tests _without_ any tags, respectively.
-These special expressions may be combined with other expressions just like normal tags.
-
-.Operators (in descending order of precedence)
-|===
-| Operator | Meaning | Associativity
-
-| `!`      | not     | right
-| `&`      | and     | left
-| `\|`     | or      | left
-|===
-
-If you are tagging your tests across multiple dimensions, tag expressions help you to
-select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
-_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
-expressions can be useful.
-
-[%header,cols="40,60"]
-|===
-| Tag Expression
-| Selection
-
-| `+++product+++`
-| all tests for *product*
-
-| `+++catalog \| shipping+++`
-| all tests for *catalog* plus all tests for *shipping*
-
-| `+++catalog &amp; shipping+++`
-| all tests for the intersection between *catalog* and *shipping*
-
-| `+++product &amp; !end-to-end+++`
-| all tests for *product*, but not the _end-to-end_ tests
-
-| `+++(micro \| integration) &amp; (product \| shipping)+++`
-| all _micro_ or _integration_ tests for *product* or *shipping*
-|===
-
-[[running-tests-capturing-output]]
-=== Capturing Standard Output/Error
-
-The JUnit Platform provides opt-in support for capturing output printed to `System.out`
-and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
-`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
-parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
-to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
-
-If enabled, the JUnit Platform captures the corresponding output and publishes it as a
-report entry using the `stdout` or `stderr` keys to all registered
-`{TestExecutionListener}` instances immediately before reporting the test or container as
-finished.
-
-Please note that the captured output will only contain output emitted by the thread that
-was used to execute a container or test. Any output by other threads will be omitted
-because particularly when
-<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
-to attribute it to a specific test or container.
-
-[[running-tests-listeners]]
-=== Using Listeners and Interceptors
-
-The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
-and custom user code to react to events fired at various points during the discovery and
-execution of a `TestPlan`.
-
-* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
-  closed.
-* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
-  `LauncherSession`.
-* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
-* `{TestExecutionListener}`: receives events that occur during test execution.
-
-The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
-registered automatically for you in order to support some feature of the build tool or IDE.
-
-The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
-order to produce some form of report or to display a graphical representation of the test
-plan in an IDE. Such listeners may be implemented and automatically registered by a build
-tool or IDE, or they may be included in a third-party library – potentially registered
-for you automatically. You can also implement and register your own listeners.
-
-For details on registering and configuring listeners, see the following sections of this
-guide.
-
-* <<launcher-api-launcher-session-listeners-custom>>
-* <<launcher-api-launcher-interceptors-custom>>
-* <<launcher-api-launcher-discovery-listeners-custom>>
-* <<launcher-api-listeners-custom>>
-* <<launcher-api-listeners-config>>
-* <<launcher-api-listeners-custom-deactivation>>
-
-The JUnit Platform provides the following listeners which you may wish to use with your
-test suite.
-
-<<junit-platform-reporting>> ::
-  `{LegacyXmlReportGeneratingListener}` can be used via the
-  <<running-tests-console-launcher>> or registered manually to generate XML reports
-  compatible with the de facto standard for JUnit 4 based test reports.
-+
-`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
-specified by {OpenTestReporting}. It is auto-registered and can be enabled and
-configured via <<running-tests-config-params>>.
-+
-See <<junit-platform-reporting>> for details.
-
-<<running-tests-listeners-flight-recorder>> ::
-  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
-  Java Flight Recorder events during test discovery and execution.
-
-`{LoggingListener}` ::
-  `TestExecutionListener` for logging informational messages for all events via a
-  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
-
-`{SummaryGeneratingListener}` ::
-  `TestExecutionListener` that generates a summary of the test execution which can be
-  printed via a `PrintWriter`.
-
-`{UniqueIdTrackingListener}` ::
-  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
-  or executed during the execution of the `TestPlan` and generates a file containing the
-  unique IDs once execution of the `TestPlan` has finished.
-
-[[running-tests-listeners-flight-recorder]]
-==== Flight Recorder Support
-
-The JUnit Platform provides opt-in support for generating Flight Recorder events.
-https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
-follows.
-
-> Flight Recorder records events originating from applications, the JVM, and the OS.
-Events are stored in a single file that can be attached to bug reports and examined by
-support engineers, allowing after-the-fact analysis of issues in the period leading up
-to a problem.
-
-In order to record Flight Recorder events generated while running tests, you need to
-start flight recording when launching a test suite via the following java command line
-option.
-
-   -XX:StartFlightRecording:filename=...
-
-Please consult the manual of your build tool for the appropriate commands.
-
-To analyze the recorded events, use the
-https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
-command line tool shipped with recent JDKs or open the recording file with
-https://jdk.java.net/jmc/[JDK Mission Control].
-
-[[stacktrace-pruning]]
-=== Stack Trace Pruning
-
-The JUnit Platform provides built-in support for pruning stack traces produced by failing
-tests. This feature is enabled by default but can be disabled by setting the
-`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
-
-When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
-packages are removed from the stack trace, unless the calls occur after the test itself
-or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
-never be excluded.
-
-In addition, all elements prior to and including the first call from the JUnit Platform
-`Launcher` will be removed.
-
-[[running-tests-discovery-issues]]
-=== Discovery Issues
-
-Test engines may encounter issues during test discovery. For example, the declaration of a
-test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
-Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
-report them with different severity levels:
-
-INFO::
-Indicates that the engine encountered something that could be potentially problematic, but
-could also happen due to a valid setup or configuration.
-
-WARNING::
-Indicates that the engine encountered something that is problematic and might lead to
-unexpected behavior or will be removed or changed in a future release.
-
-ERROR::
-Indicates that the engine encountered something that is definitely problematic and will
-lead to unexpected behavior.
-
-If an engine reports an issue with a severity equal to or higher than a configurable
-_critical_ severity, its tests will not be executed. Instead, the engine will be reported
-as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
-Non-critical issues will be logged but will not prevent the engine from executing its
-tests. The `junit.platform.discovery.issue.severity.critical`
-<<running-tests-config-params, configuration parameter>> can be used to set the critical
-severity level. Currently, the default value is `ERROR` but it may be changed in a future
-release.
-
-TIP: To surface all discovery issues in your project, it is recommended to set the
-`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
-
-In addition, registered `{LauncherDiscoveryListener}` implementations can receive
-discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
-report issues to the user in a more user-friendly way. For example, IDEs may choose to
-display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/source-launcher.adoc b/documentation/modules/ROOT/pages/running-tests/source-launcher.adoc
index 3099a146c2b4..6de303753743 100644
--- a/documentation/modules/ROOT/pages/running-tests/source-launcher.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/source-launcher.adoc
@@ -1,841 +1,3 @@
-[[running-tests]]
-== Running Tests
-
-[[running-tests-ide]]
-=== IDE Support
-
-[[running-tests-ide-intellij-idea]]
-==== IntelliJ IDEA
-
-IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
-information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
-however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
-IDEA download the following JARs automatically based on the API version used in the
-project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
-
-In order to use a different JUnit version (e.g., {version}), you may need to
-include the corresponding versions of the `junit-platform-launcher`,
-`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
-
-.Additional Gradle Dependencies
-[source,groovy]
-[subs=attributes+]
-----
-testImplementation(platform("org.junit:junit-bom:{version}"))
-testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
-testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
-----
-
-.Additional Maven Dependencies
-[source,xml]
-[subs=attributes+]
-----
-<!-- ... -->
-<dependencies>
-	<dependency>
-		<groupId>org.junit.platform</groupId>
-		<artifactId>junit-platform-launcher</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.jupiter</groupId>
-		<artifactId>junit-jupiter-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.vintage</groupId>
-		<artifactId>junit-vintage-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-</dependencies>
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-[[running-tests-ide-eclipse]]
-==== Eclipse
-
-Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
-release.
-
-For more information on using JUnit Platform in Eclipse consult the official _Eclipse
-support for JUnit 5_ section of the
-https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
-(4.7.1a) - New and Noteworthy] documentation.
-
-[[running-tests-ide-netbeans]]
-==== NetBeans
-
-NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
-https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
-
-For more information consult the JUnit 5 section of the
-https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
-release notes].
-
-[[running-tests-ide-vscode]]
-==== Visual Studio Code
-
-https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
-Platform via the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
-Runner] extension which is installed by default as part of the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
-Extension Pack].
-
-For more information consult the _Testing_ section of the
-https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
-documentation.
-
-[[running-tests-ide-other]]
-==== Other IDEs
-
-If you are using an editor or IDE other than one of those listed in the previous sections,
-and it doesn't support running tests on the JUnit Platform, you can use the
-<<running-tests-console-launcher>> to run them from the command line.
-
-[[running-tests-build]]
-=== Build Support
-
-[[running-tests-build-gradle]]
-==== Gradle
-
-Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
-https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
-for executing tests on the JUnit Platform. To enable it, you need to specify
-`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform()
-}
-----
-
-Filtering by <<running-tests-tags, tags>>,
-<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform {
-		includeTags("fast", "smoke & feature-a")
-		// excludeTags("slow", "ci")
-		includeEngines("junit-jupiter")
-		// excludeEngines("junit-vintage")
-	}
-}
-----
-
-Please refer to the
-https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
-for a comprehensive list of options.
-
-[[running-tests-build-gradle-bom]]
-===== Aligning dependency versions
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Explicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation(platform("org.junit:junit-bom:{version}"))
-	testImplementation("org.junit.jupiter:junit-jupiter")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-Since all JUnit artifacts declare a
-https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
-you usually don't need to declare an explicit dependency on it yourself. Instead, it's
-sufficient to declare _one_ regular dependency that includes a version number. Gradle will
-then pull in the BOM automatically so you can omit the version for all other JUnit
-artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Implicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
-}
-----
-<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
-<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
-
-[WARNING]
-.Declaring a dependency on junit-platform-launcher
-====
-Even though pre-8.0 versions of Gradle don't require declaring an explicit
-dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
-of JUnit artifacts on the test runtime classpath are aligned.
-
-Moreover, doing so is recommended and in some cases even required when importing the
-project into an IDE like <<running-tests-ide-eclipse>> or
-<<running-tests-ide-intellij-idea>>.
-====
-
-[[running-tests-build-gradle-engines-configure]]
-===== Configuring Test Engines
-
-In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
-
-To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
-on the dependency-aggregating JUnit Jupiter artifact similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Alternatively, you can use Gradle's
-https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
-support.
-
-[source,kotlin,indent=0]
-[subs=attributes+]
-.Kotlin DSL
-----
-testing {
-	suites {
-		named<JvmTestSuite>("test") {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Groovy DSL
-----
-testing {
-	suites {
-		test {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
-dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
-implementation similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("junit:junit:{junit4-version}")
-	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-[[running-tests-build-gradle-config-params]]
-===== Configuration Parameters
-
-The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
-Platform <<running-tests-config-params, configuration parameters>> to influence test
-discovery and execution. However, you can provide configuration parameters within the
-build script via system properties (as shown below) or via the
-`junit-platform.properties` file.
-
-[source,groovy,indent=0]
-----
-test {
-	// ...
-	systemProperty("junit.jupiter.conditions.deactivate", "*")
-	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
-	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
-	// ...
-}
-----
-
-[[running-tests-build-gradle-logging]]
-===== Configuring Logging (optional)
-
-JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
-emit warnings and debug information. Please refer to the official documentation of
-`{LogManager}` for configuration options.
-
-Alternatively, it's possible to redirect log messages to other logging frameworks such as
-{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
-`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
-qualified class name_ of the `{LogManager}` implementation to use. The example below
-demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
-details).
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
-	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
-	systemProperty("log4j2.disableJmx", "true")
-}
-----
-
-Other logging frameworks provide different means to redirect messages logged using
-`java.util.logging`. For example, for {Logback} you can use the
-https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
-dependency to the test runtime classpath.
-
-[[running-tests-build-maven]]
-==== Maven
-
-Maven Surefire and Maven Failsafe provide
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
-for executing tests on the JUnit Platform. The `pom.xml` file in the
-`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
-and can serve as a starting point for configuring your Maven build.
-
-[WARNING]
-.Minimum required version of Maven Surefire/Failsafe
-====
-As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
-====
-
-[[running-tests-build-maven-bom]]
-===== Aligning dependency versions
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-[[running-tests-build-maven-engines-configure]]
-===== Configuring Test Engines
-
-In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
-`TestEngine` implementation must be added to the test classpath.
-
-To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
-on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
-following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>org.junit.jupiter</groupId>
-			<artifactId>junit-jupiter</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
-long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
-`TestEngine` implementation similar to the following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>junit</groupId>
-			<artifactId>junit</artifactId>
-			<version>{junit4-version}</version>
-			<scope>test</scope>
-		</dependency>
-		<dependency>
-			<groupId>org.junit.vintage</groupId>
-			<artifactId>junit-vintage-engine</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-filter-test-class-names]]
-===== Filtering by Test Class Names
-
-The Maven Surefire Plugin will scan for test classes whose fully qualified names match
-the following patterns.
-
-- `+++**/Test*.java+++`
-- `+++**/*Test.java+++`
-- `+++**/*Tests.java+++`
-- `+++**/*TestCase.java+++`
-
-Moreover, it will exclude all nested classes (including static member classes) by default.
-
-Note, however, that you can override this default behavior by configuring explicit
-`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
-from excluding static member classes, you can override its exclude rules as follows.
-
-[source,xml,indent=0]
-[subs=attributes+]
-.Overriding exclude rules of Maven Surefire
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<excludes>
-						<exclude/>
-					</excludes>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Please see the
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
-documentation for Maven Surefire for details.
-
-[[running-tests-build-maven-filter-tags]]
-===== Filtering by Tags
-
-You can filter tests by <<running-tests-tags, tags>> or
-<<running-tests-tag-expressions, tag expressions>> using the following configuration
-properties.
-
-- to include _tags_ or _tag expressions_, use `groups`.
-- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<groups>acceptance | !feature-a</groups>
-					<excludedGroups>integration, regression</excludedGroups>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-config-params]]
-===== Configuration Parameters
-
-You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
-influence test discovery and execution by declaring the `configurationParameters`
-property and providing key-value pairs using the Java `Properties` file syntax (as shown
-below) or via the `junit-platform.properties` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<properties>
-						<configurationParameters>
-							junit.jupiter.conditions.deactivate = *
-							junit.jupiter.extensions.autodetection.enabled = true
-							junit.jupiter.testinstance.lifecycle.default = per_class
-						</configurationParameters>
-					</properties>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-ant]]
-==== Ant
-
-Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
-provides native support for launching tests on the JUnit Platform. The `junitlauncher`
-task is solely responsible for launching the JUnit Platform and passing it the selected
-collection of tests. The JUnit Platform then delegates to registered test engines to
-discover and execute the tests.
-
-The `junitlauncher` task attempts to align as closely as possible with native Ant
-constructs such as
-link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
-for allowing users to select the tests that they want executed by test engines. This gives
-the task a consistent and natural feel when compared to many other core Ant tasks.
-
-Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
-
-The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
-the task and can serve as a starting point.
-
-===== Basic Usage
-
-The following example demonstrates how to configure the `junitlauncher` task to select a
-single test class (i.e., `com.example.project.CalculatorTests`).
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-
-	<!-- ... -->
-
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<test name="com.example.project.CalculatorTests" />
-	</junitlauncher>
-----
-
-The `test` element allows you to specify a single test class that you want to be selected
-and executed. The `classpath` element allows you to specify the classpath to be used to
-launch the JUnit Platform. This classpath will also be used to locate test classes that
-are part of the execution.
-
-The following example demonstrates how to configure the `junitlauncher` task to select
-test classes from multiple locations.
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-	<!-- ... -->
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<testclasses outputdir="${output.dir}">
-			<fileset dir="${build.classes.dir}">
-				<include name="org/example/**/demo/**/" />
-			</fileset>
-			<fileset dir="${some.other.dir}">
-				<include name="org/myapp/**/" />
-			</fileset>
-		</testclasses>
-	</junitlauncher>
-----
-
-In the above example, the `testclasses` element allows you to select multiple test
-classes that reside in different locations.
-
-For further details on usage and configuration options please refer to the official Ant
-documentation for the
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
-
-[[running-tests-build-spring-boot]]
-==== Spring Boot
-
-link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
-managing the version of JUnit used in your project. In addition, the
-`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
-Jupiter, AssertJ, Mockito, etc.
-
-If your build relies on dependency management support from Spring Boot, you should not
-import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
-result in duplicate (and potentially conflicting) management of JUnit dependencies.
-
-If you need to override the version of a dependency used in your Spring Boot application,
-you have to override the exact name of the
-link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
-defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
-Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
-changing a dependency version is documented for both
-link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
-and
-link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
-
-With Gradle you can override the JUnit Jupiter version by including the following in your
-`build.gradle` file.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-	ext['junit-jupiter.version'] = '{version}'
-----
-
-With Maven you can override the JUnit Jupiter version by including the following in your
-`pom.xml` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<properties>
-		<junit-jupiter.version>{version}</junit-jupiter.version>
-	</properties>
-----
-
-[[running-tests-console-launcher]]
-=== Console Launcher
-
-The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
-Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
-Jupiter tests and print test execution results to the console.
-
-An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
-contains the contents of all of its dependencies is published in the {Maven_Central}
-repository under the
-https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
-directory. It contains the contents of the following artifacts:
-
-include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
-
-[NOTE]
-====
-Since the `junit-platform-console-standalone` JAR contains the contents of all of its
-dependencies, its Maven POM does not declare any dependencies.
-
-Furthermore, it is not very likely that you would need to include a dependency on the
-`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
-script. On the contrary, the executable `junit-platform-console-standalone` JAR is
-typically invoked directly from the command line or a shell script without a build script.
-
-If you need to declare dependencies in your build script on some of the artifacts
-contained in the `junit-platform-console-standalone` artifact, you should declare
-dependencies only on the JUnit artifacts that are used in your project. To simplify
-dependency management of JUnit artifacts in your build, you may wish to use the
-`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
-details.
-====
-
-You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
-standalone `ConsoleLauncher` as shown below.
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
-
-├─ JUnit Vintage
-│  └─ example.JUnit4Tests
-│     └─ standardJUnit4Test ✔
-└─ JUnit Jupiter
-   ├─ StandardTests
-   │  ├─ succeedingTest() ✔
-   │  └─ skippedTest() ↷ for demonstration purposes
-   └─ A special test case
-      ├─ Custom test name containing spaces ✔
-      ├─ ╯°□°)╯ ✔
-      └─ 😱 ✔
-
-Test run finished after 64 ms
-[         5 containers found      ]
-[         0 containers skipped    ]
-[         5 containers started    ]
-[         0 containers aborted    ]
-[         5 containers successful ]
-[         0 containers failed     ]
-[         6 tests found           ]
-[         1 tests skipped         ]
-[         5 tests started         ]
-[         0 tests aborted         ]
-[         5 tests successful      ]
-[         0 tests failed          ]
-----
-
-You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
-all jars in a directory):
-
-[source,console,subs=attributes+]
-----
-$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
-----
-
-[[running-tests-console-launcher-options]]
-==== Subcommands and Options
-
-The `{ConsoleLauncher}` provides the following subcommands:
-
-----
-include::{consoleLauncherOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-discovering-tests]]
-===== Discovering tests
-
-----
-include::{consoleLauncherDiscoverOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-executing-tests]]
-===== Executing tests
-
-.Exit Code
-NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
-All non-zero codes indicate an error of some sort. For example, status code `1`
-is returned if any containers or tests failed. If no tests are discovered and the
-`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
-with a status code of `2`. Unexpected or invalid user input yields a status code
-of `3`. An exit code of `-1` indicates an unspecified error condition.
-
-----
-include::{consoleLauncherExecuteOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-listing-test-engines]]
-===== Listing test engines
-
-----
-include::{consoleLauncherEnginesOptionsFile}[]
-----
-
-[[running-tests-console-launcher-argument-files]]
-==== Argument Files (@-files)
-
-On some platforms you may run into system limitations on the length of a command line when
-creating a command line with lots of options or with long arguments.
-
-The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
-are files that themselves contain arguments to be passed to the command. When the
-underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
-argument beginning with the character `@`, it expands the contents of that file into the
-argument list.
-
-The arguments within a file can be separated by spaces or newlines. If an argument
-contains embedded whitespace, the whole argument should be wrapped in double or single
-quotes -- for example, `"-f=My Files/Stuff.java"`.
-
-If the argument file does not exist or cannot be read, the argument will be treated
-literally and will not be removed. This will likely result in an "unmatched argument"
-error message. You can troubleshoot such errors by executing the command with the
-`picocli.trace` system property set to `DEBUG`.
-
-Multiple _@-files_ may be specified on the command line. The specified path may be
-relative to the current directory or absolute.
-
-You can pass a real parameter with an initial `@` character by escaping it with an
-additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
-subject to expansion.
-
-[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
-==== Redirecting Standard Output/Error to Files
-
-You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
-files using the `--redirect-stdout` and `--redirect-stderr` options:
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
-  --redirect-stdout=stdout.txt \
-  --redirect-stderr=stderr.txt
-----
-
-[NOTE]
-====
-If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
-output streams will be redirected to that file.
-
-The default charset is used for writing to the files.
-====
-
-[[running-tests-console-launcher-color-customization]]
-==== Color Customization
-
-The colors used in the output of the `{ConsoleLauncher}` can be customized.
-The option `--single-color` will apply a built-in monochrome style, while
-`--color-palette` will accept a properties file to override the
-https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
-The properties file below demonstrates the default style:
-
-[source,properties,indent=0]
-----
-SUCCESSFUL = 32
-ABORTED = 33
-FAILED = 31
-SKIPPED = 35
-CONTAINER = 35
-TEST = 34
-DYNAMIC = 35
-REPORTED = 37
-----
-
 [[running-tests-source-launcher]]
 === Source Launcher
 
@@ -869,348 +31,3 @@ java --module-path lib --add-modules org.junit.start HelloTests.java
 
 Find JUnit's class API documentation here: {JUnit}
 
-[[running-tests-discovery-selectors]]
-=== Discovery Selectors
-
-The JUnit Platform provides a rich set of discovery selectors that can be used to specify
-which tests should be discovered or executed.
-
-Discovery selectors can be created programmatically using the factory methods in the
-`{DiscoverySelectors}` class, specified declaratively via annotations when using the
-<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
-generically as strings via their identifiers.
-
-The following discovery selectors are provided out of the box:
-
-|===
-| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
-
-| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
-| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
-| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
-| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
-| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
-| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
-| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
-| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
-| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
-| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
-| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
-| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
-| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
-|===
-
-
-[[running-tests-config-params]]
-=== Configuration Parameters
-
-In addition to instructing the platform which test classes and test engines to include,
-which packages to scan, etc., it is sometimes necessary to provide additional custom
-configuration parameters that are specific to a particular test engine, listener, or
-registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
-parameters_ for the following use cases.
-
-- <<writing-tests-test-instance-lifecycle-changing-default>>
-- <<extensions-registration-automatic-enabling>>
-- <<extensions-conditions-deactivation>>
-- <<writing-tests-display-name-generator-default>>
-
-_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
-engines running on the JUnit Platform via one of the following mechanisms.
-
-1. The `configurationParameter()` and `configurationParameters()` methods in
-   `LauncherDiscoveryRequestBuilder` which
-   is used to build a request supplied to the <<launcher-api, Launcher API>>.
-    +
-   When running tests via one of the tools provided by the JUnit Platform you can specify
-   configuration parameters as follows:
-   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
-     option.
-   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
-     `systemProperties` DSL.
-   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
-     `configurationParameters` property.
-2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
-    +
-   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
-   specify custom configuration files using the `--config-resource` command-line option.
-3. JVM system properties.
-4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
-   in the root of the class path that follows the syntax rules for Java `Properties`
-   files.
-
-NOTE: Configuration parameters are looked up in the exact order defined above.
-Consequently, configuration parameters supplied directly to the `Launcher` take
-precedence over those supplied via custom configuration files, system properties, and the
-default configuration file. Similarly, configuration parameters supplied via system
-properties take precedence over those supplied via the default configuration file.
-
-[[running-tests-config-params-deactivation-pattern]]
-==== Pattern Matching Syntax
-
-This section describes the pattern matching syntax that is applied to the _configuration
-parameters_ used for the following features.
-
-- <<extensions-conditions-deactivation>>
-- <<launcher-api-listeners-custom-deactivation>>
-- <<stacktrace-pruning>>
-- <<extensions-registration-automatic-filtering>>
-
-If the value for the given _configuration parameter_ consists solely of an asterisk
-(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
-will be treated as a comma-separated list of patterns where each pattern will be matched
-against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
-a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
-(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
-pattern will be matched one-to-one against a FQCN.
-
-Examples:
-
-- `+++*+++`: matches all candidate classes.
-- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
-  any of its subpackages.
-- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
-  `MyCustomImpl`.
-- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
-- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
-  `System` or `Unit`.
-- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
-  `org.example.MyCustomImpl`.
-- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
-  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
-
-[[running-tests-tags]]
-=== Tags
-
-Tags are a JUnit Platform concept for marking and filtering tests. The programming model
-for adding tags to containers and tests is defined by the testing framework. For example,
-in JUnit Jupiter based tests, the `@Tag` annotation (see
-<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
-Vintage engine maps `@Category` annotations to tags (see
-<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
-own annotation or other means for users to specify tags.
-
-[[running-tests-tag-syntax-rules]]
-==== Syntax Rules for Tags
-
-Regardless how a tag is specified, the JUnit Platform enforces the following rules:
-
-* A tag must not be `null` or _blank_.
-* A _stripped_ tag must not contain whitespace.
-* A _stripped_ tag must not contain ISO control characters.
-* A _stripped_ tag must not contain any of the following _reserved characters_.
-- `,`: _comma_
-- `(`: _left parenthesis_
-- `)`: _right parenthesis_
-- `&`: _ampersand_
-- `|`: _vertical bar_
-- `!`: _exclamation point_
-
-NOTE: In the above context, "stripped" means that leading and trailing whitespace
-characters have been removed using `java.lang.String.strip()`.
-
-[[running-tests-tag-expressions]]
-==== Tag Expressions
-
-Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
-`(` and `)` can be used to adjust for operator precedence.
-
-Two special expressions are supported, `any()` and `none()`, which select all tests _with_
-any tags at all, and all tests _without_ any tags, respectively.
-These special expressions may be combined with other expressions just like normal tags.
-
-.Operators (in descending order of precedence)
-|===
-| Operator | Meaning | Associativity
-
-| `!`      | not     | right
-| `&`      | and     | left
-| `\|`     | or      | left
-|===
-
-If you are tagging your tests across multiple dimensions, tag expressions help you to
-select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
-_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
-expressions can be useful.
-
-[%header,cols="40,60"]
-|===
-| Tag Expression
-| Selection
-
-| `+++product+++`
-| all tests for *product*
-
-| `+++catalog \| shipping+++`
-| all tests for *catalog* plus all tests for *shipping*
-
-| `+++catalog &amp; shipping+++`
-| all tests for the intersection between *catalog* and *shipping*
-
-| `+++product &amp; !end-to-end+++`
-| all tests for *product*, but not the _end-to-end_ tests
-
-| `+++(micro \| integration) &amp; (product \| shipping)+++`
-| all _micro_ or _integration_ tests for *product* or *shipping*
-|===
-
-[[running-tests-capturing-output]]
-=== Capturing Standard Output/Error
-
-The JUnit Platform provides opt-in support for capturing output printed to `System.out`
-and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
-`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
-parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
-to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
-
-If enabled, the JUnit Platform captures the corresponding output and publishes it as a
-report entry using the `stdout` or `stderr` keys to all registered
-`{TestExecutionListener}` instances immediately before reporting the test or container as
-finished.
-
-Please note that the captured output will only contain output emitted by the thread that
-was used to execute a container or test. Any output by other threads will be omitted
-because particularly when
-<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
-to attribute it to a specific test or container.
-
-[[running-tests-listeners]]
-=== Using Listeners and Interceptors
-
-The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
-and custom user code to react to events fired at various points during the discovery and
-execution of a `TestPlan`.
-
-* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
-  closed.
-* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
-  `LauncherSession`.
-* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
-* `{TestExecutionListener}`: receives events that occur during test execution.
-
-The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
-registered automatically for you in order to support some feature of the build tool or IDE.
-
-The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
-order to produce some form of report or to display a graphical representation of the test
-plan in an IDE. Such listeners may be implemented and automatically registered by a build
-tool or IDE, or they may be included in a third-party library – potentially registered
-for you automatically. You can also implement and register your own listeners.
-
-For details on registering and configuring listeners, see the following sections of this
-guide.
-
-* <<launcher-api-launcher-session-listeners-custom>>
-* <<launcher-api-launcher-interceptors-custom>>
-* <<launcher-api-launcher-discovery-listeners-custom>>
-* <<launcher-api-listeners-custom>>
-* <<launcher-api-listeners-config>>
-* <<launcher-api-listeners-custom-deactivation>>
-
-The JUnit Platform provides the following listeners which you may wish to use with your
-test suite.
-
-<<junit-platform-reporting>> ::
-  `{LegacyXmlReportGeneratingListener}` can be used via the
-  <<running-tests-console-launcher>> or registered manually to generate XML reports
-  compatible with the de facto standard for JUnit 4 based test reports.
-+
-`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
-specified by {OpenTestReporting}. It is auto-registered and can be enabled and
-configured via <<running-tests-config-params>>.
-+
-See <<junit-platform-reporting>> for details.
-
-<<running-tests-listeners-flight-recorder>> ::
-  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
-  Java Flight Recorder events during test discovery and execution.
-
-`{LoggingListener}` ::
-  `TestExecutionListener` for logging informational messages for all events via a
-  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
-
-`{SummaryGeneratingListener}` ::
-  `TestExecutionListener` that generates a summary of the test execution which can be
-  printed via a `PrintWriter`.
-
-`{UniqueIdTrackingListener}` ::
-  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
-  or executed during the execution of the `TestPlan` and generates a file containing the
-  unique IDs once execution of the `TestPlan` has finished.
-
-[[running-tests-listeners-flight-recorder]]
-==== Flight Recorder Support
-
-The JUnit Platform provides opt-in support for generating Flight Recorder events.
-https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
-follows.
-
-> Flight Recorder records events originating from applications, the JVM, and the OS.
-Events are stored in a single file that can be attached to bug reports and examined by
-support engineers, allowing after-the-fact analysis of issues in the period leading up
-to a problem.
-
-In order to record Flight Recorder events generated while running tests, you need to
-start flight recording when launching a test suite via the following java command line
-option.
-
-   -XX:StartFlightRecording:filename=...
-
-Please consult the manual of your build tool for the appropriate commands.
-
-To analyze the recorded events, use the
-https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
-command line tool shipped with recent JDKs or open the recording file with
-https://jdk.java.net/jmc/[JDK Mission Control].
-
-[[stacktrace-pruning]]
-=== Stack Trace Pruning
-
-The JUnit Platform provides built-in support for pruning stack traces produced by failing
-tests. This feature is enabled by default but can be disabled by setting the
-`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
-
-When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
-packages are removed from the stack trace, unless the calls occur after the test itself
-or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
-never be excluded.
-
-In addition, all elements prior to and including the first call from the JUnit Platform
-`Launcher` will be removed.
-
-[[running-tests-discovery-issues]]
-=== Discovery Issues
-
-Test engines may encounter issues during test discovery. For example, the declaration of a
-test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
-Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
-report them with different severity levels:
-
-INFO::
-Indicates that the engine encountered something that could be potentially problematic, but
-could also happen due to a valid setup or configuration.
-
-WARNING::
-Indicates that the engine encountered something that is problematic and might lead to
-unexpected behavior or will be removed or changed in a future release.
-
-ERROR::
-Indicates that the engine encountered something that is definitely problematic and will
-lead to unexpected behavior.
-
-If an engine reports an issue with a severity equal to or higher than a configurable
-_critical_ severity, its tests will not be executed. Instead, the engine will be reported
-as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
-Non-critical issues will be logged but will not prevent the engine from executing its
-tests. The `junit.platform.discovery.issue.severity.critical`
-<<running-tests-config-params, configuration parameter>> can be used to set the critical
-severity level. Currently, the default value is `ERROR` but it may be changed in a future
-release.
-
-TIP: To surface all discovery issues in your project, it is recommended to set the
-`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
-
-In addition, registered `{LauncherDiscoveryListener}` implementations can receive
-discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
-report issues to the user in a more user-friendly way. For example, IDEs may choose to
-display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/stack-trace-pruning.adoc b/documentation/modules/ROOT/pages/running-tests/stack-trace-pruning.adoc
index 3099a146c2b4..afacfdaf0b04 100644
--- a/documentation/modules/ROOT/pages/running-tests/stack-trace-pruning.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/stack-trace-pruning.adoc
@@ -1,1168 +1,3 @@
-[[running-tests]]
-== Running Tests
-
-[[running-tests-ide]]
-=== IDE Support
-
-[[running-tests-ide-intellij-idea]]
-==== IntelliJ IDEA
-
-IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
-information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
-however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
-IDEA download the following JARs automatically based on the API version used in the
-project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
-
-In order to use a different JUnit version (e.g., {version}), you may need to
-include the corresponding versions of the `junit-platform-launcher`,
-`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
-
-.Additional Gradle Dependencies
-[source,groovy]
-[subs=attributes+]
-----
-testImplementation(platform("org.junit:junit-bom:{version}"))
-testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
-testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
-----
-
-.Additional Maven Dependencies
-[source,xml]
-[subs=attributes+]
-----
-<!-- ... -->
-<dependencies>
-	<dependency>
-		<groupId>org.junit.platform</groupId>
-		<artifactId>junit-platform-launcher</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.jupiter</groupId>
-		<artifactId>junit-jupiter-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.vintage</groupId>
-		<artifactId>junit-vintage-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-</dependencies>
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-[[running-tests-ide-eclipse]]
-==== Eclipse
-
-Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
-release.
-
-For more information on using JUnit Platform in Eclipse consult the official _Eclipse
-support for JUnit 5_ section of the
-https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
-(4.7.1a) - New and Noteworthy] documentation.
-
-[[running-tests-ide-netbeans]]
-==== NetBeans
-
-NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
-https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
-
-For more information consult the JUnit 5 section of the
-https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
-release notes].
-
-[[running-tests-ide-vscode]]
-==== Visual Studio Code
-
-https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
-Platform via the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
-Runner] extension which is installed by default as part of the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
-Extension Pack].
-
-For more information consult the _Testing_ section of the
-https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
-documentation.
-
-[[running-tests-ide-other]]
-==== Other IDEs
-
-If you are using an editor or IDE other than one of those listed in the previous sections,
-and it doesn't support running tests on the JUnit Platform, you can use the
-<<running-tests-console-launcher>> to run them from the command line.
-
-[[running-tests-build]]
-=== Build Support
-
-[[running-tests-build-gradle]]
-==== Gradle
-
-Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
-https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
-for executing tests on the JUnit Platform. To enable it, you need to specify
-`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform()
-}
-----
-
-Filtering by <<running-tests-tags, tags>>,
-<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform {
-		includeTags("fast", "smoke & feature-a")
-		// excludeTags("slow", "ci")
-		includeEngines("junit-jupiter")
-		// excludeEngines("junit-vintage")
-	}
-}
-----
-
-Please refer to the
-https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
-for a comprehensive list of options.
-
-[[running-tests-build-gradle-bom]]
-===== Aligning dependency versions
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Explicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation(platform("org.junit:junit-bom:{version}"))
-	testImplementation("org.junit.jupiter:junit-jupiter")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-Since all JUnit artifacts declare a
-https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
-you usually don't need to declare an explicit dependency on it yourself. Instead, it's
-sufficient to declare _one_ regular dependency that includes a version number. Gradle will
-then pull in the BOM automatically so you can omit the version for all other JUnit
-artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Implicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
-}
-----
-<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
-<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
-
-[WARNING]
-.Declaring a dependency on junit-platform-launcher
-====
-Even though pre-8.0 versions of Gradle don't require declaring an explicit
-dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
-of JUnit artifacts on the test runtime classpath are aligned.
-
-Moreover, doing so is recommended and in some cases even required when importing the
-project into an IDE like <<running-tests-ide-eclipse>> or
-<<running-tests-ide-intellij-idea>>.
-====
-
-[[running-tests-build-gradle-engines-configure]]
-===== Configuring Test Engines
-
-In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
-
-To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
-on the dependency-aggregating JUnit Jupiter artifact similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Alternatively, you can use Gradle's
-https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
-support.
-
-[source,kotlin,indent=0]
-[subs=attributes+]
-.Kotlin DSL
-----
-testing {
-	suites {
-		named<JvmTestSuite>("test") {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Groovy DSL
-----
-testing {
-	suites {
-		test {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
-dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
-implementation similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("junit:junit:{junit4-version}")
-	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-[[running-tests-build-gradle-config-params]]
-===== Configuration Parameters
-
-The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
-Platform <<running-tests-config-params, configuration parameters>> to influence test
-discovery and execution. However, you can provide configuration parameters within the
-build script via system properties (as shown below) or via the
-`junit-platform.properties` file.
-
-[source,groovy,indent=0]
-----
-test {
-	// ...
-	systemProperty("junit.jupiter.conditions.deactivate", "*")
-	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
-	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
-	// ...
-}
-----
-
-[[running-tests-build-gradle-logging]]
-===== Configuring Logging (optional)
-
-JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
-emit warnings and debug information. Please refer to the official documentation of
-`{LogManager}` for configuration options.
-
-Alternatively, it's possible to redirect log messages to other logging frameworks such as
-{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
-`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
-qualified class name_ of the `{LogManager}` implementation to use. The example below
-demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
-details).
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
-	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
-	systemProperty("log4j2.disableJmx", "true")
-}
-----
-
-Other logging frameworks provide different means to redirect messages logged using
-`java.util.logging`. For example, for {Logback} you can use the
-https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
-dependency to the test runtime classpath.
-
-[[running-tests-build-maven]]
-==== Maven
-
-Maven Surefire and Maven Failsafe provide
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
-for executing tests on the JUnit Platform. The `pom.xml` file in the
-`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
-and can serve as a starting point for configuring your Maven build.
-
-[WARNING]
-.Minimum required version of Maven Surefire/Failsafe
-====
-As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
-====
-
-[[running-tests-build-maven-bom]]
-===== Aligning dependency versions
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-[[running-tests-build-maven-engines-configure]]
-===== Configuring Test Engines
-
-In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
-`TestEngine` implementation must be added to the test classpath.
-
-To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
-on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
-following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>org.junit.jupiter</groupId>
-			<artifactId>junit-jupiter</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
-long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
-`TestEngine` implementation similar to the following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>junit</groupId>
-			<artifactId>junit</artifactId>
-			<version>{junit4-version}</version>
-			<scope>test</scope>
-		</dependency>
-		<dependency>
-			<groupId>org.junit.vintage</groupId>
-			<artifactId>junit-vintage-engine</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-filter-test-class-names]]
-===== Filtering by Test Class Names
-
-The Maven Surefire Plugin will scan for test classes whose fully qualified names match
-the following patterns.
-
-- `+++**/Test*.java+++`
-- `+++**/*Test.java+++`
-- `+++**/*Tests.java+++`
-- `+++**/*TestCase.java+++`
-
-Moreover, it will exclude all nested classes (including static member classes) by default.
-
-Note, however, that you can override this default behavior by configuring explicit
-`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
-from excluding static member classes, you can override its exclude rules as follows.
-
-[source,xml,indent=0]
-[subs=attributes+]
-.Overriding exclude rules of Maven Surefire
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<excludes>
-						<exclude/>
-					</excludes>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Please see the
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
-documentation for Maven Surefire for details.
-
-[[running-tests-build-maven-filter-tags]]
-===== Filtering by Tags
-
-You can filter tests by <<running-tests-tags, tags>> or
-<<running-tests-tag-expressions, tag expressions>> using the following configuration
-properties.
-
-- to include _tags_ or _tag expressions_, use `groups`.
-- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<groups>acceptance | !feature-a</groups>
-					<excludedGroups>integration, regression</excludedGroups>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-config-params]]
-===== Configuration Parameters
-
-You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
-influence test discovery and execution by declaring the `configurationParameters`
-property and providing key-value pairs using the Java `Properties` file syntax (as shown
-below) or via the `junit-platform.properties` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<properties>
-						<configurationParameters>
-							junit.jupiter.conditions.deactivate = *
-							junit.jupiter.extensions.autodetection.enabled = true
-							junit.jupiter.testinstance.lifecycle.default = per_class
-						</configurationParameters>
-					</properties>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-ant]]
-==== Ant
-
-Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
-provides native support for launching tests on the JUnit Platform. The `junitlauncher`
-task is solely responsible for launching the JUnit Platform and passing it the selected
-collection of tests. The JUnit Platform then delegates to registered test engines to
-discover and execute the tests.
-
-The `junitlauncher` task attempts to align as closely as possible with native Ant
-constructs such as
-link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
-for allowing users to select the tests that they want executed by test engines. This gives
-the task a consistent and natural feel when compared to many other core Ant tasks.
-
-Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
-
-The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
-the task and can serve as a starting point.
-
-===== Basic Usage
-
-The following example demonstrates how to configure the `junitlauncher` task to select a
-single test class (i.e., `com.example.project.CalculatorTests`).
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-
-	<!-- ... -->
-
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<test name="com.example.project.CalculatorTests" />
-	</junitlauncher>
-----
-
-The `test` element allows you to specify a single test class that you want to be selected
-and executed. The `classpath` element allows you to specify the classpath to be used to
-launch the JUnit Platform. This classpath will also be used to locate test classes that
-are part of the execution.
-
-The following example demonstrates how to configure the `junitlauncher` task to select
-test classes from multiple locations.
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-	<!-- ... -->
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<testclasses outputdir="${output.dir}">
-			<fileset dir="${build.classes.dir}">
-				<include name="org/example/**/demo/**/" />
-			</fileset>
-			<fileset dir="${some.other.dir}">
-				<include name="org/myapp/**/" />
-			</fileset>
-		</testclasses>
-	</junitlauncher>
-----
-
-In the above example, the `testclasses` element allows you to select multiple test
-classes that reside in different locations.
-
-For further details on usage and configuration options please refer to the official Ant
-documentation for the
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
-
-[[running-tests-build-spring-boot]]
-==== Spring Boot
-
-link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
-managing the version of JUnit used in your project. In addition, the
-`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
-Jupiter, AssertJ, Mockito, etc.
-
-If your build relies on dependency management support from Spring Boot, you should not
-import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
-result in duplicate (and potentially conflicting) management of JUnit dependencies.
-
-If you need to override the version of a dependency used in your Spring Boot application,
-you have to override the exact name of the
-link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
-defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
-Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
-changing a dependency version is documented for both
-link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
-and
-link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
-
-With Gradle you can override the JUnit Jupiter version by including the following in your
-`build.gradle` file.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-	ext['junit-jupiter.version'] = '{version}'
-----
-
-With Maven you can override the JUnit Jupiter version by including the following in your
-`pom.xml` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<properties>
-		<junit-jupiter.version>{version}</junit-jupiter.version>
-	</properties>
-----
-
-[[running-tests-console-launcher]]
-=== Console Launcher
-
-The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
-Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
-Jupiter tests and print test execution results to the console.
-
-An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
-contains the contents of all of its dependencies is published in the {Maven_Central}
-repository under the
-https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
-directory. It contains the contents of the following artifacts:
-
-include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
-
-[NOTE]
-====
-Since the `junit-platform-console-standalone` JAR contains the contents of all of its
-dependencies, its Maven POM does not declare any dependencies.
-
-Furthermore, it is not very likely that you would need to include a dependency on the
-`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
-script. On the contrary, the executable `junit-platform-console-standalone` JAR is
-typically invoked directly from the command line or a shell script without a build script.
-
-If you need to declare dependencies in your build script on some of the artifacts
-contained in the `junit-platform-console-standalone` artifact, you should declare
-dependencies only on the JUnit artifacts that are used in your project. To simplify
-dependency management of JUnit artifacts in your build, you may wish to use the
-`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
-details.
-====
-
-You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
-standalone `ConsoleLauncher` as shown below.
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
-
-├─ JUnit Vintage
-│  └─ example.JUnit4Tests
-│     └─ standardJUnit4Test ✔
-└─ JUnit Jupiter
-   ├─ StandardTests
-   │  ├─ succeedingTest() ✔
-   │  └─ skippedTest() ↷ for demonstration purposes
-   └─ A special test case
-      ├─ Custom test name containing spaces ✔
-      ├─ ╯°□°)╯ ✔
-      └─ 😱 ✔
-
-Test run finished after 64 ms
-[         5 containers found      ]
-[         0 containers skipped    ]
-[         5 containers started    ]
-[         0 containers aborted    ]
-[         5 containers successful ]
-[         0 containers failed     ]
-[         6 tests found           ]
-[         1 tests skipped         ]
-[         5 tests started         ]
-[         0 tests aborted         ]
-[         5 tests successful      ]
-[         0 tests failed          ]
-----
-
-You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
-all jars in a directory):
-
-[source,console,subs=attributes+]
-----
-$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
-----
-
-[[running-tests-console-launcher-options]]
-==== Subcommands and Options
-
-The `{ConsoleLauncher}` provides the following subcommands:
-
-----
-include::{consoleLauncherOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-discovering-tests]]
-===== Discovering tests
-
-----
-include::{consoleLauncherDiscoverOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-executing-tests]]
-===== Executing tests
-
-.Exit Code
-NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
-All non-zero codes indicate an error of some sort. For example, status code `1`
-is returned if any containers or tests failed. If no tests are discovered and the
-`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
-with a status code of `2`. Unexpected or invalid user input yields a status code
-of `3`. An exit code of `-1` indicates an unspecified error condition.
-
-----
-include::{consoleLauncherExecuteOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-listing-test-engines]]
-===== Listing test engines
-
-----
-include::{consoleLauncherEnginesOptionsFile}[]
-----
-
-[[running-tests-console-launcher-argument-files]]
-==== Argument Files (@-files)
-
-On some platforms you may run into system limitations on the length of a command line when
-creating a command line with lots of options or with long arguments.
-
-The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
-are files that themselves contain arguments to be passed to the command. When the
-underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
-argument beginning with the character `@`, it expands the contents of that file into the
-argument list.
-
-The arguments within a file can be separated by spaces or newlines. If an argument
-contains embedded whitespace, the whole argument should be wrapped in double or single
-quotes -- for example, `"-f=My Files/Stuff.java"`.
-
-If the argument file does not exist or cannot be read, the argument will be treated
-literally and will not be removed. This will likely result in an "unmatched argument"
-error message. You can troubleshoot such errors by executing the command with the
-`picocli.trace` system property set to `DEBUG`.
-
-Multiple _@-files_ may be specified on the command line. The specified path may be
-relative to the current directory or absolute.
-
-You can pass a real parameter with an initial `@` character by escaping it with an
-additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
-subject to expansion.
-
-[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
-==== Redirecting Standard Output/Error to Files
-
-You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
-files using the `--redirect-stdout` and `--redirect-stderr` options:
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
-  --redirect-stdout=stdout.txt \
-  --redirect-stderr=stderr.txt
-----
-
-[NOTE]
-====
-If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
-output streams will be redirected to that file.
-
-The default charset is used for writing to the files.
-====
-
-[[running-tests-console-launcher-color-customization]]
-==== Color Customization
-
-The colors used in the output of the `{ConsoleLauncher}` can be customized.
-The option `--single-color` will apply a built-in monochrome style, while
-`--color-palette` will accept a properties file to override the
-https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
-The properties file below demonstrates the default style:
-
-[source,properties,indent=0]
-----
-SUCCESSFUL = 32
-ABORTED = 33
-FAILED = 31
-SKIPPED = 35
-CONTAINER = 35
-TEST = 34
-DYNAMIC = 35
-REPORTED = 37
-----
-
-[[running-tests-source-launcher]]
-=== Source Launcher
-
-Starting with Java 25 it is possible to write minimal source code test programs
-using the `org.junit.start` module. For example, like in a `HelloTests.java`
-file reading:
-
-```java
-import module org.junit.start;
-
-void main() {
-  JUnit.run();
-}
-
-@Test
-void stringLength() {
-  Assertions.assertEquals(11, "Hello JUnit".length());
-}
-```
-With all required modular JAR files available in a local `lib/` directory, the
-following Java 25+ command will discover and execute tests using the JUnit Platform.
-It will also print the result tree to the console.
-
-```shell
-java --module-path lib --add-modules org.junit.start HelloTests.java
-╷
-└─ JUnit Jupiter ✔
-   └─ HelloTests ✔
-      └─ stringLength() ✔
-```
-
-Find JUnit's class API documentation here: {JUnit}
-
-[[running-tests-discovery-selectors]]
-=== Discovery Selectors
-
-The JUnit Platform provides a rich set of discovery selectors that can be used to specify
-which tests should be discovered or executed.
-
-Discovery selectors can be created programmatically using the factory methods in the
-`{DiscoverySelectors}` class, specified declaratively via annotations when using the
-<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
-generically as strings via their identifiers.
-
-The following discovery selectors are provided out of the box:
-
-|===
-| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
-
-| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
-| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
-| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
-| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
-| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
-| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
-| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
-| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
-| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
-| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
-| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
-| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
-| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
-|===
-
-
-[[running-tests-config-params]]
-=== Configuration Parameters
-
-In addition to instructing the platform which test classes and test engines to include,
-which packages to scan, etc., it is sometimes necessary to provide additional custom
-configuration parameters that are specific to a particular test engine, listener, or
-registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
-parameters_ for the following use cases.
-
-- <<writing-tests-test-instance-lifecycle-changing-default>>
-- <<extensions-registration-automatic-enabling>>
-- <<extensions-conditions-deactivation>>
-- <<writing-tests-display-name-generator-default>>
-
-_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
-engines running on the JUnit Platform via one of the following mechanisms.
-
-1. The `configurationParameter()` and `configurationParameters()` methods in
-   `LauncherDiscoveryRequestBuilder` which
-   is used to build a request supplied to the <<launcher-api, Launcher API>>.
-    +
-   When running tests via one of the tools provided by the JUnit Platform you can specify
-   configuration parameters as follows:
-   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
-     option.
-   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
-     `systemProperties` DSL.
-   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
-     `configurationParameters` property.
-2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
-    +
-   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
-   specify custom configuration files using the `--config-resource` command-line option.
-3. JVM system properties.
-4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
-   in the root of the class path that follows the syntax rules for Java `Properties`
-   files.
-
-NOTE: Configuration parameters are looked up in the exact order defined above.
-Consequently, configuration parameters supplied directly to the `Launcher` take
-precedence over those supplied via custom configuration files, system properties, and the
-default configuration file. Similarly, configuration parameters supplied via system
-properties take precedence over those supplied via the default configuration file.
-
-[[running-tests-config-params-deactivation-pattern]]
-==== Pattern Matching Syntax
-
-This section describes the pattern matching syntax that is applied to the _configuration
-parameters_ used for the following features.
-
-- <<extensions-conditions-deactivation>>
-- <<launcher-api-listeners-custom-deactivation>>
-- <<stacktrace-pruning>>
-- <<extensions-registration-automatic-filtering>>
-
-If the value for the given _configuration parameter_ consists solely of an asterisk
-(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
-will be treated as a comma-separated list of patterns where each pattern will be matched
-against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
-a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
-(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
-pattern will be matched one-to-one against a FQCN.
-
-Examples:
-
-- `+++*+++`: matches all candidate classes.
-- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
-  any of its subpackages.
-- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
-  `MyCustomImpl`.
-- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
-- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
-  `System` or `Unit`.
-- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
-  `org.example.MyCustomImpl`.
-- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
-  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
-
-[[running-tests-tags]]
-=== Tags
-
-Tags are a JUnit Platform concept for marking and filtering tests. The programming model
-for adding tags to containers and tests is defined by the testing framework. For example,
-in JUnit Jupiter based tests, the `@Tag` annotation (see
-<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
-Vintage engine maps `@Category` annotations to tags (see
-<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
-own annotation or other means for users to specify tags.
-
-[[running-tests-tag-syntax-rules]]
-==== Syntax Rules for Tags
-
-Regardless how a tag is specified, the JUnit Platform enforces the following rules:
-
-* A tag must not be `null` or _blank_.
-* A _stripped_ tag must not contain whitespace.
-* A _stripped_ tag must not contain ISO control characters.
-* A _stripped_ tag must not contain any of the following _reserved characters_.
-- `,`: _comma_
-- `(`: _left parenthesis_
-- `)`: _right parenthesis_
-- `&`: _ampersand_
-- `|`: _vertical bar_
-- `!`: _exclamation point_
-
-NOTE: In the above context, "stripped" means that leading and trailing whitespace
-characters have been removed using `java.lang.String.strip()`.
-
-[[running-tests-tag-expressions]]
-==== Tag Expressions
-
-Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
-`(` and `)` can be used to adjust for operator precedence.
-
-Two special expressions are supported, `any()` and `none()`, which select all tests _with_
-any tags at all, and all tests _without_ any tags, respectively.
-These special expressions may be combined with other expressions just like normal tags.
-
-.Operators (in descending order of precedence)
-|===
-| Operator | Meaning | Associativity
-
-| `!`      | not     | right
-| `&`      | and     | left
-| `\|`     | or      | left
-|===
-
-If you are tagging your tests across multiple dimensions, tag expressions help you to
-select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
-_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
-expressions can be useful.
-
-[%header,cols="40,60"]
-|===
-| Tag Expression
-| Selection
-
-| `+++product+++`
-| all tests for *product*
-
-| `+++catalog \| shipping+++`
-| all tests for *catalog* plus all tests for *shipping*
-
-| `+++catalog &amp; shipping+++`
-| all tests for the intersection between *catalog* and *shipping*
-
-| `+++product &amp; !end-to-end+++`
-| all tests for *product*, but not the _end-to-end_ tests
-
-| `+++(micro \| integration) &amp; (product \| shipping)+++`
-| all _micro_ or _integration_ tests for *product* or *shipping*
-|===
-
-[[running-tests-capturing-output]]
-=== Capturing Standard Output/Error
-
-The JUnit Platform provides opt-in support for capturing output printed to `System.out`
-and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
-`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
-parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
-to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
-
-If enabled, the JUnit Platform captures the corresponding output and publishes it as a
-report entry using the `stdout` or `stderr` keys to all registered
-`{TestExecutionListener}` instances immediately before reporting the test or container as
-finished.
-
-Please note that the captured output will only contain output emitted by the thread that
-was used to execute a container or test. Any output by other threads will be omitted
-because particularly when
-<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
-to attribute it to a specific test or container.
-
-[[running-tests-listeners]]
-=== Using Listeners and Interceptors
-
-The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
-and custom user code to react to events fired at various points during the discovery and
-execution of a `TestPlan`.
-
-* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
-  closed.
-* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
-  `LauncherSession`.
-* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
-* `{TestExecutionListener}`: receives events that occur during test execution.
-
-The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
-registered automatically for you in order to support some feature of the build tool or IDE.
-
-The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
-order to produce some form of report or to display a graphical representation of the test
-plan in an IDE. Such listeners may be implemented and automatically registered by a build
-tool or IDE, or they may be included in a third-party library – potentially registered
-for you automatically. You can also implement and register your own listeners.
-
-For details on registering and configuring listeners, see the following sections of this
-guide.
-
-* <<launcher-api-launcher-session-listeners-custom>>
-* <<launcher-api-launcher-interceptors-custom>>
-* <<launcher-api-launcher-discovery-listeners-custom>>
-* <<launcher-api-listeners-custom>>
-* <<launcher-api-listeners-config>>
-* <<launcher-api-listeners-custom-deactivation>>
-
-The JUnit Platform provides the following listeners which you may wish to use with your
-test suite.
-
-<<junit-platform-reporting>> ::
-  `{LegacyXmlReportGeneratingListener}` can be used via the
-  <<running-tests-console-launcher>> or registered manually to generate XML reports
-  compatible with the de facto standard for JUnit 4 based test reports.
-+
-`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
-specified by {OpenTestReporting}. It is auto-registered and can be enabled and
-configured via <<running-tests-config-params>>.
-+
-See <<junit-platform-reporting>> for details.
-
-<<running-tests-listeners-flight-recorder>> ::
-  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
-  Java Flight Recorder events during test discovery and execution.
-
-`{LoggingListener}` ::
-  `TestExecutionListener` for logging informational messages for all events via a
-  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
-
-`{SummaryGeneratingListener}` ::
-  `TestExecutionListener` that generates a summary of the test execution which can be
-  printed via a `PrintWriter`.
-
-`{UniqueIdTrackingListener}` ::
-  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
-  or executed during the execution of the `TestPlan` and generates a file containing the
-  unique IDs once execution of the `TestPlan` has finished.
-
-[[running-tests-listeners-flight-recorder]]
-==== Flight Recorder Support
-
-The JUnit Platform provides opt-in support for generating Flight Recorder events.
-https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
-follows.
-
-> Flight Recorder records events originating from applications, the JVM, and the OS.
-Events are stored in a single file that can be attached to bug reports and examined by
-support engineers, allowing after-the-fact analysis of issues in the period leading up
-to a problem.
-
-In order to record Flight Recorder events generated while running tests, you need to
-start flight recording when launching a test suite via the following java command line
-option.
-
-   -XX:StartFlightRecording:filename=...
-
-Please consult the manual of your build tool for the appropriate commands.
-
-To analyze the recorded events, use the
-https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
-command line tool shipped with recent JDKs or open the recording file with
-https://jdk.java.net/jmc/[JDK Mission Control].
-
 [[stacktrace-pruning]]
 === Stack Trace Pruning
 
@@ -1178,39 +13,3 @@ never be excluded.
 In addition, all elements prior to and including the first call from the JUnit Platform
 `Launcher` will be removed.
 
-[[running-tests-discovery-issues]]
-=== Discovery Issues
-
-Test engines may encounter issues during test discovery. For example, the declaration of a
-test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
-Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
-report them with different severity levels:
-
-INFO::
-Indicates that the engine encountered something that could be potentially problematic, but
-could also happen due to a valid setup or configuration.
-
-WARNING::
-Indicates that the engine encountered something that is problematic and might lead to
-unexpected behavior or will be removed or changed in a future release.
-
-ERROR::
-Indicates that the engine encountered something that is definitely problematic and will
-lead to unexpected behavior.
-
-If an engine reports an issue with a severity equal to or higher than a configurable
-_critical_ severity, its tests will not be executed. Instead, the engine will be reported
-as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
-Non-critical issues will be logged but will not prevent the engine from executing its
-tests. The `junit.platform.discovery.issue.severity.critical`
-<<running-tests-config-params, configuration parameter>> can be used to set the critical
-severity level. Currently, the default value is `ERROR` but it may be changed in a future
-release.
-
-TIP: To surface all discovery issues in your project, it is recommended to set the
-`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
-
-In addition, registered `{LauncherDiscoveryListener}` implementations can receive
-discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
-report issues to the user in a more user-friendly way. For example, IDEs may choose to
-display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/tags.adoc b/documentation/modules/ROOT/pages/running-tests/tags.adoc
index 3099a146c2b4..fc83be081ff6 100644
--- a/documentation/modules/ROOT/pages/running-tests/tags.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/tags.adoc
@@ -1,984 +1,3 @@
-[[running-tests]]
-== Running Tests
-
-[[running-tests-ide]]
-=== IDE Support
-
-[[running-tests-ide-intellij-idea]]
-==== IntelliJ IDEA
-
-IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
-information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
-however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
-IDEA download the following JARs automatically based on the API version used in the
-project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
-
-In order to use a different JUnit version (e.g., {version}), you may need to
-include the corresponding versions of the `junit-platform-launcher`,
-`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
-
-.Additional Gradle Dependencies
-[source,groovy]
-[subs=attributes+]
-----
-testImplementation(platform("org.junit:junit-bom:{version}"))
-testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
-testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
-----
-
-.Additional Maven Dependencies
-[source,xml]
-[subs=attributes+]
-----
-<!-- ... -->
-<dependencies>
-	<dependency>
-		<groupId>org.junit.platform</groupId>
-		<artifactId>junit-platform-launcher</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.jupiter</groupId>
-		<artifactId>junit-jupiter-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.vintage</groupId>
-		<artifactId>junit-vintage-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-</dependencies>
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-[[running-tests-ide-eclipse]]
-==== Eclipse
-
-Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
-release.
-
-For more information on using JUnit Platform in Eclipse consult the official _Eclipse
-support for JUnit 5_ section of the
-https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
-(4.7.1a) - New and Noteworthy] documentation.
-
-[[running-tests-ide-netbeans]]
-==== NetBeans
-
-NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
-https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
-
-For more information consult the JUnit 5 section of the
-https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
-release notes].
-
-[[running-tests-ide-vscode]]
-==== Visual Studio Code
-
-https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
-Platform via the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
-Runner] extension which is installed by default as part of the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
-Extension Pack].
-
-For more information consult the _Testing_ section of the
-https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
-documentation.
-
-[[running-tests-ide-other]]
-==== Other IDEs
-
-If you are using an editor or IDE other than one of those listed in the previous sections,
-and it doesn't support running tests on the JUnit Platform, you can use the
-<<running-tests-console-launcher>> to run them from the command line.
-
-[[running-tests-build]]
-=== Build Support
-
-[[running-tests-build-gradle]]
-==== Gradle
-
-Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
-https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
-for executing tests on the JUnit Platform. To enable it, you need to specify
-`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform()
-}
-----
-
-Filtering by <<running-tests-tags, tags>>,
-<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform {
-		includeTags("fast", "smoke & feature-a")
-		// excludeTags("slow", "ci")
-		includeEngines("junit-jupiter")
-		// excludeEngines("junit-vintage")
-	}
-}
-----
-
-Please refer to the
-https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
-for a comprehensive list of options.
-
-[[running-tests-build-gradle-bom]]
-===== Aligning dependency versions
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Explicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation(platform("org.junit:junit-bom:{version}"))
-	testImplementation("org.junit.jupiter:junit-jupiter")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-Since all JUnit artifacts declare a
-https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
-you usually don't need to declare an explicit dependency on it yourself. Instead, it's
-sufficient to declare _one_ regular dependency that includes a version number. Gradle will
-then pull in the BOM automatically so you can omit the version for all other JUnit
-artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Implicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
-}
-----
-<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
-<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
-
-[WARNING]
-.Declaring a dependency on junit-platform-launcher
-====
-Even though pre-8.0 versions of Gradle don't require declaring an explicit
-dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
-of JUnit artifacts on the test runtime classpath are aligned.
-
-Moreover, doing so is recommended and in some cases even required when importing the
-project into an IDE like <<running-tests-ide-eclipse>> or
-<<running-tests-ide-intellij-idea>>.
-====
-
-[[running-tests-build-gradle-engines-configure]]
-===== Configuring Test Engines
-
-In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
-
-To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
-on the dependency-aggregating JUnit Jupiter artifact similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Alternatively, you can use Gradle's
-https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
-support.
-
-[source,kotlin,indent=0]
-[subs=attributes+]
-.Kotlin DSL
-----
-testing {
-	suites {
-		named<JvmTestSuite>("test") {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Groovy DSL
-----
-testing {
-	suites {
-		test {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
-dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
-implementation similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("junit:junit:{junit4-version}")
-	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-[[running-tests-build-gradle-config-params]]
-===== Configuration Parameters
-
-The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
-Platform <<running-tests-config-params, configuration parameters>> to influence test
-discovery and execution. However, you can provide configuration parameters within the
-build script via system properties (as shown below) or via the
-`junit-platform.properties` file.
-
-[source,groovy,indent=0]
-----
-test {
-	// ...
-	systemProperty("junit.jupiter.conditions.deactivate", "*")
-	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
-	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
-	// ...
-}
-----
-
-[[running-tests-build-gradle-logging]]
-===== Configuring Logging (optional)
-
-JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
-emit warnings and debug information. Please refer to the official documentation of
-`{LogManager}` for configuration options.
-
-Alternatively, it's possible to redirect log messages to other logging frameworks such as
-{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
-`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
-qualified class name_ of the `{LogManager}` implementation to use. The example below
-demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
-details).
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
-	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
-	systemProperty("log4j2.disableJmx", "true")
-}
-----
-
-Other logging frameworks provide different means to redirect messages logged using
-`java.util.logging`. For example, for {Logback} you can use the
-https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
-dependency to the test runtime classpath.
-
-[[running-tests-build-maven]]
-==== Maven
-
-Maven Surefire and Maven Failsafe provide
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
-for executing tests on the JUnit Platform. The `pom.xml` file in the
-`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
-and can serve as a starting point for configuring your Maven build.
-
-[WARNING]
-.Minimum required version of Maven Surefire/Failsafe
-====
-As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
-====
-
-[[running-tests-build-maven-bom]]
-===== Aligning dependency versions
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-[[running-tests-build-maven-engines-configure]]
-===== Configuring Test Engines
-
-In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
-`TestEngine` implementation must be added to the test classpath.
-
-To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
-on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
-following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>org.junit.jupiter</groupId>
-			<artifactId>junit-jupiter</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
-long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
-`TestEngine` implementation similar to the following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>junit</groupId>
-			<artifactId>junit</artifactId>
-			<version>{junit4-version}</version>
-			<scope>test</scope>
-		</dependency>
-		<dependency>
-			<groupId>org.junit.vintage</groupId>
-			<artifactId>junit-vintage-engine</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-filter-test-class-names]]
-===== Filtering by Test Class Names
-
-The Maven Surefire Plugin will scan for test classes whose fully qualified names match
-the following patterns.
-
-- `+++**/Test*.java+++`
-- `+++**/*Test.java+++`
-- `+++**/*Tests.java+++`
-- `+++**/*TestCase.java+++`
-
-Moreover, it will exclude all nested classes (including static member classes) by default.
-
-Note, however, that you can override this default behavior by configuring explicit
-`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
-from excluding static member classes, you can override its exclude rules as follows.
-
-[source,xml,indent=0]
-[subs=attributes+]
-.Overriding exclude rules of Maven Surefire
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<excludes>
-						<exclude/>
-					</excludes>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Please see the
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
-documentation for Maven Surefire for details.
-
-[[running-tests-build-maven-filter-tags]]
-===== Filtering by Tags
-
-You can filter tests by <<running-tests-tags, tags>> or
-<<running-tests-tag-expressions, tag expressions>> using the following configuration
-properties.
-
-- to include _tags_ or _tag expressions_, use `groups`.
-- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<groups>acceptance | !feature-a</groups>
-					<excludedGroups>integration, regression</excludedGroups>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-config-params]]
-===== Configuration Parameters
-
-You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
-influence test discovery and execution by declaring the `configurationParameters`
-property and providing key-value pairs using the Java `Properties` file syntax (as shown
-below) or via the `junit-platform.properties` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<properties>
-						<configurationParameters>
-							junit.jupiter.conditions.deactivate = *
-							junit.jupiter.extensions.autodetection.enabled = true
-							junit.jupiter.testinstance.lifecycle.default = per_class
-						</configurationParameters>
-					</properties>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-ant]]
-==== Ant
-
-Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
-provides native support for launching tests on the JUnit Platform. The `junitlauncher`
-task is solely responsible for launching the JUnit Platform and passing it the selected
-collection of tests. The JUnit Platform then delegates to registered test engines to
-discover and execute the tests.
-
-The `junitlauncher` task attempts to align as closely as possible with native Ant
-constructs such as
-link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
-for allowing users to select the tests that they want executed by test engines. This gives
-the task a consistent and natural feel when compared to many other core Ant tasks.
-
-Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
-
-The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
-the task and can serve as a starting point.
-
-===== Basic Usage
-
-The following example demonstrates how to configure the `junitlauncher` task to select a
-single test class (i.e., `com.example.project.CalculatorTests`).
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-
-	<!-- ... -->
-
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<test name="com.example.project.CalculatorTests" />
-	</junitlauncher>
-----
-
-The `test` element allows you to specify a single test class that you want to be selected
-and executed. The `classpath` element allows you to specify the classpath to be used to
-launch the JUnit Platform. This classpath will also be used to locate test classes that
-are part of the execution.
-
-The following example demonstrates how to configure the `junitlauncher` task to select
-test classes from multiple locations.
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-	<!-- ... -->
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<testclasses outputdir="${output.dir}">
-			<fileset dir="${build.classes.dir}">
-				<include name="org/example/**/demo/**/" />
-			</fileset>
-			<fileset dir="${some.other.dir}">
-				<include name="org/myapp/**/" />
-			</fileset>
-		</testclasses>
-	</junitlauncher>
-----
-
-In the above example, the `testclasses` element allows you to select multiple test
-classes that reside in different locations.
-
-For further details on usage and configuration options please refer to the official Ant
-documentation for the
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
-
-[[running-tests-build-spring-boot]]
-==== Spring Boot
-
-link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
-managing the version of JUnit used in your project. In addition, the
-`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
-Jupiter, AssertJ, Mockito, etc.
-
-If your build relies on dependency management support from Spring Boot, you should not
-import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
-result in duplicate (and potentially conflicting) management of JUnit dependencies.
-
-If you need to override the version of a dependency used in your Spring Boot application,
-you have to override the exact name of the
-link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
-defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
-Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
-changing a dependency version is documented for both
-link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
-and
-link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
-
-With Gradle you can override the JUnit Jupiter version by including the following in your
-`build.gradle` file.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-	ext['junit-jupiter.version'] = '{version}'
-----
-
-With Maven you can override the JUnit Jupiter version by including the following in your
-`pom.xml` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<properties>
-		<junit-jupiter.version>{version}</junit-jupiter.version>
-	</properties>
-----
-
-[[running-tests-console-launcher]]
-=== Console Launcher
-
-The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
-Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
-Jupiter tests and print test execution results to the console.
-
-An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
-contains the contents of all of its dependencies is published in the {Maven_Central}
-repository under the
-https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
-directory. It contains the contents of the following artifacts:
-
-include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
-
-[NOTE]
-====
-Since the `junit-platform-console-standalone` JAR contains the contents of all of its
-dependencies, its Maven POM does not declare any dependencies.
-
-Furthermore, it is not very likely that you would need to include a dependency on the
-`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
-script. On the contrary, the executable `junit-platform-console-standalone` JAR is
-typically invoked directly from the command line or a shell script without a build script.
-
-If you need to declare dependencies in your build script on some of the artifacts
-contained in the `junit-platform-console-standalone` artifact, you should declare
-dependencies only on the JUnit artifacts that are used in your project. To simplify
-dependency management of JUnit artifacts in your build, you may wish to use the
-`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
-details.
-====
-
-You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
-standalone `ConsoleLauncher` as shown below.
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
-
-├─ JUnit Vintage
-│  └─ example.JUnit4Tests
-│     └─ standardJUnit4Test ✔
-└─ JUnit Jupiter
-   ├─ StandardTests
-   │  ├─ succeedingTest() ✔
-   │  └─ skippedTest() ↷ for demonstration purposes
-   └─ A special test case
-      ├─ Custom test name containing spaces ✔
-      ├─ ╯°□°)╯ ✔
-      └─ 😱 ✔
-
-Test run finished after 64 ms
-[         5 containers found      ]
-[         0 containers skipped    ]
-[         5 containers started    ]
-[         0 containers aborted    ]
-[         5 containers successful ]
-[         0 containers failed     ]
-[         6 tests found           ]
-[         1 tests skipped         ]
-[         5 tests started         ]
-[         0 tests aborted         ]
-[         5 tests successful      ]
-[         0 tests failed          ]
-----
-
-You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
-all jars in a directory):
-
-[source,console,subs=attributes+]
-----
-$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
-----
-
-[[running-tests-console-launcher-options]]
-==== Subcommands and Options
-
-The `{ConsoleLauncher}` provides the following subcommands:
-
-----
-include::{consoleLauncherOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-discovering-tests]]
-===== Discovering tests
-
-----
-include::{consoleLauncherDiscoverOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-executing-tests]]
-===== Executing tests
-
-.Exit Code
-NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
-All non-zero codes indicate an error of some sort. For example, status code `1`
-is returned if any containers or tests failed. If no tests are discovered and the
-`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
-with a status code of `2`. Unexpected or invalid user input yields a status code
-of `3`. An exit code of `-1` indicates an unspecified error condition.
-
-----
-include::{consoleLauncherExecuteOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-listing-test-engines]]
-===== Listing test engines
-
-----
-include::{consoleLauncherEnginesOptionsFile}[]
-----
-
-[[running-tests-console-launcher-argument-files]]
-==== Argument Files (@-files)
-
-On some platforms you may run into system limitations on the length of a command line when
-creating a command line with lots of options or with long arguments.
-
-The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
-are files that themselves contain arguments to be passed to the command. When the
-underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
-argument beginning with the character `@`, it expands the contents of that file into the
-argument list.
-
-The arguments within a file can be separated by spaces or newlines. If an argument
-contains embedded whitespace, the whole argument should be wrapped in double or single
-quotes -- for example, `"-f=My Files/Stuff.java"`.
-
-If the argument file does not exist or cannot be read, the argument will be treated
-literally and will not be removed. This will likely result in an "unmatched argument"
-error message. You can troubleshoot such errors by executing the command with the
-`picocli.trace` system property set to `DEBUG`.
-
-Multiple _@-files_ may be specified on the command line. The specified path may be
-relative to the current directory or absolute.
-
-You can pass a real parameter with an initial `@` character by escaping it with an
-additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
-subject to expansion.
-
-[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
-==== Redirecting Standard Output/Error to Files
-
-You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
-files using the `--redirect-stdout` and `--redirect-stderr` options:
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
-  --redirect-stdout=stdout.txt \
-  --redirect-stderr=stderr.txt
-----
-
-[NOTE]
-====
-If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
-output streams will be redirected to that file.
-
-The default charset is used for writing to the files.
-====
-
-[[running-tests-console-launcher-color-customization]]
-==== Color Customization
-
-The colors used in the output of the `{ConsoleLauncher}` can be customized.
-The option `--single-color` will apply a built-in monochrome style, while
-`--color-palette` will accept a properties file to override the
-https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
-The properties file below demonstrates the default style:
-
-[source,properties,indent=0]
-----
-SUCCESSFUL = 32
-ABORTED = 33
-FAILED = 31
-SKIPPED = 35
-CONTAINER = 35
-TEST = 34
-DYNAMIC = 35
-REPORTED = 37
-----
-
-[[running-tests-source-launcher]]
-=== Source Launcher
-
-Starting with Java 25 it is possible to write minimal source code test programs
-using the `org.junit.start` module. For example, like in a `HelloTests.java`
-file reading:
-
-```java
-import module org.junit.start;
-
-void main() {
-  JUnit.run();
-}
-
-@Test
-void stringLength() {
-  Assertions.assertEquals(11, "Hello JUnit".length());
-}
-```
-With all required modular JAR files available in a local `lib/` directory, the
-following Java 25+ command will discover and execute tests using the JUnit Platform.
-It will also print the result tree to the console.
-
-```shell
-java --module-path lib --add-modules org.junit.start HelloTests.java
-╷
-└─ JUnit Jupiter ✔
-   └─ HelloTests ✔
-      └─ stringLength() ✔
-```
-
-Find JUnit's class API documentation here: {JUnit}
-
-[[running-tests-discovery-selectors]]
-=== Discovery Selectors
-
-The JUnit Platform provides a rich set of discovery selectors that can be used to specify
-which tests should be discovered or executed.
-
-Discovery selectors can be created programmatically using the factory methods in the
-`{DiscoverySelectors}` class, specified declaratively via annotations when using the
-<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
-generically as strings via their identifiers.
-
-The following discovery selectors are provided out of the box:
-
-|===
-| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
-
-| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
-| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
-| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
-| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
-| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
-| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
-| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
-| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
-| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
-| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
-| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
-| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
-| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
-|===
-
-
-[[running-tests-config-params]]
-=== Configuration Parameters
-
-In addition to instructing the platform which test classes and test engines to include,
-which packages to scan, etc., it is sometimes necessary to provide additional custom
-configuration parameters that are specific to a particular test engine, listener, or
-registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
-parameters_ for the following use cases.
-
-- <<writing-tests-test-instance-lifecycle-changing-default>>
-- <<extensions-registration-automatic-enabling>>
-- <<extensions-conditions-deactivation>>
-- <<writing-tests-display-name-generator-default>>
-
-_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
-engines running on the JUnit Platform via one of the following mechanisms.
-
-1. The `configurationParameter()` and `configurationParameters()` methods in
-   `LauncherDiscoveryRequestBuilder` which
-   is used to build a request supplied to the <<launcher-api, Launcher API>>.
-    +
-   When running tests via one of the tools provided by the JUnit Platform you can specify
-   configuration parameters as follows:
-   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
-     option.
-   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
-     `systemProperties` DSL.
-   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
-     `configurationParameters` property.
-2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
-    +
-   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
-   specify custom configuration files using the `--config-resource` command-line option.
-3. JVM system properties.
-4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
-   in the root of the class path that follows the syntax rules for Java `Properties`
-   files.
-
-NOTE: Configuration parameters are looked up in the exact order defined above.
-Consequently, configuration parameters supplied directly to the `Launcher` take
-precedence over those supplied via custom configuration files, system properties, and the
-default configuration file. Similarly, configuration parameters supplied via system
-properties take precedence over those supplied via the default configuration file.
-
-[[running-tests-config-params-deactivation-pattern]]
-==== Pattern Matching Syntax
-
-This section describes the pattern matching syntax that is applied to the _configuration
-parameters_ used for the following features.
-
-- <<extensions-conditions-deactivation>>
-- <<launcher-api-listeners-custom-deactivation>>
-- <<stacktrace-pruning>>
-- <<extensions-registration-automatic-filtering>>
-
-If the value for the given _configuration parameter_ consists solely of an asterisk
-(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
-will be treated as a comma-separated list of patterns where each pattern will be matched
-against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
-a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
-(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
-pattern will be matched one-to-one against a FQCN.
-
-Examples:
-
-- `+++*+++`: matches all candidate classes.
-- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
-  any of its subpackages.
-- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
-  `MyCustomImpl`.
-- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
-- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
-  `System` or `Unit`.
-- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
-  `org.example.MyCustomImpl`.
-- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
-  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
-
 [[running-tests-tags]]
 === Tags
 
@@ -1054,163 +73,3 @@ expressions can be useful.
 | all _micro_ or _integration_ tests for *product* or *shipping*
 |===
 
-[[running-tests-capturing-output]]
-=== Capturing Standard Output/Error
-
-The JUnit Platform provides opt-in support for capturing output printed to `System.out`
-and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
-`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
-parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
-to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
-
-If enabled, the JUnit Platform captures the corresponding output and publishes it as a
-report entry using the `stdout` or `stderr` keys to all registered
-`{TestExecutionListener}` instances immediately before reporting the test or container as
-finished.
-
-Please note that the captured output will only contain output emitted by the thread that
-was used to execute a container or test. Any output by other threads will be omitted
-because particularly when
-<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
-to attribute it to a specific test or container.
-
-[[running-tests-listeners]]
-=== Using Listeners and Interceptors
-
-The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
-and custom user code to react to events fired at various points during the discovery and
-execution of a `TestPlan`.
-
-* `{LauncherSessionListener}`: receives events when a `{LauncherSession}` is opened and
-  closed.
-* `{LauncherInterceptor}`: intercepts test discovery and execution in the context of a
-  `LauncherSession`.
-* `{LauncherDiscoveryListener}`: receives events that occur during test discovery.
-* `{TestExecutionListener}`: receives events that occur during test execution.
-
-The `LauncherSessionListener` API is typically implemented by build tools or IDEs and
-registered automatically for you in order to support some feature of the build tool or IDE.
-
-The `LauncherDiscoveryListener` and `TestExecutionListener` APIs are often implemented in
-order to produce some form of report or to display a graphical representation of the test
-plan in an IDE. Such listeners may be implemented and automatically registered by a build
-tool or IDE, or they may be included in a third-party library – potentially registered
-for you automatically. You can also implement and register your own listeners.
-
-For details on registering and configuring listeners, see the following sections of this
-guide.
-
-* <<launcher-api-launcher-session-listeners-custom>>
-* <<launcher-api-launcher-interceptors-custom>>
-* <<launcher-api-launcher-discovery-listeners-custom>>
-* <<launcher-api-listeners-custom>>
-* <<launcher-api-listeners-config>>
-* <<launcher-api-listeners-custom-deactivation>>
-
-The JUnit Platform provides the following listeners which you may wish to use with your
-test suite.
-
-<<junit-platform-reporting>> ::
-  `{LegacyXmlReportGeneratingListener}` can be used via the
-  <<running-tests-console-launcher>> or registered manually to generate XML reports
-  compatible with the de facto standard for JUnit 4 based test reports.
-+
-`{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
-specified by {OpenTestReporting}. It is auto-registered and can be enabled and
-configured via <<running-tests-config-params>>.
-+
-See <<junit-platform-reporting>> for details.
-
-<<running-tests-listeners-flight-recorder>> ::
-  `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
-  Java Flight Recorder events during test discovery and execution.
-
-`{LoggingListener}` ::
-  `TestExecutionListener` for logging informational messages for all events via a
-  `BiConsumer` that consumes `Throwable` and `Supplier<String>`.
-
-`{SummaryGeneratingListener}` ::
-  `TestExecutionListener` that generates a summary of the test execution which can be
-  printed via a `PrintWriter`.
-
-`{UniqueIdTrackingListener}` ::
-  `TestExecutionListener` that that tracks the unique IDs of all tests that were skipped
-  or executed during the execution of the `TestPlan` and generates a file containing the
-  unique IDs once execution of the `TestPlan` has finished.
-
-[[running-tests-listeners-flight-recorder]]
-==== Flight Recorder Support
-
-The JUnit Platform provides opt-in support for generating Flight Recorder events.
-https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
-follows.
-
-> Flight Recorder records events originating from applications, the JVM, and the OS.
-Events are stored in a single file that can be attached to bug reports and examined by
-support engineers, allowing after-the-fact analysis of issues in the period leading up
-to a problem.
-
-In order to record Flight Recorder events generated while running tests, you need to
-start flight recording when launching a test suite via the following java command line
-option.
-
-   -XX:StartFlightRecording:filename=...
-
-Please consult the manual of your build tool for the appropriate commands.
-
-To analyze the recorded events, use the
-https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
-command line tool shipped with recent JDKs or open the recording file with
-https://jdk.java.net/jmc/[JDK Mission Control].
-
-[[stacktrace-pruning]]
-=== Stack Trace Pruning
-
-The JUnit Platform provides built-in support for pruning stack traces produced by failing
-tests. This feature is enabled by default but can be disabled by setting the
-`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
-
-When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
-packages are removed from the stack trace, unless the calls occur after the test itself
-or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
-never be excluded.
-
-In addition, all elements prior to and including the first call from the JUnit Platform
-`Launcher` will be removed.
-
-[[running-tests-discovery-issues]]
-=== Discovery Issues
-
-Test engines may encounter issues during test discovery. For example, the declaration of a
-test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
-Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
-report them with different severity levels:
-
-INFO::
-Indicates that the engine encountered something that could be potentially problematic, but
-could also happen due to a valid setup or configuration.
-
-WARNING::
-Indicates that the engine encountered something that is problematic and might lead to
-unexpected behavior or will be removed or changed in a future release.
-
-ERROR::
-Indicates that the engine encountered something that is definitely problematic and will
-lead to unexpected behavior.
-
-If an engine reports an issue with a severity equal to or higher than a configurable
-_critical_ severity, its tests will not be executed. Instead, the engine will be reported
-as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
-Non-critical issues will be logged but will not prevent the engine from executing its
-tests. The `junit.platform.discovery.issue.severity.critical`
-<<running-tests-config-params, configuration parameter>> can be used to set the critical
-severity level. Currently, the default value is `ERROR` but it may be changed in a future
-release.
-
-TIP: To surface all discovery issues in your project, it is recommended to set the
-`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
-
-In addition, registered `{LauncherDiscoveryListener}` implementations can receive
-discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
-report issues to the user in a more user-friendly way. For example, IDEs may choose to
-display all issues in a list or table.
diff --git a/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc b/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc
index 3099a146c2b4..6b9c40f36be0 100644
--- a/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc
@@ -1,1079 +1,3 @@
-[[running-tests]]
-== Running Tests
-
-[[running-tests-ide]]
-=== IDE Support
-
-[[running-tests-ide-intellij-idea]]
-==== IntelliJ IDEA
-
-IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
-information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
-however, that it is recommended to use IDEA 2017.3 or newer since more recent versions of
-IDEA download the following JARs automatically based on the API version used in the
-project: `junit-platform-launcher`, `junit-jupiter-engine`, and `junit-vintage-engine`.
-
-In order to use a different JUnit version (e.g., {version}), you may need to
-include the corresponding versions of the `junit-platform-launcher`,
-`junit-jupiter-engine`, and `junit-vintage-engine` JARs in the classpath.
-
-.Additional Gradle Dependencies
-[source,groovy]
-[subs=attributes+]
-----
-testImplementation(platform("org.junit:junit-bom:{version}"))
-testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
-testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
-----
-
-.Additional Maven Dependencies
-[source,xml]
-[subs=attributes+]
-----
-<!-- ... -->
-<dependencies>
-	<dependency>
-		<groupId>org.junit.platform</groupId>
-		<artifactId>junit-platform-launcher</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.jupiter</groupId>
-		<artifactId>junit-jupiter-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-	<dependency>
-		<groupId>org.junit.vintage</groupId>
-		<artifactId>junit-vintage-engine</artifactId>
-		<scope>test</scope>
-	</dependency>
-</dependencies>
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-[[running-tests-ide-eclipse]]
-==== Eclipse
-
-Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
-release.
-
-For more information on using JUnit Platform in Eclipse consult the official _Eclipse
-support for JUnit 5_ section of the
-https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
-(4.7.1a) - New and Noteworthy] documentation.
-
-[[running-tests-ide-netbeans]]
-==== NetBeans
-
-NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
-https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
-
-For more information consult the JUnit 5 section of the
-https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
-release notes].
-
-[[running-tests-ide-vscode]]
-==== Visual Studio Code
-
-https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
-Platform via the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test[Java Test
-Runner] extension which is installed by default as part of the
-https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java
-Extension Pack].
-
-For more information consult the _Testing_ section of the
-https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
-documentation.
-
-[[running-tests-ide-other]]
-==== Other IDEs
-
-If you are using an editor or IDE other than one of those listed in the previous sections,
-and it doesn't support running tests on the JUnit Platform, you can use the
-<<running-tests-console-launcher>> to run them from the command line.
-
-[[running-tests-build]]
-=== Build Support
-
-[[running-tests-build-gradle]]
-==== Gradle
-
-Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
-https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
-for executing tests on the JUnit Platform. To enable it, you need to specify
-`useJUnitPlatform()` within a `test` task declaration in `build.gradle`:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform()
-}
-----
-
-Filtering by <<running-tests-tags, tags>>,
-<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	useJUnitPlatform {
-		includeTags("fast", "smoke & feature-a")
-		// excludeTags("slow", "ci")
-		includeEngines("junit-jupiter")
-		// excludeEngines("junit-vintage")
-	}
-}
-----
-
-Please refer to the
-https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
-for a comprehensive list of options.
-
-[[running-tests-build-gradle-bom]]
-===== Aligning dependency versions
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Explicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation(platform("org.junit:junit-bom:{version}"))
-	testImplementation("org.junit.jupiter:junit-jupiter")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-Since all JUnit artifacts declare a
-https://docs.gradle.org/current/userguide/platforms.html[platform] dependency on the BOM,
-you usually don't need to declare an explicit dependency on it yourself. Instead, it's
-sufficient to declare _one_ regular dependency that includes a version number. Gradle will
-then pull in the BOM automatically so you can omit the version for all other JUnit
-artifacts.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Implicit platform dependency on the BOM
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}") // <1>
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher") // <2>
-}
-----
-<1> Dependency declaration with explicit version. Pulls in the `junit-bom` automatically.
-<2> Dependency declaration without version. The version is supplied by the `junit-bom`.
-
-[WARNING]
-.Declaring a dependency on junit-platform-launcher
-====
-Even though pre-8.0 versions of Gradle don't require declaring an explicit
-dependency on `junit-platform-launcher`, it is recommended to do so to ensure the versions
-of JUnit artifacts on the test runtime classpath are aligned.
-
-Moreover, doing so is recommended and in some cases even required when importing the
-project into an IDE like <<running-tests-ide-eclipse>> or
-<<running-tests-ide-intellij-idea>>.
-====
-
-[[running-tests-build-gradle-engines-configure]]
-===== Configuring Test Engines
-
-In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
-
-To configure support for JUnit Jupiter based tests, configure a `testImplementation` dependency
-on the dependency-aggregating JUnit Jupiter artifact similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("org.junit.jupiter:junit-jupiter:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-Alternatively, you can use Gradle's
-https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html[JVM Test Suite]
-support.
-
-[source,kotlin,indent=0]
-[subs=attributes+]
-.Kotlin DSL
-----
-testing {
-	suites {
-		named<JvmTestSuite>("test") {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-[source,groovy,indent=0]
-[subs=attributes+]
-.Groovy DSL
-----
-testing {
-	suites {
-		test {
-			useJUnitJupiter("{version}")
-		}
-	}
-}
-----
-
-The JUnit Platform can run JUnit 4 based tests as long as you configure a `testImplementation`
-dependency on JUnit 4 and a `testRuntimeOnly` dependency on the JUnit Vintage `TestEngine`
-implementation similar to the following.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-dependencies {
-	testImplementation("junit:junit:{junit4-version}")
-	testRuntimeOnly("org.junit.vintage:junit-vintage-engine:{version}")
-	testRuntimeOnly("org.junit.platform:junit-platform-launcher")
-}
-----
-
-[[running-tests-build-gradle-config-params]]
-===== Configuration Parameters
-
-The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
-Platform <<running-tests-config-params, configuration parameters>> to influence test
-discovery and execution. However, you can provide configuration parameters within the
-build script via system properties (as shown below) or via the
-`junit-platform.properties` file.
-
-[source,groovy,indent=0]
-----
-test {
-	// ...
-	systemProperty("junit.jupiter.conditions.deactivate", "*")
-	systemProperty("junit.jupiter.extensions.autodetection.enabled", true)
-	systemProperty("junit.jupiter.testinstance.lifecycle.default", "per_class")
-	// ...
-}
-----
-
-[[running-tests-build-gradle-logging]]
-===== Configuring Logging (optional)
-
-JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
-emit warnings and debug information. Please refer to the official documentation of
-`{LogManager}` for configuration options.
-
-Alternatively, it's possible to redirect log messages to other logging frameworks such as
-{Log4j} or {Logback}. To use a logging framework that provides a custom implementation of
-`{LogManager}`, set the `java.util.logging.manager` system property to the _fully
-qualified class name_ of the `{LogManager}` implementation to use. The example below
-demonstrates how to configure Log4j{nbsp}2.x (see {Log4j_JDK_Logging_Adapter} for
-details).
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-test {
-	systemProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager")
-	// Avoid overhead (see https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx)
-	systemProperty("log4j2.disableJmx", "true")
-}
-----
-
-Other logging frameworks provide different means to redirect messages logged using
-`java.util.logging`. For example, for {Logback} you can use the
-https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
-dependency to the test runtime classpath.
-
-[[running-tests-build-maven]]
-==== Maven
-
-Maven Surefire and Maven Failsafe provide
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
-for executing tests on the JUnit Platform. The `pom.xml` file in the
-`{junit-jupiter-starter-maven}` project demonstrates how to use the Maven Surefire plugin
-and can serve as a starting point for configuring your Maven build.
-
-[WARNING]
-.Minimum required version of Maven Surefire/Failsafe
-====
-As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
-====
-
-[[running-tests-build-maven-bom]]
-===== Aligning dependency versions
-
-Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
-versions of all JUnit artifacts.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-<dependencyManagement>
-	<dependencies>
-		<dependency>
-			<groupId>org.junit</groupId>
-			<artifactId>junit-bom</artifactId>
-			<version>{version}</version>
-			<type>pom</type>
-			<scope>import</scope>
-		</dependency>
-	</dependencies>
-</dependencyManagement>
-----
-
-Using the BOM allows you to omit the version when declaring dependencies on all artifacts
-with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
-
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
-of JUnit used in your Spring Boot application.
-
-[[running-tests-build-maven-engines-configure]]
-===== Configuring Test Engines
-
-In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
-`TestEngine` implementation must be added to the test classpath.
-
-To configure support for JUnit Jupiter based tests, configure `test` scoped dependencies
-on the JUnit Jupiter API and the JUnit Jupiter `TestEngine` implementation similar to the
-following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>org.junit.jupiter</groupId>
-			<artifactId>junit-jupiter</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Maven Surefire and Maven Failsafe can run JUnit 4 based tests alongside Jupiter tests as
-long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintage
-`TestEngine` implementation similar to the following.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<dependencies>
-		<!-- ... -->
-		<dependency>
-			<groupId>junit</groupId>
-			<artifactId>junit</artifactId>
-			<version>{junit4-version}</version>
-			<scope>test</scope>
-		</dependency>
-		<dependency>
-			<groupId>org.junit.vintage</groupId>
-			<artifactId>junit-vintage-engine</artifactId>
-			<version>{version}</version> <!-- can be omitted when using the BOM -->
-			<scope>test</scope>
-		</dependency>
-		<!-- ... -->
-	</dependencies>
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-			<plugin>
-				<artifactId>maven-failsafe-plugin</artifactId>
-				<version>{surefire-version}</version>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-filter-test-class-names]]
-===== Filtering by Test Class Names
-
-The Maven Surefire Plugin will scan for test classes whose fully qualified names match
-the following patterns.
-
-- `+++**/Test*.java+++`
-- `+++**/*Test.java+++`
-- `+++**/*Tests.java+++`
-- `+++**/*TestCase.java+++`
-
-Moreover, it will exclude all nested classes (including static member classes) by default.
-
-Note, however, that you can override this default behavior by configuring explicit
-`include` and `exclude` rules in your `pom.xml` file. For example, to keep Maven Surefire
-from excluding static member classes, you can override its exclude rules as follows.
-
-[source,xml,indent=0]
-[subs=attributes+]
-.Overriding exclude rules of Maven Surefire
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<excludes>
-						<exclude/>
-					</excludes>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-Please see the
-https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
-documentation for Maven Surefire for details.
-
-[[running-tests-build-maven-filter-tags]]
-===== Filtering by Tags
-
-You can filter tests by <<running-tests-tags, tags>> or
-<<running-tests-tag-expressions, tag expressions>> using the following configuration
-properties.
-
-- to include _tags_ or _tag expressions_, use `groups`.
-- to exclude _tags_ or _tag expressions_, use `excludedGroups`.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<groups>acceptance | !feature-a</groups>
-					<excludedGroups>integration, regression</excludedGroups>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-maven-config-params]]
-===== Configuration Parameters
-
-You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
-influence test discovery and execution by declaring the `configurationParameters`
-property and providing key-value pairs using the Java `Properties` file syntax (as shown
-below) or via the `junit-platform.properties` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<!-- ... -->
-	<build>
-		<plugins>
-			<plugin>
-				<artifactId>maven-surefire-plugin</artifactId>
-				<version>{surefire-version}</version>
-				<configuration>
-					<properties>
-						<configurationParameters>
-							junit.jupiter.conditions.deactivate = *
-							junit.jupiter.extensions.autodetection.enabled = true
-							junit.jupiter.testinstance.lifecycle.default = per_class
-						</configurationParameters>
-					</properties>
-				</configuration>
-			</plugin>
-		</plugins>
-	</build>
-	<!-- ... -->
-----
-
-[[running-tests-build-ant]]
-==== Ant
-
-Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
-provides native support for launching tests on the JUnit Platform. The `junitlauncher`
-task is solely responsible for launching the JUnit Platform and passing it the selected
-collection of tests. The JUnit Platform then delegates to registered test engines to
-discover and execute the tests.
-
-The `junitlauncher` task attempts to align as closely as possible with native Ant
-constructs such as
-link:https://ant.apache.org/manual/Types/resources.html#collection[resource collections]
-for allowing users to select the tests that they want executed by test engines. This gives
-the task a consistent and natural feel when compared to many other core Ant tasks.
-
-Starting with version `1.10.6` of Ant, the `junitlauncher` task supports
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tests in a separate JVM].
-
-The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
-the task and can serve as a starting point.
-
-===== Basic Usage
-
-The following example demonstrates how to configure the `junitlauncher` task to select a
-single test class (i.e., `com.example.project.CalculatorTests`).
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-
-	<!-- ... -->
-
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<test name="com.example.project.CalculatorTests" />
-	</junitlauncher>
-----
-
-The `test` element allows you to specify a single test class that you want to be selected
-and executed. The `classpath` element allows you to specify the classpath to be used to
-launch the JUnit Platform. This classpath will also be used to locate test classes that
-are part of the execution.
-
-The following example demonstrates how to configure the `junitlauncher` task to select
-test classes from multiple locations.
-
-[source,xml,indent=0]
-----
-	<path id="test.classpath">
-		<!-- The location where you have your compiled classes -->
-		<pathelement location="${build.classes.dir}" />
-	</path>
-	<!-- ... -->
-	<junitlauncher>
-		<classpath refid="test.classpath" />
-		<testclasses outputdir="${output.dir}">
-			<fileset dir="${build.classes.dir}">
-				<include name="org/example/**/demo/**/" />
-			</fileset>
-			<fileset dir="${some.other.dir}">
-				<include name="org/myapp/**/" />
-			</fileset>
-		</testclasses>
-	</junitlauncher>
-----
-
-In the above example, the `testclasses` element allows you to select multiple test
-classes that reside in different locations.
-
-For further details on usage and configuration options please refer to the official Ant
-documentation for the
-link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
-
-[[running-tests-build-spring-boot]]
-==== Spring Boot
-
-link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
-managing the version of JUnit used in your project. In addition, the
-`spring-boot-starter-test` artifact automatically includes testing libraries such as JUnit
-Jupiter, AssertJ, Mockito, etc.
-
-If your build relies on dependency management support from Spring Boot, you should not
-import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
-result in duplicate (and potentially conflicting) management of JUnit dependencies.
-
-If you need to override the version of a dependency used in your Spring Boot application,
-you have to override the exact name of the
-link:https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#appendix.dependency-versions.properties[version property]
-defined in the BOM used by the Spring Boot plugin. For example, the name of the JUnit
-Jupiter version property in Spring Boot is `junit-jupiter.version`. The mechanism for
-changing a dependency version is documented for both
-link:https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing[Gradle]
-and
-link:https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#using.parent-pom[Maven].
-
-With Gradle you can override the JUnit Jupiter version by including the following in your
-`build.gradle` file.
-
-[source,groovy,indent=0]
-[subs=attributes+]
-----
-	ext['junit-jupiter.version'] = '{version}'
-----
-
-With Maven you can override the JUnit Jupiter version by including the following in your
-`pom.xml` file.
-
-[source,xml,indent=0]
-[subs=attributes+]
-----
-	<properties>
-		<junit-jupiter.version>{version}</junit-jupiter.version>
-	</properties>
-----
-
-[[running-tests-console-launcher]]
-=== Console Launcher
-
-The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
-Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
-Jupiter tests and print test execution results to the console.
-
-An executable _Fat JAR_ (`junit-platform-console-standalone-{version}.jar`) that
-contains the contents of all of its dependencies is published in the {Maven_Central}
-repository under the
-https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
-directory. It contains the contents of the following artifacts:
-
-include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
-
-[NOTE]
-====
-Since the `junit-platform-console-standalone` JAR contains the contents of all of its
-dependencies, its Maven POM does not declare any dependencies.
-
-Furthermore, it is not very likely that you would need to include a dependency on the
-`junit-platform-console-standalone` artifact in your project's Maven POM or Gradle build
-script. On the contrary, the executable `junit-platform-console-standalone` JAR is
-typically invoked directly from the command line or a shell script without a build script.
-
-If you need to declare dependencies in your build script on some of the artifacts
-contained in the `junit-platform-console-standalone` artifact, you should declare
-dependencies only on the JUnit artifacts that are used in your project. To simplify
-dependency management of JUnit artifacts in your build, you may wish to use the
-`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
-details.
-====
-
-You can https://docs.oracle.com/javase/tutorial/deployment/jar/run.html[run] the
-standalone `ConsoleLauncher` as shown below.
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar execute <OPTIONS>
-
-├─ JUnit Vintage
-│  └─ example.JUnit4Tests
-│     └─ standardJUnit4Test ✔
-└─ JUnit Jupiter
-   ├─ StandardTests
-   │  ├─ succeedingTest() ✔
-   │  └─ skippedTest() ↷ for demonstration purposes
-   └─ A special test case
-      ├─ Custom test name containing spaces ✔
-      ├─ ╯°□°)╯ ✔
-      └─ 😱 ✔
-
-Test run finished after 64 ms
-[         5 containers found      ]
-[         0 containers skipped    ]
-[         5 containers started    ]
-[         0 containers aborted    ]
-[         5 containers successful ]
-[         0 containers failed     ]
-[         6 tests found           ]
-[         1 tests skipped         ]
-[         5 tests started         ]
-[         0 tests aborted         ]
-[         5 tests successful      ]
-[         0 tests failed          ]
-----
-
-You can also run the standalone `ConsoleLauncher` as shown below (for example, to include
-all jars in a directory):
-
-[source,console,subs=attributes+]
-----
-$ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
-----
-
-[[running-tests-console-launcher-options]]
-==== Subcommands and Options
-
-The `{ConsoleLauncher}` provides the following subcommands:
-
-----
-include::{consoleLauncherOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-discovering-tests]]
-===== Discovering tests
-
-----
-include::{consoleLauncherDiscoverOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-executing-tests]]
-===== Executing tests
-
-.Exit Code
-NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
-All non-zero codes indicate an error of some sort. For example, status code `1`
-is returned if any containers or tests failed. If no tests are discovered and the
-`--fail-if-no-tests` command-line option is supplied, the `ConsoleLauncher` exits
-with a status code of `2`. Unexpected or invalid user input yields a status code
-of `3`. An exit code of `-1` indicates an unspecified error condition.
-
-----
-include::{consoleLauncherExecuteOptionsFile}[]
-----
-
-[[running-tests-console-launcher-options-listing-test-engines]]
-===== Listing test engines
-
-----
-include::{consoleLauncherEnginesOptionsFile}[]
-----
-
-[[running-tests-console-launcher-argument-files]]
-==== Argument Files (@-files)
-
-On some platforms you may run into system limitations on the length of a command line when
-creating a command line with lots of options or with long arguments.
-
-The `ConsoleLauncher` supports _argument files_, also known as _@-files_. Argument files
-are files that themselves contain arguments to be passed to the command. When the
-underlying https://github.com/remkop/picocli[picocli] command line parser encounters an
-argument beginning with the character `@`, it expands the contents of that file into the
-argument list.
-
-The arguments within a file can be separated by spaces or newlines. If an argument
-contains embedded whitespace, the whole argument should be wrapped in double or single
-quotes -- for example, `"-f=My Files/Stuff.java"`.
-
-If the argument file does not exist or cannot be read, the argument will be treated
-literally and will not be removed. This will likely result in an "unmatched argument"
-error message. You can troubleshoot such errors by executing the command with the
-`picocli.trace` system property set to `DEBUG`.
-
-Multiple _@-files_ may be specified on the command line. The specified path may be
-relative to the current directory or absolute.
-
-You can pass a real parameter with an initial `@` character by escaping it with an
-additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
-subject to expansion.
-
-[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
-==== Redirecting Standard Output/Error to Files
-
-You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
-files using the `--redirect-stdout` and `--redirect-stderr` options:
-
-[source,console,subs=attributes+]
-----
-$ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
-  --redirect-stdout=stdout.txt \
-  --redirect-stderr=stderr.txt
-----
-
-[NOTE]
-====
-If the `--redirect-stdout` and `--redirect-stderr` arguments point to the same file, both
-output streams will be redirected to that file.
-
-The default charset is used for writing to the files.
-====
-
-[[running-tests-console-launcher-color-customization]]
-==== Color Customization
-
-The colors used in the output of the `{ConsoleLauncher}` can be customized.
-The option `--single-color` will apply a built-in monochrome style, while
-`--color-palette` will accept a properties file to override the
-https://en.wikipedia.org/wiki/ANSI_escape_code#Colors[ANSI SGR] color styling.
-The properties file below demonstrates the default style:
-
-[source,properties,indent=0]
-----
-SUCCESSFUL = 32
-ABORTED = 33
-FAILED = 31
-SKIPPED = 35
-CONTAINER = 35
-TEST = 34
-DYNAMIC = 35
-REPORTED = 37
-----
-
-[[running-tests-source-launcher]]
-=== Source Launcher
-
-Starting with Java 25 it is possible to write minimal source code test programs
-using the `org.junit.start` module. For example, like in a `HelloTests.java`
-file reading:
-
-```java
-import module org.junit.start;
-
-void main() {
-  JUnit.run();
-}
-
-@Test
-void stringLength() {
-  Assertions.assertEquals(11, "Hello JUnit".length());
-}
-```
-With all required modular JAR files available in a local `lib/` directory, the
-following Java 25+ command will discover and execute tests using the JUnit Platform.
-It will also print the result tree to the console.
-
-```shell
-java --module-path lib --add-modules org.junit.start HelloTests.java
-╷
-└─ JUnit Jupiter ✔
-   └─ HelloTests ✔
-      └─ stringLength() ✔
-```
-
-Find JUnit's class API documentation here: {JUnit}
-
-[[running-tests-discovery-selectors]]
-=== Discovery Selectors
-
-The JUnit Platform provides a rich set of discovery selectors that can be used to specify
-which tests should be discovered or executed.
-
-Discovery selectors can be created programmatically using the factory methods in the
-`{DiscoverySelectors}` class, specified declaratively via annotations when using the
-<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
-generically as strings via their identifiers.
-
-The following discovery selectors are provided out of the box:
-
-|===
-| Java Type                     | API                                            | Annotation                  | Console Launcher                                 | Identifier
-
-| `{ClasspathResourceSelector}` | `{DiscoverySelectors_selectClasspathResource}` | `{SelectClasspathResource}` | `--select-resource /foo.csv`                     | `resource:/foo.csv`
-| `{ClasspathRootSelector}`     | `{DiscoverySelectors_selectClasspathRoots}`    | --                          | `--scan-classpath bin`                           | `classpath-root:bin`
-| `{ClassSelector}`             | `{DiscoverySelectors_selectClass}`             | `{SelectClasses}`           | `--select-class com.acme.Foo`                    | `class:com.acme.Foo`
-| `{DirectorySelector}`         | `{DiscoverySelectors_selectDirectory}`         | `{SelectDirectories}`       | `--select-directory foo/bar`                     | `directory:foo/bar`
-| `{FileSelector}`              | `{DiscoverySelectors_selectFile}`              | `{SelectFile}`              | `--select-file dir/foo.txt`                      | `file:dir/foo.txt`
-| `{IterationSelector}`         | `{DiscoverySelectors_selectIteration}`         | `{Select}("<identifier>")`  | `--select-iteration method=com.acme.Foo#m[1..2]` | `iteration:method:com.acme.Foo#m[1..2]`
-| `{MethodSelector}`            | `{DiscoverySelectors_selectMethod}`            | `{SelectMethod}`            | `--select-method com.acme.Foo#m`                 | `method:com.acme.Foo#m`
-| `{ModuleSelector}`            | `{DiscoverySelectors_selectModule}`            | `{SelectModules}`           | `--select-module com.acme`                       | `module:com.acme`
-| `{NestedClassSelector}`       | `{DiscoverySelectors_selectNestedClass}`       | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-class:com.acme.Foo/Bar`
-| `{NestedMethodSelector}`      | `{DiscoverySelectors_selectNestedMethod}`      | `{Select}("<identifier>")`  | `--select <identifier>`                          | `nested-method:com.acme.Foo/Bar#m`
-| `{PackageSelector}`           | `{DiscoverySelectors_selectPackage}`           | `{SelectPackages}`          | `--select-package com.acme.foo`                  | `package:com.acme.foo`
-| `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
-| `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
-|===
-
-
-[[running-tests-config-params]]
-=== Configuration Parameters
-
-In addition to instructing the platform which test classes and test engines to include,
-which packages to scan, etc., it is sometimes necessary to provide additional custom
-configuration parameters that are specific to a particular test engine, listener, or
-registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
-parameters_ for the following use cases.
-
-- <<writing-tests-test-instance-lifecycle-changing-default>>
-- <<extensions-registration-automatic-enabling>>
-- <<extensions-conditions-deactivation>>
-- <<writing-tests-display-name-generator-default>>
-
-_Configuration Parameters_ are text-based key-value pairs that can be supplied to test
-engines running on the JUnit Platform via one of the following mechanisms.
-
-1. The `configurationParameter()` and `configurationParameters()` methods in
-   `LauncherDiscoveryRequestBuilder` which
-   is used to build a request supplied to the <<launcher-api, Launcher API>>.
-    +
-   When running tests via one of the tools provided by the JUnit Platform you can specify
-   configuration parameters as follows:
-   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
-     option.
-   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
-     `systemProperties` DSL.
-   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
-     `configurationParameters` property.
-2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
-    +
-   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
-   specify custom configuration files using the `--config-resource` command-line option.
-3. JVM system properties.
-4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
-   in the root of the class path that follows the syntax rules for Java `Properties`
-   files.
-
-NOTE: Configuration parameters are looked up in the exact order defined above.
-Consequently, configuration parameters supplied directly to the `Launcher` take
-precedence over those supplied via custom configuration files, system properties, and the
-default configuration file. Similarly, configuration parameters supplied via system
-properties take precedence over those supplied via the default configuration file.
-
-[[running-tests-config-params-deactivation-pattern]]
-==== Pattern Matching Syntax
-
-This section describes the pattern matching syntax that is applied to the _configuration
-parameters_ used for the following features.
-
-- <<extensions-conditions-deactivation>>
-- <<launcher-api-listeners-custom-deactivation>>
-- <<stacktrace-pruning>>
-- <<extensions-registration-automatic-filtering>>
-
-If the value for the given _configuration parameter_ consists solely of an asterisk
-(`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
-will be treated as a comma-separated list of patterns where each pattern will be matched
-against the fully qualified class name (_FQCN_) of each candidate class. Any dot (`.`) in
-a pattern will match against a dot (`.`) or a dollar sign (`$`) in a FQCN. Any asterisk
-(`+++*+++`) will match against one or more characters in a FQCN. All other characters in a
-pattern will be matched one-to-one against a FQCN.
-
-Examples:
-
-- `+++*+++`: matches all candidate classes.
-- `+++org.junit.*+++`: matches all candidate classes under the `org.junit` base package and
-  any of its subpackages.
-- `+++*.MyCustomImpl+++`: matches every candidate class whose simple class name is exactly
-  `MyCustomImpl`.
-- `+++*System*+++`: matches every candidate class whose FQCN contains `System`.
-- `+++*System*+++, +++*Unit*+++`: matches every candidate class whose FQCN contains
-  `System` or `Unit`.
-- `org.example.MyCustomImpl`: matches the candidate class whose FQCN is exactly
-  `org.example.MyCustomImpl`.
-- `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
-  FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
-
-[[running-tests-tags]]
-=== Tags
-
-Tags are a JUnit Platform concept for marking and filtering tests. The programming model
-for adding tags to containers and tests is defined by the testing framework. For example,
-in JUnit Jupiter based tests, the `@Tag` annotation (see
-<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
-Vintage engine maps `@Category` annotations to tags (see
-<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
-own annotation or other means for users to specify tags.
-
-[[running-tests-tag-syntax-rules]]
-==== Syntax Rules for Tags
-
-Regardless how a tag is specified, the JUnit Platform enforces the following rules:
-
-* A tag must not be `null` or _blank_.
-* A _stripped_ tag must not contain whitespace.
-* A _stripped_ tag must not contain ISO control characters.
-* A _stripped_ tag must not contain any of the following _reserved characters_.
-- `,`: _comma_
-- `(`: _left parenthesis_
-- `)`: _right parenthesis_
-- `&`: _ampersand_
-- `|`: _vertical bar_
-- `!`: _exclamation point_
-
-NOTE: In the above context, "stripped" means that leading and trailing whitespace
-characters have been removed using `java.lang.String.strip()`.
-
-[[running-tests-tag-expressions]]
-==== Tag Expressions
-
-Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
-`(` and `)` can be used to adjust for operator precedence.
-
-Two special expressions are supported, `any()` and `none()`, which select all tests _with_
-any tags at all, and all tests _without_ any tags, respectively.
-These special expressions may be combined with other expressions just like normal tags.
-
-.Operators (in descending order of precedence)
-|===
-| Operator | Meaning | Associativity
-
-| `!`      | not     | right
-| `&`      | and     | left
-| `\|`     | or      | left
-|===
-
-If you are tagging your tests across multiple dimensions, tag expressions help you to
-select which tests to execute. When tagging by test type (e.g., _micro_, _integration_,
-_end-to-end_) and feature (e.g., *product*, *catalog*, *shipping*), the following tag
-expressions can be useful.
-
-[%header,cols="40,60"]
-|===
-| Tag Expression
-| Selection
-
-| `+++product+++`
-| all tests for *product*
-
-| `+++catalog \| shipping+++`
-| all tests for *catalog* plus all tests for *shipping*
-
-| `+++catalog &amp; shipping+++`
-| all tests for the intersection between *catalog* and *shipping*
-
-| `+++product &amp; !end-to-end+++`
-| all tests for *product*, but not the _end-to-end_ tests
-
-| `+++(micro \| integration) &amp; (product \| shipping)+++`
-| all _micro_ or _integration_ tests for *product* or *shipping*
-|===
-
-[[running-tests-capturing-output]]
-=== Capturing Standard Output/Error
-
-The JUnit Platform provides opt-in support for capturing output printed to `System.out`
-and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
-`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
-parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
-to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
-
-If enabled, the JUnit Platform captures the corresponding output and publishes it as a
-report entry using the `stdout` or `stderr` keys to all registered
-`{TestExecutionListener}` instances immediately before reporting the test or container as
-finished.
-
-Please note that the captured output will only contain output emitted by the thread that
-was used to execute a container or test. Any output by other threads will be omitted
-because particularly when
-<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
-to attribute it to a specific test or container.
-
 [[running-tests-listeners]]
 === Using Listeners and Interceptors
 
@@ -1163,54 +87,3 @@ https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
 command line tool shipped with recent JDKs or open the recording file with
 https://jdk.java.net/jmc/[JDK Mission Control].
 
-[[stacktrace-pruning]]
-=== Stack Trace Pruning
-
-The JUnit Platform provides built-in support for pruning stack traces produced by failing
-tests. This feature is enabled by default but can be disabled by setting the
-`junit.platform.stacktrace.pruning.enabled` _configuration parameter_ to `false`.
-
-When enabled, all calls from the `org.junit`, `jdk.internal.reflect`, and `sun.reflect`
-packages are removed from the stack trace, unless the calls occur after the test itself
-or any of its ancestors. For that reason, calls to `{Assertions}` or `{Assumptions}` will
-never be excluded.
-
-In addition, all elements prior to and including the first call from the JUnit Platform
-`Launcher` will be removed.
-
-[[running-tests-discovery-issues]]
-=== Discovery Issues
-
-Test engines may encounter issues during test discovery. For example, the declaration of a
-test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
-Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
-report them with different severity levels:
-
-INFO::
-Indicates that the engine encountered something that could be potentially problematic, but
-could also happen due to a valid setup or configuration.
-
-WARNING::
-Indicates that the engine encountered something that is problematic and might lead to
-unexpected behavior or will be removed or changed in a future release.
-
-ERROR::
-Indicates that the engine encountered something that is definitely problematic and will
-lead to unexpected behavior.
-
-If an engine reports an issue with a severity equal to or higher than a configurable
-_critical_ severity, its tests will not be executed. Instead, the engine will be reported
-as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
-Non-critical issues will be logged but will not prevent the engine from executing its
-tests. The `junit.platform.discovery.issue.severity.critical`
-<<running-tests-config-params, configuration parameter>> can be used to set the critical
-severity level. Currently, the default value is `ERROR` but it may be changed in a future
-release.
-
-TIP: To surface all discovery issues in your project, it is recommended to set the
-`junit.platform.discovery.issue.severity.critical` configuration parameter to `INFO`.
-
-In addition, registered `{LauncherDiscoveryListener}` implementations can receive
-discovery issues via the `issueEncountered()` method. This allows IDEs and build tools to
-report issues to the user in a more user-friendly way. For example, IDEs may choose to
-display all issues in a list or table.

From 9a915125a3438d1c989526c1cbb2100595ca0fb3 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:11 +0100
Subject: [PATCH 25/57] Migrate running-tests sections to Antora syntax

---
 .../pages/running-tests/build-support.adoc    | 32 +++++++++----------
 .../capturing-standard-output-error.adoc      |  4 +--
 .../configuration-parameters.adoc             |  6 ++--
 .../pages/running-tests/console-launcher.adoc | 18 +++++------
 .../pages/running-tests/discovery-issues.adoc |  3 +-
 .../running-tests/discovery-selectors.adoc    |  5 +--
 .../ROOT/pages/running-tests/ide-support.adoc | 14 ++++----
 .../ROOT/pages/running-tests/intro.adoc       |  4 +--
 .../pages/running-tests/source-launcher.adoc  |  4 +--
 .../running-tests/stack-trace-pruning.adoc    |  4 +--
 .../ROOT/pages/running-tests/tags.adoc        |  8 ++---
 .../using-listeners-and-interceptors.adoc     |  6 ++--
 12 files changed, 43 insertions(+), 65 deletions(-)

diff --git a/documentation/modules/ROOT/pages/running-tests/build-support.adoc b/documentation/modules/ROOT/pages/running-tests/build-support.adoc
index 46ab1eebb6d4..dcb14a1d1ec0 100644
--- a/documentation/modules/ROOT/pages/running-tests/build-support.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/build-support.adoc
@@ -1,8 +1,7 @@
-[[running-tests-build]]
-=== Build Support
+= Build Support
 
 [[running-tests-build-gradle]]
-==== Gradle
+== Gradle
 
 Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
 https://docs.gradle.org/current/userguide/java_testing.html#using_junit5[native support]
@@ -38,7 +37,7 @@ https://docs.gradle.org/current/userguide/java_testing.html[official Gradle docu
 for a comprehensive list of options.
 
 [[running-tests-build-gradle-bom]]
-===== Aligning dependency versions
+=== Aligning dependency versions
 
 TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
 of JUnit used in your Spring Boot application.
@@ -93,7 +92,7 @@ project into an IDE like <<running-tests-ide-eclipse>> or
 ====
 
 [[running-tests-build-gradle-engines-configure]]
-===== Configuring Test Engines
+=== Configuring Test Engines
 
 In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
 
@@ -154,7 +153,7 @@ dependencies {
 ----
 
 [[running-tests-build-gradle-config-params]]
-===== Configuration Parameters
+=== Configuration Parameters
 
 The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
 Platform <<running-tests-config-params, configuration parameters>> to influence test
@@ -174,7 +173,7 @@ test {
 ----
 
 [[running-tests-build-gradle-logging]]
-===== Configuring Logging (optional)
+=== Configuring Logging (optional)
 
 JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
 emit warnings and debug information. Please refer to the official documentation of
@@ -203,7 +202,7 @@ https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it
 dependency to the test runtime classpath.
 
 [[running-tests-build-maven]]
-==== Maven
+== Maven
 
 Maven Surefire and Maven Failsafe provide
 https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html[native support]
@@ -218,7 +217,7 @@ As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.
 ====
 
 [[running-tests-build-maven-bom]]
-===== Aligning dependency versions
+=== Aligning dependency versions
 
 Unless you're using Spring Boot which defines its own way of managing dependencies, it is
 recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
@@ -247,7 +246,7 @@ TIP: See <<running-tests-build-spring-boot>> for details on how to override the
 of JUnit used in your Spring Boot application.
 
 [[running-tests-build-maven-engines-configure]]
-===== Configuring Test Engines
+=== Configuring Test Engines
 
 In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
 `TestEngine` implementation must be added to the test classpath.
@@ -326,7 +325,7 @@ long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintag
 ----
 
 [[running-tests-build-maven-filter-test-class-names]]
-===== Filtering by Test Class Names
+=== Filtering by Test Class Names
 
 The Maven Surefire Plugin will scan for test classes whose fully qualified names match
 the following patterns.
@@ -368,7 +367,7 @@ https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclu
 documentation for Maven Surefire for details.
 
 [[running-tests-build-maven-filter-tags]]
-===== Filtering by Tags
+=== Filtering by Tags
 
 You can filter tests by <<running-tests-tags, tags>> or
 <<running-tests-tag-expressions, tag expressions>> using the following configuration
@@ -397,7 +396,7 @@ properties.
 ----
 
 [[running-tests-build-maven-config-params]]
-===== Configuration Parameters
+=== Configuration Parameters
 
 You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
 influence test discovery and execution by declaring the `configurationParameters`
@@ -429,7 +428,7 @@ below) or via the `junit-platform.properties` file.
 ----
 
 [[running-tests-build-ant]]
-==== Ant
+== Ant
 
 Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
 link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher`] task that
@@ -450,7 +449,7 @@ link:https://ant.apache.org/manual/Tasks/junitlauncher.html#fork[forking the tes
 The `build.xml` file in the `{junit-jupiter-starter-ant}` project demonstrates how to use
 the task and can serve as a starting point.
 
-===== Basic Usage
+=== Basic Usage
 
 The following example demonstrates how to configure the `junitlauncher` task to select a
 single test class (i.e., `com.example.project.CalculatorTests`).
@@ -506,7 +505,7 @@ documentation for the
 link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
 
 [[running-tests-build-spring-boot]]
-==== Spring Boot
+== Spring Boot
 
 link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
 managing the version of JUnit used in your project. In addition, the
@@ -546,4 +545,3 @@ With Maven you can override the JUnit Jupiter version by including the following
 		<junit-jupiter.version>{version}</junit-jupiter.version>
 	</properties>
 ----
-
diff --git a/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc b/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc
index a74e8fec7b6c..a8d6ca7e0509 100644
--- a/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc
@@ -1,5 +1,4 @@
-[[running-tests-capturing-output]]
-=== Capturing Standard Output/Error
+= Capturing Standard Output/Error
 
 The JUnit Platform provides opt-in support for capturing output printed to `System.out`
 and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
@@ -17,4 +16,3 @@ was used to execute a container or test. Any output by other threads will be omi
 because particularly when
 <<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
 to attribute it to a specific test or container.
-
diff --git a/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc b/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc
index 92b99db8a69b..5e43efa01b84 100644
--- a/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc
@@ -1,5 +1,4 @@
-[[running-tests-config-params]]
-=== Configuration Parameters
+= Configuration Parameters
 
 In addition to instructing the platform which test classes and test engines to include,
 which packages to scan, etc., it is sometimes necessary to provide additional custom
@@ -43,7 +42,7 @@ default configuration file. Similarly, configuration parameters supplied via sys
 properties take precedence over those supplied via the default configuration file.
 
 [[running-tests-config-params-deactivation-pattern]]
-==== Pattern Matching Syntax
+== Pattern Matching Syntax
 
 This section describes the pattern matching syntax that is applied to the _configuration
 parameters_ used for the following features.
@@ -75,4 +74,3 @@ Examples:
   `org.example.MyCustomImpl`.
 - `org.example.MyCustomImpl, org.example.TheirCustomImpl`: matches candidate classes whose
   FQCN is exactly `org.example.MyCustomImpl` or `org.example.TheirCustomImpl`.
-
diff --git a/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc b/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc
index a09e1b1a0584..75ae13ce2f7f 100644
--- a/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc
@@ -1,5 +1,4 @@
-[[running-tests-console-launcher]]
-=== Console Launcher
+= Console Launcher
 
 The `{ConsoleLauncher}` is a command-line Java application that lets you launch the JUnit
 Platform from the console. For example, it can be used to run JUnit Vintage and JUnit
@@ -74,7 +73,7 @@ $ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS
 ----
 
 [[running-tests-console-launcher-options]]
-==== Subcommands and Options
+== Subcommands and Options
 
 The `{ConsoleLauncher}` provides the following subcommands:
 
@@ -83,14 +82,14 @@ include::{consoleLauncherOptionsFile}[]
 ----
 
 [[running-tests-console-launcher-options-discovering-tests]]
-===== Discovering tests
+=== Discovering tests
 
 ----
 include::{consoleLauncherDiscoverOptionsFile}[]
 ----
 
 [[running-tests-console-launcher-options-executing-tests]]
-===== Executing tests
+=== Executing tests
 
 .Exit Code
 NOTE: On successful runs, the `{ConsoleLauncher}` exits with a status code of `0`.
@@ -105,14 +104,14 @@ include::{consoleLauncherExecuteOptionsFile}[]
 ----
 
 [[running-tests-console-launcher-options-listing-test-engines]]
-===== Listing test engines
+=== Listing test engines
 
 ----
 include::{consoleLauncherEnginesOptionsFile}[]
 ----
 
 [[running-tests-console-launcher-argument-files]]
-==== Argument Files (@-files)
+== Argument Files (@-files)
 
 On some platforms you may run into system limitations on the length of a command line when
 creating a command line with lots of options or with long arguments.
@@ -140,7 +139,7 @@ additional `@` symbol. For example, `@@somearg` will become `@somearg` and will
 subject to expansion.
 
 [[running-tests-console-launcher-redirecting-stdout-and-stderr]]
-==== Redirecting Standard Output/Error to Files
+== Redirecting Standard Output/Error to Files
 
 You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
 files using the `--redirect-stdout` and `--redirect-stderr` options:
@@ -161,7 +160,7 @@ The default charset is used for writing to the files.
 ====
 
 [[running-tests-console-launcher-color-customization]]
-==== Color Customization
+== Color Customization
 
 The colors used in the output of the `{ConsoleLauncher}` can be customized.
 The option `--single-color` will apply a built-in monochrome style, while
@@ -180,4 +179,3 @@ TEST = 34
 DYNAMIC = 35
 REPORTED = 37
 ----
-
diff --git a/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc b/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc
index 32005494d602..b4d06dff4bb9 100644
--- a/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc
@@ -1,5 +1,4 @@
-[[running-tests-discovery-issues]]
-=== Discovery Issues
+= Discovery Issues
 
 Test engines may encounter issues during test discovery. For example, the declaration of a
 test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
diff --git a/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc b/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc
index 3e912914dd0d..68dc2a0d9a98 100644
--- a/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc
@@ -1,5 +1,4 @@
-[[running-tests-discovery-selectors]]
-=== Discovery Selectors
+= Discovery Selectors
 
 The JUnit Platform provides a rich set of discovery selectors that can be used to specify
 which tests should be discovered or executed.
@@ -28,5 +27,3 @@ The following discovery selectors are provided out of the box:
 | `{UniqueIdSelector}`          | `{DiscoverySelectors_selectUniqueId}`          | `{Select}("<identifier>")`  | `--select-unique-id <identifier>`                | `uid:[engine:Foo]/[segment:Bar]`
 | `{UriSelector}`               | `{DiscoverySelectors_selectUri}`               | `{SelectUris}`              | `--select-uri \file:///foo.txt`                  | `uri:file:///foo.txt`
 |===
-
-
diff --git a/documentation/modules/ROOT/pages/running-tests/ide-support.adoc b/documentation/modules/ROOT/pages/running-tests/ide-support.adoc
index b05f7483572a..d3330c3c1038 100644
--- a/documentation/modules/ROOT/pages/running-tests/ide-support.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/ide-support.adoc
@@ -1,8 +1,7 @@
-[[running-tests-ide]]
-=== IDE Support
+= IDE Support
 
 [[running-tests-ide-intellij-idea]]
-==== IntelliJ IDEA
+== IntelliJ IDEA
 
 IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
 information, please consult this https://jb.gg/junit-idea/[IntelliJ IDEA resource]. Note,
@@ -60,7 +59,7 @@ testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
 ----
 
 [[running-tests-ide-eclipse]]
-==== Eclipse
+== Eclipse
 
 Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
 release.
@@ -71,7 +70,7 @@ https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxy
 (4.7.1a) - New and Noteworthy] documentation.
 
 [[running-tests-ide-netbeans]]
-==== NetBeans
+== NetBeans
 
 NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
 https://netbeans.apache.org/download/nb100/nb100.html[Apache NetBeans 10.0 release].
@@ -81,7 +80,7 @@ https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 1
 release notes].
 
 [[running-tests-ide-vscode]]
-==== Visual Studio Code
+== Visual Studio Code
 
 https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
 Platform via the
@@ -95,9 +94,8 @@ https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio
 documentation.
 
 [[running-tests-ide-other]]
-==== Other IDEs
+== Other IDEs
 
 If you are using an editor or IDE other than one of those listed in the previous sections,
 and it doesn't support running tests on the JUnit Platform, you can use the
 <<running-tests-console-launcher>> to run them from the command line.
-
diff --git a/documentation/modules/ROOT/pages/running-tests/intro.adoc b/documentation/modules/ROOT/pages/running-tests/intro.adoc
index fa0b0d985b0f..82162ef9cb47 100644
--- a/documentation/modules/ROOT/pages/running-tests/intro.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/intro.adoc
@@ -1,3 +1,3 @@
-[[running-tests]]
-== Running Tests
+= Running Tests
 
+This section explains how to run tests from IDEs and build tools.
diff --git a/documentation/modules/ROOT/pages/running-tests/source-launcher.adoc b/documentation/modules/ROOT/pages/running-tests/source-launcher.adoc
index 6de303753743..151cfd54b99f 100644
--- a/documentation/modules/ROOT/pages/running-tests/source-launcher.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/source-launcher.adoc
@@ -1,5 +1,4 @@
-[[running-tests-source-launcher]]
-=== Source Launcher
+= Source Launcher
 
 Starting with Java 25 it is possible to write minimal source code test programs
 using the `org.junit.start` module. For example, like in a `HelloTests.java`
@@ -30,4 +29,3 @@ java --module-path lib --add-modules org.junit.start HelloTests.java
 ```
 
 Find JUnit's class API documentation here: {JUnit}
-
diff --git a/documentation/modules/ROOT/pages/running-tests/stack-trace-pruning.adoc b/documentation/modules/ROOT/pages/running-tests/stack-trace-pruning.adoc
index afacfdaf0b04..a3161def7e75 100644
--- a/documentation/modules/ROOT/pages/running-tests/stack-trace-pruning.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/stack-trace-pruning.adoc
@@ -1,5 +1,4 @@
-[[stacktrace-pruning]]
-=== Stack Trace Pruning
+= Stack Trace Pruning
 
 The JUnit Platform provides built-in support for pruning stack traces produced by failing
 tests. This feature is enabled by default but can be disabled by setting the
@@ -12,4 +11,3 @@ never be excluded.
 
 In addition, all elements prior to and including the first call from the JUnit Platform
 `Launcher` will be removed.
-
diff --git a/documentation/modules/ROOT/pages/running-tests/tags.adoc b/documentation/modules/ROOT/pages/running-tests/tags.adoc
index fc83be081ff6..79c807264375 100644
--- a/documentation/modules/ROOT/pages/running-tests/tags.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/tags.adoc
@@ -1,5 +1,4 @@
-[[running-tests-tags]]
-=== Tags
+= Tags
 
 Tags are a JUnit Platform concept for marking and filtering tests. The programming model
 for adding tags to containers and tests is defined by the testing framework. For example,
@@ -10,7 +9,7 @@ Vintage engine maps `@Category` annotations to tags (see
 own annotation or other means for users to specify tags.
 
 [[running-tests-tag-syntax-rules]]
-==== Syntax Rules for Tags
+== Syntax Rules for Tags
 
 Regardless how a tag is specified, the JUnit Platform enforces the following rules:
 
@@ -29,7 +28,7 @@ NOTE: In the above context, "stripped" means that leading and trailing whitespac
 characters have been removed using `java.lang.String.strip()`.
 
 [[running-tests-tag-expressions]]
-==== Tag Expressions
+== Tag Expressions
 
 Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
 `(` and `)` can be used to adjust for operator precedence.
@@ -72,4 +71,3 @@ expressions can be useful.
 | `+++(micro \| integration) &amp; (product \| shipping)+++`
 | all _micro_ or _integration_ tests for *product* or *shipping*
 |===
-
diff --git a/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc b/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc
index 6b9c40f36be0..8e03a5a22c94 100644
--- a/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc
@@ -1,5 +1,4 @@
-[[running-tests-listeners]]
-=== Using Listeners and Interceptors
+= Using Listeners and Interceptors
 
 The JUnit Platform provides the following listener APIs that allow JUnit, third parties,
 and custom user code to react to events fired at various points during the discovery and
@@ -63,7 +62,7 @@ See <<junit-platform-reporting>> for details.
   unique IDs once execution of the `TestPlan` has finished.
 
 [[running-tests-listeners-flight-recorder]]
-==== Flight Recorder Support
+== Flight Recorder Support
 
 The JUnit Platform provides opt-in support for generating Flight Recorder events.
 https://openjdk.java.net/jeps/328[JEP 328] describes the Java Flight Recorder (JFR) as
@@ -86,4 +85,3 @@ To analyze the recorded events, use the
 https://docs.oracle.com/en/java/javase/17/docs/specs/man/jfr.html[jfr]
 command line tool shipped with recent JDKs or open the recording file with
 https://jdk.java.net/jmc/[JDK Mission Control].
-

From 8f2ab798b4c2ccd35d8a3ede87efea63b823b577 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:12 +0100
Subject: [PATCH 26/57] Add running-tests sections to navigation

---
 documentation/modules/ROOT/nav.adoc | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/documentation/modules/ROOT/nav.adoc b/documentation/modules/ROOT/nav.adoc
index 96c84890418b..37c8b335fa42 100644
--- a/documentation/modules/ROOT/nav.adoc
+++ b/documentation/modules/ROOT/nav.adoc
@@ -24,3 +24,15 @@
 ** xref:writing-tests/parallel-execution.adoc[]
 ** xref:writing-tests/built-in-extensions.adoc[]
 * xref:migrating-from-junit4.adoc[]
+* xref:running-tests/intro.adoc[]
+** xref:running-tests/ide-support.adoc[]
+** xref:running-tests/build-support.adoc[]
+** xref:running-tests/console-launcher.adoc[]
+** xref:running-tests/source-launcher.adoc[]
+** xref:running-tests/discovery-selectors.adoc[]
+** xref:running-tests/configuration-parameters.adoc[]
+** xref:running-tests/tags.adoc[]
+** xref:running-tests/capturing-standard-output-error.adoc[]
+** xref:running-tests/using-listeners-and-interceptors.adoc[]
+** xref:running-tests/stack-trace-pruning.adoc[]
+** xref:running-tests/discovery-issues.adoc[]

From 6ffb4857d69f9a5441a51fcd30994d7095bbf585 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:12 +0100
Subject: [PATCH 27/57] Move extensions.adoc to Antora module

---
 .../conditional-test-execution.adoc}          |    0
 .../pages/extensions/exception-handling.adoc  | 1257 +++++++++++++++++
 .../extensions/intercepting-invocations.adoc  | 1257 +++++++++++++++++
 .../keeping-state-in-extensions.adoc          | 1257 +++++++++++++++++
 .../ROOT/pages/extensions/overview.adoc       | 1257 +++++++++++++++++
 .../extensions/parameter-resolution.adoc      | 1257 +++++++++++++++++
 .../extensions/pre-interrupt-callback.adoc    | 1257 +++++++++++++++++
 ...vocation-contexts-for-class-templates.adoc | 1257 +++++++++++++++++
 ...nvocation-contexts-for-test-templates.adoc | 1257 +++++++++++++++++
 .../extensions/registering-extensions.adoc    | 1257 +++++++++++++++++
 ...ion-order-of-user-code-and-extensions.adoc | 1257 +++++++++++++++++
 .../supported-utilities-in-extensions.adoc    | 1257 +++++++++++++++++
 .../extensions/test-instance-factories.adoc   | 1257 +++++++++++++++++
 .../test-instance-post-processing.adoc        | 1257 +++++++++++++++++
 .../test-instance-pre-construct-callback.adoc | 1257 +++++++++++++++++
 .../test-instance-pre-destroy-callback.adoc   | 1257 +++++++++++++++++
 .../extensions/test-lifecycle-callbacks.adoc  | 1257 +++++++++++++++++
 .../extensions/test-result-processing.adoc    | 1257 +++++++++++++++++
 18 files changed, 21369 insertions(+)
 rename documentation/{src/docs/asciidoc/user-guide/extensions.adoc => modules/ROOT/pages/extensions/conditional-test-execution.adoc} (100%)
 create mode 100644 documentation/modules/ROOT/pages/extensions/exception-handling.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/overview.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/registering-extensions.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/test-instance-pre-destroy-callback.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc
 create mode 100644 documentation/modules/ROOT/pages/extensions/test-result-processing.adoc

diff --git a/documentation/src/docs/asciidoc/user-guide/extensions.adoc b/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/extensions.adoc
rename to documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc
diff --git a/documentation/modules/ROOT/pages/extensions/exception-handling.adoc b/documentation/modules/ROOT/pages/extensions/exception-handling.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/exception-handling.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc b/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc b/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/overview.adoc b/documentation/modules/ROOT/pages/extensions/overview.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/overview.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc b/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc b/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc b/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc b/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc b/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-pre-destroy-callback.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-pre-destroy-callback.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-pre-destroy-callback.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc b/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====
diff --git a/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc b/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc
new file mode 100644
index 000000000000..213721b04e2c
--- /dev/null
+++ b/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc
@@ -0,0 +1,1257 @@
+:testDir: ../../../../src/test/java
+:kotlinTestDir: ../../../../src/test/kotlin
+
+[[extensions]]
+== Extension Model
+
+[[extensions-overview]]
+=== Overview
+
+In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
+JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
+`Extension` API. Note, however, that `Extension` itself is just a marker interface.
+
+[[extensions-registration]]
+=== Registering Extensions
+
+Extensions can be registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
+<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
+Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+
+[[extensions-registration-declarative]]
+==== Declarative Extension Registration
+
+Developers can register one or more extensions _declaratively_ by annotating a test
+interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
+annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+register. `@ExtendWith` may also be declared on fields or on parameters in test class
+constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
+`@AfterEach` lifecycle methods.
+
+For example, to register a `WebServerExtension` for a particular test method, you would
+annotate the test method as follows. We assume the `WebServerExtension` starts a local web
+server and injects the server's URL into parameters annotated with `@WebServerUrl`.
+
+[source,java,indent=0]
+----
+@Test
+@ExtendWith(WebServerExtension.class)
+void getProductList(@WebServerUrl String serverUrl) {
+	WebClient webClient = new WebClient();
+	// Use WebClient to connect to web server using serverUrl and verify response
+	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
+}
+----
+
+To register the `WebServerExtension` for all tests in a particular class and its
+subclasses, you would annotate the test class as follows.
+
+[source,java,indent=0]
+----
+@ExtendWith(WebServerExtension.class)
+class MyTests {
+	// ...
+}
+----
+
+Multiple extensions can be registered together like this:
+
+[source,java,indent=0]
+----
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+class MyFirstTests {
+	// ...
+}
+----
+
+As an alternative, multiple extensions can be registered separately like this:
+
+[source,java,indent=0]
+----
+@ExtendWith(DatabaseExtension.class)
+@ExtendWith(WebServerExtension.class)
+class MySecondTests {
+	// ...
+}
+----
+
+[TIP]
+.Extension Registration Order
+====
+Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
+parameter level will be executed in the order in which they are declared in the source
+code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
+be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
+====
+
+If you wish to combine multiple extensions in a reusable way, you can define a custom
+_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
+can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
+
+[source,java,indent=0]
+----
+@Target({ ElementType.TYPE, ElementType.METHOD })
+@Retention(RetentionPolicy.RUNTIME)
+@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
+public @interface DatabaseAndWebServerExtension {
+}
+----
+
+The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
+the method level; however, for certain use cases it makes sense for an extension to be
+registered declaratively at the field or parameter level. Consider a
+`RandomNumberExtension` which generates random numbers that can be injected into a field or
+via a parameter in a constructor, test method, or lifecycle method. If the extension
+provides a `@Random` annotation that is meta-annotated with
+`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
+transparently as in the following `RandomNumberDemo` example.
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/Random.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+----
+
+[[extensions-RandomNumberExtension]]
+The following code listing provides an example of how one might choose to implement such a
+`RandomNumberExtension`. This implementation works for the use cases in
+`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
+example, the random number generation support is limited to integers; it uses
+`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
+important to note which extension APIs are implemented and for what reasons.
+
+Specifically, `RandomNumberExtension` implements the following extension APIs:
+
+- `BeforeAllCallback`: to support static field injection
+- `TestInstancePostProcessor`: to support non-static field injection
+- `ParameterResolver`: to support constructor and method injection
+
+[source,java,indent=0]
+----
+include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+----
+
+[TIP]
+.Extension Registration Order for `@ExtendWith` on Fields
+====
+Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
+to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
+deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
+using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
+Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
+inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
+<<extensions-registration-programmatic-static-fields, Static Fields>> and
+<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+`@RegisterExtension` fields also applies to `@ExtendWith` fields.
+
+[[extensions-registration-programmatic]]
+==== Programmatic Extension Registration
+
+Developers can register extensions _programmatically_ by annotating fields in test classes
+with `{RegisterExtension}`.
+
+When an extension is registered _declaratively_ via
+<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
+can be configured _programmatically_ -- for example, in order to pass arguments to the
+extension's constructor, a static factory method, or a builder API.
+
+[[extensions-registration-programmatic-order]]
+[TIP]
+.Extension Registration Order
+====
+By default, extensions registered programmatically via `@RegisterExtension` or
+declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
+deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
+suite execute extensions in the same order, thereby allowing for repeatable builds.
+However, there are times when extensions need to be registered in an explicit order. To
+achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
+
+Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
+ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
+allows `@Order` annotated extension fields to be explicitly ordered before or after
+non-annotated extension fields. Extensions with an explicit order value less than the
+default order value will be registered before non-annotated extensions. Similarly,
+extensions with an explicit order value greater than the default order value will be
+registered after non-annotated extensions. For example, assigning an extension an explicit
+order value that is greater than the default order value allows _before_ callback
+extensions to be registered last and _after_ callback extensions to be registered first,
+relative to other programmatically registered extensions.
+====
+
+[TIP]
+.Extension Inheritance
+====
+Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
+will be inherited.
+
+See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+====
+
+NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
+either `static` or non-static.
+
+[[extensions-registration-programmatic-static-fields]]
+===== Static Fields
+
+If a `@RegisterExtension` field is `static`, the extension will be registered after
+extensions that are registered at the class level via `@ExtendWith`. Such _static
+extensions_ are not limited in which extension APIs they can implement. Extensions
+registered via static fields may therefore implement class-level and instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
+`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
+extension APIs such as `BeforeEachCallback`, etc.
+
+In the following example, the `server` field in the test class is initialized
+programmatically by using a builder pattern supported by the `WebServerExtension`. The
+configured `WebServerExtension` will be automatically registered as an extension at the
+class level -- for example, in order to start the server before all tests in the class
+and then stop the server after all tests in the class have completed. In addition, static
+lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
+`@AfterEach`, and `@Test` methods can access the instance of the extension via the
+`server` field if necessary.
+
+[source,java,indent=0]
+.Registering an extension via a static field in Java
+----
+include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-static-fields-kotlin]]
+====== Static Fields in Kotlin
+
+The Kotlin programming language does not have the concept of a `static` field. However,
+the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
+annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
+you can use the `@JvmField` annotation instead.
+
+The following example is a version of the `WebServerDemo` from the previous section that
+has been ported to Kotlin.
+
+[source,kotlin,indent=0]
+.Registering an extension via a static field in Kotlin
+----
+include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+----
+
+[[extensions-registration-programmatic-instance-fields]]
+===== Instance Fields
+
+If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
+will be registered after the test class has been instantiated and after each registered
+`TestInstancePostProcessor` has been given a chance to post-process the test instance
+(potentially injecting the instance of the extension to be used into the annotated
+field). Thus, if such an _instance extension_ implements class-level or instance-level
+extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
+`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
+registered _before_ extensions that are registered at the method level via `@ExtendWith`.
+
+In the following example, the `docs` field in the test class is initialized
+programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
+to the static `forPath()` factory method in the `DocumentationExtension`. The configured
+`DocumentationExtension` will be automatically registered as an extension at the method
+level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
+instance of the extension via the `docs` field if necessary.
+
+[source,java,indent=0]
+.An extension registered via an instance field
+----
+include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+----
+
+[[extensions-registration-automatic]]
+==== Automatic Extension Registration
+
+In addition to <<extensions-registration-declarative,declarative extension registration>>
+and <<extensions-registration-programmatic,programmatic extension registration>> support
+using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
+`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
+automatically registered based on what is available in the classpath.
+
+Specifically, a custom extension can be registered by supplying its fully qualified class
+name in a file named `org.junit.jupiter.api.extension.Extension` within the
+`/META-INF/services` folder in its enclosing JAR file.
+
+[[extensions-registration-automatic-enabling]]
+===== Enabling Automatic Extension Detection
+
+Auto-detection is an advanced feature and is therefore not enabled by default. To enable
+it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
+`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
+the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to enable auto-detection of extensions, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.extensions.autodetection.enabled=true`
+
+When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
+will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
+support for `TestInfo`, `TestReporter`, etc.).
+
+[[extensions-registration-automatic-filtering]]
+===== Filtering Auto-detected Extensions
+
+The list of auto-detected extensions can be filtered using include and exclude patterns
+via the following <<running-tests-config-params, configuration parameters>>:
+
+`junit.jupiter.extensions.autodetection.include=<patterns>`::
+    Comma-separated list of _include_ patterns for auto-detected extensions.
+`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
+    Comma-separated list of _exclude_ patterns for auto-detected extensions.
+
+Include patterns are applied _before_ exclude patterns. If both include and exclude
+patterns are provided, only extensions that match at least one include pattern and do not
+match any exclude pattern will be auto-detected.
+
+See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+
+[[extensions-registration-inheritance]]
+==== Extension Inheritance
+
+Registered extensions are inherited within test class hierarchies with top-down semantics.
+Similarly, extensions registered at the class-level are inherited at the method-level.
+This applies to all extensions, independent of how they are registered (declaratively or
+programmatically).
+
+This means that extensions registered declaratively via `@ExtendWith` on a superclass will
+be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
+
+Similarly, extensions registered programmatically via `@RegisterExtension` or
+`@ExtendWith` on fields in a superclass will be registered before extensions registered
+programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
+`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
+Extension Registration Order>> for details).
+
+NOTE: A specific extension implementation can only be registered once for a given
+extension context and its parent contexts. Consequently, any attempt to register a
+duplicate extension implementation will be ignored.
+
+[[extensions-conditions]]
+=== Conditional Test Execution
+
+`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
+execution_.
+
+An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
+determine if all the tests it contains should be executed based on the supplied
+`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
+determine if a given test method should be executed based on the supplied
+`ExtensionContext`.
+
+When multiple `ExecutionCondition` extensions are registered, a container or test is
+disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
+that a condition is evaluated because another extension might have already caused a
+container or test to be disabled. In other words, the evaluation works like the
+short-circuiting boolean OR operator.
+
+See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
+
+[[extensions-conditions-deactivation]]
+==== Deactivating Conditions
+
+Sometimes it can be useful to run a test suite _without_ certain conditions being active.
+For example, you may wish to run tests even if they are annotated with `@Disabled` in
+order to see if they are still _broken_. To do this, provide a pattern for the
+`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
+conditions should be deactivated (i.e., not evaluated) for the current test run. The
+pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
+`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
+configuration file (see <<running-tests-config-params>> for details).
+
+For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
+following system property.
+
+`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
+
+[[extensions-conditions-deactivation-patterns]]
+===== Pattern Matching Syntax
+
+Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+
+[[extensions-test-instance-pre-construct-callback]]
+=== Test Instance Pre-construct Callback
+
+`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
+_prior_ to test instances being constructed (by a constructor call or via
+`{TestInstanceFactory}`).
+
+This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
+in combination with other extensions to prepare constructor parameters or keeping track of test
+instances and their lifecycle.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-factories]]
+=== Test Instance Factories
+
+`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
+instances.
+
+Common use cases include acquiring the test instance from a dependency injection
+framework or invoking a static factory method to create the test class instance.
+
+If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
+constructor for the test class to instantiate it, potentially resolving constructor
+arguments via registered `ParameterResolver` extensions.
+
+Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
+top-level test classes, or `@Nested` test classes.
+
+[WARNING]
+====
+Registering multiple extensions that implement `TestInstanceFactory` for any single class
+will result in an exception being thrown for all tests in that class, in any subclass,
+and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
+or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
+the user's responsibility to ensure that only a single `TestInstanceFactory` is
+registered for any specific test class.
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-post-processing]]
+=== Test Instance Post-processing
+
+`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
+process_ test instances.
+
+Common use cases include injecting dependencies into the test instance, invoking custom
+initialization methods on the test instance, etc.
+
+For a concrete example, consult the source code for the `{MockitoExtension}` and the
+`{SpringExtension}`.
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation or if
+you want to <<extensions-keeping-state, keep state>> on the test method level.
+====
+
+[[extensions-test-instance-pre-destroy-callback]]
+=== Test Instance Pre-destroy Callback
+
+`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
+test instances _after_ they have been used in tests and _before_ they are destroyed.
+
+Common use cases include cleaning dependencies that have been injected into the
+test instance, invoking custom de-initialization methods on the test instance, etc.
+
+[[extensions-parameter-resolution]]
+=== Parameter Resolution
+
+`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
+runtime.
+
+If a _test class_ constructor, _test method_, or _lifecycle method_ (see
+<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
+`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
+combination thereof.
+
+If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
+solely on the type of the parameter, you may find it convenient to extend the
+`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
+
+For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
+`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
+
+[WARNING]
+====
+Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
+looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
+API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
+test class).
+
+The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
+includes the following convenience methods for correctly looking up annotations on
+parameters. Extension authors are strongly encouraged to use these methods instead of
+those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
+
+* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
+* `Optional<A> findAnnotation(Class<A> annotationType)`
+* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
+====
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to support injecting test specific data into constructor parameters of the
+test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
+resolving constructor parameters, unless the
+<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+====
+
+[TIP]
+.Parameter resolution for methods called from extensions
+====
+Other extensions can also leverage registered `ParameterResolvers` for method and
+constructor invocations, using the `{ExecutableInvoker}` available via the
+`getExecutableInvoker()` method in the `ExtensionContext`.
+====
+
+[[extensions-parameter-resolution-conflicts]]
+==== Parameter Conflicts
+
+If multiple implementations of `ParameterResolver` that support the same type are
+registered for a test, a `ParameterResolutionException` will be thrown, with a
+message to indicate that competing resolvers have been discovered. See the following
+example:
+
+[source,java,indent=0]
+.Conflicting parameter resolution due to multiple resolvers claiming support for integers
+----
+include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations are applied to different test
+methods as shown in the following example, no conflict occurs.
+
+[source,java,indent=0]
+.Fine-grained registration to avoid conflict
+----
+include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+----
+
+If the conflicting `ParameterResolver` implementations need to be applied to the same test
+method, you can implement a custom type or custom annotation as illustrated by
+`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
+
+[source,java,indent=0]
+.Custom type to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+----
+
+A custom annotation makes the duplicate type distinguishable from its counterpart:
+
+[source,java,indent=0]
+.Custom annotation to resolve duplicate types
+----
+include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+----
+
+JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
+attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
+tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+as Spring may also define parameter resolvers. Apply one of the techniques in this section
+to resolve any conflicts.
+
+Parameterized tests are another potential source of conflict. Ensure that tests annotated
+with `@ParameterizedTest` are not also annotated with `@Test` and see
+<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+
+[[extensions-test-result-processing]]
+=== Test Result Processing
+
+`{TestWatcher}` defines the API for extensions that wish to process the results of _test
+method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
+information for the following events.
+
+* `testDisabled`: invoked after a disabled _test method_ has been skipped
+* `testSuccessful`: invoked after a _test method_ has completed successfully
+* `testAborted`: invoked after a _test method_ has been aborted
+* `testFailed`: invoked after a _test method_ has failed
+
+NOTE: In contrast to the definition of "test method" presented in
+<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
+
+Extensions implementing this interface can be registered at the class level, instance
+level, or method level. When registered at the class level, a `TestWatcher` will be
+invoked for any contained _test method_ including those in `@Nested` classes. When
+registered at the method level, a `TestWatcher` will only be invoked for the _test method_
+for which it was registered.
+
+[WARNING]
+====
+If a `TestWatcher` is registered via a non-static (instance) field – for example, using
+`@RegisterExtension` – and the test class is configured with
+`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
+`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
+example, `@RepeatedTest` or `@ParameterizedTest`).
+
+To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
+therefore recommended that the `TestWatcher` be registered at the class level with
+`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
+====
+
+If there is a failure at the class level — for example, an exception thrown by a
+`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
+disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
+reported.
+
+In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
+influence the execution of tests. Consequently, any exception thrown by a method in the
+`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
+or fail test execution.
+
+[WARNING]
+====
+Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
+provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
+invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+work with such resources.
+====
+
+[[extensions-lifecycle-callbacks]]
+=== Test Lifecycle Callbacks
+
+The following interfaces define the APIs for extending tests at various points in the
+test execution lifecycle. Consult the following sections for examples and the Javadoc for
+each of these interfaces in the `{extension-api-package}` package for further details.
+
+* `{BeforeAllCallback}`
+** `{BeforeClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+*** `{BeforeEachCallback}`
+**** `{BeforeTestExecutionCallback}`
+**** `{AfterTestExecutionCallback}`
+*** `{AfterEachCallback}`
+** `{AfterClassTemplateInvocationCallback}` (only applicable for
+   <<writing-tests-class-templates, class templates>>)
+* `{AfterAllCallback}`
+
+.Implementing Multiple Extension APIs
+NOTE: Extension developers may choose to implement any number of these interfaces
+within a single extension. Consult the source code of the `{SpringExtension}` for a
+concrete example.
+
+[[extensions-lifecycle-callbacks-before-after-execution]]
+==== Before and After Test Execution Callbacks
+
+`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
+`Extensions` that wish to add behavior that will be executed _immediately before_ and
+_immediately after_ a test method is executed, respectively. As such, these callbacks are
+well suited for timing, tracing, and similar use cases. If you need to implement
+callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
+`BeforeEachCallback` and `AfterEachCallback` instead.
+
+The following example shows how to use these callbacks to calculate and log the execution
+time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
+and `AfterTestExecutionCallback` in order to time and log the test execution.
+
+[[extensions-lifecycle-callbacks-timing-extension]]
+[source,java,indent=0]
+.An extension that times and logs the execution of test methods
+----
+include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+----
+
+Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
+its tests will have this timing applied when they execute.
+
+[source,java,indent=0]
+.A test class that uses the example TimingExtension
+----
+include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+----
+
+The following is an example of the logging produced when `TimingExtensionTests` is run.
+
+....
+INFO: Method [sleep20ms] took 24 ms.
+INFO: Method [sleep50ms] took 53 ms.
+....
+
+[[extensions-exception-handling]]
+=== Exception Handling
+
+Exceptions thrown during the test execution may be intercepted and handled accordingly
+before propagating further, so that certain actions like error logging or resource releasing
+may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
+wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
+and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
+`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
+
+The following example shows an extension which will swallow all instances of `IOException`
+but rethrow any other type of exception.
+
+[source,java,indent=0]
+.An exception handling extension that filters IOExceptions in test execution
+----
+include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+----
+
+Another example shows how to record the state of an application under test exactly at
+the point of unexpected exception being thrown during setup and cleanup. Note that unlike
+relying on lifecycle callbacks, which may or may not be executed depending on the test
+status, this solution guarantees execution immediately after failing `@BeforeAll`,
+`@BeforeEach`, `@AfterEach` or `@AfterAll`.
+
+[source,java,indent=0]
+.An exception handling extension that records application state on error
+----
+include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+----
+
+Multiple execution exception handlers may be invoked for the same lifecycle method in
+order of declaration. If one of the handlers swallows the handled exception, subsequent
+ones will not be executed, and no failure will be propagated to JUnit engine, as if the
+exception was never thrown. Handlers may also choose to rethrow the exception or throw
+a different one, potentially wrapping the original.
+
+Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
+exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
+while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
+test methods.
+
+[source,java,indent=0]
+.Registering multiple exception handling extensions
+----
+include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+----
+
+[[extensions-preinterrupt-callback]]
+=== Pre-Interrupt Callback
+
+`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
+timeouts before the `Thread.interrupt()` is called.
+
+Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+
+
+[[extensions-intercepting-invocations]]
+=== Intercepting Invocations
+
+`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
+test code.
+
+The following example shows an extension that executes all test methods in Swing's Event
+Dispatch Thread.
+
+[source,java,indent=0]
+.An extension that executes tests in a user-defined thread
+----
+include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+----
+
+[NOTE]
+.Accessing the test-scoped `ExtensionContext`
+====
+You may override the `getTestInstantiationExtensionContextScope(...)` method to return
+`TEST_METHOD` to make test-specific data available to your extension implementation of
+`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+on the test method level.
+====
+
+[[extensions-class-templates]]
+=== Providing Invocation Contexts for Class Templates
+
+A `{ClassTemplate}` class can only be executed when at least one
+`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
+responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
+Each context may specify a custom display name and a list of additional extensions that
+will only be used for the next invocation of the `{ClassTemplate}`.
+
+The following example shows how to write a class template as well as how to register
+and implement a `{ClassTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A class template with accompanying extension
+----
+include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the class template will be invoked twice, meaning all test methods in
+the class template will be executed twice. The display names of the invocations will be
+`apple` and `banana` as specified by the invocation context. Each invocation registers a
+custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
+output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ ClassTemplateDemo ✔
+   ├─ apple ✔
+   │  ├─ notNull() ✔
+   │  └─ wellKnown() ✔
+   └─ banana ✔
+      ├─ notNull() ✔
+      └─ wellKnown() ✔
+....
+
+The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of _all_ test
+methods in a test class albeit in different contexts — for example, with different
+parameters, by preparing the test class instance differently, or multiple times without
+modifying the context.
+Please refer to the implementations of
+<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+point to provide its functionality.
+
+[[extensions-test-templates]]
+=== Providing Invocation Contexts for Test Templates
+
+A `{TestTemplate}` method can only be executed when at least one
+`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
+for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
+specify a custom display name and a list of additional extensions that will only be used
+for the next invocation of the `{TestTemplate}` method.
+
+The following example shows how to write a test template as well as how to register and
+implement a `{TestTemplateInvocationContextProvider}`.
+
+[source,java,indent=0]
+.A test template with accompanying extension
+----
+include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+----
+
+In this example, the test template will be invoked twice. The display names of the
+invocations will be `apple` and `banana` as specified by the invocation context. Each
+invocation registers a custom `{ParameterResolver}` which is used to resolve the method
+parameter. The output when using the `ConsoleLauncher` is as follows.
+
+....
+└─ testTemplate(String) ✔
+   ├─ apple ✔
+   └─ banana ✔
+....
+
+The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
+implementing different kinds of tests that rely on repetitive invocation of a test-like
+method albeit in different contexts — for example, with different parameters, by preparing
+the test class instance differently, or multiple times without modifying the context.
+Please refer to the implementations of <<writing-tests-repeated-tests>> or
+<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+to provide their functionality.
+
+[[extensions-keeping-state]]
+=== Keeping State in Extensions
+
+Usually, an extension is instantiated only once. So the question becomes relevant: How do
+you keep the state from one invocation of an extension to the next? The
+`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
+Extensions may put values into a store for later retrieval.
+
+TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+example of using the `Store` with a method-level scope.
+
+.The `ExtensionContext` and `Store` hierarchy
+image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
+
+As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
+value, if no value is stored in the current `ExtensionContext` for the supplied key, the
+stores of the context's ancestors will be queried for a value with the same key in the
+`Namespace` used to create this store. The root `ExtensionContext` represents the engine
+level so its `Store` may be used to store or cache values that are used by multiple test
+classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
+that and access the stores on the level of the current `{LauncherExecutionRequest}` or
+`{LauncherSession}` which can be used to share data across test engines or inject data
+from a registered
+<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+respectively. Please consult the Javadoc of `{ExtensionContext}`,
+`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
+
+[[extensions-keeping-state-autocloseable-support]]
+[NOTE]
+.Resource management via `_AutoCloseable_`
+====
+An extension context store is bound to its extension context lifecycle. When an extension
+context lifecycle ends it closes its associated store.
+
+All stored values that are instances of `AutoCloseable` are notified by an invocation of
+their `close()` method in the inverse order they were added in (unless the
+`junit.jupiter.extensions.store.close.autocloseable.enabled`
+<<running-tests-config-params, configuration parameter>> is set to `false`).
+
+Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
+available for backward compatibility.
+====
+
+An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
+resource.
+
+[source,java,indent=0]
+.`_HttpServer_` resource implementing `_AutoCloseable_`
+----
+include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+----
+
+This resource can then be stored in the desired `ExtensionContext`. It may be stored at
+class or method level, if desired, but this may add unnecessary overhead for this type of
+resource. For this example it might be prudent to store it at root level and instantiate
+it lazily to ensure it's only created once per test run and reused across different test
+classes and methods.
+
+[source,java,indent=0]
+.Lazily storing in root context with `_Store.computeIfAbsent_`
+----
+include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.A test case using the `_HttpServerExtension_`
+----
+include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+----
+
+[[extensions-keeping-state-autocloseable-migration]]
+[TIP]
+.Migration Note for Resource Cleanup
+====
+The framework automatically closes resources stored in the `ExtensionContext.Store` that
+implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
+`Store.CloseableResource` were automatically closed.
+
+If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
+earlier versions and your extension stores resources that need to be cleaned up, you
+should implement both interfaces:
+
+[source,java,indent=0]
+----
+public class MyResource implements Store.CloseableResource, AutoCloseable {
+    @Override
+    public void close() throws Exception {
+        // Resource cleanup code
+    }
+}
+----
+
+This ensures that your resource will be properly closed regardless of which JUnit Jupiter
+version is being used.
+====
+
+[[extensions-supported-utilities]]
+=== Supported Utilities in Extensions
+
+The `junit-platform-commons` artifact provides _maintained_ utilities for working with
+annotations, classes, reflection, classpath scanning, and conversion tasks. These
+utilities can be found in the `{junit-platform-support-package}` and its subpackages.
+`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
+order to align with the behavior of the JUnit Platform and JUnit Jupiter.
+
+[[extensions-supported-utilities-annotations]]
+==== Annotation Support
+
+`AnnotationSupport` provides static utility methods that operate on annotated elements
+(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
+These include methods to check whether an element is annotated or meta-annotated with a
+particular annotation, to search for specific annotations, and to find annotated methods
+and fields in a class or interface. Some of these methods search on implemented
+interfaces and within class hierarchies to find annotations. Consult the Javadoc for
+`{AnnotationSupport}` for further details.
+
+NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
+use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-classes]]
+==== Class Support
+
+`ClassSupport` provides static utility methods for working with classes (i.e., instances
+of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
+
+[[extensions-supported-utilities-reflection]]
+==== Reflection Support
+
+`ReflectionSupport` provides static utility methods that augment the standard JDK
+reflection and class-loading mechanisms. These include methods to scan the classpath in
+search of classes matching specified predicates, to load and create new instances of a
+class, and to find and invoke methods. Some of these methods traverse class hierarchies
+to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
+details.
+
+NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+
+[[extensions-supported-utilities-modifier]]
+==== Modifier Support
+
+`ModifierSupport` provides static utility methods for working with member and class
+modifiers -- for example, to determine if a member is declared as `public`, `private`,
+`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
+details.
+
+[[extensions-supported-utilities-conversion]]
+==== Conversion Support
+
+`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
+provides support for converting from strings to primitive types and their corresponding
+wrapper types, date and time types from the `java.time package`, and some additional
+common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
+`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
+
+[[extensions-supported-utilities-search-semantics]]
+==== Field and Method Search Semantics
+
+Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
+traverse type hierarchies to locate matching fields and methods – for example,
+`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
+
+The field and method search algorithms adhere to standard Java semantics regarding whether
+a given field or method is visible or overridden according to the rules of the Java
+language.
+
+[[extensions-execution-order]]
+=== Relative Execution Order of User Code and Extensions
+
+When executing a test class that contains one or more test methods, a number of extension
+callbacks are called in addition to the user-supplied test and lifecycle methods.
+
+NOTE: See also: <<writing-tests-test-execution-order>>
+
+[[extensions-execution-order-overview]]
+==== User and Extension Code
+
+The following diagram illustrates the relative order of user-supplied code and extension
+code. User-supplied test and lifecycle methods are shown in orange, with callback code
+implemented by extensions shown in blue. The grey box denotes the execution of a single
+test method and will be repeated for every test method in the test class.
+
+[[extensions-execution-order-diagram]]
+.User code and extension code
+image::extensions_lifecycle.png[]
+
+The following table further explains the sixteen steps in the
+<<extensions-execution-order-diagram>> diagram.
+
+. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
+extension code executed before all tests of the container are executed
+. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
+user code executed before all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeAll` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
+extension code executed before each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
+extension code executed before each test is executed
+. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
+user code executed before each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleBeforeEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@BeforeEach` methods
+. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
+extension code executed immediately before a test is executed
+. *annotation* `*org.junit.jupiter.api.Test*` +
+user code of the actual test method
+. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
+extension code for handling exceptions thrown during a test
+. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
+extension code executed immediately after test execution and its corresponding exception handlers
+. *annotation* `*org.junit.jupiter.api.AfterEach*` +
+user code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterEachMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterEach` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
+extension code executed after each test is executed
+. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
+extension code executed after each class template invocation is executed (only applicable
+if the test class is a <<writing-tests-class-templates, class template>>)
+. *annotation* `*org.junit.jupiter.api.AfterAll*` +
+user code executed after all tests of the container are executed
+. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
+#handleAfterAllMethodExecutionException*` +
+extension code for handling exceptions thrown from `@AfterAll` methods
+. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
+extension code executed after all tests of the container are executed
+
+In the simplest case only the actual test method will be executed (step 9); all other
+steps are optional depending on the presence of user code or extension support for the
+corresponding lifecycle callback. For further details on the various lifecycle callbacks
+please consult the respective Javadoc for each annotation and extension.
+
+All invocations of user code methods in the above table can additionally be intercepted
+by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+
+[[extensions-execution-order-wrapping-behavior]]
+==== Wrapping Behavior of Callbacks
+
+JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
+that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
+`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
+`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
+`AfterTestExecutionCallback`.
+
+That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
+registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
+guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
+Similarly, given the two same two extensions registered in the same order, any "after"
+callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
+callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
+`Extension2`.
+
+JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
+for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+
+* `@BeforeAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
+  **before** `@BeforeAll` methods in subclasses.
+** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
+   **before** `@BeforeAll` methods in the class that implements the interface.
+* `@AfterAll` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
+  **after** `@AfterAll` methods in subclasses.
+** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
+   are not _overridden_, and `@AfterAll` methods from an interface will be executed
+   **after** `@AfterAll` methods in the class that implements the interface.
+* `@BeforeEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
+  **before** `@BeforeEach` methods in subclasses.
+** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
+   **before** `@BeforeEach` methods in the class that implements the interface.
+* `@AfterEach` methods are inherited from superclasses as long as they are not
+  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
+  **after** `@AfterEach` methods in subclasses.
+** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
+   long as they are not _overridden_, and `@AfterEach` default methods will be executed
+   **after** `@AfterEach` methods in the class that implements the interface.
+
+The following examples demonstrate this behavior. Please note that the examples do not
+actually do anything realistic. Instead, they mimic common scenarios for testing
+interactions with the database. All methods imported statically from the `Logger` class
+log contextual information in order to help us better understand the execution order of
+user-supplied callback methods and callback methods in extensions.
+
+[source,java,indent=0]
+.Extension1
+----
+include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.Extension2
+----
+include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.AbstractDatabaseTests
+----
+include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+----
+
+[source,java,indent=0]
+.DatabaseTestsDemo
+----
+include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+----
+
+When the `DatabaseTestsDemo` test class is executed, the following is logged.
+
+----
+@BeforeAll AbstractDatabaseTests.createDatabase()
+@BeforeAll DatabaseTestsDemo.beforeAll()
+  Extension1.beforeEach()
+  Extension2.beforeEach()
+    @BeforeEach AbstractDatabaseTests.connectToDatabase()
+    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
+      @Test DatabaseTestsDemo.testDatabaseFunctionality()
+    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
+    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
+  Extension2.afterEach()
+  Extension1.afterEach()
+@BeforeAll DatabaseTestsDemo.afterAll()
+@AfterAll AbstractDatabaseTests.destroyDatabase()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
+
+JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
+that are declared within a _single_ test class or test interface. It may at times appear
+that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
+precisely true. The ordering is analogous to the ordering for `@Test` methods within a
+single test class.
+
+[NOTE]
+====
+Lifecycle methods that are declared within a _single_ test class or test interface will be
+ordered using an algorithm that is deterministic but intentionally non-obvious. This
+ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
+thereby allowing for repeatable builds.
+====
+
+In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
+methods declared within a single test class or test interface.
+
+The following example demonstrates this behavior. Specifically, the lifecycle method
+configuration is _broken_ due to the order in which the locally declared lifecycle methods
+are executed.
+
+* Test data is inserted _before_ the database connection has been opened, which results in
+  a failure to connect to the database.
+* The database connection is closed _before_ deleting the test data, which results in a
+  failure to connect to the database.
+
+[source,java,indent=0]
+.BrokenLifecycleMethodConfigDemo
+----
+include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+----
+
+When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
+
+----
+Extension1.beforeEach()
+Extension2.beforeEach()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
+  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
+    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
+  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
+  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
+Extension2.afterEach()
+Extension1.afterEach()
+----
+
+The following sequence diagram helps to shed further light on what actually goes on within
+the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
+
+////
+PNG generated using ZenUML: https://app.zenuml.com
+
+See corresponding *.txt file in images folder for the source.
+////
+image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
+
+[TIP]
+====
+Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
+most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+class or test interface unless there are no dependencies between such lifecycle methods.
+====

From 27057c1161d95ccb9881e48fca1b55812f49018a Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:13 +0100
Subject: [PATCH 28/57] Migrate extensions.adoc sections to Antora

---
 .../conditional-test-execution.adoc           | 1215 ----------------
 .../pages/extensions/exception-handling.adoc  | 1209 ----------------
 .../extensions/intercepting-invocations.adoc  | 1233 ----------------
 .../keeping-state-in-extensions.adoc          | 1161 ---------------
 .../ROOT/pages/extensions/overview.adoc       | 1250 -----------------
 .../extensions/parameter-resolution.adoc      | 1151 ---------------
 .../extensions/pre-interrupt-callback.adoc    | 1248 ----------------
 ...vocation-contexts-for-class-templates.adoc | 1214 ----------------
 ...nvocation-contexts-for-test-templates.adoc | 1220 ----------------
 .../extensions/registering-extensions.adoc    |  923 ------------
 ...ion-order-of-user-code-and-extensions.adoc | 1018 --------------
 .../supported-utilities-in-extensions.adoc    | 1186 ----------------
 .../extensions/test-instance-factories.adoc   | 1223 ----------------
 .../test-instance-post-processing.adoc        | 1237 ----------------
 .../test-instance-pre-construct-callback.adoc | 1238 ----------------
 .../test-instance-pre-destroy-callback.adoc   | 1248 ----------------
 .../extensions/test-lifecycle-callbacks.adoc  | 1197 ----------------
 .../extensions/test-result-processing.adoc    | 1204 ----------------
 18 files changed, 21375 deletions(-)

diff --git a/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc b/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc
index 213721b04e2c..5dfa63cccd3c 100644
--- a/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc
+++ b/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc
@@ -1,350 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
 [[extensions-conditions]]
 === Conditional Test Execution
 
@@ -387,871 +40,3 @@ following system property.
 
 Refer to <<running-tests-config-params-deactivation-pattern>> for details.
 
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/exception-handling.adoc b/documentation/modules/ROOT/pages/extensions/exception-handling.adoc
index 213721b04e2c..a6629a46d72b 100644
--- a/documentation/modules/ROOT/pages/extensions/exception-handling.adoc
+++ b/documentation/modules/ROOT/pages/extensions/exception-handling.adoc
@@ -1,693 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
 [[extensions-exception-handling]]
 === Exception Handling
 
@@ -736,522 +46,3 @@ test methods.
 include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
 ----
 
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc b/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc
index 213721b04e2c..590543f1a86d 100644
--- a/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc
+++ b/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc
@@ -1,750 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
 [[extensions-intercepting-invocations]]
 === Intercepting Invocations
 
@@ -769,489 +22,3 @@ You may override the `getTestInstantiationExtensionContextScope(...)` method to
 on the test method level.
 ====
 
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc b/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc
index 213721b04e2c..51cc8a553c92 100644
--- a/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc
+++ b/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc
@@ -1,854 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
 [[extensions-keeping-state]]
 === Keeping State in Extensions
 
@@ -945,313 +94,3 @@ This ensures that your resource will be properly closed regardless of which JUni
 version is being used.
 ====
 
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/overview.adoc b/documentation/modules/ROOT/pages/extensions/overview.adoc
index 213721b04e2c..8d2f8e4112b5 100644
--- a/documentation/modules/ROOT/pages/extensions/overview.adoc
+++ b/documentation/modules/ROOT/pages/extensions/overview.adoc
@@ -1,9 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
 [[extensions-overview]]
 === Overview
 
@@ -11,1247 +5,3 @@ In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension po
 JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
 `Extension` API. Note, however, that `Extension` itself is just a marker interface.
 
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc b/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc
index 213721b04e2c..6e92e3ab863d 100644
--- a/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc
+++ b/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc
@@ -1,474 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
 [[extensions-parameter-resolution]]
 === Parameter Resolution
 
@@ -575,683 +104,3 @@ Parameterized tests are another potential source of conflict. Ensure that tests
 with `@ParameterizedTest` are not also annotated with `@Test` and see
 <<writing-tests-parameterized-tests-consuming-arguments>> for more details.
 
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc b/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc
index 213721b04e2c..5d34a551de65 100644
--- a/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc
+++ b/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc
@@ -1,741 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
 [[extensions-preinterrupt-callback]]
 === Pre-Interrupt Callback
 
@@ -745,513 +7,3 @@ timeouts before the `Thread.interrupt()` is called.
 Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
 
 
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc
index 213721b04e2c..7b0ac9babcab 100644
--- a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc
+++ b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc
@@ -1,774 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
 [[extensions-class-templates]]
 === Providing Invocation Contexts for Class Templates
 
@@ -812,446 +41,3 @@ Please refer to the implementations of
 <<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
 point to provide its functionality.
 
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc
index 213721b04e2c..4a4d22c5ca6c 100644
--- a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc
+++ b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc
@@ -1,817 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
 [[extensions-test-templates]]
 === Providing Invocation Contexts for Test Templates
 
@@ -849,409 +35,3 @@ Please refer to the implementations of <<writing-tests-repeated-tests>> or
 <<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
 to provide their functionality.
 
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc b/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc
index 213721b04e2c..3dd520298948 100644
--- a/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc
+++ b/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc
@@ -1,16 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
 [[extensions-registration]]
 === Registering Extensions
 
@@ -345,913 +332,3 @@ NOTE: A specific extension implementation can only be registered once for a give
 extension context and its parent contexts. Consequently, any attempt to register a
 duplicate extension implementation will be ignored.
 
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc b/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc
index 213721b04e2c..8e5da6d38612 100644
--- a/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc
+++ b/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc
@@ -1,1021 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
 [[extensions-execution-order]]
 === Relative Execution Order of User Code and Extensions
 
diff --git a/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc b/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc
index 213721b04e2c..0bd27a99d5a2 100644
--- a/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc
+++ b/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc
@@ -1,950 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
 [[extensions-supported-utilities]]
 === Supported Utilities in Extensions
 
@@ -1016,242 +69,3 @@ The field and method search algorithms adhere to standard Java semantics regardi
 a given field or method is visible or overridden according to the rules of the Java
 language.
 
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc
index 213721b04e2c..ff042496c539 100644
--- a/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc
@@ -1,411 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
 [[extensions-test-instance-factories]]
 === Test Instance Factories
 
@@ -440,818 +32,3 @@ You may override the `getTestInstantiationExtensionContextScope(...)` method to
 you want to <<extensions-keeping-state, keep state>> on the test method level.
 ====
 
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc
index 213721b04e2c..84dbc3bca5f3 100644
--- a/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc
@@ -1,445 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
 [[extensions-test-instance-post-processing]]
 === Test Instance Post-processing
 
@@ -460,798 +18,3 @@ You may override the `getTestInstantiationExtensionContextScope(...)` method to
 you want to <<extensions-keeping-state, keep state>> on the test method level.
 ====
 
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc
index 213721b04e2c..65a185ef79aa 100644
--- a/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc
@@ -1,392 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
 [[extensions-test-instance-pre-construct-callback]]
 === Test Instance Pre-construct Callback
 
@@ -406,852 +17,3 @@ You may override the `getTestInstantiationExtensionContextScope(...)` method to
 you want to <<extensions-keeping-state, keep state>> on the test method level.
 ====
 
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-pre-destroy-callback.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-pre-destroy-callback.adoc
index 213721b04e2c..acda444fb67a 100644
--- a/documentation/modules/ROOT/pages/extensions/test-instance-pre-destroy-callback.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-pre-destroy-callback.adoc
@@ -1,465 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
 [[extensions-test-instance-pre-destroy-callback]]
 === Test Instance Pre-destroy Callback
 
@@ -469,789 +7,3 @@ test instances _after_ they have been used in tests and _before_ they are destro
 Common use cases include cleaning dependencies that have been injected into the
 test instance, invoking custom de-initialization methods on the test instance, etc.
 
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc b/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc
index 213721b04e2c..d34b10954a51 100644
--- a/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc
@@ -1,633 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
-[[extensions-test-result-processing]]
-=== Test Result Processing
-
-`{TestWatcher}` defines the API for extensions that wish to process the results of _test
-method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
-information for the following events.
-
-* `testDisabled`: invoked after a disabled _test method_ has been skipped
-* `testSuccessful`: invoked after a _test method_ has completed successfully
-* `testAborted`: invoked after a _test method_ has been aborted
-* `testFailed`: invoked after a _test method_ has failed
-
-NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
-or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
-
-Extensions implementing this interface can be registered at the class level, instance
-level, or method level. When registered at the class level, a `TestWatcher` will be
-invoked for any contained _test method_ including those in `@Nested` classes. When
-registered at the method level, a `TestWatcher` will only be invoked for the _test method_
-for which it was registered.
-
-[WARNING]
-====
-If a `TestWatcher` is registered via a non-static (instance) field – for example, using
-`@RegisterExtension` – and the test class is configured with
-`@TestInstance(Lifecycle.PER_METHOD)` semantics (which is the default lifecycle mode), the
-`TestWatcher` will **not** be invoked with events for `@TestTemplate` methods (for
-example, `@RepeatedTest` or `@ParameterizedTest`).
-
-To ensure that a `TestWatcher` is invoked for all _test methods_ in a given class, it is
-therefore recommended that the `TestWatcher` be registered at the class level with
-`@ExtendWith` or via a `static` field with `@RegisterExtension` or `@ExtendWith`.
-====
-
-If there is a failure at the class level — for example, an exception thrown by a
-`@BeforeAll` method — no test results will be reported. Similarly, if the test class is
-disabled via an `ExecutionCondition` — for example, `@Disabled` — no test results will be
-reported.
-
-In contrast to other Extension APIs, a `TestWatcher` is not permitted to adversely
-influence the execution of tests. Consequently, any exception thrown by a method in the
-`TestWatcher` API will be logged at `WARNING` level and will not be allowed to propagate
-or fail test execution.
-
-[WARNING]
-====
-Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
-provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
-work with such resources.
-====
-
 [[extensions-lifecycle-callbacks]]
 === Test Lifecycle Callbacks
 
@@ -688,570 +58,3 @@ INFO: Method [sleep20ms] took 24 ms.
 INFO: Method [sleep50ms] took 53 ms.
 ....
 
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====
diff --git a/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc b/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc
index 213721b04e2c..24e3ddf16680 100644
--- a/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc
@@ -1,580 +1,3 @@
-:testDir: ../../../../src/test/java
-:kotlinTestDir: ../../../../src/test/kotlin
-
-[[extensions]]
-== Extension Model
-
-[[extensions-overview]]
-=== Overview
-
-In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
-JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
-`Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
-[[extensions-registration]]
-=== Registering Extensions
-
-Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
-
-[[extensions-registration-declarative]]
-==== Declarative Extension Registration
-
-Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
-register. `@ExtendWith` may also be declared on fields or on parameters in test class
-constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
-`@AfterEach` lifecycle methods.
-
-For example, to register a `WebServerExtension` for a particular test method, you would
-annotate the test method as follows. We assume the `WebServerExtension` starts a local web
-server and injects the server's URL into parameters annotated with `@WebServerUrl`.
-
-[source,java,indent=0]
-----
-@Test
-@ExtendWith(WebServerExtension.class)
-void getProductList(@WebServerUrl String serverUrl) {
-	WebClient webClient = new WebClient();
-	// Use WebClient to connect to web server using serverUrl and verify response
-	assertEquals(200, webClient.get(serverUrl + "/products").getResponseStatus());
-}
-----
-
-To register the `WebServerExtension` for all tests in a particular class and its
-subclasses, you would annotate the test class as follows.
-
-[source,java,indent=0]
-----
-@ExtendWith(WebServerExtension.class)
-class MyTests {
-	// ...
-}
-----
-
-Multiple extensions can be registered together like this:
-
-[source,java,indent=0]
-----
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-class MyFirstTests {
-	// ...
-}
-----
-
-As an alternative, multiple extensions can be registered separately like this:
-
-[source,java,indent=0]
-----
-@ExtendWith(DatabaseExtension.class)
-@ExtendWith(WebServerExtension.class)
-class MySecondTests {
-	// ...
-}
-----
-
-[TIP]
-.Extension Registration Order
-====
-Extensions registered declaratively via `@ExtendWith` at the class level, method level, or
-parameter level will be executed in the order in which they are declared in the source
-code. For example, the execution of tests in both `MyFirstTests` and `MySecondTests` will
-be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly that order**.
-====
-
-If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
-_meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
-can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
-
-[source,java,indent=0]
-----
-@Target({ ElementType.TYPE, ElementType.METHOD })
-@Retention(RetentionPolicy.RUNTIME)
-@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })
-public @interface DatabaseAndWebServerExtension {
-}
-----
-
-The above examples demonstrate how `@ExtendWith` can be applied at the class level or at
-the method level; however, for certain use cases it makes sense for an extension to be
-registered declaratively at the field or parameter level. Consider a
-`RandomNumberExtension` which generates random numbers that can be injected into a field or
-via a parameter in a constructor, test method, or lifecycle method. If the extension
-provides a `@Random` annotation that is meta-annotated with
-`@ExtendWith(RandomNumberExtension.class)` (see listing below), the extension can be used
-transparently as in the following `RandomNumberDemo` example.
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
-----
-
-[[extensions-RandomNumberExtension]]
-The following code listing provides an example of how one might choose to implement such a
-`RandomNumberExtension`. This implementation works for the use cases in
-`RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
-example, the random number generation support is limited to integers; it uses
-`java.util.Random` instead of `java.security.SecureRandom`; etc. In any case, it is
-important to note which extension APIs are implemented and for what reasons.
-
-Specifically, `RandomNumberExtension` implements the following extension APIs:
-
-- `BeforeAllCallback`: to support static field injection
-- `TestInstancePostProcessor`: to support non-static field injection
-- `ParameterResolver`: to support constructor and method injection
-
-[source,java,indent=0]
-----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
-----
-
-[TIP]
-.Extension Registration Order for `@ExtendWith` on Fields
-====
-Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
-to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
-deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
-inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
-`@RegisterExtension` fields also applies to `@ExtendWith` fields.
-
-[[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
-
-Developers can register extensions _programmatically_ by annotating fields in test classes
-with `{RegisterExtension}`.
-
-When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
-via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
-can be configured _programmatically_ -- for example, in order to pass arguments to the
-extension's constructor, a static factory method, or a builder API.
-
-[[extensions-registration-programmatic-order]]
-[TIP]
-.Extension Registration Order
-====
-By default, extensions registered programmatically via `@RegisterExtension` or
-declaratively via `@ExtendWith` on fields will be ordered using an algorithm that is
-deterministic but intentionally nonobvious. This ensures that subsequent runs of a test
-suite execute extensions in the same order, thereby allowing for repeatable builds.
-However, there are times when extensions need to be registered in an explicit order. To
-achieve that, annotate `@RegisterExtension` fields or `@ExtendWith` fields with `{Order}`.
-
-Any `@RegisterExtension` field or `@ExtendWith` field not annotated with `@Order` will be
-ordered using the _default_ order which has a value of `Integer.MAX_VALUE / 2`. This
-allows `@Order` annotated extension fields to be explicitly ordered before or after
-non-annotated extension fields. Extensions with an explicit order value less than the
-default order value will be registered before non-annotated extensions. Similarly,
-extensions with an explicit order value greater than the default order value will be
-registered after non-annotated extensions. For example, assigning an extension an explicit
-order value that is greater than the default order value allows _before_ callback
-extensions to be registered last and _after_ callback extensions to be registered first,
-relative to other programmatically registered extensions.
-====
-
-[TIP]
-.Extension Inheritance
-====
-Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
-will be inherited.
-
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
-====
-
-NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
-either `static` or non-static.
-
-[[extensions-registration-programmatic-static-fields]]
-===== Static Fields
-
-If a `@RegisterExtension` field is `static`, the extension will be registered after
-extensions that are registered at the class level via `@ExtendWith`. Such _static
-extensions_ are not limited in which extension APIs they can implement. Extensions
-registered via static fields may therefore implement class-level and instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`,
-`TestInstancePostProcessor`, and `TestInstancePreDestroyCallback` as well as method-level
-extension APIs such as `BeforeEachCallback`, etc.
-
-In the following example, the `server` field in the test class is initialized
-programmatically by using a builder pattern supported by the `WebServerExtension`. The
-configured `WebServerExtension` will be automatically registered as an extension at the
-class level -- for example, in order to start the server before all tests in the class
-and then stop the server after all tests in the class have completed. In addition, static
-lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@BeforeEach`,
-`@AfterEach`, and `@Test` methods can access the instance of the extension via the
-`server` field if necessary.
-
-[source,java,indent=0]
-.Registering an extension via a static field in Java
-----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
-
-The Kotlin programming language does not have the concept of a `static` field. However,
-the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
-annotation in Kotlin. If you want the Kotlin compiler to generate a `public static` field,
-you can use the `@JvmField` annotation instead.
-
-The following example is a version of the `WebServerDemo` from the previous section that
-has been ported to Kotlin.
-
-[source,kotlin,indent=0]
-.Registering an extension via a static field in Kotlin
-----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
-----
-
-[[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
-
-If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
-will be registered after the test class has been instantiated and after each registered
-`TestInstancePostProcessor` has been given a chance to post-process the test instance
-(potentially injecting the instance of the extension to be used into the annotated
-field). Thus, if such an _instance extension_ implements class-level or instance-level
-extension APIs such as `BeforeAllCallback`, `AfterAllCallback`, or
-`TestInstancePostProcessor`, those APIs will not be honored. Instance extensions will be
-registered _before_ extensions that are registered at the method level via `@ExtendWith`.
-
-In the following example, the `docs` field in the test class is initialized
-programmatically by invoking a custom `lookUpDocsDir()` method and supplying the result
-to the static `forPath()` factory method in the `DocumentationExtension`. The configured
-`DocumentationExtension` will be automatically registered as an extension at the method
-level. In addition, `@BeforeEach`, `@AfterEach`, and `@Test` methods can access the
-instance of the extension via the `docs` field if necessary.
-
-[source,java,indent=0]
-.An extension registered via an instance field
-----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
-----
-
-[[extensions-registration-automatic]]
-==== Automatic Extension Registration
-
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
-using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
-`{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
-automatically registered based on what is available in the classpath.
-
-Specifically, a custom extension can be registered by supplying its fully qualified class
-name in a file named `org.junit.jupiter.api.extension.Extension` within the
-`/META-INF/services` folder in its enclosing JAR file.
-
-[[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
-
-Auto-detection is an advanced feature and is therefore not enabled by default. To enable
-it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
-`true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
-the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to enable auto-detection of extensions, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.extensions.autodetection.enabled=true`
-
-When auto-detection is enabled, extensions discovered via the `{ServiceLoader}` mechanism
-will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
-support for `TestInfo`, `TestReporter`, etc.).
-
-[[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
-
-The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
-
-`junit.jupiter.extensions.autodetection.include=<patterns>`::
-    Comma-separated list of _include_ patterns for auto-detected extensions.
-`junit.jupiter.extensions.autodetection.exclude=<patterns>`::
-    Comma-separated list of _exclude_ patterns for auto-detected extensions.
-
-Include patterns are applied _before_ exclude patterns. If both include and exclude
-patterns are provided, only extensions that match at least one include pattern and do not
-match any exclude pattern will be auto-detected.
-
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
-
-[[extensions-registration-inheritance]]
-==== Extension Inheritance
-
-Registered extensions are inherited within test class hierarchies with top-down semantics.
-Similarly, extensions registered at the class-level are inherited at the method-level.
-This applies to all extensions, independent of how they are registered (declaratively or
-programmatically).
-
-This means that extensions registered declaratively via `@ExtendWith` on a superclass will
-be registered before extensions registered declaratively via `@ExtendWith` on a subclass.
-
-Similarly, extensions registered programmatically via `@RegisterExtension` or
-`@ExtendWith` on fields in a superclass will be registered before extensions registered
-programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
-
-NOTE: A specific extension implementation can only be registered once for a given
-extension context and its parent contexts. Consequently, any attempt to register a
-duplicate extension implementation will be ignored.
-
-[[extensions-conditions]]
-=== Conditional Test Execution
-
-`{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
-execution_.
-
-An `ExecutionCondition` is _evaluated_ for each container (e.g., a test class) to
-determine if all the tests it contains should be executed based on the supplied
-`ExtensionContext`. Similarly, an `ExecutionCondition` is _evaluated_ for each test to
-determine if a given test method should be executed based on the supplied
-`ExtensionContext`.
-
-When multiple `ExecutionCondition` extensions are registered, a container or test is
-disabled as soon as one of the conditions returns _disabled_. Thus, there is no guarantee
-that a condition is evaluated because another extension might have already caused a
-container or test to be disabled. In other words, the evaluation works like the
-short-circuiting boolean OR operator.
-
-See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
-
-[[extensions-conditions-deactivation]]
-==== Deactivating Conditions
-
-Sometimes it can be useful to run a test suite _without_ certain conditions being active.
-For example, you may wish to run tests even if they are annotated with `@Disabled` in
-order to see if they are still _broken_. To do this, provide a pattern for the
-`junit.jupiter.conditions.deactivate` _configuration parameter_ to specify which
-conditions should be deactivated (i.e., not evaluated) for the current test run. The
-pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
-`LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
-
-For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
-following system property.
-
-`-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
-
-[[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
-
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
-
-`{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
-_prior_ to test instances being constructed (by a constructor call or via
-`{TestInstanceFactory}`).
-
-This extension provides a symmetric call to `{TestInstancePreDestroyCallback}` and is useful
-in combination with other extensions to prepare constructor parameters or keeping track of test
-instances and their lifecycle.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
-
-`{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
-instances.
-
-Common use cases include acquiring the test instance from a dependency injection
-framework or invoking a static factory method to create the test class instance.
-
-If no `TestInstanceFactory` is registered, the framework will invoke the _sole_
-constructor for the test class to instantiate it, potentially resolving constructor
-arguments via registered `ParameterResolver` extensions.
-
-Extensions that implement `TestInstanceFactory` can be registered on test interfaces,
-top-level test classes, or `@Nested` test classes.
-
-[WARNING]
-====
-Registering multiple extensions that implement `TestInstanceFactory` for any single class
-will result in an exception being thrown for all tests in that class, in any subclass,
-and in any nested class. Note that any `TestInstanceFactory` registered in a superclass
-or _enclosing_ class (i.e., in the case of a `@Nested` test class) is _inherited_. It is
-the user's responsibility to ensure that only a single `TestInstanceFactory` is
-registered for any specific test class.
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
-
-`{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
-process_ test instances.
-
-Common use cases include injecting dependencies into the test instance, invoking custom
-initialization methods on the test instance, etc.
-
-For a concrete example, consult the source code for the `{MockitoExtension}` and the
-`{SpringExtension}`.
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
-====
-
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
-
-`{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
-test instances _after_ they have been used in tests and _before_ they are destroyed.
-
-Common use cases include cleaning dependencies that have been injected into the
-test instance, invoking custom de-initialization methods on the test instance, etc.
-
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
-
-`{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
-runtime.
-
-If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
-runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
-Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
-combination thereof.
-
-If you wish to implement a custom `{ParameterResolver}` that resolves parameters based
-solely on the type of the parameter, you may find it convenient to extend the
-`{TypeBasedParameterResolver}` which serves as a generic adapter for such use cases.
-
-For concrete examples, consult the source code for `{CustomTypeParameterResolver}`,
-`{CustomAnnotationParameterResolver}`, and `{MapOfListsTypeBasedParameterResolver}`.
-
-[WARNING]
-====
-Due to a bug in the byte code generated by `javac` on JDK versions prior to JDK 9,
-looking up annotations on parameters directly via the core `java.lang.reflect.Parameter`
-API will always fail for _inner class_ constructors (e.g., a constructor in a `@Nested`
-test class).
-
-The `{ParameterContext}` API supplied to `ParameterResolver` implementations therefore
-includes the following convenience methods for correctly looking up annotations on
-parameters. Extension authors are strongly encouraged to use these methods instead of
-those provided in `java.lang.reflect.Parameter` in order to avoid this bug in the JDK.
-
-* `boolean isAnnotated(Class<? extends Annotation> annotationType)`
-* `Optional<A> findAnnotation(Class<A> annotationType)`
-* `List<A> findRepeatableAnnotations(Class<A> annotationType)`
-====
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to support injecting test specific data into constructor parameters of the
-test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
-resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
-====
-
-[TIP]
-.Parameter resolution for methods called from extensions
-====
-Other extensions can also leverage registered `ParameterResolvers` for method and
-constructor invocations, using the `{ExecutableInvoker}` available via the
-`getExecutableInvoker()` method in the `ExtensionContext`.
-====
-
-[[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
-
-If multiple implementations of `ParameterResolver` that support the same type are
-registered for a test, a `ParameterResolutionException` will be thrown, with a
-message to indicate that competing resolvers have been discovered. See the following
-example:
-
-[source,java,indent=0]
-.Conflicting parameter resolution due to multiple resolvers claiming support for integers
-----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations are applied to different test
-methods as shown in the following example, no conflict occurs.
-
-[source,java,indent=0]
-.Fine-grained registration to avoid conflict
-----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
-----
-
-If the conflicting `ParameterResolver` implementations need to be applied to the same test
-method, you can implement a custom type or custom annotation as illustrated by
-`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
-
-[source,java,indent=0]
-.Custom type to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
-----
-
-A custom annotation makes the duplicate type distinguishable from its counterpart:
-
-[source,java,indent=0]
-.Custom annotation to resolve duplicate types
-----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
-----
-
-JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
-attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
-as Spring may also define parameter resolvers. Apply one of the techniques in this section
-to resolve any conflicts.
-
-Parameterized tests are another potential source of conflict. Ensure that tests annotated
-with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
 [[extensions-test-result-processing]]
 === Test Result Processing
 
@@ -628,630 +51,3 @@ invoked (see <<extensions-keeping-state>>). You can use the parent context's `St
 work with such resources.
 ====
 
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
-
-The following interfaces define the APIs for extending tests at various points in the
-test execution lifecycle. Consult the following sections for examples and the Javadoc for
-each of these interfaces in the `{extension-api-package}` package for further details.
-
-* `{BeforeAllCallback}`
-** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-*** `{BeforeEachCallback}`
-**** `{BeforeTestExecutionCallback}`
-**** `{AfterTestExecutionCallback}`
-*** `{AfterEachCallback}`
-** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
-* `{AfterAllCallback}`
-
-.Implementing Multiple Extension APIs
-NOTE: Extension developers may choose to implement any number of these interfaces
-within a single extension. Consult the source code of the `{SpringExtension}` for a
-concrete example.
-
-[[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
-
-`{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
-`Extensions` that wish to add behavior that will be executed _immediately before_ and
-_immediately after_ a test method is executed, respectively. As such, these callbacks are
-well suited for timing, tracing, and similar use cases. If you need to implement
-callbacks that are invoked _around_ `@BeforeEach` and `@AfterEach` methods, implement
-`BeforeEachCallback` and `AfterEachCallback` instead.
-
-The following example shows how to use these callbacks to calculate and log the execution
-time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
-and `AfterTestExecutionCallback` in order to time and log the test execution.
-
-[[extensions-lifecycle-callbacks-timing-extension]]
-[source,java,indent=0]
-.An extension that times and logs the execution of test methods
-----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
-----
-
-Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
-its tests will have this timing applied when they execute.
-
-[source,java,indent=0]
-.A test class that uses the example TimingExtension
-----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
-----
-
-The following is an example of the logging produced when `TimingExtensionTests` is run.
-
-....
-INFO: Method [sleep20ms] took 24 ms.
-INFO: Method [sleep50ms] took 53 ms.
-....
-
-[[extensions-exception-handling]]
-=== Exception Handling
-
-Exceptions thrown during the test execution may be intercepted and handled accordingly
-before propagating further, so that certain actions like error logging or resource releasing
-may be defined in specialized `Extensions`. JUnit Jupiter offers API for `Extensions` that
-wish to handle exceptions thrown during `@Test` methods via `{TestExecutionExceptionHandler}`
-and for those thrown during one of test lifecycle methods (`@BeforeAll`, `@BeforeEach`,
-`@AfterEach` and `@AfterAll`) via `{LifecycleMethodExecutionExceptionHandler}`.
-
-The following example shows an extension which will swallow all instances of `IOException`
-but rethrow any other type of exception.
-
-[source,java,indent=0]
-.An exception handling extension that filters IOExceptions in test execution
-----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
-----
-
-Another example shows how to record the state of an application under test exactly at
-the point of unexpected exception being thrown during setup and cleanup. Note that unlike
-relying on lifecycle callbacks, which may or may not be executed depending on the test
-status, this solution guarantees execution immediately after failing `@BeforeAll`,
-`@BeforeEach`, `@AfterEach` or `@AfterAll`.
-
-[source,java,indent=0]
-.An exception handling extension that records application state on error
-----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
-----
-
-Multiple execution exception handlers may be invoked for the same lifecycle method in
-order of declaration. If one of the handlers swallows the handled exception, subsequent
-ones will not be executed, and no failure will be propagated to JUnit engine, as if the
-exception was never thrown. Handlers may also choose to rethrow the exception or throw
-a different one, potentially wrapping the original.
-
-Extensions implementing `{LifecycleMethodExecutionExceptionHandler}` that wish to handle
-exceptions thrown during `@BeforeAll` or `@AfterAll` need to be registered on a class level,
-while handlers for `BeforeEach` and `AfterEach` may be also registered for individual
-test methods.
-
-[source,java,indent=0]
-.Registering multiple exception handling extensions
-----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
-----
-
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
-
-`{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
-timeouts before the `Thread.interrupt()` is called.
-
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
-
-`{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
-test code.
-
-The following example shows an extension that executes all test methods in Swing's Event
-Dispatch Thread.
-
-[source,java,indent=0]
-.An extension that executes tests in a user-defined thread
-----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
-----
-
-[NOTE]
-.Accessing the test-scoped `ExtensionContext`
-====
-You may override the `getTestInstantiationExtensionContextScope(...)` method to return
-`TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
-on the test method level.
-====
-
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
-
-A `{ClassTemplate}` class can only be executed when at least one
-`{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
-responsible for providing a `Stream` of `{ClassTemplateInvocationContext}` instances.
-Each context may specify a custom display name and a list of additional extensions that
-will only be used for the next invocation of the `{ClassTemplate}`.
-
-The following example shows how to write a class template as well as how to register
-and implement a `{ClassTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A class template with accompanying extension
-----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the class template will be invoked twice, meaning all test methods in
-the class template will be executed twice. The display names of the invocations will be
-`apple` and `banana` as specified by the invocation context. Each invocation registers a
-custom `{TestInstancePostProcessor}` which is used to inject a value into a field. The
-output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ ClassTemplateDemo ✔
-   ├─ apple ✔
-   │  ├─ notNull() ✔
-   │  └─ wellKnown() ✔
-   └─ banana ✔
-      ├─ notNull() ✔
-      └─ wellKnown() ✔
-....
-
-The `{ClassTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of _all_ test
-methods in a test class albeit in different contexts — for example, with different
-parameters, by preparing the test class instance differently, or multiple times without
-modifying the context.
-Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
-point to provide its functionality.
-
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
-
-A `{TestTemplate}` method can only be executed when at least one
-`{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
-for providing a `Stream` of `{TestTemplateInvocationContext}` instances. Each context may
-specify a custom display name and a list of additional extensions that will only be used
-for the next invocation of the `{TestTemplate}` method.
-
-The following example shows how to write a test template as well as how to register and
-implement a `{TestTemplateInvocationContextProvider}`.
-
-[source,java,indent=0]
-.A test template with accompanying extension
-----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
-----
-
-In this example, the test template will be invoked twice. The display names of the
-invocations will be `apple` and `banana` as specified by the invocation context. Each
-invocation registers a custom `{ParameterResolver}` which is used to resolve the method
-parameter. The output when using the `ConsoleLauncher` is as follows.
-
-....
-└─ testTemplate(String) ✔
-   ├─ apple ✔
-   └─ banana ✔
-....
-
-The `{TestTemplateInvocationContextProvider}` extension API is primarily intended for
-implementing different kinds of tests that rely on repetitive invocation of a test-like
-method albeit in different contexts — for example, with different parameters, by preparing
-the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
-to provide their functionality.
-
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
-
-Usually, an extension is instantiated only once. So the question becomes relevant: How do
-you keep the state from one invocation of an extension to the next? The
-`{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
-Extensions may put values into a store for later retrieval.
-
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
-example of using the `Store` with a method-level scope.
-
-.The `ExtensionContext` and `Store` hierarchy
-image::extensions_StoreHierarchy.svg[alt=UML diagram,role=text-center]
-
-As illustrated by the diagram above, stores are hierarchical in nature. When looking up a
-value, if no value is stored in the current `ExtensionContext` for the supplied key, the
-stores of the context's ancestors will be queried for a value with the same key in the
-`Namespace` used to create this store. The root `ExtensionContext` represents the engine
-level so its `Store` may be used to store or cache values that are used by multiple test
-classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyond even
-that and access the stores on the level of the current `{LauncherExecutionRequest}` or
-`{LauncherSession}` which can be used to share data across test engines or inject data
-from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
-respectively. Please consult the Javadoc of `{ExtensionContext}`,
-`{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
-
-[[extensions-keeping-state-autocloseable-support]]
-[NOTE]
-.Resource management via `_AutoCloseable_`
-====
-An extension context store is bound to its extension context lifecycle. When an extension
-context lifecycle ends it closes its associated store.
-
-All stored values that are instances of `AutoCloseable` are notified by an invocation of
-their `close()` method in the inverse order they were added in (unless the
-`junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
-
-Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
-available for backward compatibility.
-====
-
-An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
-resource.
-
-[source,java,indent=0]
-.`_HttpServer_` resource implementing `_AutoCloseable_`
-----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
-----
-
-This resource can then be stored in the desired `ExtensionContext`. It may be stored at
-class or method level, if desired, but this may add unnecessary overhead for this type of
-resource. For this example it might be prudent to store it at root level and instantiate
-it lazily to ensure it's only created once per test run and reused across different test
-classes and methods.
-
-[source,java,indent=0]
-.Lazily storing in root context with `_Store.computeIfAbsent_`
-----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.A test case using the `_HttpServerExtension_`
-----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
-----
-
-[[extensions-keeping-state-autocloseable-migration]]
-[TIP]
-.Migration Note for Resource Cleanup
-====
-The framework automatically closes resources stored in the `ExtensionContext.Store` that
-implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
-`Store.CloseableResource` were automatically closed.
-
-If you're developing an extension that needs to support both JUnit Jupiter 5.13+ and
-earlier versions and your extension stores resources that need to be cleaned up, you
-should implement both interfaces:
-
-[source,java,indent=0]
-----
-public class MyResource implements Store.CloseableResource, AutoCloseable {
-    @Override
-    public void close() throws Exception {
-        // Resource cleanup code
-    }
-}
-----
-
-This ensures that your resource will be properly closed regardless of which JUnit Jupiter
-version is being used.
-====
-
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
-
-The `junit-platform-commons` artifact provides _maintained_ utilities for working with
-annotations, classes, reflection, classpath scanning, and conversion tasks. These
-utilities can be found in the `{junit-platform-support-package}` and its subpackages.
-`TestEngine` and `Extension` authors are encouraged to use these supported utilities in
-order to align with the behavior of the JUnit Platform and JUnit Jupiter.
-
-[[extensions-supported-utilities-annotations]]
-==== Annotation Support
-
-`AnnotationSupport` provides static utility methods that operate on annotated elements
-(e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
-These include methods to check whether an element is annotated or meta-annotated with a
-particular annotation, to search for specific annotations, and to find annotated methods
-and fields in a class or interface. Some of these methods search on implemented
-interfaces and within class hierarchies to find annotations. Consult the Javadoc for
-`{AnnotationSupport}` for further details.
-
-NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
-use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-classes]]
-==== Class Support
-
-`ClassSupport` provides static utility methods for working with classes (i.e., instances
-of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
-
-[[extensions-supported-utilities-reflection]]
-==== Reflection Support
-
-`ReflectionSupport` provides static utility methods that augment the standard JDK
-reflection and class-loading mechanisms. These include methods to scan the classpath in
-search of classes matching specified predicates, to load and create new instances of a
-class, and to find and invoke methods. Some of these methods traverse class hierarchies
-to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
-details.
-
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
-
-[[extensions-supported-utilities-modifier]]
-==== Modifier Support
-
-`ModifierSupport` provides static utility methods for working with member and class
-modifiers -- for example, to determine if a member is declared as `public`, `private`,
-`abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
-details.
-
-[[extensions-supported-utilities-conversion]]
-==== Conversion Support
-
-`ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
-provides support for converting from strings to primitive types and their corresponding
-wrapper types, date and time types from the `java.time package`, and some additional
-common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
-`URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
-
-[[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
-
-Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
-traverse type hierarchies to locate matching fields and methods – for example,
-`AnnotationSupport.findAnnotatedFields(...)`, `ReflectionSupport.findMethods(...)`, etc.
-
-The field and method search algorithms adhere to standard Java semantics regarding whether
-a given field or method is visible or overridden according to the rules of the Java
-language.
-
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
-
-When executing a test class that contains one or more test methods, a number of extension
-callbacks are called in addition to the user-supplied test and lifecycle methods.
-
-NOTE: See also: <<writing-tests-test-execution-order>>
-
-[[extensions-execution-order-overview]]
-==== User and Extension Code
-
-The following diagram illustrates the relative order of user-supplied code and extension
-code. User-supplied test and lifecycle methods are shown in orange, with callback code
-implemented by extensions shown in blue. The grey box denotes the execution of a single
-test method and will be repeated for every test method in the test class.
-
-[[extensions-execution-order-diagram]]
-.User code and extension code
-image::extensions_lifecycle.png[]
-
-The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
-
-. *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
-extension code executed before all tests of the container are executed
-. *annotation* `*org.junit.jupiter.api.BeforeAll*` +
-user code executed before all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeAll` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
-extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
-extension code executed before each test is executed
-. *annotation* `*org.junit.jupiter.api.BeforeEach*` +
-user code executed before each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleBeforeEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@BeforeEach` methods
-. *interface* `*org.junit.jupiter.api.extension.BeforeTestExecutionCallback*` +
-extension code executed immediately before a test is executed
-. *annotation* `*org.junit.jupiter.api.Test*` +
-user code of the actual test method
-. *interface* `*org.junit.jupiter.api.extension.TestExecutionExceptionHandler*` +
-extension code for handling exceptions thrown during a test
-. *interface* `*org.junit.jupiter.api.extension.AfterTestExecutionCallback*` +
-extension code executed immediately after test execution and its corresponding exception handlers
-. *annotation* `*org.junit.jupiter.api.AfterEach*` +
-user code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterEachMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterEach` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterEachCallback*` +
-extension code executed after each test is executed
-. *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
-extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
-. *annotation* `*org.junit.jupiter.api.AfterAll*` +
-user code executed after all tests of the container are executed
-. *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
-#handleAfterAllMethodExecutionException*` +
-extension code for handling exceptions thrown from `@AfterAll` methods
-. *interface* `*org.junit.jupiter.api.extension.AfterAllCallback*` +
-extension code executed after all tests of the container are executed
-
-In the simplest case only the actual test method will be executed (step 9); all other
-steps are optional depending on the presence of user code or extension support for the
-corresponding lifecycle callback. For further details on the various lifecycle callbacks
-please consult the respective Javadoc for each annotation and extension.
-
-All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
-
-[[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
-
-JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
-that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
-`BeforeClassTemplateInvocationCallback`, `AfterClassTemplateInvocationCallback`,
-`BeforeEachCallback`, `AfterEachCallback`, `BeforeTestExecutionCallback`, and
-`AfterTestExecutionCallback`.
-
-That means that, given two extensions `Extension1` and `Extension2` with `Extension1`
-registered before `Extension2`, any "before" callbacks implemented by `Extension1` are
-guaranteed to execute **before** any "before" callbacks implemented by `Extension2`.
-Similarly, given the two same two extensions registered in the same order, any "after"
-callbacks implemented by `Extension1` are guaranteed to execute **after** any "after"
-callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
-`Extension2`.
-
-JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
-
-* `@BeforeAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
-  **before** `@BeforeAll` methods in subclasses.
-** Similarly, `@BeforeAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@BeforeAll` methods from an interface will be executed
-   **before** `@BeforeAll` methods in the class that implements the interface.
-* `@AfterAll` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterAll` methods from superclasses will be executed
-  **after** `@AfterAll` methods in subclasses.
-** Similarly, `@AfterAll` methods declared in an interface are inherited as long as they
-   are not _overridden_, and `@AfterAll` methods from an interface will be executed
-   **after** `@AfterAll` methods in the class that implements the interface.
-* `@BeforeEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@BeforeEach` methods from superclasses will be executed
-  **before** `@BeforeEach` methods in subclasses.
-** Similarly, `@BeforeEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@BeforeEach` default methods will be executed
-   **before** `@BeforeEach` methods in the class that implements the interface.
-* `@AfterEach` methods are inherited from superclasses as long as they are not
-  _overridden_. Furthermore, `@AfterEach` methods from superclasses will be executed
-  **after** `@AfterEach` methods in subclasses.
-** Similarly, `@AfterEach` methods declared as interface default methods are inherited as
-   long as they are not _overridden_, and `@AfterEach` default methods will be executed
-   **after** `@AfterEach` methods in the class that implements the interface.
-
-The following examples demonstrate this behavior. Please note that the examples do not
-actually do anything realistic. Instead, they mimic common scenarios for testing
-interactions with the database. All methods imported statically from the `Logger` class
-log contextual information in order to help us better understand the execution order of
-user-supplied callback methods and callback methods in extensions.
-
-[source,java,indent=0]
-.Extension1
-----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.Extension2
-----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.AbstractDatabaseTests
-----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
-----
-
-[source,java,indent=0]
-.DatabaseTestsDemo
-----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
-----
-
-When the `DatabaseTestsDemo` test class is executed, the following is logged.
-
-----
-@BeforeAll AbstractDatabaseTests.createDatabase()
-@BeforeAll DatabaseTestsDemo.beforeAll()
-  Extension1.beforeEach()
-  Extension2.beforeEach()
-    @BeforeEach AbstractDatabaseTests.connectToDatabase()
-    @BeforeEach DatabaseTestsDemo.insertTestDataIntoDatabase()
-      @Test DatabaseTestsDemo.testDatabaseFunctionality()
-    @AfterEach DatabaseTestsDemo.deleteTestDataFromDatabase()
-    @AfterEach AbstractDatabaseTests.disconnectFromDatabase()
-  Extension2.afterEach()
-  Extension1.afterEach()
-@BeforeAll DatabaseTestsDemo.afterAll()
-@AfterAll AbstractDatabaseTests.destroyDatabase()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `DatabaseTestsDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_DatabaseTestsDemo.png[caption='',title='DatabaseTestsDemo']
-
-JUnit Jupiter does **not** guarantee the execution order of multiple lifecycle methods
-that are declared within a _single_ test class or test interface. It may at times appear
-that JUnit Jupiter invokes such methods in alphabetical order. However, that is not
-precisely true. The ordering is analogous to the ordering for `@Test` methods within a
-single test class.
-
-[NOTE]
-====
-Lifecycle methods that are declared within a _single_ test class or test interface will be
-ordered using an algorithm that is deterministic but intentionally non-obvious. This
-ensures that subsequent runs of a test suite execute lifecycle methods in the same order,
-thereby allowing for repeatable builds.
-====
-
-In addition, JUnit Jupiter does **not** support _wrapping_ behavior for multiple lifecycle
-methods declared within a single test class or test interface.
-
-The following example demonstrates this behavior. Specifically, the lifecycle method
-configuration is _broken_ due to the order in which the locally declared lifecycle methods
-are executed.
-
-* Test data is inserted _before_ the database connection has been opened, which results in
-  a failure to connect to the database.
-* The database connection is closed _before_ deleting the test data, which results in a
-  failure to connect to the database.
-
-[source,java,indent=0]
-.BrokenLifecycleMethodConfigDemo
-----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
-----
-
-When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
-
-----
-Extension1.beforeEach()
-Extension2.beforeEach()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.insertTestDataIntoDatabase()
-  @BeforeEach BrokenLifecycleMethodConfigDemo.connectToDatabase()
-    @Test BrokenLifecycleMethodConfigDemo.testDatabaseFunctionality()
-  @AfterEach BrokenLifecycleMethodConfigDemo.disconnectFromDatabase()
-  @AfterEach BrokenLifecycleMethodConfigDemo.deleteTestDataFromDatabase()
-Extension2.afterEach()
-Extension1.afterEach()
-----
-
-The following sequence diagram helps to shed further light on what actually goes on within
-the `JupiterTestEngine` when the `BrokenLifecycleMethodConfigDemo` test class is executed.
-
-////
-PNG generated using ZenUML: https://app.zenuml.com
-
-See corresponding *.txt file in images folder for the source.
-////
-image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLifecycleMethodConfigDemo']
-
-[TIP]
-====
-Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
-class or test interface unless there are no dependencies between such lifecycle methods.
-====

From d9b8c5468ca39c6c26b92a1d84e9ea60d203cb14 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:13 +0100
Subject: [PATCH 29/57] Migrate extensions sections to Antora syntax

---
 .../conditional-test-execution.adoc           |  8 ++---
 .../pages/extensions/exception-handling.adoc  | 10 +++---
 .../extensions/intercepting-invocations.adoc  |  6 ++--
 .../keeping-state-in-extensions.adoc          | 10 +++---
 .../ROOT/pages/extensions/overview.adoc       |  4 +--
 .../extensions/parameter-resolution.adoc      | 14 ++++----
 .../extensions/pre-interrupt-callback.adoc    |  5 +--
 ...vocation-contexts-for-class-templates.adoc |  6 ++--
 ...nvocation-contexts-for-test-templates.adoc |  6 ++--
 .../extensions/registering-extensions.adoc    | 34 +++++++++----------
 ...ion-order-of-user-code-and-extensions.adoc | 17 +++++-----
 .../supported-utilities-in-extensions.adoc    | 16 ++++-----
 .../extensions/test-instance-factories.adoc   |  4 +--
 .../test-instance-post-processing.adoc        |  4 +--
 .../test-instance-pre-construct-callback.adoc |  4 +--
 .../test-instance-pre-destroy-callback.adoc   |  4 +--
 .../extensions/test-lifecycle-callbacks.adoc  | 10 +++---
 .../extensions/test-result-processing.adoc    |  4 +--
 18 files changed, 65 insertions(+), 101 deletions(-)

diff --git a/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc b/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc
index 5dfa63cccd3c..8efca7980733 100644
--- a/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc
+++ b/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc
@@ -1,5 +1,4 @@
-[[extensions-conditions]]
-=== Conditional Test Execution
+= Conditional Test Execution
 
 `{ExecutionCondition}` defines the `Extension` API for programmatic, _conditional test
 execution_.
@@ -19,7 +18,7 @@ short-circuiting boolean OR operator.
 See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
 
 [[extensions-conditions-deactivation]]
-==== Deactivating Conditions
+== Deactivating Conditions
 
 Sometimes it can be useful to run a test suite _without_ certain conditions being active.
 For example, you may wish to run tests even if they are annotated with `@Disabled` in
@@ -36,7 +35,6 @@ following system property.
 `-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
 
 [[extensions-conditions-deactivation-patterns]]
-===== Pattern Matching Syntax
+=== Pattern Matching Syntax
 
 Refer to <<running-tests-config-params-deactivation-pattern>> for details.
-
diff --git a/documentation/modules/ROOT/pages/extensions/exception-handling.adoc b/documentation/modules/ROOT/pages/extensions/exception-handling.adoc
index a6629a46d72b..b4eb6d0eb213 100644
--- a/documentation/modules/ROOT/pages/extensions/exception-handling.adoc
+++ b/documentation/modules/ROOT/pages/extensions/exception-handling.adoc
@@ -1,5 +1,4 @@
-[[extensions-exception-handling]]
-=== Exception Handling
+= Exception Handling
 
 Exceptions thrown during the test execution may be intercepted and handled accordingly
 before propagating further, so that certain actions like error logging or resource releasing
@@ -14,7 +13,7 @@ but rethrow any other type of exception.
 [source,java,indent=0]
 .An exception handling extension that filters IOExceptions in test execution
 ----
-include::{testDir}/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
+include::example$java/example/exception/IgnoreIOExceptionExtension.java[tags=user_guide]
 ----
 
 Another example shows how to record the state of an application under test exactly at
@@ -26,7 +25,7 @@ status, this solution guarantees execution immediately after failing `@BeforeAll
 [source,java,indent=0]
 .An exception handling extension that records application state on error
 ----
-include::{testDir}/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
+include::example$java/example/exception/RecordStateOnErrorExtension.java[tags=user_guide]
 ----
 
 Multiple execution exception handlers may be invoked for the same lifecycle method in
@@ -43,6 +42,5 @@ test methods.
 [source,java,indent=0]
 .Registering multiple exception handling extensions
 ----
-include::{testDir}/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
+include::example$java/example/exception/MultipleHandlersTestCase.java[tags=user_guide]
 ----
-
diff --git a/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc b/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc
index 590543f1a86d..c78e1edc00e5 100644
--- a/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc
+++ b/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc
@@ -1,5 +1,4 @@
-[[extensions-intercepting-invocations]]
-=== Intercepting Invocations
+= Intercepting Invocations
 
 `{InvocationInterceptor}` defines the API for `Extensions` that wish to intercept calls to
 test code.
@@ -10,7 +9,7 @@ Dispatch Thread.
 [source,java,indent=0]
 .An extension that executes tests in a user-defined thread
 ----
-include::{testDir}/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
+include::example$java/example/interceptor/SwingEdtInterceptor.java[tags=user_guide]
 ----
 
 [NOTE]
@@ -21,4 +20,3 @@ You may override the `getTestInstantiationExtensionContextScope(...)` method to
 `interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
 on the test method level.
 ====
-
diff --git a/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc b/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc
index 51cc8a553c92..5017884c73f5 100644
--- a/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc
+++ b/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc
@@ -1,5 +1,4 @@
-[[extensions-keeping-state]]
-=== Keeping State in Extensions
+= Keeping State in Extensions
 
 Usually, an extension is instantiated only once. So the question becomes relevant: How do
 you keep the state from one invocation of an extension to the next? The
@@ -47,7 +46,7 @@ resource.
 [source,java,indent=0]
 .`_HttpServer_` resource implementing `_AutoCloseable_`
 ----
-include::{testDir}/example/extensions/HttpServerResource.java[tags=user_guide]
+include::example$java/example/extensions/HttpServerResource.java[tags=user_guide]
 ----
 
 This resource can then be stored in the desired `ExtensionContext`. It may be stored at
@@ -59,13 +58,13 @@ classes and methods.
 [source,java,indent=0]
 .Lazily storing in root context with `_Store.computeIfAbsent_`
 ----
-include::{testDir}/example/extensions/HttpServerExtension.java[tags=user_guide]
+include::example$java/example/extensions/HttpServerExtension.java[tags=user_guide]
 ----
 
 [source,java,indent=0]
 .A test case using the `_HttpServerExtension_`
 ----
-include::{testDir}/example/HttpServerDemo.java[tags=user_guide]
+include::example$java/example/HttpServerDemo.java[tags=user_guide]
 ----
 
 [[extensions-keeping-state-autocloseable-migration]]
@@ -93,4 +92,3 @@ public class MyResource implements Store.CloseableResource, AutoCloseable {
 This ensures that your resource will be properly closed regardless of which JUnit Jupiter
 version is being used.
 ====
-
diff --git a/documentation/modules/ROOT/pages/extensions/overview.adoc b/documentation/modules/ROOT/pages/extensions/overview.adoc
index 8d2f8e4112b5..9bf16307643a 100644
--- a/documentation/modules/ROOT/pages/extensions/overview.adoc
+++ b/documentation/modules/ROOT/pages/extensions/overview.adoc
@@ -1,7 +1,5 @@
-[[extensions-overview]]
-=== Overview
+= Extension Model
 
 In contrast to the competing `Runner`, `TestRule`, and `MethodRule` extension points in
 JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
 `Extension` API. Note, however, that `Extension` itself is just a marker interface.
-
diff --git a/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc b/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc
index 6e92e3ab863d..c626f20c8530 100644
--- a/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc
+++ b/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc
@@ -1,5 +1,4 @@
-[[extensions-parameter-resolution]]
-=== Parameter Resolution
+= Parameter Resolution
 
 `{ParameterResolver}` defines the `Extension` API for dynamically resolving parameters at
 runtime.
@@ -54,7 +53,7 @@ constructor invocations, using the `{ExecutableInvoker}` available via the
 ====
 
 [[extensions-parameter-resolution-conflicts]]
-==== Parameter Conflicts
+== Parameter Conflicts
 
 If multiple implementations of `ParameterResolver` that support the same type are
 registered for a test, a `ParameterResolutionException` will be thrown, with a
@@ -64,7 +63,7 @@ example:
 [source,java,indent=0]
 .Conflicting parameter resolution due to multiple resolvers claiming support for integers
 ----
-include::{testDir}/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
+include::example$java/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
 ----
 
 If the conflicting `ParameterResolver` implementations are applied to different test
@@ -73,7 +72,7 @@ methods as shown in the following example, no conflict occurs.
 [source,java,indent=0]
 .Fine-grained registration to avoid conflict
 ----
-include::{testDir}/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
+include::example$java/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
 ----
 
 If the conflicting `ParameterResolver` implementations need to be applied to the same test
@@ -83,7 +82,7 @@ method, you can implement a custom type or custom annotation as illustrated by
 [source,java,indent=0]
 .Custom type to resolve duplicate types
 ----
-include::{testDir}/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
+include::example$java/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
 ----
 
 A custom annotation makes the duplicate type distinguishable from its counterpart:
@@ -91,7 +90,7 @@ A custom annotation makes the duplicate type distinguishable from its counterpar
 [source,java,indent=0]
 .Custom annotation to resolve duplicate types
 ----
-include::{testDir}/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
+include::example$java/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
 ----
 
 JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
@@ -103,4 +102,3 @@ to resolve any conflicts.
 Parameterized tests are another potential source of conflict. Ensure that tests annotated
 with `@ParameterizedTest` are not also annotated with `@Test` and see
 <<writing-tests-parameterized-tests-consuming-arguments>> for more details.
-
diff --git a/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc b/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc
index 5d34a551de65..5e61a03abe74 100644
--- a/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc
+++ b/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc
@@ -1,9 +1,6 @@
-[[extensions-preinterrupt-callback]]
-=== Pre-Interrupt Callback
+= Pre-Interrupt Callback
 
 `{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
 timeouts before the `Thread.interrupt()` is called.
 
 Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
-
-
diff --git a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc
index 7b0ac9babcab..f111450665bc 100644
--- a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc
+++ b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc
@@ -1,5 +1,4 @@
-[[extensions-class-templates]]
-=== Providing Invocation Contexts for Class Templates
+= Providing Invocation Contexts for Class Templates
 
 A `{ClassTemplate}` class can only be executed when at least one
 `{ClassTemplateInvocationContextProvider}` is registered. Each such provider is
@@ -13,7 +12,7 @@ and implement a `{ClassTemplateInvocationContextProvider}`.
 [source,java,indent=0]
 .A class template with accompanying extension
 ----
-include::{testDir}/example/ClassTemplateDemo.java[tags=user_guide]
+include::example$java/example/ClassTemplateDemo.java[tags=user_guide]
 ----
 
 In this example, the class template will be invoked twice, meaning all test methods in
@@ -40,4 +39,3 @@ modifying the context.
 Please refer to the implementations of
 <<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
 point to provide its functionality.
-
diff --git a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc
index 4a4d22c5ca6c..b7b488180b5b 100644
--- a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc
+++ b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc
@@ -1,5 +1,4 @@
-[[extensions-test-templates]]
-=== Providing Invocation Contexts for Test Templates
+= Providing Invocation Contexts for Test Templates
 
 A `{TestTemplate}` method can only be executed when at least one
 `{TestTemplateInvocationContextProvider}` is registered. Each such provider is responsible
@@ -13,7 +12,7 @@ implement a `{TestTemplateInvocationContextProvider}`.
 [source,java,indent=0]
 .A test template with accompanying extension
 ----
-include::{testDir}/example/TestTemplateDemo.java[tags=user_guide]
+include::example$java/example/TestTemplateDemo.java[tags=user_guide]
 ----
 
 In this example, the test template will be invoked twice. The display names of the
@@ -34,4 +33,3 @@ the test class instance differently, or multiple times without modifying the con
 Please refer to the implementations of <<writing-tests-repeated-tests>> or
 <<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
 to provide their functionality.
-
diff --git a/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc b/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc
index 3dd520298948..d7d9dedbf39b 100644
--- a/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc
+++ b/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc
@@ -1,5 +1,4 @@
-[[extensions-registration]]
-=== Registering Extensions
+= Registering Extensions
 
 Extensions can be registered _declaratively_ via
 <<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
@@ -7,7 +6,7 @@ Extensions can be registered _declaratively_ via
 Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
 
 [[extensions-registration-declarative]]
-==== Declarative Extension Registration
+== Declarative Extension Registration
 
 Developers can register one or more extensions _declaratively_ by annotating a test
 interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
@@ -97,12 +96,12 @@ transparently as in the following `RandomNumberDemo` example.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/extensions/Random.java[tags=user_guide]
+include::example$java/example/extensions/Random.java[tags=user_guide]
 ----
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/extensions/RandomNumberDemo.java[tags=user_guide]
+include::example$java/example/extensions/RandomNumberDemo.java[tags=user_guide]
 ----
 
 [[extensions-RandomNumberExtension]]
@@ -121,7 +120,7 @@ Specifically, `RandomNumberExtension` implements the following extension APIs:
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/extensions/RandomNumberExtension.java[tags=user_guide]
+include::example$java/example/extensions/RandomNumberExtension.java[tags=user_guide]
 ----
 
 [TIP]
@@ -149,7 +148,7 @@ NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentati
 `@RegisterExtension` fields also applies to `@ExtendWith` fields.
 
 [[extensions-registration-programmatic]]
-==== Programmatic Extension Registration
+== Programmatic Extension Registration
 
 Developers can register extensions _programmatically_ by annotating fields in test classes
 with `{RegisterExtension}`.
@@ -196,7 +195,7 @@ NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but ma
 either `static` or non-static.
 
 [[extensions-registration-programmatic-static-fields]]
-===== Static Fields
+=== Static Fields
 
 If a `@RegisterExtension` field is `static`, the extension will be registered after
 extensions that are registered at the class level via `@ExtendWith`. Such _static
@@ -218,11 +217,11 @@ lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@Before
 [source,java,indent=0]
 .Registering an extension via a static field in Java
 ----
-include::{testDir}/example/registration/WebServerDemo.java[tags=user_guide]
+include::example$java/example/registration/WebServerDemo.java[tags=user_guide]
 ----
 
 [[extensions-registration-programmatic-static-fields-kotlin]]
-====== Static Fields in Kotlin
+==== Static Fields in Kotlin
 
 The Kotlin programming language does not have the concept of a `static` field. However,
 the compiler can be instructed to generate a `private static` field using the `@JvmStatic`
@@ -235,11 +234,11 @@ has been ported to Kotlin.
 [source,kotlin,indent=0]
 .Registering an extension via a static field in Kotlin
 ----
-include::{kotlinTestDir}/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
+include::example$kotlin/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
 ----
 
 [[extensions-registration-programmatic-instance-fields]]
-===== Instance Fields
+=== Instance Fields
 
 If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
 will be registered after the test class has been instantiated and after each registered
@@ -260,11 +259,11 @@ instance of the extension via the `docs` field if necessary.
 [source,java,indent=0]
 .An extension registered via an instance field
 ----
-include::{testDir}/example/registration/DocumentationDemo.java[tags=user_guide]
+include::example$java/example/registration/DocumentationDemo.java[tags=user_guide]
 ----
 
 [[extensions-registration-automatic]]
-==== Automatic Extension Registration
+== Automatic Extension Registration
 
 In addition to <<extensions-registration-declarative,declarative extension registration>>
 and <<extensions-registration-programmatic,programmatic extension registration>> support
@@ -277,7 +276,7 @@ name in a file named `org.junit.jupiter.api.extension.Extension` within the
 `/META-INF/services` folder in its enclosing JAR file.
 
 [[extensions-registration-automatic-enabling]]
-===== Enabling Automatic Extension Detection
+=== Enabling Automatic Extension Detection
 
 Auto-detection is an advanced feature and is therefore not enabled by default. To enable
 it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
@@ -295,7 +294,7 @@ will be added to the extension registry after JUnit Jupiter's global extensions
 support for `TestInfo`, `TestReporter`, etc.).
 
 [[extensions-registration-automatic-filtering]]
-===== Filtering Auto-detected Extensions
+=== Filtering Auto-detected Extensions
 
 The list of auto-detected extensions can be filtered using include and exclude patterns
 via the following <<running-tests-config-params, configuration parameters>>:
@@ -312,7 +311,7 @@ match any exclude pattern will be auto-detected.
 See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
 
 [[extensions-registration-inheritance]]
-==== Extension Inheritance
+== Extension Inheritance
 
 Registered extensions are inherited within test class hierarchies with top-down semantics.
 Similarly, extensions registered at the class-level are inherited at the method-level.
@@ -331,4 +330,3 @@ Extension Registration Order>> for details).
 NOTE: A specific extension implementation can only be registered once for a given
 extension context and its parent contexts. Consequently, any attempt to register a
 duplicate extension implementation will be ignored.
-
diff --git a/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc b/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc
index 8e5da6d38612..f062f7987df0 100644
--- a/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc
+++ b/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc
@@ -1,5 +1,4 @@
-[[extensions-execution-order]]
-=== Relative Execution Order of User Code and Extensions
+= Relative Execution Order of User Code and Extensions
 
 When executing a test class that contains one or more test methods, a number of extension
 callbacks are called in addition to the user-supplied test and lifecycle methods.
@@ -7,7 +6,7 @@ callbacks are called in addition to the user-supplied test and lifecycle methods
 NOTE: See also: <<writing-tests-test-execution-order>>
 
 [[extensions-execution-order-overview]]
-==== User and Extension Code
+== User and Extension Code
 
 The following diagram illustrates the relative order of user-supplied code and extension
 code. User-supplied test and lifecycle methods are shown in orange, with callback code
@@ -73,7 +72,7 @@ All invocations of user code methods in the above table can additionally be inte
 by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
 
 [[extensions-execution-order-wrapping-behavior]]
-==== Wrapping Behavior of Callbacks
+== Wrapping Behavior of Callbacks
 
 JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
 that implement lifecycle callbacks such as `BeforeAllCallback`, `AfterAllCallback`,
@@ -126,25 +125,25 @@ user-supplied callback methods and callback methods in extensions.
 [source,java,indent=0]
 .Extension1
 ----
-include::{testDir}/example/callbacks/Extension1.java[tags=user_guide]
+include::example$java/example/callbacks/Extension1.java[tags=user_guide]
 ----
 
 [source,java,indent=0]
 .Extension2
 ----
-include::{testDir}/example/callbacks/Extension2.java[tags=user_guide]
+include::example$java/example/callbacks/Extension2.java[tags=user_guide]
 ----
 
 [source,java,indent=0]
 .AbstractDatabaseTests
 ----
-include::{testDir}/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
+include::example$java/example/callbacks/AbstractDatabaseTests.java[tags=user_guide]
 ----
 
 [source,java,indent=0]
 .DatabaseTestsDemo
 ----
-include::{testDir}/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
+include::example$java/example/callbacks/DatabaseTestsDemo.java[tags=user_guide]
 ----
 
 When the `DatabaseTestsDemo` test class is executed, the following is logged.
@@ -204,7 +203,7 @@ are executed.
 [source,java,indent=0]
 .BrokenLifecycleMethodConfigDemo
 ----
-include::{testDir}/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
+include::example$java/example/callbacks/BrokenLifecycleMethodConfigDemo.java[tags=user_guide]
 ----
 
 When the `BrokenLifecycleMethodConfigDemo` test class is executed, the following is logged.
diff --git a/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc b/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc
index 0bd27a99d5a2..38ca96625bab 100644
--- a/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc
+++ b/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc
@@ -1,5 +1,4 @@
-[[extensions-supported-utilities]]
-=== Supported Utilities in Extensions
+= Supported Utilities in Extensions
 
 The `junit-platform-commons` artifact provides _maintained_ utilities for working with
 annotations, classes, reflection, classpath scanning, and conversion tasks. These
@@ -8,7 +7,7 @@ utilities can be found in the `{junit-platform-support-package}` and its subpack
 order to align with the behavior of the JUnit Platform and JUnit Jupiter.
 
 [[extensions-supported-utilities-annotations]]
-==== Annotation Support
+== Annotation Support
 
 `AnnotationSupport` provides static utility methods that operate on annotated elements
 (e.g., packages, annotations, classes, interfaces, constructors, methods, and fields).
@@ -24,13 +23,13 @@ use one of the `findRepeatableAnnotations()` methods and verify that the returne
 NOTE: See also: <<extensions-supported-utilities-search-semantics>>
 
 [[extensions-supported-utilities-classes]]
-==== Class Support
+== Class Support
 
 `ClassSupport` provides static utility methods for working with classes (i.e., instances
 of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
 
 [[extensions-supported-utilities-reflection]]
-==== Reflection Support
+== Reflection Support
 
 `ReflectionSupport` provides static utility methods that augment the standard JDK
 reflection and class-loading mechanisms. These include methods to scan the classpath in
@@ -42,7 +41,7 @@ details.
 NOTE: See also: <<extensions-supported-utilities-search-semantics>>
 
 [[extensions-supported-utilities-modifier]]
-==== Modifier Support
+== Modifier Support
 
 `ModifierSupport` provides static utility methods for working with member and class
 modifiers -- for example, to determine if a member is declared as `public`, `private`,
@@ -50,7 +49,7 @@ modifiers -- for example, to determine if a member is declared as `public`, `pri
 details.
 
 [[extensions-supported-utilities-conversion]]
-==== Conversion Support
+== Conversion Support
 
 `ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
 provides support for converting from strings to primitive types and their corresponding
@@ -59,7 +58,7 @@ common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Local
 `URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
 
 [[extensions-supported-utilities-search-semantics]]
-==== Field and Method Search Semantics
+== Field and Method Search Semantics
 
 Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
 traverse type hierarchies to locate matching fields and methods – for example,
@@ -68,4 +67,3 @@ traverse type hierarchies to locate matching fields and methods – for example,
 The field and method search algorithms adhere to standard Java semantics regarding whether
 a given field or method is visible or overridden according to the rules of the Java
 language.
-
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc
index ff042496c539..1682268d2ae5 100644
--- a/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc
@@ -1,5 +1,4 @@
-[[extensions-test-instance-factories]]
-=== Test Instance Factories
+= Test Instance Factories
 
 `{TestInstanceFactory}` defines the API for `Extensions` that wish to _create_ test class
 instances.
@@ -31,4 +30,3 @@ You may override the `getTestInstantiationExtensionContextScope(...)` method to
 `TEST_METHOD` to make test-specific data available to your extension implementation or if
 you want to <<extensions-keeping-state, keep state>> on the test method level.
 ====
-
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc
index 84dbc3bca5f3..41b8b3b3de28 100644
--- a/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc
@@ -1,5 +1,4 @@
-[[extensions-test-instance-post-processing]]
-=== Test Instance Post-processing
+= Test Instance Post-processing
 
 `{TestInstancePostProcessor}` defines the API for `Extensions` that wish to _post
 process_ test instances.
@@ -17,4 +16,3 @@ You may override the `getTestInstantiationExtensionContextScope(...)` method to
 `TEST_METHOD` to make test-specific data available to your extension implementation or if
 you want to <<extensions-keeping-state, keep state>> on the test method level.
 ====
-
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc
index 65a185ef79aa..4d4623367526 100644
--- a/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc
@@ -1,5 +1,4 @@
-[[extensions-test-instance-pre-construct-callback]]
-=== Test Instance Pre-construct Callback
+= Test Instance Pre-construct Callback
 
 `{TestInstancePreConstructCallback}` defines the API for `Extensions` that wish to be invoked
 _prior_ to test instances being constructed (by a constructor call or via
@@ -16,4 +15,3 @@ You may override the `getTestInstantiationExtensionContextScope(...)` method to
 `TEST_METHOD` to make test-specific data available to your extension implementation or if
 you want to <<extensions-keeping-state, keep state>> on the test method level.
 ====
-
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-pre-destroy-callback.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-pre-destroy-callback.adoc
index acda444fb67a..4816c3a465c5 100644
--- a/documentation/modules/ROOT/pages/extensions/test-instance-pre-destroy-callback.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-pre-destroy-callback.adoc
@@ -1,9 +1,7 @@
-[[extensions-test-instance-pre-destroy-callback]]
-=== Test Instance Pre-destroy Callback
+= Test Instance Pre-destroy Callback
 
 `{TestInstancePreDestroyCallback}` defines the API for `Extensions` that wish to process
 test instances _after_ they have been used in tests and _before_ they are destroyed.
 
 Common use cases include cleaning dependencies that have been injected into the
 test instance, invoking custom de-initialization methods on the test instance, etc.
-
diff --git a/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc b/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc
index d34b10954a51..f0782ab64c31 100644
--- a/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc
@@ -1,5 +1,4 @@
-[[extensions-lifecycle-callbacks]]
-=== Test Lifecycle Callbacks
+= Test Lifecycle Callbacks
 
 The following interfaces define the APIs for extending tests at various points in the
 test execution lifecycle. Consult the following sections for examples and the Javadoc for
@@ -22,7 +21,7 @@ within a single extension. Consult the source code of the `{SpringExtension}` fo
 concrete example.
 
 [[extensions-lifecycle-callbacks-before-after-execution]]
-==== Before and After Test Execution Callbacks
+== Before and After Test Execution Callbacks
 
 `{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
 `Extensions` that wish to add behavior that will be executed _immediately before_ and
@@ -39,7 +38,7 @@ and `AfterTestExecutionCallback` in order to time and log the test execution.
 [source,java,indent=0]
 .An extension that times and logs the execution of test methods
 ----
-include::{testDir}/example/timing/TimingExtension.java[tags=user_guide]
+include::example$java/example/timing/TimingExtension.java[tags=user_guide]
 ----
 
 Since the `TimingExtensionTests` class registers the `TimingExtension` via `@ExtendWith`,
@@ -48,7 +47,7 @@ its tests will have this timing applied when they execute.
 [source,java,indent=0]
 .A test class that uses the example TimingExtension
 ----
-include::{testDir}/example/timing/TimingExtensionTests.java[tags=user_guide]
+include::example$java/example/timing/TimingExtensionTests.java[tags=user_guide]
 ----
 
 The following is an example of the logging produced when `TimingExtensionTests` is run.
@@ -57,4 +56,3 @@ The following is an example of the logging produced when `TimingExtensionTests`
 INFO: Method [sleep20ms] took 24 ms.
 INFO: Method [sleep50ms] took 53 ms.
 ....
-
diff --git a/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc b/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc
index 24e3ddf16680..c3d0f7503a1b 100644
--- a/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc
@@ -1,5 +1,4 @@
-[[extensions-test-result-processing]]
-=== Test Result Processing
+= Test Result Processing
 
 `{TestWatcher}` defines the API for extensions that wish to process the results of _test
 method_ executions. Specifically, a `TestWatcher` will be invoked with contextual
@@ -50,4 +49,3 @@ provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatche
 invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
 work with such resources.
 ====
-

From 336f793ef50b14df212fa18cd975396158857ad2 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:13 +0100
Subject: [PATCH 30/57] Add extensions sections to navigation

---
 documentation/modules/ROOT/nav.adoc | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/documentation/modules/ROOT/nav.adoc b/documentation/modules/ROOT/nav.adoc
index 37c8b335fa42..4f6e26390b2b 100644
--- a/documentation/modules/ROOT/nav.adoc
+++ b/documentation/modules/ROOT/nav.adoc
@@ -36,3 +36,21 @@
 ** xref:running-tests/using-listeners-and-interceptors.adoc[]
 ** xref:running-tests/stack-trace-pruning.adoc[]
 ** xref:running-tests/discovery-issues.adoc[]
+* xref:extensions/overview.adoc[]
+** xref:extensions/registering-extensions.adoc[]
+** xref:extensions/conditional-test-execution.adoc[]
+** xref:extensions/test-instance-pre-construct-callback.adoc[]
+** xref:extensions/test-instance-factories.adoc[]
+** xref:extensions/test-instance-post-processing.adoc[]
+** xref:extensions/test-instance-pre-destroy-callback.adoc[]
+** xref:extensions/parameter-resolution.adoc[]
+** xref:extensions/test-result-processing.adoc[]
+** xref:extensions/test-lifecycle-callbacks.adoc[]
+** xref:extensions/exception-handling.adoc[]
+** xref:extensions/pre-interrupt-callback.adoc[]
+** xref:extensions/intercepting-invocations.adoc[]
+** xref:extensions/providing-invocation-contexts-for-class-templates.adoc[]
+** xref:extensions/providing-invocation-contexts-for-test-templates.adoc[]
+** xref:extensions/keeping-state-in-extensions.adoc[]
+** xref:extensions/supported-utilities-in-extensions.adoc[]
+** xref:extensions/relative-execution-order-of-user-code-and-extensions.adoc[]

From 2a204f8bfc7363de2c9f09e284c37a5e6ef2bec8 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:14 +0100
Subject: [PATCH 31/57] Remove Advanced Topics include file

---
 .../docs/asciidoc/user-guide/advanced-topics.adoc    | 12 ------------
 1 file changed, 12 deletions(-)
 delete mode 100644 documentation/src/docs/asciidoc/user-guide/advanced-topics.adoc

diff --git a/documentation/src/docs/asciidoc/user-guide/advanced-topics.adoc b/documentation/src/docs/asciidoc/user-guide/advanced-topics.adoc
deleted file mode 100644
index ab7f4d11463a..000000000000
--- a/documentation/src/docs/asciidoc/user-guide/advanced-topics.adoc
+++ /dev/null
@@ -1,12 +0,0 @@
-[[advanced-topics]]
-== Advanced Topics
-
-include::advanced-topics/junit-platform-reporting.adoc[]
-
-include::advanced-topics/junit-platform-suite-engine.adoc[]
-
-include::advanced-topics/testkit.adoc[]
-
-include::advanced-topics/launcher-api.adoc[]
-
-include::advanced-topics/engines.adoc[]

From 679dd6239d4057ff3fa888485100388e657dc3af Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:14 +0100
Subject: [PATCH 32/57] Move junit-platform-reporting.adoc to Antora module

---
 .../ROOT/pages}/advanced-topics/junit-platform-reporting.adoc     | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT/pages}/advanced-topics/junit-platform-reporting.adoc (100%)

diff --git a/documentation/src/docs/asciidoc/user-guide/advanced-topics/junit-platform-reporting.adoc b/documentation/modules/ROOT/pages/advanced-topics/junit-platform-reporting.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/advanced-topics/junit-platform-reporting.adoc
rename to documentation/modules/ROOT/pages/advanced-topics/junit-platform-reporting.adoc

From 94421b69ab4cc4c391f8864863e42fa0d26a2ee9 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:14 +0100
Subject: [PATCH 33/57] Migrate junit-platform-reporting.adoc to Antora syntax

---
 .../advanced-topics/junit-platform-reporting.adoc | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/documentation/modules/ROOT/pages/advanced-topics/junit-platform-reporting.adoc b/documentation/modules/ROOT/pages/advanced-topics/junit-platform-reporting.adoc
index 10f7744f54b0..2c4d89c4b85a 100644
--- a/documentation/modules/ROOT/pages/advanced-topics/junit-platform-reporting.adoc
+++ b/documentation/modules/ROOT/pages/advanced-topics/junit-platform-reporting.adoc
@@ -1,5 +1,4 @@
-[[junit-platform-reporting]]
-=== JUnit Platform Reporting
+= JUnit Platform Reporting
 
 The `junit-platform-reporting` artifact contains `{TestExecutionListener}` implementations
 that generate XML test reports in two flavors:
@@ -10,7 +9,7 @@ NOTE: The module also contains other `TestExecutionListener` implementations tha
 used to build custom reporting. See <<running-tests-listeners>> for details.
 
 [[junit-platform-reporting-output-directory]]
-==== Output Directory
+== Output Directory
 
 The JUnit Platform provides an `{OutputDirectoryCreator}` via `{EngineDiscoveryRequest}`
 and `{TestPlan}` to registered <<test-engines, test engines>> and
@@ -29,7 +28,7 @@ Gradle's or Maven's parallel execution capabilities which create multiple JVM fo
 that run concurrently.
 
 [[junit-platform-reporting-open-test-reporting]]
-==== Open Test Reporting
+== Open Test Reporting
 
 `{OpenTestReportGeneratingListener}` writes an XML report for the entire execution in the
 event-based format specified by {OpenTestReporting} which supports all features of the
@@ -58,7 +57,7 @@ written to `System.out` and `System.err` will be included in the report as well.
 TIP: The {OpenTestReportingCliTool} can be used to convert from the event-based format to
 the hierarchical format which is more human-readable.
 
-===== Gradle
+=== Gradle
 
 For Gradle, writing Open Test Reporting compatible XML reports can be enabled and
 configured via system properties. The following samples configure its output directory to
@@ -102,7 +101,7 @@ tasks.withType<Test>().configureEach {
 }
 ----
 
-===== Maven
+=== Maven
 
 For Maven Surefire/Failsafe, you can enable Open Test Reporting output and configure the
 resulting XML files to be written to the same directory Surefire/Failsafe uses for its own
@@ -141,7 +140,7 @@ XML reports as follows:
 </project>
 ----
 
-===== Console Launcher
+=== Console Launcher
 
 When using the <<running-tests-console-launcher>>, you can enable Open Test Reporting
 output by setting the configuration parameters via `--config`:
@@ -163,7 +162,7 @@ $ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
 ----
 
 [[junit-platform-reporting-legacy-xml]]
-==== Legacy XML format
+== Legacy XML format
 
 `{LegacyXmlReportGeneratingListener}` generates a separate XML report for each root in the
 `{TestPlan}`. Note that the generated XML format is compatible with the de facto standard

From 1b25c9acb095e33cc05cf3e61872d2e43d7a6add Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:14 +0100
Subject: [PATCH 34/57] Move junit-platform-suite-engine.adoc to Antora module

---
 .../ROOT/pages}/advanced-topics/junit-platform-suite-engine.adoc  | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT/pages}/advanced-topics/junit-platform-suite-engine.adoc (100%)

diff --git a/documentation/src/docs/asciidoc/user-guide/advanced-topics/junit-platform-suite-engine.adoc b/documentation/modules/ROOT/pages/advanced-topics/junit-platform-suite-engine.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/advanced-topics/junit-platform-suite-engine.adoc
rename to documentation/modules/ROOT/pages/advanced-topics/junit-platform-suite-engine.adoc

From 1dc6ca42a0e28cadf9d80a6efe548fb623606f8f Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:15 +0100
Subject: [PATCH 35/57] Migrate junit-platform-suite-engine.adoc to Antora
 syntax

---
 .../junit-platform-suite-engine.adoc          | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/documentation/modules/ROOT/pages/advanced-topics/junit-platform-suite-engine.adoc b/documentation/modules/ROOT/pages/advanced-topics/junit-platform-suite-engine.adoc
index 57c1f80dfa5f..5262d1332bee 100644
--- a/documentation/modules/ROOT/pages/advanced-topics/junit-platform-suite-engine.adoc
+++ b/documentation/modules/ROOT/pages/advanced-topics/junit-platform-suite-engine.adoc
@@ -1,5 +1,4 @@
-[[junit-platform-suite-engine]]
-=== JUnit Platform Suite Engine
+= JUnit Platform Suite Engine
 
 The Suite Engine supports the declarative selection and execution of tests from _any_ test
 engine on the JUnit Platform using the <<launcher-api>>.
@@ -7,14 +6,14 @@ engine on the JUnit Platform using the <<launcher-api>>.
 image::junit-platform-suite-engine-diagram.svg[role=text-center]
 
 [[junit-platform-suite-engine-setup]]
-==== Setup
+== Setup
 
 In addition to the `junit-platform-suite-api` and `junit-platform-suite-engine` artifacts,
 you need _at least one_ other test engine and its dependencies on the classpath. See
 <<dependency-metadata>> for details regarding group IDs, artifact IDs, and versions.
 
 [[junit-platform-suite-engine-setup-required-dependencies]]
-===== Required Dependencies
+=== Required Dependencies
 
 * `junit-platform-suite-api` in _test_ scope: artifact containing annotations needed to
   configure a test suite
@@ -26,7 +25,7 @@ artifact which can be declared in _test_ scope instead of declaring explicit dep
 on `junit-platform-suite-api` and `junit-platform-suite-engine`.
 
 [[junit-platform-suite-engine-setup-transitive-dependencies]]
-===== Transitive Dependencies
+=== Transitive Dependencies
 
 * `junit-platform-launcher` in _test_ scope
 * `junit-platform-engine` in _test_ scope
@@ -34,7 +33,7 @@ on `junit-platform-suite-api` and `junit-platform-suite-engine`.
 * `opentest4j` in _test_ scope
 
 [[junit-platform-suite-engine-example]]
-==== @Suite Example
+== @Suite Example
 
 Annotate a class with `@Suite` to have it marked as a test suite on the JUnit Platform. As
 seen in the following example, selector and filter annotations can be used to control the
@@ -42,7 +41,7 @@ contents of the suite.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/SuiteDemo.java[tags=user_guide]
+include::example$java/example/SuiteDemo.java[tags=user_guide]
 ----
 
 .Additional Configuration Options
@@ -50,7 +49,7 @@ NOTE: There are numerous configuration options for discovering and filtering tes
 test suite. Please consult the Javadoc of the `{suite-api-package}` package for a full
 list of supported annotations and further details.
 
-==== @BeforeSuite and @AfterSuite
+== @BeforeSuite and @AfterSuite
 
 `@BeforeSuite` and `@AfterSuite` annotations can be used on methods inside a
 `@Suite`-annotated class. They will be executed before and after all tests of the test
@@ -58,11 +57,11 @@ suite, respectively.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/BeforeAndAfterSuiteDemo.java[tags=user_guide]
+include::example$java/example/BeforeAndAfterSuiteDemo.java[tags=user_guide]
 ----
 
 [[junit-platform-suite-engine-duplicate-test-execution]]
-==== Duplicate Test Execution
+== Duplicate Test Execution
 
 Depending on the declared selectors, different suites may contain the same tests,
 potentially with different configurations. Moreover, tests in a suite are executed in

From 1b09417560ed41cad8fdffb5bbd25295f451552c Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:15 +0100
Subject: [PATCH 36/57] Move testkit.adoc to Antora module

---
 .../ROOT/pages}/advanced-topics/testkit.adoc                      | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT/pages}/advanced-topics/testkit.adoc (100%)

diff --git a/documentation/src/docs/asciidoc/user-guide/advanced-topics/testkit.adoc b/documentation/modules/ROOT/pages/advanced-topics/testkit.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/advanced-topics/testkit.adoc
rename to documentation/modules/ROOT/pages/advanced-topics/testkit.adoc

From d81d53d442ef8cd544388292acc0d3bfd9a92ac8 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:15 +0100
Subject: [PATCH 37/57] Migrate testkit.adoc to Antora syntax

---
 .../ROOT/pages/advanced-topics/testkit.adoc   | 25 ++++++++-----------
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/documentation/modules/ROOT/pages/advanced-topics/testkit.adoc b/documentation/modules/ROOT/pages/advanced-topics/testkit.adoc
index b21678c3f38c..6910b8bea154 100644
--- a/documentation/modules/ROOT/pages/advanced-topics/testkit.adoc
+++ b/documentation/modules/ROOT/pages/advanced-topics/testkit.adoc
@@ -1,14 +1,11 @@
-:testDir: ../../../../../src/test/java
-
-[[testkit]]
-=== JUnit Platform Test Kit
+= JUnit Platform Test Kit
 
 The `junit-platform-testkit` artifact provides support for executing a test plan on the
 JUnit Platform and then verifying the expected results. This support is currently limited
 to the execution of a single `TestEngine` (see <<testkit-engine>>).
 
 [[testkit-engine]]
-==== Engine Test Kit
+== Engine Test Kit
 
 The `{testkit-engine-package}` package provides support for discovering and executing a
 `{TestPlan}` for a given `{TestEngine}` running on the JUnit Platform and then accessing
@@ -27,7 +24,7 @@ The following test class written using JUnit Jupiter will be used in subsequent
 [[testkit-engine-ExampleTestCase]]
 [source,java,indent=0]
 ----
-include::{testDir}/example/ExampleTestCase.java[tags=user_guide]
+include::example$java/example/ExampleTestCase.java[tags=user_guide]
 ----
 
 For the sake of brevity, the following sections demonstrate how to test JUnit's own
@@ -37,14 +34,14 @@ may test your own `TestEngine` by supplying an instance of it to the
 `EngineTestKit.engine(TestEngine)` static factory method.
 
 [[testkit-engine-discovery]]
-==== Verifying Test Discovery
+== Verifying Test Discovery
 
 The following test demonstrates how to verify that a `TestPlan` was discovered as expected
 by the JUnit Jupiter `TestEngine`.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/testkit/EngineTestKitDiscoveryDemo.java[tags=user_guide]
+include::example$java/example/testkit/EngineTestKitDiscoveryDemo.java[tags=user_guide]
 ----
 <1> Select the JUnit Jupiter `TestEngine`.
 <2> Select the <<testkit-engine-ExampleTestCase, `ExampleTestCase`>> test class.
@@ -53,7 +50,7 @@ include::{testDir}/example/testkit/EngineTestKitDiscoveryDemo.java[tags=user_gui
 <5> Assert no discovery issues were encountered.
 
 [[testkit-engine-statistics]]
-==== Asserting Execution Statistics
+== Asserting Execution Statistics
 
 One of the most common features of the Test Kit is the ability to assert statistics
 against events fired during the execution of a `TestPlan`. The following tests demonstrate
@@ -62,7 +59,7 @@ For details on what statistics are available, consult the Javadoc for `{EventSta
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/testkit/EngineTestKitStatisticsDemo.java[tags=user_guide]
+include::example$java/example/testkit/EngineTestKitStatisticsDemo.java[tags=user_guide]
 ----
 <1> Select the JUnit Jupiter `TestEngine`.
 <2> Select the <<testkit-engine-ExampleTestCase, `ExampleTestCase`>> test class.
@@ -77,7 +74,7 @@ NOTE: In the `verifyJupiterContainerStats()` test method, the counts for the `st
 <<testkit-engine-ExampleTestCase, `ExampleTestCase`>> class are both considered containers.
 
 [[testkit-engine-events]]
-==== Asserting Events
+== Asserting Events
 
 If you find that <<testkit-engine-statistics, asserting statistics>> alone is insufficient
 for verifying the expected behavior of test execution, you can work directly with the
@@ -99,7 +96,7 @@ events, consult the Javadoc for `{EventConditions}`.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/testkit/EngineTestKitSkippedMethodDemo.java[tags=user_guide]
+include::example$java/example/testkit/EngineTestKitSkippedMethodDemo.java[tags=user_guide]
 ----
 <1> Select the JUnit Jupiter `TestEngine`.
 <2> Select the `skippedTest()` method in the <<testkit-engine-ExampleTestCase,
@@ -123,7 +120,7 @@ events and execution results, consult the Javadoc for `{EventConditions}` and
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/testkit/EngineTestKitFailedMethodDemo.java[tags=user_guide]
+include::example$java/example/testkit/EngineTestKitFailedMethodDemo.java[tags=user_guide]
 ----
 <1> Select the JUnit Jupiter `TestEngine`.
 <2> Select the <<testkit-engine-ExampleTestCase, `ExampleTestCase`>> test class.
@@ -153,7 +150,7 @@ respectively.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/testkit/EngineTestKitAllEventsDemo.java[tags=user_guide]
+include::example$java/example/testkit/EngineTestKitAllEventsDemo.java[tags=user_guide]
 ----
 <1> Select the JUnit Jupiter `TestEngine`.
 <2> Select the <<testkit-engine-ExampleTestCase, `ExampleTestCase`>> test class.

From 16814761d8c79ff8daab325c14017ae7e381e1fb Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:16 +0100
Subject: [PATCH 38/57] Move launcher-api.adoc to Antora module

---
 .../ROOT/pages}/advanced-topics/launcher-api.adoc                 | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT/pages}/advanced-topics/launcher-api.adoc (100%)

diff --git a/documentation/src/docs/asciidoc/user-guide/advanced-topics/launcher-api.adoc b/documentation/modules/ROOT/pages/advanced-topics/launcher-api.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/advanced-topics/launcher-api.adoc
rename to documentation/modules/ROOT/pages/advanced-topics/launcher-api.adoc

From a19f51d1c862d7385176d96c9dd372fe115e0b35 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:16 +0100
Subject: [PATCH 39/57] Migrate launcher-api.adoc to Antora syntax

---
 .../pages/advanced-topics/launcher-api.adoc   | 66 +++++++++----------
 1 file changed, 31 insertions(+), 35 deletions(-)

diff --git a/documentation/modules/ROOT/pages/advanced-topics/launcher-api.adoc b/documentation/modules/ROOT/pages/advanced-topics/launcher-api.adoc
index 434761485d2a..ac57b65a254c 100644
--- a/documentation/modules/ROOT/pages/advanced-topics/launcher-api.adoc
+++ b/documentation/modules/ROOT/pages/advanced-topics/launcher-api.adoc
@@ -1,8 +1,4 @@
-:testDir: ../../../../../src/test/java
-:testResourcesDir: ../../../../../src/test/resources
-
-[[launcher-api]]
-=== JUnit Platform Launcher API
+= JUnit Platform Launcher API
 
 One of the prominent goals of the JUnit Platform is to make the interface between JUnit
 and its programmatic clients – build tools and IDEs – more powerful and stable. The
@@ -22,7 +18,7 @@ An example consumer of the launcher API is the `{ConsoleLauncher}` in the
 `{junit-platform-console}` project.
 
 [[launcher-api-discovery]]
-==== Discovering Tests
+== Discovering Tests
 
 Having _test discovery_ as a dedicated feature of the platform frees IDEs and build tools
 from most of the difficulties they had to go through to identify test classes and test
@@ -32,12 +28,12 @@ Usage Example:
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/UsingTheLauncherForDiscoveryDemo.java[tags=imports]
+include::example$java/example/UsingTheLauncherForDiscoveryDemo.java[tags=imports]
 ----
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/UsingTheLauncherForDiscoveryDemo.java[tags=discovery]
+include::example$java/example/UsingTheLauncherForDiscoveryDemo.java[tags=discovery]
 ----
 
 You can select classes, methods, and all classes in a package or even search for all tests
@@ -59,7 +55,7 @@ test discovery after the first discovery failure is encountered. The default
 parameter>>.
 
 [[launcher-api-execution]]
-==== Executing Tests
+== Executing Tests
 
 To execute tests, clients can use the same `LauncherDiscoveryRequest` as in the discovery
 phase or create a new request. Test progress and reporting can be achieved by registering
@@ -68,7 +64,7 @@ following example.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/UsingTheLauncherDemo.java[tags=execution]
+include::example$java/example/UsingTheLauncherDemo.java[tags=execution]
 ----
 
 There is no return value for the `execute()` method, but you can use a
@@ -82,13 +78,13 @@ reverse order.
 Test case execution won't start before all `executionStarted` calls have returned.
 
 [[launcher-api-engines-custom]]
-==== Registering a TestEngine
+== Registering a TestEngine
 
 See the dedicated section on <<test-engines-registration, TestEngine registration>> for
 details.
 
 [[launcher-api-post-discovery-filters-custom]]
-==== Registering a PostDiscoveryFilter
+== Registering a PostDiscoveryFilter
 
 In addition to specifying post-discovery filters as part of a `{LauncherDiscoveryRequest}`
 passed to the `{Launcher}` API, `{PostDiscoveryFilter}` implementations will be discovered
@@ -100,7 +96,7 @@ declared within the `/META-INF/services/org.junit.platform.launcher.PostDiscover
 file is loaded and applied automatically.
 
 [[launcher-api-launcher-session-listeners-custom]]
-==== Registering a LauncherSessionListener
+== Registering a LauncherSessionListener
 
 Registered implementations of `{LauncherSessionListener}` are notified when a
 `{LauncherSession}` is opened (before a `{Launcher}` first discovers and executes tests)
@@ -110,7 +106,7 @@ they can be discovered at runtime via Java's `{ServiceLoader}` mechanism and aut
 registered with `LauncherSession` (unless automatic registration is disabled.)
 
 [[launcher-api-launcher-session-listeners-tool-support]]
-===== Tool Support
+=== Tool Support
 
 The following build tools and IDEs are known to provide full support for `LauncherSession`:
 
@@ -121,7 +117,7 @@ The following build tools and IDEs are known to provide full support for `Launch
 Other tools might also work but have not been tested explicitly.
 
 [[launcher-api-launcher-session-listeners-tool-example-usage]]
-===== Example Usage
+=== Example Usage
 
 A `LauncherSessionListener` is well suited for implementing once-per-JVM setup/teardown
 behavior since it's called before the first and after the last test in a launcher session,
@@ -135,7 +131,7 @@ executed, could look like this:
 ----
 package example.session;
 
-include::{testDir}/example/session/GlobalSetupTeardownListener.java[tags=user_guide]
+include::example$java/example/session/GlobalSetupTeardownListener.java[tags=user_guide]
 ----
 <1> Get the store from the launcher session
 <2> Lazily create the HTTP server and put it into the store
@@ -149,7 +145,7 @@ closed:
 ----
 package example.session;
 
-include::{testDir}/example/session/CloseableHttpServer.java[tags=user_guide]
+include::example$java/example/session/CloseableHttpServer.java[tags=user_guide]
 ----
 <1> The `close()` method is called when the launcher session is closed
 <2> Stop the HTTP server
@@ -163,7 +159,7 @@ by adding the file to `src/test/resources`):
 [source]
 .src/test/resources/META-INF/services/org.junit.platform.launcher.LauncherSessionListener
 ----
-include::{testResourcesDir}/META-INF/services/org.junit.platform.launcher.LauncherSessionListener[]
+include::example$resources/META-INF/services/org.junit.platform.launcher.LauncherSessionListener[]
 ----
 
 You can now use the resource from your test:
@@ -173,7 +169,7 @@ You can now use the resource from your test:
 ----
 package example.session;
 
-include::{testDir}/example/session/HttpTests.java[tags=user_guide]
+include::example$java/example/session/HttpTests.java[tags=user_guide]
 ----
 <1> Retrieve the HTTP server instance from the store
 <2> Get the host string directly from the injected HTTP server instance
@@ -182,7 +178,7 @@ include::{testDir}/example/session/HttpTests.java[tags=user_guide]
 <5> Check the status code of the response
 
 [[launcher-api-launcher-interceptors-custom]]
-==== Registering a LauncherInterceptor
+== Registering a LauncherInterceptor
 
 In order to intercept the creation of instances of `{Launcher}` and
 `{LauncherSessionListener}` and calls to the `discover` and `execute` methods of the
@@ -206,11 +202,11 @@ the JUnit Platform to load test classes and engine implementations.
 
 [source,java]
 ----
-include::{testDir}/example/CustomLauncherInterceptor.java[tags=user_guide]
+include::example$java/example/CustomLauncherInterceptor.java[tags=user_guide]
 ----
 
 [[launcher-api-launcher-discovery-listeners-custom]]
-==== Registering a LauncherDiscoveryListener
+== Registering a LauncherDiscoveryListener
 
 In addition to specifying discovery listeners as part of a `{LauncherDiscoveryRequest}` or
 registering them programmatically via the `{Launcher}` API, custom
@@ -224,7 +220,7 @@ For example, an `example.CustomLauncherDiscoveryListener` class implementing
 and registered automatically.
 
 [[launcher-api-listeners-custom]]
-==== Registering a TestExecutionListener
+== Registering a TestExecutionListener
 
 In addition to the public `{Launcher}` API method for registering test execution listeners
 programmatically, custom `{TestExecutionListener}` implementations will be discovered at
@@ -237,7 +233,7 @@ For example, an `example.CustomTestExecutionListener` class implementing
 registered automatically.
 
 [[launcher-api-listeners-config]]
-==== Configuring a TestExecutionListener
+== Configuring a TestExecutionListener
 
 When a `{TestExecutionListener}` is registered programmatically via the `{Launcher}` API,
 the listener may provide programmatic ways for it to be configured -- for example, via its
@@ -251,7 +247,7 @@ listener can then access the configuration parameters via the `TestPlan` supplie
 methods. See the `{UniqueIdTrackingListener}` for an example.
 
 [[launcher-api-listeners-custom-deactivation]]
-==== Deactivating a TestExecutionListener
+== Deactivating a TestExecutionListener
 
 Sometimes it can be useful to run a test suite _without_ certain execution listeners being
 active. For example, you might have custom a `{TestExecutionListener}` that sends the test
@@ -276,12 +272,12 @@ supplied in the `LauncherDiscoveryRequest` that is passed to the `{Launcher}`.
 ====
 
 [[launcher-api-listeners-custom-deactivation-pattern]]
-===== Pattern Matching Syntax
+=== Pattern Matching Syntax
 
 Refer to <<running-tests-config-params-deactivation-pattern>> for details.
 
 [[launcher-api-launcher-config]]
-==== Configuring the Launcher
+== Configuring the Launcher
 
 If you require fine-grained control over automatic detection and registration of test
 engines and listeners, you may create an instance of `{LauncherConfig}` and supply that to
@@ -290,11 +286,11 @@ built-in fluent _builder_ API, as demonstrated in the following example.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/UsingTheLauncherDemo.java[tags=launcherConfig]
+include::example$java/example/UsingTheLauncherDemo.java[tags=launcherConfig]
 ----
 
 [[launcher-api-dry-run-mode]]
-==== Dry-Run Mode
+== Dry-Run Mode
 
 When running tests via the `{Launcher}` API, you can enable _dry-run mode_ by setting the
 `junit.platform.execution.dryRun.enabled` <<running-tests-config-params,
@@ -305,7 +301,7 @@ test changes in the configuration of a build or to verify a listener is called a
 without having to wait for all tests to be executed.
 
 [[launcher-api-managing-state-across-test-engines]]
-==== Managing State Across Test Engines
+== Managing State Across Test Engines
 
 When running tests on the JUnit Platform, multiple test engines may need to access shared
 resources. Rather than initializing these resources multiple times, JUnit Platform
@@ -324,7 +320,7 @@ global store or creates a new one if it doesn't exist:
 
 [source,java]
 ----
-include::{testDir}/example/FirstCustomEngine.java[tags=user_guide]
+include::example$java/example/FirstCustomEngine.java[tags=user_guide]
 ----
 
 `SecondCustomEngine` follows the same pattern, ensuring that regardless whether it runs
@@ -332,7 +328,7 @@ before or after `FirstCustomEngine`, it will use the same socket instance:
 
 [source,java]
 ----
-include::{testDir}/example/SecondCustomEngine.java[tags=user_guide]
+include::example$java/example/SecondCustomEngine.java[tags=user_guide]
 ----
 
 TIP: In this case, the `ServerSocket` can be stored directly in the global store while
@@ -346,7 +342,7 @@ For illustration, the following test verifies that both engines are sharing the
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/sharedresources/SharedResourceDemo.java[tags=user_guide]
+include::example$java/example/sharedresources/SharedResourceDemo.java[tags=user_guide]
 ----
 
 By using the Platform's `{NamespacedHierarchicalStore}` API with shared namespaces in this
@@ -357,7 +353,7 @@ Alternatively, it's possible to inject resources into test engines by
 <<launcher-api-launcher-session-listeners-custom, registering a `LauncherSessionListener`>>.
 
 [[launcher-api-launcher-cancellation]]
-==== Cancelling a Running Test Execution
+== Cancelling a Running Test Execution
 
 The launcher API provides the ability to cancel a running test execution mid-flight while
 allowing engines to clean up resources. To request an execution to be cancelled, you need
@@ -369,7 +365,7 @@ failed can be achieved as follows.
 
 [source,java,indent=0]
 ----
-include::{testDir}/example/UsingTheLauncherDemo.java[tags=cancellation]
+include::example$java/example/UsingTheLauncherDemo.java[tags=cancellation]
 ----
 <1> Create a `{CancellationToken}`
 <2> Implement a `{TestExecutionListener}` that calls `cancel()` when a test fails

From 42445c2ffac66d471514dcc9d4cd246635984935 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:16 +0100
Subject: [PATCH 40/57] Move engines.adoc to Antora module

---
 .../ROOT/pages}/advanced-topics/engines.adoc                      | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT/pages}/advanced-topics/engines.adoc (100%)

diff --git a/documentation/src/docs/asciidoc/user-guide/advanced-topics/engines.adoc b/documentation/modules/ROOT/pages/advanced-topics/engines.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/advanced-topics/engines.adoc
rename to documentation/modules/ROOT/pages/advanced-topics/engines.adoc

From c374131c129f9fbcf6af22c7ac995f72e6b1051a Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:17 +0100
Subject: [PATCH 41/57] Migrate engines.adoc to Antora syntax

---
 .../ROOT/pages/advanced-topics/engines.adoc     | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/documentation/modules/ROOT/pages/advanced-topics/engines.adoc b/documentation/modules/ROOT/pages/advanced-topics/engines.adoc
index 8876443f0461..181d19656165 100644
--- a/documentation/modules/ROOT/pages/advanced-topics/engines.adoc
+++ b/documentation/modules/ROOT/pages/advanced-topics/engines.adoc
@@ -1,5 +1,4 @@
-[[test-engines]]
-=== Test Engines
+= Test Engines
 
 A `TestEngine` facilitates _discovery_ and _execution_ of tests for a particular
 programming model.
@@ -8,7 +7,7 @@ For example, JUnit provides a `TestEngine` that discovers and executes tests wri
 the JUnit Jupiter programming model (see <<writing-tests>> and <<extensions>>).
 
 [[test-engines-junit]]
-==== JUnit Test Engines
+== JUnit Test Engines
 
 JUnit provides three `TestEngine` implementations.
 
@@ -19,7 +18,7 @@ JUnit provides three `TestEngine` implementations.
   Platform launcher infrastructure.
 
 [[test-engines-custom]]
-==== Custom Test Engines
+== Custom Test Engines
 
 You can contribute your own custom `{TestEngine}` by implementing the interfaces in the
 {junit-platform-engine} module and _registering_ your engine.
@@ -70,7 +69,7 @@ provide the logic for test discovery. It implements execution of `TestDescriptor
 implement the `Node` interface, including support for parallel execution.
 
 [[test-engines-registration]]
-==== Registering a TestEngine
+== Registering a TestEngine
 
 `TestEngine` registration is supported via Java's `{ServiceLoader}` mechanism.
 
@@ -80,14 +79,14 @@ For example, the `junit-jupiter-engine` module registers its
 `junit-jupiter-engine` JAR.
 
 [[test-engines-requirements]]
-==== Requirements
+== Requirements
 
 NOTE: The words "must", "must not", "required", "shall", "shall not", "should", "should
 not", "recommended",  "may", and "optional" in this section are to be interpreted as
 described in https://www.ietf.org/rfc/rfc2119.txt[RFC 2119.]
 
 [[test-engines-requirements-mandatory]]
-===== Mandatory requirements
+=== Mandatory requirements
 
 For interoperability with build tools and IDEs, `TestEngine` implementations must adhere
 to the following requirements:
@@ -108,7 +107,7 @@ to the following requirements:
   reported for its descendants.
 
 [[test-engines-requirements-enhanced-compatibility]]
-===== Enhanced compatibility
+=== Enhanced compatibility
 
 Adhering to the following requirements is optional but recommended for enhanced
 compatibility with build tools and IDEs:
@@ -131,7 +130,7 @@ compatibility with build tools and IDEs:
   that it has created just like if execution had finished regularly.
 
 [[test-engines-discovery-issues]]
-==== Reporting Discovery Issues
+== Reporting Discovery Issues
 
 Test engines should report <<running-tests-discovery-issues, discovery issues>> if they
 encounter any problems or potential misconfigurations during test discovery. This is

From 32c773fa74d6b99f1f164339835181bdbdbb1aeb Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:17 +0100
Subject: [PATCH 42/57] Add advanced topics to navigation

---
 documentation/modules/ROOT/nav.adoc | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/documentation/modules/ROOT/nav.adoc b/documentation/modules/ROOT/nav.adoc
index 4f6e26390b2b..1001902474f3 100644
--- a/documentation/modules/ROOT/nav.adoc
+++ b/documentation/modules/ROOT/nav.adoc
@@ -54,3 +54,9 @@
 ** xref:extensions/keeping-state-in-extensions.adoc[]
 ** xref:extensions/supported-utilities-in-extensions.adoc[]
 ** xref:extensions/relative-execution-order-of-user-code-and-extensions.adoc[]
+* Advanced Topics
+** xref:advanced-topics/junit-platform-reporting.adoc[]
+** xref:advanced-topics/junit-platform-suite-engine.adoc[]
+** xref:advanced-topics/testkit.adoc[]
+** xref:advanced-topics/launcher-api.adoc[]
+** xref:advanced-topics/engines.adoc[]

From 873bca39e0968f6e833c88826067c915acfa7029 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:17 +0100
Subject: [PATCH 43/57] Move api-evolution.adoc to Antora module

---
 .../asciidoc/user-guide => modules/ROOT/pages}/api-evolution.adoc | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT/pages}/api-evolution.adoc (100%)

diff --git a/documentation/src/docs/asciidoc/user-guide/api-evolution.adoc b/documentation/modules/ROOT/pages/api-evolution.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/api-evolution.adoc
rename to documentation/modules/ROOT/pages/api-evolution.adoc

From 218b471ec38d25bb3e6c0e7936afd75ddbe564da Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:17 +0100
Subject: [PATCH 44/57] Migrate api-evolution.adoc to Antora syntax

---
 documentation/modules/ROOT/pages/api-evolution.adoc | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/documentation/modules/ROOT/pages/api-evolution.adoc b/documentation/modules/ROOT/pages/api-evolution.adoc
index 601299666251..448c4aff5c2c 100644
--- a/documentation/modules/ROOT/pages/api-evolution.adoc
+++ b/documentation/modules/ROOT/pages/api-evolution.adoc
@@ -1,5 +1,5 @@
-[[api-evolution]]
-== API Evolution
+= API Evolution
+:page-toclevels: 1
 
 One of the major goals of the JUnit Platform architecture is to improve maintainers'
 capabilities to evolve JUnit despite its being used in many projects. With JUnit 4 a lot
@@ -11,7 +11,7 @@ That's why JUnit now uses a defined lifecycle for all publicly available interfa
 classes, and methods.
 
 [[api-evolution-version-and-status]]
-=== API Version and Status
+== API Version and Status
 
 Every published artifact has a version number `<major>.<minor>.<patch>`, and all publicly
 available interfaces, classes, and methods are annotated with {API} from the
@@ -39,7 +39,7 @@ public members of that type as well. A member is allowed to declare a different
 value of lower stability.
 
 [[api-evolution-experimental-apis]]
-=== Experimental APIs
+== Experimental APIs
 
 The following tables list which APIs are currently designated as _experimental_ via
 `@API(status = EXPERIMENTAL)`. Caution should be taken when relying on such APIs.
@@ -47,7 +47,7 @@ The following tables list which APIs are currently designated as _experimental_
 include::{experimentalApisTableFile}[]
 
 [[api-evolution-deprecated-apis]]
-=== Deprecated APIs
+== Deprecated APIs
 
 The following tables list which APIs are currently designated as _deprecated_ via
 `@API(status = DEPRECATED)`. You should avoid using deprecated APIs whenever possible,
@@ -56,7 +56,7 @@ since such APIs will likely be removed in an upcoming release.
 include::{deprecatedApisTableFile}[]
 
 [[api-evolution-tooling]]
-=== @API Tooling Support
+== @API Tooling Support
 
 The {API_Guardian} project plans to provide tooling support for publishers and consumers
 of APIs annotated with {API}. For example, the tooling support will likely provide a

From e37158d24a3b927bb4304754eb6a17f3f2ffda3b Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:18 +0100
Subject: [PATCH 45/57] Add api-evolution.adoc to navigation

---
 documentation/modules/ROOT/nav.adoc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/documentation/modules/ROOT/nav.adoc b/documentation/modules/ROOT/nav.adoc
index 1001902474f3..947ca70d2a18 100644
--- a/documentation/modules/ROOT/nav.adoc
+++ b/documentation/modules/ROOT/nav.adoc
@@ -60,3 +60,4 @@
 ** xref:advanced-topics/testkit.adoc[]
 ** xref:advanced-topics/launcher-api.adoc[]
 ** xref:advanced-topics/engines.adoc[]
+* xref:api-evolution.adoc[]

From 4a103997b009c054fcb3b6eebefefd56e2176c79 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:18 +0100
Subject: [PATCH 46/57] Remove Contributors link to GitHub

---
 documentation/src/docs/asciidoc/user-guide/contributors.adoc | 4 ----
 1 file changed, 4 deletions(-)
 delete mode 100644 documentation/src/docs/asciidoc/user-guide/contributors.adoc

diff --git a/documentation/src/docs/asciidoc/user-guide/contributors.adoc b/documentation/src/docs/asciidoc/user-guide/contributors.adoc
deleted file mode 100644
index 00911583c4d3..000000000000
--- a/documentation/src/docs/asciidoc/user-guide/contributors.adoc
+++ /dev/null
@@ -1,4 +0,0 @@
-[[contributors]]
-== Contributors
-
-Browse the {junit-framework-repo}/graphs/contributors[current list of contributors] directly on GitHub.

From e1959322a2286f664fcdaedbcaebc06e64e0d8f6 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:18 +0100
Subject: [PATCH 47/57] Move release-notes.adoc to Antora module

---
 .../index.adoc => modules/ROOT/pages/release-notes.adoc}          | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename documentation/{src/docs/asciidoc/release-notes/index.adoc => modules/ROOT/pages/release-notes.adoc} (100%)

diff --git a/documentation/src/docs/asciidoc/release-notes/index.adoc b/documentation/modules/ROOT/pages/release-notes.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/release-notes/index.adoc
rename to documentation/modules/ROOT/pages/release-notes.adoc

From 7ec05312c383cada75103bd8100af2768d082436 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:19 +0100
Subject: [PATCH 48/57] Migrate release-notes.adoc to Antora syntax

---
 .../modules/ROOT/pages/release-notes.adoc     | 22 ++++++-------------
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/documentation/modules/ROOT/pages/release-notes.adoc b/documentation/modules/ROOT/pages/release-notes.adoc
index c7f8737025c6..d1577a11de8a 100644
--- a/documentation/modules/ROOT/pages/release-notes.adoc
+++ b/documentation/modules/ROOT/pages/release-notes.adoc
@@ -1,12 +1,6 @@
-[[release-notes]]
-= JUnit Release Notes
-Stefan Bechtold; Sam Brannen; Johannes Link; Matthias Merdes; Marc Philipp; Juliette de Rancourt; Christian Stein
+= Release Notes
+:page-aliases: release-notes/index.adoc
 //
-:basedir: {includedir}/release-notes
-:docinfodir: {includedir}/docinfos
-:docinfo2:
-:numbered!:
-:last-update-label!:
 //
 
 This document contains the change log for all JUnit releases since 6.0 GA.
@@ -15,14 +9,12 @@ Please refer to the <<../user-guide/index.adoc#user-guide,User Guide>> for compr
 reference documentation for programmers writing tests, extension authors, and engine
 authors as well as build tool and IDE vendors.
 
-include::{includedir}/link-attributes.adoc[]
+include::partial$release-notes/release-notes-6.1.0-M2.adoc[]
 
-include::{basedir}/release-notes-6.1.0-M2.adoc[]
+include::partial$release-notes/release-notes-6.1.0-M1.adoc[]
 
-include::{basedir}/release-notes-6.1.0-M1.adoc[]
+include::partial$release-notes/release-notes-6.0.2.adoc[]
 
-include::{basedir}/release-notes-6.0.2.adoc[]
+include::partial$release-notes/release-notes-6.0.1.adoc[]
 
-include::{basedir}/release-notes-6.0.1.adoc[]
-
-include::{basedir}/release-notes-6.0.0.adoc[]
+include::partial$release-notes/release-notes-6.0.0.adoc[]

From 4183ffb88c8d7bc07742961f06eca7a14bfb83bb Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:19 +0100
Subject: [PATCH 49/57] Add release-notes.adoc to navigation

---
 documentation/modules/ROOT/nav.adoc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/documentation/modules/ROOT/nav.adoc b/documentation/modules/ROOT/nav.adoc
index 947ca70d2a18..f94938523cb5 100644
--- a/documentation/modules/ROOT/nav.adoc
+++ b/documentation/modules/ROOT/nav.adoc
@@ -61,3 +61,4 @@
 ** xref:advanced-topics/launcher-api.adoc[]
 ** xref:advanced-topics/engines.adoc[]
 * xref:api-evolution.adoc[]
+* xref:release-notes.adoc[]

From 057bb1b1b541785bebf7d0d2d4bf60941204428e Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:19 +0100
Subject: [PATCH 50/57] Move individual release note files to Antora module

---
 .../ROOT/partials}/release-notes/release-notes-6.0.0.adoc         | 0
 .../ROOT/partials}/release-notes/release-notes-6.0.1.adoc         | 0
 .../ROOT/partials}/release-notes/release-notes-6.0.2.adoc         | 0
 .../ROOT/partials}/release-notes/release-notes-6.1.0-M1.adoc      | 0
 .../ROOT/partials}/release-notes/release-notes-6.1.0-M2.adoc      | 0
 5 files changed, 0 insertions(+), 0 deletions(-)
 rename documentation/{src/docs/asciidoc => modules/ROOT/partials}/release-notes/release-notes-6.0.0.adoc (100%)
 rename documentation/{src/docs/asciidoc => modules/ROOT/partials}/release-notes/release-notes-6.0.1.adoc (100%)
 rename documentation/{src/docs/asciidoc => modules/ROOT/partials}/release-notes/release-notes-6.0.2.adoc (100%)
 rename documentation/{src/docs/asciidoc => modules/ROOT/partials}/release-notes/release-notes-6.1.0-M1.adoc (100%)
 rename documentation/{src/docs/asciidoc => modules/ROOT/partials}/release-notes/release-notes-6.1.0-M2.adoc (100%)

diff --git a/documentation/src/docs/asciidoc/release-notes/release-notes-6.0.0.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.0.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/release-notes/release-notes-6.0.0.adoc
rename to documentation/modules/ROOT/partials/release-notes/release-notes-6.0.0.adoc
diff --git a/documentation/src/docs/asciidoc/release-notes/release-notes-6.0.1.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.1.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/release-notes/release-notes-6.0.1.adoc
rename to documentation/modules/ROOT/partials/release-notes/release-notes-6.0.1.adoc
diff --git a/documentation/src/docs/asciidoc/release-notes/release-notes-6.0.2.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.2.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/release-notes/release-notes-6.0.2.adoc
rename to documentation/modules/ROOT/partials/release-notes/release-notes-6.0.2.adoc
diff --git a/documentation/src/docs/asciidoc/release-notes/release-notes-6.1.0-M1.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M1.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/release-notes/release-notes-6.1.0-M1.adoc
rename to documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M1.adoc
diff --git a/documentation/src/docs/asciidoc/release-notes/release-notes-6.1.0-M2.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M2.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/release-notes/release-notes-6.1.0-M2.adoc
rename to documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M2.adoc

From eee25cad4a8eb9018698547e1fa67097bfe06171 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:20 +0100
Subject: [PATCH 51/57] Move release-notes-TEMPLATE.adoc to Antora module

---
 .../ROOT/partials}/release-notes/release-notes-TEMPLATE.adoc      | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename documentation/{src/docs/asciidoc => modules/ROOT/partials}/release-notes/release-notes-TEMPLATE.adoc (100%)

diff --git a/documentation/src/docs/asciidoc/release-notes/release-notes-TEMPLATE.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-TEMPLATE.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/release-notes/release-notes-TEMPLATE.adoc
rename to documentation/modules/ROOT/partials/release-notes/release-notes-TEMPLATE.adoc

From 2b25d542442e6a63977dc5ba89bf67444fa87577 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:20 +0100
Subject: [PATCH 52/57] Migrate release-notes-TEMPLATE.adoc to Antora syntax

---
 .../ROOT/partials/release-notes/release-notes-TEMPLATE.adoc     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/modules/ROOT/partials/release-notes/release-notes-TEMPLATE.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-TEMPLATE.adoc
index 5bd352c3c008..3861188d538e 100644
--- a/documentation/modules/ROOT/partials/release-notes/release-notes-TEMPLATE.adoc
+++ b/documentation/modules/ROOT/partials/release-notes/release-notes-TEMPLATE.adoc
@@ -10,7 +10,7 @@
 //    which you can determine via https://github.com/junit-team/junit-framework/milestones/.
 //    If a GitHub milestone does not yet exist for the given VERSION, you will need to
 //    create a new GitHub milestone or ask a member of the JUnit team to create it for you.
-// 5) 'include:' this new file in index.adoc.
+// 5) 'include:' this new file in ../../pages/release-notes.adoc.
 // 6) Delete this entire comment block.
 //
 [[release-notes-VERSION]]

From c1ef601f7150997a28c914b6b8af657287fe7b37 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:20 +0100
Subject: [PATCH 53/57] Move appendix.adoc to Antora module

---
 .../docs/asciidoc/user-guide => modules/ROOT/pages}/appendix.adoc | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename documentation/{src/docs/asciidoc/user-guide => modules/ROOT/pages}/appendix.adoc (100%)

diff --git a/documentation/src/docs/asciidoc/user-guide/appendix.adoc b/documentation/modules/ROOT/pages/appendix.adoc
similarity index 100%
rename from documentation/src/docs/asciidoc/user-guide/appendix.adoc
rename to documentation/modules/ROOT/pages/appendix.adoc

From 2fb0b440fe58573b8f9ad8093dcc34178f36272e Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:21 +0100
Subject: [PATCH 54/57] Migrate appendix.adoc to Antora syntax

---
 .../modules/ROOT/pages/appendix.adoc          | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/documentation/modules/ROOT/pages/appendix.adoc b/documentation/modules/ROOT/pages/appendix.adoc
index ea11c07b7dea..50139eca50c9 100644
--- a/documentation/modules/ROOT/pages/appendix.adoc
+++ b/documentation/modules/ROOT/pages/appendix.adoc
@@ -1,8 +1,7 @@
-[[appendix]]
-== Appendix
+= Appendix
 
 [[reproducible-builds]]
-=== Reproducible Builds
+== Reproducible Builds
 
 JUnit aims for its non-javadoc JARs to be https://reproducible-builds.org/[reproducible].
 
@@ -14,7 +13,7 @@ Central/Sonatype and produce the same output artifact locally, confirming that t
 artifacts in the repositories were actually generated from this source code.
 
 [[dependency-metadata]]
-=== Dependency Metadata
+== Dependency Metadata
 
 Artifacts for final releases and milestones are deployed to {Maven_Central}. Consult
 https://central.sonatype.org/consume/[Sonatype's documentation] for how to consume those
@@ -46,7 +45,7 @@ Please refer to the corresponding sections for <<running-tests-build-maven-bom,
 ====
 
 [[dependency-metadata-junit-platform]]
-==== JUnit Platform
+=== JUnit Platform
 
 * *Group ID*: `org.junit.platform`
 * *Version*: `{version}`
@@ -85,7 +84,7 @@ Please refer to the corresponding sections for <<running-tests-build-maven-bom,
      accessing the results via a fluent API to verify the expected results.
 
 [[dependency-metadata-junit-jupiter]]
-==== JUnit Jupiter
+=== JUnit Jupiter
 
 * *Group ID*: `org.junit.jupiter`
 * *Version*: `{version}`
@@ -105,7 +104,7 @@ Please refer to the corresponding sections for <<running-tests-build-maven-bom,
     support for JUnit 4's `@Ignore` annotation and for running selected JUnit 4 rules.
 
 [[dependency-metadata-junit-vintage]]
-==== JUnit Vintage
+=== JUnit Vintage
 
 * *Group ID*: `org.junit.vintage`
 * *Version*: `{version}`
@@ -116,7 +115,7 @@ Please refer to the corresponding sections for <<running-tests-build-maven-bom,
     APIs or tests written using testing frameworks built on those APIs.
 
 [[dependency-metadata-junit-bom]]
-==== Bill of Materials (BOM)
+=== Bill of Materials (BOM)
 
 The _Bill of Materials_ POM provided under the following Maven coordinates can be used to
 ease dependency management when referencing multiple of the above artifacts using
@@ -128,7 +127,7 @@ or https://docs.gradle.org/current/userguide/platforms.html#sub:bom_import[Gradl
 * *Version*: `{version}`
 
 [[dependency-metadata-dependencies]]
-==== Dependencies
+=== Dependencies
 
 Most of the above artifacts have a dependency in their published Maven POMs on the
 following _@API Guardian_ JAR.
@@ -145,6 +144,6 @@ following _OpenTest4J_ JAR.
 * *Version*: `{ota4j-version}`
 
 [[dependency-diagram]]
-=== Dependency Diagram
+== Dependency Diagram
 
 image::component-diagram.svg[]

From 78740510205f55e751e72a898fdbedbcdc45b172 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:21 +0100
Subject: [PATCH 55/57] Add appendix.adoc to navigation

---
 documentation/modules/ROOT/nav.adoc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/documentation/modules/ROOT/nav.adoc b/documentation/modules/ROOT/nav.adoc
index f94938523cb5..568e8e4dc25a 100644
--- a/documentation/modules/ROOT/nav.adoc
+++ b/documentation/modules/ROOT/nav.adoc
@@ -62,3 +62,4 @@
 ** xref:advanced-topics/engines.adoc[]
 * xref:api-evolution.adoc[]
 * xref:release-notes.adoc[]
+* xref:appendix.adoc[]

From a8eb0db298d568ea9de940fe3697812d0c679cc9 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:22 +0100
Subject: [PATCH 56/57] Fix links

---
 .../ROOT/pages/advanced-topics/engines.adoc   |  30 ++---
 .../junit-platform-reporting.adoc             |  28 ++---
 .../junit-platform-suite-engine.adoc          |  16 +--
 .../pages/advanced-topics/launcher-api.adoc   |  64 +++++-----
 .../ROOT/pages/advanced-topics/testkit.adoc   |  33 +++--
 .../modules/ROOT/pages/api-evolution.adoc     |  12 +-
 .../modules/ROOT/pages/appendix.adoc          |  24 ++--
 .../conditional-test-execution.adoc           |   8 +-
 .../extensions/intercepting-invocations.adoc  |   2 +-
 .../keeping-state-in-extensions.adoc          |  10 +-
 .../extensions/parameter-resolution.adoc      |  12 +-
 .../extensions/pre-interrupt-callback.adoc    |   2 +-
 ...vocation-contexts-for-class-templates.adoc |   2 +-
 ...nvocation-contexts-for-test-templates.adoc |   4 +-
 .../extensions/registering-extensions.adoc    |  60 +++++----
 ...ion-order-of-user-code-and-extensions.adoc |  20 +--
 .../supported-utilities-in-extensions.adoc    |  16 +--
 .../extensions/test-instance-factories.adoc   |   2 +-
 .../test-instance-post-processing.adoc        |   2 +-
 .../test-instance-pre-construct-callback.adoc |   2 +-
 .../extensions/test-lifecycle-callbacks.adoc  |   8 +-
 .../extensions/test-result-processing.adoc    |   4 +-
 .../ROOT/pages/migrating-from-junit4.adoc     |  54 ++++----
 .../modules/ROOT/pages/overview.adoc          |  50 ++++----
 .../modules/ROOT/pages/release-notes.adoc     |   2 +-
 .../pages/running-tests/build-support.adoc    |  52 ++++----
 .../capturing-standard-output-error.adoc      |   6 +-
 .../configuration-parameters.adoc             |  28 ++---
 .../pages/running-tests/console-launcher.adoc |  26 ++--
 .../pages/running-tests/discovery-issues.adoc |   4 +-
 .../running-tests/discovery-selectors.adoc    |   2 +-
 .../ROOT/pages/running-tests/ide-support.adoc |  12 +-
 .../ROOT/pages/running-tests/tags.adoc        |   8 +-
 .../using-listeners-and-interceptors.adoc     |  24 ++--
 .../ROOT/pages/writing-tests/annotations.adoc |  54 ++++----
 .../ROOT/pages/writing-tests/assertions.adoc  |   6 +-
 .../writing-tests/built-in-extensions.adoc    |  19 ++-
 .../pages/writing-tests/class-templates.adoc  |   4 +-
 .../conditional-test-execution.adoc           |  26 ++--
 .../ROOT/pages/writing-tests/definitions.adoc |   3 +-
 ...njection-for-constructors-and-methods.adoc |   6 +-
 .../pages/writing-tests/disabling-tests.adoc  |   3 +-
 .../pages/writing-tests/display-names.adoc    |  10 +-
 .../pages/writing-tests/dynamic-tests.adoc    |  12 +-
 .../writing-tests/exception-handling.adoc     |  20 +--
 .../pages/writing-tests/nested-tests.adoc     |   4 +-
 .../writing-tests/parallel-execution.adoc     |  24 ++--
 .../parameterized-classes-and-tests.adoc      | 118 +++++++++---------
 .../pages/writing-tests/repeated-tests.adoc   |   4 +-
 .../writing-tests/tagging-and-filtering.adoc  |   6 +-
 .../test-classes-and-methods.adoc             |   8 +-
 .../writing-tests/test-execution-order.adoc   |  25 ++--
 .../test-instance-lifecycle.adoc              |   8 +-
 .../test-interfaces-and-default-methods.adoc  |   6 +-
 .../pages/writing-tests/test-templates.adoc   |   6 +-
 .../ROOT/pages/writing-tests/timeouts.adoc    |  22 ++--
 .../release-notes/release-notes-6.0.0.adoc    |   2 +-
 .../release-notes/release-notes-6.0.1.adoc    |  20 +--
 .../release-notes/release-notes-6.0.2.adoc    |  26 ++--
 .../release-notes/release-notes-6.1.0-M1.adoc |  18 +--
 .../release-notes/release-notes-6.1.0-M2.adoc |  28 ++---
 .../release-notes/release-notes-TEMPLATE.adoc |  26 ++--
 62 files changed, 567 insertions(+), 576 deletions(-)

diff --git a/documentation/modules/ROOT/pages/advanced-topics/engines.adoc b/documentation/modules/ROOT/pages/advanced-topics/engines.adoc
index 181d19656165..c11272db9fd4 100644
--- a/documentation/modules/ROOT/pages/advanced-topics/engines.adoc
+++ b/documentation/modules/ROOT/pages/advanced-topics/engines.adoc
@@ -4,9 +4,9 @@ A `TestEngine` facilitates _discovery_ and _execution_ of tests for a particular
 programming model.
 
 For example, JUnit provides a `TestEngine` that discovers and executes tests written using
-the JUnit Jupiter programming model (see <<writing-tests>> and <<extensions>>).
+the JUnit Jupiter programming model (see xref:writing-tests/intro.adoc[] and xref:extensions/overview.adoc[]).
 
-[[test-engines-junit]]
+[[junit]]
 == JUnit Test Engines
 
 JUnit provides three `TestEngine` implementations.
@@ -17,7 +17,7 @@ JUnit provides three `TestEngine` implementations.
 * `{junit-platform-suite-engine}`: Executes declarative suites of tests with the JUnit
   Platform launcher infrastructure.
 
-[[test-engines-custom]]
+[[custom]]
 == Custom Test Engines
 
 You can contribute your own custom `{TestEngine}` by implementing the interfaces in the
@@ -45,7 +45,7 @@ annotation. For example, the `@Test` and `@TestFactory` annotations in JUnit Jup
 meta-annotated with `@Testable`. Consult the Javadoc for `{Testable}` for further details.
 
 If your custom `TestEngine` needs to be configured, consider allowing users to supply
-configuration via <<running-tests-config-params,configuration parameters>>. Please note,
+configuration via xref:running-tests/configuration-parameters.adoc[configuration parameters]. Please note,
 however, that you are strongly encouraged to use a unique prefix for all configuration
 parameters supported by your test engine. Doing so will ensure that there are no conflicts
 between the names of your configuration parameters and those from other test engines. In
@@ -57,7 +57,7 @@ parameters. Furthermore, as with the warning above regarding the `junit-` prefix
 configuration parameters.
 
 Although there is currently no official guide on how to implement a custom `TestEngine`,
-you can consult the implementation of <<test-engines-junit>> or the implementation of
+you can consult the implementation of <<junit>> or the implementation of
 third-party test engines listed in the
 https://github.com/junit-team/junit-framework/wiki/Third-party-Extensions#junit-platform-test-engines[JUnit wiki].
 You will also find various tutorials and blogs on the Internet that demonstrate how to
@@ -68,7 +68,7 @@ NOTE: `{HierarchicalTestEngine}` is a convenient abstract base implementation of
 provide the logic for test discovery. It implements execution of `TestDescriptors` that
 implement the `Node` interface, including support for parallel execution.
 
-[[test-engines-registration]]
+[[registration]]
 == Registering a TestEngine
 
 `TestEngine` registration is supported via Java's `{ServiceLoader}` mechanism.
@@ -78,14 +78,14 @@ For example, the `junit-jupiter-engine` module registers its
 `org.junit.platform.engine.TestEngine` within the `/META-INF/services` folder in the
 `junit-jupiter-engine` JAR.
 
-[[test-engines-requirements]]
+[[requirements]]
 == Requirements
 
 NOTE: The words "must", "must not", "required", "shall", "shall not", "should", "should
 not", "recommended",  "may", and "optional" in this section are to be interpreted as
 described in https://www.ietf.org/rfc/rfc2119.txt[RFC 2119.]
 
-[[test-engines-requirements-mandatory]]
+[[requirements-mandatory]]
 === Mandatory requirements
 
 For interoperability with build tools and IDEs, `TestEngine` implementations must adhere
@@ -106,7 +106,7 @@ to the following requirements:
   after their children. If a node is reported as skipped, there _must not_ be any events
   reported for its descendants.
 
-[[test-engines-requirements-enhanced-compatibility]]
+[[requirements-enhanced-compatibility]]
 === Enhanced compatibility
 
 Adhering to the following requirements is optional but recommended for enhanced
@@ -119,9 +119,9 @@ compatibility with build tools and IDEs:
 * When resolving `UniqueIdSelectors`, a `TestEngine` _should_ only return `TestDescriptor`
   instances with matching unique IDs including their ancestors but _may_ return additional
   siblings or other nodes that are required for the execution of the selected tests.
-* `TestEngines` _should_ support <<running-tests-tags, tagging>> tests and containers so
+* `TestEngines` _should_ support xref:running-tests/tags.adoc[tagging] tests and containers so
   that tag filters can be applied when discovering tests.
-* [[test-engines-requirements-cancellation]] A `TestEngine` _should_ cancel its execution
+* [[requirements-cancellation]] A `TestEngine` _should_ cancel its execution
   when the `{CancellationToken}` it is passed as part of the `ExecutionRequest` indicates
   that cancellation has been requested. In this case, it _should_ report any remaining
   `TestDescriptors` as skipped but not report any events for their descendants. It _may_
@@ -129,10 +129,10 @@ compatibility with build tools and IDEs:
   completely. If a `TestEngine` supports cancellation, it should clean up any resources
   that it has created just like if execution had finished regularly.
 
-[[test-engines-discovery-issues]]
+[[discovery-issues]]
 == Reporting Discovery Issues
 
-Test engines should report <<running-tests-discovery-issues, discovery issues>> if they
+Test engines should report xref:running-tests/discovery-issues.adoc[discovery issues] if they
 encounter any problems or potential misconfigurations during test discovery. This is
 especially important if the issue could lead to tests not being executed at all or only
 partially.
@@ -143,7 +143,7 @@ In order to report a `{DiscoveryIssue}`, a test engine should call the
 listener around, the `{DiscoveryIssueReporter}` interface should be used. It also provides
 a way to create a `Condition` that reports a discovery issue if its check fails and may
 be used as a `Predicate` or `Consumer`. Please refer to the implementations of the
-<<test-engines-junit, test engines provided by JUnit>> for examples.
+<<junit, test engines provided by JUnit>> for examples.
 
-Moreover, <<testkit-engine-discovery, Engine Test Kit>> provides a way to write tests for
+Moreover, xref:advanced-topics/testkit.adoc#engine-discovery[Engine Test Kit] provides a way to write tests for
 reported discovery issues.
diff --git a/documentation/modules/ROOT/pages/advanced-topics/junit-platform-reporting.adoc b/documentation/modules/ROOT/pages/advanced-topics/junit-platform-reporting.adoc
index 2c4d89c4b85a..fe74bef80896 100644
--- a/documentation/modules/ROOT/pages/advanced-topics/junit-platform-reporting.adoc
+++ b/documentation/modules/ROOT/pages/advanced-topics/junit-platform-reporting.adoc
@@ -2,19 +2,19 @@
 
 The `junit-platform-reporting` artifact contains `{TestExecutionListener}` implementations
 that generate XML test reports in two flavors:
-<<junit-platform-reporting-open-test-reporting, Open Test Reporting>> and
-<<junit-platform-reporting-legacy-xml, legacy>>.
+<<open-test-reporting, Open Test Reporting>> and
+<<legacy-xml, legacy>>.
 
 NOTE: The module also contains other `TestExecutionListener` implementations that can be
-used to build custom reporting. See <<running-tests-listeners>> for details.
+used to build custom reporting. See xref:running-tests/using-listeners-and-interceptors.adoc[] for details.
 
-[[junit-platform-reporting-output-directory]]
+[[output-directory]]
 == Output Directory
 
 The JUnit Platform provides an `{OutputDirectoryCreator}` via `{EngineDiscoveryRequest}`
-and `{TestPlan}` to registered <<test-engines, test engines>> and
-<<running-tests-listeners, listeners>>, respectively. Its root directory can be configured
-via the following <<running-tests-config-params, configuration parameter>>:
+and `{TestPlan}` to registered xref:advanced-topics/engines.adoc[test engines] and
+xref:running-tests/using-listeners-and-interceptors.adoc[listeners], respectively. Its root directory can be configured
+via the following xref:running-tests/configuration-parameters.adoc[configuration parameter]:
 
 `junit.platform.reporting.output.dir=<path>`::
   Configure the output directory for reporting. By default, `build` is used if a Gradle
@@ -27,7 +27,7 @@ directories like `reports/junit-8803697269315188212`. This can be useful when us
 Gradle's or Maven's parallel execution capabilities which create multiple JVM forks
 that run concurrently.
 
-[[junit-platform-reporting-open-test-reporting]]
+[[open-test-reporting]]
 == Open Test Reporting
 
 `{OpenTestReportGeneratingListener}` writes an XML report for the entire execution in the
@@ -35,7 +35,7 @@ event-based format specified by {OpenTestReporting} which supports all features
 JUnit Platform such as hierarchical test structures, display names, tags, etc.
 
 The listener is auto-registered and can be configured via the following
-<<running-tests-config-params, configuration parameters>>:
+xref:running-tests/configuration-parameters.adoc[configuration parameters]:
 
 `junit.platform.reporting.open.xml.enabled=true|false`::
   Enable/disable writing the report; defaults to `false`.
@@ -47,11 +47,11 @@ The listener is auto-registered and can be configured via the following
   connection is automatically closed when the test execution completes.
 
 If enabled, the listener creates an XML report file named `open-test-report.xml` in the
-configured <<junit-platform-reporting-output-directory, output directory>>, unless the
+configured <<output-directory, output directory>>, unless the
 `junit.platform.reporting.open.xml.socket` configuration parameter is set, in which case the
 events are sent to the specified socket instead.
 
-If <<running-tests-capturing-output, output capturing>> is enabled, the captured output
+If xref:running-tests/capturing-standard-output-error.adoc[output capturing] is enabled, the captured output
 written to `System.out` and `System.err` will be included in the report as well.
 
 TIP: The {OpenTestReportingCliTool} can be used to convert from the event-based format to
@@ -142,7 +142,7 @@ XML reports as follows:
 
 === Console Launcher
 
-When using the <<running-tests-console-launcher>>, you can enable Open Test Reporting
+When using the xref:running-tests/console-launcher.adoc[], you can enable Open Test Reporting
 output by setting the configuration parameters via `--config`:
 
 [source,console,subs=attributes+]
@@ -161,12 +161,12 @@ $ java -jar junit-platform-console-standalone-{version}.jar <OPTIONS> \
   --config-resource=configuration.properties
 ----
 
-[[junit-platform-reporting-legacy-xml]]
+[[legacy-xml]]
 == Legacy XML format
 
 `{LegacyXmlReportGeneratingListener}` generates a separate XML report for each root in the
 `{TestPlan}`. Note that the generated XML format is compatible with the de facto standard
 for JUnit 4 based test reports that was made popular by the Ant build system.
 
-The `LegacyXmlReportGeneratingListener` is used by the <<running-tests-console-launcher>>
+The `LegacyXmlReportGeneratingListener` is used by the xref:running-tests/console-launcher.adoc[]
 as well.
diff --git a/documentation/modules/ROOT/pages/advanced-topics/junit-platform-suite-engine.adoc b/documentation/modules/ROOT/pages/advanced-topics/junit-platform-suite-engine.adoc
index 5262d1332bee..8466f1fa2c62 100644
--- a/documentation/modules/ROOT/pages/advanced-topics/junit-platform-suite-engine.adoc
+++ b/documentation/modules/ROOT/pages/advanced-topics/junit-platform-suite-engine.adoc
@@ -1,18 +1,18 @@
 = JUnit Platform Suite Engine
 
 The Suite Engine supports the declarative selection and execution of tests from _any_ test
-engine on the JUnit Platform using the <<launcher-api>>.
+engine on the JUnit Platform using the xref:advanced-topics/launcher-api.adoc[].
 
 image::junit-platform-suite-engine-diagram.svg[role=text-center]
 
-[[junit-platform-suite-engine-setup]]
+[[setup]]
 == Setup
 
 In addition to the `junit-platform-suite-api` and `junit-platform-suite-engine` artifacts,
 you need _at least one_ other test engine and its dependencies on the classpath. See
-<<dependency-metadata>> for details regarding group IDs, artifact IDs, and versions.
+xref:appendix.adoc#dependency-metadata[Dependency Metadata] for details regarding group IDs, artifact IDs, and versions.
 
-[[junit-platform-suite-engine-setup-required-dependencies]]
+[[setup-required-dependencies]]
 === Required Dependencies
 
 * `junit-platform-suite-api` in _test_ scope: artifact containing annotations needed to
@@ -24,7 +24,7 @@ NOTE: Both of the required dependencies are aggregated in the `junit-platform-su
 artifact which can be declared in _test_ scope instead of declaring explicit dependencies
 on `junit-platform-suite-api` and `junit-platform-suite-engine`.
 
-[[junit-platform-suite-engine-setup-transitive-dependencies]]
+[[setup-transitive-dependencies]]
 === Transitive Dependencies
 
 * `junit-platform-launcher` in _test_ scope
@@ -32,7 +32,7 @@ on `junit-platform-suite-api` and `junit-platform-suite-engine`.
 * `junit-platform-commons` in _test_ scope
 * `opentest4j` in _test_ scope
 
-[[junit-platform-suite-engine-example]]
+[[example]]
 == @Suite Example
 
 Annotate a class with `@Suite` to have it marked as a test suite on the JUnit Platform. As
@@ -60,7 +60,7 @@ suite, respectively.
 include::example$java/example/BeforeAndAfterSuiteDemo.java[tags=user_guide]
 ----
 
-[[junit-platform-suite-engine-duplicate-test-execution]]
+[[duplicate-test-execution]]
 == Duplicate Test Execution
 
 Depending on the declared selectors, different suites may contain the same tests,
@@ -75,5 +75,5 @@ include only the `junit-platform-suite` engine, or use a custom naming pattern.
 example, name all suites `*Suite` and all tests `*Test`, and configure your build tool to
 include only the former.
 
-Alternatively, consider <<running-tests-tags, using tags>> to select specific groups of
+Alternatively, consider xref:running-tests/tags.adoc[using tags] to select specific groups of
 tests.
diff --git a/documentation/modules/ROOT/pages/advanced-topics/launcher-api.adoc b/documentation/modules/ROOT/pages/advanced-topics/launcher-api.adoc
index ac57b65a254c..903591aabb82 100644
--- a/documentation/modules/ROOT/pages/advanced-topics/launcher-api.adoc
+++ b/documentation/modules/ROOT/pages/advanced-topics/launcher-api.adoc
@@ -8,7 +8,7 @@ filtering and configuration that is necessary from the outside.
 JUnit Platform provides a `Launcher` API that can be used to discover, filter, and execute
 tests. Moreover, third party test libraries – like Spock or Cucumber – can plug into the
 JUnit Platform's launching infrastructure by providing a custom
-<<test-engines,TestEngine>>.
+xref:advanced-topics/engines.adoc[TestEngine].
 
 image::launcher-api-diagram.svg[role=text-center]
 
@@ -17,7 +17,7 @@ The launcher API is in the `{junit-platform-launcher}` module.
 An example consumer of the launcher API is the `{ConsoleLauncher}` in the
 `{junit-platform-console}` project.
 
-[[launcher-api-discovery]]
+[[discovery]]
 == Discovering Tests
 
 Having _test discovery_ as a dedicated feature of the platform frees IDEs and build tools
@@ -51,10 +51,10 @@ Clients can register one or more `{LauncherDiscoveryListener}` implementations v
 discovery. By default, the builder registers an "abort on failure" listener that aborts
 test discovery after the first discovery failure is encountered. The default
 `LauncherDiscoveryListener` can be changed via the
-`junit.platform.discovery.listener.default` <<running-tests-config-params, configuration
-parameter>>.
+`junit.platform.discovery.listener.default` xref:running-tests/configuration-parameters.adoc[configuration
+parameter].
 
-[[launcher-api-execution]]
+[[execution]]
 == Executing Tests
 
 To execute tests, clients can use the same `LauncherDiscoveryRequest` as in the discovery
@@ -77,13 +77,13 @@ events are called in registration order while methods for finish events are call
 reverse order.
 Test case execution won't start before all `executionStarted` calls have returned.
 
-[[launcher-api-engines-custom]]
+[[engines-custom]]
 == Registering a TestEngine
 
-See the dedicated section on <<test-engines-registration, TestEngine registration>> for
+See the dedicated section on xref:advanced-topics/engines.adoc#registration[TestEngine registration] for
 details.
 
-[[launcher-api-post-discovery-filters-custom]]
+[[post-discovery-filters-custom]]
 == Registering a PostDiscoveryFilter
 
 In addition to specifying post-discovery filters as part of a `{LauncherDiscoveryRequest}`
@@ -95,7 +95,7 @@ For example, an `example.CustomTagFilter` class implementing `PostDiscoveryFilte
 declared within the `/META-INF/services/org.junit.platform.launcher.PostDiscoveryFilter`
 file is loaded and applied automatically.
 
-[[launcher-api-launcher-session-listeners-custom]]
+[[launcher-session-listeners-custom]]
 == Registering a LauncherSessionListener
 
 Registered implementations of `{LauncherSessionListener}` are notified when a
@@ -105,7 +105,7 @@ programmatically via the `{LauncherConfig}` that is passed to the `{LauncherFact
 they can be discovered at runtime via Java's `{ServiceLoader}` mechanism and automatically
 registered with `LauncherSession` (unless automatic registration is disabled.)
 
-[[launcher-api-launcher-session-listeners-tool-support]]
+[[launcher-session-listeners-tool-support]]
 === Tool Support
 
 The following build tools and IDEs are known to provide full support for `LauncherSession`:
@@ -116,7 +116,7 @@ The following build tools and IDEs are known to provide full support for `Launch
 
 Other tools might also work but have not been tested explicitly.
 
-[[launcher-api-launcher-session-listeners-tool-example-usage]]
+[[launcher-session-listeners-tool-example-usage]]
 === Example Usage
 
 A `LauncherSessionListener` is well suited for implementing once-per-JVM setup/teardown
@@ -177,22 +177,21 @@ include::example$java/example/session/HttpTests.java[tags=user_guide]
 <4> Send a request to the server
 <5> Check the status code of the response
 
-[[launcher-api-launcher-interceptors-custom]]
+[[launcher-interceptors-custom]]
 == Registering a LauncherInterceptor
 
 In order to intercept the creation of instances of `{Launcher}` and
 `{LauncherSessionListener}` and calls to the `discover` and `execute` methods of the
 former, clients can register custom implementations of `{LauncherInterceptor}` via Java's
 `{ServiceLoader}` mechanism by setting the
-`junit.platform.launcher.interceptors.enabled` <<running-tests-config-params,
-configuration parameter>> to `true`.
+`junit.platform.launcher.interceptors.enabled` xref:running-tests/configuration-parameters.adoc[configuration parameter] to `true`.
 
 [NOTE]
 ====
 Since interceptors are registered before the test run starts, the
 `junit.platform.launcher.interceptors.enabled` _configuration parameter_ can only be
 supplied as a JVM system property or via the JUnit Platform configuration file (see
-<<running-tests-config-params>> for details). This _configuration parameter_ cannot be
+xref:running-tests/configuration-parameters.adoc[] for details). This _configuration parameter_ cannot be
 supplied in the `LauncherDiscoveryRequest` that is passed to the `{Launcher}`.
 ====
 
@@ -205,7 +204,7 @@ the JUnit Platform to load test classes and engine implementations.
 include::example$java/example/CustomLauncherInterceptor.java[tags=user_guide]
 ----
 
-[[launcher-api-launcher-discovery-listeners-custom]]
+[[launcher-discovery-listeners-custom]]
 == Registering a LauncherDiscoveryListener
 
 In addition to specifying discovery listeners as part of a `{LauncherDiscoveryRequest}` or
@@ -219,7 +218,7 @@ For example, an `example.CustomLauncherDiscoveryListener` class implementing
 `/META-INF/services/org.junit.platform.launcher.LauncherDiscoveryListener` file is loaded
 and registered automatically.
 
-[[launcher-api-listeners-custom]]
+[[listeners-custom]]
 == Registering a TestExecutionListener
 
 In addition to the public `{Launcher}` API method for registering test execution listeners
@@ -232,21 +231,21 @@ For example, an `example.CustomTestExecutionListener` class implementing
 `/META-INF/services/org.junit.platform.launcher.TestExecutionListener` file is loaded and
 registered automatically.
 
-[[launcher-api-listeners-config]]
+[[listeners-config]]
 == Configuring a TestExecutionListener
 
 When a `{TestExecutionListener}` is registered programmatically via the `{Launcher}` API,
 the listener may provide programmatic ways for it to be configured -- for example, via its
 constructor, setter methods, etc. However, when a `TestExecutionListener` is registered
 automatically via Java's `ServiceLoader` mechanism (see
-<<launcher-api-listeners-custom>>), there is no way for the user to directly configure the
+<<listeners-custom>>), there is no way for the user to directly configure the
 listener. In such cases, the author of a `TestExecutionListener` may choose to make the
-listener configurable via <<running-tests-config-params, configuration parameters>>. The
+listener configurable via xref:running-tests/configuration-parameters.adoc[configuration parameters]. The
 listener can then access the configuration parameters via the `TestPlan` supplied to the
 `testPlanExecutionStarted(TestPlan)` and `testPlanExecutionFinished(TestPlan)` callback
 methods. See the `{UniqueIdTrackingListener}` for an example.
 
-[[launcher-api-listeners-custom-deactivation]]
+[[listeners-custom-deactivation]]
 == Deactivating a TestExecutionListener
 
 Sometimes it can be useful to run a test suite _without_ certain execution listeners being
@@ -267,16 +266,16 @@ deactivated. In other words, any `TestExecutionListener` registered explicitly v
 In addition, since execution listeners are registered before the test run starts, the
 `junit.platform.execution.listeners.deactivate` _configuration parameter_ can only be
 supplied as a JVM system property or via the JUnit Platform configuration file (see
-<<running-tests-config-params>> for details). This _configuration parameter_ cannot be
+xref:running-tests/configuration-parameters.adoc[] for details). This _configuration parameter_ cannot be
 supplied in the `LauncherDiscoveryRequest` that is passed to the `{Launcher}`.
 ====
 
-[[launcher-api-listeners-custom-deactivation-pattern]]
+[[listeners-custom-deactivation-pattern]]
 === Pattern Matching Syntax
 
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+Refer to xref:running-tests/configuration-parameters.adoc#pattern[Pattern Matching Syntax] for details.
 
-[[launcher-api-launcher-config]]
+[[launcher-config]]
 == Configuring the Launcher
 
 If you require fine-grained control over automatic detection and registration of test
@@ -289,18 +288,17 @@ built-in fluent _builder_ API, as demonstrated in the following example.
 include::example$java/example/UsingTheLauncherDemo.java[tags=launcherConfig]
 ----
 
-[[launcher-api-dry-run-mode]]
+[[dry-run-mode]]
 == Dry-Run Mode
 
 When running tests via the `{Launcher}` API, you can enable _dry-run mode_ by setting the
-`junit.platform.execution.dryRun.enabled` <<running-tests-config-params,
-configuration parameter>> to `true`. In this mode, the `{Launcher}` will not actually
+`junit.platform.execution.dryRun.enabled` xref:running-tests/configuration-parameters.adoc[configuration parameter] to `true`. In this mode, the `{Launcher}` will not actually
 execute any tests but will notify registered `{TestExecutionListener}` instances as if all
 tests had been skipped and their containers had been successful. This can be useful to
 test changes in the configuration of a build or to verify a listener is called as expected
 without having to wait for all tests to be executed.
 
-[[launcher-api-managing-state-across-test-engines]]
+[[managing-state-across-test-engines]]
 == Managing State Across Test Engines
 
 When running tests on the JUnit Platform, multiple test engines may need to access shared
@@ -350,9 +348,9 @@ way, test engines can coordinate resource creation and sharing without direct de
 between them.
 
 Alternatively, it's possible to inject resources into test engines by
-<<launcher-api-launcher-session-listeners-custom, registering a `LauncherSessionListener`>>.
+<<launcher-session-listeners-custom, registering a `LauncherSessionListener`>>.
 
-[[launcher-api-launcher-cancellation]]
+[[launcher-cancellation]]
 == Cancelling a Running Test Execution
 
 The launcher API provides the ability to cancel a running test execution mid-flight while
@@ -376,9 +374,9 @@ include::example$java/example/UsingTheLauncherDemo.java[tags=cancellation]
 [NOTE]
 .Test Engine Support for Cancellation
 ====
-Cancelling tests relies on <<test-engines>> checking and responding to the
+Cancelling tests relies on xref:advanced-topics/engines.adoc[] checking and responding to the
 `{CancellationToken}` appropriately (see
-<<test-engines-requirements-cancellation, Test Engine Requirements>> for details). The
+xref:advanced-topics/engines.adoc#requirements-cancellation[Test Engine Requirements] for details). The
 `Launcher` will also check the token and cancel test execution when multiple test engines
 are present at runtime.
 
diff --git a/documentation/modules/ROOT/pages/advanced-topics/testkit.adoc b/documentation/modules/ROOT/pages/advanced-topics/testkit.adoc
index 6910b8bea154..7900df1623d8 100644
--- a/documentation/modules/ROOT/pages/advanced-topics/testkit.adoc
+++ b/documentation/modules/ROOT/pages/advanced-topics/testkit.adoc
@@ -2,9 +2,9 @@
 
 The `junit-platform-testkit` artifact provides support for executing a test plan on the
 JUnit Platform and then verifying the expected results. This support is currently limited
-to the execution of a single `TestEngine` (see <<testkit-engine>>).
+to the execution of a single `TestEngine` (see <<engine>>).
 
-[[testkit-engine]]
+[[engine]]
 == Engine Test Kit
 
 The `{testkit-engine-package}` package provides support for discovering and executing a
@@ -21,7 +21,7 @@ to build your `LauncherDiscoveryRequest`, you must use one of the `discover()` o
 
 The following test class written using JUnit Jupiter will be used in subsequent examples.
 
-[[testkit-engine-ExampleTestCase]]
+[[engine-ExampleTestCase]]
 [source,java,indent=0]
 ----
 include::example$java/example/ExampleTestCase.java[tags=user_guide]
@@ -33,7 +33,7 @@ own `TestEngine` implementation, you need to use its unique engine ID. Alternati
 may test your own `TestEngine` by supplying an instance of it to the
 `EngineTestKit.engine(TestEngine)` static factory method.
 
-[[testkit-engine-discovery]]
+[[engine-discovery]]
 == Verifying Test Discovery
 
 The following test demonstrates how to verify that a `TestPlan` was discovered as expected
@@ -44,12 +44,12 @@ by the JUnit Jupiter `TestEngine`.
 include::example$java/example/testkit/EngineTestKitDiscoveryDemo.java[tags=user_guide]
 ----
 <1> Select the JUnit Jupiter `TestEngine`.
-<2> Select the <<testkit-engine-ExampleTestCase, `ExampleTestCase`>> test class.
+<2> Select the <<engine-ExampleTestCase, `ExampleTestCase`>> test class.
 <3> Discover the `TestPlan`.
 <4> Assert engine root descriptor has expected display name.
 <5> Assert no discovery issues were encountered.
 
-[[testkit-engine-statistics]]
+[[engine-statistics]]
 == Asserting Execution Statistics
 
 One of the most common features of the Test Kit is the ability to assert statistics
@@ -62,7 +62,7 @@ For details on what statistics are available, consult the Javadoc for `{EventSta
 include::example$java/example/testkit/EngineTestKitStatisticsDemo.java[tags=user_guide]
 ----
 <1> Select the JUnit Jupiter `TestEngine`.
-<2> Select the <<testkit-engine-ExampleTestCase, `ExampleTestCase`>> test class.
+<2> Select the <<engine-ExampleTestCase, `ExampleTestCase`>> test class.
 <3> Execute the `TestPlan`.
 <4> Filter by _container_ events.
 <5> Assert statistics for _container_ events.
@@ -71,17 +71,17 @@ include::example$java/example/testkit/EngineTestKitStatisticsDemo.java[tags=user
 
 NOTE: In the `verifyJupiterContainerStats()` test method, the counts for the `started` and
 `succeeded` statistics are `2` since the `JupiterTestEngine` and the
-<<testkit-engine-ExampleTestCase, `ExampleTestCase`>> class are both considered containers.
+<<engine-ExampleTestCase, `ExampleTestCase`>> class are both considered containers.
 
-[[testkit-engine-events]]
+[[engine-events]]
 == Asserting Events
 
-If you find that <<testkit-engine-statistics, asserting statistics>> alone is insufficient
+If you find that <<engine-statistics, asserting statistics>> alone is insufficient
 for verifying the expected behavior of test execution, you can work directly with the
 recorded `{Event}` elements and perform assertions against them.
 
 For example, if you want to verify the reason that the `skippedTest()` method in
-<<testkit-engine-ExampleTestCase, `ExampleTestCase`>> was skipped, you can do that as
+<<engine-ExampleTestCase, `ExampleTestCase`>> was skipped, you can do that as
 follows.
 
 [TIP]
@@ -99,8 +99,7 @@ events, consult the Javadoc for `{EventConditions}`.
 include::example$java/example/testkit/EngineTestKitSkippedMethodDemo.java[tags=user_guide]
 ----
 <1> Select the JUnit Jupiter `TestEngine`.
-<2> Select the `skippedTest()` method in the <<testkit-engine-ExampleTestCase,
-    `ExampleTestCase`>> test class.
+<2> Select the `skippedTest()` method in the <<engine-ExampleTestCase, `ExampleTestCase`>> test class.
 <3> Execute the `TestPlan`.
 <4> Filter by _test_ events.
 <5> Save the _test_ `Events` to a local variable.
@@ -109,7 +108,7 @@ include::example$java/example/testkit/EngineTestKitSkippedMethodDemo.java[tags=u
     `skippedTest` with `"for demonstration purposes"` as the _reason_.
 
 If you want to verify the type of exception thrown from the `failingTest()` method in
-<<testkit-engine-ExampleTestCase, `ExampleTestCase`>>, you can do that as follows.
+<<engine-ExampleTestCase, `ExampleTestCase`>>, you can do that as follows.
 
 [TIP]
 ====
@@ -123,7 +122,7 @@ events and execution results, consult the Javadoc for `{EventConditions}` and
 include::example$java/example/testkit/EngineTestKitFailedMethodDemo.java[tags=user_guide]
 ----
 <1> Select the JUnit Jupiter `TestEngine`.
-<2> Select the <<testkit-engine-ExampleTestCase, `ExampleTestCase`>> test class.
+<2> Select the <<engine-ExampleTestCase, `ExampleTestCase`>> test class.
 <3> Execute the `TestPlan`.
 <4> Filter by _test_ events.
 <5> Assert that the recorded _test_ events contain exactly one failing test named
@@ -137,7 +136,7 @@ achieve this via the `assertEventsMatchExactly()` method in the `EngineTestKit`
 [TIP]
 ====
 Since `assertEventsMatchExactly()` matches conditions exactly in the order in which the
-events were fired, <<testkit-engine-ExampleTestCase, `ExampleTestCase`>> has been
+events were fired, <<engine-ExampleTestCase, `ExampleTestCase`>> has been
 annotated with `@TestMethodOrder(OrderAnnotation.class)` and each test method has been
 annotated with `@Order(...)`. This allows us to enforce the order in which the test
 methods are executed, which in turn allows our `verifyAllJupiterEvents()` test to be
@@ -153,7 +152,7 @@ respectively.
 include::example$java/example/testkit/EngineTestKitAllEventsDemo.java[tags=user_guide]
 ----
 <1> Select the JUnit Jupiter `TestEngine`.
-<2> Select the <<testkit-engine-ExampleTestCase, `ExampleTestCase`>> test class.
+<2> Select the <<engine-ExampleTestCase, `ExampleTestCase`>> test class.
 <3> Execute the `TestPlan`.
 <4> Filter by _all_ events.
 <5> Print all events to the supplied `writer` for debugging purposes. Debug information
diff --git a/documentation/modules/ROOT/pages/api-evolution.adoc b/documentation/modules/ROOT/pages/api-evolution.adoc
index 448c4aff5c2c..87570809f5f7 100644
--- a/documentation/modules/ROOT/pages/api-evolution.adoc
+++ b/documentation/modules/ROOT/pages/api-evolution.adoc
@@ -10,7 +10,7 @@ sometimes impossible.
 That's why JUnit now uses a defined lifecycle for all publicly available interfaces,
 classes, and methods.
 
-[[api-evolution-version-and-status]]
+[[version-and-status]]
 == API Version and Status
 
 Every published artifact has a version number `<major>.<minor>.<patch>`, and all publicly
@@ -38,24 +38,24 @@ If the `@API` annotation is present on a type, it is considered to be applicable
 public members of that type as well. A member is allowed to declare a different `status`
 value of lower stability.
 
-[[api-evolution-experimental-apis]]
+[[experimental-apis]]
 == Experimental APIs
 
 The following tables list which APIs are currently designated as _experimental_ via
 `@API(status = EXPERIMENTAL)`. Caution should be taken when relying on such APIs.
 
-include::{experimentalApisTableFile}[]
+include::partial$experimental-apis-table.adoc[]
 
-[[api-evolution-deprecated-apis]]
+[[deprecated-apis]]
 == Deprecated APIs
 
 The following tables list which APIs are currently designated as _deprecated_ via
 `@API(status = DEPRECATED)`. You should avoid using deprecated APIs whenever possible,
 since such APIs will likely be removed in an upcoming release.
 
-include::{deprecatedApisTableFile}[]
+include::partial$deprecated-apis-table.adoc[]
 
-[[api-evolution-tooling]]
+[[tooling]]
 == @API Tooling Support
 
 The {API_Guardian} project plans to provide tooling support for publishers and consumers
diff --git a/documentation/modules/ROOT/pages/appendix.adoc b/documentation/modules/ROOT/pages/appendix.adoc
index 50139eca50c9..4cb40e7240bd 100644
--- a/documentation/modules/ROOT/pages/appendix.adoc
+++ b/documentation/modules/ROOT/pages/appendix.adoc
@@ -36,12 +36,12 @@ of the above artifacts and their versions.
 ====
 To ensure that all JUnit artifacts are compatible with each other, their versions should
 be aligned.
-If you rely on <<running-tests-build-spring-boot, Spring Boot>> for dependency management,
+If you rely on xref:running-tests/build-support.adoc#spring-boot[Spring Boot] for dependency management,
 please see the corresponding section.
 Otherwise, instead of managing individual versions of the JUnit artifacts, it is
 recommended to apply the <<dependency-metadata-junit-bom, BOM>> to your project.
-Please refer to the corresponding sections for <<running-tests-build-maven-bom, Maven>> or
-<<running-tests-build-gradle-bom, Gradle>>.
+Please refer to the corresponding sections for xref:running-tests/build-support.adoc#maven-bom[Maven] or
+xref:running-tests/build-support.adoc#gradle-bom[Gradle].
 ====
 
 [[dependency-metadata-junit-platform]]
@@ -56,29 +56,29 @@ Please refer to the corresponding sections for <<running-tests-build-maven-bom,
     itself. _Any usage of internal APIs by external parties is not supported!_
   `junit-platform-console`::
     Support for discovering and executing tests on the JUnit Platform from the console.
-    See <<running-tests-console-launcher>> for details.
+    See xref:running-tests/console-launcher.adoc[] for details.
   `junit-platform-console-standalone`::
     An executable _Fat JAR_ that contains all dependencies is provided in Maven Central under the
     https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
-    directory. See <<running-tests-console-launcher>> for details.
+    directory. See xref:running-tests/console-launcher.adoc[] for details.
   `junit-platform-engine`::
-    Public API for test engines. See <<launcher-api-engines-custom>> for details.
+    Public API for test engines. See xref:advanced-topics/launcher-api.adoc#engines-custom[Registering a TestEngine] for details.
   `junit-platform-launcher`::
     Public API for configuring and launching test plans -- typically used by IDEs and
-    build tools. See <<launcher-api>> for details.
+    build tools. See xref:advanced-topics/launcher-api.adoc[] for details.
   `junit-platform-reporting`::
     `TestExecutionListener` implementations that generate test reports -- typically used
-    by IDEs and build tools. See <<junit-platform-reporting>> for details.
+    by IDEs and build tools. See xref:advanced-topics/junit-platform-reporting.adoc[] for details.
   `junit-platform-suite`::
     JUnit Platform Suite artifact that transitively pulls in dependencies on
     `junit-platform-suite-api` and `junit-platform-suite-engine` for simplified dependency
 	management in build tools such as Gradle and Maven.
   `junit-platform-suite-api`::
     Annotations for configuring test suites on the JUnit Platform. Supported by the
-    <<junit-platform-suite-engine, JUnit Platform Suite Engine>>.
+    xref:advanced-topics/junit-platform-suite-engine.adoc[JUnit Platform Suite Engine].
   `junit-platform-suite-engine`::
     Engine that executes test suites on the JUnit Platform; only required at runtime. See
-    <<junit-platform-suite-engine,JUnit Platform Suite Engine>> for details.
+    xref:advanced-topics/junit-platform-suite-engine.adoc[JUnit Platform Suite Engine] for details.
   `junit-platform-testkit`::
      Provides support for executing a test plan for a given `TestEngine` and then
      accessing the results via a fluent API to verify the expected results.
@@ -94,11 +94,11 @@ Please refer to the corresponding sections for <<running-tests-build-maven-bom,
     `junit-jupiter-api`, `junit-jupiter-params`, and `junit-jupiter-engine` for
     simplified dependency management in build tools such as Gradle and Maven.
   `junit-jupiter-api`::
-    JUnit Jupiter API for <<writing-tests,writing tests>> and <<extensions,extensions>>.
+    JUnit Jupiter API for xref:writing-tests/intro.adoc[writing tests] and xref:extensions/overview.adoc[extensions].
   `junit-jupiter-engine`::
     JUnit Jupiter test engine implementation; only required at runtime.
   `junit-jupiter-params`::
-    Support for <<writing-tests-parameterized-tests>> in JUnit Jupiter.
+    Support for xref:writing-tests/parameterized-classes-and-tests.adoc[] in JUnit Jupiter.
   `junit-jupiter-migrationsupport`::
     _Deprecated_ support for migrating from JUnit 4 to JUnit Jupiter; only required for
     support for JUnit 4's `@Ignore` annotation and for running selected JUnit 4 rules.
diff --git a/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc b/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc
index 8efca7980733..45a3e7cb5a41 100644
--- a/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc
+++ b/documentation/modules/ROOT/pages/extensions/conditional-test-execution.adoc
@@ -17,7 +17,7 @@ short-circuiting boolean OR operator.
 
 See the source code of `{DisabledCondition}` and `{Disabled}` for concrete examples.
 
-[[extensions-conditions-deactivation]]
+[[deactivation]]
 == Deactivating Conditions
 
 Sometimes it can be useful to run a test suite _without_ certain conditions being active.
@@ -27,14 +27,14 @@ order to see if they are still _broken_. To do this, provide a pattern for the
 conditions should be deactivated (i.e., not evaluated) for the current test run. The
 pattern can be supplied as a JVM system property, as a _configuration parameter_ in the
 `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
+configuration file (see xref:running-tests/configuration-parameters.adoc[] for details).
 
 For example, to deactivate JUnit's `@Disabled` condition, you can start your JVM with the
 following system property.
 
 `-Djunit.jupiter.conditions.deactivate=org.junit.*DisabledCondition`
 
-[[extensions-conditions-deactivation-patterns]]
+[[deactivation-patterns]]
 === Pattern Matching Syntax
 
-Refer to <<running-tests-config-params-deactivation-pattern>> for details.
+Refer to xref:running-tests/configuration-parameters.adoc#pattern[Pattern Matching Syntax] for details.
diff --git a/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc b/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc
index c78e1edc00e5..b3090668d4d3 100644
--- a/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc
+++ b/documentation/modules/ROOT/pages/extensions/intercepting-invocations.adoc
@@ -17,6 +17,6 @@ include::example$java/example/interceptor/SwingEdtInterceptor.java[tags=user_gui
 ====
 You may override the `getTestInstantiationExtensionContextScope(...)` method to return
 `TEST_METHOD` to make test-specific data available to your extension implementation of
-`interceptTestClassConstructor` or if you want to <<extensions-keeping-state, keep state>>
+`interceptTestClassConstructor` or if you want to xref:extensions/keeping-state-in-extensions.adoc[keep state]
 on the test method level.
 ====
diff --git a/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc b/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc
index 5017884c73f5..082da03fa2ed 100644
--- a/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc
+++ b/documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc
@@ -5,7 +5,7 @@ you keep the state from one invocation of an extension to the next? The
 `{ExtensionContext}` API provides a `{ExtensionContext_Store}` exactly for this purpose.
 Extensions may put values into a store for later retrieval.
 
-TIP: See the `<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>` for an
+TIP: See the `xref:extensions/test-lifecycle-callbacks.adoc#timing-extension[TimingExtension]` for an
 example of using the `Store` with a method-level scope.
 
 .The `ExtensionContext` and `Store` hierarchy
@@ -20,11 +20,11 @@ classes or extension. The `{ExtensionContext_StoreScope}` enum allows to go beyo
 that and access the stores on the level of the current `{LauncherExecutionRequest}` or
 `{LauncherSession}` which can be used to share data across test engines or inject data
 from a registered
-<<launcher-api-launcher-session-listeners-custom, `LauncherSessionListener`>>,
+xref:advanced-topics/launcher-api.adoc#launcher-session-listeners-custom[`LauncherSessionListener`],
 respectively. Please consult the Javadoc of `{ExtensionContext}`,
 `{ExtensionContext_Store}`, and `{ExtensionContext_StoreScope}` for details.
 
-[[extensions-keeping-state-autocloseable-support]]
+[[support]]
 [NOTE]
 .Resource management via `_AutoCloseable_`
 ====
@@ -34,7 +34,7 @@ context lifecycle ends it closes its associated store.
 All stored values that are instances of `AutoCloseable` are notified by an invocation of
 their `close()` method in the inverse order they were added in (unless the
 `junit.jupiter.extensions.store.close.autocloseable.enabled`
-<<running-tests-config-params, configuration parameter>> is set to `false`).
+xref:running-tests/configuration-parameters.adoc[configuration parameter] is set to `false`).
 
 Versions prior to 5.13 only supported `CloseableResource`, which is deprecated but still
 available for backward compatibility.
@@ -67,7 +67,7 @@ include::example$java/example/extensions/HttpServerExtension.java[tags=user_guid
 include::example$java/example/HttpServerDemo.java[tags=user_guide]
 ----
 
-[[extensions-keeping-state-autocloseable-migration]]
+[[migration]]
 [TIP]
 .Migration Note for Resource Cleanup
 ====
diff --git a/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc b/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc
index c626f20c8530..da61a5a67bce 100644
--- a/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc
+++ b/documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc
@@ -4,9 +4,9 @@
 runtime.
 
 If a _test class_ constructor, _test method_, or _lifecycle method_ (see
-<<writing-tests-definitions>>) declares a parameter, the parameter must be _resolved_ at
+xref:writing-tests/definitions.adoc[]) declares a parameter, the parameter must be _resolved_ at
 runtime by a `ParameterResolver`. A `ParameterResolver` can either be built-in (see
-`{TestInfoParameterResolver}`) or <<extensions-registration,registered by the user>>.
+`{TestInfoParameterResolver}`) or xref:extensions/registering-extensions.adoc[registered by the user].
 Generally speaking, parameters may be resolved by _name_, _type_, _annotation_, or any
 combination thereof.
 
@@ -41,7 +41,7 @@ You may override the `getTestInstantiationExtensionContextScope(...)` method to
 `TEST_METHOD` to support injecting test specific data into constructor parameters of the
 test class instance. Doing so causes a test-specific `{ExtensionContext}` to be used while
 resolving constructor parameters, unless the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is set to `PER_CLASS`.
+xref:writing-tests/test-instance-lifecycle.adoc[test instance lifecycle] is set to `PER_CLASS`.
 ====
 
 [TIP]
@@ -52,7 +52,7 @@ constructor invocations, using the `{ExecutableInvoker}` available via the
 `getExecutableInvoker()` method in the `ExtensionContext`.
 ====
 
-[[extensions-parameter-resolution-conflicts]]
+[[conflicts]]
 == Parameter Conflicts
 
 If multiple implementations of `ParameterResolver` that support the same type are
@@ -95,10 +95,10 @@ include::example$java/example/extensions/ParameterResolverCustomAnnotationDemo.j
 
 JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
 attempts to claim their supported types. For example, `{TestInfo}` provides metadata about
-tests. See <<writing-tests-dependency-injection>> for details. Third-party frameworks such
+tests. See xref:writing-tests/dependency-injection-for-constructors-and-methods.adoc[] for details. Third-party frameworks such
 as Spring may also define parameter resolvers. Apply one of the techniques in this section
 to resolve any conflicts.
 
 Parameterized tests are another potential source of conflict. Ensure that tests annotated
 with `@ParameterizedTest` are not also annotated with `@Test` and see
-<<writing-tests-parameterized-tests-consuming-arguments>> for more details.
+xref:writing-tests/parameterized-classes-and-tests.adoc#tests-consuming-arguments[Consuming Arguments] for more details.
diff --git a/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc b/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc
index 5e61a03abe74..d046c1e29a4e 100644
--- a/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc
+++ b/documentation/modules/ROOT/pages/extensions/pre-interrupt-callback.adoc
@@ -3,4 +3,4 @@
 `{PreInterruptCallback}` defines the API for `Extensions` that wish to react on
 timeouts before the `Thread.interrupt()` is called.
 
-Please refer to <<writing-tests-declarative-timeouts-debugging>> for additional information.
+Please refer to xref:writing-tests/timeouts.adoc#debugging[Debugging Timeouts] for additional information.
diff --git a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc
index f111450665bc..fa1b7936b10a 100644
--- a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc
+++ b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-class-templates.adoc
@@ -37,5 +37,5 @@ methods in a test class albeit in different contexts — for example, with diffe
 parameters, by preparing the test class instance differently, or multiple times without
 modifying the context.
 Please refer to the implementations of
-<<writing-tests-parameterized-tests, Parameterized Classes>> which uses this extension
+xref:writing-tests/parameterized-classes-and-tests.adoc[Parameterized Classes] which uses this extension
 point to provide its functionality.
diff --git a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc
index b7b488180b5b..2d55a58a5ae3 100644
--- a/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc
+++ b/documentation/modules/ROOT/pages/extensions/providing-invocation-contexts-for-test-templates.adoc
@@ -30,6 +30,6 @@ The `{TestTemplateInvocationContextProvider}` extension API is primarily intende
 implementing different kinds of tests that rely on repetitive invocation of a test-like
 method albeit in different contexts — for example, with different parameters, by preparing
 the test class instance differently, or multiple times without modifying the context.
-Please refer to the implementations of <<writing-tests-repeated-tests>> or
-<<writing-tests-parameterized-tests, Parameterized Tests>> which use this extension point
+Please refer to the implementations of xref:writing-tests/repeated-tests.adoc[] or
+xref:writing-tests/parameterized-classes-and-tests.adoc[Parameterized Tests] which use this extension point
 to provide their functionality.
diff --git a/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc b/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc
index d7d9dedbf39b..e25eb404f063 100644
--- a/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc
+++ b/documentation/modules/ROOT/pages/extensions/registering-extensions.adoc
@@ -1,16 +1,16 @@
 = Registering Extensions
 
 Extensions can be registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, _programmatically_ via
-<<extensions-registration-programmatic,`@RegisterExtension`>>, or _automatically_ via
-Java's <<extensions-registration-automatic,`ServiceLoader`>> mechanism.
+<<registration-declarative, `@ExtendWith`>>, _programmatically_ via
+<<registration-programmatic, `@RegisterExtension`>>, or _automatically_ via
+Java's <<registration-automatic, `ServiceLoader`>> mechanism.
 
-[[extensions-registration-declarative]]
+[[registration-declarative]]
 == Declarative Extension Registration
 
 Developers can register one or more extensions _declaratively_ by annotating a test
-interface, test class, test method, or custom _<<writing-tests-meta-annotations,composed
-annotation>>_ with `@ExtendWith(...)` and supplying class references for the extensions to
+interface, test class, test method, or custom _xref:writing-tests/annotations.adoc#annotations[composed
+annotation]_ with `@ExtendWith(...)` and supplying class references for the extensions to
 register. `@ExtendWith` may also be declared on fields or on parameters in test class
 constructors, in test methods, and in `@BeforeAll`, `@AfterAll`, `@BeforeEach`, and
 `@AfterEach` lifecycle methods.
@@ -72,7 +72,7 @@ be extended by the `DatabaseExtension` and `WebServerExtension`, **in exactly th
 ====
 
 If you wish to combine multiple extensions in a reusable way, you can define a custom
-_<<writing-tests-meta-annotations,composed annotation>>_ and use `@ExtendWith` as a
+_xref:writing-tests/annotations.adoc#annotations[composed annotation]_ and use `@ExtendWith` as a
 _meta-annotation_ as in the following code listing. Then `@DatabaseAndWebServerExtension`
 can be used in place of `@ExtendWith({ DatabaseExtension.class, WebServerExtension.class })`.
 
@@ -104,7 +104,7 @@ include::example$java/example/extensions/Random.java[tags=user_guide]
 include::example$java/example/extensions/RandomNumberDemo.java[tags=user_guide]
 ----
 
-[[extensions-RandomNumberExtension]]
+[[RandomNumberExtension]]
 The following code listing provides an example of how one might choose to implement such a
 `RandomNumberExtension`. This implementation works for the use cases in
 `RandomNumberDemo`; however, it may not prove robust enough to cover all use cases -- for
@@ -129,8 +129,7 @@ include::example$java/example/extensions/RandomNumberExtension.java[tags=user_gu
 Extensions registered declaratively via `@ExtendWith` on fields will be ordered relative
 to `@RegisterExtension` fields and other `@ExtendWith` fields using an algorithm that is
 deterministic but intentionally nonobvious. However, `@ExtendWith` fields can be ordered
-using the `@Order` annotation. See the <<extensions-registration-programmatic-order,
-Extension Registration Order>> tip for `@RegisterExtension` fields for details.
+using the `@Order` annotation. See the <<registration-programmatic-order, Extension Registration Order>> tip for `@RegisterExtension` fields for details.
 ====
 
 [TIP]
@@ -139,27 +138,27 @@ Extension Registration Order>> tip for `@RegisterExtension` fields for details.
 Extensions registered declaratively via `@ExtendWith` on fields in superclasses will be
 inherited.
 
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+See <<registration-inheritance, Extension Inheritance>> for details.
 ====
 
 NOTE: `@ExtendWith` fields may be either `static` or non-static. The documentation on
-<<extensions-registration-programmatic-static-fields, Static Fields>> and
-<<extensions-registration-programmatic-instance-fields, Instance Fields>> for
+<<registration-programmatic-static-fields, Static Fields>> and
+<<registration-programmatic-instance-fields, Instance Fields>> for
 `@RegisterExtension` fields also applies to `@ExtendWith` fields.
 
-[[extensions-registration-programmatic]]
+[[registration-programmatic]]
 == Programmatic Extension Registration
 
 Developers can register extensions _programmatically_ by annotating fields in test classes
 with `{RegisterExtension}`.
 
 When an extension is registered _declaratively_ via
-<<extensions-registration-declarative,`@ExtendWith`>>, it can typically only be configured
+<<registration-declarative, `@ExtendWith`>>, it can typically only be configured
 via annotations. In contrast, when an extension is registered via `@RegisterExtension`, it
 can be configured _programmatically_ -- for example, in order to pass arguments to the
 extension's constructor, a static factory method, or a builder API.
 
-[[extensions-registration-programmatic-order]]
+[[registration-programmatic-order]]
 [TIP]
 .Extension Registration Order
 ====
@@ -188,13 +187,13 @@ relative to other programmatically registered extensions.
 Extensions registered via `@RegisterExtension` or `@ExtendWith` on fields in superclasses
 will be inherited.
 
-See <<extensions-registration-inheritance, Extension Inheritance>> for details.
+See <<registration-inheritance, Extension Inheritance>> for details.
 ====
 
 NOTE: `@RegisterExtension` fields must not be `null` (at evaluation time) but may be
 either `static` or non-static.
 
-[[extensions-registration-programmatic-static-fields]]
+[[registration-programmatic-static-fields]]
 === Static Fields
 
 If a `@RegisterExtension` field is `static`, the extension will be registered after
@@ -220,7 +219,7 @@ lifecycle methods annotated with `@BeforeAll` or `@AfterAll` as well as `@Before
 include::example$java/example/registration/WebServerDemo.java[tags=user_guide]
 ----
 
-[[extensions-registration-programmatic-static-fields-kotlin]]
+[[registration-programmatic-static-fields-kotlin]]
 ==== Static Fields in Kotlin
 
 The Kotlin programming language does not have the concept of a `static` field. However,
@@ -237,7 +236,7 @@ has been ported to Kotlin.
 include::example$kotlin/example/registration/KotlinWebServerDemo.kt[tags=user_guide]
 ----
 
-[[extensions-registration-programmatic-instance-fields]]
+[[registration-programmatic-instance-fields]]
 === Instance Fields
 
 If a `@RegisterExtension` field is non-static (i.e., an instance field), the extension
@@ -262,11 +261,11 @@ instance of the extension via the `docs` field if necessary.
 include::example$java/example/registration/DocumentationDemo.java[tags=user_guide]
 ----
 
-[[extensions-registration-automatic]]
+[[registration-automatic]]
 == Automatic Extension Registration
 
-In addition to <<extensions-registration-declarative,declarative extension registration>>
-and <<extensions-registration-programmatic,programmatic extension registration>> support
+In addition to <<registration-declarative, declarative extension registration>>
+and <<registration-programmatic, programmatic extension registration>> support
 using annotations, JUnit Jupiter also supports _global extension registration_ via Java's
 `{ServiceLoader}` mechanism, allowing third-party extensions to be auto-detected and
 automatically registered based on what is available in the classpath.
@@ -275,14 +274,14 @@ Specifically, a custom extension can be registered by supplying its fully qualif
 name in a file named `org.junit.jupiter.api.extension.Extension` within the
 `/META-INF/services` folder in its enclosing JAR file.
 
-[[extensions-registration-automatic-enabling]]
+[[registration-automatic-enabling]]
 === Enabling Automatic Extension Detection
 
 Auto-detection is an advanced feature and is therefore not enabled by default. To enable
 it, set the `junit.jupiter.extensions.autodetection.enabled` _configuration parameter_ to
 `true`. This can be supplied as a JVM system property, as a _configuration parameter_ in
 the `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
+configuration file (see xref:running-tests/configuration-parameters.adoc[] for details).
 
 For example, to enable auto-detection of extensions, you can start your JVM with the
 following system property.
@@ -293,11 +292,11 @@ When auto-detection is enabled, extensions discovered via the `{ServiceLoader}`
 will be added to the extension registry after JUnit Jupiter's global extensions (e.g.,
 support for `TestInfo`, `TestReporter`, etc.).
 
-[[extensions-registration-automatic-filtering]]
+[[registration-automatic-filtering]]
 === Filtering Auto-detected Extensions
 
 The list of auto-detected extensions can be filtered using include and exclude patterns
-via the following <<running-tests-config-params, configuration parameters>>:
+via the following xref:running-tests/configuration-parameters.adoc[configuration parameters]:
 
 `junit.jupiter.extensions.autodetection.include=<patterns>`::
     Comma-separated list of _include_ patterns for auto-detected extensions.
@@ -308,9 +307,9 @@ Include patterns are applied _before_ exclude patterns. If both include and excl
 patterns are provided, only extensions that match at least one include pattern and do not
 match any exclude pattern will be auto-detected.
 
-See <<running-tests-config-params-deactivation-pattern>> for details on the pattern syntax.
+See xref:running-tests/configuration-parameters.adoc#pattern[Pattern Matching Syntax] for details on the pattern syntax.
 
-[[extensions-registration-inheritance]]
+[[registration-inheritance]]
 == Extension Inheritance
 
 Registered extensions are inherited within test class hierarchies with top-down semantics.
@@ -324,8 +323,7 @@ be registered before extensions registered declaratively via `@ExtendWith` on a
 Similarly, extensions registered programmatically via `@RegisterExtension` or
 `@ExtendWith` on fields in a superclass will be registered before extensions registered
 programmatically via `@RegisterExtension` or `@ExtendWith` on fields in a subclass, unless
-`@Order` is used to alter that behavior (see <<extensions-registration-programmatic-order,
-Extension Registration Order>> for details).
+`@Order` is used to alter that behavior (see <<registration-programmatic-order, Extension Registration Order>> for details).
 
 NOTE: A specific extension implementation can only be registered once for a given
 extension context and its parent contexts. Consequently, any attempt to register a
diff --git a/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc b/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc
index f062f7987df0..6c88a1ed6d29 100644
--- a/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc
+++ b/documentation/modules/ROOT/pages/extensions/relative-execution-order-of-user-code-and-extensions.adoc
@@ -3,9 +3,9 @@
 When executing a test class that contains one or more test methods, a number of extension
 callbacks are called in addition to the user-supplied test and lifecycle methods.
 
-NOTE: See also: <<writing-tests-test-execution-order>>
+NOTE: See also: xref:writing-tests/test-execution-order.adoc[]
 
-[[extensions-execution-order-overview]]
+[[overview]]
 == User and Extension Code
 
 The following diagram illustrates the relative order of user-supplied code and extension
@@ -13,12 +13,12 @@ code. User-supplied test and lifecycle methods are shown in orange, with callbac
 implemented by extensions shown in blue. The grey box denotes the execution of a single
 test method and will be repeated for every test method in the test class.
 
-[[extensions-execution-order-diagram]]
+[[diagram]]
 .User code and extension code
 image::extensions_lifecycle.png[]
 
 The following table further explains the sixteen steps in the
-<<extensions-execution-order-diagram>> diagram.
+<<diagram>> diagram.
 
 . *interface* `*org.junit.jupiter.api.extension.BeforeAllCallback*` +
 extension code executed before all tests of the container are executed
@@ -29,7 +29,7 @@ user code executed before all tests of the container are executed
 extension code for handling exceptions thrown from `@BeforeAll` methods
 . *interface* `*org.junit.jupiter.api.extension.BeforeClassTemplateInvocationCallback*` +
 extension code executed before each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
+if the test class is a xref:writing-tests/class-templates.adoc[class template])
 . *interface* `*org.junit.jupiter.api.extension.BeforeEachCallback*` +
 extension code executed before each test is executed
 . *annotation* `*org.junit.jupiter.api.BeforeEach*` +
@@ -54,7 +54,7 @@ extension code for handling exceptions thrown from `@AfterEach` methods
 extension code executed after each test is executed
 . *interface* `*org.junit.jupiter.api.extension.AfterClassTemplateInvocationCallback*` +
 extension code executed after each class template invocation is executed (only applicable
-if the test class is a <<writing-tests-class-templates, class template>>)
+if the test class is a xref:writing-tests/class-templates.adoc[class template])
 . *annotation* `*org.junit.jupiter.api.AfterAll*` +
 user code executed after all tests of the container are executed
 . *interface* `*org.junit.jupiter.api.extension.LifecycleMethodExecutionExceptionHandler
@@ -69,9 +69,9 @@ corresponding lifecycle callback. For further details on the various lifecycle c
 please consult the respective Javadoc for each annotation and extension.
 
 All invocations of user code methods in the above table can additionally be intercepted
-by implementing <<extensions-intercepting-invocations, `InvocationInterceptor`>>.
+by implementing xref:extensions/intercepting-invocations.adoc[`InvocationInterceptor`].
 
-[[extensions-execution-order-wrapping-behavior]]
+[[wrapping-behavior]]
 == Wrapping Behavior of Callbacks
 
 JUnit Jupiter always guarantees _wrapping_ behavior for multiple registered extensions
@@ -89,7 +89,7 @@ callbacks implemented by `Extension2`. `Extension1` is therefore said to _wrap_
 `Extension2`.
 
 JUnit Jupiter also guarantees _wrapping_ behavior within class and interface hierarchies
-for user-supplied _lifecycle methods_ (see <<writing-tests-definitions>>).
+for user-supplied _lifecycle methods_ (see xref:writing-tests/definitions.adoc[]).
 
 * `@BeforeAll` methods are inherited from superclasses as long as they are not
   _overridden_. Furthermore, `@BeforeAll` methods from superclasses will be executed
@@ -233,6 +233,6 @@ image::extensions_BrokenLifecycleMethodConfigDemo.png[caption='',title='BrokenLi
 [TIP]
 ====
 Due to the aforementioned behavior, the JUnit Team recommends that developers declare at
-most one of each type of _lifecycle method_ (see <<writing-tests-definitions>>) per test
+most one of each type of _lifecycle method_ (see xref:writing-tests/definitions.adoc[]) per test
 class or test interface unless there are no dependencies between such lifecycle methods.
 ====
diff --git a/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc b/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc
index 38ca96625bab..bacf8790a3e2 100644
--- a/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc
+++ b/documentation/modules/ROOT/pages/extensions/supported-utilities-in-extensions.adoc
@@ -6,7 +6,7 @@ utilities can be found in the `{junit-platform-support-package}` and its subpack
 `TestEngine` and `Extension` authors are encouraged to use these supported utilities in
 order to align with the behavior of the JUnit Platform and JUnit Jupiter.
 
-[[extensions-supported-utilities-annotations]]
+[[annotations]]
 == Annotation Support
 
 `AnnotationSupport` provides static utility methods that operate on annotated elements
@@ -20,15 +20,15 @@ interfaces and within class hierarchies to find annotations. Consult the Javadoc
 NOTE: The `isAnnotated()` methods do not find repeatable annotations. To check for repeatable annotations,
 use one of the `findRepeatableAnnotations()` methods and verify that the returned list is not empty.
 
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+NOTE: See also: <<search-semantics>>
 
-[[extensions-supported-utilities-classes]]
+[[classes]]
 == Class Support
 
 `ClassSupport` provides static utility methods for working with classes (i.e., instances
 of `java.lang.Class`). Consult the Javadoc for `{ClassSupport}` for further details.
 
-[[extensions-supported-utilities-reflection]]
+[[reflection]]
 == Reflection Support
 
 `ReflectionSupport` provides static utility methods that augment the standard JDK
@@ -38,9 +38,9 @@ class, and to find and invoke methods. Some of these methods traverse class hier
 to locate matching methods. Consult the Javadoc for `{ReflectionSupport}` for further
 details.
 
-NOTE: See also: <<extensions-supported-utilities-search-semantics>>
+NOTE: See also: <<search-semantics>>
 
-[[extensions-supported-utilities-modifier]]
+[[modifier]]
 == Modifier Support
 
 `ModifierSupport` provides static utility methods for working with member and class
@@ -48,7 +48,7 @@ modifiers -- for example, to determine if a member is declared as `public`, `pri
 `abstract`, `static`, etc. Consult the Javadoc for `{ModifierSupport}` for further
 details.
 
-[[extensions-supported-utilities-conversion]]
+[[conversion]]
 == Conversion Support
 
 `ConversionSupport` (in the `org.junit.platform.commons.support.conversion` package)
@@ -57,7 +57,7 @@ wrapper types, date and time types from the `java.time package`, and some additi
 common Java types such as `File`, `BigDecimal`, `BigInteger`, `Currency`, `Locale`, `URI`,
 `URL`, `UUID`, etc. Consult the Javadoc for `{ConversionSupport}` for further details.
 
-[[extensions-supported-utilities-search-semantics]]
+[[search-semantics]]
 == Field and Method Search Semantics
 
 Various methods in `AnnotationSupport` and `ReflectionSupport` use search algorithms that
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc
index 1682268d2ae5..0710cf755f42 100644
--- a/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-factories.adoc
@@ -28,5 +28,5 @@ registered for any specific test class.
 ====
 You may override the `getTestInstantiationExtensionContextScope(...)` method to return
 `TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
+you want to xref:extensions/keeping-state-in-extensions.adoc[keep state] on the test method level.
 ====
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc
index 41b8b3b3de28..93bab7eaac29 100644
--- a/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-post-processing.adoc
@@ -14,5 +14,5 @@ For a concrete example, consult the source code for the `{MockitoExtension}` and
 ====
 You may override the `getTestInstantiationExtensionContextScope(...)` method to return
 `TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
+you want to xref:extensions/keeping-state-in-extensions.adoc[keep state] on the test method level.
 ====
diff --git a/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc b/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc
index 4d4623367526..0d72d10018f2 100644
--- a/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-instance-pre-construct-callback.adoc
@@ -13,5 +13,5 @@ instances and their lifecycle.
 ====
 You may override the `getTestInstantiationExtensionContextScope(...)` method to return
 `TEST_METHOD` to make test-specific data available to your extension implementation or if
-you want to <<extensions-keeping-state, keep state>> on the test method level.
+you want to xref:extensions/keeping-state-in-extensions.adoc[keep state] on the test method level.
 ====
diff --git a/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc b/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc
index f0782ab64c31..2b0190598f5e 100644
--- a/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-lifecycle-callbacks.adoc
@@ -6,13 +6,13 @@ each of these interfaces in the `{extension-api-package}` package for further de
 
 * `{BeforeAllCallback}`
 ** `{BeforeClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
+   xref:writing-tests/class-templates.adoc[class templates])
 *** `{BeforeEachCallback}`
 **** `{BeforeTestExecutionCallback}`
 **** `{AfterTestExecutionCallback}`
 *** `{AfterEachCallback}`
 ** `{AfterClassTemplateInvocationCallback}` (only applicable for
-   <<writing-tests-class-templates, class templates>>)
+   xref:writing-tests/class-templates.adoc[class templates])
 * `{AfterAllCallback}`
 
 .Implementing Multiple Extension APIs
@@ -20,7 +20,7 @@ NOTE: Extension developers may choose to implement any number of these interface
 within a single extension. Consult the source code of the `{SpringExtension}` for a
 concrete example.
 
-[[extensions-lifecycle-callbacks-before-after-execution]]
+[[before-after-execution]]
 == Before and After Test Execution Callbacks
 
 `{BeforeTestExecutionCallback}` and `{AfterTestExecutionCallback}` define the APIs for
@@ -34,7 +34,7 @@ The following example shows how to use these callbacks to calculate and log the
 time of a test method. `TimingExtension` implements both `BeforeTestExecutionCallback`
 and `AfterTestExecutionCallback` in order to time and log the test execution.
 
-[[extensions-lifecycle-callbacks-timing-extension]]
+[[timing-extension]]
 [source,java,indent=0]
 .An extension that times and logs the execution of test methods
 ----
diff --git a/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc b/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc
index c3d0f7503a1b..24fa7d04315e 100644
--- a/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc
+++ b/documentation/modules/ROOT/pages/extensions/test-result-processing.adoc
@@ -10,7 +10,7 @@ information for the following events.
 * `testFailed`: invoked after a _test method_ has failed
 
 NOTE: In contrast to the definition of "test method" presented in
-<<writing-tests-definitions>>, in this context _test method_ refers to any `@Test` method
+xref:writing-tests/definitions.adoc[], in this context _test method_ refers to any `@Test` method
 or `@TestTemplate` method (for example, a `@RepeatedTest` or `@ParameterizedTest`).
 
 Extensions implementing this interface can be registered at the class level, instance
@@ -46,6 +46,6 @@ or fail test execution.
 ====
 Any instances of `ExtensionContext.Store.CloseableResource` stored in the `Store` of the
 provided `{ExtensionContext}` will be closed _before_ methods in the `TestWatcher` API are
-invoked (see <<extensions-keeping-state>>). You can use the parent context's `Store` to
+invoked (see xref:extensions/keeping-state-in-extensions.adoc[]). You can use the parent context's `Store` to
 work with such resources.
 ====
diff --git a/documentation/modules/ROOT/pages/migrating-from-junit4.adoc b/documentation/modules/ROOT/pages/migrating-from-junit4.adoc
index b0442759aad1..679b8b59acd7 100644
--- a/documentation/modules/ROOT/pages/migrating-from-junit4.adoc
+++ b/documentation/modules/ROOT/pages/migrating-from-junit4.adoc
@@ -13,7 +13,7 @@ classpath does not lead to any conflicts. It is therefore safe to maintain exist
 4 tests alongside JUnit Jupiter tests and migrate them gradually.
 
 
-[[migrating-from-junit4-running]]
+[[running]]
 == Running JUnit 4 Tests on the JUnit Platform
 
 [WARNING]
@@ -23,10 +23,10 @@ migrating tests to JUnit Jupiter or another testing framework with native JUnit
 support.
 
 By default, if the JUnit Vintage engine is registered and discovers at least one test
-class, it reports a <<running-tests-discovery-issues, discovery issue>> of INFO severity.
+class, it reports a xref:running-tests/discovery-issues.adoc[discovery issue] of INFO severity.
 You can prevent this discovery issue from being reported by setting the
 `junit.vintage.discovery.issue.reporting.enabled`
-<<running-tests-config-params, configuration parameter>> to `false`.
+xref:running-tests/configuration-parameters.adoc[configuration parameter] to `false`.
 ====
 
 Make sure that the `junit-vintage-engine` artifact is in your test runtime path. In that
@@ -36,23 +36,23 @@ launcher.
 See the example projects in the {junit-examples-repo}[`junit-examples`] repository to
 find out how this is done with Gradle and Maven.
 
-[[migrating-from-junit4-categories-support]]
+[[categories-support]]
 === Categories Support
 
 For test classes or methods that are annotated with `@Category`, the _JUnit Vintage test
-engine_ exposes the category's fully qualified class name as a <<running-tests-tags, tag>>
+engine_ exposes the category's fully qualified class name as a xref:running-tests/tags.adoc[tag]
 for the corresponding test class or test method. For example, if a test method is
 annotated with `@Category(Example.class)`, it will be tagged with `"com.acme.Example"`.
 Similar to the `Categories` runner in JUnit 4, this information can be used to filter the
-discovered tests before executing them (see <<running-tests>> for details).
+discovered tests before executing them (see xref:running-tests/intro.adoc[] for details).
 
-[[migrating-from-junit4-parallel-execution]]
+[[parallel-execution]]
 == Parallel Execution
 
 The JUnit Vintage test engine supports parallel execution of top-level test classes and test methods,
 allowing existing JUnit 3 and JUnit 4 tests to benefit from improved performance through
 concurrent test execution. It can be enabled and configured using the following
-<<running-tests-config-params, configuration parameters>>:
+xref:running-tests/configuration-parameters.adoc[configuration parameters]:
 
 `junit.vintage.execution.parallel.enabled=true|false`::
   Enable/disable parallel execution (defaults to `false`). Requires opt-in for `classes`
@@ -68,7 +68,7 @@ concurrent test execution. It can be enabled and configured using the following
   Specifies the size of the thread pool to be used for parallel execution. By default, the
   number of available processors is used.
 
-[[migrating-from-junit4-parallel-execution-class-level]]
+[[parallel-execution-class-level]]
 === Parallelization at Class Level
 
 Let's assume we have two test classes `FooTest` and `BarTest` with each class containing
@@ -93,7 +93,7 @@ ForkJoinPool-1-worker-1 - BarTest::test3
 ForkJoinPool-1-worker-2 - FooTest::test3
 ----
 
-[[migrating-from-junit4-parallel-execution-method-level]]
+[[parallel-execution-method-level]]
 === Parallelization at Method Level
 
 Alternatively, we can enable parallel test execution at a method level,
@@ -119,7 +119,7 @@ ForkJoinPool-1-worker-2 - FooTest::test2
 ForkJoinPool-1-worker-1 - FooTest::test3
 ----
 
-[[migrating-from-junit4-parallel-execution-class-and-method-level]]
+[[parallel-execution-class-and-method-level]]
 === Full Parallelization
 
 Finally, we can also enable parallelization at both class and method level:
@@ -144,7 +144,7 @@ ForkJoinPool-1-worker-5 - BarTest::test2
 ForkJoinPool-1-worker-4 - BarTest::test1
 ----
 
-[[migrating-from-junit4-parallel-execution-pool-size]]
+[[parallel-execution-pool-size]]
 === Configuring the Pool Size
 
 The default thread pool size is equal to the number of available processors. However, we
@@ -176,7 +176,7 @@ As we can see, even though we set the thread pool size was four, only three thre
 used in this case. This happens because the pool adjusts the number of active threads
 based on workload and system needs.
 
-[[migrating-from-junit4-parallel-execution-disabled]]
+[[parallel-execution-disabled]]
 === Sequential Execution
 
 On the other hand, if we disable parallel execution, the `VintageTestEngine`
@@ -192,7 +192,7 @@ junit.vintage.execution.parallel.methods=true
 Similarly, tests will be executed sequentially if you enable parallel execution in general
 but enable neither class-level nor method-level parallelization.
 
-[[migrating-from-junit4-tips]]
+[[tips]]
 == Migration Tips
 
 The following are topics that you should be aware of when migrating existing JUnit 4
@@ -211,29 +211,29 @@ tests to JUnit Jupiter.
 * `@BeforeClass` and `@AfterClass` no longer exist; use `@BeforeAll` and `@AfterAll`
   instead.
 * `@Ignore` no longer exists: use `@Disabled` or one of the other built-in
-  <<writing-tests-conditional-execution, execution conditions>> instead
-  - See also <<migrating-from-junit4-ignore-annotation-support>>.
+  xref:writing-tests/conditional-test-execution.adoc[execution conditions] instead
+  - See also <<ignore-annotation-support>>.
 * `@Category` no longer exists; use `@Tag` instead.
 * `@RunWith` no longer exists; superseded by `@ExtendWith`.
   - For `@RunWith(Enclosed.class)` use `@Nested`.
-  - For `@RunWith(Parameterized.class)` see <<migrating-from-junit4-tips-parameterized>>.
+  - For `@RunWith(Parameterized.class)` see <<tips-parameterized>>.
 * `@Rule` and `@ClassRule` no longer exist; superseded by `@ExtendWith` and
   `@RegisterExtension`.
-  - See also <<migrating-from-junit4-rule-support>>.
+  - See also <<rule-support>>.
 * `@Test(expected = ...)` and the `ExpectedException` rule no longer exist; use
   `Assertions.assertThrows(...)` instead.
-  - See <<migrating-from-junit4-rule-support>> if you still need to use
+  - See <<rule-support>> if you still need to use
     `ExpectedException`.
 * Assertions and assumptions in JUnit Jupiter accept the failure message as their last
   argument instead of the first one.
-  - See <<migrating-from-junit4-failure-message-arguments>> for details.
+  - See <<failure-message-arguments>> for details.
 
-[[migrating-from-junit4-tips-parameterized]]
+[[tips-parameterized]]
 === Parameterized test classes
 
 Unless `@UseParametersRunnerFactory` is used, a JUnit 4 parameterized test class can be
 converted into a JUnit Jupiter
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> by following these steps:
+xref:writing-tests/parameterized-classes-and-tests.adoc[`@ParameterizedClass`] by following these steps:
 
 . Replace `@RunWith(Parameterized.class)` with `@ParameterizedClass`.
 . Add a class-level `@MethodSource("methodName")` annotation where `methodName` is the
@@ -261,7 +261,7 @@ include::example$java/example/ParameterizedMigrationDemo.java[tags=after]
 ----
 ====
 
-[[migrating-from-junit4-rule-support]]
+[[rule-support]]
 == Limited JUnit 4 Rule Support
 
 WARNING: _JUnit 4 rule support_ is deprecated for removal since version 6.0.0. Please
@@ -292,13 +292,13 @@ This limited form of `Rule` support can be switched on by the class-level annota
 all rule migration support extensions: `VerifierSupport`, `ExternalResourceSupport`, and
 `ExpectedExceptionSupport`. You may alternatively choose to annotate your test class with
 `@EnableJUnit4MigrationSupport` which registers migration support for rules _and_ JUnit
-4's `@Ignore` annotation (see <<migrating-from-junit4-ignore-annotation-support>>).
+4's `@Ignore` annotation (see <<ignore-annotation-support>>).
 
 However, if you intend to develop a new extension for JUnit Jupiter please use the new
 extension model of JUnit Jupiter instead of the rule-based model of JUnit 4.
 
 
-[[migrating-from-junit4-ignore-annotation-support]]
+[[ignore-annotation-support]]
 == JUnit 4 @Ignore Support
 
 WARNING: _JUnit 4 `@Ignore` support_ is deprecated for removal since version 6.0.0. Please
@@ -312,7 +312,7 @@ To use `@Ignore` with JUnit Jupiter based tests, configure a _test_ dependency o
 `junit-jupiter-migrationsupport` module in your build and then annotate your test class
 with `@ExtendWith(IgnoreCondition.class)` or `{EnableJUnit4MigrationSupport}` (which
 automatically registers the `IgnoreCondition` along with
-<<migrating-from-junit4-rule-support>>). The `IgnoreCondition` is an
+<<rule-support>>). The `IgnoreCondition` is an
 `{ExecutionCondition}` that disables test classes or test methods that are annotated with
 `@Ignore`.
 
@@ -322,7 +322,7 @@ include::example$java/example/IgnoredTestsDemo.java[tags=user_guide]
 ----
 
 
-[[migrating-from-junit4-failure-message-arguments]]
+[[failure-message-arguments]]
 == Failure Message Arguments
 
 The `Assumptions` and `Assertions` classes in JUnit Jupiter declare arguments in a
diff --git a/documentation/modules/ROOT/pages/overview.adoc b/documentation/modules/ROOT/pages/overview.adoc
index a5f27923123c..5a48feea6e43 100644
--- a/documentation/modules/ROOT/pages/overview.adoc
+++ b/documentation/modules/ROOT/pages/overview.adoc
@@ -11,26 +11,26 @@ This document is also available as a link:{userGuidePdfFileName}[PDF download].
 endif::linkToPdf[]
 endif::backend-html5[]
 
-[[overview-what-is-junit]]
+[[what-is-junit]]
 == What is JUnit?
 
 JUnit is composed of several different modules from three different sub-projects.
 
 **JUnit {version} = _JUnit Platform_ + _JUnit Jupiter_ + _JUnit Vintage_**
 
-The **JUnit Platform** serves as a foundation for <<launcher-api,launching testing
-frameworks>> on the JVM. It also defines the `{TestEngine}` API for developing a testing
+The **JUnit Platform** serves as a foundation for xref:advanced-topics/launcher-api.adoc[launching testing
+frameworks] on the JVM. It also defines the `{TestEngine}` API for developing a testing
 framework that runs on the platform. Furthermore, the platform provides a
-<<running-tests-console-launcher,Console Launcher>> to launch the platform from the
-command line and the <<junit-platform-suite-engine>> for running a custom test suite using
+xref:running-tests/console-launcher.adoc[Console Launcher] to launch the platform from the
+command line and the xref:advanced-topics/junit-platform-suite-engine.adoc[] for running a custom test suite using
 one or more test engines on the platform. First-class support for the JUnit Platform also
-exists in popular IDEs (see <<running-tests-ide-intellij-idea>>,
-<<running-tests-ide-eclipse>>, <<running-tests-ide-netbeans>>, and
-<<running-tests-ide-vscode>>) and build tools (see <<running-tests-build-gradle>>,
-<<running-tests-build-maven>>, and <<running-tests-build-ant>>).
+exists in popular IDEs (see xref:running-tests/ide-support.adoc#intellij-idea[IntelliJ IDEA],
+xref:running-tests/ide-support.adoc#eclipse[Eclipse], xref:running-tests/ide-support.adoc#netbeans[NetBeans], and
+xref:running-tests/ide-support.adoc#vscode[Visual Studio Code]) and build tools (see xref:running-tests/build-support.adoc#gradle[Gradle],
+xref:running-tests/build-support.adoc#maven[Maven], and xref:running-tests/build-support.adoc#ant[Ant]).
 
-**JUnit Jupiter** is the combination of the <<writing-tests,programming model>> and
-<<extensions,extension model>> for writing JUnit tests and extensions. The Jupiter
+**JUnit Jupiter** is the combination of the xref:writing-tests/intro.adoc[programming model] and
+xref:extensions/overview.adoc[extension model] for writing JUnit tests and extensions. The Jupiter
 sub-project provides a `TestEngine` for running Jupiter based tests on the platform.
 
 **JUnit Vintage** provides a `TestEngine` for running JUnit 3 and JUnit 4 based tests on
@@ -39,42 +39,42 @@ path. Note, however, that the JUnit Vintage engine is deprecated and should only
 temporarily while migrating tests to JUnit Jupiter or another testing framework with
 native JUnit Platform support.
 
-[[overview-java-versions]]
+[[java-versions]]
 == Supported Java Versions
 
 JUnit requires Java 17 (or higher) at runtime. However, you can still test code that
 has been compiled with previous versions of the JDK.
 
-[[overview-getting-help]]
+[[getting-help]]
 == Getting Help
 
 Ask JUnit-related questions on {StackOverflow} or use the {DiscussionsQA}.
 
-[[overview-getting-started]]
+[[getting-started]]
 == Getting Started
 
-[[overview-getting-started-junit-artifacts]]
+[[getting-started-junit-artifacts]]
 === Downloading JUnit Artifacts
 
 To find out what artifacts are available for download and inclusion in your project, refer
-to <<dependency-metadata>>. To set up dependency management for your build, refer to
-<<running-tests-build>> and the <<overview-getting-started-example-projects>>.
+to xref:appendix.adoc#dependency-metadata[Dependency Metadata]. To set up dependency management for your build, refer to
+xref:running-tests/build-support.adoc[] and the <<getting-started-example-projects>>.
 
-[[overview-getting-started-features]]
+[[getting-started-features]]
 === JUnit Features
 
 To find out what features are available in JUnit {version} and how to use them, read the
 corresponding sections of this User Guide, organized by topic.
 
-* <<writing-tests, Writing Tests in JUnit Jupiter>>
-* <<migrating-from-junit4, Migrating from JUnit 4 to JUnit Jupiter>>
-* <<running-tests>>
-* <<extensions, Extension Model for JUnit Jupiter>>
+* xref:writing-tests/intro.adoc[Writing Tests in JUnit Jupiter]
+* xref:migrating-from-junit4.adoc[Migrating from JUnit 4 to JUnit Jupiter]
+* xref:running-tests/intro.adoc[]
+* xref:extensions/overview.adoc[Extension Model for JUnit Jupiter]
 * Advanced Topics
-  - <<launcher-api>>
-  - <<testkit>>
+  - xref:advanced-topics/launcher-api.adoc[]
+  - xref:advanced-topics/testkit.adoc[]
 
-[[overview-getting-started-example-projects]]
+[[getting-started-example-projects]]
 === Example Projects
 
 To see complete, working examples of projects that you can copy and experiment with, the
diff --git a/documentation/modules/ROOT/pages/release-notes.adoc b/documentation/modules/ROOT/pages/release-notes.adoc
index d1577a11de8a..f816e5a663dd 100644
--- a/documentation/modules/ROOT/pages/release-notes.adoc
+++ b/documentation/modules/ROOT/pages/release-notes.adoc
@@ -5,7 +5,7 @@
 
 This document contains the change log for all JUnit releases since 6.0 GA.
 
-Please refer to the <<../user-guide/index.adoc#user-guide,User Guide>> for comprehensive
+Please refer to the xref:overview.adoc[User Guide] for comprehensive
 reference documentation for programmers writing tests, extension authors, and engine
 authors as well as build tool and IDE vendors.
 
diff --git a/documentation/modules/ROOT/pages/running-tests/build-support.adoc b/documentation/modules/ROOT/pages/running-tests/build-support.adoc
index dcb14a1d1ec0..36978dcb5559 100644
--- a/documentation/modules/ROOT/pages/running-tests/build-support.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/build-support.adoc
@@ -1,6 +1,6 @@
 = Build Support
 
-[[running-tests-build-gradle]]
+[[gradle]]
 == Gradle
 
 Starting with https://docs.gradle.org/4.6/release-notes.html[version 4.6], Gradle provides
@@ -16,8 +16,8 @@ test {
 }
 ----
 
-Filtering by <<running-tests-tags, tags>>,
-<<running-tests-tag-expressions, tag expressions>>, or engines is also supported:
+Filtering by xref:running-tests/tags.adoc[tags],
+xref:running-tests/tags.adoc#expressions[tag expressions], or engines is also supported:
 
 [source,groovy,indent=0]
 [subs=attributes+]
@@ -36,14 +36,14 @@ Please refer to the
 https://docs.gradle.org/current/userguide/java_testing.html[official Gradle documentation]
 for a comprehensive list of options.
 
-[[running-tests-build-gradle-bom]]
+[[gradle-bom]]
 === Aligning dependency versions
 
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+TIP: See <<spring-boot>> for details on how to override the version
 of JUnit used in your Spring Boot application.
 
 Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+recommended to use the JUnit Platform xref:appendix.adoc#dependency-metadata-junit-bom[Bill of Materials (BOM)] to align the
 versions of all JUnit artifacts.
 
 [source,groovy,indent=0]
@@ -87,11 +87,11 @@ dependency on `junit-platform-launcher`, it is recommended to do so to ensure th
 of JUnit artifacts on the test runtime classpath are aligned.
 
 Moreover, doing so is recommended and in some cases even required when importing the
-project into an IDE like <<running-tests-ide-eclipse>> or
-<<running-tests-ide-intellij-idea>>.
+project into an IDE like xref:running-tests/ide-support.adoc#eclipse[Eclipse] or
+xref:running-tests/ide-support.adoc#intellij-idea[IntelliJ IDEA].
 ====
 
-[[running-tests-build-gradle-engines-configure]]
+[[gradle-engines-configure]]
 === Configuring Test Engines
 
 In order to run any tests at all, a `TestEngine` implementation must be on the classpath.
@@ -152,11 +152,11 @@ dependencies {
 }
 ----
 
-[[running-tests-build-gradle-config-params]]
+[[gradle-config-params]]
 === Configuration Parameters
 
 The standard Gradle `test` task currently does not provide a dedicated DSL to set JUnit
-Platform <<running-tests-config-params, configuration parameters>> to influence test
+Platform xref:running-tests/configuration-parameters.adoc[configuration parameters] to influence test
 discovery and execution. However, you can provide configuration parameters within the
 build script via system properties (as shown below) or via the
 `junit-platform.properties` file.
@@ -172,7 +172,7 @@ test {
 }
 ----
 
-[[running-tests-build-gradle-logging]]
+[[gradle-logging]]
 === Configuring Logging (optional)
 
 JUnit uses the Java Logging APIs in the `java.util.logging` package (a.k.a. _JUL_) to
@@ -201,7 +201,7 @@ Other logging frameworks provide different means to redirect messages logged usi
 https://www.slf4j.org/legacy.html#jul-to-slf4j[JUL to SLF4J Bridge] by adding it as a
 dependency to the test runtime classpath.
 
-[[running-tests-build-maven]]
+[[maven]]
 == Maven
 
 Maven Surefire and Maven Failsafe provide
@@ -216,11 +216,11 @@ and can serve as a starting point for configuring your Maven build.
 As of JUnit 6.0, the minimum required version of Maven Surefire/Failsafe is 3.0.0.
 ====
 
-[[running-tests-build-maven-bom]]
+[[maven-bom]]
 === Aligning dependency versions
 
 Unless you're using Spring Boot which defines its own way of managing dependencies, it is
-recommended to use the JUnit Platform <<dependency-metadata-junit-bom>> to align the
+recommended to use the JUnit Platform xref:appendix.adoc#dependency-metadata-junit-bom[Bill of Materials (BOM)] to align the
 versions of all JUnit artifacts.
 
 [source,xml,indent=0]
@@ -242,10 +242,10 @@ versions of all JUnit artifacts.
 Using the BOM allows you to omit the version when declaring dependencies on all artifacts
 with the `org.junit.platform`, `org.junit.jupiter`, and `org.junit.vintage` group IDs.
 
-TIP: See <<running-tests-build-spring-boot>> for details on how to override the version
+TIP: See <<spring-boot>> for details on how to override the version
 of JUnit used in your Spring Boot application.
 
-[[running-tests-build-maven-engines-configure]]
+[[maven-engines-configure]]
 === Configuring Test Engines
 
 In order to have Maven Surefire or Maven Failsafe run any tests at all, at least one
@@ -324,7 +324,7 @@ long as you configure `test` scoped dependencies on JUnit 4 and the JUnit Vintag
 	<!-- ... -->
 ----
 
-[[running-tests-build-maven-filter-test-class-names]]
+[[maven-filter-test-class-names]]
 === Filtering by Test Class Names
 
 The Maven Surefire Plugin will scan for test classes whose fully qualified names match
@@ -366,11 +366,11 @@ Please see the
 https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html[Inclusions and Exclusions of Tests]
 documentation for Maven Surefire for details.
 
-[[running-tests-build-maven-filter-tags]]
+[[maven-filter-tags]]
 === Filtering by Tags
 
-You can filter tests by <<running-tests-tags, tags>> or
-<<running-tests-tag-expressions, tag expressions>> using the following configuration
+You can filter tests by xref:running-tests/tags.adoc[tags] or
+xref:running-tests/tags.adoc#expressions[tag expressions] using the following configuration
 properties.
 
 - to include _tags_ or _tag expressions_, use `groups`.
@@ -395,10 +395,10 @@ properties.
 	<!-- ... -->
 ----
 
-[[running-tests-build-maven-config-params]]
+[[maven-config-params]]
 === Configuration Parameters
 
-You can set JUnit Platform <<running-tests-config-params, configuration parameters>> to
+You can set JUnit Platform xref:running-tests/configuration-parameters.adoc[configuration parameters] to
 influence test discovery and execution by declaring the `configurationParameters`
 property and providing key-value pairs using the Java `Properties` file syntax (as shown
 below) or via the `junit-platform.properties` file.
@@ -427,7 +427,7 @@ below) or via the `junit-platform.properties` file.
 	<!-- ... -->
 ----
 
-[[running-tests-build-ant]]
+[[ant]]
 == Ant
 
 Starting with version `1.10.3`, link:https://ant.apache.org/[Ant] has a
@@ -504,7 +504,7 @@ For further details on usage and configuration options please refer to the offic
 documentation for the
 link:https://ant.apache.org/manual/Tasks/junitlauncher.html[`junitlauncher` task].
 
-[[running-tests-build-spring-boot]]
+[[spring-boot]]
 == Spring Boot
 
 link:https://spring.io/projects/spring-boot[Spring Boot] provides automatic support for
@@ -513,7 +513,7 @@ managing the version of JUnit used in your project. In addition, the
 Jupiter, AssertJ, Mockito, etc.
 
 If your build relies on dependency management support from Spring Boot, you should not
-import JUnit's <<dependency-metadata-junit-bom>> in your build script since that would
+import JUnit's xref:appendix.adoc#dependency-metadata-junit-bom[Bill of Materials (BOM)] in your build script since that would
 result in duplicate (and potentially conflicting) management of JUnit dependencies.
 
 If you need to override the version of a dependency used in your Spring Boot application,
diff --git a/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc b/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc
index a8d6ca7e0509..a15cb60ab1f8 100644
--- a/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/capturing-standard-output-error.adoc
@@ -2,8 +2,8 @@
 
 The JUnit Platform provides opt-in support for capturing output printed to `System.out`
 and `System.err`. To enable it, set the `junit.platform.output.capture.stdout` and/or
-`junit.platform.output.capture.stderr` <<running-tests-config-params, configuration
-parameter>> to `true`. In addition, you may configure the maximum number of buffered bytes
+`junit.platform.output.capture.stderr` xref:running-tests/configuration-parameters.adoc[configuration
+parameter] to `true`. In addition, you may configure the maximum number of buffered bytes
 to be used per executed test or container using `junit.platform.output.capture.maxBuffer`.
 
 If enabled, the JUnit Platform captures the corresponding output and publishes it as a
@@ -14,5 +14,5 @@ finished.
 Please note that the captured output will only contain output emitted by the thread that
 was used to execute a container or test. Any output by other threads will be omitted
 because particularly when
-<<writing-tests-parallel-execution, executing tests in parallel>> it would be impossible
+xref:writing-tests/parallel-execution.adoc[executing tests in parallel] it would be impossible
 to attribute it to a specific test or container.
diff --git a/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc b/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc
index 5e43efa01b84..8688d0e27862 100644
--- a/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/configuration-parameters.adoc
@@ -6,29 +6,29 @@ configuration parameters that are specific to a particular test engine, listener
 registered extension. For example, the JUnit Jupiter `TestEngine` supports _configuration
 parameters_ for the following use cases.
 
-- <<writing-tests-test-instance-lifecycle-changing-default>>
-- <<extensions-registration-automatic-enabling>>
-- <<extensions-conditions-deactivation>>
-- <<writing-tests-display-name-generator-default>>
+- xref:writing-tests/test-instance-lifecycle.adoc#default[Changing the Default Test Instance Lifecycle]
+- xref:extensions/registering-extensions.adoc#registration-automatic-enabling[Enabling Automatic Extension Detection]
+- xref:extensions/conditional-test-execution.adoc#deactivation[Deactivating Conditions]
+- xref:writing-tests/display-names.adoc#generator-default[Setting the Default Display Name Generator]
 
 _Configuration Parameters_ are text-based key-value pairs that can be supplied to test
 engines running on the JUnit Platform via one of the following mechanisms.
 
 1. The `configurationParameter()` and `configurationParameters()` methods in
    `LauncherDiscoveryRequestBuilder` which
-   is used to build a request supplied to the <<launcher-api, Launcher API>>.
+   is used to build a request supplied to the xref:advanced-topics/launcher-api.adoc[Launcher API].
     +
    When running tests via one of the tools provided by the JUnit Platform you can specify
    configuration parameters as follows:
-   * <<running-tests-console-launcher,Console Launcher>>: use the `--config` command-line
+   * xref:running-tests/console-launcher.adoc[Console Launcher]: use the `--config` command-line
      option.
-   * <<running-tests-build-gradle-config-params,Gradle>>: use the `systemProperty` or
+   * xref:running-tests/build-support.adoc#gradle-config-params[Gradle]: use the `systemProperty` or
      `systemProperties` DSL.
-   * <<running-tests-build-maven-config-params,Maven Surefire provider>>: use the
+   * xref:running-tests/build-support.adoc#maven-config-params[Maven Surefire provider]: use the
      `configurationParameters` property.
 2. The `configurationParametersResources()` method in `LauncherDiscoveryRequestBuilder`.
     +
-   When running tests via the <<running-tests-console-launcher,Console Launcher>> you can
+   When running tests via the xref:running-tests/console-launcher.adoc[Console Launcher] you can
    specify custom configuration files using the `--config-resource` command-line option.
 3. JVM system properties.
 4. The JUnit Platform default configuration file: a file named `junit-platform.properties`
@@ -41,16 +41,16 @@ precedence over those supplied via custom configuration files, system properties
 default configuration file. Similarly, configuration parameters supplied via system
 properties take precedence over those supplied via the default configuration file.
 
-[[running-tests-config-params-deactivation-pattern]]
+[[pattern]]
 == Pattern Matching Syntax
 
 This section describes the pattern matching syntax that is applied to the _configuration
 parameters_ used for the following features.
 
-- <<extensions-conditions-deactivation>>
-- <<launcher-api-listeners-custom-deactivation>>
-- <<stacktrace-pruning>>
-- <<extensions-registration-automatic-filtering>>
+- xref:extensions/conditional-test-execution.adoc#deactivation[Deactivating Conditions]
+- xref:advanced-topics/launcher-api.adoc#listeners-custom-deactivation[Deactivating a TestExecutionListener]
+- xref:running-tests/stack-trace-pruning.adoc[]
+- xref:extensions/registering-extensions.adoc#registration-automatic-filtering[Filtering Auto-detected Extensions]
 
 If the value for the given _configuration parameter_ consists solely of an asterisk
 (`+++*+++`), the pattern will match against all candidate classes. Otherwise, the value
diff --git a/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc b/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc
index 75ae13ce2f7f..1e7da4d9bd48 100644
--- a/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/console-launcher.adoc
@@ -10,7 +10,7 @@ repository under the
 https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone[junit-platform-console-standalone]
 directory. It contains the contents of the following artifacts:
 
-include::{standaloneConsoleLauncherShadowedArtifactsFile}[]
+include::partial$console-launcher-standalone-shadowed-artifacts.adoc[]
 
 [NOTE]
 ====
@@ -26,7 +26,7 @@ If you need to declare dependencies in your build script on some of the artifact
 contained in the `junit-platform-console-standalone` artifact, you should declare
 dependencies only on the JUnit artifacts that are used in your project. To simplify
 dependency management of JUnit artifacts in your build, you may wish to use the
-`junit-jupiter` aggregator artifact or `junit-bom`. See <<dependency-metadata>> for
+`junit-jupiter` aggregator artifact or `junit-bom`. See xref:appendix.adoc#dependency-metadata[Dependency Metadata] for
 details.
 ====
 
@@ -72,23 +72,23 @@ all jars in a directory):
 $ java -cp classes:testlib/* org.junit.platform.console.ConsoleLauncher <OPTIONS>
 ----
 
-[[running-tests-console-launcher-options]]
+[[options]]
 == Subcommands and Options
 
 The `{ConsoleLauncher}` provides the following subcommands:
 
 ----
-include::{consoleLauncherOptionsFile}[]
+include::partial$console-launcher-options.txt[]
 ----
 
-[[running-tests-console-launcher-options-discovering-tests]]
+[[options-discovering-tests]]
 === Discovering tests
 
 ----
-include::{consoleLauncherDiscoverOptionsFile}[]
+include::partial$console-launcher-discover-options.txt[]
 ----
 
-[[running-tests-console-launcher-options-executing-tests]]
+[[options-executing-tests]]
 === Executing tests
 
 .Exit Code
@@ -100,17 +100,17 @@ with a status code of `2`. Unexpected or invalid user input yields a status code
 of `3`. An exit code of `-1` indicates an unspecified error condition.
 
 ----
-include::{consoleLauncherExecuteOptionsFile}[]
+include::partial$console-launcher-execute-options.txt[]
 ----
 
-[[running-tests-console-launcher-options-listing-test-engines]]
+[[options-listing-test-engines]]
 === Listing test engines
 
 ----
-include::{consoleLauncherEnginesOptionsFile}[]
+include::partial$console-launcher-engines-options.txt[]
 ----
 
-[[running-tests-console-launcher-argument-files]]
+[[argument-files]]
 == Argument Files (@-files)
 
 On some platforms you may run into system limitations on the length of a command line when
@@ -138,7 +138,7 @@ You can pass a real parameter with an initial `@` character by escaping it with
 additional `@` symbol. For example, `@@somearg` will become `@somearg` and will not be
 subject to expansion.
 
-[[running-tests-console-launcher-redirecting-stdout-and-stderr]]
+[[redirecting-stdout-and-stderr]]
 == Redirecting Standard Output/Error to Files
 
 You can redirect the `System.out` (stdout) and `System.err` (stderr) output streams to
@@ -159,7 +159,7 @@ output streams will be redirected to that file.
 The default charset is used for writing to the files.
 ====
 
-[[running-tests-console-launcher-color-customization]]
+[[color-customization]]
 == Color Customization
 
 The colors used in the output of the `{ConsoleLauncher}` can be customized.
diff --git a/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc b/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc
index b4d06dff4bb9..c2f358be82b4 100644
--- a/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/discovery-issues.adoc
@@ -2,7 +2,7 @@
 
 Test engines may encounter issues during test discovery. For example, the declaration of a
 test class or method may be invalid. To avoid such issues from going unnoticed, the JUnit
-Platform provides a <<test-engines-discovery-issues, mechanism for test engines>> to
+Platform provides a xref:advanced-topics/engines.adoc#discovery-issues[mechanism for test engines] to
 report them with different severity levels:
 
 INFO::
@@ -22,7 +22,7 @@ _critical_ severity, its tests will not be executed. Instead, the engine will be
 as failed during execution with a `{DiscoveryIssueException}` listing all critical issues.
 Non-critical issues will be logged but will not prevent the engine from executing its
 tests. The `junit.platform.discovery.issue.severity.critical`
-<<running-tests-config-params, configuration parameter>> can be used to set the critical
+xref:running-tests/configuration-parameters.adoc[configuration parameter] can be used to set the critical
 severity level. Currently, the default value is `ERROR` but it may be changed in a future
 release.
 
diff --git a/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc b/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc
index 68dc2a0d9a98..5ee75c0d9044 100644
--- a/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/discovery-selectors.adoc
@@ -5,7 +5,7 @@ which tests should be discovered or executed.
 
 Discovery selectors can be created programmatically using the factory methods in the
 `{DiscoverySelectors}` class, specified declaratively via annotations when using the
-<<junit-platform-suite-engine>>, via options of the <<running-tests-console-launcher>>, or
+xref:advanced-topics/junit-platform-suite-engine.adoc[], via options of the xref:running-tests/console-launcher.adoc[], or
 generically as strings via their identifiers.
 
 The following discovery selectors are provided out of the box:
diff --git a/documentation/modules/ROOT/pages/running-tests/ide-support.adoc b/documentation/modules/ROOT/pages/running-tests/ide-support.adoc
index d3330c3c1038..2cb3d8b551f0 100644
--- a/documentation/modules/ROOT/pages/running-tests/ide-support.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/ide-support.adoc
@@ -1,6 +1,6 @@
 = IDE Support
 
-[[running-tests-ide-intellij-idea]]
+[[intellij-idea]]
 == IntelliJ IDEA
 
 IntelliJ IDEA supports running tests on the JUnit Platform since version 2016.2. For more
@@ -58,7 +58,7 @@ testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
 </dependencyManagement>
 ----
 
-[[running-tests-ide-eclipse]]
+[[eclipse]]
 == Eclipse
 
 Eclipse IDE offers support for the JUnit Platform since the Eclipse Oxygen.1a (4.7.1a)
@@ -69,7 +69,7 @@ support for JUnit 5_ section of the
 https://www.eclipse.org/eclipse/news/4.7.1a/#junit-5-support[Eclipse Project Oxygen.1a
 (4.7.1a) - New and Noteworthy] documentation.
 
-[[running-tests-ide-netbeans]]
+[[netbeans]]
 == NetBeans
 
 NetBeans offers support for JUnit Jupiter and the JUnit Platform since the
@@ -79,7 +79,7 @@ For more information consult the JUnit 5 section of the
 https://netbeans.apache.org/download/nb100/index.html#_junit_5[Apache NetBeans 10.0
 release notes].
 
-[[running-tests-ide-vscode]]
+[[vscode]]
 == Visual Studio Code
 
 https://code.visualstudio.com/[Visual Studio Code] supports JUnit Jupiter and the JUnit
@@ -93,9 +93,9 @@ For more information consult the _Testing_ section of the
 https://code.visualstudio.com/docs/languages/java#_testing[Java in Visual Studio Code]
 documentation.
 
-[[running-tests-ide-other]]
+[[other]]
 == Other IDEs
 
 If you are using an editor or IDE other than one of those listed in the previous sections,
 and it doesn't support running tests on the JUnit Platform, you can use the
-<<running-tests-console-launcher>> to run them from the command line.
+xref:running-tests/console-launcher.adoc[] to run them from the command line.
diff --git a/documentation/modules/ROOT/pages/running-tests/tags.adoc b/documentation/modules/ROOT/pages/running-tests/tags.adoc
index 79c807264375..c99cfea4802a 100644
--- a/documentation/modules/ROOT/pages/running-tests/tags.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/tags.adoc
@@ -3,12 +3,12 @@
 Tags are a JUnit Platform concept for marking and filtering tests. The programming model
 for adding tags to containers and tests is defined by the testing framework. For example,
 in JUnit Jupiter based tests, the `@Tag` annotation (see
-<<writing-tests-tagging-and-filtering>>) should be used. For JUnit 4 based tests, the
+xref:writing-tests/tagging-and-filtering.adoc[]) should be used. For JUnit 4 based tests, the
 Vintage engine maps `@Category` annotations to tags (see
-<<migrating-from-junit4-categories-support>>). Other testing frameworks may define their
+xref:migrating-from-junit4.adoc#categories-support[Categories Support]). Other testing frameworks may define their
 own annotation or other means for users to specify tags.
 
-[[running-tests-tag-syntax-rules]]
+[[syntax-rules]]
 == Syntax Rules for Tags
 
 Regardless how a tag is specified, the JUnit Platform enforces the following rules:
@@ -27,7 +27,7 @@ Regardless how a tag is specified, the JUnit Platform enforces the following rul
 NOTE: In the above context, "stripped" means that leading and trailing whitespace
 characters have been removed using `java.lang.String.strip()`.
 
-[[running-tests-tag-expressions]]
+[[expressions]]
 == Tag Expressions
 
 Tag expressions are boolean expressions with the operators `!`, `&` and `|`. In addition,
diff --git a/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc b/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc
index 8e03a5a22c94..e69ad7165e4b 100644
--- a/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc
+++ b/documentation/modules/ROOT/pages/running-tests/using-listeners-and-interceptors.adoc
@@ -23,28 +23,28 @@ for you automatically. You can also implement and register your own listeners.
 For details on registering and configuring listeners, see the following sections of this
 guide.
 
-* <<launcher-api-launcher-session-listeners-custom>>
-* <<launcher-api-launcher-interceptors-custom>>
-* <<launcher-api-launcher-discovery-listeners-custom>>
-* <<launcher-api-listeners-custom>>
-* <<launcher-api-listeners-config>>
-* <<launcher-api-listeners-custom-deactivation>>
+* xref:advanced-topics/launcher-api.adoc#launcher-session-listeners-custom[Registering a LauncherSessionListener]
+* xref:advanced-topics/launcher-api.adoc#launcher-interceptors-custom[Registering a LauncherInterceptor]
+* xref:advanced-topics/launcher-api.adoc#launcher-discovery-listeners-custom[Registering a LauncherDiscoveryListener]
+* xref:advanced-topics/launcher-api.adoc#listeners-custom[Registering a TestExecutionListener]
+* xref:advanced-topics/launcher-api.adoc#listeners-config[Configuring a TestExecutionListener]
+* xref:advanced-topics/launcher-api.adoc#listeners-custom-deactivation[Deactivating a TestExecutionListener]
 
 The JUnit Platform provides the following listeners which you may wish to use with your
 test suite.
 
-<<junit-platform-reporting>> ::
+xref:advanced-topics/junit-platform-reporting.adoc[] ::
   `{LegacyXmlReportGeneratingListener}` can be used via the
-  <<running-tests-console-launcher>> or registered manually to generate XML reports
+  xref:running-tests/console-launcher.adoc[] or registered manually to generate XML reports
   compatible with the de facto standard for JUnit 4 based test reports.
 +
 `{OpenTestReportGeneratingListener}` generates an XML report in the event-based format
 specified by {OpenTestReporting}. It is auto-registered and can be enabled and
-configured via <<running-tests-config-params>>.
+configured via xref:running-tests/configuration-parameters.adoc[].
 +
-See <<junit-platform-reporting>> for details.
+See xref:advanced-topics/junit-platform-reporting.adoc[] for details.
 
-<<running-tests-listeners-flight-recorder>> ::
+<<recorder>> ::
   `FlightRecordingExecutionListener` and `FlightRecordingDiscoveryListener` that generate
   Java Flight Recorder events during test discovery and execution.
 
@@ -61,7 +61,7 @@ See <<junit-platform-reporting>> for details.
   or executed during the execution of the `TestPlan` and generates a file containing the
   unique IDs once execution of the `TestPlan` has finished.
 
-[[running-tests-listeners-flight-recorder]]
+[[recorder]]
 == Flight Recorder Support
 
 The JUnit Platform provides opt-in support for generating Flight Recorder events.
diff --git a/documentation/modules/ROOT/pages/writing-tests/annotations.adoc b/documentation/modules/ROOT/pages/writing-tests/annotations.adoc
index 90fd500c730f..33d1c1e9f7a7 100644
--- a/documentation/modules/ROOT/pages/writing-tests/annotations.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/annotations.adoc
@@ -12,41 +12,41 @@ operate based on their own dedicated annotations. Such methods are inherited unl
 are overridden.
 
 `*@ParameterizedTest*`:: Denotes that a method is a
-<<writing-tests-parameterized-tests, parameterized test>>. Such methods are inherited
+xref:writing-tests/parameterized-classes-and-tests.adoc[parameterized test]. Such methods are inherited
 unless they are overridden.
 
 `*@RepeatedTest*`:: Denotes that a method is a test template for a
-<<writing-tests-repeated-tests, repeated test>>. Such methods are inherited unless they
+xref:writing-tests/repeated-tests.adoc[repeated test]. Such methods are inherited unless they
 are overridden.
 
 `*@TestFactory*`:: Denotes that a method is a test factory for
-<<writing-tests-dynamic-tests, dynamic tests>>. Such methods are inherited unless they are
+xref:writing-tests/dynamic-tests.adoc[dynamic tests]. Such methods are inherited unless they are
 overridden.
 
 `*@TestTemplate*`:: Denotes that a method is a
-<<writing-tests-test-templates, template for a test case>> designed to be invoked multiple
+xref:writing-tests/test-templates.adoc[template for a test case] designed to be invoked multiple
 times depending on the number of invocation contexts returned by the registered
-<<extensions-test-templates, providers>>. Such methods are inherited unless they are
+xref:extensions/providing-invocation-contexts-for-test-templates.adoc[providers]. Such methods are inherited unless they are
 overridden.
 
 `*@TestClassOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-classes, test class execution order>> for `@Nested`
+xref:writing-tests/test-execution-order.adoc#classes[test class execution order] for `@Nested`
 test classes in the annotated test class. Such annotations are inherited.
 
 `*@TestMethodOrder*`:: Used to configure the
-<<writing-tests-test-execution-order-methods, test method execution order>> for the
+xref:writing-tests/test-execution-order.adoc#methods[test method execution order] for the
 annotated test class; similar to JUnit 4's `@FixMethodOrder`. Such annotations are
 inherited.
 
 `*@TestInstance*`:: Used to configure the
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> for the annotated test
+xref:writing-tests/test-instance-lifecycle.adoc[test instance lifecycle] for the annotated test
 class. Such annotations are inherited.
 
-`*@DisplayName*`:: Declares a custom <<writing-tests-display-names,display name>> for the
+`*@DisplayName*`:: Declares a custom xref:writing-tests/display-names.adoc[display name] for the
 test class or test method. Such annotations are not inherited.
 
 `*@DisplayNameGeneration*`:: Declares a custom
-<<writing-tests-display-name-generator, display name generator>> for the test class. Such
+xref:writing-tests/display-names.adoc#generator[display name generator] for the test class. Such
 annotations are inherited.
 
 `*@BeforeEach*`:: Denotes that the annotated method should be executed _before_ *each*
@@ -63,68 +63,68 @@ overridden.
 `@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
 top-level or `@Nested` test class; analogous to JUnit 4's `@BeforeClass`. Such methods are
 inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+xref:writing-tests/test-instance-lifecycle.adoc[test instance lifecycle] is used.
 
 `*@AfterAll*`:: Denotes that the annotated method should be executed _after_ *all*
 `@Test`, `@RepeatedTest`, `@ParameterizedTest`, and `@TestFactory` methods in the current
 top-level or `@Nested` test class; analogous to JUnit 4's `@AfterClass`. Such methods are
 inherited unless they are overridden and must be `static` unless the "per-class"
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> is used.
+xref:writing-tests/test-instance-lifecycle.adoc[test instance lifecycle] is used.
 
 `*@ParameterizedClass*`:: Denotes that the annotated class is a
-<<writing-tests-parameterized-tests, parameterized class>>. Such annotations are
+xref:writing-tests/parameterized-classes-and-tests.adoc[parameterized class]. Such annotations are
 inherited.
 
 `*@BeforeParameterizedClassInvocation*`:: Denotes that the annotated method should be
 executed once _before_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+xref:writing-tests/parameterized-classes-and-tests.adoc[parameterized class]. Such methods are inherited
 unless they are overridden.
 
 `*@AfterParameterizedClassInvocation*`:: Denotes that the annotated method should be
 executed once _after_ each invocation of a
-<<writing-tests-parameterized-tests, parameterized class>>. Such methods are inherited
+xref:writing-tests/parameterized-classes-and-tests.adoc[parameterized class]. Such methods are inherited
 unless they are overridden.
 
 `*@ClassTemplate*`:: Denotes that the annotated class is a
-<<writing-tests-class-templates, template for a test class>> designed to be executed
+xref:writing-tests/class-templates.adoc[template for a test class] designed to be executed
 multiple times depending on the number of invocation contexts returned by the registered
-<<extensions-class-templates, providers>>. Such annotations are inherited.
+xref:extensions/providing-invocation-contexts-for-class-templates.adoc[providers]. Such annotations are inherited.
 
 `*@Nested*`:: Denotes that the annotated class is a non-static
-<<writing-tests-nested, nested test class>>. Such annotations are not inherited.
+xref:writing-tests/nested-tests.adoc[nested test class]. Such annotations are not inherited.
 
 `*@Tag*`:: Used to declare
-<<writing-tests-tagging-and-filtering, tags for filtering tests>>, either at the class or
+xref:writing-tests/tagging-and-filtering.adoc[tags for filtering tests], either at the class or
 method level; analogous to test groups in TestNG or Categories in JUnit 4. Such
 annotations are inherited at the class level but not at the method level.
 
-`*@Disabled*`:: Used to <<writing-tests-disabling, disable>> a test class or test method;
+`*@Disabled*`:: Used to xref:writing-tests/disabling-tests.adoc[disable] a test class or test method;
 analogous to JUnit 4's `@Ignore`. Such annotations are not inherited.
 
 `*@AutoClose*`:: Denotes that the annotated field represents a resource that will be
-<<writing-tests-built-in-extensions-AutoClose, automatically closed>> after test
+xref:writing-tests/built-in-extensions.adoc#AutoClose[automatically closed] after test
 execution. Such fields are inherited.
 
 `*@Timeout*`:: Used to fail a test, test factory, test template, or lifecycle method if
 its execution exceeds a given duration. Such annotations are inherited.
 
 `*@TempDir*`:: Used to supply a
-<<writing-tests-built-in-extensions-TempDirectory, temporary directory>> via field
+xref:writing-tests/built-in-extensions.adoc#TempDirectory[temporary directory] via field
 injection or parameter injection in a test class constructor, lifecycle method, or test
 method; located in the `org.junit.jupiter.api.io` package. Such fields are inherited.
 
 `*@ExtendWith*`:: Used to
-<<extensions-registration-declarative, register extensions declaratively>>. Such
+xref:extensions/registering-extensions.adoc#registration-declarative[register extensions declaratively]. Such
 annotations are inherited.
 
 `*@RegisterExtension*`:: Used to
-<<extensions-registration-programmatic, register extensions programmatically>> via fields.
+xref:extensions/registering-extensions.adoc#registration-programmatic[register extensions programmatically] via fields.
 Such fields are inherited.
 
 WARNING: Some annotations may currently be _experimental_. Consult the table in
-<<api-evolution-experimental-apis>> for details.
+xref:api-evolution.adoc#experimental-apis[Experimental APIs] for details.
 
-[[writing-tests-meta-annotations]]
+[[annotations]]
 == Meta-Annotations and Composed Annotations
 
 JUnit Jupiter annotations can be used as _meta-annotations_. That means that you can
@@ -132,7 +132,7 @@ define your own _composed annotation_ that will automatically _inherit_ the sema
 its meta-annotations.
 
 For example, instead of copying and pasting `@Tag("fast")` throughout your code base (see
-<<writing-tests-tagging-and-filtering>>), you can create a custom _composed annotation_
+xref:writing-tests/tagging-and-filtering.adoc[]), you can create a custom _composed annotation_
 named `@Fast` as follows. `@Fast` can then be used as a drop-in replacement for
 `@Tag("fast")`.
 
diff --git a/documentation/modules/ROOT/pages/writing-tests/assertions.adoc b/documentation/modules/ROOT/pages/writing-tests/assertions.adoc
index 6166f3597124..71a36ee2c467 100644
--- a/documentation/modules/ROOT/pages/writing-tests/assertions.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/assertions.adoc
@@ -16,7 +16,7 @@ complex or time-consuming, as it is only evaluated when the assertion fails.
 include::example$java/example/AssertionsDemo.java[tags=user_guide]
 ----
 
-[[writing-tests-assertions-preemptive-timeouts]]
+[[preemptive-timeouts]]
 [WARNING]
 .Preemptive Timeouts with `assertTimeoutPreemptively()`
 ====
@@ -38,7 +38,7 @@ Similar side effects may be encountered with other frameworks that rely on
 `ThreadLocal` storage.
 ====
 
-[[writing-tests-assertions-kotlin]]
+[[kotlin]]
 == Kotlin Assertion Support
 
 JUnit Jupiter also comes with a few assertion methods that lend themselves well to being
@@ -50,7 +50,7 @@ functions in the `org.junit.jupiter.api` package.
 include::example$kotlin/example/KotlinAssertionsDemo.kt[tags=user_guide]
 ----
 
-[[writing-tests-assertions-third-party]]
+[[third-party]]
 == Third-party Assertion Libraries
 
 Even though the assertion facilities provided by JUnit Jupiter are sufficient for many
diff --git a/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc b/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc
index 67804ac7ed65..3d5fa42d45c5 100644
--- a/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/built-in-extensions.adoc
@@ -5,7 +5,7 @@ separate libraries, JUnit Jupiter includes a few user-facing extension implement
 that are considered so generally useful that users shouldn't have to add another
 dependency.
 
-[[writing-tests-built-in-extensions-TempDirectory]]
+[[TempDirectory]]
 == The @TempDir Extension
 
 The built-in `{TempDirectory}` extension is used to create and clean up a temporary
@@ -51,7 +51,7 @@ temporary directory will only be deleted after the test if the test completed su
 
 The default cleanup mode is `ALWAYS`. You can use the
 `junit.jupiter.tempdir.cleanup.mode.default`
-<<running-tests-config-params, configuration parameter>> to override this default.
+xref:running-tests/configuration-parameters.adoc[configuration parameter] to override this default.
 
 [source,java,indent=0]
 .A test class with a temporary directory that doesn't get cleaned up
@@ -92,7 +92,7 @@ temporary directory. The following example demonstrates how to achieve that.
 include::example$java/example/TempDirectoryDemo.java[tags=user_guide_factory_jimfs]
 ----
 
-`@TempDir` can also be used as a <<writing-tests-meta-annotations, meta-annotation>> to
+`@TempDir` can also be used as a xref:writing-tests/annotations.adoc#annotations[meta-annotation] to
 reduce repetition. The following code listing shows how to create a custom `@JimfsTempDir`
 annotation that can be used as a drop-in replacement for
 `@TempDir(factory = JimfsTempDirFactory.class)`.
@@ -116,8 +116,7 @@ annotation is declared on might expose additional attributes to configure the fa
 Such annotations and related attributes can be accessed via the `AnnotatedElementContext`
 parameter of the `createTempDirectory(...)` method.
 
-You can use the `junit.jupiter.tempdir.factory.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
+You can use the `junit.jupiter.tempdir.factory.default` xref:running-tests/configuration-parameters.adoc[configuration parameter] to specify the fully qualified class name of the
 `TempDirFactory` you would like to use by default. Just like for factories configured via
 the `factory` attribute of the `@TempDir` annotation, the supplied class has to implement
 the `TempDirFactory` interface. The default factory will be used for all `@TempDir`
@@ -131,7 +130,7 @@ precedence rules:
 parameter, if present
 3. Otherwise, `org.junit.jupiter.api.io.TempDirFactory$Standard` will be used.
 
-[[writing-tests-built-in-extensions-AutoClose]]
+[[AutoClose]]
 == The @AutoClose Extension
 
 The built-in `{AutoCloseExtension}` automatically closes resources associated with fields.
@@ -180,7 +179,7 @@ include::example$java/example/AutoCloseDemo.java[tags=user_guide_example]
 <2> `WebClient` implements `java.lang.AutoCloseable` which defines a `close()` method that
     will be invoked after each `@Test` method.
 
-[[writing-tests-built-in-extensions-DefaultLocaleAndTimeZone]]
+[[DefaultLocaleAndTimeZone]]
 == The @DefaultLocale and @DefaultTimeZone Extensions
 
 The `{DefaultLocale}` and `{DefaultTimeZone}` annotations can be used to change the values
@@ -190,7 +189,7 @@ work on the test class level and on the test method level, and are inherited fro
 higher-level containers. After the annotated element has been executed, the initial
 default value is restored.
 
-[[writing-tests-built-in-extensions-DefaultLocale]]
+[[DefaultLocale]]
 === @DefaultLocale
 
 The default `Locale` can be specified using an
@@ -241,7 +240,7 @@ include::example$java/example/DefaultLocaleTimezoneExtensionDemo.java[tag=defaul
 
 NOTE: The provider implementation must have a no-args (or the default) constructor.
 
-[[writing-tests-built-in-extensions-DefaultTimeZone]]
+[[DefaultTimeZone]]
 === @DefaultTimeZone
 
 The default `TimeZone` is specified according to the
@@ -275,7 +274,7 @@ NOTE: The provider implementation must have a no-args (or the default) construct
 === Thread Safety
 
 Since the default locale and time zone are global state, reading and writing them during
-<<writing-tests-parallel-execution, parallel test execution>> can lead to unpredictable
+xref:writing-tests/parallel-execution.adoc[parallel test execution] can lead to unpredictable
 results and flaky tests. The `@DefaultLocale` and `@DefaultTimeZone` extensions are
 prepared for that and tests annotated with them will never execute in parallel (thanks to
 `{ResourceLock}`) to guarantee correct test results.
diff --git a/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc b/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc
index 9159045675f6..b82f9f1e9353 100644
--- a/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/class-templates.adoc
@@ -6,7 +6,7 @@ contexts returned by the registered providers. Thus, it must be used in conjunct
 registered `{ClassTemplateInvocationContextProvider}` extension.
 Each invocation of a class template behaves like the execution of a regular test class
 with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-class-templates>> for usage examples.
+xref:extensions/providing-invocation-contexts-for-class-templates.adoc[] for usage examples.
 
-NOTE: <<writing-tests-parameterized-tests, Parameterized Classes>> are a built-in
+NOTE: xref:writing-tests/parameterized-classes-and-tests.adoc[Parameterized Classes] are a built-in
 specialization of class templates.
diff --git a/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc b/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc
index ab2d5d500fa1..712c1a06b3ff 100644
--- a/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/conditional-test-execution.adoc
@@ -1,10 +1,10 @@
 = Conditional Test Execution
 
-The <<extensions-conditions, `ExecutionCondition`>> extension API in JUnit Jupiter allows
+The xref:extensions/conditional-test-execution.adoc[`ExecutionCondition`] extension API in JUnit Jupiter allows
 developers to either _enable_ or _disable_ a test class or test method based on certain
 conditions _programmatically_. The simplest example of such a condition is the built-in
 `{DisabledCondition}` which supports the `{Disabled}` annotation (see
-<<writing-tests-disabling>>).
+xref:writing-tests/disabling-tests.adoc[]).
 
 In addition to `@Disabled`, JUnit Jupiter also supports several other annotation-based
 conditions in the `org.junit.jupiter.api.condition` package that allow developers to
@@ -21,7 +21,7 @@ APIs. However, that does not prevent the test class from being instantiated, and
 not prevent the execution of class-level lifecycle callbacks such as `@BeforeAll` methods,
 `@AfterAll` methods, and corresponding extension APIs.
 
-See <<extensions-conditions, `ExecutionCondition`>> and the following sections for
+See xref:extensions/conditional-test-execution.adoc[`ExecutionCondition`] and the following sections for
 details.
 
 [TIP]
@@ -30,7 +30,7 @@ details.
 Note that any of the _conditional_ annotations listed in the following sections may also
 be used as a meta-annotation in order to create a custom _composed annotation_. For
 example, the `@TestOnMac` annotation in the
-<<writing-tests-conditional-execution-os-demo, @EnabledOnOs demo>> shows how you can
+<<os-demo, @EnabledOnOs demo>> shows how you can
 combine `@Test` and `@EnabledOnOs` in a single, reusable annotation.
 ====
 
@@ -52,28 +52,28 @@ conditional annotation may be used in conjunction with other conditional annotat
 the `org.junit.jupiter.api.condition` package.
 ====
 
-[[writing-tests-conditional-execution-os]]
+[[os]]
 == Operating System and Architecture Conditions
 
 A container or test may be enabled or disabled on a particular operating system,
 architecture, or combination of both via the `{EnabledOnOs}` and `{DisabledOnOs}`
 annotations.
 
-[[writing-tests-conditional-execution-os-demo]]
+[[os-demo]]
 [source,java,indent=0]
 .Conditional execution based on operating system
 ----
 include::example$java/example/ConditionalTestExecutionDemo.java[tags=user_guide_os]
 ----
 
-[[writing-tests-conditional-execution-architectures-demo]]
+[[architectures-demo]]
 [source,java,indent=0]
 .Conditional execution based on architecture
 ----
 include::example$java/example/ConditionalTestExecutionDemo.java[tags=user_guide_architecture]
 ----
 
-[[writing-tests-conditional-execution-jre]]
+[[jre]]
 == Java Runtime Environment Conditions
 
 A container or test may be enabled or disabled on particular versions of the Java Runtime
@@ -107,7 +107,7 @@ versions.
 include::example$java/example/ConditionalTestExecutionDemo.java[tags=user_guide_jre_arbitrary_versions]
 ----
 
-[[writing-tests-conditional-execution-native]]
+[[native]]
 == Native Image Conditions
 
 A container or test may be enabled or disabled within a
@@ -122,7 +122,7 @@ Build Tools] project.
 include::example$java/example/ConditionalTestExecutionDemo.java[tags=user_guide_native]
 ----
 
-[[writing-tests-conditional-execution-system-properties]]
+[[system-properties]]
 == System Property Conditions
 
 A container or test may be enabled or disabled based on the value of the `named` JVM
@@ -143,7 +143,7 @@ class, or test method. Specifically, these annotations will be found if they are
 present, indirectly present, or meta-present on a given element.
 ====
 
-[[writing-tests-conditional-execution-environment-variables]]
+[[environment-variables]]
 == Environment Variable Conditions
 
 A container or test may be enabled or disabled based on the value of the `named`
@@ -164,10 +164,10 @@ interface, test class, or test method. Specifically, these annotations will be f
 they are directly present, indirectly present, or meta-present on a given element.
 ====
 
-[[writing-tests-conditional-execution-custom]]
+[[custom]]
 == Custom Conditions
 
-As an alternative to implementing an <<extensions-conditions, `ExecutionCondition`>>, a
+As an alternative to implementing an xref:extensions/conditional-test-execution.adoc[`ExecutionCondition`], a
 container or test may be enabled or disabled based on a _condition method_ configured via
 the `{EnabledIf}` and `{DisabledIf}` annotations. A condition method must have a `boolean`
 return type and may accept either no arguments or a single `ExtensionContext` argument.
diff --git a/documentation/modules/ROOT/pages/writing-tests/definitions.adoc b/documentation/modules/ROOT/pages/writing-tests/definitions.adoc
index 86dc2331fd19..351fe22f151d 100644
--- a/documentation/modules/ROOT/pages/writing-tests/definitions.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/definitions.adoc
@@ -15,8 +15,7 @@ any method that is directly annotated or meta-annotated with
 `@BeforeAll`, `@AfterAll`, `@BeforeEach`, or `@AfterEach`.
 
 Test Class::
-any top-level class, `static` member class, or <<writing-tests-nested,
-`@Nested` class>> that contains at least one _test method_, i.e. a _container_.
+any top-level class, `static` member class, or xref:writing-tests/nested-tests.adoc[`@Nested` class] that contains at least one _test method_, i.e. a _container_.
 Test classes must not be `abstract` and must have a single constructor.
 Java `record` classes are supported as well.
 
diff --git a/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc b/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc
index 85c0b3d7ecc8..cdb18e0091ea 100644
--- a/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/dependency-injection-for-constructors-and-methods.adoc
@@ -8,7 +8,7 @@ constructors and methods.
 
 `{ParameterResolver}` defines the API for test extensions that wish to _dynamically_
 resolve parameters at runtime. If a _test class_ constructor, a _test method_, or a
-_lifecycle method_ (see <<writing-tests-definitions>>) accepts a parameter, the parameter
+_lifecycle method_ (see xref:writing-tests/definitions.adoc[]) accepts a parameter, the parameter
 must be resolved at runtime by a registered `ParameterResolver`.
 
 There are currently three built-in resolvers that are registered automatically.
@@ -36,7 +36,7 @@ include::example$java/example/TestInfoDemo.java[tags=user_guide]
   information about the current repetition, the total number of repetitions, the number of
   repetitions that have failed, and the failure threshold for the corresponding
   `@RepeatedTest`. Note, however, that `RepetitionExtension` is not registered outside the
-  context of a `@RepeatedTest`. See <<writing-tests-repeated-tests-examples>>.
+  context of a `@RepeatedTest`. See xref:writing-tests/repeated-tests.adoc#examples[Repeated Test Examples].
 
 * `{TestReporterParameterResolver}`: if a constructor or method parameter is of type
   `{TestReporter}`, the `TestReporterParameterResolver` will supply an instance of
@@ -55,7 +55,7 @@ include::example$java/example/TestReporterDemo.java[tags=user_guide]
 ----
 
 NOTE: Other parameter resolvers must be explicitly enabled by registering appropriate
-<<extensions,extensions>> via `@ExtendWith`.
+xref:extensions/overview.adoc[extensions] via `@ExtendWith`.
 
 Check out the `{RandomParametersExtension}` for an example of a custom
 `{ParameterResolver}`. While not intended to be production-ready, it demonstrates the
diff --git a/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc
index 981acf5d408d..5630bf30eac8 100644
--- a/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/disabling-tests.adoc
@@ -2,8 +2,7 @@
 
 Entire test classes or individual test methods may be _disabled_ via the `{Disabled}`
 annotation, via one of the annotations discussed in
-<<writing-tests-conditional-execution>>, or via a custom <<extensions-conditions,
-`ExecutionCondition`>>.
+xref:writing-tests/conditional-test-execution.adoc[], or via a custom xref:extensions/conditional-test-execution.adoc[`ExecutionCondition`].
 
 When `@Disabled` is applied at the class level, all test methods within that class are
 automatically disabled as well.
diff --git a/documentation/modules/ROOT/pages/writing-tests/display-names.adoc b/documentation/modules/ROOT/pages/writing-tests/display-names.adoc
index de76247ca321..86aef486627d 100644
--- a/documentation/modules/ROOT/pages/writing-tests/display-names.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/display-names.adoc
@@ -12,7 +12,7 @@ include::example$java/example/DisplayNameDemo.java[tags=user_guide]
 [NOTE]
 ====
 Control characters in text-based arguments in display names for parameterized tests are
-escaped by default. See <<writing-tests-parameterized-tests-display-names-quoted-text>>
+escaped by default. See xref:writing-tests/parameterized-classes-and-tests.adoc#tests-display-names-quoted-text[Quoted Text-based Arguments]
 for details.
 
 Any remaining ISO control characters in a display name will be replaced as follows.
@@ -35,7 +35,7 @@ Any remaining ISO control characters in a display name will be replaced as follo
 |===
 ====
 
-[[writing-tests-display-name-generator]]
+[[generator]]
 == Display Name Generators
 
 JUnit Jupiter supports custom display name generators that can be configured via the
@@ -121,11 +121,11 @@ A year is a leap year ✔
 ======
 
 
-[[writing-tests-display-name-generator-default]]
+[[generator-default]]
 == Setting the Default Display Name Generator
 
 You can use the `junit.jupiter.displayname.generator.default`
-<<running-tests-config-params, configuration parameter>> to specify the fully qualified
+xref:running-tests/configuration-parameters.adoc[configuration parameter] to specify the fully qualified
 class name of the `DisplayNameGenerator` you would like to use by default. Just like for
 display name generators configured via the `@DisplayNameGeneration` annotation, the
 supplied class has to implement the `DisplayNameGenerator` interface. The default display
@@ -147,7 +147,7 @@ junit.jupiter.displayname.generator.default = \
 Similarly, you can specify the fully qualified name of any custom class that implements
 `DisplayNameGenerator`.
 
-[[writing-tests-display-name-generator-precedence-rules]]
+[[generator-precedence-rules]]
 In summary, the display name for a test class or method is determined according to the
 following precedence rules:
 
diff --git a/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc
index 5fea6ae2737f..7878f90d3b2f 100644
--- a/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc
@@ -1,7 +1,7 @@
 = Dynamic Tests
 
 The standard `@Test` annotation in JUnit Jupiter described in
-<<writing-tests-annotations>> is very similar to the `@Test` annotation in JUnit 4. Both
+xref:writing-tests/annotations.adoc[] is very similar to the `@Test` annotation in JUnit 4. Both
 describe methods that implement test cases. These test cases are static in the sense that
 they are fully specified at compile time, and their behavior cannot be changed by
 anything happening at runtime. _Assumptions provide a basic form of dynamic behavior but
@@ -46,7 +46,7 @@ lambda expression for a dynamic test, those fields will not be reset by callback
 or extensions between the execution of individual dynamic tests generated by the same
 `@TestFactory` method.
 
-[[writing-tests-dynamic-tests-examples]]
+[[examples]]
 == Dynamic Test Examples
 
 The following `DynamicTestsDemo` class demonstrates several examples of test factories
@@ -81,7 +81,7 @@ a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
 include::example$java/example/DynamicTestsDemo.java[tags=user_guide]
 ----
 
-[[writing-tests-dynamic-tests-named-support]]
+[[named-support]]
 == Dynamic Tests and Named
 
 In some cases, it can be more natural to specify inputs together with a descriptive name
@@ -95,7 +95,7 @@ interface along with `Named` via the `NamedExecutable` base class.
 include::example$java/example/DynamicTestsNamedDemo.java[tags=user_guide]
 ----
 
-[[writing-tests-dynamic-tests-uri-test-source]]
+[[uri-test-source]]
 == URI Test Sources for Dynamic Tests
 
 The JUnit Platform provides `TestSource`, a representation of the source of a test or
@@ -130,11 +130,11 @@ implementations.
 `UriSource` ::
   If none of the above `TestSource` implementations are applicable.
 
-[[writing-tests-dynamic-tests-parallel-execution]]
+[[parallel-execution]]
 == Parallel Execution
 
 Dynamic tests and containers support
-<<writing-tests-parallel-execution, parallel execution>>. You can configure their
+xref:writing-tests/parallel-execution.adoc[parallel execution]. You can configure their
 `ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
 factory methods as illustrated by the following example.
 
diff --git a/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc b/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc
index d71bea1c10a9..2e1d6501b26a 100644
--- a/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc
@@ -5,7 +5,7 @@ built-in mechanisms for managing test failures due to exceptions, the role of ex
 in implementing assertions and assumptions, and how to specifically assert non-throwing
 conditions in code.
 
-[[writing-tests-exceptions-uncaught]]
+[[uncaught]]
 == Uncaught Exceptions
 
 In JUnit Jupiter, if an exception is thrown from a test method, a lifecycle method, or an
@@ -19,7 +19,7 @@ Failed assumptions deviate from this general rule.
 In contrast to failed assertions, failed assumptions do not result in a test failure;
 rather, a failed assumption results in a test being aborted.
 
-See <<writing-tests-assumptions>> for further details and examples.
+See xref:writing-tests/assumptions.adoc[] for further details and examples.
 ====
 
 In the following example, the `failsDueToUncaughtException()` method throws an
@@ -36,18 +36,18 @@ no effect on the outcome of the test. JUnit Jupiter does not interpret a `throws
 as an expectation or assertion about what exceptions the test method should throw. A test
 fails only if an exception is thrown unexpectedly or if an assertion fails.
 
-[[writing-tests-exceptions-failed-assertions]]
+[[failed-assertions]]
 == Failed Assertions
 
 Assertions in JUnit Jupiter are implemented using exceptions. The framework provides a set
 of assertion methods in the `org.junit.jupiter.api.Assertions` class, which throw
 `AssertionError` when an assertion fails. This mechanism is a core aspect of how JUnit
-handles assertion failures as exceptions. See the <<writing-tests-assertions>> section for
+handles assertion failures as exceptions. See the xref:writing-tests/assertions.adoc[] section for
 further information about JUnit Jupiter's assertion support.
 
 NOTE: Third-party assertion libraries may choose to throw an `AssertionError` to signal a
 failed assertion; however, they may also choose to throw different types of exceptions to
-signal failures. See also: <<writing-tests-assertions-third-party>>.
+signal failures. See also: xref:writing-tests/assertions.adoc#third-party[Third-party Assertion Libraries].
 
 TIP: JUnit Jupiter itself does not differentiate between failed assertions
 (`AssertionError`) and other types of exceptions. All uncaught exceptions lead to a test
@@ -64,7 +64,7 @@ will mark the test as failed.
 include::example$java/example/exception/FailedAssertionDemo.java[tags=user_guide]
 ----
 
-[[writing-tests-exceptions-expected]]
+[[expected]]
 == Asserting Expected Exceptions
 
 JUnit Jupiter offers specialized assertions for testing that specific exceptions are
@@ -72,7 +72,7 @@ thrown under expected conditions. The `assertThrows()` and `assertThrowsExactly(
 assertions are critical tools for validating that your code responds correctly to error
 conditions by throwing the appropriate exceptions.
 
-[[writing-tests-exceptions-expected-assertThrows]]
+[[expected-assertThrows]]
 === Using `assertThrows()`
 
 The `assertThrows()` method is used to verify that a particular type of exception is
@@ -86,7 +86,7 @@ thrown exception object to allow performing additional assertions on it.
 include::example$java/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
 ----
 
-[[writing-tests-exceptions-expected-assertThrowsExactly]]
+[[expected-assertThrowsExactly]]
 === Using `assertThrowsExactly()`
 
 The `assertThrowsExactly()` method is used when you need to assert that the exception
@@ -100,7 +100,7 @@ returns the thrown exception object to allow performing additional assertions on
 include::example$java/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
 ----
 
-[[writing-tests-exceptions-not-expected]]
+[[not-expected]]
 == Asserting That no Exception is Expected
 
 Although any exception thrown from a test method will cause the test to fail, there are
@@ -116,4 +116,4 @@ include::example$java/example/exception/AssertDoesNotThrowExceptionDemo.java[tag
 
 NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
 has `assertThatNoException().isThrownBy(() -> ...)`. See also:
-<<writing-tests-assertions-third-party>>.
+xref:writing-tests/assertions.adoc#third-party[Third-party Assertion Libraries].
diff --git a/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc
index 7f1ac2e85542..ce88abcd2185 100644
--- a/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc
@@ -29,11 +29,11 @@ NOTE: _Only non-static nested classes_ (i.e. _inner classes_) can serve as `@Nes
 classes. Nesting can be arbitrarily deep, and those inner classes are subject to full
 lifecycle support, including `@BeforeAll` and `@AfterAll` methods on each level.
 
-[[writing-tests-nested-interoperability]]
+[[interoperability]]
 == Interoperability
 
 `@Nested` may be combined with
-<<writing-tests-parameterized-tests, `@ParameterizedClass`>> in which case the nested test
+xref:writing-tests/parameterized-classes-and-tests.adoc[`@ParameterizedClass`] in which case the nested test
 class is parameterized.
 
 The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
diff --git a/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc b/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc
index 5460dfa5df82..60056b77c543 100644
--- a/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/parallel-execution.adoc
@@ -4,7 +4,7 @@ By default, JUnit Jupiter tests are run sequentially in a single thread; however
 tests in parallel -- for example, to speed up execution -- is available as an opt-in
 feature. To enable parallel execution, set the `junit.jupiter.execution.parallel.enabled`
 configuration parameter to `true` -- for example, in `junit-platform.properties` (see
-<<running-tests-config-params>> for other options).
+xref:running-tests/configuration-parameters.adoc[] for other options).
 
 Please note that enabling this property is only the first step required to execute tests
 in parallel. If enabled, test classes and methods will still be executed sequentially by
@@ -52,16 +52,16 @@ This allows test classes or methods to opt in or out of concurrent execution reg
 the globally configured default.
 
 When parallel execution is enabled and a default `{ClassOrderer}` is registered (see
-<<writing-tests-test-execution-order-classes>> for details), top-level test classes will
+xref:writing-tests/test-execution-order.adoc#classes[Class Order] for details), top-level test classes will
 initially be sorted accordingly and scheduled in that order. However, they are not
 guaranteed to be started in exactly that order since the threads they are executed on are
 not controlled directly by JUnit.
 
 All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
 be executed fully in parallel according to the provided
-<<writing-tests-parallel-execution-config, configuration>> while observing the
-declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
-mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
+<<config, configuration>> while observing the
+declarative <<synchronization, synchronization>>
+mechanism. Please note that xref:running-tests/capturing-standard-output-error.adoc[] needs to be enabled
 separately.
 
 In addition, you can configure the default execution mode for top-level classes by setting
@@ -137,10 +137,10 @@ If the `junit.jupiter.execution.parallel.mode.classes.default` configuration par
 not explicitly set, the value for `junit.jupiter.execution.parallel.mode.default` will be
 used instead.
 
-[[writing-tests-parallel-execution-config]]
+[[config]]
 == Configuration
 
-[[writing-tests-parallel-execution-config-executor-service]]
+[[config-executor-service]]
 === Executor Service
 
 If parallel execution is enabled, a thread pool is used behind the scenes to execute tests
@@ -162,9 +162,9 @@ API in the JDK.
 
 WARNING: Using `worker_thread_pool` is currently an _experimental_ feature. You're invited
 to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
+xref:api-evolution.adoc[promote] this feature.
 
-[[writing-tests-parallel-execution-config-strategies]]
+[[config-strategies]]
 === Strategies
 
 Properties such as the desired parallelism and the maximum pool size can be configured
@@ -206,11 +206,11 @@ parallelism. If you require such guarantees, it is possible to limit the maximum
 threads by configuring the maximum pool size of the `dynamic`, `fixed` and `custom`
 strategies.
 
-[[writing-tests-parallel-execution-config-properties]]
+[[config-properties]]
 === Relevant properties
 
 The following table lists relevant properties for configuring parallel execution. See
-<<running-tests-config-params>> for details on how to set such properties.
+xref:running-tests/configuration-parameters.adoc[] for details on how to set such properties.
 
 ==== General
 
@@ -273,7 +273,7 @@ The following table lists relevant properties for configuring parallel execution
   Fully qualified class name of the `ParallelExecutionConfigurationStrategy` to be used
   for the ```custom``` configuration strategy (no default value).
 
-[[writing-tests-parallel-execution-synchronization]]
+[[synchronization]]
 == Synchronization
 
 In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
diff --git a/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc
index 075beac659dc..8f3844fcce9c 100644
--- a/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/parameterized-classes-and-tests.adoc
@@ -5,18 +5,18 @@ arguments. They are declared just like regular `@Test` methods but use the
 `{ParameterizedTest}` annotation instead.
 
 _Parameterized classes_ make it possible to run _all_ tests in a test class, including
-<<writing-tests-nested>>, multiple times with different arguments. They are declared just
+xref:writing-tests/nested-tests.adoc[], multiple times with different arguments. They are declared just
 like regular test classes and may contain any supported test method type (including
 `@ParameterizedTest`) but annotated with the `{ParameterizedClass}` annotation.
 
 WARNING: _Parameterized classes_ are currently an _experimental_ feature. You're invited
 to give it a try and provide feedback to the JUnit team so they can improve and eventually
-<<api-evolution, promote>> this feature.
+xref:api-evolution.adoc[promote] this feature.
 
 Regardless of whether you are parameterizing a test method or a test class, you must
-declare at least one <<writing-tests-parameterized-tests-sources, source>> that will
+declare at least one <<tests-sources, source>> that will
 provide the arguments for each invocation and then
-<<writing-tests-parameterized-tests-consuming-arguments, consume>> the arguments in the
+<<tests-consuming-arguments, consume>> the arguments in the
 parameterized method or class, respectively.
 
 The following example demonstrates a parameterized test that uses the `@ValueSource`
@@ -63,24 +63,24 @@ PalindromeTests ✔
    └─ reversePalindrome() ✔
 ....
 
-[[writing-tests-parameterized-tests-setup]]
+[[tests-setup]]
 == Required Setup
 
 In order to use parameterized classes or tests you need to add a dependency on the
-`junit-jupiter-params` artifact. Please refer to <<dependency-metadata>> for details.
+`junit-jupiter-params` artifact. Please refer to xref:appendix.adoc#dependency-metadata[Dependency Metadata] for details.
 
-[[writing-tests-parameterized-tests-consuming-arguments]]
+[[tests-consuming-arguments]]
 == Consuming Arguments
 
-[[writing-tests-parameterized-tests-consuming-arguments-methods]]
+[[tests-consuming-arguments-methods]]
 === Parameterized Tests
 
 Parameterized test methods _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>) following a one-to-one correlation between
+<<tests-sources>>) following a one-to-one correlation between
 argument source index and method parameter index (see examples in
-<<writing-tests-parameterized-tests-sources-CsvSource>>). However, a parameterized test
+<<tests-sources-CsvSource>>). However, a parameterized test
 method may also choose to _aggregate_ arguments from the source into a single object
-passed to the method (see <<writing-tests-parameterized-tests-argument-aggregation>>).
+passed to the method (see <<tests-argument-aggregation>>).
 Additional arguments may also be provided by a `ParameterResolver` (e.g., to obtain an
 instance of `TestInfo`, `TestReporter`, etc.). Specifically, a parameterized test method
 must declare formal parameters according to the following rules.
@@ -95,25 +95,25 @@ parameterized method at the same index in the method's formal parameter list. An
 _aggregator_ is any parameter of type `{ArgumentsAccessor}` or any parameter annotated
 with `{AggregateWith}`.
 
-[[writing-tests-parameterized-tests-consuming-arguments-classes]]
+[[tests-consuming-arguments-classes]]
 === Parameterized Classes
 
 Parameterized classes _consume_ arguments directly from the configured source (see
-<<writing-tests-parameterized-tests-sources>>); either via their unique constructor or via
+<<tests-sources>>); either via their unique constructor or via
 field injection. If a `{Parameter}`-annotated field is declared in the parameterized class
 or one of its superclasses, field injection will be used. Otherwise, constructor injection
 will be used.
 
-[[writing-tests-parameterized-tests-consuming-arguments-constructor-injection]]
+[[tests-consuming-arguments-constructor-injection]]
 ==== Constructor Injection
 
 WARNING: Constructor injection can only be used with the (default) `PER_METHOD`
-<<writing-tests-test-instance-lifecycle, test instance lifecycle>> mode. Please use
-<<writing-tests-parameterized-tests-consuming-arguments-field-injection, field injection>>
+xref:writing-tests/test-instance-lifecycle.adoc[test instance lifecycle] mode. Please use
+<<tests-consuming-arguments-field-injection, field injection>>
 with the `PER_CLASS` mode instead.
 
 For constructor injection, the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>>
+<<tests-consuming-arguments-methods, parameterized tests>>
 above. In the following example, two arguments are injected into the constructor of the
 test class.
 
@@ -130,7 +130,7 @@ of declaring a test class constructor.
 include::example$java/example/ParameterizedRecordDemo.java[tags=example]
 ----
 
-[[writing-tests-parameterized-tests-consuming-arguments-field-injection]]
+[[tests-consuming-arguments-field-injection]]
 ==== Field Injection
 
 For field injection, the following rules apply for fields annotated with `@Parameter`.
@@ -158,20 +158,20 @@ include::example$java/example/ParameterizedClassDemo.java[tags=field_injection]
 ----
 
 If field injection is used, no constructor parameters will be resolved with arguments from
-the source. Other <<writing-tests-dependency-injection, `ParameterResolver` extensions>>
+the source. Other xref:writing-tests/dependency-injection-for-constructors-and-methods.adoc[`ParameterResolver` extensions]
 may resolve constructor parameters as usual, though.
 
-[[writing-tests-parameterized-tests-consuming-arguments-lifecycle-method]]
+[[tests-consuming-arguments-lifecycle-method]]
 ==== Lifecycle Methods
 
 `{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` can also
 be used to consume arguments if their `injectArguments` attribute is set to `true` (the
 default). If so, their method signatures must follow the same rules apply as defined for
-<<writing-tests-parameterized-tests-consuming-arguments-methods, parameterized tests>> and
+<<tests-consuming-arguments-methods, parameterized tests>> and
 additionally use the same parameter types as the _indexed parameters_ of the parameterized
 test class. Please refer to the Javadoc of `{BeforeParameterizedClassInvocation}` and
 `{AfterParameterizedClassInvocation}` for details and to the
-<<writing-tests-parameterized-tests-lifecycle-interop-classes, Lifecycle>> section for an
+<<tests-lifecycle-interop-classes, Lifecycle>> section for an
 example.
 
 [NOTE]
@@ -189,14 +189,14 @@ method, you must specify the `autoCloseArguments = false` on the `{Parameterized
 invocations.
 ====
 
-[[writing-tests-parameterized-tests-consuming-arguments-other-extensions]]
+[[tests-consuming-arguments-other-extensions]]
 === Other Extensions
 
 Other extensions can access the parameters and resolved arguments of a parameterized test
 or class by retrieving a `{ParameterInfo}` object from the `{ExtensionContext_Store}`.
 Please refer to the Javadoc of `{ParameterInfo}` for details.
 
-[[writing-tests-parameterized-tests-sources]]
+[[tests-sources]]
 == Sources of Arguments
 
 Out of the box, JUnit Jupiter provides quite a few _source_ annotations. Each of the
@@ -208,7 +208,7 @@ TIP: All source annotations in this section are applicable to both `{Parameteriz
 and `{ParameterizedTest}`. For the sake of brevity, the examples in this section will only
 show how to use them with `{ParameterizedTest}` methods.
 
-[[writing-tests-parameterized-tests-sources-ValueSource]]
+[[tests-sources-ValueSource]]
 === @ValueSource
 
 `@ValueSource` is one of the simplest possible sources. It lets you specify a single
@@ -236,7 +236,7 @@ the values `1`, `2`, and `3` respectively.
 include::example$java/example/ParameterizedTestDemo.java[tags=ValueSource_example]
 ----
 
-[[writing-tests-parameterized-tests-sources-null-and-empty]]
+[[tests-sources-null-and-empty]]
 === Null and Empty Sources
 
 In order to check corner cases and verify proper behavior of our software when it is
@@ -259,7 +259,7 @@ for parameterized tests that accept a single argument.
 
 If you need to supply multiple varying types of _blank_ strings to a parameterized
 class or test, you can achieve that using
-<<writing-tests-parameterized-tests-sources-ValueSource>> -- for example,
+<<tests-sources-ValueSource>> -- for example,
 `@ValueSource(strings = {"{nbsp}", "{nbsp}{nbsp}{nbsp}", "\t", "\n"})`.
 
 You can also combine `@NullSource`, `@EmptySource`, and `@ValueSource` to test a wider
@@ -283,7 +283,7 @@ NOTE: Both variants of the `nullEmptyAndBlankStrings(String)` parameterized test
 result in six invocations: 1 for `null`, 1 for the empty string, and 4 for the explicit
 blank strings supplied via `@ValueSource`.
 
-[[writing-tests-parameterized-tests-sources-EnumSource]]
+[[tests-sources-EnumSource]]
 === @EnumSource
 
 `@EnumSource` provides a convenient way to use `Enum` constants.
@@ -351,7 +351,7 @@ range of constants while excluding specific values from that range as shown belo
 include::example$java/example/ParameterizedTestDemo.java[tags=EnumSource_range_exclude_example]
 ----
 
-[[writing-tests-parameterized-tests-sources-MethodSource]]
+[[tests-sources-MethodSource]]
 === @MethodSource
 
 `{MethodSource}` allows you to refer to one or more _factory_ methods of the test class
@@ -439,7 +439,7 @@ can be referenced by its fully qualified method name, e.g.
 include::example$java/example/MethodSourceParameterResolutionDemo.java[tags=parameter_resolution_MethodSource_example]
 ----
 
-[[writing-tests-parameterized-tests-sources-FieldSource]]
+[[tests-sources-FieldSource]]
 === @FieldSource
 
 `{FieldSource}` allows you to refer to one or more fields of the test class or external
@@ -466,7 +466,7 @@ a single argument.
 [WARNING]
 ====
 In contrast to the supported return types for
-<<writing-tests-parameterized-tests-sources-MethodSource, `@MethodSource`>> factory
+<<tests-sources-MethodSource, `@MethodSource`>> factory
 methods, the value of a `@FieldSource` field cannot be an instance of `Stream`,
 `DoubleStream`, `LongStream`, `IntStream`, or `Iterator`, since the values of such types
 are _consumed_ the first time they are processed. However, if you wish to use one of
@@ -560,7 +560,7 @@ _fully qualified field name_ as demonstrated in the following example.
 include::example$java/example/ExternalFieldSourceDemo.java[tags=external_field_FieldSource_example]
 ----
 
-[[writing-tests-parameterized-tests-sources-CsvSource]]
+[[tests-sources-CsvSource]]
 === @CsvSource
 
 `@CsvSource` allows you to express argument lists as comma-separated values (i.e., CSV
@@ -683,7 +683,7 @@ within quoted strings, you will need to ensure that there is no leading whitespa
 your text block.
 ====
 
-[[writing-tests-parameterized-tests-sources-CsvFileSource]]
+[[tests-sources-CsvFileSource]]
 === @CsvFileSource
 
 `@CsvFileSource` lets you use comma-separated value (CSV) files from the classpath or the
@@ -750,7 +750,7 @@ Except within a quoted string, leading and trailing whitespace in a CSV column i
 by default. This behavior can be changed by setting the
 `ignoreLeadingAndTrailingWhitespace` attribute to `true`.
 
-[[writing-tests-parameterized-tests-sources-ArgumentsSource]]
+[[tests-sources-ArgumentsSource]]
 === @ArgumentsSource
 
 `@ArgumentsSource` can be used to specify a custom, reusable `ArgumentsProvider`. Note
@@ -780,7 +780,7 @@ following example.
 include::example$java/example/ParameterizedTestDemo.java[tags=ArgumentsProviderWithConstructorInjection_example]
 ----
 
-[[writing-tests-parameterized-repeatable-sources]]
+[[repeatable-sources]]
 === Multiple sources using repeatable annotations
 
 Repeatable annotations provide a convenient way to specify multiple sources from
@@ -808,7 +808,7 @@ The following annotations are repeatable:
 * `@CsvFileSource`
 * `@ArgumentsSource`
 
-[[writing-tests-parameterized-tests-argument-count-validation]]
+[[tests-argument-count-validation]]
 == Argument Count Validation
 
 By default, when an arguments source provides more arguments than the test method needs,
@@ -821,7 +821,7 @@ Then, any additional arguments will cause an error instead.
 
 To change this behavior for all tests, set the
 `junit.jupiter.params.argumentCountValidation`
-<<running-tests-config-params, configuration parameter>> to `strict`.
+xref:running-tests/configuration-parameters.adoc[configuration parameter] to `strict`.
 To change this behavior for a single parameterized class or test method,
 use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
 `@ParameterizedTest` annotation:
@@ -831,10 +831,10 @@ use the `argumentCountValidation` attribute of the `@ParameterizedClass` or
 include::example$java/example/ParameterizedTestDemo.java[tags=argument_count_validation]
 ----
 
-[[writing-tests-parameterized-tests-argument-conversion]]
+[[tests-argument-conversion]]
 == Argument Conversion
 
-[[writing-tests-parameterized-tests-argument-conversion-widening]]
+[[tests-argument-conversion-widening]]
 === Widening Conversion
 
 JUnit Jupiter supports
@@ -844,7 +844,7 @@ For example, a parameterized class or test method annotated with
 `@ValueSource(ints = { 1, 2, 3 })` can be declared to accept not only an argument of type
 `int` but also an argument of type `long`, `float`, or `double`.
 
-[[writing-tests-parameterized-tests-argument-conversion-implicit]]
+[[tests-argument-conversion-implicit]]
 === Implicit Conversion
 
 To support use cases like `@CsvSource`, JUnit Jupiter provides a number of built-in
@@ -865,7 +865,7 @@ include::example$java/example/ParameterizedTestDemo.java[tags=implicit_conversio
 NOTE: Decimal, hexadecimal, and octal `String` literals will be converted to their
 integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
 
-[[writing-tests-parameterized-tests-argument-conversion-implicit-table]]
+[[tests-argument-conversion-implicit-table]]
 [cols="10,90"]
 |===
 | Target Type | Example
@@ -908,7 +908,7 @@ integral types: `byte`, `short`, `int`, `long`, and their boxed counterparts.
 | `java.util.UUID`           | `"d043e930-7b3b-48e3-bdbe-5a3ccfb833db"` -> `UUID.fromString("d043e930-7b3b-48e3-bdbe-5a3ccfb833db")`
 |===
 
-[[writing-tests-parameterized-tests-argument-conversion-implicit-fallback]]
+[[tests-argument-conversion-implicit-fallback]]
 ==== Fallback String-to-Object Conversion
 
 In addition to implicit conversion from strings to the target types listed in the above
@@ -942,7 +942,7 @@ include::example$java/example/ParameterizedTestDemo.java[tags=implicit_fallback_
 include::example$java/example/ParameterizedTestDemo.java[tags=implicit_fallback_conversion_example_Book]
 ----
 
-[[writing-tests-parameterized-tests-argument-conversion-explicit]]
+[[tests-argument-conversion-explicit]]
 === Explicit Conversion
 
 Instead of relying on implicit argument conversion, you may explicitly specify an
@@ -982,7 +982,7 @@ If you wish to implement a custom `ArgumentConverter` that also consumes an anno
 (like `JavaTimeArgumentConverter`), you have the possibility to extend the
 `{AnnotationBasedArgumentConverter}` class.
 
-[[writing-tests-parameterized-tests-argument-aggregation]]
+[[tests-argument-aggregation]]
 == Argument Aggregation
 
 By default, each _argument_ provided to a `@ParameterizedClass` or `@ParameterizedTest`
@@ -993,7 +993,7 @@ signatures, respectively.
 In such cases, an `{ArgumentsAccessor}` can be used instead of multiple parameters. Using
 this API, you can access the provided arguments through a single argument passed to your
 test method. In addition, type conversion is supported as discussed in
-<<writing-tests-parameterized-tests-argument-conversion-implicit>>.
+<<tests-argument-conversion-implicit>>.
 
 Besides, you can retrieve the current test invocation index with
 `ArgumentsAccessor.getInvocationIndex()`.
@@ -1006,7 +1006,7 @@ include::example$java/example/ParameterizedTestDemo.java[tags=ArgumentsAccessor_
 _An instance of `ArgumentsAccessor` is automatically injected into any parameter of type
 `ArgumentsAccessor`._
 
-[[writing-tests-parameterized-tests-argument-aggregation-custom]]
+[[tests-argument-aggregation-custom]]
 === Custom Aggregators
 
 Apart from direct access to the arguments of a `@ParameterizedClass` or
@@ -1047,7 +1047,7 @@ include::example$java/example/ParameterizedTestDemo.java[tags=ArgumentsAggregato
 ----
 
 
-[[writing-tests-parameterized-tests-display-names]]
+[[tests-display-names]]
 == Customizing Display Names
 
 By default, the display name of a parameterized class or test invocation contains the
@@ -1167,7 +1167,7 @@ Note that `argumentSet(String, Object...)` is a static factory method defined in
 `org.junit.jupiter.params.provider.Arguments` interface.
 ====
 
-[[writing-tests-parameterized-tests-display-names-quoted-text]]
+[[tests-display-names-quoted-text]]
 === Quoted Text-based Arguments
 
 As of JUnit Jupiter 6.0, text-based arguments in display names for parameterized tests are
@@ -1193,7 +1193,7 @@ in the display name would be `"'\\t'"` which is printed as `'\t'`.
 
 For a concrete example, if you run the first `nullEmptyAndBlankStrings(String text)`
 parameterized test method from the
-<<writing-tests-parameterized-tests-sources-null-and-empty>> section above, the following
+<<tests-sources-null-and-empty>> section above, the following
 display names are generated.
 
 ----
@@ -1206,7 +1206,7 @@ display names are generated.
 ----
 
 If you run the first `testWithCsvSource(String fruit, int rank)` parameterized test method
-from the <<writing-tests-parameterized-tests-sources-CsvSource>> section above, the
+from the <<tests-sources-CsvSource>> section above, the
 following display names are generated.
 
 ----
@@ -1227,20 +1227,20 @@ instead of `3.14`. You can see the effect of this with the `rank` values in the
 example.
 ====
 
-[[writing-tests-parameterized-tests-display-names-default-pattern]]
+[[tests-display-names-default-pattern]]
 === Default Display Name Pattern
 
 If you'd like to set a default name pattern for all parameterized classes and tests in
 your project, you can declare the `junit.jupiter.params.displayname.default` configuration
 parameter in the `junit-platform.properties` file as demonstrated in the following example (see
-<<running-tests-config-params>> for other options).
+xref:running-tests/configuration-parameters.adoc[] for other options).
 
 [source,properties,indent=0]
 ----
 junit.jupiter.params.displayname.default = {index}
 ----
 
-[[writing-tests-parameterized-tests-display-names-precedence-rules]]
+[[tests-display-names-precedence-rules]]
 === Precedence Rules
 
 The display name for a parameterized class or test is determined according to the
@@ -1251,15 +1251,15 @@ following precedence rules:
 3. `DEFAULT_DISPLAY_NAME` constant defined in
    `org.junit.jupiter.params.ParameterizedInvocationConstants`
 
-[[writing-tests-parameterized-tests-lifecycle-interop]]
+[[tests-lifecycle-interop]]
 == Lifecycle and Interoperability
 
-[[writing-tests-parameterized-tests-lifecycle-interop-methods]]
+[[tests-lifecycle-interop-methods]]
 === Parameterized Tests
 
 Each invocation of a parameterized test has the same lifecycle as a regular `@Test`
 method. For example, `@BeforeEach` methods will be executed before each invocation.
-Similar to <<writing-tests-dynamic-tests>>, invocations will appear one by one in the
+Similar to xref:writing-tests/dynamic-tests.adoc[], invocations will appear one by one in the
 test tree of an IDE. You may at will mix regular `@Test` methods and `@ParameterizedTest`
 methods within the same test class.
 
@@ -1274,13 +1274,13 @@ lifecycle methods (e.g. `@BeforeEach`) and test class constructors.
 include::example$java/example/ParameterizedTestDemo.java[tags=ParameterResolver_example]
 ----
 
-[[writing-tests-parameterized-tests-lifecycle-interop-classes]]
+[[tests-lifecycle-interop-classes]]
 === Parameterized Classes
 
 Each invocation of a parameterized class has the same lifecycle as a regular test class.
 For example, `@BeforeAll` methods will be executed _once_ before all invocations and
 `@BeforeEach` methods will be executed before each _test method_ invocation. Similar to
-<<writing-tests-dynamic-tests>>, invocations will appear one by one in the test tree of an
+xref:writing-tests/dynamic-tests.adoc[], invocations will appear one by one in the test tree of an
 IDE.
 
 You may use `ParameterResolver` extensions with `@ParameterizedClass` constructors.
@@ -1292,7 +1292,7 @@ In addition to regular lifecycle methods, parameterized classes may declare
 `{BeforeParameterizedClassInvocation}` and `{AfterParameterizedClassInvocation}` lifecycle
 methods that are called once before/after each invocation of the parameterized class.
 These methods must be `static` unless the parameterized class is configured to use
-`@TestInstance(Lifecycle.PER_CLASS)` (see <<writing-tests-test-instance-lifecycle>>).
+`@TestInstance(Lifecycle.PER_CLASS)` (see xref:writing-tests/test-instance-lifecycle.adoc[]).
 
 These lifecycle methods may optionally declare parameters that are resolved depending on
 the setting of the `injectArguments` annotation attribute. If it is set to `false`, the
diff --git a/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc b/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc
index 90e35cb9f477..d81d9b40dd13 100644
--- a/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc
@@ -35,7 +35,7 @@ repetitions will be invoked regardless of whether any repetitions fail.
 WARNING: If the repetitions of a `@RepeatedTest` method are executed in parallel, no
 guarantees can be made regarding the failure threshold. It is therefore recommended that a
 `@RepeatedTest` method be annotated with `@Execution(SAME_THREAD)` when parallel execution
-is configured. See <<writing-tests-parallel-execution>> for further details.
+is configured. See xref:writing-tests/parallel-execution.adoc[] for further details.
 
 In addition to specifying the number of repetitions and failure threshold, a custom
 display name can be configured for each repetition via the `name` attribute of the
@@ -62,7 +62,7 @@ repetitions, the number of repetitions that have failed, and the failure thresho
 developer can choose to have an instance of `{RepetitionInfo}` injected into a
 `@RepeatedTest`, `@BeforeEach`, or `@AfterEach` method.
 
-[[writing-tests-repeated-tests-examples]]
+[[examples]]
 == Repeated Test Examples
 
 The `RepeatedTestsDemo` class at the end of this section demonstrates several examples of
diff --git a/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc b/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc
index b38ffbb75bb9..ad5bb6c07300 100644
--- a/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/tagging-and-filtering.adoc
@@ -1,8 +1,8 @@
 = Tagging and Filtering
 
 Test classes and methods can be tagged via the `@Tag` annotation. Those tags can later be
-used to filter <<running-tests, test discovery and execution>>. Please refer to the
-<<running-tests-tags>> section for more information about tag support in the JUnit
+used to filter xref:running-tests/intro.adoc[test discovery and execution]. Please refer to the
+xref:running-tests/tags.adoc[] section for more information about tag support in the JUnit
 Platform.
 
 [source,java,indent=0]
@@ -10,5 +10,5 @@ Platform.
 include::example$java/example/TaggingDemo.java[tags=user_guide]
 ----
 
-TIP: See <<writing-tests-meta-annotations>> for examples demonstrating how to create
+TIP: See xref:writing-tests/annotations.adoc#annotations[Meta-Annotations and Composed Annotations] for examples demonstrating how to create
 custom annotations for tags.
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc b/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc
index aeb1b1d552d0..0dd9e086fc48 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc
@@ -2,7 +2,7 @@
 
 Test methods and lifecycle methods may be declared locally within the current test class,
 inherited from superclasses, or inherited from interfaces (see
-<<writing-tests-test-interfaces-and-default-methods>>). In addition, test methods and
+xref:writing-tests/test-interfaces-and-default-methods.adoc[]). In addition, test methods and
 lifecycle methods must not be `abstract` and must not return a value (except `@TestFactory`
 methods which are required to return a value).
 
@@ -33,13 +33,13 @@ a different package than the subclass, that `@Test` method will always be applie
 subclass since the subclass cannot override a package-private method from a superclass in
 a different package.
 
-See also: <<extensions-supported-utilities-search-semantics>>
+See also: xref:extensions/supported-utilities-in-extensions.adoc#search-semantics[Field and Method Search Semantics]
 ====
 
 The following test class demonstrates the use of `@Test` methods and all supported
 lifecycle methods. For further information on runtime semantics, see
-<<writing-tests-test-execution-order>> and
-<<extensions-execution-order-wrapping-behavior>>.
+xref:writing-tests/test-execution-order.adoc[] and
+xref:extensions/relative-execution-order-of-user-code-and-extensions.adoc#wrapping-behavior[Wrapping Behavior of Callbacks].
 
 [source,java,indent=0]
 .A standard Java test class
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc b/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc
index 83b38d41fc97..20bae4e323fb 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-execution-order.adoc
@@ -5,9 +5,9 @@ deterministic but intentionally nonobvious. This ensures that subsequent runs of
 suite execute test classes and test methods in the same order, thereby allowing for
 repeatable builds.
 
-NOTE: See <<writing-tests-definitions>> for a definition of _test method_ and _test class_.
+NOTE: See xref:writing-tests/definitions.adoc[] for a definition of _test method_ and _test class_.
 
-[[writing-tests-test-execution-order-methods]]
+[[methods]]
 == Method Order
 
 Although true _unit tests_ typically should not rely on the order in which they are
@@ -22,8 +22,8 @@ implementation. You can implement your own custom `MethodOrderer` or use one of
 following built-in `MethodOrderer` implementations.
 
 * `{MethodOrderer_DisplayName}`: sorts test methods _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
+  display names (see xref:writing-tests/display-names.adoc#generator-precedence-rules[display name
+  generation precedence rules])
 * `{MethodOrderer_MethodName}`: sorts test methods _alphanumerically_ based on their names
   and formal parameter lists
 * `{MethodOrderer_OrderAnnotation}`: sorts test methods _numerically_ based on values
@@ -36,7 +36,7 @@ it contains, recursively. If you want to avoid that a `@Nested` test class uses
 `MethodOrderer` as its enclosing class, you can specify `{MethodOrderer_Default}` together
 with `{TestMethodOrder}`.
 
-NOTE: See also: <<extensions-execution-order-wrapping-behavior>>
+NOTE: See also: xref:extensions/relative-execution-order-of-user-code-and-extensions.adoc#wrapping-behavior[Wrapping Behavior of Callbacks]
 
 The following example demonstrates how to guarantee that test methods are executed in the
 order specified via the `@Order` annotation.
@@ -46,11 +46,10 @@ order specified via the `@Order` annotation.
 include::example$java/example/OrderedTestsDemo.java[tags=user_guide]
 ----
 
-[[writing-tests-test-execution-order-methods-default]]
+[[methods-default]]
 === Setting the Default Method Orderer
 
-You can use the `junit.jupiter.testmethod.order.default` <<running-tests-config-params,
-configuration parameter>> to specify the fully qualified class name of the
+You can use the `junit.jupiter.testmethod.order.default` xref:running-tests/configuration-parameters.adoc[configuration parameter] to specify the fully qualified class name of the
 `{MethodOrderer}` you would like to use by default. Just like for the orderer configured
 via the `{TestMethodOrder}` annotation, the supplied class has to implement the
 `MethodOrderer` interface. The default orderer will be used for all tests unless the
@@ -69,7 +68,7 @@ junit.jupiter.testmethod.order.default = \
 Similarly, you can specify the fully qualified name of any custom class that implements
 `MethodOrderer`.
 
-[[writing-tests-test-execution-order-classes]]
+[[classes]]
 == Class Order
 
 Although test classes typically should not rely on the order in which they are executed,
@@ -84,8 +83,8 @@ time as outlined in the following scenarios.
 * Various other use cases
 
 To configure test class execution order _globally_ for the entire test suite, use the
-`junit.jupiter.testclass.order.default` <<running-tests-config-params, configuration
-parameter>> to specify the fully qualified class name of the `{ClassOrderer}` you would
+`junit.jupiter.testclass.order.default` xref:running-tests/configuration-parameters.adoc[configuration
+parameter] to specify the fully qualified class name of the `{ClassOrderer}` you would
 like to use. The supplied class must implement the `ClassOrderer` interface.
 
 You can implement your own custom `ClassOrderer` or use one of the following built-in
@@ -94,8 +93,8 @@ You can implement your own custom `ClassOrderer` or use one of the following bui
 * `{ClassOrderer_ClassName}`: sorts test classes _alphanumerically_ based on their fully
   qualified class names
 * `{ClassOrderer_DisplayName}`: sorts test classes _alphanumerically_ based on their
-  display names (see <<writing-tests-display-name-generator-precedence-rules, display name
-  generation precedence rules>>)
+  display names (see xref:writing-tests/display-names.adoc#generator-precedence-rules[display name
+  generation precedence rules])
 * `{ClassOrderer_OrderAnnotation}`: sorts test classes _numerically_ based on values
   specified via the `{Order}` annotation
 * `{ClassOrderer_Random}`: orders test classes _pseudo-randomly_ and supports
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc b/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc
index be2479032530..aa12cdb745b7 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-instance-lifecycle.adoc
@@ -3,11 +3,11 @@
 In order to allow individual test methods to be executed in isolation and to avoid
 unexpected side effects due to mutable test instance state, JUnit creates a new instance
 of each test class before executing each _test method_ (see
-<<writing-tests-definitions>>). This "per-method" test instance lifecycle is the default
+xref:writing-tests/definitions.adoc[]). This "per-method" test instance lifecycle is the default
 behavior in JUnit Jupiter and is analogous to all previous versions of JUnit.
 
 NOTE: Please note that the test class will still be instantiated if a given _test method_
-is _disabled_ via a <<writing-tests-conditional-execution,condition>> (e.g., `@Disabled`,
+is _disabled_ via a xref:writing-tests/conditional-test-execution.adoc[condition] (e.g., `@Disabled`,
 `@DisabledOnOs`, etc.) even when the "per-method" test instance lifecycle mode is active.
 
 If you would prefer that JUnit Jupiter execute all test methods on the same test
@@ -25,7 +25,7 @@ easier to implement non-static `@BeforeAll` and `@AfterAll` lifecycle methods as
 `@MethodSource` factory methods by switching to the "per-class" test instance lifecycle
 mode.
 
-[[writing-tests-test-instance-lifecycle-changing-default]]
+[[default]]
 == Changing the Default Test Instance Lifecycle
 
 If a test class or test interface is not annotated with `@TestInstance`, JUnit Jupiter
@@ -36,7 +36,7 @@ To change the default test instance lifecycle mode, set the
 an enum constant defined in `TestInstance.Lifecycle`, ignoring case. This can be supplied
 as a JVM system property, as a _configuration parameter_ in the
 `LauncherDiscoveryRequest` that is passed to the `Launcher`, or via the JUnit Platform
-configuration file (see <<running-tests-config-params>> for details).
+configuration file (see xref:running-tests/configuration-parameters.adoc[] for details).
 
 For example, to set the default test instance lifecycle mode to `Lifecycle.PER_CLASS`,
 you can start your JVM with the following system property.
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc b/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc
index 81151f883771..d5425fe0767f 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-interfaces-and-default-methods.adoc
@@ -5,7 +5,7 @@ JUnit Jupiter allows `@Test`, `@RepeatedTest`, `@ParameterizedTest`, `@TestFacto
 methods. `@BeforeAll` and `@AfterAll` can either be declared on `static` methods in a
 test interface or on interface `default` methods _if_ the test interface or test class is
 annotated with `@TestInstance(Lifecycle.PER_CLASS)` (see
-<<writing-tests-test-instance-lifecycle>>). Here are some examples.
+xref:writing-tests/test-instance-lifecycle.adoc[]). Here are some examples.
 
 [source,java]
 ----
@@ -19,8 +19,8 @@ include::example$java/example/testinterface/TestInterfaceDynamicTestsDemo.java[t
 
 `@ExtendWith` and `@Tag` can be declared on a test interface so that classes that
 implement the interface automatically inherit its tags and extensions. See
-<<extensions-lifecycle-callbacks-before-after-execution>> for the source code of the
-<<extensions-lifecycle-callbacks-timing-extension, TimingExtension>>.
+xref:extensions/test-lifecycle-callbacks.adoc#before-after-execution[Before and After Test Execution Callbacks] for the source code of the
+xref:extensions/test-lifecycle-callbacks.adoc#timing-extension[TimingExtension].
 
 [source,java]
 ----
diff --git a/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc b/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc
index 9afe87e2c9be..c1a9426b6e1f 100644
--- a/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/test-templates.adoc
@@ -6,8 +6,8 @@ invocation contexts returned by the registered providers. Thus, it must be used
 conjunction with a registered `{TestTemplateInvocationContextProvider}` extension. Each
 invocation of a test template method behaves like the execution of a regular `@Test`
 method with full support for the same lifecycle callbacks and extensions. Please refer to
-<<extensions-test-templates>> for usage examples.
+xref:extensions/providing-invocation-contexts-for-test-templates.adoc[] for usage examples.
 
-NOTE: <<writing-tests-repeated-tests>> and
-<<writing-tests-parameterized-tests, Parameterized Tests>> are built-in specializations of
+NOTE: xref:writing-tests/repeated-tests.adoc[] and
+xref:writing-tests/parameterized-classes-and-tests.adoc[Parameterized Tests] are built-in specializations of
 test templates.
diff --git a/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc b/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc
index 51fb4e18e371..531573c1bc78 100644
--- a/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc
+++ b/documentation/modules/ROOT/pages/writing-tests/timeouts.adoc
@@ -26,7 +26,7 @@ within the specified duration but does not verify the execution time of each ind
 If `@Timeout` is present on a `@TestTemplate` method — for example, a `@RepeatedTest` or
 `@ParameterizedTest` — each invocation will have the given timeout applied to it.
 
-[[writing-tests-declarative-timeouts-thread-mode]]
+[[thread-mode]]
 == Thread mode
 
 The timeout can be applied using one of the following three thread modes: `SAME_THREAD`,
@@ -40,17 +40,17 @@ example, `ThreadLocal` transaction management.
 
 On the contrary when `SEPARATE_THREAD` is used, like the `assertTimeoutPreemptively()`
 assertion, the execution of the annotated method proceeds in a separate thread, this
-can lead to undesirable side effects, see <<writing-tests-assertions-preemptive-timeouts>>.
+can lead to undesirable side effects, see xref:writing-tests/assertions.adoc#preemptive-timeouts[Preemptive Timeouts with `assertTimeoutPreemptively()`].
 
 When `INFERRED` (default) thread mode is used, the thread mode is resolved via the
 `junit.jupiter.execution.timeout.thread.mode.default` configuration parameter. If the
 provided configuration parameter is invalid or not present then `SAME_THREAD` is used as
 fallback.
 
-[[writing-tests-declarative-timeouts-default-timeouts]]
+[[default-timeouts]]
 == Default Timeouts
 
-The following <<running-tests-config-params, configuration parameters>> can be used to
+The following xref:running-tests/configuration-parameters.adoc[configuration parameters] can be used to
 specify default timeouts for all methods of a certain category unless they or an enclosing
 test class is annotated with `@Timeout`:
 
@@ -100,7 +100,7 @@ omitted. Specifying no unit is equivalent to using seconds.
 |===
 
 
-[[writing-tests-declarative-timeouts-polling]]
+[[polling]]
 == Using @Timeout for Polling Tests
 
 When dealing with asynchronous code, it is common to write tests that poll while waiting
@@ -127,25 +127,25 @@ asynchronous tests, consider using a dedicated library such as
 link:https://github.com/awaitility/awaitility[Awaitility].
 
 
-[[writing-tests-declarative-timeouts-debugging]]
+[[debugging]]
 == Debugging Timeouts
 
-Registered <<extensions-preinterrupt-callback>> extensions are called prior to invoking
+Registered xref:extensions/pre-interrupt-callback.adoc[] extensions are called prior to invoking
 `Thread.interrupt()` on the thread that is executing the timed out method. This allows to
 inspect the application state and output additional information that might be helpful for
 diagnosing the cause of a timeout.
 
 
-[[writing-tests-declarative-timeouts-debugging-thread-dump]]
+[[debugging-thread-dump]]
 === Thread Dump on Timeout
 
-JUnit registers a default implementation of the <<extensions-preinterrupt-callback>>
+JUnit registers a default implementation of the xref:extensions/pre-interrupt-callback.adoc[]
 extension point that dumps the stacks of all threads to `System.out` if enabled by setting
 the `junit.jupiter.execution.timeout.threaddump.enabled`
-<<running-tests-config-params, configuration parameter>> to `true`.
+xref:running-tests/configuration-parameters.adoc[configuration parameter] to `true`.
 
 
-[[writing-tests-declarative-timeouts-mode]]
+[[mode]]
 == Disable @Timeout Globally
 
 When stepping through your code in a debug session, a fixed timeout limit may influence
diff --git a/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.0.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.0.adoc
index 49435a023433..a4271f992d78 100644
--- a/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.0.adoc
+++ b/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.0.adoc
@@ -1,4 +1,4 @@
-[[release-notes-6.0.0]]
+[[v6.0.0]]
 == 6.0.0
 
 *Date of Release:* September 30, 2025
diff --git a/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.1.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.1.adoc
index 1972f8a9971e..b48b6a74c4f1 100644
--- a/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.1.adoc
+++ b/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.1.adoc
@@ -1,4 +1,4 @@
-[[release-notes-6.0.1]]
+[[v6.0.1]]
 == 6.0.1
 
 *Date of Release:* October 31, 2025
@@ -10,25 +10,25 @@ link:{junit-framework-repo}+/milestone/110?closed=1+[6.0.1] milestone page in th
 repository on GitHub.
 
 
-[[release-notes-6.0.1-junit-platform]]
+[[v6.0.1-junit-platform]]
 === JUnit Platform
 
-[[release-notes-6.0.1-junit-platform-bug-fixes]]
+[[v6.0.1-junit-platform-bug-fixes]]
 ==== Bug Fixes
 
 * The `jdk.jfr` package is now an optional import when using the `junit-platform-launcher`
   as an OSGi bundle.
 
-[[release-notes-6.0.1-junit-platform-new-features-and-improvements]]
+[[v6.0.1-junit-platform-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * Legacy documentation regarding Java 8 compatibility has been removed from the User Guide.
 
 
-[[release-notes-6.0.1-junit-jupiter]]
+[[v6.0.1-junit-jupiter]]
 === JUnit Jupiter
 
-[[release-notes-6.0.1-junit-jupiter-bug-fixes]]
+[[v6.0.1-junit-jupiter-bug-fixes]]
 ==== Bug Fixes
 
 * A regression introduced in version 6.0.0 caused an exception when using `@CsvSource` or
@@ -44,13 +44,13 @@ repository on GitHub.
 * Fix support for test methods with the same signature as package-private methods declared
   in super classes in different packages.
 
-[[release-notes-6.0.1-junit-jupiter-deprecations-and-breaking-changes]]
+[[v6.0.1-junit-jupiter-deprecations-and-breaking-changes]]
 ==== Deprecations and Breaking Changes
 
 * The `org.junit.jupiter.migrationsupport` module descriptor has been marked as deprecated
   for removal.
 
-[[release-notes-6.0.1-junit-jupiter-new-features-and-improvements]]
+[[v6.0.1-junit-jupiter-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * The `@CsvSource` and `@CsvFileSource` annotations now allow specifying a custom comment
@@ -61,10 +61,10 @@ repository on GitHub.
   without having to cast class literals to `Class<@Nullable T>`.
 
 
-[[release-notes-6.0.1-junit-vintage]]
+[[v6.0.1-junit-vintage]]
 === JUnit Vintage
 
-[[release-notes-6.0.1-junit-vintage-new-features-and-improvements]]
+[[v6.0.1-junit-vintage-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * Allow disabling the reporting of discovery issues by the JUnit Vintage engine (including
diff --git a/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.2.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.2.adoc
index 382420cc04bc..74a9291a1a3f 100644
--- a/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.2.adoc
+++ b/documentation/modules/ROOT/partials/release-notes/release-notes-6.0.2.adoc
@@ -1,4 +1,4 @@
-[[release-notes-6.0.2]]
+[[v6.0.2]]
 == 6.0.2
 
 *Date of Release:* ❓
@@ -10,59 +10,59 @@ link:{junit-framework-repo}+/milestone/113?closed=1+[6.0.2] milestone page in th
 repository on GitHub.
 
 
-[[release-notes-6.0.2-junit-platform]]
+[[v6.0.2-junit-platform]]
 === JUnit Platform
 
-[[release-notes-6.0.2-junit-platform-bug-fixes]]
+[[v6.0.2-junit-platform-bug-fixes]]
 ==== Bug Fixes
 
 * Make `ConsoleLauncher` compatible with JDK 26 by avoiding final field mutations.
 
-[[release-notes-6.0.2-junit-platform-deprecations-and-breaking-changes]]
+[[v6.0.2-junit-platform-deprecations-and-breaking-changes]]
 ==== Deprecations and Breaking Changes
 
 * ❓
 
-[[release-notes-6.0.2-junit-platform-new-features-and-improvements]]
+[[v6.0.2-junit-platform-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * ❓
 
 
-[[release-notes-6.0.2-junit-jupiter]]
+[[v6.0.2-junit-jupiter]]
 === JUnit Jupiter
 
-[[release-notes-6.0.2-junit-jupiter-bug-fixes]]
+[[v6.0.2-junit-jupiter-bug-fixes]]
 ==== Bug Fixes
 
 * Allow using `@ResourceLock` on classes annotated with `@ClassTemplate` (or
   `@ParameterizedClass`).
 
-[[release-notes-6.0.2-junit-jupiter-deprecations-and-breaking-changes]]
+[[v6.0.2-junit-jupiter-deprecations-and-breaking-changes]]
 ==== Deprecations and Breaking Changes
 
 * ❓
 
-[[release-notes-6.0.2-junit-jupiter-new-features-and-improvements]]
+[[v6.0.2-junit-jupiter-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * ❓
 
 
-[[release-notes-6.0.2-junit-vintage]]
+[[v6.0.2-junit-vintage]]
 === JUnit Vintage
 
-[[release-notes-6.0.2-junit-vintage-bug-fixes]]
+[[v6.0.2-junit-vintage-bug-fixes]]
 ==== Bug Fixes
 
 * ❓
 
-[[release-notes-6.0.2-junit-vintage-deprecations-and-breaking-changes]]
+[[v6.0.2-junit-vintage-deprecations-and-breaking-changes]]
 ==== Deprecations and Breaking Changes
 
 * ❓
 
-[[release-notes-6.0.2-junit-vintage-new-features-and-improvements]]
+[[v6.0.2-junit-vintage-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * ❓
diff --git a/documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M1.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M1.adoc
index 7f489ef6713d..98a7fd44094c 100644
--- a/documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M1.adoc
+++ b/documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M1.adoc
@@ -1,4 +1,4 @@
-[[release-notes-6.1.0-M1]]
+[[v6.1.0-M1]]
 == 6.1.0-M1
 
 *Date of Release:* November 17, 2025
@@ -14,17 +14,17 @@ link:{junit-framework-repo}+/milestone/104?closed=1+[6.1.0-M1] milestone page in
 repository on GitHub.
 
 
-[[release-notes-6.1.0-M1-junit-platform]]
+[[v6.1.0-M1-junit-platform]]
 === JUnit Platform
 
-[[release-notes-6.1.0-M1-junit-platform-deprecations-and-breaking-changes]]
+[[v6.1.0-M1-junit-platform-deprecations-and-breaking-changes]]
 ==== Deprecations and Breaking Changes
 
 * Deprecate constructors for `ForkJoinPoolHierarchicalTestExecutorService` in favor of the
   new `ParallelHierarchicalTestExecutorServiceFactory` that also supports
   `WorkerThreadPoolHierarchicalTestExecutorService`.
 
-[[release-notes-6.1.0-M1-junit-platform-new-features-and-improvements]]
+[[v6.1.0-M1-junit-platform-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * Support for creating a `ModuleSelector` from a `java.lang.Module` and using
@@ -42,15 +42,15 @@ repository on GitHub.
   `false`.
 
 
-[[release-notes-6.1.0-M1-junit-jupiter]]
+[[v6.1.0-M1-junit-jupiter]]
 === JUnit Jupiter
 
-[[release-notes-6.1.0-M1-junit-jupiter-new-features-and-improvements]]
+[[v6.1.0-M1-junit-jupiter-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * Introduce new module `org.junit.start` for writing and running tests. It simplifies
   using JUnit in compact source files together with a single `module import` statement.
-  Find an example at the <<../user-guide/#running-tests-source-launcher, User Guide>>.
+  Find an example at the xref:running-tests/source-launcher.adoc[User Guide].
 * Introduce new `dynamicTest(Consumer<? super Configuration>)` factory method for dynamic
   tests. It allows configuring the `ExecutionMode` of the dynamic test in addition to its
   display name, test source URI, and executable.
@@ -65,10 +65,10 @@ repository on GitHub.
   `junit.jupiter.execution.parallel.config.executor-service` configuration parameter to
   in order to add support for `WorkerThreadPoolHierarchicalTestExecutorService`. Please
   refer to the
-  <<../user-guide/index.adoc#writing-tests-parallel-execution-config-executor-service, User Guide>>
+  xref:writing-tests/parallel-execution.adoc#config-executor-service[User Guide]
   for details.
 
-[[release-notes-6.1.0-M1-junit-vintage]]
+[[v6.1.0-M1-junit-vintage]]
 === JUnit Vintage
 
 No changes.
diff --git a/documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M2.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M2.adoc
index 9a9ee9e870cc..f55ef4a580f6 100644
--- a/documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M2.adoc
+++ b/documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M2.adoc
@@ -1,4 +1,4 @@
-[[release-notes-6.1.0-M2]]
+[[v6.1.0-M2]]
 == 6.1.0-M2
 
 *Date of Release:* ❓
@@ -9,59 +9,59 @@ For a complete list of all _closed_ issues and pull requests for this release, c
 link:{junit-framework-repo}+/milestone/112?closed=1+[6.1.0-M2] milestone page in the JUnit
 repository on GitHub.
 
-[[release-notes-6.1.0-M2-junit-platform]]
+[[v6.1.0-M2-junit-platform]]
 === JUnit Platform
 
-[[release-notes-6.1.0-M2-junit-platform-bug-fixes]]
+[[v6.1.0-M2-junit-platform-bug-fixes]]
 ==== Bug Fixes
 
 * Clarify `TestDescriptor` implementation requirements.
 
-[[release-notes-6.1.0-M2-junit-platform-deprecations-and-breaking-changes]]
+[[v6.1.0-M2-junit-platform-deprecations-and-breaking-changes]]
 ==== Deprecations and Breaking Changes
 
 * ❓
 
-[[release-notes-6.1.0-M2-junit-platform-new-features-and-improvements]]
+[[v6.1.0-M2-junit-platform-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * ❓
 
-[[release-notes-6.1.0-M2-junit-jupiter]]
+[[v6.1.0-M2-junit-jupiter]]
 === JUnit Jupiter
 
-[[release-notes-6.1.0-M2-junit-jupiter-bug-fixes]]
+[[v6.1.0-M2-junit-jupiter-bug-fixes]]
 ==== Bug Fixes
 
 * ❓
 
-[[release-notes-6.1.0-M2-junit-jupiter-deprecations-and-breaking-changes]]
+[[v6.1.0-M2-junit-jupiter-deprecations-and-breaking-changes]]
 ==== Deprecations and Breaking Changes
 
 * ❓
 
-[[release-notes-6.1.0-M2-junit-jupiter-new-features-and-improvements]]
+[[v6.1.0-M2-junit-jupiter-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * `JAVA_27` has been added to the `JRE` enum for use with `JRE`-based execution conditions.
 * https://www.junit-pioneer.org/[JUnit Pioneer]'s `DefaultLocaleExtension` and
   `DefaultTimeZoneExtension` are now part of the JUnit Jupiter. Find examples in the
-  <<../user-guide/index.adoc#writing-tests-built-in-extensions-DefaultLocaleAndTimeZone, User Guide>>.
+  xref:writing-tests/built-in-extensions.adoc#DefaultLocaleAndTimeZone[User Guide].
 
-[[release-notes-6.1.0-M2-junit-vintage]]
+[[v6.1.0-M2-junit-vintage]]
 === JUnit Vintage
 
-[[release-notes-6.1.0-M2-junit-vintage-bug-fixes]]
+[[v6.1.0-M2-junit-vintage-bug-fixes]]
 ==== Bug Fixes
 
 * ❓
 
-[[release-notes-6.1.0-M2-junit-vintage-deprecations-and-breaking-changes]]
+[[v6.1.0-M2-junit-vintage-deprecations-and-breaking-changes]]
 ==== Deprecations and Breaking Changes
 
 * ❓
 
-[[release-notes-6.1.0-M2-junit-vintage-new-features-and-improvements]]
+[[v6.1.0-M2-junit-vintage-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * ❓
diff --git a/documentation/modules/ROOT/partials/release-notes/release-notes-TEMPLATE.adoc b/documentation/modules/ROOT/partials/release-notes/release-notes-TEMPLATE.adoc
index 3861188d538e..6bcfc9452fc5 100644
--- a/documentation/modules/ROOT/partials/release-notes/release-notes-TEMPLATE.adoc
+++ b/documentation/modules/ROOT/partials/release-notes/release-notes-TEMPLATE.adoc
@@ -13,7 +13,7 @@
 // 5) 'include:' this new file in ../../pages/release-notes.adoc.
 // 6) Delete this entire comment block.
 //
-[[release-notes-VERSION]]
+[[vVERSION]]
 == VERSION
 
 *Date of Release:* ❓
@@ -25,58 +25,58 @@ link:{junit-framework-repo}+/milestone/MILESTONE_NUMBER?closed=1+[VERSION] miles
 repository on GitHub.
 
 
-[[release-notes-VERSION-junit-platform]]
+[[vVERSION-junit-platform]]
 === JUnit Platform
 
-[[release-notes-VERSION-junit-platform-bug-fixes]]
+[[vVERSION-junit-platform-bug-fixes]]
 ==== Bug Fixes
 
 * ❓
 
-[[release-notes-VERSION-junit-platform-deprecations-and-breaking-changes]]
+[[vVERSION-junit-platform-deprecations-and-breaking-changes]]
 ==== Deprecations and Breaking Changes
 
 * ❓
 
-[[release-notes-VERSION-junit-platform-new-features-and-improvements]]
+[[vVERSION-junit-platform-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * ❓
 
 
-[[release-notes-VERSION-junit-jupiter]]
+[[vVERSION-junit-jupiter]]
 === JUnit Jupiter
 
-[[release-notes-VERSION-junit-jupiter-bug-fixes]]
+[[vVERSION-junit-jupiter-bug-fixes]]
 ==== Bug Fixes
 
 * ❓
 
-[[release-notes-VERSION-junit-jupiter-deprecations-and-breaking-changes]]
+[[vVERSION-junit-jupiter-deprecations-and-breaking-changes]]
 ==== Deprecations and Breaking Changes
 
 * ❓
 
-[[release-notes-VERSION-junit-jupiter-new-features-and-improvements]]
+[[vVERSION-junit-jupiter-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * ❓
 
 
-[[release-notes-VERSION-junit-vintage]]
+[[vVERSION-junit-vintage]]
 === JUnit Vintage
 
-[[release-notes-VERSION-junit-vintage-bug-fixes]]
+[[vVERSION-junit-vintage-bug-fixes]]
 ==== Bug Fixes
 
 * ❓
 
-[[release-notes-VERSION-junit-vintage-deprecations-and-breaking-changes]]
+[[vVERSION-junit-vintage-deprecations-and-breaking-changes]]
 ==== Deprecations and Breaking Changes
 
 * ❓
 
-[[release-notes-VERSION-junit-vintage-new-features-and-improvements]]
+[[vVERSION-junit-vintage-new-features-and-improvements]]
 ==== New Features and Improvements
 
 * ❓

From 3e4bbf7f4e10e85fdfe237dbf88e012905640f97 Mon Sep 17 00:00:00 2001
From: Marc Philipp <mail@marcphilipp.de>
Date: Sun, 7 Dec 2025 17:03:22 +0100
Subject: [PATCH 57/57] Remove obsolete Asciidoctor resources

---
 .../asciidoc/docinfos/docinfo-footer.html     |  33 ----
 .../src/docs/asciidoc/docinfos/docinfo.html   |  23 ---
 .../docs/asciidoc/resources/fonts/Symbola.ttf | Bin 2440452 -> 0 bytes
 .../resources/themes/junit-pdf-theme.yml      |   6 -
 .../asciidoc/resources/themes/rouge_junit.rb  | 148 ------------------
 .../src/docs/asciidoc/tocbot-3.0.2/styles.css |   1 -
 .../src/docs/asciidoc/tocbot-3.0.2/tocbot.css |   1 -
 .../src/docs/asciidoc/tocbot-3.0.2/tocbot.js  | 136 ----------------
 .../docs/asciidoc/tocbot-3.0.2/tocbot.min.js  |   1 -
 9 files changed, 349 deletions(-)
 delete mode 100644 documentation/src/docs/asciidoc/docinfos/docinfo-footer.html
 delete mode 100644 documentation/src/docs/asciidoc/docinfos/docinfo.html
 delete mode 100644 documentation/src/docs/asciidoc/resources/fonts/Symbola.ttf
 delete mode 100644 documentation/src/docs/asciidoc/resources/themes/junit-pdf-theme.yml
 delete mode 100644 documentation/src/docs/asciidoc/resources/themes/rouge_junit.rb
 delete mode 100644 documentation/src/docs/asciidoc/tocbot-3.0.2/styles.css
 delete mode 100644 documentation/src/docs/asciidoc/tocbot-3.0.2/tocbot.css
 delete mode 100644 documentation/src/docs/asciidoc/tocbot-3.0.2/tocbot.js
 delete mode 100644 documentation/src/docs/asciidoc/tocbot-3.0.2/tocbot.min.js

diff --git a/documentation/src/docs/asciidoc/docinfos/docinfo-footer.html b/documentation/src/docs/asciidoc/docinfos/docinfo-footer.html
deleted file mode 100644
index 221366510a23..000000000000
--- a/documentation/src/docs/asciidoc/docinfos/docinfo-footer.html
+++ /dev/null
@@ -1,33 +0,0 @@
-<script src="../tocbot-3.0.2/tocbot.min.js"></script>
-<script>
-    /* Tocbot dynamic TOC, works with tocbot 3.0.2 */
-    /* Source: https://github.com/asciidoctor/asciidoctor/issues/699#issuecomment-321066006 */
-    var oldtoc = document.getElementById('toctitle').nextElementSibling;
-    var newtoc = document.createElement('div');
-    newtoc.setAttribute('id', 'tocbot');
-    newtoc.setAttribute('class', 'js-toc');
-    oldtoc.parentNode.replaceChild(newtoc, oldtoc);
-    tocbot.init({ contentSelector: '#content',
-        headingSelector: 'h1, h2, h3, h4, h5',
-        smoothScroll: false });
-    var handleTocOnResize = function() {
-        var width = window.innerWidth
-                    || document.documentElement.clientWidth
-                    || document.body.clientWidth;
-        if (width < 768) {
-            tocbot.refresh({ contentSelector: '#content',
-                headingSelector: 'h1, h2, h3, h4, h5',
-                collapseDepth: 6,
-                activeLinkClass: 'ignoreactive',
-                throttleTimeout: 1000,
-                smoothScroll: false });
-        }
-        else {
-            tocbot.refresh({ contentSelector: '#content',
-                headingSelector: 'h1, h2, h3, h4, h5',
-                smoothScroll: false });
-        }
-    };
-    window.addEventListener('resize', handleTocOnResize);
-    handleTocOnResize();
-</script>
diff --git a/documentation/src/docs/asciidoc/docinfos/docinfo.html b/documentation/src/docs/asciidoc/docinfos/docinfo.html
deleted file mode 100644
index 15ca19338a7e..000000000000
--- a/documentation/src/docs/asciidoc/docinfos/docinfo.html
+++ /dev/null
@@ -1,23 +0,0 @@
-<link rel="icon" type="image/png" href="https://junit.org/assets/img/junit-diamond.png" />
-<style>
-  /* Tocbot dynamic TOC, works with tocbot 3.0.2 */
-  /* Source: https://github.com/asciidoctor/asciidoctor/issues/699#issuecomment-321066006 */
-  #tocbot a.toc-link.node-name--H1{ font-style: italic }
-  @media screen{
-    #tocbot > ul.toc-list{ margin-bottom: 0.5em; margin-left: 0.125em }
-    #tocbot ul.sectlevel0, #tocbot a.toc-link.node-name--H1 + ul{
-      padding-left: 0 }
-    #tocbot a.toc-link{ height:100% }
-    .is-collapsible{ max-height:3000px; overflow:hidden; }
-    .is-collapsed{ max-height:0 }
-    .is-active-link{ font-weight:700 }
-    table {
-      overflow-x: auto;
-      display: block;
-      border-width: 0;
-    }
-  }
-  @media print{
-    #tocbot a.toc-link.node-name--H4{ display:none }
-  }
-</style>
diff --git a/documentation/src/docs/asciidoc/resources/fonts/Symbola.ttf b/documentation/src/docs/asciidoc/resources/fonts/Symbola.ttf
deleted file mode 100644
index 055f02558b9a1edd0036bb1f48f435b250d474bb..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 2440452
zcmeF44Sbj5{`f!l<M+Fj8d9N$RV$Mo)>`XPR;`+()=DzT)M6zy6_&yfk`R(fhY*rQ
z=nz7j5JEa3gdt8CI!*|y@BjU|zW2S>6wdFQ|L^~M`0w?4?{hsr-`92B*L_{rS1b`Z
zNJ_<#+=1Es2V8OEvU{a<#}pCE9+*3H_=`{7@>glyVHU2I4IF+_-xnk9XVUt}B9TKI
z3?1GvJ+sj#@8EV6_66h4Iiq-j*L{JsPD>T3``%fTW}G?T>o+=!l{rFM_G?!({*1z=
zv!7dv+pUmUghAtbx^BUL1N13H=S(lzJ>v7v(61I*G<edKac8`|@<!Y*cG2gab4E#V
zYM=Uzu<wTZ<jH58Gk(Ivw-Tk*j8YM|QSp>%({DTY*%PJJMP*|BX`^V~5|2H1Zqg;k
zpI*P$_aadYMBZL_|E{>4KmVseyR#eZh>#yi5Zm}5c#%la?rf39^3$LyX|y9SS5M}z
z%}r|3=B9e%t$Sppc%gY99YS)w4c2@i-TpD&#RPd!T-yC4*V<`$w(U876ya8g9qTKx
zSbbMoc%@5<22344Ua}-PwmY7NNRhp!K&(4HqMV)EyuQSdEWYPTsm5l9ESK%}o03I@
zM>*?cl7F$J``zVqyRl5Nm&>Uz3G=CbS6PmqIgVf_a+BSik`p-|?uP;x3h9A57pY;Y
z*-*QsELAj&5a(Js+1nv`-Ui7gZP{K|coYUnw)-P;Ev%PpyF#*^S5SY8Ic5<nZtmTK
ztPc;vHr!zET><#<MY5wuq5cMSGyD}1&T=W%G$W@t9ZcH9T8r!;UEDd+#VJExg}euv
zq3!{Hk}h^S433@cPDA#SF8;T1b64Hq&-m$zpA?7$c9-C;73w<xwWHy`BZbx?S&Cfj
zwv^VU{3&}A?~yW)a%!S!wJyWWI=RvQT(Z2Ka=Mc#sqS>?sO6?*uVz}djw1!etfAyM
z4W*a$GkGbH4E$=?H`%$kX(*RCZH@n@{U_y;fL^BTwcPhZqy^?$7t}*dv>pNuMz%F|
zMOmAA(7LFB-_@#T^lD!NQx_jlAFC-BE%*K4y+c`17p5MxE&@zFXkDbo9*2#TL3gbm
zQx94fHPCV~dbO_!bz$lZsd?A<e<jJg#;;|tU#V?$A@)eEdo3eP<L^q^uC^&{*ZY-}
zlcrV63)zS=Za_YtG-aM1`!SH;#3kjR^+9=f&)|MO<-{|h?bJLcv{h}d`n+hHttlPa
zs?mS9*F1<bjC-#vr44F&<`EC|t7TeSMlR$T8-lq$gM?j6w$|s;JR5P@v9?~HS$%Gd
zyeN>W-?uz|SFg{zK69pxQNQ7Hug{)7|23s^vt-f^8hby{hgFfUIkJ^Lr~|S+^*-8f
zkJ$#&Kpp!Naq|m$>e{(eGR!lfWubl2->^%NWWQs)pYh+u4RKL7y~BE-{Oh`BNax7$
z`Ygm|n>yBKWffuY97KkrUQ1jr5*BIY`8Iu-mYHdTKhk^0%cogbPJRx4+K|WhkV_@g
zpN!wi8u`4+q&M4HCB0yzYtuhx6YkZd?>*c#rv2nu;{0HVyHJ+c^g{`&=`(+zf89*D
z+HY<qj1kf$dM{?Lqt|C5cxK4ok@_4~w}n4gSLQjX_1u~MhG#zhT*O|iem-a~+J>v+
z2-+X@p!pi9ZM|liLw}Li@HYv6VVZ*Ys^ba53G-4dYdy#0u>*Nr8-LDX+iItyRy*Gt
zUl4ED&cpWY&LZ6x*GSj3)E&=_i+ksB=@GWkU!^BZ?*U}k-kk)(E~I`(Q@50jPy6*>
zz>NHdeVIP@COtY<-3ZgA6?K0EZNE3=)!Q3`eY_kRh5d;?8nYt_XPb27`A!bwGkrJD
zggzJg{FpwQHe&k3_Jkeu+ulIb)1<fJ*~m9Z-%0dSZJ8@v1x3<X$4Hkrs{87Bxali(
z?Mlh8drN0~E$Xk~7TnAvUyQ+q3iOW?)?nmh!qNU|m2~#5krD0##7lo<_`HTXFmo@*
zJ(#}fC7v<mCJ3H4CrX%0d3Hxij{A^gXd2C!u4#P;zYh`SeL!0@P?lPr1}%qmkU;ov
zlJAr7Px``n1pYdET1J6;znrk?1N>J>|Fv*7Y74d##$|98YV8loWuA8d>gM>pT2dA3
zwb*?7B1u&ofs5sEcLj1Pc55X|=XTcZH8>76XuT`$D&`H!DRG=5m^Xm@4L5sm`*Iwk
z-?3M3orqcq!m~a=9bn_m-i&@QybT)(GZnMPU^?my(Dc1Xx+jy?xkyb<A@;R73p3?W
zAU*c`gjW@?1qrqwNv8>)I5aM+0BWR3)x>GAA18mZn|FcT$BI<l0!!g7kzaNoU&s7L
z<Vxgea3bnefV<r<z{!CgcgF1m%#^7jv4fC30|p_LUocNb-U`D5a`C%1?tjlH%)<DX
zp_;HdV8`gB@l{<3kAS9A3F57pW|Qu^@$~<~%gXMyxFbxB)A;{0k}!66gavVTyN^dr
z{;HlpPDN_ocnY)}G;O<21>97v-pena$IXPl-K1;xh1h9%9SwuyRGp8+e=Gyp3;So0
zhapP?u0<*}^t&74rVCsJM_{)H*%fHgs;(j)t%u!OR!se>cDt9-Zw_NT-p=?oRyr~N
z9R>sZ)9L@mNrvpAu6Yhac%NCKeVX+M?L_C+^oz8cn|yK?$z=Q-!W-8;s1uO0c~7X6
zdZzE>-NdEebRUWLjoMG^*rMZsU4dkr(tfl0y~K{&88`J&>s<PZz-%g#vDLd1&NTkp
znsJ4`TKh+L5d9r}o;wuO>~ZGv_e#3XJ4_$i4|Ci&n*(>#(H{!T``rlU%iwd=lkxK*
zYQ}r_IMmDNXEn@+F<VXFg&Qx;gi%k;jUS|%X?_^Hj&~oE4DIV9izpAI`t>g(oOZYg
z#v=D3Y3%NhuKK>_EGC@mB;V;M1H9*P&vWm8!n`3#dOBZXUm`u-Lt@jN+hSKb$CCH=
zrKeXyxo?Iyao-nxA@X_L5r?Kp>(0z+i7%{2Hv=_!({hcrrW}94-G`EhezYlTm5gBu
z^_Zu1r{+2yYkfgmZ3oeg<n1TiOyM1r^l7`{y&>Cs8Fb8~-WB!lw~M`};ptq+T^_i_
zz43QQjk+hDwd>u48P+>t`+W%K+&Dh%C_-78xQILQIO=W0q3=b_q_r787%SW-V$bP#
z>MvwGxdr`40aqdKWh}`@2IHTR%p<kD++Nfd<CS*^>N{Wx?p~J8%ohz_M@jd-!i;f>
zhpMypDN@J8VC?3-qM?peYUeQi#NWYUFPizqv4qh8JKj|o$Kz?zv5`2KKNfqh%Uu6_
z%Kz_jY-Bt6j$p3&Ybl)*x{+5GJ$30mE1jd1gTIn67D-=cF6$40dDzah%uKoinZP@L
zg#7rFm6uI83z7BE2k~lsn>0@p9`P#r)T&AJ8-AQB%zmO@{%MlwD=14-&y<0#CpcOL
z)VaxbEvfadb)aoP>p|;Z^Ils<c(zG<y0!(akH{MIpCk2oa7ZulxOd}^bZR|m|KOf4
zBf_~=D7CL}uc3U7mOQ_k99z2_{0`VZPq>o_|AD<y+j*GQFl|2V)U=f#O<~@{FirnO
zJJR`<wtsDdp{$-e^9-0dygrY#5v?DUVO(LkxC3Oc&WWny&^}qq8Tb2phYagWpA|FD
zsx5<h59`G|Gum#0`U%UaT59<+FO5(>{u{{4q_6iB^%0?cZIyKGH~cP?*JntNbP<lu
zL;V5B*LY@LAz#e#!ZM4#g}Wzl-vfCr;eCxfOIqsMlg1Oidxm8lZHawn+z0g?wgZoF
zb&l(=5%F5H(%CWgUczy)=lnjgZ{3$;Z~9T}Zzo^RTMxoW>h=w|5gvtd_&m^KFS{7W
z8E18#Qk75J*0EaEZ7^rfv8NSg6VX2f=U}!;<mVp(xzTx)@j&~Po9HY4!gKou{XA_|
z`viSvoy+Ag_gwVKJJ<((ggb`xDfQ_S7_&^D@C|y}shQV?ebETaMEbjZ@C)8^<a;V{
zt-w6KR@2!$YxFl}F0Or*#y?2b`sFghOP9578FkQ=aL2<epzJ-?P|UO041c&cVGKh}
zKNzOhq*c=!q?5FEGVd9<H}4bsOD}dVY1Z^rrz=R4NdxO}j#6UQ(^8!oakc#hb64el
z-WS0+j(P19*iDdBZvb)@um)$p5SOUis9*aO^zk`-iE+n#*x7^mR!OlpvWB;T_1H2w
z%Kku_Yj|dUukLYI?dE4m3ElX&Q#N%Vk@8tW8>K&VpNyM1NW&E5EMR=lH7LrpjYFRu
z=}F&yA^HZmKMFg_f_J`Np1w~t#r)6G%72XKhj&c-z1UBYD>2Ui?0LUx={$v+9+rCS
z;$`B$Ir1b}0TJ}fW!&p|_ggGyvCh%OIR##kv*=^a@_0{jUXZi2T(yi$IUOp;nDU&6
z9<XbzWkoqOv$N$W>v?Ize7=o&_wjJkHTDbdIc>b2L76X(&3EhKPxD9F)5gtvhW!Qe
zIxY9>B*7UWnZ|x0<*a2&89NJ+Z^C=b5x<k8cy4Zvqw{t%2Y&%s6MYu|Gmj4Ev&h}Y
zfzElSzzo#=kk13N&8qw0HOzE=+XVDEZ2-(XcSqoINXN}zLFd70=0H;z2Hl_!sF}jN
z-^`u!kUGxs*ctN{asO4z(Chp<oL7?<eP7sJ9+y=UaCZ%8`bnRO`~0x)H)A91<ySHs
zyI3RBKG6F;8IB#lBh6e=+nx5wv{BP{?p+r>pq??WS+HK(7P(R9v97Kk)si}9*wt&I
zu~=MREg#o$P}de}%im4MfyTDbT*o9W$51kN(X|Pk@9jq(>X2@oa~(idud9aZO9zxX
z-v5E}V{#N9djlDcX}>4Un9E!&l;PY(-;+!~Q(KZ2)-jW-*HV~g=z45GBkvUa={jqz
zImo{H*kAV56aR0z-;e$8v_qZmJNFRJ0o>8v%=&vMy|AA5D`OuY(0&!=zMAy?o~%`m
z)oZ{x%>8sN_&`$M-RR@PdZ{fVyt^_!H*zRHdk^m7bFT)b&(?nX08rlg4xQ!m1=Mc`
zSpljC^S&Ca`_)wY`aZdo_iTEqNE$E~QuMv{w}>>xT}${99^{K`kAP7~(D&vzv8~9)
z`|4v`UE-oY5!N8ZeGy4-X(&d5dEeA`&RY2N)IKXDkw@VIU_?;N`?S7OAAktGdE{x*
zb`bI>;?Q^N-@u<uJY~3@1A~E?o8ew0g!K@XWmr~WKErf}=?UWs{T)dDUOk5K97z6N
zy@csFko=?h-e3ClnXiq-TBqGtI$QIQx?TwTOS^w1<-MA+Wwg}wAMM}mmAGFU_^TA#
zu8e(8`PK_SkC{IA;4*USnvt$&+Rp^>)M^WkuE9WcozOREKVaGh?Zao})wL)^*QNGX
zMyCDUgWJ1+HlpiB>Q?hd(j^L^v>zZm^wvpnGowZ?rTXvJe@q@uSMaaj>yrp8$rqW=
zcjKiRCTnKbz`fQdQmWEfXSL@0a$n|erAEHZTp5@vr4d&jd%0|5-nWf#wxOT=>lpW%
zunj^I+DLkx*Cm~GyQa>W($sxjn$}d?o8)l&HR%XXdr{UB&gXkM`vx>^&U$HVSS^P~
zM#u`{yGpLx6Cn-7FvVXXC$si+vOf?%I)_~+Dc(c!q2jzRli81O9dpl@Rn0zx)h^%U
zohs>JFTiaQ@7tNAX%BJU73^K;VAR?8GkY1Vm-go6Kcb?HyPEfeh7v`6JoJLo0@=%b
zPD(@U!=yh9(>XBqUEvZi-~Ew)+&}Lx`mSQ;#B&3+hB+a=7H{4|R6hed*5!4s?2V4E
zwV8MHA8GgORnYm7J}(K)nJY1WF>{1WS*Y_szeJALIhW2y_y&;b4(B~$EqX=Anj4Ue
zG2RJ`EyH;>R>}bVHt80~$Ov<A#)f>a72&Rz#X9F?j{13=-MpbHzkC`Hm{+w&pA)C5
zEpj{Wxo5-cKrgCj7(b`Ljja3VdNOi%d#kN^e^x&`uzMvg!}vnEyBFV+QoUQ@9LZ!Y
zYb@(+{k)$^>r3SCE2+mfqGpT_W1Y&_CciAU#v3Bt{dweXu3TrhGxm!6g*5V>;9Jq@
zauR*dQNGI@^DaqZ&94`8r+oKu%JePFQY6QFL|XWDDa&4zla}wrl2M1}EMXq+!-CmB
z+NjPYA0r*gkl1(hO=j&@`$PXlX+?Zzx=X18O2b_x4|`Y2be&r#OqIL&z9Zh%l=Dc|
zYac@%j9et+BV(m!ou>%rS}FDB%e(GQ(!lp8?+mzIE^){5-CQ}FHQvi&4|@Hj%)Ld*
z_~umN*s&>oPr1k2DyMj_%IVRD^nG8kW?aB}Ua<EhVPo|kl$^j!WiN;Z`r`wsW~x5T
zSt^&<tfP38MTB*}Xg>L)3{)mEXF8}JYMuLh6PJm1(UzV=uWbzbh)o%Ero5`i!wckx
zJpyhik~N7a@5%{(MLhvC-kDWK(|O0`{ebss^DR@`di3siSVj`A+UdN|n@&H$x>|y+
z9X~0@(JvLiQ2M`V$QHF^OZ2m9F-_gnq_)4%E-)XCY^j9ifgGGjI12h%*q>jUz+GqL
z;6Oc%K5mc_>RqvP!(6NV>HTH#{HR^14rSneI`N;0db;9%D#r%0x0<8xh5k45PuwjO
z+|@3>%P>=>xu2MDj8yghz}*#oYq?UvzNh;0m+wu#>Os>PmVHh2G}e)HOud<JC&{Q)
zKaF|uAb*LBRlE_hTwz~~k)hh|io5AD-msK4llXo&^{e^0N?{zDYL8&N1m?mwR)ZUp
z&en2=_mWHtv8P%|_SD!<)J+opI}+ElnmDZV`Hh$dbY@K4M;-fz^Gh7ucUPDne5Nu;
zSGX6?q)*cb+7?oYt7)LGY4;yd4=0@A^o`S$e<92;t@}ux$K?v;QWk{0kNtk)t8HIf
zAEvRk`ETlL)(3I!;}*M%6u$@c{d;tkBK%jwGc!#I^I?B0(-bw+_7OQUE<<-=n+eje
zsdieZ+w_1!>=x3lOG3XU9@<`{iOdM|!}EQW;?$EgYpbO3o@DkMvcIqWUiPNXZ$RFa
zpbWxrR8mL9p?RJ9vRn!E|AeeA3;d{hpD=X(N&c$w$L{|*B|YZ3t!=N*vtP%AIW1bs
zUf9u=>;6^d1)PpNow?KV&b3w{^Uz~LN!~Pn)lfFgS%3V{ZzDqju6Jiiebz@?yR)SY
z)KfS9XgPy%q_C!6RePNnpOwqv;O<G%l9<p)`uP>oFS<akbdHpdVVasna!B)NX$|!t
z2WG?l@F6@BNZo%s&8gVizR*{<HPnN&eR_w>p-L^gBFZ)1KkfB1i1yZmb?31)+|vKW
zVygcwJM5R^FCW?5s5S28a=H40L4lm6VN)JVm6*q4uI&h^bskC$XROzOZwD_x{8=%1
z3frE}i}W2#->n!6(s_SQ#Vj?@XZVRy66q_~5M~p~X@Wgfj#j_qcexT-52aG*r%56D
z0sb!ZFPSuGI+YXrZuI$GrPSYyyLj3(eIZvx5>4A@KQ?)+zzsw*;*d8TYyK^0n~6&7
z0m2)o9F)WseV~0*LwmcCw5|8MdQEG`Yxj{th3^J~YLJ0C<QUW;%TX^6{dl9v*9WE@
ze#rRo4skpLT35>xZOIA=%~X2prKu_78tJQ<R@_X|wjG%(3qk8d=RH4qGZ^2C<&J>W
zNF^@>Hx(hg1K#BqTf5>Iceu6GJ!Y~Ccgqx~o7F9Hm25_R7$pB!h4%U(dnWe5AH#E=
z3fa8h{vaPl=zEy!e@Gry{hL`rc>hN1#Zj^Eg4^M6xE4mkQn&=JiHda`d<=PjoizfO
zXBv3}Qq4y~$A53yelwr{?sEO_6y6ld`H!G^lK;<t_cDmx$e0rF-zzVEGUM(az)6#0
z#hVi+)bk#fYiP^d9ax7rMq$74d5V379Ir$Q<P}BT)N+@GyENPwaFeU}b8#2KoXf4?
zdzi{3<{-cKj(|OT6qNb3pDp4}_1ij!#Zh%N=b^4f*K7A%E<yS=4}|?|H+#bi!>$g~
z{XvQq_WBt#KEj}{rp-(;b0;0U#qY~I1US!1E^FC^n%~Hc(oJEGJb^L4eYCAKFw_`_
z`S$aP2`33Z&8Sz1bTZ*Lj$AD(_F|XD)pn`3iM6fN>UW;gh(Fm~&pdIL6fpNFREgOK
zkp@zZZ0!F`xMkAYe}*+WU`)yWZDd4bgye<zKIiLxkeQ163i<m>oJf>9AHh23TJ}(U
zE$NY4NW)=Ln9xU7M5mDU$B|DW=RgVEfW9+wGV(>ZQdaoAk^g*uIu$>;a77^Z)n_mt
zPA5&g7czG+I5)^bC)<$gJ;OUidsBW5@Nd2k{D$m;U5)<UYK%VT0HkAHg9DYbY{K29
zgoZpf*(M)Hkk;Jjdy*I_l3}bR=SGU9DEhplMh4I>O3m8P>G*kwdOHM}#NMV{e*m0D
zUHrs%jtTHF>T)FE`rjir@$7-~JZ&DgksXqo@CmXH{lSs6YutG$@(OKch4;K{VZNX5
z{2;^ev%-IvHZ~$)j;tq6UB6O}hZ^OfYAZBL#BQwGhiw^k3HGld`@`ih3Q|GKwGg{{
zaVc|<v`d4w2?cwZ0UaPeK+OigLf(&bexzZlSv49r`UKE=Vjd=6`GZWHQv#{|Kwr?X
zwH+M;>L(9QgsyNt=$hh-pk=OWNGHIigj87&b)+!z6>%a}@Bbp>uuE4W3;0&>4D~i1
zcpltGY4ZbRP~<ZFJPayd#IJ?@K)|m*3<=(;a3|{FFceONeuU8h?uIMT-z#INuR_+a
z3;o%kX4k?^aY#d<zX7g>?_nc+3hIYGDsmf=@O+KGD_jqA=sVWYhfPLZ09T<VZtvrO
za?Z7u%TV(!sCm<{!TStW!7HHVnjWA(h^MI(^%&ypf_^Xr`84^`@b8G@bjR*uDRgq=
z4!-jh+Qq1^fiZEs8*m4zSIK%zp?fTlXMK-Vvq+M8P8vI_q!ZuW5}l5c=hWdl<SIE%
zahtMEp%k&64fZuM(fS*Ey{TU%tiS(k85v7{D2r+uk{8OwSE>1<-XpY$$anBF?Pg@0
z$e++F)L-O*IP9w_j2w?&+NKgojbrMEI*MpHuV#!<Nt_YP{4<d$fu!ssw3!If{|K25
z8uvfoW+_bUz*xe18fDa*wo|=cp=+xOea1A_5k%J#*f+a8k|qsU!?;}~?!$GN=IRcr
z*N6zutivP>HDR8FTgEBTcb|iy(BH~C_f|QHZ>NI4d67l9KTQ%1!J390d?U3NalU&I
z=eu8&Q(+R{0hcQF0L%xl{>8a4#g$k$>b+^5wKA<1)6pwu2Ij*9y~^`+e?LsB!9>(G
zuybqJsk<6>s<wyxi}t@4{_olUi}A|@(*M7hf4Tnt#q$4u9smF4x|a!IUxl2m1m6dT
z2m0akDJ_+-pQ+*A^l_mcH`U(-Lo*}S$NR#4%!2+gFw?lqH%IRynN^d}{GX81{J+rW
z)_`=qpb$o@TD*t;J^E&|MvQu&{M6KI-a@^5zO+(Q&lthlnE9rldd&xBv2&FD=r#Od
zHS9zEr<i@Je*Ka0a6_qP2SVKh?zG;1<&J#m+IaPt7OK68j8)3T(n@h}WISO`ZNDV<
z>-`sc_l0vdW6jyscZ=xwW5%HBF)19ILK(N$^>wqB9LjL4vKGm8_VeuJ;d_{lw~DH(
zSuZD5s{`{$1@kPZZO%M0A5N~8-Kf7>ME^uOYMK2?U+Wz{dL!@CfV-mFM87m<Ct@BD
z`y$ej`M{HM5|HPb-`e78_ANf8XucKB>KXQ_tMFS$ChP3)auy3&O?SD3y)_H=#wpFs
z8bpvU+9cnA4ULdWFGa&Qcc^fp%Dqq)*neV=7%&%Jz&v9CZYDu)SVy?m_XmR?d`k=^
z>-y7_=m_g2_WZQ+T1u<Lq496n`W<^O`VBj-cSr0scTYoIwO5au!<5LWvOaP+>7>m?
zuhVbC)?)Ihb@oTmI>)V54^9dsYQFuL^07w7Wp&%AQFpQxyR8~GYXXJA+-;xl_4_kR
zDCRpJVAn0cd@~Nz`}pS_cbefgS>oTu-Zh;cUKtRdEAHc-Z<^J5&e%<cC8V)-Sxm!h
zFFIe{tB<?IENEW~>U?h6PH4W*a~anCZ^-bwSm^IS`r789``?qHzfc<Yx=%pURObZb
z>$RxWx0v#&ZT4&ZxrA2@Wn;b<hWX|^((?Tg+J`c96Y6V+6PkzaLK!V1KA`@!orUD0
z&UGfUe#Lu1K=pnB{XQD@c{S|SUA(MlyX1YVUC1}mP23F;N7z#~UE70qos|^Hm+88X
zB;gfVuHe_;J<VJnd$&E$WJ4=SAuqbdQBA_mcpGwqeLFSnRIT=EhdOL)M(SE(EfUe!
zWM*VN?`mM*6^Ao+#fB1@&z{8jkwmj@k;Xo018bnkitcUTT_;)L{+3k5i&CBtrXzT_
zIWN>Bhu2W=lUB~M?yIkr7uJ@hD+luL-@?8Oo=-*hTezih$jcK7{xn^6U|9(JSC@0H
zbh$qx4tw{OEB;QxN|J>&rN7gTa)-pin$)xp-K*KJ%nLB9$$rC+`wRX5O8x`;AEZ2z
zEalZQh%0m(S;6;SFnZiaDGTyCjkTD#*@0xOaM(YwuqI*np=8WkSd-8^l+iB4T?4-<
z`swksYx)&k^XA)Ynzpq_4_Ox(M0?ZpK^S-Snm*~{`80X(=8(rGjPuDd-sKJ+_9^B$
zPqLOANY;uw+x<9$8I#s}X2{#dzD7MObEzEUvG>-T>0zI(o^fK0#+<d`44%1%z}G#Z
zs9E3c645i~SKx;Ir0%7-E8(0YXZcwJHFu+!vzVNZ)U$Lh=Pg+m(X+7XH`^UAJ)DX7
ziE@U&0y%{<`m1=(*}LxcME?wD^}oYi!Cree4fDq^e;@Nf($iYPesw+j{}lQ(<bB9y
zgwq&#DSAC$vjN!%c?UA^$KK#<=dXl&9Q!xf!)M}q7Jux2ch@0rLVktRy~e$e4bab$
zo~&_YGcNY@*)z(w|DLRUX0!Iy(_xRO{U!J8L<si=^baBX?bUln;O;W~olJPQ;O`>x
z_%3ssARNw3W;>1WSBbn3c{8#-l6!odHl(iwavAb)<XxDv57#+uuf08*_?u$?I`JHb
z)ckEGzAK6EInuEf^Uk>c9&;_1E$9bIk1)Tc>~6+9hdjQ7qzpK7+cPqWwBpx06!|8y
zrSxQfGp7@F+lo7faBS>8<-9<fII6aLqF#vnS+2sJo)2sW>G)j;*P_<*iG)$b>`Tug
znsbQk9Iif(sP+eAw;SGpe*pWctHxq}5V8<?6m)?IdJU%%{tS;n1?+-S$LE_7aMm-<
zb|knwQ;KsuBn7ap<{TP_{*jYAOacS!({WG#&$@82hveK-v2zgUU4va@fRoRfrtb3(
z{Ht2Aac}5}tO0GOSaEyEsW3^;11Q9?)Tjy9;+qleGnIn63FcHwJtwe^XLud&J$g=p
zJN?*-lhhdO1#*s!y)%+K5&3pyFXz5DbH2i?wa+EY0Zup4T?6|#`j<=0ntv{RVXnVN
z)z<%N!hSE5+IKm6W|IC(_kEduk~8D(dd#_F%Mb2}V6M`I_v|hS^a-qmr$>|ME5>nN
z|Ia)>pYpxsVDvpW1I;tc9?8yr2J$({NPM0$ABw&Y`j@ePIrf=5CAKm0XzV@znAmfy
zFK4qCw{w)f$^R?%wax-2kiJMG`sCXrn>IU$vj`V+=74AKry{3Z3V2SEG5-d6D!8b(
z0w>S(*)-1!XBu|*Fn23)2a?`PV$Sdf`A%#{_z#m0?wZqm>;CuLTawHD0=gIeO1|@*
zLAp89&Yr|<=2@LNqtOrjG3*!0_QqoW3g(>8jM7K>G0qzV=?(MY{J?qhBcu&!*#;}<
zbF|;dcIt9&rkSMEmkhKokxWzWoPY2c8@#!c^;x(%oqCBO8#4Z^K`!N)*a(S~*J9%1
z{CSkSA${sEN*~YqLl?bUkiA}eWk2-n*Vn!Mj_$$#mNj$s^XV86ob`?C>GSxWq4yj%
zU<^IVr?2Mr*$mE7WxLy{chbc>qMpS~rGHHIZO&j^PCVqre+cv7UI)&GWqW%5VLbj0
zB0p!N=Zw6LuX?63JR3{f%C>1Y?g#PkswHtbyE#ul{&;Wh;+!9wV!y@tkZjU77V{;<
zt?jcNVZBSZoS$)SLsCY1kDL1S7{8q#xmWC6B<F?Q`NR!+ZlC;_v&^1@*?QauZp<0l
zZ_qE`oLD~hAiYFCpDN3&*X4Sx8~Y#JrAB{c>WTWMOtalX*e9uH9?<*T&*Kf!@ME(b
zJ&VnA;vS65L~?G0vnkmw_kOTnGTVI(IS%;)l6L35K{=OdTDhb1E0gvv{w0j1cN69$
z?7!#U#V*Lvv_I<2oLhbonFXBvb;l7-_?&8c)O#7epqy0xh@1M<okbohICpUo_LZb-
z3wh<-hI=$>og<NE&LXATFH^?cK|mX5AJH=`^)ct1hx2;CM&cT>7w_-50lmL~_vX&_
z2PT{@?h%+z#Lp9q)2o>i-9&yUCk@LyXFO}}FHj21xm0>d$ZfF{FKN$5?gz2y?j59~
zg1X>72%CKrb}Mlm&SFuPojF_7*>6l(_v42);HF3?z8iFLuLJz~v?Ko~!tBGd^_ei9
z{;Pjg?c!&hs>a3TZpL9f1N94i&u`j26L+^ae#W9?$g^^#*xJNcITeZ8p2hgJY_C)`
z`xXtVW*>Dm-sg<7wTS9_+@yGTq13Qz!h2n@{dzpiP=;}Yk~=d0kQ<)$V*4A?@h8G7
zgJWR<`Z>r{DNZ17&I19fF`I{-&NXUtYhboEkQ?{9VGgmc`x<uKi&5-RCSE>alNL+o
zFH7QayEEecc)p8W^5X%0Q8D9EailzMr|Dq6UhJO}hqGnHOuCAh8x}|V1#UD=%&{UP
zaT}!HWzOWCjM@E|F<+uDDE1bk9s^qg?mz}OkDy*f9G#Gqkxw1be-<;>F7{qUj)pTS
zrw1v|naG{E+X0USoR4gQThiv9h-?DeNaI}eq)**B<d3*dVhk?kTYWL>mc=~h#oTLH
zOy5!Lo`j?>+=p=6mw3L2hrzpiG5vcn{Xwxa6fQ(P5(Z%YEOG-f4fi*iwSZ#IxfR=Q
zW3FNK1}#^0_Z8)#dC;=Z_==$y`rFWxR)_Gty2v${C*eo+#Oo9g-g(qryI5mq8guT8
zIeT=U^t89cPOy1r@Qy*P?+&AZcO#yWo}Rul@P4Fjo##N`9k#~x?nKnz@s7|1`C@#&
z&pTjG-V1s<7X*HmqwdcA3E&;ZU9ht`qqq!p0kQ>hkz^)337sU9eQ24Cx0$RfXL?iN
zE8N#d;?FI|+{fKC)P<O}Lf(#_D*WKiyBkU*)6%;dMq<|i{fEf=U=HCBkAFuTCyTJ`
zxOucOVK$J==y>>EGV2gmbO_uQH;<rZ4v`tTKr$1tkCLv0W0Cmb9Xc~QlW@Kz9Ywe!
zjyh?99EG31V1G4w^6T$FTG-zo_nSak5*7mCCg3Kr75R{49(0;y*1Z%ry$H7%;T}hR
zxSPv81vk@C6DNCmG9%<ILfT!<J2HRI<h?#KVIu5-yYT-7>8&Krw~#|IdpZtvnaO=o
znRRf-8O2PW@{ay3?mzKa)RcXl_u|xjinQDmcdPCb$WP(`ApeIp#}8$pB#g$*^Q5(F
zJg&$X%)!S!bKgvdyKK0RDl>sHX3tq>ggUk6;r>hPPr!`2b@A(O2>69`jEk#z2hH^I
z0w~`|9n^u0(1z6B`5<nl=8Un12zhcpkE@M)ZEp+E??O(FyN^;QyyItbPhckBATsOp
zA*{R6?~LQ&*3-5|n*D9034hV{r2Bo`ZO6^c<cYdd{C6<FJx-Li<s1W-#Pv=S)Mvm(
z+-aJLL+dV5w$~5ii;082J=4!6P78NGz+BvrKjsga+;f!4I>TQ5<AFYiSJp|UVqJ`z
zbN7ZFrb~Xr9xQb~3cn*|oO6PVa#FZESL<Vo47cya><RXzb(Lf7M=+buT1+z}?XX&E
zol@??TY_xhJpY(D(hohv^?N=?j$up@zO#vg70-y!w;1Rz#rZ^9C{~WNRK4|~^kW^O
zAJ4w*m-D5cQ>HQeeBJM1|HS;tC%hl{4kXe(pds=i7_C^-IX9;JUq|5%oI=)HXGpTw
zNRIOkVz1E!gb|V=XV@vy@>gW=uACwHFa{<E^g{j-M&M34C14n`pF(j7Y3!jeMrGMA
z#m&`@wVhwVd)EfJ24?TYz7jtH))CUmIwN*XZ8V<W{v$jM`#`LfBV?`U`pf~{SeMb}
zhDnk&M=WbS_n&-%zA#qi%;ru3u%4Heiv6IR?R;qN2G#pP)2(lyujE@pV)q)3Mm<3C
z<#Wm#iJyGl>kPE%eD<2PRIIas?}OYi*A`|1EpJZ|bBdO%aUJ9wj;w_5A({IdlI22Z
z=Pakb`F#m{FvROr>opE%;F*6_BMT+{SA37ZWD}-_TayWaeu6cTJ0r&OE&L)GrZR+e
zo?(WwWSIAf4D(mXFwP_mW8dMhXdmn_H|s)88N+pc!#szy7Tf1TNdWT$#?WHkCyF_5
zp6h+Y-qBy;Qq@L38ncVxX7t5@*-h*vO+Y;;&>zkEO{2IQ_0Ra4>rF=LUet=f-7ToG
z^B+X2J-@RO##u8iU-z>TS4g#;k9*RjVVZC+it8ztxH(}m_UE!LYxKt7kQ(YBKkNn0
zRT%4Y-E{%I_o{hc=orFX0IW^@?_QJof1Q6P$I5nhSlri7J!Dzg3ETIrkA!8G-iy$a
zd2LTm*WsCOG8ga3+`6a7T-B>&K6yBL3-w1x=9v-JrPZ9dbWe8=avW6Q?mc8z*aUxL
zuA7K_190Q!!6DM#ohj{|^8)z<>a$TF4l5ZmPKM`V6M1iGZ;zAqyh|JN(4X;pF@7BE
zw+D6u_>G1SQICNWvBMwh3jMr#aD%+%UBa4HCA@+Ddh~PXqaUI_ze}cj_hUYuGqg`*
zhdJL6-g39arMD2fCUUGd%S!R?u%>ulvR~S@E@%C!pC7R<cZXr0!(A6UWE<-}Wky{t
zW%k{%Hmo}~vu}`@_A9Z;ZhiJ-^pwXbvze^1&E#FD%pDl}hwI}PJ?}+j+;MmT-*IQU
ztz{-_Ni*G1%s+=?SI#=rGo&XOI>=_$1^T(4!j0(fNB<Ui*-Ty@=UeO}n3Gpu^SKr#
z%O>|r<P6#5Te#UyUV2!~y^Yp6-nZ7J(KPE)Z!zv&>r%cy9M9ao%=uK_<a<UL?>A-4
zfy?ZVVox}`<Vdfhyh&eNV&52>!o4JKGH$#XIZaAPQwiS?%G`Rf@7zJgPYK^=PIMMo
zp66rNO-lT>$S&Nsxr{qOKGyFrvFE+r)=~bWR(<a=E5Yp(d%&N|n&i~jGw%JehWmJC
zaKFkF^4i-wL`JdBaX0I2_eJiNyZ!F$(OD+%c$aeyn;R0Hvlz3#WWM7f&xjrDj*4xt
zd!asa&k3&0xR=ZKnoG@Elek^?yv&-r@LfUdWwAZ9FTG<-`0gY0!{S^S+s@oxoMQYm
z=PuW#>~T3<#_>EH?Y5Isy$VTkFXWtQ2lP*i<vobMKD6ms;_yE0M*8s`?kTyz>&toJ
z_hlaIH%HTVxAz{Gu3mR(=RP9?BY&5Hw4dhQdE_mdbIk9`)3k%<oKkt2^@*pMXFS84
z{!HG%SI~FfZ9gtm*0V9+`AIf$-{(62W-G=0I~*x1ooD%u@ELw`<x{>@JYYY}H;MJ~
zEzi~iUJH4KcKI23`pkL55^o4=o`>_z{BZ7^_=2<8L*#nY<?a`;J*ZvGaw0j>fHu?|
z^E}9bTzDD#JSadt1~;8>+Z}hUS+Bhu+S~7P57bgAqTb7R*X?4|OQn-tkNGS(uSj2{
zhS|}LN^|V5LSBKq6u&L-cMkqqW7Y|?u7sVBSx@u>upeyJ;99WOrR%PXIBUgvE3%8D
z-!S!e5yqp>VXc;XM0p;}ZzIqzb@5rF<E%=TXkW~^$BzD}i+4HoL4Uz|L3^(?@;&;C
z38*JS4tbe@p4D~t@2Fqo+)-!D>92S<Xz!&%KkQ@pqh6hd(bE@sm$H_KTdy4~#BMhI
z)&<g#eFIH>`Z?~MYU=Z?z#k<|DZjyd2WUzjn|cq#R`}USkMkB2V>|pUv^&0~^88BV
zO-R7sDDwXgiFoT`f5pCOf{pvlu`da?sh1U-;bzHbp3fBCd-566vz$BRG<%yg<D2Gb
z&OhWZ`+BKw=W_mgGU_L#zMn?kriqVT7Vm#4$kUvAq`vdB<k-6<1-tsZb9CZ+NL%-C
z`lv?K38T6D62E)#s@y~WbqdeoJ?=!Xx!Y$l`o3}xbGvh#qxqeQE&L|c$Cz)2UU0db
z!m}TjTk-RfOmt6-{oQNM9ma&|@8As7E7aKuu`1*^@-mY6Z*`_}r&lvMg*H6O9?m&1
z)NV())!HaG*aKs)IbU$rVWZsUPnKKN+;wD>`crrICgcB9`!@Q}j&dVz)4d5YP^Dpp
zoamj-v)Z5gq(p|$S1xuRgPG`WNB=r|5})Bb+8f-@bQ0#{WHH|h7Bj{y_O@Z46v&C#
zZRgC-Drx8~k*jGx2eGEm33(XrGoJgR^kv;-pnI##V{V;;9K;xv!+S+5qkc%{*~iIj
z`(D<?Cm8iS|9kG1z}&suxSyx)oc{R#n+&mI_<KlZy94BKz7e!`&txw^jvP*Z-QV33
zdxUQcJ=~o#l{scl^3s#_`5rtoQ+15Ce-z8<5?jT*u{UMfgXf`#mkVX=ujy~(RMu2_
z&>tO58W+>nub?hph#X|u?$+3=tj#}*+)ZDVOc{5eesbvd2N2frrhb~p!IX6e#<>a9
zPfOZBhN}H3{Du<d)XyNdS*!xT1E?SMUyu5k=ysOz&UU^#OprUAFJdpDZtKj5eeRXS
z9`a73EE}=!=6(8{4KN@5YV=>wCf|sC?^MKA(Ed8HzS4>3rjz$GQe?cB8pzABi-|?M
zTH!q@7xS&_9nK9^d1u7R8PDDzKW{TfPNIxkP(R1I&-43XW4OQiC4Rr)*4Q4(x`kaK
zCsRL1P(LkIP5rb`bN4db-x}M5-|o~;3+Hd#3mD_xym#azH=8l<T$%5l$#a*(-lEFb
zJMMJa_;l$5dC&toLT~5`$H2WX6EdMcG>5Km9t;d*1LP#g00&yYA)tOzU<?d_0dRXD
zuR|^dji)_41cyUUP`iep=GTJyOM}sH4_pjtr{<de6CnpChI5;6-l%gz#`pNVk$GM?
zH`IBf&KbF%ta{E!8#MDqbz|m^v`;hd)Oq8zkj^|s=ZvZz!hB%~_j$Oaqbd2;-?ZQk
zF=r0wJ#;>1xwN&<Xk(M%n!xNZ?4LI4C>h+*(#1_juX|i(a?a91{{`xmalf>M4Ep#C
z`lMXO)C|V^47USv1aY?KF0!?Z8^L_iy^T3mI_P|o`Cm9^)cK^&B}wPrxg_@!>U`2;
zJ)n9{*^WC)bUt~rbv)zP$2ynv=30X}6MVJ5#G1o-w=&K!wqfpJ=84WX%&7)rHio(2
zo6HTK<T*TrdK*IDb~S4_SJBsTPl}mSu3-+@o_kww!~I=w1oJNDlkOVS=kXgD%qN+r
zm$}z7RxCk&L6~oG=l0_=4*#vaXQeEhYckL2N8dHT%r%)C>O7NYZIjM58N2#<tlfn3
zOuqN&yXq$I9sKBgQ`J20X0Ca=mBV{Qh0Zg*3hM;=rpq*+lv5e~V-ai2?^2#+ZlWxr
z?B}>;Ce2SfIr0^A!8a+7`K&vi;c}0Uvy6Mpm}`1<Wdq|+0pHEaD5qQaCbQ8^WiEOt
zXDj;34(}Y)%te`-m9XDtk^6+qbr;E_^mljR|7g}e%fkL&`*v>u`<b=>r@z*|U;B86
z{$Klk+|>*Fe!f|pWBPw}6N~|r-B8p23*-Htq`&t4{>$vaWnN?2Z2@=p)#o>wK4vaS
zpU(H16Pz#Q1n*$xft~sO_q|MEy?hFFk?xJA-+zR0Y7@^pZfRRx*i$gic?7k^bI12X
zZw>cYI;h!e;FnXD3338?%VD2$4s~9Sy;6Pr3yl3d|33Cm2mPq_k=}!`hfP09zo&hu
z_LbU?QeS*qjI9j&Q0`~9O+Sj8urGCAi+yVP(Z-x_UBeyi^r7VQ4R2@c&*bxOUIF`*
z>+>D^W7+Ip9;+gshmz03$mjLsGnIUnlFyOMHy4u6W60+t<g*$1%p{+u@mmL9k<UW%
znMpoRBcE%?=h>LwL_VJ)pB>3(Tk_e}y(_lOeLwaI`5Z$z^fz`t(U<Vd@*1GOKYA4u
zK+WGDRdt`hY$$7;cY0H;hRCmB8>|b|Pa!wLHSiRBJ<fqjxD4h%CM*Iqp9QDG$<!Zt
zlaE24E3MCC;R=`t7sDVJO5a%o>)~w3hwh+#`s6^bW|R45mj2%fzW3JupMaas{P%wV
z|DD>-f914t-_T6~oW1(Jdx@&=FId8}@Snvh;tDwu^=JDd@<9#rMm5w2aKFDW{-9Zy
zmjA1g-*sB1{J}Ksw@m)ces3c@MdNz3R@k-m|7v<ZCH(&k^t?vF|6r2Io1*(?_5KR8
zk2aLvFWlYHgYPuGutRcxaUOT{#nq}$MBOc*0h0T`@hjCVW$%72oDIi93E;-)ry);=
zR*=nm!XxlJ>T69HxzVx66jj^Ldl}|Fj}g`3){LWCZRvRkjhlNtWGW1ZR1sbg@0-uU
z`>6F^n#CskRsJ(b(jVy!lUSSEArC}eM?DvKM~zH{3gGwhGz^71XXZzGpk9dkUGS2W
zM)Z6F?)-VkzruAU{6~oY5!TA`BIm)qFbMM*kc^sqn{sT2q-<E9%Zs)FHoY3DX(~j2
z98$|m%U0ve<bI>p<YfT*qtIW4)I5=v=pjhr_M^1dPRRC12hy=49fUoB_nY-m;$$5@
z&ufbt{Q89Dug1O``?wn!ceh3w@+~i$`>M}Je*};oeorDVvJ*KBc(04r#h*udv<!bn
zUjU;~TgW_^MLJ86q@Dd&@ifNUS0QyudaO#)q+`oi)+M$ntOc6;b}-)x?M(hDhX{F#
zx{yY?NrSI-K^~*opy?xysFtsmi?)H0$Y!AKggwD(hg;Tq^89+J$vfsI3~eK(4HFLg
zZA=@C;wJJS>ODx}^In$IIWuw;?|>O@UAZPwjGu{oBTd5o47i3h<0{S<WpQ?8Gj}`c
z{fw{ko7qb_Q`?h!FyG+L(=4;UYVWfVZ>ztp&m^8xNwYpfQ{zONAU}ug*!jq3;5*QK
zP$w$+CTZF>Z8|Ud7|#y)uf~bA<USc7{|o&Ospk#m%x@O@PPIw6pYVDR#xfYox2zK&
zCVA}Z(efMUUt{E0_9m%5J@OOozmZ`H{Us~HZ_@g=bKmp`$%;nE1LrDu*Ue)8ayOoV
zEG<{_d_IZXX8h+xC~uP|!eN~%FM15rfi|FZLY=WE#<*eMRi1w%W@n=BLL6rh=9j2B
zE2Qng+b9=lc>a~>MQ+gN&Dc}-Ccc9M*%Emfd=Hde<P&(?_$iKL8QGLI#XNr!=J@qr
zp?tRh?IYSejy~HF>Vog)d0wHEE2a(dzNP7jXn9eW{#xWAxKU_Bksk=BJu($u#?FOg
z)EkiG)%3TR@ohd=%fMfb9r0jyNPylaeu$R4cM#B*@ZPWXy(1r+_7=LUEeBPHkw}=I
z8$a{4T(q5GSEhZXzZv~jXh=HQ<7fKH_pm2T>ei+2Hud!u@_cBApP!MZNM7Q_xFHWl
zYTL|$x%-YU#Iw(MWAy9~K&HV7raZK4EAX2PW1s;vmOPtyBI_Xy_dmcw)VttI&@>!@
zr2fg<Fxq5ZM4yG)V>x+LKmL>0Erzz}?*%P?jjtK&I@Gg27PD;1R_(sSygq2TX}+jS
z(-$I5Jfo0=Y5G~}mpJo$q(>e5gW*EVMgwOqtKmMWpw1VW{!H(Pn~$3zxF_wVZzFzF
zKQAKJVMe&7ylK0vU*!2^=o=$-OlXOlMX0Gu_D$w#KV{lK_3VF(9pz%i1;)fE>G8j&
ztx$K-c_4BrB=cRfFhU<2;n_7~H-5F9c$vUB;eX6Gk-^-lY;m^y3DB??;GZ;@=T+;8
zc(t#jUpLPbXCLzXO47u6Yjqcyi5s<B4k<vs%vh9;nsV1VGtZ>f<2KkCH`DRR*iB-L
zDj<xyKwYvvZk{n6*R&mbglF=-0sThQ!MXcLC1(r4`-b0i0RKzQCj#F>)0D{VoMTi*
z%4ov?`ttMR(BEf!Ke3*E3vl-teS-F-=O(aMmbJ5D@>&pSBV!{s^6ii`|KB7i|6IzS
zXU5Wd$2t@Df`m1)!dY(a;JAYII8EPcu*WU2+9AKg?RCIBDYhF~!1`>lbB_E-zjhP;
z%A@50V(D1jCZV2`hv46a=P}RqC(`fs=58~kEgTMQpbqC)pWJ&UH0%>uhc0LRxjZr!
zNgqiW?HAU~%4@>9SGhvGxn4slMb-u8dseb{qBSNGoI6#i>Etf(6}0O?k()^iGP(p7
z%OjB%m~(evI0mZp$B@<<5bj3-uSQ>x73@!45q*d;k3Nmx@m=99q<;s>*~s5j(@qHQ
z6D1)@)iz_k6*3+5nb^G?@HP5FQByy13+l;0eaZKr_xD{A$IC{)5XJ{+owS7x0gaGK
zV!++VQQpzqNkJKThsC9z9G3_8j?dZk*;aQT%w2|>`LaGs^dZ%1)hqe?F$?YXCm;PM
z-S01qf7VRnq+k41+G~WPbHv}W|CQZnp6@X{*W2+&KOWJ3EEoMrCY<RySH-*lf81U8
z>p4{|v)bcdH|%So<8)294_azMJ2G{rb2n8V#rp2VYI!E_;g4{)MO`_~KZgG3Sve;0
z7}jukUaP6Y{)7TKlJDQ$gD}D{#q{YD$lGQ}pl$SkG}M=wxkb94h@{WsyQ7|QkZ2Wo
z*S`5=_K?iRt<DSk!VAEdr0)S{9+ZO|h5lY7<;D5&yu{0qdOy&2eD{BfFb06mt?ARv
zxUOL{4&Ww_y%F&_K^yw`KZB3H9pTaE>${2nJbLPdvu%0)=cv_hJ)n;0$MZb;YMz5U
z?>oX`4$K~%V(!l@cHfdhGrwrSv;KgI%hZLw2XMB;goj^E!{?xV>T9gW&vTBIc?k;`
zFQ?1Gggec1+8Vnz{dT6D3Yb%5vHvlPx;Yth*3tC-Zd>O#VOi_<^VcKIiJ$fRgr3p{
zxg)A~>@7297W(1QlZ{$<_smM@M&BFnC;B5Zsh52JsC}W_@_8rE=bbj+{hIqYx586#
zoC`7A8OLvhzY(aPMQ+4T9o&4mFYYmzcOooxdjaw}<lFe^1Gm9^^iLzZvtM<K<R`4;
z8{4XYaY0z;A^BY;b*t`-eUG@*FjUXGU48`AUd{McmCqiPeE%NQq>*nS`ECL7Nzn9W
z1^!4k->>u8OOnq!UOwY_KHop{J@TEHhyGi*68%S*_rPrg+Mw@+{wwlE`2L)Lf!Mu@
z-4p0<L2ky)>!b^F#eX07nwDwk*$b>BJcGOTn2~O8HL{p6dID-MAF1W}B5q%X)37hZ
zEQ)*sbJESXBoiNFRDNVQcD3%Pu;+81LajTLYU-_J?7`j4bC~@5Sm(3<+~&Ldy@WY;
zFP1OKRuT7p%x8~71$Tecx;tWDy>)`W)9M1vAd21J;XPQ#JJLe94z7et-~u=cy9(F{
zYhfiUf%y=>!=k2ak6BG>+M%Y+&-Z(?CkvS8RYM&X91#3DN5ta_C4EQy?ukIwPK*6m
z+&+}ftiXRD-M(>sD0!cbhZo4u{NEvU?B*MP{EiKzwh>K#D4mmow1x8ZKp)83dDHoj
zyOBLEf%KL#zll?>GBl3_c?~7sxfj+Xa(_IYP%>65tO@H-rc6RfU%Id++`}2S4<!Be
z!kR=M59|ZUJKw^Z*tf^aAe7EUq>ns@((j19)>9yz!(^PDE90!MVXlnhd0e;;lpkZ*
zUdGh0NA0}NJ}ttCyvUkE0Pltc-dw)9o(!AflKm9LHK{$9NMKA2%$C&U-GuM_#opbl
zo1DY=^e|yVLR-cS&fl>PQ=E`SpT7}v<}bAWxI7Z|EX>zehZTmYGN)#oE@$@G!<oiD
z%{0F`@w~wAYclpx)>+J%vv}9jF=Zm}`|To|SbuvP9+o5gq5M|U`Pfgu{Z+_*?6Z5B
zv5j+stYKu)uJ+O%`zzpL>{#!K?gsABP3(az!Tc@cq3{GWLH{m(D@X%p9eI~4W<5*8
zERCciyJNn?jG;O=86UB^OXd{jG52702=*WG9(T3*&XmJ9_;t~)%)17f_4<QYn;q=W
zm(__s6OTyi#68@#Jf8GdqECWs%JxF~xZ6p?<HU14a5gjghKX-EekAe*?(US430=%@
zxal10cvGIl&)le(alJU|A-_dN=yz^Jy#)0@WNUbi@*a-fBJAS=x7?*cIJt=%SyvxK
zowhRT9T%{!Q_TEeBs>G70=3>TduE_MH;^OQ<I~w$%>I`V$Sp|T`&7+ZlDR)X^$zz4
z=y`JYa@5=>pnll5)!7*j{I0xnA2JBTZH8LI(evar!eW0<XP0x=PC5G*?q_e?75pyz
z338Op@69_Cp#}TCPGt{eW6a)!7-na3cgW9@Vn0b7eNn&3KG~s|KMOyC&u?|!hAd;Q
zx)b~L_|J&@WgkIjHz7#F7-W6YrTHiV(q{LDZ%}LgNk8LiJk44TpQ5grU+#1;`QiQ^
zziZr2b^i6YJYOJvl!HAHd0br0e*aV_{N4M1wtO~_hni*d9s1uZr~g11MHbO+w?Y|A
z=h@MAyo5IV-`t#MBKiOGU#|@44{{Xd-oC=K6y9&g@7-0aLo>a5FLXBu`w(MKIF$<K
zH-P^3TD3n_JHc<JhG$@S*3Ef~@H~SZoCUChef8m9^>B~3?uXXB(e`odC1y`?xEHs2
z4{NaZGul4(h%=IXc0**PXS1Hi9ULm7=f)*{Nf+&h9PYtzKcfGj@8Nx^i^7^^HfMV>
z7^AY;>(yD$)Nn_68<+Da%$d(%*w8;tQ0&8cPMWrZZ7iRy<n4G4tEZ)~niCXBP{@i4
zURWU(R&vE(3zdvODS)0gIbrmage<^+;wY}W6Tn~H#;}H8HRJI)Xgc7x9(MHztKLSo
zB@s>%<_D+3YCacmI^>WoB8TF)0e%})@$+8TABMYz*f+|6?fmoy_Kk6OIPwVm9!Z!-
zmWwn&-Gum>;;!jVk!GtznvVeNnpf}`6K3*Yz&x4wTSQ@<NXslB{8q?T*rkw;)+s<(
zZQ8+7mM;kBC}iq9k)xAgHp^PX*LEF0vp|?QlXjzE1IKH-!8Vq>7I4)&79Hm>g+itg
zM%pfxUUCDL@o9=UJ2!y&A{j-1S(oWRxS3`AWCQj()OO2&(IVZk>yF#*TR93#JUs?O
z0btf+2~==AED130iFr@*&}+8Hv4wnk86k392~;sfYXGDvD;o$mi*U2%@mUDjN99t$
zZ=cOj$!7o;nm`5&hMgR4t_vy93r4^sm<`xvlb&qylD!tTz>fG&W%OUk=kMt-4~Sy`
zaSYfDmBG*8;dUTybE1$8-5?hzo19W81Hw3-_>L#O<B9M1#jpxCz&4hpa6f1xZ0A#r
zKx0UQ9M}>6`HR7XJ(#cu<90A%4<_uvggtmAtcMEN#m{CWK`LayC@6+GfZHM2FdE3u
zka<9UhLE2j<Y!1_e2e4ICddpJ423WY7C<?ygRQWWX;)oH;aX_i4%@*}QWQvIUN^{v
zA|Q=<#GAJg*0b!=7^?UrLl`3n<0Qg3i7-y;1(oqB+sGzJ!W=mmh=1fPSODcL`HX@s
zKzyT!Zxr#3>ITF&iugv&7C8mKr{Lxk+?by#!A(AH@^O=on^UnrbsJQ1guDT?gKQWL
z(_tPgg*C7lDupej&;;;%+F&SzS+GE43}KI13FL1~1?=J{?~@=EvS1Vx!yH%wt6?K-
z=M$PhV@QJ>z@VT6=EE{r3tL3aAilArVJv>e5ieRPB&~&{t+0yeJYk-R-!qBltW;Pd
zQban7cCl4~uqHNvcCcRL>{6~##_c(cf$%10Lj^y%wu)|cHsI&nGPZr-ZW?Z;m2<T^
zVNTy7a$X5P$I=aUid=yE64EeZlE{U)yKn<+<+vekW|F2^OE{{Jzl-pHG43u&0o;@l
z?xlorX{E?zr1!EN{2a|3k=cYX8$VYJ2F$LU1-saOOZw;3g$y8^ITa#T<NxYhC<4Np
zTPSi3{^sFs-cFHgNyl{x>gzGPp17~?1tVY*%!b9V25@(M6-yvZpcjmWS+JN--ARxJ
z#C1b4%!g&LR^-M7Y`Ito>wz@gL|PXlK`LZH0hB@+;BEo#ZbrSZh|dwka|>y?g|w6r
zR~de9#qX{7y)_4Lb1Qyt#r>`Ly>&fQ0PYsyZV~PlWx*&YhB>eVR>MZv&h{~Z#*hX%
zPyi(`AC|#d*aADuGO8?2Ms|Z-C=&S-W%j3yKv=gE*6rmYci?{s=1bOy+==@;DaSi0
zr#n}{2H3{W{J4OdyRxAW$lqO*)m^x`Yco`e+>M*NF<;sX)`{HH1c>Ke;=8Yut7l2a
zGSYTG@hwjgd7v?@6e-UF+^;ATd2lpPeh(4GLt8~w;`ZSNu!ikI*gZ-<9^J)uM$+|X
z;(rYNW2he=48*m%0IEcum?QFJ8Y~rgig=!?5Lq)z<Z0B;2;lcw<g;r<){X$ee6F0&
zcD-PW$Y17*tQ!Sep_1$R3t%TdS2P<oi@a1OvL5xz(?wpv?v*N$SC??{Mq?oE*GSK6
z6(X;%6nUc?tQFZ<1Up#vCLM1gHx-KfwH*-dX2N_6KW}Xld3!YM5_x9?tP$Cg3+qMR
z#r?Y*`2<iR@_rI5V;c}*Zzb#xa)59?BuyVR2J9+QV5!K**|3GrYp6e+$4?z&zm4!d
z!(5l?KgaxUsJ9F368U1A$d_CBS*J3lq9r0<&lmZIw0yHpm)wE$|2+jN`BaMfALQX5
zi$!)e0K)%187f46K>Z`?A4kC&Abq=VyQ>fu0O9>aI6uvXm9UljLtID${QO)Bg!}Vq
z*aG<fg?#@)7{BB|5s<cD$^pMsbpgLsBLKfu_^l!xyYaJoG@##&eh=>U5dNNdA~E8R
zO&3cVz#4AC$c93g1Ld$0c8FysK{pr;vpFfpRMkm=!B7kfpaQBmO@_If3z)gvI0fti
zW?nWF0%3d0V6(8G3~4Y57Q<@5JVJczuCXHXV5?ZsR49QZum-k?#cG$8fPKPxu@VU<
zk@O|bg0)a7R-Gn57|emKI<sM;San?>th%JTF5%TByt>=PI*70iDu8m>C00H3^(Fyv
z)!QN#TlcN{_^Ce~76WEU4PX>tmNXw$i*+z&2loQvJQ#NeZx;PYHS3UWKzN6&gl%FS
z+61zJI1eoa{2p2*R)ZoagEfHuuoS@EVVE@}?1s2)h<T$X0oXMvfsJA{b|DpVVIHi7
zO0f>d{_tI59gz&9fv}EP1^79VaE=@W3&d)IeG~jOso<xUy1`Phnh|HS`C>J%3me2r
z#yoiz;HJeKv0CD%CH`A(6{{6-w<?4sVx^SAde|XW>msq*2$YF+6lpvP|3{UJmD(86
zpa3vS#XgmErIN1HO0kZPLNegy=q$jlE&kh*rnV`N0mRXE3v3tb7{WQG7)p7SBE9XJ
zz*-=@_Pt=RSRDj5z*c_xcAZ#hxKEn{OJFtNHjS|OQE00Z>FZQ3RyzLDvFltU7RP6-
z49vO^e;538*&$ZuXjsGciZoatRyW*rTQ633($^igJ+fh$SUvIEvsA2Jbz!zx$0osi
z!0y<!Kt7HoyxvjRDb{g>m6Zdd#Ol)k+QBNZ`eN3P^z|eD>{K9a{WAbLfH($}K!sQX
zi6e)&a;o?Vy$xaw8Vu{jI-yvs!Gt%MI8VfENS0Vb+W~gD<RzCh48w0;T_AnKqfh|&
z8@@}d5v5|Clmg{!5$Oh-#X1>(Cs&F!YPwjbBm-fcQUSQnUkh8rI<*Xz!D`qD*pEhi
z8unvK0sAp4#X6lh3vyr-5M}}CKZCT4B^_fMi!}~6g~foM@r%VebE#No5&v0}U>3{+
z%+D%^HLyXfBHS0@zKF0V<cc+sa3)rXHAw)s=fLDN*df*w+!qsO@hY*-Ef8xeZl;p2
zX+=;X)_J7kymexokDCkDidBMo2Id#0h&8h=Gy&{p;(sP~vj}%qmRJ{MKsHp0b@4K>
zF2PSJ;a*C3ml4Nh^ZB_!+|6zPTY$7&f!!6G0Y6ug#w*KV4PbWVHnFZ+E!G_Lb2b3_
zIaOj^y-}>WggY1YHN-KGFz2DZuCZ9xla}juiZ!2bZm1B8?X}i|y0A;Eg_Fd(Wvy7Z
zidc)<iFI2FKLgSPF#FSBSSQx)-5?i=#JXd)SWDo}La~?^S$D(I9I@^p%zM^|buVeS
zk2vpJD%P?FfWKu6V6#~F6Yg@tEuSUU3hW=;Al5_peF%RmN5f9B9wv^5w~F;hAykU>
zXt`Lc3dDNM73=Xbu~yF$>k0fniF}H1*Q^xl>2+c~gP&)2h{c@7dJdi^tiK?c%UCZE
z=Zm;|sYI;x8GzZ##Q(}@z}>5}fv`5D!WOY!D;4W??A}O$ZDMUK6YEX<ZW<xhU-7@$
zh0S8UwOFjTN!vT*{T=*mnJ?D6sNW;}t;@vvV2M~C&JpXQ!D3a^g<bqS_ja*9!SAP}
zX&d&R5$@;RfVBTjV7*w|vD;2~+cEnBvoDf>bbPr0mclC70BTkx)>jRn9b^Mxe}(y1
zm{($6iFqaFm7`%g%!UO}4(oulR_+w*>$;Evy<h}P0^EMR7*>h(O%`kf(*G@K`WCYt
z1!Dc3wEw+|?MR!&`p0~+b|yobSl<)g_iM%aVX0U@&Jt@^u2?@2K64%GXY%&THnFM*
zYj>Ggd$IsEa}ry+!49#RhuC(J*iMPq?j*6jT(SKeu_L3zj*fsrz<qQ!ED$?krPzt<
z#b&&>>#h^~penKJr@&URlS;)txIpYfl3<tEhi(`9ux(;D+9Kws)Q?CL`$z%&9*KRE
z3|K67Q_PwYN7G8Nn-O=jd4QkhsGAdJa$Q&o#M=TtE#`~eas<qRH9*|08UXr~ELbLX
z>nI@GltGo)N0k8KGX~m6=ZMW%XSXFC$7GA$u8G*~(YIeCb_e`-SSxnNLLiN43&ie(
zT_?g$$6xwRu{$pjJ0l4QGh>I?T}HqLu`>sY-L(O%6T2JncSGNeIJ%RD9tD7#p1AFa
z>{TlEv6Enn*uCdKh1kaxiJgW2EW&3@vir;yyKh|}ef>y7ztw=>ez@(oQ|xTw$i^-^
z4c5a}AU*wY+rKfigDfD<{)FA1JoKLrOM$TZ6IOr1>Q7h$2x|a-2CNZ#AmQZ@Mh@;7
z-|XXyVVl^4CIN0w*eLekY}h6CiJQe9g82~K4yhD-XetobQ2gZ*Z|*v=hh>PJ*8p%c
zye=#in`yK?Vu{!%HGw&R`;keI0^MLR6u<@`jU#u8eez1NM-j#;qr}cn6Z_N>u}2q*
zecEWT#}LOD(sTM|u?ui>Mq{zZ631Blj>ApiB(cZ4FkS33vjMk^V|G!F*b{I!VU^eu
zNypiw{p?Dy&xr#0oV--*DTH5~1v|w)cY)YbiFX=dO+!C@nb_wQi+w)voxe@&3rJ&0
zq1ZF<KZ7tY#P3Yp&Riq*|6%R^<0_l?INrbQy=L$Ad+kODA%qY@=+GgA5JHF(LI@#*
z5JCtcgb+e#XhuUbLQL4$W}2~$5JE;q#zu%~2>0ba?mzdhd++0M|9C#WYkj|;Uu!$3
z-QF|KY0L#ZuV%e^SfOjmF{;qD#9T{m6Lqd5_B!^j8&c@{QZT~}ndnfc*~O$nHzpLi
ziJY70e{&VMZ)sKN7V>W4`qmPRD0Ca^ZREES)5`ws*<ijq3NWb9ow;ZMz1xUwYeF}O
zZJSi+F8bY-5AyFK{;nB??&kh(df!c*yP5r-Jaj6=`&_7<{d<}JUSjX#`aWvh&rJ7E
zDbzvD2g<<SgVf-=htNZ;4^gKx1LQo+Tn`T@^hg%!!Ca44DAZ+w`!4PuBkyr~@clsO
z@mYnQs8gsr9n^oa1Y-(4B^06oJxD6_bPT1S{?o+tWFQaZ^i+Y^o;DEQGlWshC^V0_
zdBn{lZXR)bzYv;7+&tpu5jT&xc~c5KV<HE{JyU}gbYTEVOe*xOi5wK60(BtnS>m20
z?pflVC9YS<Kpsj^g$A^t2MG{2pSbzN%_nX?ar23rPuzUs<`XxcxcS5_AZ`J13y51l
z+ydej5VwH11;i~F!YHN`dd@@^3Q&d`G@%0nAnv&t{um_#1*kv+I?#s%#xbMN!WeQ;
z1mYGFw~)An#4RLlA#n?dd!D%GiF>{THE2N(5|~uz1t9}@C_xpd^+FqndtnHpm{O?U
zL>3BA0pj{QFn}bew}^U+GC;jW)LTToMZ_(l-XiKPqTZrWP;W8y7E^C=0m@K=CUl?=
z35;V#p%-JwK@loYhZb~UK%s$3g<did#|Tmiz07}>U(Q56%2AJY^kW3m3cZq!e3YXe
z?dZn{rWG1YM?T6?k9PE982oo;a8{vL(~*l}RHGT)h+{&b*9>H%7}aP-C#drpbzYkQ
zb(T<P33Zkbw}iMQ#4YJY91{u+8OTO4s?iMU3{hu@Iztnn&g;~9ojR`*_j)Dj(TZ*i
zVgxDv^+N-h$VVxv(TH~RB91XkEA*y|Y!sp#wP;o-&iYm^x)pjm14)J6p~gGZc&8WC
zc!wJAP$S`j8VPD7sF5Hy!9T+U{|poSGfa@1NGbF#{~X`VLIKK9gC=yKAH=;&+*0C}
zQg3MyDo_XNEv4R4>MbR1>7+u-giKIx8GV-#x2zRCV7_JJm{Djrh8$3Dn0mv+4O4HJ
zdc%Vl1<$dZxaGMhK{cAtfj%Taz2($fLEH-BRuH#>xD~{$=)?e$m{jOJAp?0J?!78B
zpdHkEZy3ZSiAxffBrZu@lDH&s$u{(W=SYrYR-yNadp{p#s6`99Fn}bew~~4*iCam%
zmDF2Fy_M8kNxhZSTRDVL%qa8$aUT?*0uAWE07fyR&`1UfQHe%$g8Y#Qg+4Tpjbc=z
z8Qq9uLZOdL@EU!@tRK~*1A`b>=wk!fC`L7!(TzAJ6dE;<gHqIi*KBkEW8!~Y4%sL~
zIjH?fD|$ixC**%JtI((Ep#P`Es01}W?Z%`+pJjo0KBMMmNlYm;#=K+n93y_L3XLFU
ztWTlO4OCzdBS<Oq1$$p)A|Iuw2034l^F_ZxUsCT&_P$JjXZ~_Vq45~#F<u1fjn|<C
zT^Inh$C>3T7xf@-71yhBQ4H#>qQ|OE5WkA}Rm6Wy%-7i{N5}uAkM&>l|No4d6B%I6
zi5j$leiJhaeN%u|FxzT+u5M81Tl#;?GfeV&O!h1EU6n#>n4iysp*2HDDfB&g-*eAr
z!2d@n`u|u8UYj4M75a((KMgB1MU5%)r)CuTnI1p0_Y3uZtyXB-1oKRnqZ$1Q{YL(8
z^!#m1q2IGW+*<Nx@)TMp6oJ=s9kJ`^`3KMX2lfA?&Mft2n=q=-Uj}9s`ny)4f0*H)
zgu-e-T;cV~6%J*gRpD^P{|~4ePAO~%>BvDL%1{l?4SE?}=m)dRslbrJ5&H8t2*c4l
zbSP|+XO1Xr<zrM~yB>p>P}s=^_YQduF>VPeQ3uZ58HK%GaPD`aPvM{l<zPS7qHtQ3
z!gJ{{mwDHx#s<Qe!W*%d(Wvmo{R(fAiAjYwrEVrR%R-aFo5wJ&@D>9KXVogaB{^FX
zw^f_MTlaw(vgwgc?QJ_1-p)Xe!Z}3>Z%^*_rQm#fVz=knb|?n@b|h{`X55k3Tw-%M
z+ljNCk_zukkDVL9-Y&%K!d_mt!n;<1I=fCPyju<`k-&_?yO*E`6AI^Np$<a|??KHy
zD-_;~*$S!^=DXGK-WixycpvH)wkiByV)l(8sc=yNW)$9^^8=`NV5`E#)H<k4;e(mw
zV4m}k5rz5u7(TQ?;lrqTc&);v%zOlWkE~bts3wKWSdZrXm|lgCCFi(Og^wry1Q&e@
zS8#q}CgKX8)QT~M`HnMOS*7sF?444H5rt1Br-~k@^(%aOk-}$?TTQPsV<7J=6P%wl
zrSRDU3ZFxtb8()5E`@7}IiLIUM-{%n1vM^cSNOtah3i@rzNkRqi*pseqy+S<k1Kpx
zp2C+`U_#-BafPp-_mv5SubNi)YWiJ64L;X}n>rM}Zbso7vJ`G6=SF(n)T3|<F}Kty
zd~2J+x22;+;Z|~P#~sXY2fgnsRk)2Fcl9cKH$CrRubq1LPASayiQ)TZ6~4bo;f{QC
zEBrvC!VeBA{7@_C$#;w4hlzcZye|4YR;cjfB?>=5Ot%a6pJaWKnV%y6=}Lur>J^@6
zpi$vxID3Y9o~3?oT;cg63NI*E__<7UD%_WiUWFHO{=6`u@C!9aDcoO&X@wVcE4;W$
z;TN+ouJAy=!Y`5ga;?Izlqoz&kHLh(uTu9_W`2!1mr!pg4@rezuTz-c{laf>7B>}s
zD+4_Wzs(G96Z?*V2GBE6ukgFndzbU2B?>QVRCt)&Va}EpgZSl>3a?;qMKh@X9(CTM
zM-uOozY_c&5&mFS;gKPQ`CTCV5j{WZR`_H3jIw^h`e_XP3V&9L35Ca~_4%;EUo<KF
zWiEKu@m7Vu;`%H0SF!&!eJ2czDEv*Q!mDc){x(nHNrC(C3XxKHO^3qY7h_uC6t#aC
zQus%n>8ECer@9pWnP=d=BK#}))9DKH9blOEh4Am=3a_0~c&1h1b@ck<U)1<>P~ln5
z|EdA!e{=m0XaDreP&N8wtXGO@8KFWnV^T)AO9nr?4SrS|bF$EcUKx=bbjygQgLr;E
z8>WdOG{~^nx2n(v>e$0F9CBUqT<*OraPB2!`1z>B0A^$a^%#;7b3sh3Uq)JqjJaH|
zKPw|WDPu$KGm2zvj7_-S^k3v>=74;@Pc$}TZ!?~2^9mXK`I@msBT_Q5IL{iDu_fnQ
zvTnt*Z8arhYhts@Wo(ltW7~90%Gi$h9Ab7Le+SNYEXKHu+%ojb*r@=6GInN;orh%X
z!n(_VjJ!f{zbosm-0xO_Q5pHAGWH;54{GmOi-e55YA`0Ffc*kq)Bj|Hb#HR^q3=HJ
zG77Um4u6(q>`Tpkhh^;7B%>%F6EgNE=73fi2R6$nCa0MDgBoQVOznfmWgNo1e4l5O
z^vgK3O~zqWG7cy1aOxdCE2Fd=Q!<X=>`0+b#!<OQ$tY`)adbAA|Cl}*#}<Lw#}3FS
zr$#xo$~(dNan%@;aeO_<J)uEH1-U1tgWe|<q6?h;uN9LrDzi`ldRHc7oGg^01H_%e
z*(rlEPR+%Dj4ICfGb`h?Mj59QdwL1TJ$*{X89c`s)Zk~oQBD4tF4#Mhyt6XVgi#r1
zXP^o_GHOiJfcP46&*61CXGF%i)Ht_S#(Bh^SBoJTwe+qf=6uf1ACqxGql^nVzmR9E
z%fX<Gi&!semvM2Wj7xa-OX4!>YcMS1(mYJaxQz45>t!@huOTJlidGp{#=!nnbut>+
zzq&%kHUFBFaczT)CTcZ}$hfWueKM}kLYs^m3~+t}am}@0y|D_+cT+hMGHxzJuZ)%)
zbRi|<mSzxhYdRV+F5|Xp8LdJGhA}JS_B>GUc4oUhj%gWpWP{mwk23B^%D6KV)ZlwW
zqpc3)-i5oVb#JbW`+6`Y<9-)~s0H^OrQqxV1Kr|ZGDlp-L)3U=5VJBKEt1j2dDpm%
z$C!)vFXQn}49j?e=X;_R{TP+eO@24$-OV8WN%}lFDdVYX%*c4UMMh6P+K`elkJx!#
zGM*vtnJO92#z5a*`p?e<F$)UOE#o=zp6iv-$J#d`V<EFF<ox+E(CdW?u=cmgSVYbu
zdM)Cd?~9DZBQjpB1Tzc}_fih1`EnL|WW2)OE0Z$#-o|*<M2n2qsPS4t#*$ocHq<ZU
zb$Y)(B;yTgy_pH>#_1OylkrwLxPQAt#ychGmysyNw2XI~WGt;hpNwUB;C`6bWO=iU
z6`b=~-AI!AK0Q~u7?ANnO2!E1ALh#7{m=NAmG?j6;~5#FH5irgNjZ`-J|+LtRwOVf
z<Fg4FpT{sD;|pTHh=ctvi_n1~8RHosf4l+xn3C}odta5I9mKDq=PF`Wk+X{Puk%m=
z=Kq>!o+to)C+PPLx!;ta3o|lSXMy|G)gXR#Ck8;BZ*$NqW3mV%GQOkEcigWbXHA!k
z@9FdX5U7*lIz^3Chm0Rg3}RBok1??SV^YRXyly{@%9yIhw2Ys#Q3Y!Lk`HSBDiA+S
zjcN9$CuIDVg*q9(6aRZDm~kz2*HUAKoS9)T!#d8_m7xVgn3XZ>%J_@xf0{H$ofyCf
zrZi_g7X>IstLB7?kkp*8fl|#evNgvo(VPvkG-tC(&DpkIb9SE5oV~_1r>I$TN?4CB
z)ExetWzK1}nsZK{=3K<ymDIexUHqRTXwE&kn)6VV<~%W^IlbifPiW4o#JpXsIV%P<
z=i?mB`La@TzGZ)^NONZRe;ZJfB4)25u>nOg5{hI^D3X&>B(GJGf?7q2Vu~CxtVl^F
zD$#>!MGmb7*Zdh&<ghGMpbdkH9A2hKsf!Usj%ZZm$b3bPGSIFFpD!Xu7b|j%iGD?n
zrB6A1j>}c#cwtJB6FL>CAoj!-MNVqKv?BlGzOo3zikwXRDcR^y<kTufsxlB)<g{`{
zPEW^}B4;!!Qce7soSn&>XSFJFcC{ikg<z(d2}RDSK(8X_@{H$ler`gM^QduNQjywX
zbSrXxE`}7jAP@bDT*&!_eTvjoVn&gR+7!9C04YT-X;P#<AESy~O0UbZK>f>e5Lblv
zmPi9Nt|0e{2}Q0X{wmI{qF*DkTy3I5k!#4ihThjQ>$O9QG?jsv>lzffz5tVo+|aH_
zGqW{wek1!g#n7V&?<<j;#}#R*QRJ3PaDHp6BDay(>Vo^*I~BQu+&dDA+(}#;Gq;T@
za#x)qcbj1U9_qIjD{?P&@8$kJ&hF>_{*)pe&5Argp9jVid9X^6hq6H3&U!^2rq;vL
ziagSx$fKNfQLn2<k;h6ftH|T*KS7-*$mKnOe{m6<KUINAMR-4m^pt{n^I8>ohU;fd
zMS2ZI=4UIipiGhHDi!H#RAgblBG30K^1_rNi#S_M>|*j3Q|CqIez5?|@L~^$8OTE&
z;)=YKfok+&RFRjN<K-Nbp#fb;U`ml!h<&99HE6>C#uXVfk%ua<KS<rd8AV>D&a2G$
zDtoUEA*IM`)Of7~%>7yqMip7&q5#aXq#fihnNnmZ6Fkchu|vcTjVSWEfqc;G^;Qgm
zx^GbT4PxJD0<Xs#lZx;@6nV1@%@_c2@hp_11?0x*^Hw%0z?^R-FssPhd8kGQl8U@z
zq6AH#);q)`3Q!O36V!e;3zcXGIZHD^ucg#oI;zOB7^ty~^JT+|4D&3*%skBf@R%aY
z3sHw|5Wm7jF34HYf<CbSo{)nwG@uI!%qqh7+mR%5C#jhn0CnFd{{3uF=lxo=p&v<1
zE3z^J^j=woX7pefQ;K{XQ{;<YMOM*gRVRipp~%-JnC<H_aP~E4Uvu^~XA>^+Pzuf_
zn1T1e$TzhZRAhCRBHwcUE%Dz?DYAz6H3cX~6R5R@=UFqU$oJ%ZpN}duq8sFWpHd{n
z47>+MQuImDC)EzlQuO=5Ko&Urp$2W}#VBSJ`7sxDm{sH_YWzgcsVPN%rpGVb|5A&%
zBEM4OS8D&7RAjmUt?0+NBD_aNek1QU@_sKy9k~CU*?*r_WG!>AC3h`zt)=%`_Sa4*
z!uO()nM$;PS~FvctV>4~*jv}9$RC;D{*Nw<EAnR+s6Cqj>irc1^ZZ53U*!BnoxhTp
zRpf7C{w`8frHY0c6b;uXYIQ1Vw<D>jlZPgZE9%xN>g8ZUQNIi+MboMkP3JtlSJ4fq
zvjJxtwko=DuA-aFD!OR_DizJ-Y%_8;n^JW1Hbt|t72R?`(XGoB&1Nqr1Ju}_+#RMB
z-KAU6ymZtnx@!s8-<28o3>w|NUC}+Lx2FMS-HW<=wIHcz0XYRcLjko4=>MNmaJ{by
z^7k85w5VFq{mI>*{s+`5dLY*alFw((Xfd-DPb+#5H4f(fU~&&(J%qKS7GsJY+NCI;
zJ)?(bqFK>WW-qN%^oU|G!;vM59!+fdh@!`l$9r@1<dmYPfbaIA)s>*fSv*56apwz-
zit>ILy@37~rej7?-Y=td?TTL1t?0$0ieAG0CCqsVx%K4L4=Z|U3_XfoR;}pe#9e_a
z%f!E6h!I5_n-smeSkY^k@tS@`uPsoN_r~aT9g5ySZgUO>6umJQLyF$ipy<t|infq*
zO9dtry|oQfir!X-RuF&NxT38YC_}rVx4Yo_j%G#gq*fc(ca<x84|CkprD!|uC6CWf
z(Ff@H5Is7p(G7Y$Os|Kj^GL0t{9TD?R~~v5eT-U<jVk&$@sAHF`a~wE`vmp6+3TKB
z^hxrb98vVCK1H8)Q43;w3PJsOx#+~SqR(*s41J&JRrJ}EqVwrBe^Sxs`W1b?O3@dn
zx42Hx7t0lWxn0pE%*y*nG+v4p(Bmzx-=ZGh+eP0Yj?XC3cS{sqDzG<9?P2OHA5?S&
z`~2Bsl%K!R_mYYx^U<j2`zGl3J~1n6Fs$eY?0wLu=m_^C<nx_f^dlD?it@8HI!fQs
zxT2ph4}ZoM<<HZipYoiaQSY-^MaS?(4n`FHvKZ7HuU7P{grcj+{hIi%={b=Fa=u}v
z)zn|zujsd(icU5t`dz)EYuHa^D*6L8ekA^<5=Ey9F`(!#%r?#5@6524+B4;fuA}E4
z)cIpp(Ld=mOYCe)(ZBLgr|93r{5`GcKh*xG2a__Diz*DtT(3}OC>{MW!;LZx%*mG-
zsROamcA1t?gQQHGTstAtDVOPHpjD>FxmSU>OrKnSHkm;eCS=C?WTu&Dk~z0n=K3Wv
z(>rBuK;DKUGB+BNxpA9Jeny#_<;mQfvn?8AX3=ZQ9+_JcpUq6$kiYGu%p4P?7?inv
z4Ak77`0a_^o?1Ip$=tCFLo#zSL0)bL`a#W|a=_kBvod$C$FR&@sId$8d5to6rT(tf
zAa-}j%uh!px-lwq4;T4hZ;xj5Vg%&xN$ow$K^))7nR~Hc&?fUgT>mE}bMJnc`*6Jv
z*M);J|64C}-#l==U!BaNLXf+EtIPwcFe&puVv9LHs2$TX4<_f34A8qIhJKlcni!LL
z7|(ThF33Hc_`~}^jnZ@!p%y&H5kd|sFf8*(VvmetTINyNC`Jo7JBq!s0#LgwA@gWz
z9ZmhCsdF^7kI6?bW@H{)DzlvPa&pTjWFA+EB>!W+^gg~{<_Vmiz<x!C%oEEoAoHX~
z(C2?;Ag?kD#GaguPMN2eVE<IsQ^`5C72`7b3}sd|U_|C=?4LFy^K^1fuSY`W8O30)
zn!45GS95)433_Fo<%09G=zUg7=GjGHt)bsJrC`2uCS{(RgBtXL^Yf}fKR#=jwY;|H
zbAEo8%nK@IUdTKb#%0#k$-IaeE*7YN31^o~%dBsec`5T=W}sc><pmg%*)Z^bq2CqM
zxPl&6v|(K4m3ipIu*|D6QHxQTjr48okjdvS^J;2cP2X$MLGCppGOx`B`%MP^T_<E-
zSB|*M>sha7y@B-x_M189Gnsi~3{^<Vyop{nG4D;YGH+(RnVu~r7?61j>n;5<Z!N}%
z%-fp5+RA+^`?s^+&Uy#y9qix9`JK};+gR^PM_lIJ<udOv&@Z!{{q{bY_wst(TZTcI
z_wii!HDFTa{q-QHBOl!|AIL+O%m-N?WbTJ}O&%hrGZ&pQA7*`+^%2%b*ngDsN5^D#
zv3AYMe5_aI<Aq4ce4<lkH~Za#GM~%^_fN4t#cTU?4tU<48jQ-E$2xCD<}*DqpJkS3
zCuH`v%bZ`05t$2E7fj21jv4zn=leZ#A?MGt|2+FIu-{)Ub5S-%WG?3Z#d?_ooDZ~N
zT;@wW(@Q+tOH(pmu0m4gE3B{d$sEi=o6J{P`J86H#`+rjOE_P`I>h}D`>(UU&iV%H
z8|=Ty`I||Zan|^h%(uE^@|nqedtBx_Z88(=CwgVRn~7GLd=@g7vMys?#{O_65;B)p
zU{dCa4w-zWG2i1gNw&y*pZ)haU&*?X^A9*5;e3Si4>|vc{g2rHnElZbnV)1JA@fu2
zKdX^B#`zep#pmg0miYzi7pz~he#!oLIpQ+EV*P4D=Bjp?{M`=o>k*j~%`(4X{~OL%
zv##d+Th1pr=Q}y`JI>dzzlQzq*-sVA{2?82nLl#>Q?<+~&ZmZC{#*uLlV5mE_$*=m
znv^-+B=a}+e;bqeJFm&wLYXrz24$|}{tsT8KTE;+EcbtL{x|1;bN)}OELF-{uN1Sg
zLc_Acow5w}=dd4PKUyfuWVOm=*^RQCB3Z5>%gdDIr(-}?Ky1v#psX~m(`IGOZI`uv
z4#s4qQ*VP&S-h888#Tzv$i$4Sjj?G=R%VH;&AMf6PQA^WWo=O`E6W5mw#-1ktgXsq
zZB5?Rld`fqWNkyvHso*HBWt@pSvdo;wjYwULqgV$g<vn2y`9+Gxk=V8?B!8+SDs}z
zdhRwTYxind`OKY9+#cmf$=Z|td(nsYMXR7o)_>^3`=YgXr>uR*Ev%6B-x^u_Hptqq
zNLCT~MYFOFNSAeBA(*u|7vvs9pM$8!d!ltPIR}r*I)t1<x@DD+S5l8LS%<QBXpgMJ
zh(D|r!?Jjfv<`2@q^!~saDIe|4p~QXcI2R}qe?-|GM=MsO4iYhn2>c0`+N^*9h-?>
zS>@C(C+|4+k530VCvacE94D4xR@O;e|F2wDWd;(mPA2E%0a>Tyq6@^F%Jr%2RTW}L
z)@k{m{^>#mIxr&Zj4afm56o3fTy;H0Wt~}ol&rI;dG>&;8sg6({v6`ZO$X0;UNPEb
z)w0ifm{m)S^E+i-P>NOz%epWdjiAPb)3WN=yNGAt{mi<gOjdo4tV;!YUPg_}*=uk?
ztt;qxC3#oT=PK653M6G+U4sc(*KmC;{hI1zU6%=Fy1opvvToqIxe!fA$hxsb)=dU#
zF(vEfN({+rp=Jy7+>!%gZb`|ywFK<l%DlIgqhD4l&)7<z+o^GThpapLWZjvN)keL$
z8fD#0ox91sCmY<~!x`^K*1fH=?yCp)_vfJj^zEQ-2m24?BQEQ~V)V;;s0ahHI!i&^
z!_<11{YMN`f!>cKWj$I5YIYIdMf_uxAntMQAD@)<1bf{D7?Jg4I?6FF>nWb$Db}ZZ
zW%cyPdS+PGvrV#k%Vf=WF(qpO=g-lnuUghZ`aGY3F<E@3vidn+M4!bivR=#wu>;IH
z&@Stx5{$@tISbT(B?k5fg=Sf==7Rm#sP|eG60(-$VNli(&p*^J>vd|pPK`IXf0MH}
zCuGH`@m7tjx5;@Y2h>PVJHd<zY9wZ5z1t^iDd$VcT}JLQY7J+DbvgIT$7QW(l=WUd
zQnHc_vfej9UEXu7mGoLky$_ne`A7xG`H=GuXJmcUieXtFyP)PM>nLZV#C$^RC!?}H
zEyRGV&oa>|Ym9ZQ4sltZ=b&5G7qzm!tirUcaqhorleMZGld^apvL>j*`;hfbQr7Bv
zS>G0*SJotZ-(_G%)|zHn-^Va4E5&t+y&tIiqtGGir#!@EO;un@*3YA|ei@SWD>Z(l
z&u<yBelL-=)&To_CuOZGll4b7W@P=@FKf0=)?cNv{>}l<@=pvsvQ>yd*?iWs*Bg@^
zYLp$$1=mKm>^ZfVmK|X~nuWM*vkZN*tr$9G+u7jU9+mBsVo0`I0`9#k**<yxi0q(A
zc8u#Z1Js{8C42oD*&CG0-jH4!Q6r-QN!c5dzcKln)X3hHoK1<(WR}cX*_$=X-rPm6
z>@Db*RUmsyX4rB<_Eyx{YFsw&S@za-NXX9SJiABsHpSp<Tl#F5fdSb$4WRb+l^B-2
zLlY)t??}%bE6^r8m$O`AcQR3ie%U+6Pz|nk$pF{8FwZX2vh#}2jw#u^@7cQ!%HAyp
zqq29;M_hJ(9*Et8vpuQ5=d5hLE3@~SkX=v$@(Y;tKSQ$j?vlMvlk7rz{Fj)0O|b6A
zx?hLvq8u>a{w1;x$OL^4B=$i171O_%8pSEu2W6lbwdlk!=zDOkY(6vEhtTH`_70hp
z&F4qEqyY7xcFBb7LtW70&>E0`=pg9D`=@<a9;(nS`*8XkUWuga(q7p|5O-uk_EDUb
zk#}^z>|;7)A4|>hG1<pa|9G50{E759sap2`N@Z7aT^W~sGOxucJ+k?XXY<+4u43;r
z<~p5O&Zv-Gog@3qLfK~-7?ypuiF_~*?{)UsQ?hG{QG;&T=fp56`&?!@kJ$5g?poH`
zI&fY)D*JqTpI?Mp(Et2FOvt`~{uh*?0mSm2XkRcR`@&+hg50_+G+|u!MZ{lJ3hpl&
z0JB`2gDP|&CHs;hw1N8dT-P&K{kZH)vr&T{aCTW1DnZ_5ld>-_KnuoXH{_uSN!eGB
zcLi}*F!vS2T}j-PtXI{5y{qDwmfc8PV==1HjBbp`zFNpd1*m^@KPF`JInus{y4Q4p
zde;(jZ5=qjc2;&%F@|OHdD6aaT=w<!yM9Xc4GrMDnI6sD-^e^ScF4Yo^(N-MiPzv}
z7kQ{c8+wrdeOs8PB^MQ-cMI{i5O>R{>|0rHrN(WX-PVp_*{uc&LC@Q%bw{P_J55ll
zEiU^m`re(7Y1#LT%WkLFy%}hceV+^J-Cu?g*&XCQkOyKPY(=N+hsb|uP<AJ0os+U3
zZUlWE?#6)ZN0{+Z>OabLS0Sjw`?>uXy&tF6<J><{FS}cy=aX6Jm;Ds6PYua_n)*-o
z$?jplhq^sH(>&&yNBw7t!TKz@&$9NGfIjo7JAYjE0%lw=CHuK@BxLs$f%Ap==)kP(
z=j*`S{GAf}1!DT!WiKLrF*O%=$$qg~_COX=vR|UdOEa=xrq9dNc_jzr4A!F;6S7~;
zMvd&(46wJPS@sb3ucu>B_M5KkIL{X6`YqPCIDczY_S^J*rvT(6=$9Cg{cZy|Tbd7^
zeQ8SevTBUU9?nH0W@RsDUC!AG`m9LGelHK?C7Wcw9|O;^vIG;dKj@Ur`@j7m`yXY1
z{Lv!WpK$*v_n(f*{;Ws#SS7|~e_n+~u=hDNzo?V_rNBAw^Y%FNk5l(6X8dXxv$9vU
z%Kq9!jqC|(enb6lsI|IVHt+fNx5Q0$U`qCPwIF8=>zbtO?;B*Nm?bqNoA-VD$2<(m
z{)zpcW@JxQ%l?`3pUMA)p1&}|ucNZ3nd7$-*}s$XdmBbT-L+X@j<vmDZzdDu&XBjR
z98Kr~{r>1j5}f^+fl9DH>!Jdj{bis>_CMWn<l^5ojtM#IRbm9Qaza@sMh#lghZ#9x
z_QJ#(O_-81rwXi*E;-R`)M5aWa?E^GgIp^UopNkeJ0ZuZ05zN*jLC7k<#?lV{9#PX
z35vmejGD0)u%E_W8rNwlIdfa(tY0T5eMruR%&_5%oQ=xmWVoQ##s%n?vq>&S<ZRlA
zNjaIsWRA<(tQtu<n-_xnEt=(I#n35dOLDj5Y^w@zwlzJo^U)_~8|rNnm$PjVM&)c*
z2G$(v<?tNale2wF&JNVuVOGwL4RUg+o7*F2Cu;08C}-y!w9DCrb(bMIc_kQ;vn#cB
z9hS3OjU2v{c6M)(lb?<*IeQShN4K0kv(O`FFKX?@Jp6v)6eQ*RryQ(%(|>RJ?$ax$
zkn8`t$V4vK-#39#Ov>4>Nlp><_<h6Kzevsj#d7%k?G#tZIf%1^E9D%LC#NI>DLMSE
z;2cVi!^Y(tJ}l=5>K;kVQ6_rjl-0>OI$O>$IdYC=J(eEjU2=}2-tjRo{|TI(Feayh
z`X{!_IjKR;$@S=wbIP=wQ_JL3@hnx`pT_m+<eg5;83J+DC5X#8ljk|J2Gl=uLe5#t
za(14angWc<Ifwe^70Ril=K1uyfSd~_<?uf4T+}b;VrpJIBIlBPIra3pv>e1;#(Fum
zE~jQgABN;ynIY$@DmjhBHd6cQI?Twqh8ow*%DI->O#`6*br~3xbA2V)yTL#@*lX^W
zb0c+b%EXAAn~TsRhxbCKWm?WHO>%DK8E%WoY32D^Q*v%k%DJOi&YjhmmD4sXhtIUm
z-Ia3g$&u4u0Q&M-*14}n&i(9lxS;+62{{jT$$5yqhp5p>-OhSB4-52qgkFyj^Ju4>
zt|E-dd8|#&<IM9!zMO7m?`Ezinc=AhIZu<@Q-Ucu^T>ZD8*w?$mV?~h5jpew<t*Ur
zxkAjy>FblTuvX6VS)k7g8R(JI&w2l-oJDnV7RS&o=f!j+<qXi{rD{1Z=YYDe49FSG
zm-DKL4mqz8_gXVja+cI%R?ZOjL#(ftAtC1tp688jId2-E|C{W+IVFepE+^iIeoV@F
zi+XQoqZ~7G-eEt%bz)r3yDf5-Qg0cxmXSML4SFo6){161@8yE)BsuT5$yr$?=L33;
z)X4cTAI$erx15i=<nSKld}4t3Pe<f@M*J8tW5j$;&KFtW`pY^n$M~R}uR7(dqSn`?
zawhW7Bj+3TR};UwQO>s}n17P<$+(>F+U2YvZVmb0Gt2i=a#HmFK_KtPYB@huVp`7B
zgq)w-<or^O0Xe^xfd12+a(-)&^LsHy<g9H)QV#Dq&bk<=^9MElWZpkHo6Q7$XX*J@
zqny86<owgdJ4-eu<*qj*H`F3GTqf5rkd!;8Np8eMqugjZ`sJF%;LK{3YuC$l3PHYG
zgBiKrlw5y6Zcr^Z)+slQ>$$aZ*YElN!7w$bpPq#>P&d5=-AEuMcY{onf_XM*Mi)lq
zZW#N&+q_Qh=F@VwaKSTd!Lx3`yj#RED>thM?I31Lo@L8%xm(e1EBbBKhe^3x=YqVg
zIm>3A>|wdvl%q@Twt1jV4)wRMl)J-}++1q!%q+X+gW9{5%H5s#{C>H6GH*e>+`UKS
z@_ExO>X5s?0qzf=PH~&ugPY}+jLAK`UG9;+a*v_Mu>!Trnen)PF~e~)a*r<raVKP>
z3Z009*otCsRzci}WuVuIqjFEmM;(%K|Ca;y|3`c!F_r9{oD2G%l8I)yr<$lm52oc-
zkyBL<?yE*HEBCY#v|&Q-=^3cNklZt<bw&-C=?rqK3qZ~4F}Y`^qa1yhl6zJ$nlLQ)
zY<i!~TxV0GhI+h*xaaVE=X8VXbF<MX_dMdxt3Vg1QJaMZx##DhUG4>CXq9_m3~h4j
zn7xkvb(3;0Dnf_ci(TY{*ozZ#`ON5E5|>+F3hLHR%e|CZm(uq#>RiV8W!ztplG`{S
z_nKk3*B8ibCZ}aY?k&{3twe5Xv0OeQxp&g@F0^N0M(%xCa_{H*{-j(!1Gx`S^FeBK
zmdkyZ`-cbQJ~}G*u^zdPSBqc8<UUFKQ&n=Go|XHIEB9H>`Ap(I*D7}*Jr>o-eX&vQ
zOI>nbX73ex4`NBW+@X}**NJ^24)Wj3MZMfOXYqEh$7cuktueW8XQD&yJM?>pnh6uk
z@NOQ6UCRAZa+eh#0dj|%FeP_+rQ8+dt>}^a9&yQkwO~Z<`_z5E7QJ#;60?%nmF$0z
z58_9dX{1x`hh_M8oss)dImYCET#9zNqtqKEZ**GjC*1S-!u^!`pH9mCjOQE60{LUz
zaz8hako!d;`s98|+?S(r$9b0Vq};EF`zj@O6|rA4{{-jX6v<u9{%U$pa{V2--;uM1
z+19km{hnD;^!=ez?vM3yf2x!FbDrE^Oc3{LvE1oKxxW?2{e3|0+Df@I%&?9g>t^Nt
z(Ixj!*4aV1e>2D5^#7+2ZSs_ZL3!(S%H!v=7n+tAW<NY3&!|E|-kfHn<ng<`7cIb~
zJd@SzmS<&xTss5A*~B@O@?7@a4tZWK+Cg2vT3#Tq#;6?|m6z5lZ*Hl)^~qm<TpmAb
zy$$HUVZFSKh|8c>#-O~7+1sQ-UM6vwL-IDOk+*raye;xDCNGOxTheRGCQxUqLhw9W
z3$2)v$M5c5Hg&U^e;ev;TZ>_N+cn6`DVMi>mAoA~<?TrA9os=pZYi3PlD8B6cZ$o~
z*#xzAX1<+?-=ze^=24U1-M!t4zzn;$%FE|0pX)v7vB$K$J-OeDm;x6=^8QmGZ|@#?
z`_y4ZUSX5G|JGwd-oA~Pl~=^x0puJ&?*oZHkb1>a@(yN(gD2%3QVHTqnB~wc49Po;
zv%`oxoEoKEmvVgs^Bh?y@2DK~$t$aocQkVxO^st}<sDmsS$X9>@{Y?!o4n&$k0+O(
z?Op|SDiZQeY?gOYjlBP*V*n#a$*bhPvKoW(PA&p_r;v9F`KM-sdR46a{Ps@EL$5r3
zW_zdigJ(Y@2c7b&vrs4ROatYh&RNWTRtKne)|kArIXgQSob&VAJG)OFKd-%-CJf6v
zhnnYdeO@t!FfOmQ2*jNqLp_-D{3&_-toANw1M^%kBJV;M>|NM}S$P*#$-9_3m(<F;
zRPrvP-{np68j9py!Rv5kD~2#5@2YIH$ZKRizJv1`6Y{Q(p#n*H*OVYG@7gSo*F-PA
zTl22(me)+oO~l^Bv))vNX7H>x=YaE;QhB$Kck92%xwR3@cUv}!Py=#q>jiypo08W`
z{nmVxp#kk+|8{b2r^oHY-##wy4r1;g|NlhH9ewidq~@I+n3mU;2d;TP@$Mr2ZtCAN
zD*mgDax`H;-o4!4n+5vaOPza%<lSeYLEil_jL7SV|Gz*_zN7OVr~tJe=mUEX=A%yD
zLk7AqA+M8}I;%j;!|Xp?4f;G%4EjG>0M@Q%q~tx84qoHO`sF>&Y>&^#d!j{NcP7|-
zvIM-gPbTC&m4PCV`&1`p<vq<zPd9<r`ROrvJ-o&}#Pn1liD`NBGEsvedCyX#H-<ux
zKYvi(0uzn$p34Ps&vj!=ULX5?*`P-s=Y8xgBxWIVJ<s}lF)C4yR*?5RJzmH{Ek@+^
z=b-`YFQV3>7I}-wU0et1y_f^)zu1XMc>^VA$Bev}N--$!<s$URd&NW*Qt}2fLEpiC
zOv`(<08JQ?_gW!3<Sj8k{1Re@1ZEj3$Edv5^HG7Myf@NOgl6=CIo_n#n>A?104C(|
zyMh-dFHT&1NZwl+s0Q=A&Gp;#eY+d8^4=*yqr3!t6AkFaxV(2=6oA_Ac7QtXvcHtL
zrQ|Oqb}2I~9h0|=8I}>ZtP3OZh7Irx!<A?Oal@mSk+(bpMW_Su%aig}P;*5tN>LAH
zTQMo`y(}>Idjs;4#3akn59+*Mf*x?alKquK@;)H`gI0MX^dG4Ju^+PcVG~mFKB~c}
zypM_hn7R2}>5VemC-nZLQy#ygc%RbyGjcwo_88}5?U<JLIdgm-m-j^;dgXnYi4J+=
z#Ev&(O5RtspzbPqubPziHT}LOccM++H$tPl)h3AlHU{cU79c6_y9SWErWC{SzAwap
zyi_sh`$HM1`6IP|9Fg}^6~^UF(eq~)o$`L6)-MzCeyv7I-gL9P-{|vOue{&M`<+?V
z5;s$hI&^^E>(W6Ee_zL2Hze;5X8nVHf7GHK!}9*5&Y#5axz+n~5Y(Eb-)yhEznJx}
zxV*o!(1sa#|8&V$9_leJe?8Xq;_^e~;67Z4Uin6y{5k0ul^@B+kbJ%i^`nFG%}ONY
zTUlV=rk>p;--)3KGxFUr`CbM3<oh}Jcb$|U5Esh?acKsck&-{R6I1fnFGIilbmmFt
zeuGAg$ls8-jX2wgy^I$58<W3Dt^7^d%dD5bnTdA!oA=A#qDp>Nwfrsf!Lw||99!qf
z&(6k#{B8Q=Z%d8s(lIN4dvdpDe}@|RJF>SUIl1KK@*F!g$lsZ~ok!*G!gU_!dBpBo
zE`PU5`Mc+$Lw-KFd*mQ4f6qFk<nPrZzku_C8TtPil)pFm`%r72VflqT*MGCnEq`C~
z_v5UnRQ~?ONXS2+ME-$AAhx(y{z23{Xk7lmt?~~klV8Gohnnb@e^@nA@()kSFP)Ho
zM3?*{seL3pk7CZFs8>e6vT6B8_sBn{RQ|CphUAyim(Rlfaij8&C-(&QDzY&y|HLNw
zC(+}iUitqkmS0IuWw-p3**}GPr&7C0@=r^be>!JpWXP}1m47DdS<HBLA!g*C6T_tZ
zbD59dU;J8n@%xH@!MOZ7@-E7ee{sG1OQ>@RGt^hfztlj#{L5-U?&WRr8|sjff5nLW
zD_i7WMg6O$<To<Q)zrDVRsJ;vn3jJnJ({?`u3G-}mGW<(cC(32`TY5we<LwBG0V*j
z@>__xC58d{x6<b}>bCxCM*i(R^6#jSe`k*THhQ!T%D<~d{@wW)mVXcN?RE0+&6a;3
zHSX(>e}696@5n>9{0F#yU{d~rP4XWSTI6?Tp;`XJr5KU_NEMjrQEEL(Y!@@}{_a24
zh*9~EbN+Zz{u2e5mES!s|4BSW{iliL{o0>LpJ&oR+_Mexd;8?i=X^nh{O36DE5?NU
zh3q}g{R_47`-xrDEPpY57Ej54k-Qhj<PVTDFeLvap7W(q`7iU#FEbbKpZ*|y23zI7
zngO2WRpx%JNj~qF{u1(sTvUVj*U5W>8gC59f3pZ9^5ebo-(t46iG7FOd^hR8TZU2j
zOR2Z4Uq0_q{_;{#W5u-m_j=?fYvsS6EuZ%l|AP+sBjkQa{71P+$p5%T{-}Yt{7;$l
zvrG)hA8VEWc|CZpFJ|O_N&RtZ^WNZp)g^ybiTtk%LF`1M{BH{6udbH=Ejg3a{7&-M
znDY7A@29dbEC0s~`TVT+r<mdAUirT;&#ztbr|JD$r~I|q@@I%&NA4fR^8d`2Kieq(
zFP`)7O8Ng}C{UGxkgFh^slX^zFeeXv3L@ngP!O%akOH$%fkm8^P+%7!sle$~;AUe+
zf!D3Tk6~0nKu$nhtVaPqUxPI2&86P@`QSXgMZpHeXjHJFPy>2wIHh1C=GdqegP2s1
zk%LMQo6(O61sij}G1r@vf!dqqfu5T(!=_0EndvA8eKH3WY{vO!TyIA1=7s12wYQ+o
z7M+MI$cmvD>}4@a)~tdp%h01>D+7g~C!c?Vt-0R12HhA}kWFrO5gHV1W1<lw3brM0
z+k6nWEzi9j_uCbN^X)ppUJmg&^@uCjo_^cYZ-)X@fxI24vttG-!0WQ(paR|(f?Te1
zCl%~O-<>+Z96OW0a~p`+g}S?Nwo4_36yynYNGRAf3)I_{+Ph_=8szQ9{q8Z4w>z=B
zGfO_b@|iV%R>2-z?@@zs1$$<q4DCo_TESigAaAb;1qFp*{Z9#oF{5B_uJ^7-KZxHa
z2bJKuup9#l{+owx5WjCT$lWgk^xcpB{pejp-=YqXw?EhW_kjHasC7V}f&*iq|ACDd
zL`p$%7C0{^?w}%cVN}7vF6u$v!OVLIGaW*&Lt2qkP-22PN=6hMT8D&!!<hB3CNSG!
z%y~Gy4(I;xeoQJT<+^lS!4dgj@5ppigT142!CXg?Tjrt^0}75dK;NU;KPC^gV4h>C
zeQY<FrJOqD6==brg5!!Xrr>z)kDpR-0&4{^6>$Y8)`PkyWr6$uWn)@FWxIltGtr^o
zlu8As<{+h@in>+IcUrZA)9HUYbDTl_GrAR27lK-6=7RMs&d=&na5nvFT+pkA{^ztJ
zso>lO%qTdI`sYn5sIA3_g7euwe?q|p>|Zdf;6m=}Vi;6#5%XQtqu}CP(C^|>bbz>v
z$B@FTf=kG`gua(>cFBx_dJ`GwM6ZHNxxbYAOPjz<mkB)c<<z^p64YpD!>EEQsuWyl
zpiaS6nHW;gSc@?QR~LgmSJU?z@~(+1xRx24sMl11go5kxkyLO!``0&OQo#*1Aiud9
zvkGqPRB#jLyw3+W7h_lf@Abhg)ZzU;xFrjm-OBZ?T;H09B9MEVi%j%^nA?&HS_eUm
z+dI&s;Er6x!Rvcxn}Rm_we>2vYe2!>%^>!kItA^8AopJ8<9qAizHtTjw<zc^!8{MR
zApgMvkpB?<9-?1oIYt#cOdh`@1drsRPr;)Vm{HKxui&vF%qn=iLBSI_piejPPo{&M
zCnqqi;Hg${{}lI6asRY|VT>WApr-{L=ut2)4q~4n=b26g&t`(XXW8p*S1`X8jS3c2
zDR`~`O$z$5FsWc6b3C68YQI2CKl}aE>7P}wD4}36@rzRmUaV2T?-;=V>q{nxeQ8R;
z%j~^8q~I0SL1r8rQ1B|R&1=+oZBW6IY)mT{YF6-i4w&hUPV|EFH^vq4_j!UhGm(oz
z^n>~N-6Mz#F;Fi~k2w9~)Q@*5cq<)cr~-Z8E&(xblm8C2-l@c}f&}}C9tH0*%e(Cg
zmXf!WI!h-MEF*4NBgPaA7okJJ@&b^voF2=k6|AU5Qo(zfXi|_g(SmUW?^l7`m4%?!
z2gP8P5qgdE;NR;6rWAZg{)hDYkk}7PF^WmdDEKG~c_>07S}_P}@@E0T$J~G1iCG1s
zb!b9L!6#gQ(xu>2@;{~DXFS_y+>e=P!;}JkmkK_o&KJz|MKjp@lA2#qYrF<=1z+W&
zSHUV`R#9^m&;50)f(aK53cjJ<H;oumu$ueToPSHLN%~DrD)_DpJqp%jq7uY?-vZVY
z@jsCNLoH?%{K)J-<)KZ%RE>h4sq-`YzY4q-(;W)<oh<mB{%hG=TLA87$eE$WOhUmr
z`mLkxA2}FM@F!<~QtMByXDiU5;4gCjYR900zv=N$Ci)bU(5~2eWf)eB&(g8bv|?da
z!^MDNkru_wR>kZB#hgmT+&0Am1FUm16-ysdY@=qyHknjx^LoX$q*iv0V%t(@2UD?K
z$=MCNQ)>^-_abj^`WE&owqKuO2h!&tYL`qYcEqq^<r#|cJ$CHOLd7nmMq{yJx8^Fw
z&#u@#`HJy#C-z9YVvm<9_GGqV&&(>;JFZw?CdL$7NUeoUV4mmc_d*t^*FUP*q6x(o
zlec(8u@{Nq@8ic_BK~E1yix~h4fZJZDtWI}DYm3mu_5}tPTm{L{br?N@e;+}s!;6h
zX2ss2&bvj5Ep;)Y7~fOHmggz9g4*x#Jnyrvq{asgij8zD_TjW*A6F|j%K9nypY<s=
z#>`*jDE4K$Vqaw|wu+h)oP8rO-!}t_t)}N{>VF$oY?7Ss1{GUF&YFJ3zOPm+m9N+j
zS&IEg@1L0Qr<7t-or?Wjqu4JMiv7yUf0kmuO(^y|eb$mQQ?A%L_Wxl2PvZX~?{8}U
zldd#nD{Z}UrG>hcW^g};HPWWEXqVE=q|$88opz;pIZESq_q1R_X=yQ~&8<}0`ol`w
zfOR8RX&Ibt!hL3~(l#$uS{Cb89ZK7Vyc|PmJCL_?mC|<OdJnGm$yZuYgVGKuRN4_e
zN;{IhvTCIrL+xV+ly+Rd(oUFE+DWd`D!D(kQE8`B^K8_Tb8)xQ8n|xCRoZp*xV}Vb
zH`FVwnYbItz1dJ&OSaN(p*G*wr?s-SjVbNkYNb6yP8YL1k)gEiNu@o_{k&nN@xGDv
z95FAnD(%HerM)t)w4q+5y~XRWjJcBJd|afo&r?cURjRa!VWoY;^|$PQm!q^b4N6P#
zjQq1no08Ig=Khx{rTxY||9wtdmsHwcO-lPGTXWY-X|B<!xsjyiI>nmnu{XC)b2k{$
z+zr!Fi$2Ze^UmCj+AyKH8KoH3+>Kq3y9sBTkiTgKCN(#cxXq}u*?{J5UVwhh-J%>L
znw!O%MeLT9pvG3!NNMiYU7DMnhbhh7hWu^I5ZB!8N<dsrljd%3qD6CeFfgdOJJxD$
zF1>T7HFqa!>`d&=%)JY}cOh<<QO(WcI<FlQn!9U0sI%*s=I%z`Zq49&_bQN=UkYa4
zgF1WsAC!Fwd`;K(|2pRmnQoFhkLTXpdoxcmPcjG+Nk~Wtf*=TjAP5bDlpy9%G(|}@
zt)Wz^imH}ssG_a5+NZ6mw)&o`_IZ6?pOPH^?>RRyyy5rz{h!Y_=bk;Rz4qE`ueJ6*
zd-tsdu8}$sbrKJeI!OVP0{cjv44TQUq)w?Mb@vidr%D05r-cBhpN=}|D3_rHs)2S=
z_b3N0kUBFOXaSJcvlh5T>R$B#-g`HbItw(iE|NMs0%#(29|G{qQ2<o{@^Z6)<D|~x
zfQ`UiQui$d_5t|auL3wq>U?*g7&rvnA$0-D6ySINWT1)E0|J1Jq%K68g_QtgP^1Nr
zR&<-x1Ji&8QV&A@pjJ{Bqus&aV=!nBL3zaT>Y;d+l#qHD>J0<U;l;o$Qjb_o>QdAh
zSw-qms6XlksmqWyCK^EcShO)N7q~#`@^(^Bu#<Ws=ubRO>I%@CgtjNwk-8G^Q&DeP
zA*rW>->Mc;&qUs=Hd4<<{W;*J2I+GTk$OI!wV=BYGFwzj>bfhWUR+LU#JTFFptT(7
z4f{yFGMUt?z|Wd|Qm;Ku>PGOi{t~I5!8>A4_2v*#KMOj~wv)Q4hSbkVfo-JTQU=^6
z^;Xp1rXcn6DF6ILQg5#(^$zgYjQkghNxjof>K8MCJEU&8M(UR?ka`!&?*h%;z@7-;
z7OD3l{}r^c-yO&T(8jA*NPPf2WB#jKD@grX32>Lx2X~YD^+TjSgf<SL&SCI$cps^c
zfY&2ONqrP_-z+8dv0MQ8Z`A-dNPWDG)NgMi^*hz1KG8_(ccV#t3N+tCep@oBPlJ~;
z$b0`JsXss)=g^-Ec2a*BK<Y0*=TEJq{<4<TU)?436_ouklhl7}BK2>``^RNc|Bm!~
z$)pK6P8!TFO<DtK^4dv*HKwNDZPMhg2Jl``1Kc7_{|ewTX$Dl1270F{x=xxwNE@sr
z%}@nthPRTY6zL;DZ&W_eM4GZ%(u})7nu*b*nS#7&nWUKo8gtNI%@xwjy+)b^C|4&X
zO+zzjR#uZ{)jra!DJ9L?Lei{5{b#_-vqsW1p`GVSNVBbqG&}MB5@_uOFZ)|bgFQUW
z3D9}3oHT7mNpm`yG-tMv<^$xPNBxg4lIGJi(p<Vrnr{P0^L-;}en2~aLHVColjd)B
z()@OXG<QJfchpCmq`7~Yv~oLXy>5_Jtst%TF8;6FuankPMp|<SY3)+dhFl_TI7iyp
z7Sh80XcOB>3%jCCTTR-GO44Sz1E7-!<fBX>$_~0q+QBF{3N*(mNjv^FX(twww&Egb
zr{t1$+F8=pG?5m*NL!EerD>#Ho=n;mS)^UnNZNHZq}`0RpNl5#j#AP#Yf1Y8u=6r$
z_m_~i6*$;H+Bd<&TcGzg_<ip-X+NwW?I%s7{WO!bUm)#j4QUadYJWUS+Fx2p``bm*
zBKFfh*hf0ab<(+2kj}jXI8HhR0Z8-CBAstC=`_W_Wzy*`kWP<xeGBP~?xZu_B^`W)
zE=Wl_*nVADA?adEfm@`5jn*ZWlMXglm$sX987P-|g>=0*()B^vegUM*uO{6<)EN{_
zx*?!7Y#Zr@gVu;F(v{Ydt{iPmLOYW;lCDZYy4j#L=Qio)rjc%;k#tK?ZyDYjE|P9#
z4e3@jk#2P>>DJsJU1J65u%E4a?lS4NMUZZLCh2yd&W`J(+ll%wqwFqV4}R}O-Yeke
z74V2TuG_zwbg$keT`Qgk(dO%*`Gyj>K)S<6Nq5u^94Fmz&_9mnyLf*OZMM~r?sNm`
z&VmNkQMz+Px(k;{_c7>S1Z~86y319h`?7^}U*94f))cxQkar!lucIx*bh;l;lI}(+
z>29L#P2~SpPr5q_(*5%q=^or5z1wZl`)(w?VKwRf8b}}5Li+G((nkYH5u{JAA^jkv
z*IXohZ6)a!1Iv-O%ANG9@kC6ce-`;KRFHme8tGp{x#M`A$|wD~cG6#JBmH-~N&l0Q
z^uOF9{he*3zaLL}ejgdwWHQJukik<+25&soQZndnlfj%x275gj0_(^Sa+VAc$cqjk
zL+l+gByS``Mk5*el#!u7-Us426z`>#WSH1QhRW+?nBGc;ndM}dbCeA8k-iA@mx9&`
zyu<z*HdK*eGwN<b-j0i8cwsjgUTh%4%g4#ETLGZVUOO3HxkiT8Lu7cPmJCOLH$meq
z)Oovv3@4EOUH}=+pzZhXlHr32GJJG}44=A_;S$>UvWyH@YRGUE{rCZG-Bgm{ulS94
z%<%ViGThrph7Kti*^Oj$Zy=*@GZ{^*$!N_aqdl37{-tCL+(yQryJQS$Bx86k8M_6L
zF$QVzXUUj^v=r3uUQWi;+hpv)kukfKjCr6_5JASmCNd5xBxA`%GLAx>F{NZIKT5`m
zYh;{uiHx&q$yklw3#!Pt=p-4R1{U8T<Fb8ZT!pmt*U7jknv9z-ld%cdUQEWFsNd2;
z#yxFhe5Ia@uQ!tMjT$l@L7iiudHfI=Pb2;P>twu;MaB>D{!tSdKgRPDwD;+5GJb}3
zF13>p>u%#$NdNi<8NV@-@tTs1-)$q~56xu!vx1C&Au`^m08suWp0~6BX#H}9jDJPi
z-&@Ie2Q+_gBjf!_GV&M6M1Z7%OtKK*4w>BJfo){+Xd#nlCV(`oB~2P5nY86((&duL
zpd^zyi%b@PyFezt65tk@?9F6yR+9<)=cbT0GGTpb>Q+dmSkz58Nv0$_nUW*O)V-EW
zsl{YUYavs{Au?swk*O!@WD|hjee22853~n>W)YqP)5uf|T0_dnG!*np>|`2-awG6Q
z7WF5A*5pfMntGH>)6v#+JgZ8{G~+m#X5J>#tc_%<R*-2n^5*1|>8X8WszKh|CNj;#
zdtCsT789B3rDVc>o~hvunO1@3sw-q#(@v(w8ZvEaAk(v#$@E+WnYPxG>3Q(51NC=t
zz+E!!MwvaRv*$XQ_EwYWmDOb0calu|L34iufc#grWNN)kri0+=P%W7bE68*-giOZ-
zG?VEqq`wXNC(6k5F6y3w?Ai{I=``w|*+{1M!RuMH_W{a(aE(motH^W#`5)dT6ZU&d
z7lBXF)@Si#`W$sHgO@L_km;)uGF@#X)3+%5J=*^Pw0|rn(@)7{x(ObB+eW6}k@wG1
zGTlYpKY)A4yT6-E?V!`41R8+bWa2@KZw79V=>f_=xJYKYOJ?Q{nc1^smRupT^fsC0
z`0Zu~iplKmPG%3lYaf{v?PT^TCA0E6nKdY@J5FXp8JSH)W^)snxnwe1FOk^~W$d7f
z^{5$Z9djVs39cq{sFciMEo6?!B6B2YMAefy2Klj<$sAup=0qczla7)(rG(6>pa~r_
zr(Ga(I?~e*ks0d?b0+xc*-GYKm&x24&n(dBgZv!S$vH~qT$ImC2Ck90ANatYzj;70
znTye<!FB-8A$TuAI?nl-hu4vL6rQ8*ka;xH%ap(+GLLB^^Ei&o<FAu>!frB8Y$S69
z(k9ga;A2V|nJb&fJWWgH>7Y>s%m5wethqXZ%yW?b6yC9BHqR{tj+1#_0I-qF^QFKI
zGS^-t^8)a?poPo}QGOxHFGTvHJ7jJ^J1fxcN?=t9aGlJn8vx|3xlHDD(PVD411P^9
zZ9aoGHXb7Lrc40O&9!8HwiG~q(`qs|gU;SYG9PLq^Bb*XKHLOcBlD4JG9N7_^P5M>
ze5{7dZxN6MQ~?*sd^{i6N9MPY_BPso8?@ii0-%R|SM!NWWIlO?%<pa_^C{Fhbr!fz
z=J%8U+J6tcwt>&KIsomREhO^?Xy-iI`%ntpCiBNA_c7{RJWl3M(f~XWf0{qV^Ro&v
zUow*UbI1|<JLa!4$@~r8zqw21tCz`)d11bWa@TH<`FoW49?u`@fp#)qZv<|U`NvW+
zcZ84`I&YzkWbvpci%%t4l$Xh(0@QcOqP;^F-9@tKFObD31(0rb2asnuNfvG&S*%F2
zZ6k|cBU$XA1s%6I4w1!~PZs|WvIG>8B`^X2t)MGp3BE=a=)5HidExP7iLjF;5;P-k
zkfj^)qVSAHxtQBziPHk0kC@nk?{$`Bq^ICL4Rz9xmXS%89w?IudOhpO(yN#(y^)qx
zLzX_dWXY)`OCHeoBw6yoLq6(a4Q%NT+JzNlDJmn&z$&r~Dkn>EBUuKc+)yG*325S6
zhh-T0HypG^;5q6pS;lN6OZjTDRJfC63d&EfB+Cr&RE@MbMzTBwI&<y7b+XLcO_up+
zqc#FSdkb30vap&gi;~Gw7flxI7g-jg>=M*la*HhWC&{uD^p~N|@-nhCl#*pdF<DmT
zl4VsqSyrR$8h79hSsJBe*?{+FvdFTrnk<_e$b$0|mMx&M?Gjm@Zz9Wf(Af?d?Er7h
z#biNjW_bZT>?EKNxJZ^4GXbQ%DEz)nmKN~Rg0z><l4UnXmOXgibBHXj94E{EjbuUm
zYC$YydF>8aUPl{;&@SR4%i$Wb90f0LR*?ns#B%&PSxz9o4ZqJ+ljZ$uWI1<~EEkf=
z@=-onK1Q8SkoFnsUn1ZxSw2VF7g7M_|6~VFlI3gAxB^<=7Lw&U<aqrCS^m;YmYd+=
zXAY<*%Pj?2ele2e*KK6E4LZM7kmc{Y$?^|(viuX}{y?4k0c2?hI=~-)oH)8f98*Oc
zn?{^uH*wPI#JNQf=iWk`Cw_ZZ66YIFoKgYYAWmIIoTeVQL!1_QI(OhQafT4$%*Zp}
zBF>8PwnpOoZWCv}Mw|n`ouD6t-yz5gC7_A8a3z59*sJ2A>;THg7y+~shu`t7#3hsw
zmzYmnGTP}LKwR1-;xcv<mkIO&dZTXkHsboU6PE*?bFLAWi?X?y0Qk$@M_eA-$*ToW
zrZ4LE1Kk2CfVTTb1K?!<+8A(`xI*L=H4-<l1h_!lpe*1lamC0lzD(R;j<_K;#0>>K
z_z129WriVbxDq%-+=wdTN(pEtZe%5Ji?~rJKRN_BN?chfaGN;HA8stt#x@Z*E*ZE&
zTsi8N-yv>%34r$rXmcWHO{@h@5?2ucG!Qq513-UrHE~nWk13alt3+BQXjY=VsnI|k
z&_>)e)Sq^dxaloGJ8?76)=YO`HGr~+pSbE$;^u(HQ%0Zy0Dt)A%GIF$TqS_|^AtcP
zfVBB|)}sD`<HRijtwo?+hqOA>!CdB^-c8)%eBcUkOY8v3E&+`tcZsXd1x^yTv=Bi4
zGW21218|+V2Jq5wgSZu-xAGd$PTVT+ggMWxLits70LrZfjn(^zTcZU~e=PwQ0MuP4
z1)_mc0Cd+K0zj)#0ia%EJ%Dx_!OMEoUmp+D0LO{jfcFikyCEN_1X=;K_Y8Qzo*4HG
z+J6T0o<TbsIiL(^0r0*l0;mE|XVY!sHYWopzxgb2&nf}%^XzV*ow%k#0QH*g5cgaz
zu#LDaQUGmkxkTL7G+-le96<Zq6hH~k02~Ew5chl*02<GuZ`(Nlyle-Z9RWZsaDljH
z)N4LT+za64g+}6b)&t;SC-QcJ#}~CgCQtz&|3%P#@j7uWsMit?lme*Jf;ugz({hKn
zm(bQrsPj@euo^&}m#z`_vO5qBpw7#v^YT965^=i-2muO#8lVLLtzDo6yUOj(0xE%x
zz;WO@aeEX%JOEmIKx+?Z?E$Sl?Zjan%I!s+z2JH8YTyuX89*NP7`RvRfofnI&<5Nf
zZXf9F18@6E0MOe9diy|cAL{H!`u=iYBY^Vz?-2KD08k8|?5k&qJD>!z0PufcH-Pq9
zr9eDT4xnx;%C&;tYY{*huo^fH+#>EE2cZ84LGR#E0BNry?RBKRj<na2_BzrIp>K!K
zE_?}h2z3wLChm;@pacNDH%<a~h&vntlmd-F8*rDnBU&ID$OkHbCIERyK;tOr9!2`m
zYG4}xUXNZU?o9%~$D7GO9f0&>N&xL)&B7f+nYSW<DggW(mjZ<VXdFk`<KX2Tv~jYS
zxOZEKJB4=NQvi(s^02SUwV~{3&^X;n+?g`s-mf9<1JFNrfw&6+#C@Dg+(nf6<SucS
zz~2|O#9h8j+*fJDUEzrP<~DKPRTB5Z72<xpPTXIbh`U)s+|Qu*SLEMDJHN#fcjp>$
zza#yhwZ#3QCGH+*wIlyQ6Iq!`vPy`ovKq3=L&)l8B&(;Atcq=9^+CSx1+p4j$ZA44
ze7~`BH^^#RO;&pvS)FBM4X7t;Pyks&E|WDZnXD0a$%?hFH43z18ps-3P1d+;WKF0b
zYmyW=PS%v$WbJ;ItZ9eHntqF{JyACgd3|q?wLfSK;K(`<JQbt8A?;)x3Oev5R_yy)
z$02Wg1X(BIy#jS7gT|CvvQ~l~))Urg*U35qbgEHzHu9bVZ*z0WI=_&tb@^mnj{0j(
zlJ&WGvNnUpt~#>rEhX#zMzXdl$$GGgtVci(F}?L|{60}e)>A-RCRxv*{@E*JJ>Nvu
zPe2p#wDoK7{w>=4u8^$PuaWi7A!NM)dN&)%daIqRzk<ix;O95sj*_hZC?@M4;OTw@
zSvwSD<s-;OnPg)wl1+-ItdwkSC1mqxCYu+4xWcBtL^fkGPz#(Tn<<xUW+_lXHVX$F
zCmUx3K*L%^HXG7xmB4MX`Qhnzg>3d(vN=HCaguD#EC6Nw>&X_7544jla39%%kRG&+
zY{Ah$3vh>QAvM4)vW23pP|yo2BU?BDZDfl;oyar*zq^4>w;N=ODg>Iz7OeovfeU1d
zi6>jE6etDo9*4ff9Vc777N`cUku3pb6Yxw#d-#rKOIl5~WIKR%lTjz77{If8B>+BB
ztH_oHnrV$>O9%Z74#4jo?!aZTWukmf0zj`P==K8r-bMhwvp_rRF4?l{fLmnivyE&y
z`M`Cu<)#6L$d(rXw2-ZD2-*5cfhMx$X91VVR)F>jb_1Z%zZL*L1HjjSJ7g;?CtDH9
z7o8>Bz*e#i$^_cTR*dxG8)O??51`E<rNBP24K)H)0O*#W>@X!z0pNW&${=pCjnD$%
zwG?zq@f?XdBT;u$1aOjUquqf@0DP2zhjGzl8{a^-iAbwJyORk(`cymFri1nj^l@eY
z*=Dtpts4B#0nM6bvSCliHeW%u+A6XwXdzpjl5C4NlC2)Um!2ita{O*sO}3Rs$+iYG
z*Ipvqy5nS9pG&q4g=E{<NVd&4$kud`Y|o+mR<ykhdE4=9ZX(-G^ykHRvbD65?WGH3
zgO9WAZ6F)`jt%qAb|8~%tpQ{^i07divK>w%+Yv3<jw0{f60&`8l5C$M|Eof>VZCa*
z*+#a%yOZsHH2F#5$<M2b{4_1(XSqOr{;lK}ew+N_^T{u58~J6mkzf8@@*A8?ek04s
zZ~R&En-)TTb5LjDW%9#bzTY}`^4p9uI||8fS1tJ+K$)W($q#FEzjMXp_gMh>T~UzV
z_1)z63uydaLVgc&$?l#>c4a-;jkn0|s3d#nQL@LbCVOf!*?Vs!d%l+J#Z6={y-4=)
zX=I;zh3s>rWM3FfcEou0wa3Z+EZ&;~$i7EO_SaDF&68w*w~Xu`pzg&MvR~du_G_Sf
zqmAshZ<GBGBRQ}(ad@01hq{m)79xlLadJdnCr8pPa`dbwN8h957*tD+krCvWP(qHX
zHge3{M~=mp$+1dFj%Uirv9*;PFWw=?zFcw~LfPZD$#ELLKScT$QgU2HnLl44$6xcw
zfpwCTqRHuANKR!nIbn~S#yjLRwUE;s0URZ#rIef;0Vr!NBd0B%oPO>=D>>~Yz*%xS
zl7VaFbRx|^69A2X-M|%c1}cE#<P53;kRDt^&JdId1&z>?<P2*DE|W7n8o+x*F>r{S
zkth?njhx*GKs(*`kuwUkqBa6I$Qg}t(UkzwqrpRr6hNJrdZ3M*uusm|d;omFUpeFJ
z$eEx7z)NB&aF?7(?c_{Geo8KIiJaY0J{5eV*#VSG$9wv1a%MD;vj^JEY$0dQ)xZsM
z_S#3z-Vr3FIwEPk><g0M|LX%|OBBke91@j7#b|vQ|KP-gct=v4U80ryJA)G96XRm_
z()#=DQfXED6?VxDQ;zN&f6(O4oIITp9GoIR_Qky|(%<iUN-AC}eg1RjbI(s{-y-CM
zq@)nBbc2XFB|C=G@lX*)0<yu9Xcu9fR`Xah%)0}mCX;kPW<*3LlNlMADL^)`y)-IH
z(&7;wA0O^<-y)<&WM+bHrbNQ7m!*;qSwUCp#(;7{d{SZ(Se8Bc%C2|g|K{nf8IZ5`
zjVt2+>c-#pRCK<{Bwh+WM5XY)`9nld@?*aR-h&@3mwYMx8>LbYp^b2neKewR2>lR#
z2!B(Vt_PadY273aP3I5c6_w&*8HdCn`7-OxY(=O;n$4ebJ=bMrZBPCpE9-hMA-NZm
z;d+*5Wz9_9o5kPdPbD)M%)(H9PL{uyo>|%T3=L&605O$c+4T$!<xepg{3(oV<%5lq
zA+nb#j?ySgl#bj@=bzAxNr=aI>a-XGy+IWeEDUf`LYz)-5EJnl7i$O#R^dHRC3lnS
zv<5vBAB>a?MlxjdxJ_wWj}HrqE%8xB-hQEA(&-IpO{2z?1jP+gdB^^|qp*UXI=)Ze
zzCD?(*}bMsTFuln&6w>yY>4LvTgSu(4U>N1!)Ao`o3wSqC*CDP+=q|cR2COhB7MiJ
z<DbDps@j=*p4qwO6SLBJ<<x>)L&rs*9RyXS*a!3E`SLJmYcM5HAM{4)u&V&c!$B5?
zK3K1FrN<idaj}9DXcEA=ztc@_Wt13!cytW^9wx~1`9JeF7!zaSRrmj{(}rp!O_O&w
zuh6@aH}!q#<)610w4uv2{!=Uc)i1o*Ze(QEs6f3@d}ChZQ<>AudA3ktx<`JY-khws
z&$uBCuGF=g-m~7XS+lwK;=10O*7Lih`tJ?(JtG3$T(5*N8vWoi*;kks$rvF7n+(M5
z#=42TC&l?N=n;B_5fL;xNqk~#Fia8*jv-NldFr1alorNE=oH2(Q6qG*bKEcszFN>L
zqR)Y{El(Hq>MxC#?0V|(>j&Q3@@0^5P*uO;5k-^7MET!KSy9q`X|rNO(Vmj&9co{{
zg7mQ1^gqS+pFTQ!tRp5eb;fQ<9Fq|66#vEaBZ)nyFMe^`wgdJ3(u0On5BlO<)2KmX
za>^R`o14!*-MfV`2grtJ%H>SY<ish7nNPj+#!u}N`@gVi!>E*^nbU^M#BdTrl@bZF
zPn@^^I%}DIofES_rHn0lVq&7+2!1D<A-hQiL7yQVbXBEvO?S*WQYjfdo1yXY|9;Hq
z(PO^%_tF^oOH723Kcu!EyL6EWWkN4rI%ZY78~HCg-spIP|I*mW59ki)q^rajK<W^>
zK+iQDAZ~U*Cq*WLzhrc^!S><*)Jc#DX8W=Im|&y3*c5o3$$ldlD7R3Iz$*v_2Wr4_
zI-`+wj%lPo96D-{NigNCj3f{*7+g1RMlTuYF#0HX-j<SV<sW$a7@QWykN?i%H28Qk
zj5RsM#;^(>qr=R9$M~5g9~y%_4)gEE#K@TLhdqLgev0~fZ$Cqb#}TFn68SSnJVFe9
z-u3kgSAX|DxFlO6#aCZZjt&(VOHet`=QxK7yy#SpSlODuj&DLkJFW%?v(C^^)<2N#
z^XM%gFtFo_i&g_ao2j8M1zLgHPRT(rJ2hA6pPs2H&UR{jHcFvPu-!TSCbnt$G`+j;
z^Y8iSg9Kw<05<`djb^Rv3+#0AaPcKF6wAI4$a@9{GrtQQgko=!p=a=CD%$iC+H{Fi
zkR3C%%VkXM@(~OX-^`}SZjrY@v&%y;D9)y^ywS}O%rZCdSN5LV?GLFr6ocPx7VLiB
zgU=*~WjIMp0jLSB5cEyZHlarn)uS1w6)dD+ZX}2M&$;vcoRRsnfB$v%p#6dAdv>P>
zGLF>!`_i547XEzmZ=bX<1DVw3f8KbBAIwNE&v@s=%s+(|6^8zG?v+b5=+_<?g%Y&s
zhd?UG-{Evih!rU(sO0_$u}R|OSD`h7K1ouN)03~v%u&R7Kd1MY`r^H(J*{$yyYB>_
zxpH|X8?N@3_DIZJ>LYjDALmdx+!zM*%Rqkz=!c+35(iYA5k@M=-zj%Pw{(IiT`DQ4
zq1=se#3m+5cBHi5Gct`|W#=y&)8ugToSV^Y`i<>xE?80!F_$l9nj1pQ%w&GE+F@bd
z{`*&}Mo*qIik;dmv-<ffl`{{|nbu<tKgNNMp-CD5nYN<+9C0i}iFQQ+!VCH($WdS^
zoDpWAVD>sWbW0T3d&~%eK~#{mu2^zld+qAXgxKEMv7VmYMh-4pkP#i%V_Bsm+F`Fv
z?;f2n?o{#9sokPe=U1*;TeWy-(Sr43Co$#w=1d<r^4Wx}-m!6+OhI^X^@tVghs`kP
z<qYdyKB{p-k3NgpDc#aiqw9-uat1D2IB`s<wR{Tt!BQ;b_@S&G<K#q7`~?L_(zymq
z>_Ix?NDx#EwpxWL#YjH9=%G0<D3$*qc~F#Un%1M^bGA-tHp$tG{5D>~3~RHggBY02
zOeRR>*On>y)TENz+w&zJ?f(?yRtC8V<CZ4KjYO9qnhHT^Hl|Bvf(H;MpfHEKJfJX;
zD5Vm)k?i3A`S#YU<0I13Bh*Uk{)+VjVggg28kQ3o8RTx&dZ=EmTK<eet_^6sI%N3N
zt*_3S%(T42|MLCT>D?nDQf1?pH4OgXVDYkWOG0=k+u)R^WylQ5kQXfcl*x@tA(uk%
z`5O2Pghvx*n>fO%&VWpCTu8tO8iE8?T`akEd1yh1o%86mIkj*7HhoaP!Ohd>ROJ?-
zv80(P3yb=GTHJc1X69Q#Jr*y{P6;w6re>|~6~OFyXT`dI9$_>e?mbb~D>1z?qI+`a
zSlQsHrF_sw>z4nmqPhRmizcr5sH}H*R6}2v9%h2i6SBpGMS^G(z>Hu5l}ut1CY{{P
zUlS+r;*gxs@IQ`n8p=j9)PD=_JzHb2#%IT~3cst&eOa{K!p~mv-Lw1`GiNe&Oykrm
z3f}|Ft6Fa;h2){GTPd8nKaxg5d?37*pxdH)XayaH7C$m4f@6;l?#2X*k(X#!T9+-_
zzk9(-CNgQ<i0bLjZkRf^W27=IaKbagif2wL9zEIi!^Maw$Cg8P#*e9=Kc<oyxp&so
zQ58FX-efNvw`9}!F-5~xpL#mkD<pIVn_HEio0w5PqCmf)rekG(YUre?%f4JZtT?+s
z(Ce=G8Qe8~t`Y2v80EpDa$`n{<J#4SF5az7mmO@4Onz$l?wbCkqeGK>Mr5uj$f*gp
z41679w{+nf69)f!!kMvhWlnft=90zPN$i1FSM8s*BrbJkc~WRZvMfJpz<V{HezLCN
z*tr#p6E^ba&yCnsU$|??3kCI0PXv!GkmW+jFxY<4d$}|U!qlrC_XG>OJVDo!{iV|-
zbQE{_2GD}<+9=ZU7e?q2EzN)PWD9#nMD!G(-(d4{xisND$7yDN5i>F~+kd*e*$>X`
zg%faYD4Lls3_tCC@H>3&X3_{g3o}yi{;<D-*>&?^^s+Uf?(+N7Ef(o|xqGPb{yWlM
zM!!%A8{%y=db1&tP_tJD-@(J<K?Zx7L9#WH6!=L{LnP#K-LX*O&R_7}_a_AhOP>ww
zdP<b=oqTV>fj+^@BcJHe8SDtWSnf|3xRCa`|BexSN!MH0K1T13%K{rL{^w;5m2_N&
zOJ!*&ls!?_LJo=)cyW`egtbLF15epGwb4T{o)R_waVbj@$MU~fOmAd!F&o}0nmKCJ
zi1Oz@9zTHpzH88=>lWpm<salG#gsB$r~1wv9Z|Sy<fySz1`HjQcfab<I1c1Lmu;6$
zrXe&|<Utt7U@?9cXIfwvBQ6WnrMQB1?o`<XWpI!%^L5yfh!x^6(f`T)?Jk$^up@{`
z5QA#HFe7E#)B3IHGu7R>rL=DJQ=iu}@|4WU&-IV&**$FR)X_C>R>ms5H2T1yQI6-D
z`CGS-yv|H!oL3olFZW>mn5~Tq`M1x1bnYWY%|yR-gm=DD(=@aH^xQ0F&-3%2ujn&)
zd~8Pb>*X0f>S_Ilj7^9POCC3)Px@0y8Ii;J^&x(N&rF)m81}!>cJep=TYl$!S(wfz
zEzo)TEYpk8T>kp}X@1}r@}7g9>p!V@fG|E-`^i?wmQWBObV5{tph7RmBiJGK2WAeQ
z3yF!MG8!0Iqa?<Qk*!#CeMaA%QGR~BiQ|If!;;<(&RFqkB=ek)-R{He(e*Hm=9#Nk
z<nnYT&APaFa9-XNN1Vlwjs$jz^tq6b`!VT0a+Z0QeY#^2>>>D&^0FS-X^wbk4;|v_
zB{4yWrrZ)7g1;2v4$&YAApiyhp=gp|5aC_L!9qwP<<~yFtGzvgnW2-(^at3BFFd_*
z@`$IOnL6*zh8YhMd^AkZqLLBOxdk=+QjJdn!#v%}RJ<^0R5}~!<tMfHdBwVC3>w{3
zGpxX*EE&r(Gq!s9Ch)=i2X_3ecG#$nza|J5@$o-~vL1Xc{kv?MOS3U&g{74sEU8K<
zgCdCGiJ&X=P*GwHf??N5|L$jzEBxciDi&8v<iB8gl?_{cBV6Sv#fs#@NBp(3ZEYVg
ze(&xbr}EKDhM4VXa~Aa<9J`*6;{#TP?p+#R;_&~Fzx=1q7$@Vnba_vs$sx{rVJxd4
zL%lGTLQERUB<THxkf~FG&{GLixl?pd?o>ul*Q(vEe0xW9mb_B$>1o)*US!-3ynK4%
z(|`Ur!AGn0jsN7k1=HBg{M}O*(pf*BAZb8=k3*XA`C0xB6R`d;q;vl(2nC-21(|>c
zH}DXL7sQa_eCTRk<1ffZoJcA$Dv4A1W9Y(}&Y?p%Cvz*lzdlO7K;`D9Iw&npjxpvG
ze$M}q=&L!nEG#fCE+}m2L5*)Bqq;S`cL>wYOVgPkrCn;ZsY2x$e4nrKhbVmG`JkAH
zhK_$WM8tOd7VoQ=UfkX}UeK}E!CN$V6Ikh#!@sf86|9LFouZSz9%JlT@JV~5Qopx8
zEFd~MAgq3`oBDd+bbeJ#Zof=pu-x|zX^Ld&mwktMdMEQ<agobAes73~<9#ivaH*j8
zp6Vp2-GrA6m+r_GKzD?gO;lvT=*t~l7Nt{Bgf-#6s#Q{Ay0D-R$Jl~F*@8k<h%#*O
z82&bY^@G!b-kjM5z0om(iaF!TCM~WQ#h+)A%cj*9kM%G#_2~KZ(L>Btxo<DN$vSV>
z7oRc#T}s4zK-Ff~^&i}=iBIB_pNmTFIcH&rG9*<dbLl(AcB!lv4SKZxFvPlqB+kAr
zxy5#+cCm>`s&fi6Lzu9FKt<*sPlYZf$(H7X@y`b2cxct0PpREI4!Wyf&xzo-1m<{X
z)Sh$IP>K3(eZrWrk$pS@J?3lN+5YaTB|=JhI8r?4somYx2L+20ptQ2;j$f_H07eiz
z6X4?~4e|4FX2|6kEHe2Z<}0i6;p_d&Ldl0Z!fr<&UDgn~n(#mN27IHl?Dm{){Ho9#
zcb(d^PUGRBULKbd!PJEI@eKCt$0c|v`?HlIA1b@lZdbV)_E2}f|E)!5mAhp7;B!d>
z+7;GbL2)jP=nAi3GGO^!;Z^5c5@)WYA%acQ+N!5E&K)^EJtit+LC%J8DN!EUpZgEG
znzvXcWxZ5M?UUA&4eygbJEmuks48~m_(4-7Ypv>F31oq$#QFLP+QqKfBkRw&2{ZCP
z4JW)q+~eaWt`J2<)X9Z71^z<z%A(U%IkWxvtv`CG59Y-1FNNp0V*nQ@<(SibVwfSZ
zeLR9Z7b@lK<bV;`(~l)I&*ir<XTzcbiUc90>ASJYulVOUmD4qPA-+~=n8nAR6^9RR
z9rbL!(~<6aujco4jLp#axcVYp&?!UMp2r97U-|B`eM!;<N%whojncDL(656zNz9_C
zJg*3^Z8}e_Z`}S%Bl;L!X2##gE)B8!I2o4`sr>GL1=}*e?D|8!k-r1mg8AIJHg`=7
ze{tuL@mFaDaf;qmm;jv)%>xmh<Kfg0WG;WFUj%<Js9$~$V+hMzee`-2AHbgfM5p=e
zoLo`hRmKdCR5JURSAG1Mkx+U_)m<ehy{9TcT7BO?AY6Lp{^d0;$*qz6tXJBxxX%c?
z4{I8b!G`+U?q4;l1Z{VXy)d6eokOrAhMmDra4HyV!Sgbz&b>t0(hFv#y8UZ~+xd%n
z{l#-CzsRY~5SyAkdj3O;`GQQ!Y`DMQZkBFQx!-T^Vnga~RY;^6=60E6z$!uU5O+NI
zTs8*w&sW&Z5Pa1`(<eHqz{mV(Qh;pCk(2xl{>F(ThfiQT)_mgdIljGg{J0VPJ;r0i
z*x{oXFZOx<hflux`V)p@te=1T?Ipg0Ioy<(@EqTl4}UQ^X<KKkBfWqz>WW3>uArey
z&!2FW2sYf}yF7%$F1@g6#f$uFZt6q1>HM+S+&uL>=!^O__Q<O%wp@62=P@C!P%<f!
zPj*Zz=VR^4U{<s|LB0;D#jXsMWsI8q@(b$}J_#MSpfHGc_{Fkm=)Z#!DHC?Jb2S_+
ze;6x34k|I+5fmvdR-){biC}UNw<5`qD1(@=5QHO;O^fe2Z(*uaKY9fJmlH?3<TPpO
zn;8pNhIuFqpYr$0%Eyf6|B*dpKQ}t7vEV2E&jAgw*}dXQHOt2@TAcT??W<28O7Htm
z4!&7@@@0Q^IrIMZ?#a*diJ$L$KQl5WYwX2+=iBmP<FY!(uo?2~L0CAucK5`!YkY#z
z0fql>7Uc0jPFUT#`iDJxmxGA2%bH^niknLYGJMAmZoY^6X7k@>_myi^o(K!zW!cF`
zHXoWbYWYj4CSQfZZ|HcN3~^I7e_%NV;cI5l{vjDzMg4YqTP)tf&b?I?C=tiP-`7v-
zXHiE;Gm6W1%^T6rk+L9u>fpiK5BN#ci~~c%yLZlI*y4SizS%V{k2X$3VT(%_Ok&|{
zi7*agP$$lxpkUS^j0pN=V<h{gR_(gA&={@s(Hd<xPtDw%kvzR*U-g=+&9AP_Rw;~}
zTIQxM;(waD>HWdG8g?+#cRw|MMPOgEl{sL|UH8TASrZC#IaPF6+x+IMtEwyxeh{Y*
zEn=LTroNr72@m;G=N#^ZF$l&i@@HME6hZWXur~kdz5MNRiND4n>lLG4%HQp#G<a$l
zwzv<Ums9LvHToP?yIWN;4`{J2IzW0@vXqfO<>3={{}Yow)Fr@Rl}#EQ?(M$d0Wrsf
zwlRkV`yuRM2MNAi6c%;4DA7@LdVQs9n8hsDM+w=|-JJWJMQ1MXSKPD*@&+;9#ktXn
zIckrS8M%9>miLGp{h`$=*pnf~h>r5}8=hzUF0glP-a#_K05eXNv%`b`Vzghw!UOF7
zVGe^}Ryuh)4xWUaH*8VLT{aEN2SLqrLHM4i);w}rvg0kWe6EkvPsu0gQ!PWjSUf9l
zXY1t2%p{L>Te8QEMDt7T&kGEfzM10VCb-NDCdJ05@PFn1DmiRaj&ga?&UW2?K)blu
zfOt-9*W*95Zoo2HTqQi@2PrOf5>woMXbR_-d7I1%{wV*pH)m4tv*jw&;@?Kh%zIhN
zq%j(mTImcLE4;rX!+VHlkLdKR1BMNk;TvpiaG>Ppc0+KW^oYjkaPgb!t7uP_6!gf9
zR;t7fr26`{r%KlPxhHUX!I^dHJZ#Wj@Soll2Y@MbK-6TH<BClZdGC}Yav0$Y6FTGS
zN~ilzlI>me)AZar{v`hwO_+bTzO#FN(Kd|f&2M)0v=6U3b|9yYQGBNgb#^OSW4v}|
zDE~L6*+0`h0v=43=*j%RkL9%CCY|WNmN4J2{&C)N(b3Biy!ly7fk_u`)VX}{LVk9~
zsswL0R+K;Z{~G)!xa2QP0R(3MItc{fyVOtT??m53*>~#W*ZT+XOFVu1u@mwV`IAX`
z?rN0~6!7Dm>ALcTKh4ZDR(Uh!Otx;u*1WOMjJl3Ze63Ssm3M}iR%R{xVzNRi2szqE
z*YOssavBR<0v3I(G!XL?pOmmJ5_Yc{7z%79I)u#xY^7uIBMtO#ALsC9dH&o-t%^9k
zq~7V%A!V}uIy~Q-_38M{q0>r_9QcTN%dXVl?>BSwAJF$Ie49$ew<+=a1^k&nPJFPb
zS^QjPc~%yJ{{;LAb;}J2{bPh6t0%sBh!aHos*A5<DZvgm-pJxFbA#nS2sO*wv5GYR
zA$1e#O-EbZJKJ*YBz1ljV!QKmv$B{3{yhFJ=XZvN%3lgaRDn8~lB?{mGMrYyi)%6C
zvZbB7_pW_T!3*FU+OIkpdv?~u&se$6X)r!Lz{}{S@OJYu<ky=_ev)<@n{x5k05-r^
z<>{HZ+7RL8Wr$qS%M(Wd#Xj|s62A?em9V?+kWxE74D)@42zfXMz|?hpPkhv0G|ALy
zygm89xfR9wstX24d=)C@vcfAlDB_2k@NWqZZb<G)PQpX?dgR~!KQ@jqJK|)I?F&in
zb&Dy=j*4*eZyG6V3@u^Yuraiypj&22xUeyFWSVPZXaJkUZ^5?Di~-p8d1p{cMq*4(
z=eAF}Z~rH@eG+?M+h;JgeGYK(9@y9!xJBI95qXyml6^=z?Ce1D_$m+#ZF4PV13UND
zF?n4s7n4PB!qP$f%`>l0FeW5KnMN~lb6-8NwC-Tq;MF5a#@dE8Y#ElxeE2^9{qx<1
zN;^t)3Q2E6$M97f*PVEO?8@}sL-;<C5sO!j6XY$(tsHWL20RuO2#ylV7}pnTv0+uG
zR}jOSa!bW`r<N^QyzI=}Q8UJbrIZiYoR+rxV2`vJSs_6-jg{9YoPTC*+Xow(5;LpH
zlfy>I`a4JQAMhWQIWq%`GKKgK?Mert&n60k6@%o_X+%ndhPyhBo+bqfFJi~L`aO_;
ze|qc5`llJg=@+L6eUI;k?W^~VLmRgY>zO`y)yQFG#<gpoS$paX<5<dEbanpTtrERL
z@)q;1J>cn;<>yb2TiH8Tu%#}&nSuUu_|oy8B;e?57eSq1kFeO2NM`s?yL4vd^4i5G
z4podx=-8V%yy;A-LTOpU#`atg8ne@zx1}B5wBhWj#%JfxI+FD9#Kv!|jQ8rXwT1%z
zo*;8Hd{cH^+}n6u##Say*A<J2`yDQ8hb<xhgt*SHdF;*6!3mj;z_O%n_kVX&zFCy{
zW<W|`HK)!rICt+pu_iYqQ#N2!d~mkjcS7-`yICEXI&C+$mz>3c6otAw`%c#HYt97W
z$R%c90-r0DOU_XWWefWR!kmY#6FMnw-U(``(_(MTr3_swTo^xLD^}c&MGkWHj8YsT
zoXZe4_z)Y4zDQJ4c}9lQ!>eN0(8>u7b4CRm(e%~)HgWB14KMCk@mfYw;iz8YD<?KQ
zJ$7PkWDkDDTNC1(Z;g-h|B2svB6rfV%K7sq*GtA^rbqa)#YGF3m6r4lPuV0%EqZZv
zL27D#LqS@CA!G5_{(~Eql@2W!pT_^pxDV}K!`~f}+A-wF^xUaE;^H!0@|I45uElrx
zOK}Dvz7e_Z3Vxj~Z`rj07pRKMVB+j1Mw=v^bT-WSkxkvh;Ml%+P`;;b+1X&ctFrXg
z2;*2LmJQuq&IIg|%OPS-3hVa6)beF~Rj?-5t(TDIqsf$x7^+jSn1sfWRs0#=GZ)b-
zbPqD;WmEC}<6pm72xIWXc3_~$B{QRUbhlo;Bcpq-Ij0MKH_ok>!4Ya0#e~Hf^QG<4
zy|cSTX7#%FxzMP$I-Tt^SgT;N4DDA_ec*W62UGYwX0h0w5P@pt;`A2A4`*-iBAy=-
zw=aZqD<)y%$}J&~S=>8HY_k{Bzj*QR>_JIkVJUsPCvW%AKgVP}YIX9`vWX$l#bL?G
zVfk7sW0H&v*2T)Q44v}Nfcz0}J>0jDxVgR(cCNI=^?zqD8mM{{^kJt$&?RvzTbfZa
zHe+}Gg9b0}XhZJYS%GbyM!jNOq+uKr$8?KIuddH5Si0g>A4U}&7*PNruyH}mi0Z3x
zN}XK7h(j?(7zi(>x8Z&VBMS|WWwYGfv6Z?)!)p1bd+W`@#*%A(`hs8he;2>Pr~8M@
z!63jevA$Q-f$w{EQ;dy3`>_h&Sbet8<k+qj?tLDs654gqlfNZ7NQ1lR{crmBKkB6p
zBW8eViWXWYMDj`Ux6XuwTrjJ0boS?=pbFixGZFqDitmELdg<%WgbMF{^nMYhF-+w6
zKizkP@0zf^PY*`aT5nBH=I_4>T01>h=PwsU^(bvtlq$fb$w*@}hUyh;mf^eaJ{>)4
zaKTO=&f>#Q%=74!n{*QTiErwi<1Cnf|81V3Kab5atEOv~X_vnr;{3>}7G{}?>3^SN
zLE1-i>=9>t8?O*%SeJdj3H$EtI#&qaN?jj~-2TP2NN&QVw(&nVtbYH@>W0^oi=S^P
zic1>QysIdRIrl#QBV#@N!KS9?HXZ)3bmh9?=RO|YxV_ZX20vCh2>lL5^wH_RamG$?
zU#@7pYq(uoNrB=3V#h*sCql7@{=9$wV3U`jeot=R%YmNRI-9#9!cfS>E!zKf{lbI2
zi&nfo);40<`jWn)Zx4y+&DVyh{M~xVWW87z8OhB!rO8W%!CA9rQ{%~J7j4<cJG+H1
zZmJV(4R{;~9__;DFfRMz8lBFWFL++PAt}yfXu904IQzh0qIBTPeG7L6dS&Zvv-X@^
zwwTejl@7=cDT-2Pm+>Fw4VYRsAlqr{RkX6=5I?q)A!gAQ_~FxxGbv%nsryCUbpCGa
zA||qG#Mpw~<wGYn)opF*nr{*bc#9IG2X;jF@^B8MGCJ4Z4$jShldgH_lA=Ts7ZRKh
zEq8CoNlG>hjwtH&YEWvS$}2)q9tqPNntv=UDqa#5k{BP7sbyDBf0lnaLkVSuJ7mWS
z8sh~6`SZ{ILf|FDB<yYIN)Le#(ISEwv?of&HHa8A;a{f;B?^bV;5A)|BFCb2Kzw|A
zLh0t!V+u5Si_Rl3DR1e-%)Z~&X$QuSs4QJGXHc5fXf?P?B+9HFrK2*7Mn%uvn>T_{
zZz#+iInu%Oviony8Xg%x_L*o-W(w<9xvWoWdb)%654YKdMnyQohYX3(8y(q0I(hz7
z7AT&^6?qO4q6Oh|R-DSA!&ZM>EXFd9{WQA!<ob1o*XE_N2}}(CapQU>p7EGbShj5`
z+doFOdiwJ?j@t3+Ul^xa*dh?)Ghr?VU@mt>XO9JDofBL15TeFNC-E1Cy>&9Dhre+O
z(>)+;T5WERNKD&Q{4u`!Zb|>s%u^GLN=Un-`^;|fm7^9jwJuB2;U+x0+UzIU3LX7V
z`vF)3S{^wDX}`6}{7*`&Rmq<>M(B!ahB7ziwSVnBVR>wJsbna#rXwdLguR>Q?ZyZ;
zKGC;h6YI3AhYJ?Jvn|=LXe&u<OFYNy^~4@Pw73Iduyid$on7z3LRwr#%YI!F-R{G2
zK36XLS~wN|n<m_lyDsUc1(MH>1SzfMHQCH}bzYyp=egk7n5+`XP|4Dcp5UphV`o@2
z`;SB)7iUbWr+de1tbCG^6BuPuy!<-$vrbMuRwA<M@*mPE;Ps*Z1Pc;zX1eT)upSko
z)6UgB9H#iizH70My%oV_NvDjMmH1l0#htc{H5p?EG|h_NdMU>qFk@P&?R>wZ%N#u_
z%knCkCTb2cet}8$LU=PtoF}9CAkdjEx`ev!XBcg%3jb{=_bfJ6`}3|)XS!5)kxbTJ
z<JU!by9@49;Fr&n3ghV7YZ9f38S^l*0Jr!;jalRhxP*<KCkHl#Up{_+e)o)F!SRDb
z(?<5RC#wDV6Z&X#e$7zZ`I>uQ`i$S}D~|Gt_UZqKj_*4nE~v;es5G)JY_P;T(Z^kM
z>r9fS;}urvR6ZJW1ii)J%LFDn*Y(1jeYmg}lsZXL9MlmRq-G0$-JP1?kzi!s4pMg<
zx^tvwyf@RxSJ`}x5^F}v9%dNlV{HFRQO|c=eJ<yBN`$q&=mA_7L9|q2P$fD+q1#=j
z5ioeJ{o>Ap3qnXCNez8<dY;z1U-leFfa*7IZQj(@Q1zBUVG5ZpYU|c0olFrnXp5SE
z)6hSzXV?@bWp?j$4_2#|Gk)JNDO19F#uex_QjfvmInL4i&%?sYA|uPfhVeg-cIJc+
z_K;#+TKH!A9p@+Etc8!2qGi+lj&mfT*ggoAw+ACE6vl5G`ZBAlFG2t&@+#QEu5*0i
zK`_A%3MRp25M4$RMa90%a`j;PtN)<~p{-LpyUF%Z3EcDV3*7fNbaBt<hJ^{-hYw?P
zo!o2m1wyC!_r*?w$3Ui5(!pMMWcLEZq3mQbE><cGCKhcSeex>H`7ehwgv;F&YFkd<
zDdkM?kgb6pdX9Z&`oJMSEwNg|Q>G3adh;mM755wX;mj$i7BRU6qIe=kc6p{4;WmIl
z6V06JI@-brR~%fI9VEMOn;`<HS?>KP-f)n#L`AhDND$VU8ztp9!yoKg^+D@Y{;nhY
z&<j<Za7O>(dOKJpC?cAX38(gjmA9naQvPY$>vQK+*BnlpQ!-gtbN5@*wc4H)7_j@G
zA9F^ZaLR+f&e)XeR=s(A-9|NI=f9UFWLAnR@V?UaO~T^)SIH<3t!pu^0$({;|6i0<
zVAllS1v<SR4xM)`4Ge;*!RoWi<AF)!2_x?B6o(o<Mk$=~5a*7-GBSikqvWE#|FOZP
z_PIslV^d0c`KL;CpMT;}I^pHnJ<~%iF$z6v8G6#wi)F_1+j<ob8lST~(cMj<P<M=v
zkC@c2gmIdCe3z^lxw}tX&q1ECA?1vF+T5Y9%v;tgBiqs~eX1m#|0<=dDkP2n?R}23
zP0?ztYn<bT3Hr-oEnhCVE)B*ALZJiQgx&<Z1&b@z;3Q$eYDhAOOI%GnxW)Pc+$Tz|
zcV9QZxq1Hj<i-gT8k5%xzt?rgZ|!HBHhm^wYtp)j6V@iJpTDDd{+g6E6DF=rSu?+R
z$9%@@%KuDgTR2l8>}~d;JjfHf%Mg&8PV~f>82`S@iT$sHVEpNFGuZeRcRR79f#_Wu
z0F1vu_Vug%`P<Amz9yHs$VYqn_GKqNx%C;xe3;A6XUh1C{%Mc)K*MG+3fCrR$BHnW
zOj^hHNt^AR#-Dy-Gc-HRdv+T0+oKIp-o(7_+7Ru?$L>7()xz(D?YQYWr}oHth=(o3
zgXW?g5p0PhJUyLVoSyzitn29-lMVa{NeuQD(?z-9tYoJmiQ5|ZEvyDH3gRZU82@$d
zcXUn)K^CrE1>svC^iQl{NR-5UT)k!H$Uc3;>^aI%dr11E1=ZCHKbgI?YGh8ozJB4}
z6<MR_&zd=Z)S^j~*DjbeX+6WAu3b2D*4ES>BkZw7>MT`&PB|)l{It<!^Ov1kP*+{G
zB_(Y{ahOe+<~yt`d;FvkrB7X(JZI?8;@YXRhYZ09ImjYY`WpMPY|6i%Ta-O!FW8rp
zf`XC+@WoxfWInExu6G0<!amIC2Mw}K(sxCAJ)t!?xn{?W1>rC5A!5ZMo@K-Cl%U8E
zjv5*aErzY_nu@T|;{KfAS&<{##Mkh*_+PN8+`wS(pIIKqZ+^h@&oYx3;+aYOPp6k0
zSy+4j@VrTxYK>8gb6R;X>=@YRbV~OjYb<hasgI5g0D&5@x|UhN&*6W0z)ayc@(+mL
z%uE@x_;|z8qemE@2@{O`X@fa1@8Hu@cky2iHccF8&s0K2A#9w)SNb`1dw4<&yGbtg
z!J{zDu-7gn=vt4VKM3y;tOkmUey9Wdro=Zeq~|zW?^R>^j(%y}J0X$%MkV)&^)DXU
zw{*>rw3rw+ga5X+cw+yg0ddjn`P9&eF_UnKZ(&xLM|gHjVw88fJv@J4Oz6Pw)%^90
z$(qPnvhetkQ9To4as=746!qYy<fsI<FNLUIJk2TkGgpW&NK=p}cKvaeN28ZLjP?I>
zzT{|>R_E<K;4NFSudlWHu>s!RS}sH~|C?{;O8Am!txkbFYs$ksYp^R%W{I%*y)@Cs
z&(qh})7P*3Wrsb~B5~ud&#UGC>?ZjibKwj3(qWmA{Zja@AoL)ibEiL6Co_hIwtM05
zs59{Ez(8hSXec&0|F3s5q)+H&5y6f9H_dbtR~`xR37Dp?6JiLKg&oX<*f`fPx|R-|
zUz6c3Tn<CH$0Z)^!rA)&RcV{;&ZN(n?JJ}nv!X-Z3yGHbD%|>cO7Y69s4koNVYNl2
zQb%;xNPV^Zcl{EcN(f&1(f_Q)8Ofm$AL7%I`yswf<)LGvq|zux>#k;-lwL+jbW+bL
zjol+BOqkGPvXS|7RS4(LzXhGaHwsyS<fQCH%v=(_Ur0{2*GcMR1^9l!Qkf)^eNndf
z-)#d<C_MBv?2CKm*6i6+Gj~tnypo~wYloD~la86Ydrys!STb+^(4q6^i{nZ-XZ!=s
zSqkI&#8;fIyFHyBkU9?uv(CpZ`QXwIuKEZTnSpI)ox#B!R}txXq6-fmP%hh>{aDsc
zZtgQ-f(pg7G&Yd^TGoNIS*|ppuhLTHnCz<S9*-LnEJQzg<`~DnA9z=9w{?>}V>dh?
zf2NleXNEyHo*ymMAjXzUW{a{4<R{_2gPhcml|Mor@t<hLFtHqx9m5NE6~??hZ9(0P
zBh07LbARlRkNIPV<conLkGwW=5ZZr+jb)}vydcjfqOnK!gV-HihlgEb!%t$B<VpC@
zB-1+l6YQc#ab1dJm3%`9lM@-7TGl77$L}wM&q;PznH7_~oY)Ts?~5RlCQ&9cI{WXk
zV-nag{I@oq;K1dEgqYLixo~Gl@~5U}Kfko4sdCbm(6p-A-2+2XXFb*3DOtGU)O!sp
zKdhLzU|IK)5h?Y{(npkIDaX>=4{l1cC7rfMh`n6@#5h}>6eJNBO~PCe{t2f}{-=Ct
zwvR34cz;+Nb0{<W#~+?zf;p|XcmKC+-F^6ButuGEZ1s;n%wdDA8X?aw#g};rCdXFM
zVu#6*$r!_;1&m25w}jdqFOB!Hiw5bx=R)N8bhn8AMm`5}<M1URM~EY3UH5228(@GP
z@47~ViH^;uCk{Jw-iH!b4oQ%LuwH~q5YE#}RE&JiHkqQKAmmSh1>Fl2a()zZ-Ph>9
zt=-wH8~<@cZ(qI6W2%pQz`|2w6hSh@>k^s#{wH3>5V<r8fAjbk!m8CCIwn&l%Vcz(
zs_JBRm9|^QX11G5)`Ky6Y1#9BJ%&ZL|5@W{U?ehck3SZuLcBfXOH}tJFqiodp??yw
zf3wiPAnHv;=-m_dtsXit@GHdd7$esg;{T6+%4c=!*rj74Ux-O6TbVjGA!y_q^VW`;
znC2Y8f5P~U^YPNQm;GP*E9d{vn{`Y?^Sa^bS@YN;|Co|#&-ELyXi)#~0sK8r_c?6d
z|JH9|Jk!MS?7(=2Q8`WgU&iyXi@Oj(*An81^}gU0Iv0;Z94Cm(wU~S;GAKCnUkCfk
z$H%lIW6Ff(^F~h_8<sq(?}m~H|JREAM-K}RUA-W4NXdw?#Z#sZosbegczk9KJNLg0
zzij4XBi*rf?!bcNUQ<TI1{F((<fRV()?|{)dZdlsnB|sNG;nlEOicH(qTW56mR>pS
zwJxo|T?xKQk|?ed#k&&FS<F_!HoESci19&yN{|BXD?c<65CU#14(M7r{>61mVl3nH
z_|=Jri^%)?#p@B%aC3rTgqsumKOWwk5bTw()>z?|2ED{C9l5cmWW<d659#ko+a61|
zJS^WPz4a(v{^i5;(@&&deVBgkiS&C9(=Q-B5%vuH$gkquL>|GP2q(%Pp6YZ6mP<60
zIw9^8Zzu>#k>C)|nTsDgg%|(<-{a@Z#Ut;+H(=C}$gdW+C&+!g-Fj**{MPQAMYzdu
zJVd<7P%e$lln!^DKyStY^le=S(6`|L`d;DudHde{Snb=c<Dm*w8uQt%yu8W&k8U}T
z!ae-qq4bVBU5C>70N0`Pz0A+kQaY|d%z}LRN#b3CAV>gmr+Lg#S31VSO&kxwa9}*7
z#~#Y}@$|>X!_7??4_EoN$HvJ`F38=Le(n(+cDqPF!bM-w)J6Y^^!FrHV!8@W<};DL
zt9+Yeo|uj=?(8v<zAOElknS2k@lJvbc3eE?`RGo9a199mWrWT!?#a6e4sjD)JXQYh
zcNALn`qqEDr@+)141C?c-&SB5gVMnK_^($Mcngv{I$ZY_I`w<0sIS<vft(-et8h+L
zln=gfi1Pp5C7*vue<*)3U68-4e4F&6N99HOuJqH=%a5fC<Kjv`CzL0K@u6f{s1*N2
zm(CT0c$f?>tm_(<aB^5!LkM@nLc@JM`9wb1OBv?He84Apg(<z5v&=b9-*BYkSsvlZ
zoI}1V{j5-qPeyu#k5Dhs6aFacfn7F6Zo{oPd)Ms|2mUi0!I~g80e7_!Worx)y;}Ur
zgZnK8Mj6cLF}XU==DxaNd*;r%4Z^Y01J694*}P~yzkKfV!U5eS5_xUM?zv5m4(Sf(
z{}#yT#xwDIg`>Kqj3SW#WdeVeS@4v2T=(Rg%pXkPzWev)3#WF)xgnf06vrUhH3l-z
zhq8M-{XLoXv2<Y!{vUJi0UuSh{flRxb7m%;)R_d*CcXD$(t8C$5(ohT2_b~udzaoj
zf`A3FgIGaPv7j^o0k0zHwcu4zlv})4uLa0#-dcN~GjnE=0KfPC|Mz*9D`ZagoU`^m
zYp=cPck%Hj6d8v1VLZyOpH;5I9{YmbKabu2xF%KMUFkuPJyv@YGO&0A4z&$yzHnG7
zx}7mEJ`%Ac&?K=Y52uAl5AIm~6#dRVd3e58byX^<$gg_EOGn&z9`PDTVZB1Kg%9?O
z8-CF?i`dvBl4ZpSQ63>PRoTQmuCfAhKPph0>^jB-$-_|?!I6z*keg85#!52Kp|4H`
z0l$e(l2#0B+q!Z@wE;s-u?3ZNBa1TWG0o8X%8GM}My{{O*Le5WJG~g|HDTYr&kk>z
zz4XaxWIq|Xed-)J*0iUr-wY@<EtoC%mU$0uST?$D@aVx?6AmYI?8iXf5Xc!h`|8<2
zEo*083|WHjnB`h&a36rg$9*Ptuy=2N{kYBbw=LsOh`*@DFR)xcX>)yv<@#Bh>nAMN
z&q3}A>Syp=%@Yu}GdUEYcS+7;f)j`N8$7zJ8H7#AoUTR>%;>Ww_~^t8$&>j6HBUgM
z&&AcL?M>q#2TT}lmjUMDwCHt~0rV<~vL*m6EYH+!qvg|Tr?164pnd%lVxS6;WQGp0
z$p&+E-HgdWG)K-2TG+OM{&cwqz1eTv8eC(rn=mgc5;+Cd_$LXV4CJ++#@4>7)7q=A
zA6Ko}G!3pjAFp2fX&PK(e%-Rhz?YQW|5y3`A^f>^*N=;?c>VTkaF)zt_vhnJh;01r
zzrgiYc7J~TEMA8*Cj0hJ;&IJJ&{)!N2k>}2#-4>Jd|w&qh2RM_K_D7lh%Z1GIe6+a
zQDv~2S;y&bM~=|nh|7^jM&%y=Nzw(mT;B0w)S1Ko)@p)XJ|jb(C66vzUsqIAvuQ(Z
z0Xg^%j(z8S((@%EytYaVch@eQlM>`NYn>SGrdvpVqa`gzf1BBS_Hx_o+0DvaAzujj
z6107GzJLsp*Zw+NoBr(jF$wgpF0LP!w5sd4_I&&a39M4fc)UNqe$wVX_)hrsv-r+|
zzn^vR1wX(Xuz`J{2Eo=2R{R2>c*F9^I;gm@G%2aHEHSZ6a8Rm-sRMq->ykF9q$DY^
zw3K>*bATG)r$o2{k79c%O1v&D1}v#Spo71mDA{?A8wNe+;DBZ4Nv5d08J0RRZRDoh
z%^yJa#Ps&fxm!OtR7NM&jD+Ngnf=B<B1LbOLy`91(BHS-gft4%@1Zvz{O6a$&6P!a
zh6(AVkWleMJ6{`Edz3AM<u&fBteMUA;}Q^T8INns$Dfca?+V7_TJq~>mFpOrWcMG&
z?tff@`vYHMegx)V-eV4jO;#obLQr>QIhp@wIUHJzlEYyhY@fuz=ga8Fd2#yBLaj8e
z14v@cTJ3tc4m=4wdrH>TxlB%g>s(f!5`R>UH(SP^wi*AZW&CMnJZ+b2kNN$tYmdqF
zw6nZh<^I<-z%@t@*4wgk8a@L($5r=lXX{_VughlyACGzfAFt?QNPjz%FMRw7g&w>=
z(+~LgGZNSJ_;_3&KK@KM_rG965AqKme?gX;xSms)?hG*`p#Orbo8wvYfEKAl2eMAM
zPv$E&9`p~b!#22%@xC9WslZP$-2bh3MU_+vp6F^stvU_RTX-G?NIa%ttHqr()$lw^
zaJ44A(h+(+d6cETK5wA=)tRr-7DGo7rn;7>a$x&{_FTd9VCi*3M>Da>f|Yqk$9N~2
z&FPeNuHrNe@(w>E)V!n9BJc3=r)|a~@9^=bRcooXXU@p_G`=hK8FWULn`OXjSeLBa
z|GLK6!fTkTtK9#(1n_(c{VF@^f~?2$`{TRi^jxs=f@TpL50((T!xPf)Oc!POu#DGw
z^Xpb#(=1~1<>OB)yoUL+8k{d5Z`muLyDnn9$;Vsf%f=&b^6_WHE1Z7wK2~2GiMh}~
z&yUh)@_ga`jMw=1Pn7Y%n=2Xpn8%Csb2}dLNu_bR7Px;O`FbOH40sWF6Kj7)qA$m2
z=YH$D8d$dXkTdP-e?evL@+wP(lGz*}2tDswA-q+u-+K2d;VlNk7N``aE6v?i3yU*>
zzh|o|hG)-K)eFytUv_N3nqgrNiKL&yk%nj^a5kLBb%E7D>wtM4y3GexEe0gSLfHl;
zeHrg5Klpir;dz!LO!n&awDs<p!s4g6TY0uH>{bs0ooG!N24438;qn%<O}XuUlH2;X
zkHGadrn7K;>!hex_J**B?QK5(6!!t#{sYG6v%Ss7pAth=<8g2E@u%hS|AO%)jMw@2
z(_#o8Pup1ywle;@%%d5!o#i%1I^g-L6RwM}2l-wFdhmSb_dmmY4`3I;i=mKj2Jc3G
zCn_)mIs2J*N_y@((-}wwA5EoZA@F=OL*u*GDs3>CZG6+6*`Fu4q^4;W-m#wB9D4UE
zb6)d(^9%c$Z%u$)^L_K3I~Af!m}e!PV)@(#(57L}t93wiEZXXn1r-i`)WGnT{BFJj
zI<2;NO3C{+A5gN+g@!Itz-e};*J8;EPf~KyyUPym=-1sVL|%c~&QF<~10O4sbN8W~
z#yoam6v}CGgJ0*ih(j63QLK-T1TO%SqZ;@J?vr8OCt?11q(eV`9d$>L11K*Gfaf3>
zBl8^Q)uG$KlDhkUD=%Fr;(6&5P$|34OXqt>TEuiJ$drZkI4(ZU&n;m19=fqGKY)p0
z*F(rU91rux8v97htcB}8O7|)2Az*&HGX6&q&K>#wZ?p4;kH4gaY&Kj!FbquWI=}xV
z=_Si}_5IIi=F(w&yzq|d{%53CIt<nu<SnBIG;|y9uuhvqA`4~bqAg}YL}oD2>j-Mt
z+!?IK0NCi|=H%w}k{uKP8Rw0c>5NX80HnFi&CA`(ZGo^v4Gv&7o7rW0okq(r0gN};
z8i9txc_S6}Oa|06t4NLTG$DCC7<s@l)|!CHJ}!<f-WyqIzy$X5I%|ahdA<nnro3J2
zg)#i4n|l_p3$;|>H3R%z$bK~L<2<hD9PI2u`N?h5<Ff6DypLymBxYT*cP;A>zyp}a
ztBn6qYE|BytV8he7i{j2IupPD1+<TVo+8j8`T`F`!S(Oh6D|p#!oRqW%4h|9HhAPn
zBnU{^@xsC(7Ay>~88Imy+-~f|h0H-rB9rk7_z?_v1#M&Y0X{}SGQ-DMGq7KzxrdA6
z2N(PdAF9y{J_rmr%g_tP9+*DYikC5U^oAk1QjLdG*JuVCcm*xITacT_U`>DzF{;Y5
zQq+=>mop*LDdfru0@KqW^E|{;JZ38jpT@$Vu1Xdr*ww`d*N6+N4~p!jb^(?Y-#_}M
z*}0tx7to&LK4{cwud{QT`v^`cIx`!O=Qba2(NWoW)KU5P)3P6l-Jj`-eEfOYAIt8q
zb+C*-kM<3or?)TZOi*W^4lz)cJ*%~VAHdGImoSb7g9q^LWyB?&slgnS{AzCnDWdvh
zlJLfzBRHWc>p6_Xun}KkBqvURkVvwi2?Z#D8*>K_-25z<A1oY_v5QvI*vD}y++V2m
z2RkAZ@ccmbEB?Z;P{ER0#T|pPU2k;_igMM4#T%vd2M^)ZP0Rm!h|*UttXT17Hx+@;
zrdF@oSe}?#xps4T9J&RM9wh-M&ys|rM?04YR$XdZzPjn7&xWsgpjqLCy-e<dBu4oz
z%~a&RC^B1mAipk7<-7y30I?n-QF1d`aDiQibCA_pL}DcpUWe>5>;2L8=Ho9&YuNoG
zV6jAI5ApFA#7)Y0@i|5hoDWEkc!kr0^%IO9NQGh7)#LI0eEbQqgN;vu@&94>=i^U^
zyZHUV_lcMe@_2{&4yQT&klTUv8Igbvhxh+UJglO}dVjFtyS)De>-{x|!w`wt|15sD
z+j4)brHDi%Ja&KX*GBuPgy|t{Joo~5oCx>IB6cqF@t36E;d|_yWA}&AR-6aLY5<<<
zg!dr(0oVqy$9*8fAXfHdC-evU3^)OXbb$e3{uzyi5H%14`5Rmkyew!CNF&fL;9S9i
z<k}(Djqo5}hN^zV*J9S$)RFAe>vvjfNsbx}M^*JC#19_#r&3e$Cz5lO*Oka}jmPeA
zGh*ycw!Oh$!hNoT<?EoMS;nJZi;q7g$AN%;7>~XQKK_*AhhcFel!JWyX`B0_9OUCq
zE4~9Z9%I>j{5gnMWx{j${V~?S$Dfn^jVL!)GP%jepVtH_yf2Moa+8lgulVJ_m%-0v
zKK?r7z~a2XK9bL6KK{A}PES5x-FJ-Fa@abY(8eqG*Zhm^l_q{&1DXkr2j2XGjfd~U
zdY-^|7`s3EIq@7H#;?ogI2+IGFFyXPJRWtk2)3sIRRZpFTx#X_0U6N1_B8m$@w(ze
z!SU=qeEb=xFJ{kW<I%^#$6I_H?Ebh%`S=S`qiQ_T$;UJQ8}Mf)+-Ic5QX|c)47g*A
zV?D|lhLAl3iWvmUup|Ne)9|0KI8t3)6=_!`trTEMC$05V6+4nT*4h+GOJ%(13eP@2
z;5GCOM_B9ous&beF0%Jd+2BZpQr(B86Dr>@tJg=D0IS*OE`d8#?$3j*V|CoYHhQ6p
z5`H+(;D4G|L7t^K6r%;e_Olw!k1rc84Nth`$*T|pmGhOr+!3w#NwAo<AdQ+=tsspC
zui|k7Ck6WS#X8^G)cE<WTZPtcKpXqc>k_mv+1({7ttCFMcXn*7sk(T;x^mN9Asm?x
zOL`sV80L`N#S8&)Qk_U52X(<m1FH{qL#FgPOu<~D;7p2dm{R<5dY|5z*29NH@7?mk
ziDwrB1d4mcn_b{b(uz;2ha*y9)Q|}W);?<il@uJll=*^T7+7%|ETs6_L<zd$1>r3}
zs4>dj*XNn;*+6riKC?f&U^|WK{PqR3bODQV8sJEV*{@4fMg-IV^7uAi3V7u<keh!a
zt>I*{Jpac!0c?uim%}ca$J$OC_Cta^Z*Pn>Sm({2cQ@{Tk+>&xKUeX_Ct+W8iBy5I
zZkUYWsl{_2&)M6Tw7=<k^LkBC<01OR@u*?f@yvL&!fDCncCc!$fHlFShF<%d6_f8?
z@IK$z%aQ!FrB<vybJN|>KX;J?=Ir6;FW{T)LH!deNP%<)ynsx?NykmA2Hn8SLT;%r
ziskYM>6{D)kr5ZtQx}+*J>3R~!-CT>vFTL?4dKM0Ax71Yr_*`{Oi74U<8tUNupJ3+
zZ+aI%BINT0aY~iA1}wZb3O>g<6aeM+xTW1m8ry^+z9~(a+9(y6X_u1aF5srYUC5HI
zpia?#fqi0;A2Gy|fs8sAOFzRZKuifyBsTbYLoxM&xgDg}%_Yw)-Soniy(Ajk3Oi5t
z&hbkziEq59*JymFL7SFs^xEQQUt0Pmq=dALd+hlML&#q<++BxPe?pEFIHtM;-}*k-
zB|)eaJfB^=^f{LvD6)Bs2r*CsaTi;vY<Xx1GbSNv4v1oA=v{D7p6R0$E8YnV<>Gc$
zxY!LCir|oL{z{w(`n3hs7Yn=i8NoTv;yh%@DdF-tqCW1RYYAjRPn<vd^{_ERBeP}>
zn>4R^T3cM!sJb0>dA;}2|Mc3sWaaBGj~lTgw|f1GimZ=!53Cn_Ut6}QS5*J%w3^lt
zS@8fFGb$@?xYRE=vU>EQj{}}Md1Twp#dFT=ny_losLgL)_nSNp_dc9?GInhYwB!LY
zF{cNiQZQE_%rlKK8Pll2qstaj{dP6FTU#4aqD!0pK|B$#c4cg2T3STxDg>;hH!jsx
z`lVz^4F?h0b`iLIIyxGrz!4z0r^c@loYusr5CoKL?E5*qUTutL(5>%6JR*r~Cu>^4
zb}?csN5M*jR7j2p$Z}Fx-DNQ3gyF6*dU5?g(|Y(Qy+(g|`;dp!pZ?L@vT4h@L}x>=
zue;}<*Dn&kqpzLsSk&tW1XBD_c$$89>FWz8h?f_+^hEZoX&XX%lC?(v#k;=vh|Z!L
zS7&CdmUT&K70{xU&M<lDK+82xz}^Mjigb^utB4t{F4!QM8Z}RJfvnpFrl~ZeGq|qV
zrIVvO2p!!Z0pWdy&?d<Q^^ryJ0W%puzHxyF?Uo?T341kR4k_nDAPrNW^r-m3AGu$X
zEZ_}#$&{TiI3qG9BQMseKOkSa|D`#?KQX6yMrB$~UP_<bxQL39xE{ukh~dxsgdd2L
zBC`jKuFNgbcqEqgkIdHum%7s$eUD)3bZX?`wmlIsWhoVvam7N!yqG5*I!$i-Bwuse
zThtN-0StZy{Q+lCKbh`3pFy^Gz`n?;Ox|lPh?)q0Bp*qC*d9sU;RAQV6n=Y8H)m7V
zaKX9u@WMMuJU^uvKhu+}o-vV~R8Y@oBM?lGr_bDY_$oTVv|({il)%a>0l6A6+qOOA
zKC*S_)};-@8+X#wusokpoxs|tuC}z~@S>J}X^9%ZZF~Mt|HIQaH`L{oEu6fU{3-l5
z%Z*{>*`T)F+&pB{#0m7Tn_K1-qglhxSM6gUTOo34iGFk&;FC3Y2KeLY%V3P;<U6h~
z<LL}M2Mt9YTe#xNJL4wb0S4&Sf#$v`g)`G*>rBzHY5hw2ztB=g{`_{^!!0A<BDr^i
z1~St}o>=w9su?>1-3COZ<;3<)irze*^VyGL8u)ji76{Rnc;&TSXcl-0taLH$m(`Ei
zz#8}Mm9g%5GL_DKbh-G93evcv;Tq`=YXv8{@Fd(DvwnSe2)Bz$RoUF(2PPO@m_n%l
zMZ<m+o-~|d;K??DuakQHNgG-KV)>Loc-lY-!YOk&KF<(B!PFsFRkYCn1AC7s=MR7#
z2zh;$7)?}nn8*AjS?Z|SQD6%ubXVBp+L7-8gq8(k>)v6H#Xr`y%!-UFvtVzTpXdtt
z7~ds$*&rTeJEv~qPK@jBG$Hgv-U%J)1gd?O>D((!lK3-%gsJ9Y>MksW^Kk|K$%MTI
z9tjKoD4ug3Hc{~oM$nO6G7Yb@kca}K^oCyl28)-x&e+47M?w&aNN6Mf1ojY;<!A}S
zh>1hm?eC?2u!i8l#HvgXLZTL%uCcljX#N6C5#S8TCERg<no3$~Fl75;2R~ddsb4~U
zdO*R7)%3q9!+QGU#|b8#TUsssEh6HdX$F^`z4X4pQJ-X15TD4%KS+&_pR3L*s`_!V
zW-ooaY@}CqV4RSzbKm)SZ0v?&eYTrc=iI~Zp>wgZ9r@Wt51_B?_D?!3?5PG>vkQqr
z;zB^Ur^ETr;~gv%f+v6~y1)c!B<I|2uR~lyr=>?neM<jhjO#yeG(AI}IhC4fivX3G
zV2c2ihMzeC6hm*y&LL%p-XxY*I~8iRg#^%@Iz}Q2l$eVsP<Gc$hyrD~<|kve++IPe
znSTqS2rTvk2Q-WGsE%rDz*!aXk%2rd2-PvBS@p$D3bxoCkg9K<TRwPJSn>!9(3mF6
z4zQZbf5_*Pv8W)ZfA<^@egt4>$BOuN7c45;hOuivd=sDIV!gYFPRC?Kqr$v>1xMSD
z<#E~}Y3l@Lu4+Y%(F=Q0DEazIgaom)KXCgURlpmr;+l>*PS8dV0kw%ep!OBAdrM}<
zRywAb7C(|@+KKiLJo}*LF!<R}`{TBx-cwBh9B)jYf-MBQ1q2Vk`q@EyA1o`X4-7i0
z2KfH^`TXpNxKs~k=ZI`mL~IuQ-X85+Q(c>xqP<K%SA%|U3-IvnDdt8*m`coL_UPZJ
zccB0ELCGIH46wr$da*r6s0F{vo?3W?Y~Lszw+DgR5aVbIsMp~&*%>yZKB9*B5}yMy
zb?f$9fWB7xSxBTBTgWe5PdZiS3A%M6`ZIyUSdoFekLBHq`(182qpYo*$O8Q?EpaeY
zrp~h>iLQ^WC=lj(JFSb0NS?E0KmF<5*ABl+{Kk(<4Na_S^(Boi`okUX)0=I>5J!F3
zh%tTo)2VWLh-S+?Pv3|R<K)W5FFq!{uu>z^%h8z_ZtM;4iIRjYv6T2^?4(sR=CQ0C
zsB_2lrBgK<n5~C)yv+{5WdxywJJ@!u73ysk8nkZBhSP@FccV0bMi}5%(fi>UYdDJ9
z&|xt~V_v16#HRc8F>mZyzn255)vOKmMB*7rp?JC4;8S7#X-r!+0<3M{9qr}hEEsO}
zL(oE@f*cQum(kV+SAe?-X@~!5mNPpBVg%gVsl;m8Yp~?9$n1c;4EBP>dtzJjVGPkM
z?*cHsD}O}gJpjme;gV1lfH3-buJIo5*E0Hnr{R=RW}p&PKsSp+s=Y((njD41uOQ2H
znRm>fKrPOpdxVhFRH@E=bP`?aoP><B#7pxMoNfIahT!R|h<Z5L?tmq4r>g?iDVrP^
zb#NNvADju)kE)>MUrNnrcvKB7|6zIWuG)5he*1?F%zWc$JD7RB4b1!}7MS^PyCxqQ
zcR-tGww{7DFC#(7JjE=}3@GpqK`Rwh5G>C}3!m{F+O1f>05gP|9?*Tn=X~5f{F3kc
z$1_tWJ-TM#Gw<)1M1QJx^wf9-__=zPZ+c<xm5nn8JwGL@;DPDKt_S(K2lkBUy>`Kz
zeVaaw_KMGcd(sYiC8k~<K%O`Dn!5hV-UTOO^>G1Jb)#qOyS%w75O|Eo_hc+P#Ds{l
za6ekivT?)cVyYRu3m{ew2QXsg!vL=O3jfx7*NoWkz_8IntDl{h+)`iEGOV!7Llhki
zfqp)D17>d=HgRZrf1f2^_bwW<vf32k<lD>1*xX!Iw{3P~xzSG_-`E%z8lN;MC@3zB
z8uRmWD^^YH6YH-DNWQ-<J)x;=TUdw^%aVRUU!#aIE7<3dr*T|!4fIOO831+<%tSt)
zz}I8|_5oSNs8voaCZ70ui^q$yt2Q2On%KT!Q`_hR;n2#qxJgRLYK<@!WkkhfntzSY
zZ0|i`LhmW`N?Bawsf|)q!N&Hs%`;jip78#DNv!9s(c>CM_b`-2rDtejCe^l1=-qn)
zUth>U!}uw9?yNh2zi{+Rcp{)NhE%(P;<L>hF-F<r^4X`1jB@V^q>rF2$l}ZpS+vHP
zVJ$kvm#qRj(q0tap}~OBEAz?w9+)mnO)4x-nbo&q?(_rVgzj1m#JlOL2kqKcxu_s1
zxnNZDynSQZ6h0Is(9<EK%*M|RX~b4^LhjpEmJ4#?88eEK)ozgy3pt2kWp+syK*t=r
zaJ~X*C`KiePLZLGQ6HyE*;=7jPThL}q>h$rI~E6fmtpv%?2&A8DfuwDty5-q5qZDm
zK4HKp>vA=<Zj^4?#N07nu|k^#Xv^%>lI4PO(&A$+rHNdH=-i1RGcD6(-2mDZGn2Ag
zqUt^G+??TDP;8(2uuTz)j;8rwa+<Hk(Zyi$kGr>a4FJlX$F(&e9d$E}qj-_`FlEx8
zA6`mv1D^@g7G#Zx=S{)B0O?~TU*iZGnkfemA{FdN!$ceG$jnr=z9x<a4b9j5Uo<^R
z?u;pURBzGUm@Rfm`vAxlmX858NF3qaT7VKX520ojms^1WMDZstJWhm}jz;YRDIUH7
z#ecgxc=&6JHg8_^+VH_w|5hB}>yc7KrqqV?3P`*$sI_&_jl_UnA+=<RczbeK(wFqe
zr~6)S%*}0lecz{~;>)D4$)qT?u%V)I(=#-Ee{Sx6a_*T;l@$$zn1Tg#W`d56zGKkP
zP^*#8RmP6!DfBUf$(*Vj{2<ApMH~>HY4KCBodakgt>raKw!Zq|_MP5_h-kg1m_Mq%
zX?ESvr{166?5SN-UNa**qpC15x!}>syC$_JgbP1?{N!sB7pz@>R=5EO^;z*5;mLFR
z&s#dktUoYy$?tFdJfMLLYEGJ<Dac4HDoLKadvfa|i;-sdpEeF?MlBM&gGgByz9Z%&
z1TyWUPpZ19gEp?4rVd*xeBv|v7rVR1<mN>u1O>DVX?<xNnR4gu4uhr}GR8_dG10kE
z;YrPXD-W3W+w^#V96-$vKsSrO;Y#D_!J~(~BM5wE)LOjEI0waUht?!`y2CpE;NLSg
zDz_jywXAn}j?sMOj=+^<*O2EL3o4|S;)0CnQPH_#MtM%{&C7R&uoSO+nu2**Aj2?+
z0{9sHEF!u$urCFxAcB7_{0oW|t52}$Q$eQDZy{l*oQziWtDui|KyJ}jbc0RX3ZWdG
zE$MRa3iBuM$^0rduwXO*B@9C|#!7?i+<_kV)=dOndmsW_Eo{rnn3^Q`1-<@DBC3!z
zJ6<*zzNS~y@S0>9`U0C3j7|C+e5CU@&?d_9*Q8Qd1ISv%ygjIUS6&qEW?7At^_wW0
zWr5#GrAJ?;w;!6jKxvyirftH(xpVrr?$0gmMINPB&L4DvRvuGB-Rb@#OYggUYuARU
zGalp}liSNn?ptu^(9#F=VZtV5ajqI3+QrvJp$pDA#AyS=4{`~?ISyO|`2dL|%t&;&
zQ*j&H$w8^~*N5osmyg~)Lif9eic|GzE(g!kE9B8$#ku=i`_Gwsa6;RdKo8LT^5aLP
zKlt5-UANvQX$Bzx`i0T*3on|dhv^?!dg#!C`%22&HM#NeIlwD<be-5DK7>^kEY>4G
zUwJ&x1^jC{^1!_<(<-)Py5>dRN8cnHBNC!k?W!5H>Vew!?AQ_0TIQWxvwrThLv({z
zr0|h2WlE4Yoe=5z^y&?h=JnIG#AdZmEy`T9<oF9y$GegRUOoYgUmDG3u?^@z9R;v`
zLO7HtE(7BXnFv|bAsI|Pg@wYGC-alo<^?=Do9meWxi2R<*`-IIQ(Ri>nw>*O&mOjV
zacs+tvBeQ&BYpF}$UN6fU*V%jaj}mVT}gi!BP*Kkl+@LE`g!=YCJnBr**34fsHeYI
z+`!$Lkz|K=&=kUAIjyk21kFTFYaF&D!mjCQGTaaJlV*EO)}FiSvkogN35I|AWy{Uf
z(|N!3ym&ecHs6_=PJP$MA4X@VUlxVF>T=)p(qiEEbxZA<udiK(?r@X=kOScW{Eq~q
zH-sNhOcrszV!Y2!V4jEqsUH%sz61UK)vBW2<-^m$lB0@Taz>0T&pUG9Q(eIQ;&ktH
zubA|u^eG~o_%}Ipn11HgBO*0BEHA6sC2Q{3sUNMqkE}F0N9zjcqBW`c^tx`!TBHT^
z0458V-&c8s7E)lH<jO{c4qw=UV#9)|o5u}WkYbDqPIpS~H)@^v=Rp5aqE4Ug7G#`G
z-~DpiDH6PHX#ard{>Fr)8mFX%?brU^X7D9t^yG{n<0fqxB#QB8KMndft0HI5hW*d%
zF2$C_g}^`gM5ToD;tn9=>F)5kt!a%_!87iN%DqQPah%>5;h{%3Zsu1piC4j|;>YrF
zJT!pws$pObvQp#={GApeH`?}u58_q&>uYb&3r!*M%>A7^aAXrnJ`|d?VDgq-tDX}Y
z>CFopQt4kumqZv728(+J`(XcqbB+0xwC|eYrWNMVvGX2cyg?jppC|n_vk<Ed?NhcI
zzN9}wz&XdnXa;k9UjfGnzq4`PHX|+H5jZIDFx5A2?o;kS9QNKmFXHzjkOwid2%mK)
zcslX-2>Jw+nm-j4MTYXf0hO*f0<OZ}<ii+R2cKVp|A1I>Fe-}ngV8VGdj1H{IHoxQ
zy$5^2PYkD9OjZ<jZ*=N#QKl#FaR^=n<0T5flBR#hu%smMNhgNJd#jfW702^hoMvI(
zBsm0&2lc&9PqTbPIAa};VcsNpMZVt3Y*XNM-Cl@sM3Ptebw|*6fIg@*(>@2jkZ7!z
zxaV%5HsvoWy<dr^!5P8JU9`{Lxy<aNyLQC9Yn55Y5$w#{ealSnThnT-v)nfXvRBnr
zW_RoyqDFwa<0PGxQnRjFjL?~Pouj4R>}Gd$X3$#lj+2CUiT!Y@#dYwGUBK&HWIIpp
zA?3j=HWg;wKpdtk<6kMQ6W1y8qAQg!m$h36nQ!X{u<NICiABEbyNNt+S50E+vLf@M
zWBdP@7d4UKK!JmVg>9627mytwI+gMq9;|U}zcViy@6v4)JKWx(+OgoCx{>000)Es<
z{~P>xuM^ct%6sdQAD7*6o_FU((*K@j%J@-pL7pdMec$uGLp>7$^k8hmYh*enx6f^^
zTS}QQ-le&4#~DA2{g3Vv4ZHiid9A0aLsEC~GS<CC&OKbqa@*1Ij~EPcojd3qH(72w
zNNc<<=cL04A$-NggLcHOuRxjJ38UtM7{dLH7>{G)c@31M1`h6jo!!5`{9N$zAw4jj
z*WH6Qi}#nYtuR(Kj*TBIk1tV;H$lt|$43c(VdZcWz6Ui7f-~HYeNP()zsK*v@1-oL
z<HlOAEC*_N9@cg8?;qFHk#+EUb|1_4w^_b_Tzc5y75qKkr;G0^&qulsSiZm8@_ps`
z7ogVR%PziuOnUi_&p#$!vOXVmAy`LCZ#5RD;no`1zQ~Gjb}M-`qEWWo#A$L@HK9@I
zs>YkGy+So|cQx{ny02PK)@qGjXWiA1X3%KX>Tu1GXS!T-@g`ey<Q@3E_zPciz^Y(t
z&c5GZ`99#N2vM-6XMp#L_?iLl{RY41-$zW0)A)PwN51CZ54pnX_SV4t;azGod7T6J
z%${KND*O0#>09`h>GKdvnT%EPXfI=`$Gx|fmo0D9bXj->Gjb5r4D1liONOWJxz+p+
zdi@VdyLm__d&)pU4A<|W;k*-=Dkk1^9<#`bn2jRcJ_R@z!^E?Yvop}4h2e+7%w%^~
zltObPSbCtk+4PZ<VL_2OFlhi7B#Ie|%%;#mEt0QIr@2h*G-m*OeT93ZVTQ3Wdl#);
zwfM29QF{FlQkYq<?l9L?FS>2gPy<b~be<FF?xR)XiEzo?Topch#K^YRnV%TOW+fzK
zkAcZb_ATcUIyI*o@R*Z9%(rbsCl%DhheyOKGDM9%Vv#uv8wBfMAY%>qMvX&rfXOJ3
zL3mwNr(2*ag7N+2>y2bN@;}rYVXtnb4)nSPq6Emdv|YRoc8O94YQavy@s>K%DCkQF
z<B@NbdQ<$KrQQ^Nk9AY*_fYJ_o(KLIq>s##=?G{1-U$AOxhN9_$bez<0Zm@6-Dh}V
za_v5o#dxMWI5^D$yVegP1t2}G{w=Ft3-fzT5%wwPQ2NnzcDd86?mM)0xU<aje$e|(
z?~L%22bE0omowab0GRU7H;X2B*~WDZ{qxwld?DC9QVO@nsl4?$hp1#a3bP{$9sHqQ
zMXs1de;tZF#nH@tW1Vv7yPc5Zv2Hulbi98L^Xa;M4bk4ij2Olqvw!@-;)Zvnyq_-S
zqeKDZJa(pMF#V%b4!dq|_Y?Z*?rlE1o)4X>f<C%K`%mOuIL|qr0z`#?M~^FYoop{+
zjXmFstmci$>K}ExK)-HBSuOiJ0O<ydHB_51^}qsnt4L&ZlB5w`0Cr(;U(Y*ao9cE!
zw&}4M3(N-{y$)5z(+49eoxHuA=Rr4n&lQOkv7{}b!YRUOfw!a3&(U)^UTKemE6(%1
z9J^0L9d(4{nE!={IC3-OU@2OKo<k$a=PLZ1j#FJ{q@ul%LHkI>AZuh_2Z;E)_&TIw
z`tiAU=yOAZnXjWEr=e{KnQ}JFw0q*_ox6^T0N6~gy`4^<o0cCDk}yQm2Q&T(3?DY+
zm6_jrbNKG%x6E+|zu|HR&S{P(%JB=1DHv4X!{hjI9KYb0s_t>Et`6R5IK1m9;hc0I
z>5cDPbDB&?`N(w2U*Pw^-S~TP{_TG-o;cy)gS>+0I;)T5=lXGNi|SlQUg78ZanSL&
zoCl0nHvU1Gw@%38qd=bG_#^UlS&lNjqeZ4qCwwGve*~k8)s-S$a9zQq!to4~3g@E}
zE-L2&n+Mjp^6?kNPb}-DV|A<1{65md3jN|VcK<5*{;Kip{(SsJWqnbnV>m#3{6!h#
z3r+>$FuOn3y+4w1gWiSfRqXy8H|Qe;s|Bv_VfW|bFUsSu!u2c_&d@~#$B60bxISE0
zSFg`?c7Lv`Th<51v-|V$7nSo2=)cbH&&OX>;UVm0^kb|A*MB@;9}wmuyZ=CWeKyJO
z_mXBWyFVX)5%@`|e-+vN`S^?0nt7YL;g78E%cgGlBNaU>+5J)Xhxcp6X8``T)-hjH
z>XOa-)HU;f_0p5knPJ{%Q#1dg_#CGnFalIH@K($*7_Y8@|52&6qnn^UgU9(iG!m4T
za!)<i<aJTt$ut!Z`_vNVf@Fy>)>2c+L^soq>2vEAe!1z5x`xFS!v|+3SFJhSvv`)5
zQ&Hu#bz3L<Xtgf>So%`@#HTMV+}2dPU`@XP#DiXVV`r&g%o(@-=+d?^N%5wbK4l|4
zVjilB2%j~ud2ne_uYj<gB;M#hd~RLyQ%mNJuL>Is_{<=uUKOiB_sPN7j0P))yP{nV
z8iAgQq8(lRmZTV#qa;?-OV@8t9{%vyEh$-JGaG8-({sk}))x#(POlj~p<fTJ*2&N4
z@13>a(XGuh#|>&OEt>rKqP8NU4=)|MWKw1S$gt=rQ&O2*_>RijyyBeL7`?Awud^XF
zH5nzVTAxbr9@5C<29s-8Ck>VP@ZK#pFUmEh?*YyeyAJvuo=K3$*9YE9=PX3_X1a;T
z@`K0->8_ac!%i?wpQ=jw*UGAd9<#li4AILTc(rpjKW6fi<sFY6&5qJ}y^JY*1tion
zRQhmd*6{wfzEfxPOCgxdUp}p^?EKB!0X?F$=wCB`t7$_YDn#NzCt?Uy;Gx$d_kf!o
z)qSuC)Gfe)KIjVo)S{lDM9v6yQqi$6TBfFLYulK?L*>LCD@GziN5r%r^J{8+M8O?W
zeFnv5wD*~Gp>1<^j*{l{O{a$8egzxJ7@|f>q?>zBfQIg^nE!)0aF?VNn#Td(5wi+>
zh-4E>1K$}U*%}zlhHy*`i(+fdN@9S)cs7`{g5FQ0HA@a|m^6E6&9w6ao(X!@DgCX*
zyGU(it=JM$8XHc(tBTn)ysmZklo|I+-`=D@?)v<NY2zD)u9-4vSi$_t%^UhvMa2Y{
zj9A;;``7FJielZ0vu^!!aaBy;l*TcGr|f{kM{vjinKxJb9Q^fgRuUhLDjCw2Pzc$;
zyFi|R0EK0}#kus_D{su7+JDr`(+5oOdsUk@C;5S!i=Fz%rx^pkzw}Z`Zgq85f!KHZ
z2XiOSdpf~1X4A}+zHK8*;-dn6%9^SJ^Y_nhBOw7vvF6-4%`;jn6Jul0hCtpOB#i}~
zA2QZ7dL}|ZiQ-XhtCEb#n$j5Zs&9WnzBJbw-2|!%VVfmkc~f5DvK`xkhmN=akl)g4
za%}cipNuTF_nX8S;zKM~$_JhS{U`V{Y&2JVh&bal{lF`<pi}Qh@^o{4>HJ;WgIh+N
zwrl^Gkf!X}wG0b^pT+1aU}piW`%Q*H%g<u)5pdZ{$Eooxp?|;@E~^3eM2&B$U_PUs
zI)eE$@GJwLg>-@Yk)#WXA4$B<d>VMB;qQCiz5p`f6r2HyA87<T+xYhp&)&#>|Cx{?
z>ptr510J#b{c!8|+5GVP=nMJQGQaC=e)wFx&d(fsde4AfEwSfyO)q@UmR{h8FPKfr
zF)B`J^7!)@_AO$5V16LZ4?=FJhnl|?13|9%V?>Hc6-B7P`NQoG6eO$zlPovHz^!eg
zpO?i3^U0&I$W==ROAerBEH6B{2{Hka1+6jw<=I@ok;+7i)&99mVkx$P${(xpyV?__
znG3?~6`3ejV%8O)RQH66E_bd&Fi%lW0R3}o#dL_F2IE<SSqm6V=F-?UbJ3nqF<mWn
ztr1gO(*CNJutF~-T1qq2RDc{{ed(9NI)eZ9PT>@?w2Od=eXgW6Ai```?M~neBj}81
zgR^)!NEXb^?Bb;90<}ZItg^^L?M^5sKp2layR)V<rhz$Kee$rD-H#*=nr(m5bb)r@
zXmjoWi?i5Nn|2GV5!M?pjF0ZJ##M8}cHaDmw@VneOiMXbGqqb_UI<+c?Yz5b^u2Ju
zT^Dk5u}#}=OH=X{*yvknN^a8weC0~pzT|H9&A=r%S3|(A2?8rE8n_ao`$jzMGxRK)
zA4Z^yCw_!%6+EVT5lA2d&#{TP5GeKPLBiP4YS64*e05sy$CHACzoC~(2anETO=5Pt
zhlIFK__mbZCOv%%{fC>kPX6-E+cj+y4+jK9jmKJwyuf7*1I?{LCnRmYuw2?59SxOL
zH-pUYbX>@H*9xLU3e1bY`l_J1dV;aWhshqG7jUS9z{|s`C)pN?1bB2z#z37I$YfP3
ztUZS(@6Lf3>Kx!6yQKmknvX&Hm7z`~4KnYo8s9o(!;f*E&XTtuJ$K=Ymk$@ceeJ{<
z61;rE#-gpkp(8!r_4LC*?PJH#%Ok`_#GIJj_trlf6JnlSnLgMUcAkE=0=l!2vQJ4d
zF@Ew{$uAK%{6n|+8|%|kx6(BF1eck&<HdGqK2)j08e=9EP!2Hfi9~kE^A4#jx(>B;
z9PXXv=Oe{hpcq=xj{RnEzxtwv@%JrTbt)~Rx~S?=>`QA*reF5yuk@z<EiwTRDTY#j
zmI(RMaJA^_vNPLuxt{VnR=AqAr48}vxR!-|X@$u;#G?3QCh|Mz2B7aEwj@|THo<b)
zeaz*$Z4s&hz+(xXtFa=n4~;!g<O0ZkTiFREQV_t=OMX-%M9K|lWN=8J4{NzXG$o8r
z<5><0*3(CcDDNX=UyvBZHCGPk1?!o{-Zr@Bp{*JAM1$08uh^tbx2@P-dx}VhC9zms
zx~yp8*Yuh2v_ucXi}ZTg>t2rH$}da%xYOR|J~F;n67**g#|pkmp7GZaM+%6Od+fE2
z*U1_R`^A&#K&QnBuzw)Rq{vs)sNt0}`^-LJM&<zE+-{oNqpHiRHXz0*r(cK>MLCs2
zo4jUMCiE<IQFpyx;laD!&uYlg^RD+j%8Q0#*ZZXTkY6*hX?ti`U_g>ze9t0G$=_X`
z6xZyvySdy*N<zZ6l{F=#w{1%al>B4+Ok7!!m!EH>R@|n>c)cGa-pt-oTP=j7CMJ~o
z>&qckALo2KLfi&=A80H#bLNf6Z2YheN>Y$&HrsGE?Y^t~Cj?dd2iU2EG|E3TVsU(8
zMxq}hIS)v#^;llpXrmpPmkJse_kfm}^JJnJUxxwn)C2Ad%ZC?qofQO-8>UQ8p4My0
z>cyQ0-@9?h*>}~cn6UE!-evkgV`O3JTL+8tx7D{n-K1$+%N!6A;<1DDmJj6Ect<;8
z@hoxoE+Xr-#$g1QVW_cA(;RCu#ZD>Cr2k;_fW{_l5&z=AyO=TXTO|j82ap*(vTY3X
zC^0*|u;s|=bbachK|P-gc29Bh3JXX`UcDqSesFf~fB{X_Lm#{%tebbx<EsRXAQnqf
z5pi^mAYNL1&YSOK`$l+}diSnNjCh;vCCH=!3?szjOSjbP%lK80n8HEn_=ZP4UE#hi
zA**B=z)VFuu%jb-{Sl4+Md2^qz*W`Er7KAxh=lh#0U^B&5<v_Jc1d+C=pL$y{u@Re
zhX?>TSOkXx(Ag39Er(_MN5Vl1RnIIXmK%x=b~EFmj0sm?@F}Co%R>0jB2CFg*R0$Z
z;P|A$@Z{{pr_RwYaXvbq7pn&lw}z@@SFqZJ_X-n+pAQT?NB=YzzFScB?4));Np19t
zr)@ymyB}<Ogan`a5T)DSgWMuD1+w{01Ig1vj0X7FvEs~SdU<&8n)|q&0(&PwvmEMi
z(3iz!o(^PQhC`toqk$8HlZlxIsM#7(&M_#iC=m`nxtm**D8CRm5P7X6E(buUX><)8
zFSeI9o=?&)Ladd8V))3?#=m8y_@rj9{-re}AT7-pG2;S&vJg+~;znm1deR#J*z#b&
zeTV@1x1eMBB+?^93Jmg$(H49i^d7Bvqh^S&`5ULSg!$$_mL{ZWXi6c60)^unVZ0&>
z==U%k=yPbe9VJeKUMEJd8xoX^VmJq}la}o<XcXBtU_hXvH+xGW&=05JGzd@cUhs78
z^P3@XJ*>~N++~ks(C3acZIK%S6+ST5)Hf#OaktBnhe8qfvxR;WO5(PE2tn-7Z$iJB
z@h=m7X9e~EdbFLINp6y%hTbgR+r-X5z`uS=J_8|w$_qtMaRq4r+dzS4QK3hIqJ(*4
zzB1l9=pN!*hF9$YTIhAiM%6p{{Jr0RE7i+bQqQZb=zgO;LJOIQ+;UaMBQL-V9@-P4
zyaL1E?#*&jnEwOL5}7XVE-1wudVggnqb!j@0LU^W?c}uKpsjL$ORvAhGNKL|ESV)8
zhYaQmb_q~`Bj929DatohQ)Zw8FaV7?dF9#_;1i2R-;5&t(Z6I{j+=(U7lfRaFDOx}
za(N!Db_EprY?(B3)MHBh_43*trtpRkYbB7mk^YH*v?CY%IHj)g6)2H{nxC(>E2y*)
zy7-$B6B^oiNf5a%JV8<si1xO_yZ>G|8SPf6K}Z6fJ{%Dtl!%gz9}G2k79o-sx05eS
zlQf{bX<0)*#Tsd<sSm4<-jkKX(DlsM)g}o2tsyyjOzTR;*%g=2_sLsd(`y{fk6f{{
zI<PnPB@N=p_C-8YSw{py?oj91g|ODhA{jJdMbWUW^4yz}(Xdxt<@t4aZ>^7~GYEv!
z2E%D>k5`59P~8ceqZ)+s!BKJkJzQOb2aU2T@qFH<#M9GK;u+Q>m>?u7`K6avyi@=M
zp6`u<kEUVilLijl^J1{*MU1ZQ8PpMF0^ksVpcCPpz?r1vTX7sBosD|Q+gpPx*#_T2
zW^HbBiDFuGR7SGaae1XlLv%p<jV!~!`1+C;B6I6JUE*EapVsT2PVj3ZF@2BZC8di=
z(V6MdMLxpvG24Ma`j-L^U5QqZ5dR_qE_^Xa??TE9fB$<}B=R_L_7@-<Di9e3D{o}-
zm`2e>1rESr@JbPu)`x7*;d)3KL7x~uYr+f+rRNvY1k^66cJ9$f7+sx7-!)Z3mu%;S
zUb-r}6GTTT{U|iww_SnmiJ48DeWyKC-PUYg7q8byOK3HaJDV;H^;QsG+ylub?8HHS
z&T^IT+yVF=8bDqO^{atT<{Hq7_<oT3fX-IJ&&(bWAm>FSAYD-G+1BHTGP8*=BUN3F
zk;Ne7`FKlxHf0YuVK7{w|Ls(n^X8{|{X3KN$vykd9TWt<OX5@SKI+*X<-_Rx-%J+=
zk+o-mV)Gok>KyVu&ciX&-BBoWbSxt#ANuEsP>&}3MC0i%I1lvufxgZBLb$Irvg=xw
zk&3Gr=EM&AQ1~^JcA=67TciM{&3Y1|p%n;FCYj>ROUvmEyXJGL9xmSch+4svm{MP!
z6t4^0)eJrAo}5-YrK;?}++D(#huZUdfUl~tEh8Z|Yvi<w{5hG02~Fexly|)tkUnQX
zc0p!J<-k#?1#|k1Yp9)eSzFwn(=PP~{?`N2yB#JS6Gk91u_3FiM;;K%-nWrJN!`QH
zq0}+!ut(9GwgQK(oAudBbpvP#{J^mBWPtv_g?A=A`=^sk?BPR6HlyR^{DJG6hqQ9(
zM?O47zsAQ3H>|CZ-a9#RU1?PlEer`?x~?7fzJlku2Qv55ardK#1-wO`c-*4eDI3H1
zTJDbQX<L5Z**m28gQPxo75ATZM)^d!ggn&_JO$BM<)pCL5VFO<Vpj?)iS1yR&uf{6
zR(b6MT>wLpFTfZFygg=#_X}+yCX(73iq^QEK|wNp(2AqrxiQSj<$eP0BE%iZS=MH0
z0JG97Ema43r(9<eN6neCI3cEYPHKAZ&4U}4uC}4*@E7xDWfl&3-xxY(a5M2<Fm#~f
z^tt}y=cFuOvfGBX;q)v$2?<@})9E+P6&M4<^Rq%i{6vnws=>-|BuX7XLU!$RXsX%u
zi3u!J)QMkdi=U8e@2k7f8yQHj>!8JHf&9J%u<N3D^^gs(AQ8THX)%naI#H%cupl-t
zij+<D#DsSd$I1K;^?9zbf_Zj~vvT&aQ^dHE1R-19ddYT+@%`OpP9|_Tv-enVgb}B}
z(dfi!tJj_SWO7(957%L*b~P25pUoIK_LZZ{7QW*4cuLHo;#7frdV1TAxAKB|27a|=
z%!j7eW-QpbWhT+q7@(=;9iI9BTOKHXrlwMQ6uhMsxMP4dK+D7C<2?woAUUg`H3Hii
zy<ajjd&ArTD}<G&0WZNPJ;dy||4UQZR`iV4%`N=%1<O|*dvRQVk^Efuxa{fbHU8@Z
zi+{@rigTVF8dQ}M7M5b35=QmaJM#(;ia~`#Zv{*W2#on->+utt?q3|*!y`h7+s1a9
zA^n4y#H+X^Y;D+EJ}%W^DJgX8>XGJ4GeSqezAu1%pAP#E{9q~#4C1Bg?Z+4&MKY4j
zCII}$Kj97)(?chJwtecl`qFXDIYlelHd^Yhl4{SsukWvK9OOH|_iwk)HM)2N+z!ck
zJHOAGk!9I_`rP873vv@Il~~8#(r20U=dXSR0XvjQUDAfK5;~>8O0z|U_2ZxTDyw7$
z_aTYt>!xo1Y;tIThfCwR+kXQ(1~mdj@1Lzra!L=5GNvpTG;U+tilUt6ai#TtuIZEi
zc20<Y;8$1A>rGkuw~i$_)g&bt`$q>P<SrOmoU8ZC2E|CGO(Vej2ZWL?-adM-lv5bR
z=)I7PD{03W8bM}=r&2kAcc061qfe=M#L5|OX7rIKFtYnu7JjAX6D9+JKkf(qzz$G0
z9Kz2mzQ`zz)o(+6dW-jOn7-rmip7hTpR}y=9_xF^&l&N;<k2l-UcCM1>c068Y(9H>
z<96#>58<z&IXz|deJ{PbXgyndW*b(64gp#n3A49aWm_;K&0+@%)u(N3zsr}I<#$>T
z%=g=yd(+DH$;RGxc$naj3cY7yLGGq9kA#nn+y#^++$D;!9Kt|36i6faSO<T%dNndN
zu@(tzrn76BT4FLM<ZUF=X6%2D-dMlp<e}kQ68{3Rk8Okcl-8{q`-)l+hnqi6&7Ino
z5i^|hCXYP+Akn;gV#U(^qy*)0hu43m4jZv*=7T$Ct$z~NiqS9bhqW>?|HB<AM*T~)
zBUjwtC6&W!`$pF%ZB)@XvrD>68I8xx&)X7(*m~bd8RDC)b7f>2=%BEyQNTYIk;Arv
zH(o_+0^<QPU;>yJmQ-{pBgZLIA5dC%>dJ$=c0Ty!j)m1O9{$7_pmXdw@V%O{@4m07
zADUmTb)S@-+q!-$1S?4LFF}3B-@oO|sjWLE5AP8|pYIhIUGq-RNP3Z8Y!42Ptsdy-
zXvot@DBt1iM_VDD#a*;I(Pl?8Ka<)l=!I5J6t@b1L`-e~xdhNjedg5uInq$lr*g{3
z(!Q1YvGhc6bkFKJgPp&gZ~okE^zzJ#p>$E2bN`*gt8)R~XAl$_m%oy>Wz3|a{N&8m
zVQb=^5h}9Xon>3Vl_rsuhF(Jn7z4Lv_M2{a<d4bKO$nG@%FiV68qmy8W58xZs%4KV
zQJF9XZ<Ptd@-To@@mgM7ujEg6efiFMdNp$D+(DYFYaKs&+iCWyG%#2moj$$9G(j9>
z^v<Jyyu9G-yNlM4d1;)eBv%*u_v<d+b@;L4j{#ezwPZmRAL^8_hU0)9)OIzVVeTXh
z!0+xAn-FvwX&k+P9S!N1&tQR2kXNC>*ab2wZ8iu~o2QZ-@_QBcNka{g`3A<S$(AVZ
zD6n$5pSmLu`yS$20d1J?1p68y>v9B;sVCjnGl6vOq@*)IS1X=hmjv1>>i5u~alf6y
zzQfv|k*z88mIAsVJ5upHDgHVx`MT{b)$Ihj?ltAR>U0#WxhDhyx|)K0T-?%jO1<D>
zS93YRc-0jcHk0}HAU8nqgaC<pZ;<Gy&*Hw%&~vD@FqJeX)0A$3CqGQ{>uc!^_~C~!
zh87b0q1BuBDcyt^Z|v>6dF7K)WseN>aRnC#MbQp<De2Io<~5LwT5&q#iL~3d1y^wo
z+CUIW>ptH)jL9Ul5L43x*P>8*EvU%F+e6pn3VDUC$%Ub$S5Tp=x2HDC+gKqq5sjvR
zcsqFu?|VCW72pT0Q;0b`Rzg0+b$A7A4D33=^h5^KW?2C4{=w&A1|+bcY^-|ffn9}H
z`uY^*`S-NooVp~qwnYZlHioh5ek|`KBDA(qxIV}$+lkiOV4mLa92o?c9Z3gIKk2yc
zITDru<OtIA4bT*h=u?CxpxY4?!g$U?Obo|gK`(^x4gJ<ak8`4H8@*JS+g{E{Awjg!
zEg`+2xG7!`=w2IYT3^qrZ4$g>Qs$LqmDE)B1VV6)K#mAUfgbR_T6kVr2T({&nNexN
zQG{-)Dr3*tK044{$k;W#uC=c3D$Ndl&l?Y1TVI5Q?0CO*tlvs0YBUl*ci170I|yYX
zTW<mkz}*0LljrUN=zIYh9tPq89`BzgEoShlK{dNpMI|6w#7pzzb8XgwQ760<32+mK
zrp@hr+-$Lp=S|wM`e|1Hi|{j!p#bmYs}%_{uF$4b=$bDCAmW7U_^Esjw|~;U39=P3
zlw@Ro&ON9A|9^u3t9_GR9QElf1^~OKq7V>ZqoZvRVB^DV5nv&3Xomnhu;y`ufF--D
zo%lBNE~ah>0ZX<b1gzb)jR*m&Tr(fz5U~9HD|3Z&M2pG-%P07MWUhGrtoY{R;n_L=
z2h;5cmZ!_+TdmcDT!N^Wh2NQ_2n+`t>Ms|mspaHd4lfoFVGb_v{)KpI^|lHzG#9LK
zg~;z6UMNXmyztCu65gfgAGMNBQNL31E52qrL;XsH0-R$RLkFHg@f={eS<-TtE1<@9
zc@8Tt8e|_@RBZZu1HyDTmhN&@_3)rN+nL4tk3h;v_%o;j@Y>+%<5rnx*y;UZtwI_-
z!ODZVoT%3H1==u2gnOpIq1x^Fs;n^(g*7+8oJg~#FAtz}+rLqXr6|!8;k&!^Z#4H(
zLMlijSY=YK_z1+d9SEYThJ_{(h~z2fCwBnLT`;*9Udr7a<msX@KehX5PmgDIIR{Q7
zE&(3o*6t^Le4Y?n2b&GSJ+z{adF()vF9E2*K;f__(d7G@#|eQAa0Ol)=8J({i1mJM
z;K>cf^#O0DV*2QHvf8fGD3z1qbqh@HsSRrm37HL#JXxP22=(R{g^U4vpQ%qIXD!IM
zyLW6kFnHbOLC=)D+Pq~Cgeu`o0-Hgz0&E6Le@KNf@Kl80wz@qN+YD)*Va!(Wlv}Kr
zEJ<nHn9!^!HJ=MDt;oK7|HcjXf115LRPas6_DaisWL~(V>%_JIznmPuz!4LD!k4^I
zoDyVS=x=PVDtY%<Y30LY9Np>O<AE*5Pi%cKgdTq&C0pYdOizXcw9rk>0Y>^_uxpj+
z`DX=Tbd)KyoqkQvP6)?2G~E7&#w30RJ+>ihgmaV_CaCNlYg;e5YKvKy%qf5#1dVCv
z*!@2QXam3BKW^yzumAF|BWK^5HUH$P1+(98Pm4|-(UK6E+WtPdcxdxe#GU@~)aFBf
z-@ReegI7<l-n3=S8QRd^Z%Xd>In$@-e4jhDrd@uIbgDF4lL8dwV$28Lqg{hycrJv%
z;ng~rxYLChIoRt2qX%&OVeVfPBF%tkh659H0BJV;_XjRL(tInv@{Bx%O27y7Kg8{P
zn`@%;sYuVSDtyy=xSU(N>QG7jj>l_FwC|(+@`~!n2Z!mu44<pdzRwNB`_<Qo(f?u_
zSK~xDkW(-E-M{7OV=Xg!bvzWfs`<9q9yn*%JI6-MfeFFce)}hguRVnMFV>DX$Rb>L
z!0C>f16Ii~0F*S=Vt`jDh$8)zMaty3+L}s}T|f<jX)HdLBS+FUOxa1AtYI`fvRnwR
zt4s&PHvezYAy6wF9YHEO0CVIASP!h<u*fhxLS^}M=Veg|GVup4$m$P3EV0`avX^Eg
z?8C6gZkDTKmqn1FPS(caqAYI-=)<!e)iADs<r2GqsO1O%qs$Tr?ec}$M?c}6nH{Zb
zC4Q+2d-AiF(SiCndUaKFs1^fOjjy3i>_|<BvJiaHx`@Ie9eb4ph~<%Uv5$%vSQ8K$
zKf(FKVlp<Qz$WXwB*5jMfB$6hFWE6Kv*N@+YlE&d>nf19(dcA+OQ%|%2~2`rqB3OV
zg1KT~AHmGIGaD;=&>t-P<XM*+`9ev3{6IriTm}cf9nO$(+g;;bK*9*x5}ikZ*gU>|
zR1eIcYhhrx9f#V$8fUUysskR)LtnbZ3!Mk9Gu|u&4l_oFYz?w^FK23j{86I*cn}cy
zMkugMTB=kR9ap-ry!egBB&Urf>3>ZxDef`YS(2RAlP@;R*m!+(jJK<klW$I<-pO6k
z2hd0VJ37Maq2KSzPe{qmnC=wrbcnv~1vVSA*Ss9Pg_EAneo{eB`JA04(KQj(**R^|
zUb()4?hW@K`Wo(em<OE2b>i!M9?YqwoP!`3WyAqi*v3!gR7*AuayfXhamLKZgOC8u
z97U8=7oeBio%D%0zD`cA-Z7)EZ=A7#Myz*|B<I0BirLIII!TYcQCz;TG%lJx`ujs(
z5u^Vr28Q_NdPTS8WLHPjM3?NGQ=U^G`8j(EC%qlL2u?}>W0byq2xdAxBReI*{P0`!
zwIFvcyTIN;Y-dEA;*2iGm$}SPF+Xw~o=nW41e3LR@Zeo^liVr%n<1mA*<}5ohF-o-
z5vJ;uV~Tozy~Ky-bIu-+=fm?kJ<1A)VLoT_JPTgh%W6&<*}8=sRB}1*PY%#vE+=oV
z**TXJ_P7I`E8efU3Nc5RpY6WlyPCUnWouA&<cjxO(1O+e5K|)iq^Y&^Wx185a^Q?^
z7$==p_LlNoIg{HWS^!W3JBs;+vAtz+Df8zeyd3B<=mB9HTt&yNTl@Ce(qg%yqUX;t
z^9yCa+tT!Bnb4nK!#&UF0yzWg!R-wtZvc7LX1B9<&AC9lpKb6&lX|;bKK;rzxbOg?
zTU$50dA#zO?H31H0r=ZjLB6qgI6TR+Bp_KJh5~vdI1S~j2Jkkp1;CJ+;$9VxXU0Tj
z6d5C0vl67H;>@h#@B^dUHf?C1*u)mb{Oh182*2H)8Lz300S|4Np$EK@TcbT=mwfMi
zVq(jT&28-)3nT_he{+04gx_whWpYsNUkoUd=$C;oy)gsQCc{F(>ayfgz^)ZO-c+3{
zWY7;u3brUlFGO|4VX{)QVag+99W3)Tdc`XRQKM^XR+<mW`>R@Xgu0jz<Ui#gQGp1m
zGqOZSI6;;-_O}+nC?^Xy7)GoV-%~1II&zfr1RewO$Q5vdcENj%VBRI!uO`Qd8C#*V
zA5-Ow$`5H8m?Ru7xTB?AA6k)<FJBHr>|}BjE|J_1=_9l_Ja+QJszPw&yoRQe44C|4
z*^1GA9?Zw~Ah)RK_HXyl>(dj{C$`|aRsl`!AnPIfgM<Nl$z}sLO?+hq(jript|_^{
zypR6<<VpJXeJ>BJ@_(ews5dq2+0$Us8`~c7uNo*;?!J1Geh1whuI_GdbWG2g(dYiZ
zv~1bZ@|XMj%*aW1bj0U^uTPo}ve~3wbC^CxG1V_rR=ibb9r7e&JZb(S)|?9vk84Ft
ziy54naPvTOO}E{+o`O`E=K<$<Ku$qPUK4$&Yor5q&O@x>5b^`Jfg!x<LQs|FUQkGC
zMFLRSHc5Tv4kAC!@A$%P^y<{|VVkmu!6PuxgJk%{`_@CgP-YKdg852_7t0qaBO8S`
zqNB}@d2Tw`=C}@^Q)vDL&w_P;XC=cC1n=GjZ=D7Y!y}1(RzDm=)&>Z0C?sh9wb}I3
zBJtvDksg8VbIZv$OI$7;cV4tJrEKu><PP_M0QWCH>(MK~6H>$D3{{xJl<Vv$)S7RO
z^9W!mP1!EN!T|G?0IxO?KZ`4cqd??dp(Qri?2_pYq{?fe>5ow>*)L$bCXjZ)UW!d_
z2<%hKB0<L0&A;+|t4-NtUZ?CVQjD2dEW^rM7-;^toMKf*){0y0QnEUJ#cV9Te&8dP
z7J`o$B^G4GvCSf@Cl+uHkWjH8we`TpauS?3I2C2<d*SLV`kmHgO>y*pVv1codT0l`
zNc4l?8eO>ixEC9X1Nt}-@t^Jk7iada6I=V!HcEY5xYyWQ=SiH%iTHd;Q((}#LN@te
zU$<EJ#NI2!T3&>G#q?G#Q}Rg{m8iJ2Ak1fTpi3`;D2GGX{DfU0g83B&oNS7;oYwRU
z5bSW?j<G34=(q;($#m*O<xmFMlW|)sJ_7XcK9wNl5TOZt*j<sN<nthH;v;j%t>}|F
z46=DBI7)>&6_~U6l^;Hz3+X(A-py%kY9rqF)mGH+hh!c*T1Y-5@%)?*)-3Q5!wCX9
zK)Jn}uh)W`1DgSAlDqclS`mQn;KXH!zbbbvtVbi9b#sA^csbL89d2;qSv4lL+u4Q`
zkWt*OhA7?KF$v*G#^}|@=MJCN-ZbmLQV+%1Y){xHlMjrjtZVK)@?h_$=C;iB95ZNs
zX7QA%l||3wWOG-u4V84u3n^L6O-YfkW)N5Zf2xK=p@&tM!<t#N1UW1$pIBU2>e0lv
zDx!L^9*bAn>bK<=AAGB{Fwz*PFY^vK9~N_Jm9H~kT5sKSW=_jA>2)kyY1Y&khtj{&
zuZ9`5bXJkKJM+OiMtcLStk2RF2T!kGn_0}|Kp6PH>NTtQeq*(g>M)$8!UpX_7RW+b
z5Q%y|GFLtQ1|NE7!pMo!^dIobEQFCL5(b2k^=iWCQ$QHXOFEh5??EWo>NDo&mW_zS
zjnB__{3R6GjsN<qWfR9Q`&J2H?A}qE9S~xwogn8OErk4`f1dcypQnDY1S@`f>Dc0R
zj}E>M(~D$ZptKoqLR_H27SDD0P=`D@2e~kmxrK0hvnpV&K<cH<^vJbq^a!cAc8yd#
zIbi&`bK?i_zv(~9latHwKf%{B0!F{L_W9@6zQ_OOzb^-0B-mZzW!PH*ph?2{#w<v%
zvr<x7Bm`9)tF_3hdYHXsX+w{8R;GA)>d2+$m$Qe7g8LdFdf~`f=SP*)oEuyJZiLq-
z!<Iy(n;PjqydsV@FYcILU7Rn3NzTG?FKvLfAiHGJwtRhdF&SPp5{$ufW9Y8B>^%B(
zklSSB6|B|yQG6KeDV9TH(fB~CP-j_LSE_T0mH6=D6{mMh-(X3wI=OsN&FIN5jL6AX
zrB}T;riFZZcJl-IeOIfptF~`E@zQ;(Q_`E|<f`?HfF{(3zSRtbI5Hqm+1o%Ul<*IV
z9h<}p%aPVOV?#DhGy^T(2WS`W*fXkkO><4f4?kA+Z!D<MdOnrYw&1bY0-wOrx-*v^
zdi=46E^c37-#6TRqh~;Lzd`Al!J`4i<)hKTp)s{JeolTxP~(;Mk6tws*KhgwFI(4-
zzs)*`v$^1zoC|02K;V75xGmFW(HVaCXf9~?YWOT`kQbD$+`<rOEnVaW4ec7>xE`!=
zUSDXWzpyLXfi7T+HzyPZ6BlEln}>&Xkc)=wlP|f3z$H)ZKvzlQyiSe;dy*#lw5O9d
zv%`tE&Rh7vTPL6Kj$ZTwlHn-_iosYn!v}9v-b9x76vtxbVJtH1!(}1tV~Cntta8*=
zWw(?k=<}AdLn($yD&7Aq50WezdXObTJxkB-sGd`hS-MB+NGdB&Oeib4d4CL#knAZ;
z6#m6CqB{CbN$43jw<s!<$(stP0QOui@Q=pRMp*@22f=<-87JQ0I!2BH?Goi+XjCYu
z-6*w9QUN_rKTgV@xuU3M<=PkA>Ced#@il|n3ikEAy~f2Y*-$laM#KqcKfUY71j9&(
zw2ABKt(dq}mU^O{xYk?nA&X1(J$bM+Es{Pp^GceB5<Mj&Fy#YWvMf#_&ITSqo8JyM
z8rhoRsHt8#a}Jxt+3_7exq7<m&~xOxt|*3tgcZAcd+VmUX<Zz{mpxpZ=7qt4eB!P3
zftTp$$=pRgPG08BAV*DI(Zg*2gKv}N?xt{*0M!A;7ePL_P(HHuQ>YX0Bx88B1}i{~
zq6K8C(s;Y7r&s5Ywbqu029?y?W|7@I)MW|1oJDr)vVGY+te<iQGy6#ZtW5M)SOVkt
zS~Iyx$$sp%zV!Tgb%p7L3wNk7U0$|bU1Ykc?2WFgOs%vrze*SSfkG_u9zTs0Vu2?W
z>#mcYaN&YlQ#gPA4!Xh{Wt-Gz^7gXjDs6$|M9hW!g;3B!0dWNQ&n{UTcLrGDETI5b
z(gd|9V9US`iINov%K@sL8%Z6k)ev%exv)3VOIFrbF@>3IS7&k~l3{1mLdYm^_hYI%
z`53yP&^bL^hj-5Brt7r3fc7$!u6NU*Wp=*9>_GSERNbN7)t#=rCMm-%O`RpvTQVp*
zma1pjWj;k<$Vkev>Pxy@06C>XV>fRJ?HBEPFmJ>!$aAQ{Q_^C?gxz6+X<*Fo>Th^^
z5#TR^PBozRbb5{NS<IY8-Mme-b?8n0Hiav)(bKU>J!7j0)aB&x?UH=*z5H@#F{`M;
zZmKBDp|)TM_@h`ZGq)Z2>5o4vUDKdYQ0}P4q03|~k_&drHUfdwjo()@1pK~(Dq_-N
z+&%q`ehH;EUFo*mlLMF)^b@abbyeZ|#PIMG?{K@ub-!iZvl|#~R618<0{>%n7rDK7
zw&JW*kwaEFsa_6Q=^=>GiEmkB>c&Mp=A>n^&&hsC+OTEHkOq~T*4}OW;~CZ5nEUqD
z74n1mg=;e>p-u_>3E1rsaH7b(3FK<gz($0fE?*nUJlT_FV-a|I1QW#qXTn=^VeXXs
z<cgX@gS5#xBQ4Zpo4ip$ZuVtAl3ZmIY8*YdMO9^!e{g)&K-DzB6Mb!c-k#nzl{Wy&
zLC+5tl+qi7L}mI#wKfRe%~-WP1KcIYaqo}=1FWlPeHb-DI6izih&Tj3bj2iMOT<Eq
z5XCk|U^0oPHpn)4q*KlYXds{IJl?1;dNVA$+AF}T$Pl`3-`Yh-+J{XmPf9E)OlsVC
zh$QfYlP<GlAR}gKq>nWt6*6LcUCc$kK1m`g#U!p?Il?<-XI~jVBEd8Sb+O((<KEkJ
z4pL@#z6|bF=u3|B*a2FZ0*j(`$+HAO#lm9*-M5gR$8~sl!rgC6sUI!dRzD;o;(d(M
zvjjB{Kz12;_b?2-+)Gp^sNKAj?NNOEuHhHtU5JyV!5n&lcZh3a@P=4Stn)DlmYS3n
z*%57_&gQ5)FdL6H+blWDnKu7vI+W{QAm4u0#6gY`Y#nezu`Vy*V1+GXlNa3!y1C0L
zY9uH(Jf}M{it!KRHvI2=P4n}#;u{8oui=x=@o)N5;Jmqm#2+BF`ppQ-k8eB07~?U|
z`hPN3x<;nZfzi=q7F`d2UstlRo!lwpx|i5|EbGxD+Tevr<7S8doo~TA+u+bs69V}R
z-rT~65HLzT{0AD4fszVGf9GqOkf7jOKLiCQNIAidTJ_K3^ze9+MNh}akiF3m-n<oW
z`&pI&6`EX#U*y1Bv*wR8mbVW~@g2@~0Pc3C<^k)VhN{Vxv&gSnyqGL<b;nHdV#Sro
zBh~cb?z73!_foA520E*NPHQ|zPIv#GkgLit&<69&0ha%M7s_oTLai%_k!8c*%N(pJ
z7$9?_g;KFio5r$}m|T$sCulL~xw2FDal?Y_F?oV;fnS=$w!OhUpESB9xcf{RmTS_w
zjoTa8^T`mm6gSTTr;Ho@wtl}zC}lt`P9bE-#)`s$^ml`cuLcc!1aA?(FA+(RCykl<
z1w9y{vC!iUXduw}2<6<}=mAQ2jy{Mz`~sFY-<7x>ld}>s>T82t-AW>Y?@r~EwzWNj
z)2l1P3_?L#*@rT*C}(bOA;Ba=^9%UFB9Ie6zQ~>~YmE|?cwt;uk#-~_D=IQ8D>5pp
zpm=meX4!y-$e@5p*?!qXr+FkiH7zVGHMyg#xuhx}te{Vy7=zPGLVlV~6p9gdDOxBI
z8YR?GnGXjh4M#tyUxrYg90JiC7L$-4W?~7TdZDql*0V7oyh@CZt4v+i^Hp~rFUR6S
z$IM?!<|ReOOB1TAdippumN)+pFBEIw-I&OtQh|_S&v|qGF&qldO@rsY&7P}M!0y=0
zAPWpjbW(YKRVbMHXj3EWK&E`-uO)MnBjftjdJIg6U{6n3*7I-=Z*Rw<LY+w{WA~4*
zs$@?e_CtceIKxDjm58vs_*{S=a)9STuBfulm`=v^G+5Yf9}gmd>2iQElUXskIKOmi
zH-t<K2#RbNKprj#3#ck--aWxTpff?{w_b8G#PmU$1P6cEGySBGARYvjBs}K>84v!T
zrlJiqW-#4@cRND<RXS*Zl?Q)7q2VP>azG|i>=*1WIVXl1y*>TY9(^URimspHr1cDw
zDqeC6+B4ZnJ8QDDAUNik>eH*}*ID896Wp8%Mnz>wt-%3BGs}C$`6so_Nc1T3bPghG
zjJ^WFMT8Fr24rVt1qYVUQI$PCUk{f=4?n)9LYlNvdWXeDZH_pAJzzU78H6c23}ycf
zyj1Jq$abW(a#ZMB?!5xs9@_2RtCz=F&kV=tSut<42-_FC^z^Q8PbY_3bvxJSS{8<<
z^@ZSBf0|%4l0|eyXe9X~R$#6h5~vaBCXyc%=gB_@XuP2(;{Z?RETLGd!?ot`zYoxg
zF|J5e7gfHc*n%ol;}PKNqpHdh`%I3eKh&<yOG@oqn_>tkO7x3z^Z(g9&oQ>WSpWEt
zmv=k&UF(`wD=i=c&5!L5jWAV|Cwe<)2R8J~6hwu}o*qDCA795*nJD5=B)O9%+6o8A
zoB^IhodQ)Ze6eJSj{e)()w{N@SC6!Mt-FgWjrMePyZ&7~;%mV7gstp*Q0!{=O>p3=
zZzOEh(f>HR$v2`ucYE6`^&?=tilkwrMH>md?PShmr1@&0HjT8j_s>in*mv4<uS>5C
zE-xH7sU%OE5IEjcV*fqh<P7lWvF!uCsFuc>Y0n+TFKcQhmFDvAl*1kDzXwk-_*(oc
zq~-PJru7||n%TcybD_M%G(Ipvn^!VvU|~7?-T;T&nvWru*a184Wu)Ts5c=fyl)ALa
z%C!2)8t?ik6_sgemF1J|#&Z$t8;X-kyInVBay@=S8Zf24esVc}1IG6hN`)<2Z^Y;Y
zsjTx1W7RY0ro=-6_9=g9uon?@Y*}ZdG3h)YjnS9Mnl9kQRQG3j(Cl7#Ut9p(@bEac
z48RhQp0{N{|D3EL@rg@TrzG?WU%qPC@GB1vt!~mx?cLkt5#gKt&YL-UEuBkhJq9<;
zTl;oIBF@+0O=+gI-2q_YBS;4Ebt2NtTj!+ojy7@6o8)o|`FIeWOvkf5q8jT&GT{Gg
ztoUfh2q|6IND~{$HuAtwibn?Aca!8V9b@+ma{>UjG|9h-j;E6ck&jb0iF-QQBn)$_
z$FWiHe1967LK6q!&7@-rEo`i`Soj?JvS3hJ7omwF!smhXFZ3^gq(<5obNKN8;_W-&
zn!MJyIq%3~WRZjwAPFJtkpN-ujUrn_5D^r&briQEZf&irj=HPWE^Xb`F5B8=$GvuV
zyL&rt$L+q?+g5V;o^#$L1hwPd@B4kFNZyh6J>wbwXPoCmBaP6`!TY3)oi{V@;FI{I
z9wnh9ek=YOY2aSrd9%EZ@J~RL#|u`5*^YE~bF<JeK_29DuQN~Z_2e3Y>>TC^M<26<
zd%aiq-gvZD_#U)bjn?9~jg$B%@DT)F4$>#ieVue1tu^6yK7@0l$Ti&Rb!6aPk9Xo$
z_dD@d%)<kd-S2$Zv5~n2e<i#VSE9882kABUGvS=@O!qb3-JUjQbBH{EM)|S_;JYB~
zkl18Vo9s5^+Y;FF$}25_?15Ka>2H69w2gVgc^|!t-a)R?KEci*1L%|A;Ug3=gpUUA
zx8IzPx(3;Z(!mL|2Vv4evjL20o5qIr;DZah7oO<;>@yhFq4yw@#*_+M{GmN?2Wmsx
zKl`kE$UWZh1>qj&v*12*t9kb9?pb6>9(f)rVjf0s4IOV(bSJ&WZD6+Y`@EEJK%E|7
z^V(d|O=hdEx?$$bhH71suCj3C$ihk;zi;-iy1HSrYvQA#;%l7G=Z+#Dem-C}A{*R@
z4f$lp#AK6SUM>6u$1TzK`A{o-8_>5mS&ioT4O;z~N+D|++SXN8GGRhVSyy&JLR?W{
zd_n=QE*n3gv}Al|8SHN!7hgo>EUt&j+}U0#(taT-0J#~^6IvYtZER^S8r>GN)YKT5
zIVmm{A8lzY8q*oyIXa@Yd`=J<8}2;w1-}w(GH3sZ*b&wV62ZfKQ5Kk&lYDn_O{1wS
z06rarPyFb5ZF*;CRD(97tCRMpi|L_!Lg<b)sZH?9^t@v%Sn{5s5E$k#305ImFD@T#
zXHwWOSij&NZ$O;zLT5;sNeN8PE-{-{vmw#SMscLHH#EGyh_M&PCCM{B(I{dA^2AT3
z_*BE!fsWr{{>5*g<1V&9oj;3R2eti}e~tb1*Rj{G(SO-Y*C#lJwnia6OZ0yf$qEA3
z4q4qyd|lN0cwLz$l94KSegIzy)52D@rJr4&o!&G&EobwW+F*4~XQBA`=u>w|hE0n~
zsm7N&x(jR#+`>`#!w=i5<717MlEzoj5~D;UK$0LC{_x+va$BKD-2Yv{p*u_C0Em*l
zfZc@lf!zd%O0ZLgpl-<H1wDZFJ>(m*&sU?C<mK`izbFjyT)`T$gWUt@I$znpDon*e
zpijWpW!#${>yDt4)ax2X3WfZRZ--{H!RtWLl+~2a?ygKz2ZaWRnA8LJ@9Xf(k1B5}
zo7$8g?H>}Zldzn2%YEhHjeQwqEIT3Hnwc4XB}^lIX5Oe!HKzzo8Qz{89T^#ZpCMEi
zFnwHVh>xEx5mph<_7$?7fWt|=g^(P<2NtUDsNGEvuiXM$l2dd@;06>UhC7^xVv!ty
zS<ZG=H$~l%xp|g<!tBI~lDQ3*X**MsTG~pqcc=HZX%k16*_-E8dS_HzHuo@vV23aP
z;v<W->M$;k;|uC6i;m}LV69*Qqx0R+9jFRt3dljRcV6vxF(h0H?R4q=1UL|MJZUXy
z57o=UAEC)wVz~UKnpXNI`-L3}3f(u!SM(bi`&+Y2La=s$NaL-0->tl9JMuwrM8F=y
zpc4%=kCchnjnAP^`A`xc1YU4n2M!djLs}`lqkK1eWj7*jh2Oh}xnnnT#~<8-$fG>(
zfwn|L?N9P1D3n&ddp8g0$oU=%dkbl6G*W`kpRwS;F_08@OaHf?*NL<+0JIVAm^%h;
z0UbM+y#>z|o`Wly*#mbHY{9c8)~2&FvmZbAM4023Dfl$1dgBc$d#XWyzv|R^B)`_J
z#fc{8t9x;8uk*fL{97P*XvQ`v&rP`72wdTWrGS`kJjv|(ON}H>FN>6!5+-IxN8%kr
zkNK>9)#fB|L~62cvZ*aOF=yx@bc2isu0f9h7J&Zppp{c~HamLktl!zkxW~SD;f0M?
zt_-~gSxn#(vFXrba0A?iYpz_`_`(Z=&)PBYGS%?#D7#IpK|A2;#w)mnKGOLt=RNQ~
zd#VMVwS&B8;|sr#m!2i#0hr>#z>9(o;ytw15FK=3dR^Ug@>^P(Vk;xRSK+vp{HBza
z+u&E2&l6}Z<4yFd*^OCF5RgPL$qA;1@e$_743kJElIbzL_vp{YcOE_AR1DYMcY_XL
ze1_-{yo32-pp)n<*t?v};2-O(=RH*xX&2gu!ucsT>R{GmEKqnsLVRICLSjBD6h0Ji
z{Rss`7w7kXLO&E1IOm1)LVNgO6te;zQ37JQ+Kt+{&psol4`{&ix`1f9uflaN7oGul
zxCdwicm{aFiHf?f643Y={l4dQf}03xy4sCfyWujO^HSD2u$$5a`95GP*6Q$EgnnIw
zOHtDYA9&p3dWV7D!Sv7@==B<AF3^^gv_U6Omw}m!7ak@Ab{MV1AKn2pM&yJeoomG>
zV2?0zuNVnFDyV#E#?OZ&gobOmr6%O13lELg!@W6h?^)-)V3t})GO!k(4S@>qKWoE7
z6ZkFRx&bc}D%8i5zVvVBmJW;(@IOoO{}DZY3_qqv9RU9?ToB+t+;@mOKQN46Na%pQ
z2_2j&56I63=mND2%60JRAbbMoqRHs&3~kg9=mO7plY4g{81{|?+J%%3!)K23Oeyzn
z9cjn4@A=_CVHArKsdDXmPQedvqVwJVDz{<42)GgKV&UBcH-<u4#5DT{ZqOL8uDN+#
zfD1A<O`Ar(j2xS}Q+N#DOL2<_wc#;tycpz(7yBRPP7UPK`vEU{(x)fiUT}RGQ^-kS
zr|U6J7@7_5ZiBhl%zp#*=%^iQ%7yhpMB{r{usSW?d^;P>HV(@Ph)uV~X646P`59ST
zi|yw^n~ahepV*T0@Q_dw^o4N@=ceO>{KXsj$WxBsgEwN?pzE<L(|?L<9mob@FQqf;
zrWE4J5NPJ2KmIoQ1x=(r5kK$#$e#_-;=k$9ICGrd{fUh85IT|~Fc6R6eR!W96{BLO
zeR$ylnU80=g*cXfp3nf)g0kV*2@}ADLkvX5F%qurq}PbHf~zdKW9Nhk?+G{IQ{=|$
z+wSHF*8S;XH2&5<Q6H(9>H5IU*Q01{h(6AY_qsljcLHt23>ZZ+7*p77#M3^|xh)id
z(grE!;`KCl$Vow41arkjdqe2f1o+Ab%TlPTNvHiFNubvx=d-vC<XiOn&@33INkBWR
zZ|)1itAE=UH1vBzeL;BjZ~KBAv*3M8cn7s@0Hg~Tkpe8@2Ej|}DkkoVwOC@is*>V)
zduI;hGzGO8)k<Y>MqM5Re4xz(zU-&K!_$eq0Uq=l75q?j&RxEV{&r+J-omE`TCS6I
zr(Lqnam_>4dE7flxA?SM*8Siq>R?PO9sT&oK&hb5K`(%0$49!aUhQ`D&+eKnjQfy#
z=qfL`=V~`-hZ(a`CAkSXu5qniUZM`7KLAmIwCce#86KQ>cl6M42xqQ(t>6NQ#i^zS
zPoi_b3;_TUiM*mXzt)}^TAgl=O;*Ze<_x<zCY^n7L|U>Y)2L7dvsq>{@$ETwIzGb9
z17nGg01dJEakJn&E4Mm6x}}CX&#ZtDNc-wx4EGGA3i?T~`(Xjl8R(<qE$HqI_c-l-
zya(<;mH1T{5qeLJ;}^Vtpn}Ry54#`l@9FA+|M3j+FX=My{{=j6APHY0^Tzr^_9kRv
z7_5IaJKnQcm<TgI5FHIz5bk@`@hk=^fhq(ZdCz1-1gEePrsUJ1QT^M#yRP=bPw*Vv
z?0D8|y6_xfj4iNZoK52qk((|A<Zg3E+hz)jcE9^+aMcy)2b_h+42XYQKi~sH^#jft
z$fx)JclyEo7`J|492qdT=U{Gs*EfOB&8V%JF{7sD7K#hYt+q0JpmxSBHRNOpI9aXb
z;4^hha@>no56lvL$G^$<c;|IKU`GO;grD}3c`3+z7)+@`CIYyMz$V2{<2513JKmBt
zw$zq)^+0S-x<QZDPVzRw>I|66UvL*b4j3Os0(Map%zBV-b|N~RMjJjpZg+8dZfVSv
z3E}?5#iNb-h_SgpJYb0}D9JKqriGa@GwaigTJ=<T9#BRoj&u6zh~$s!?#7{1H=zDi
z<jR17@Bz>lSl6((8~wA*VsV@UBKs7NijQBgAU>Xechr9Zrw`-|@Py99g4020p$#&B
zQt3a>BqWb)NlhI+GC5)R<caYAwNdHW#l_j_qvpVW<Qdx?zYdHVNGE(QzD}q8KwX|h
zr47CBIt+zPo*3#?EFCZo1d%y{8KUj^EgbXt5LE*2@c1tK2f74Hhw764L%3jI*Z}k2
zU^o2n_1Fy`7zoBc4Z&{sfD^mn1F$BQUUOkL;gT0~?RyM9h=GytJ<#cZl&Q@~&>j7)
z!=IB!K>vJD{J^KoB3Kgu^Gn7if|&l~1I^mvz&}P+XGlrq)Gqwa$n{Yov5zWr)0FWj
zvZ*aGSgTNlFvZjBMt-qeuaC``cHfuTrs{0^>}%hn2jCSBBAX!V!6}=}{n-`^d(n*E
z5JVGTPzl`kg>WAfGj!hfh56U177M@CeIs(j419r~V@WL)Kn$+X4~bmk=NNois*h$+
z75vL?7xVo+fze`~T}L2b|7Kh|Foqu|(6HzC?q(b-$=8^L@GqYs=6|u0uZdoTuR+5-
zbpT-4!FUU9CgGFPl-lV;B!DbPDTROw9nV#`9{8o4z6+L%k~Ba1N3+cl0^Cw=vEcd_
z1crh8nf}v`mj|*2B4L)mv&xDM7Ny;wgM}EHXJw8JG8r>V)`AlpS7b6&DwAD3e3<m-
z1dbTU10I720ZZb>A`L0w0`q2qvCzTqQ^S=bQu3-p4YnG^@Ze275fO7Y;mL*dsi{%1
zg}a)Yp>K(RJD%ddrSjLquZW*&xb;@o|J=i_PjCvpvlYJ6Dr%*&4g?KR9nO%K9k))L
z@ErUvVnnH`m1&!NTR6LJRq|GtdZ0z{(RuOT3A9Kk)kUq;+SubHM&zh~=Wpgu3m6sI
z@MaooXeDt0is=sv*GQZKAI9&PCiACVaf<#&xE%v_@bOYxMX;91XlQ|cUlg4weLJ#T
z6D~Sa{AOIahF|vO(uMFpo#X5A7ZIR?;W)g6V6R;hE9&Bts=D|GGJ=&#wXrQIo=?l^
z9G(dY7cd3=&jO~86)p9W00IlAv<W+xz{^RHPQVUO-^k-Lenxk})T+xXpJ<Paw3A=l
z;QA!WFh=2r{LrmqaHeq0b;VBG`@G|0e0abt@BloXC|@dC@!{;~1><5O<8g6xM(;D1
zvogs2VEgR{+pmd80TyBm8u<OJ7Pr-b1-QSf>kQn(0EW;EBn`w1Hi_8HfgtFw#}h7G
z(GR@)os)kV$7sMkTL&V9`E}b5Tf4ho>+W{Eg@y_C1I#bncNp#?wmFS>;KRf};CM^$
z5A>hox(3qukBQypv^T-u?WSw86B^9s3rwtSOiEE!OV)4;ozt|UjF!yuxGH~sS7&}@
z_+;zk_=R5@CR!&(FM_!_$Mz4Ti)w(*^@3Mya7qMA!}WafY)`urS0)*aN#yri@<ulW
zU4b|K#dV3t!YxTF;nhG?ix%ON&NDEs=ePiPcQV9Xz>XZW-d%L5refCf{j_gG-V}Dj
zyG6<FSH0o-1Tyq<$6H=9(BXjg2rd%@xZOZaUNGCic_GMg;8}yy8K~3BVtaDJlwrM&
zv|jj=(-Z4FW-d98@d1@CFW(Su=;(ld^7C}6>y9Z+Ryf{=d2J*<Ohoaj9Uq4H)G_?}
z)vJBLyQ{b^ypjKcUguNomQ)^Z#8=OpK{D=x1p)WpAFu!(1NSZ9Cg2SIGfLY-F?WUw
zb8{1hVD3RXQcmp1>ov64gXylf{EoVO3EVGkwf&w8aw12x<2C&Jz%4h($LFh;Epz>k
z!(E@?6tsUB@aCa`F%<th{g(I;^;<eVcKR)c+~f3H;zNSp67LiomoOGge~;tifd%wg
zM4~yprDo?hRym!f4Z;^4A5-V4Mff^$T;N*pQvPk1jPTG~OQ+Xb%Zc9NgFtVUTitqV
zAcZ>xGMf5plpdqz8YJH3W+C&G?f45mH84lmJB<`lqf{1|hXkt2gY;0M`ND|H3`DRT
zwj(E5Pb8dyPsRF4C+K2TA*^nK)HhDIWQi`$mz+`R$r-;`?UE&0T$3niTFFKQDOWa0
z5`!fPiP9iAvx<odRIZ|D5)&kZX4w8G9seFk9H;_}MR!l79Bgs(I8lbeezQbhf#b?d
zYF0WwU+yYvPO-L<03<A<ZuSU5;?G^-NPM7dd{q?*NLE(5Ly`%u&?Jn7hD*ioinMgj
zS(DwMwu$k(tGY+xzrsKKDE!{zDB^LD!@Z8T*xmsnof9uZII@#q7r|C+FK)!K@Y5K2
z^7}8ZT>0|*llb4HN<;j_oUE*ziR8Q7J!~)NPl9{?=)3&WL%(}FAIZ+<=TV&snwOpZ
zOOWVuJ`&I$>c1W8yUYgLk@$q%*YG@gt(QAU-$`PajKPTt!IK6RgPhGS#P=U}OgXly
zVnk?q@H=-OXEq*PUs0#$zr&}#wAq*LJ@${J)IP%3L)tF}Sws=01$x5vy89f89zbuR
zH@VlG-Hu0)??c)M<2D=Q8tFTYp+Z9=EiiiQ?DMnJGKT;1ACYu;M%wK2_|B0Na;-^q
zN!Hv6BMEIV4pMRS9sVDXe`ken6RIYZ;gp5MCFq&cqSHb~APpMYAXkqT@W<~YN85F=
z!?WYFCS*-*jteuSr`zMxn^GdRI>vhT!HPILcfy=zP4f>)sg4d1sm7>%3|5;hG%z`$
z^q$aknL$zN-JS_$5gA7+wB=D~OR$%bw1sdAa0ielNyLn$btSBM1j{;y2S2Jz?P~3v
z+tOf7H1(r^h}_x;MkEgyDQVIN#fZ5}@}TPZbv5&CNy7|<Mq4%SH*vOFUqt)88gSGk
z(d|H!fa-;a9)J-t>`<bL<Q*DKkd6wS1vg+`Zf;)gc$umrEGC3E?+Hf+QDa6%y5lbl
zW7T~WhOFLD-wE0u1ns{9?Z3faH@F^GAZUE0uWfYSvbMHm6Sc;?!f=1BA-^bG%?H-a
znNwH4aN)2jLy|STa+uL-H^BU2*aYN9{u81h5sW*Tp1~GU4k3q-ZVnBG<VgJE{@9|?
zrm!H1<)A($IV3Pl6mc+|H*;;?Nr{ohnoUs*wD|8)dUJT<W&=W`{jV4hp$Fu!LmwW2
zKA6d<44r`+vXQ9KgC7wk^o(A-xHUZ<vI2wkvATfb^1y&xy;SDw8^m3b_;mKv)-TY)
z_IOskpRc!J=5(V^j6y+DcVNs|=-W4<lMwHYa`nzR=Md$E$sk?Qf;tqyJ3*e%;WYfs
zL2JRNh09yB6T`$22S^7cri|Q(pa7#ivI069Wtm%3*AuZFx@YxvI7lzEk4k0nNfDLh
zrX)!EgO|a$w&EY*-SKchXWmMu9)urBeAPnQA0Y=gNz;=FJpk>&B|HAHOD*pXltg8u
z<Oljhj91cwFy6dBy5aUpt`+D)^I}y+;$0dBL4GR(Wmb<FP_j3^nz8C>IY-{T0Pt`R
z%qc8UVO_6*S-kPx^rVoA>(L_Dgwr%!Xq6@ek%q17QYpIw#Iew>AfJdXwSpXE+Ki#l
z$}SZgNn*l8=DkTZUHarkXG;U08c~tB%iq<~r$$7Y5_f7{hwqc2vwCM`78I=GHKM(w
z_0WFs_m2jD|0nJYe#jRlgXWPfY=em+%_NLOnyJMHQ&QO)GZPe+q#v%B<>Twig@^Hx
zyQA_#Q~86*Nm8l*yp{gQ#xhnE1n;$ar`w4ja5Mu=?hwr+{t|&E$?8zZZV}dEf;h0@
z9Xfs5s+xIB((2VVJD0=(`ixohw^(lX4%^$q*TFM5c*Z~Zcjzh+$o3#iM8=)u6+l)h
zDcl3p>`L>%|18ojl4<<C*LdquL}BEdv`#}hiZ9oOrtyc9@K3O>Sfnn6V{H=g<-8Rv
z3!fpZ*YAKa`3c?uR)s5<A@aY@WxzkB+H|9hiu^oTNL6rbQdMF=_Q<f{^qeT)Zeyv{
zJ0vG2JTog?6K9$0U&)OogC$Xy7kNv3nPi5wCFqJeO)_X3oaU?SJ`x{D%H>j!+BYe7
zm5wmEuwQX5?8lZ02h=Kdt#JZd#+l{~V?mY~lH6-yJu{(E$lHgt&9G4>mzx$Dvl6eB
zs7{u};k(RbQngApUj>_Du1F}2LF3{}rDo|uwFJ#w6=P0Ar`E(-9Y5(65h#c3Tpi&T
z#zlqs8Oh#iOoT#@P04X<NV`&i7xb|9!3PdVJ^+<zu$Gn8<HFmcwe2VtJ%Jv=wah0?
zP<y>dhdU@OlDgIWW>`-Go<C#)-6^OCy2!vrQjBT01`Ga?o<L%ff!~~=km<~0eoa>D
zC8`sOaSdg-vaDg8;)F^9I~)HxCdHT$$$ifxUl?(w>M4nD?6tp!DlI}EEXq(W2{tl*
zYBFwN{h;lTMZ_h;8g}qE(l$WNJ(H5W3AS(t6=nb@GM5}Lii)rJZ0lzg@lm4qO=B42
zm`zO2Fl$Et>uh|6b(pFB;K6oyRxR^7I>moAG!K{tOVKF_{)B^+;YXF(rZj%1Qtg;1
zGw@>O!Q4b)EJ|?|x(|(WewWZWh*MhM2;C=qOM>+91XRF_9SymOMx~nBArrn^43UEn
zpbJQ6GhA2Y0AQ&g5dV-u(2YbxWT_~mECz3nD3kiDWOG##hY|S=6L<YC^)MgER}pgR
ziUo3#El^2dk|_Ns^z6lc1q$WS%?YYMgZ;tmqONOi5yGQ%5A?+ufxaM4Y%sy%O9U|#
zCygQ4V3RX$jdJ`V5E_#@Vf7nmm1A_ai`X0z<|D_wx54y!<vafFb#5Sv;8``vu7n(o
zb3S8zR6f~0j&J?^P@*^Zso*}>K4=y=pt@AR{A4HzKD_xhXs}z;hm(W#>d?rj;+e1?
z)4kc*jj>!(aANK9sh!WQUWQ(QO_^Rw(P{H*&H2W$$cob1jp?G!^xDSEq#c_<r@G(k
zO{$rA#tk77MFbzA2oT5wRgoisU0l^U$Q5R^%b|j#P}Jq=Rm)*3w9cu^YZHT$xY))a
zyR)I!oGzGOp}5PI4HscOW>RKjZF;9D-AFb<dv&Z)sO>V?E{o7ES6fI+etSebokDEa
zAB_&);%@oxkJCkGtI2rnht&bI*nGfk6n6?dLo}8Uy&<Dz0dE0mFNLFMT26FKPEJg8
z4!<bSTkX3DRHRDJN~UDSPhs9B_HlG>u7kULn_eST?sx_vKaQCYM*@)`dk0u{4e%I2
zJI<YN-IGFIIk;6WrA$&z#?G#x``%u^HLhz@T%IF)-Co;%{f4;QSm$22<h}V20-Oag
zTW~f4EegIjEt+Ne*09c)sZZoTii^XqtI)V6aE^c&CigRk{|kQ|llwpV>tOE;kURWZ
zemT?~kAQcJ#XopOfp-{rZGnwIrhzXTxXF`>(X{;d_<ZuqHjuw@`T6iQcn<t0x)ox)
z7Rc@-u4Z`Bzy)}c>)KEBTI|iPaX$1~+>O@;-V}AvYgQseZg}Ri<Qh8$b=~AzKD{;$
zk!(26w)l~~LSSqo>0Tis@n^5X4IbklBI6(&)4j$;1dS8g0r|BU^c=zFM9<MB$?mmu
z*Gpz_kaLTZ12QXLxMGw0OH`j!Cg47MxkL@Sqr(2xijy3}u6(1S9X6D`_BXB4!cgTL
zDK~KXFhwMr3$Fy;An%+3bE6<q(=2#9)nubj;98`$K>GfSfPPlnhw@}Pg~{xT-u8YQ
z-+}Lt%jIG;o$U+Fiir62`LGR~_S#pjK8m3aBEkXAKAPz<iNy%CK=vXR5p521SPc96
zlJS=dz6+!fiwv%<k;9?<mBJheT9#8PcrD1(2*H0V<UR2nXD{F{TstD8peN5<!u_q|
z$u7u9I(l5o800<Q>UcRhnMtuSd+;Zh-*N4R{NWq0gYTIgX{kGLC5}CqZr_bEii=T5
zF^q=LMrJQ<W1Q=le}En*xaNuOMGp2F=uv=FS}<Rvw62X79Ov|mM;S&w<m>6v%MWMa
zU-4Vg)R>I3QFUG0<Ip0%urNQgPNWWAMzmhG;w&54KPkk|7NQf>-db*JOw6?m|A;UK
zUMsXq^aLGCFmQ&9C7=^BmN1v(x}R4NU2o^aN(Peqp*DC9otibUB>Nr2GC_QH?o=|v
ziF}kT4z|rCN|bZuN0J>AVdQosUr=1TN1g;%ef`^6woRjuaNgFiTyKS8ElTNsrK=0o
zb#^+w#%EDQy0OH^U#r|f+vc2C5%D_+v<-XE=M(Jg#2!RN(uKjE&_g&0qLG*t2BG>7
z!KDB(0A%nh%S?E!zN|Vs(Be2D@~!q63n$iv(i0-zVQ4a6AoKV4p05yze24qC!?=1Y
zQ@C5Ntq+oiiv=`6PDH|?C^r{b{DQB&6R04Uoa4#8Ove}Ws*@jogk$i+KphscSWAi^
zwSaCPU@{PoAKB`d4BwAw*N#P~&=stW=0>C?hE5*yZ=8Yd^i|?;M)|LCvjWg-7^+9>
zm<DF60hfGTUF`U$QYO_p_LtOt>7L6%`feKIAae<P(c%ScDy$TA>G2`*Ku5<AhKnLm
zm&cp%u2yFgm{`kqgy|$4ugFeKf1ox?to?9UJ>FJ7tZIu+l2!MB-I@W*)n&TSlB$`<
zrZ$8zp^Z}?oLN=M#Th~a0+K_6U)c1b<2$`PK}^L*v|k9LdU5mffgy=Ofd<2zma+R5
zJ@fS9ePde$`r{M$5?CLY>jhpIf{Ew`0WOG6BT=s0X&5$Q^pl0UFov|WKCyyfn#BsU
zutfmj`h@d4|0Y&_S~UXitf}%zldsYGy|(@I=^dBF%Fn85Q1^%`AG>_D*6(jS&tJrM
z9cu4%{EY8m4xGQW!@t9#jN?hG8M7{>PSe?Q_DoNww$rSPW+-?x>r!hq9X*erdb30B
z+ur#K^Bshp@Co;P+)sHv%S8)(8}tpZGwGK`LHAL1_e{VysVS+EsS#{sDhO|a!a%tb
zx`iJBhkABZql{3)3=u)gw*^kcMH2syDob!*Nu^I{ko-1(Z-l3ZN`0d=8og=c<fs5%
z9GklvI$c?UmXuUVW4-V8mmsl<m+5j$%~f22pTu|`bN0nrRV+uR3Pow7RK_Tu6!g~>
zT$@HL@|J5`GnPI#X?HZcAkZ}kG0K4cRe5OltfcWlawne}K^_wu7ib<jp&Infr~puc
z;0Oh4AqzSC=t7zVKZyzZ!VhoE$BzX1Uh1B4=FE)lOBQ@SKS^o!mq$Mx+_q6V?CIm5
zefIFv!=xMAf}e?oHN7e&%EuS{g0?XU+s-dpvu4TpZI0KrMWOuJxf1b=O&=<6U;h3b
zeSLSlzx;O92b*SyCE@xxgkND{8gpLs0pJRd(_Uic61xD6amvLGa-JO{oaa8K=Se+`
zrGSwl*~#R*_y+{n;eNVzC_V2)6<*)d^C`H2)6(;|IPc#moTvJoJZBc17m0r$A`YHI
z>IMf>y}yLs|C!f&@R#CZZYkI$VZ@3w3vf^*;B->D%e9v^_@VqQHuu&et~{1BZfU%=
zc74#=Ll;){A^(fQeu_{qsG70k{jja#VA-xm8!~c_JhWxQ)6XKK9kx^K|EDF~{D8Dw
zaea|4#w!K4vwi%N5NAviC>q-1uk#0yW&)|Ka27%2SR#s@ZH1<$rNWjru!)^O?rh)E
z1>2UdKxRl#n6zhH_fshN{@CQo^t3Qz%*eFi&9A?lSvh@4Q3iV8h2DiTwRT(3`^%56
z<C@UxO)YnwUAz)MFmvf0dBJj3P-1BJ<4A*#^q)*BYnj#xbZEt$>>RMS4WxAtH>9=<
zNZ?2dY=QzdHzZrBwQ7~XK<u2AUE|Hwb;WT-Qzj1cF>PKpLDjq^*w-i6UdoP`HsE#g
z<Y#wp-uckmFF%9=cKIPCe#MSABHN{oh-R1{m^XGR{}NCUVE92x4xW7-jSI#$6}I3|
z;sBn&dLh?5K|R{3y(`ZhpVYCS=bWi~bY%MMwrTU*W{!(ZA7684O?KseBoE%d`L&&m
zwOJMGSCposm(FkA-rIBfY~SKwOI?L+_}Gs0I4GPsK0UUbs}75-n6UV@kbCgJqhAF~
zpR{+!lvRtz13AIi+;p#7p|yjSADuL!82<n6!<&LD*&O~jsr4sVqcr?Q)jAD3nZlI{
zB!Xt@gb0){fk1Xdd^m$rU?#CSjm?|ZR>3~SIWbYSX<-Y)@KO}=#4*Lh5}UVA`YlTf
zlD1C0b<>EdwRag;89RDAw~QIrT&A}s=B73HqDRq2SPHnUC)pfdZ7X2%tC}L4%2WMU
zJ@@#lJ6B3plQE>c4YmiELx8ox8AddyMsP}zG4rVNP0IcF!_p-1AZWKn?Oj$s{7xwA
z4cr%>T-OjEHU2GRMz~@18_d7Inb@(y@fa%uu6s~2d>(LPNmldU@iX#Jz1%Skd<!h4
zwf+2Mz`FsIwiRNaXEsu)utQxXHQ5b`9E<2~NaRc!yMN654?kEiX7s#IKAzXQpRrYL
z-&O@a=Qzh3jIC<h_DUP`1|GOVa>D)w#S5ixp%DD(+i$;h8hPV?pZQzy+mFD0I`VV0
z&(1vzi4RMVLZstF2SX(wGDWaA-dU(hzp|`^dgFw>@sLc|91p!Mc;y`R!sd9?pU35c
zTni`u7DU!cJ0C_XY4`&L5?0ab5M(iP`9I*@YgfhVx?q{{qFvQpIhGK6aQyp>1j!TY
zN1&@cxR?2;8456h-!A}Ft{xYek@=LrH|{M0&ljmd`UU#|tosgv1CT-92v*_(ce-Rj
zFwJtcu^(*T(J~c(v<=PICZsK`@rl^6W7Ib(%SQN`5Q{%UC1{PKirrd&_^|_W6pSD3
z-~ZSFfu}$oa%zw_V6`|UbR><$xFjO@j|6NAABglLqMB2KV5SsMp93;*%RV5Dt%6`C
zlDH(h`J=$-Kq~Wi$E0s2b*y009IPOcU442TXprDbA(sn$*3c*7`_>92g+TujZg?Gn
zHd=L{{HvtMz|r-$gxX{N`h2vZJHp0xx83D{1XreaxyCOUjhr;c@eG<)Wi_oajU(<~
zp!0He2Y<g;wTmAKE&<E|T>y7Dj33MroKldQ7xb5|!GjwFmIOv1@lN7OqV60HPLQvX
zM(t=AwK_4*9v>JyDY&X}SgLuO`NF(){c}2YKQwXKrNwcpCrq5NAosb75WQ(^VbzF9
z175AQ%i@m3O<vKqZv0eDP)uM<=;*4{dY^`lb4YxwaYo0)h}m-_2H#<0r6=R+tdZ=r
zv6D(7QhXHw$$?7cxz`pIW%(?0%Io7WZgS_y30-jdyoko4yi6O)9$&N^cA%ZRu<x0t
zdlw!oXgIvOAf;&Jp<mGFuWsGFb^XQXx9qxo4gUJk^{3{K-Ew}@qh!pi17CC5KnuiM
zWYEBN!h#<Ss)7-JD~yv$4dZ4bpTP6WW#fNO)zsFQ13s-$46Be$D10(wp+u2gG@gxQ
z?RVqN&qm4%pIy2M&2{A8mg^k~HBye%DJ(gKKzM>4z90Icqr0*RgFL8*ukVvUd+hzt
zsZCud;!bn>luOQjP0dYfZMsG1*GyejTF8~&qwARAmzQjC_OE5cOnmS3sxpDzQ}Hmi
z5#CF+KOI0}*n~Hb`4wi|gIHX&;%Zc5g30YK%q;HmukoL}w54s;`Z%qAvc9Ngp{i5~
zo<*qt2A)M0nG#$s!)a5Nh!#&-J#Ku1Ha>Df(QPvDD!#A<yozKztbn0>VeA!jZb|Nr
z%Z*6J8YwJ;bIbYS&v(sT^2{UiXZ0+8jETdaZr`>zKfR!S@As^I)d$aQ*uG))V^7|`
z&G9v|Eg4nacXB<XcL?+Q1+A|Rd?)ZaDbzPOp&Dn2K8uZ=mzX}GckL<Xd@^J4BkRZM
zeVLSjY1OUUmNDsc9=jYDKU|f!Rd_bVfb2Qy|8q5+h{fx43f;B?&=iT{Yq{Xbb6+~q
z)*@^c0a^t%i}-L~UH+H+{`N-n{p*_#c8@!S?g7DZR8&p0N@3P$vO~ntRVPt-UASt)
zQu1y>OI_Sz_88zyK*mJE6Ojx8h0v*8P_Wb#A&^}qPNR(?mKL{o<;Kq%KHaox(k*A%
zc{y<+$?*2$n#e^v1`dk~sutHC8&!@zdHjyuO1uEAlx<u8$o^Fu;#1@1jhuLJ!-D}#
z^_>~x@z-DPTfY4%$4c3vE;`0G+{~^3`T`#b5AvFYdgOw|;F8#Co!UmMJqjgl?20@0
zl%(Qsx1dG-G0GTQakY;L&P3xact?Ou8Dk|UHsLQ({=XfcFyD4OU1`nPCr4WR)Z^%?
zBV*1#;CL^YTQUYjHY5on05KXR*+}}v2_WJDR-_UGI)x!p7Uto2=Ysd^@i@<Uu-G4{
z-`>&GSkxHo$87x9(?8&aXeH`H`^apFsg5VJao~Ju7rUgtZ*$+iQpA^x?a2~!7S|7L
zAs9oT1<Gi2Iy7M1f<mG49cUb6s#0N2CB)D_qV4WS+S(quyKTh$-XHKImsXD|YH2AN
zwfYi%<cHq*=-AO^JKlYF$FigUUb~4+l40oa54UZ9_ucKc{eX6(mt{%prgbm{V2@Bg
zB&>aO+9_U>oqkA4qx3wrQ@kb<J4LWx*yGgRnFkLb_7SX7ciT0@-VyAYAJ8H9`F?tT
zpY#5|!(Z@YLJi~1U^~~sfe5nKJ(yUKE6`gq?BFva;%3l@hEP252~iX=)K(tcGM(SN
zZvlQ4t)8-U)eEjV^xLv>&UE8@@IR!g6J^Qxp4c)81S}UTfB{aFCZi^6sWeiyL?L1(
zM~p6+aXuA1>T~e>*tq=UOPhDNOVt}ETszf^j^Tgdogqr2;Dd{j>$#X<Ka=1wfFs8W
zW|+~CLyn=ZtXBo#l9T*hkYy4{;+t+<MOY5lOi-M_d+-^o1tPpi<tg=0C3SL1?;~$7
zY#%=Qp=Ev5_Pqa`dd<f7y>a4~$EGfyJ}zbNhUbIwYj!NiPbsY5{uMfYe%0DX?)du0
zzy4=dLqv4deWMD{iY;faF}F32Yg)-9<oEx4@1i|Zo0lKyyPN9Duem<{Q?NV%kyB5S
zKS7+9NI@tK!dyMsiBz3tA-)T$*Z_?}0bar00)GeBCy&Z&obmG25y`+GwM+_NpXQ{P
z&$ncmnRB;pPR*PA;-pHh2Y-daQy0`FM=?(;)&G7SfA`>2q$9i%LF86uYaFgc-2RVh
z?c*08nKgPUe)sZ#BKPt=NHuoEX#6t_DbO47eZ5P4FWGQ{I6u9_Bf%$;O1)vuom3zZ
z#u@qb*h>Z29Q;Y(PNL#gN~lIS0k(*+wop9s=m@-ACa+>9RHWex_6ms#{N*Y!?lk6T
zx|V!7t0LeQU(|(4G&6TqjBESlYYle9T+l=p^IWgvPQ1vd){CfnCBjdSHZTX%eK_Jw
zO7hb<9%YoqfZ=cy60F0YhoV}ut1r|?LHYtd3O)+F4qyimS<Q7q{(7j8V=+`(3yWZg
zj2_%BQ!E1M0HXTydJxsCH+@q7(Z+R$rNi1z9~)JQ$DV4*7fY(gfS}&E%PpwSZQLb4
zbjWwZ>T8GB9?|q~mMt3hIXm5FT}R)c+aIK33;I@64f-~O_$FYNC1?3LK~O2|9%_+Q
zSPW3(f2hzBRbSmZD6jT@;MA0S`nA=L+g1;XF4jI1|9EWWo_F8fv+@}7n@JTXwjtHX
zk@#C&^TTcPpMQS-Z9kByCNjK~{TbvYj2P8oA}~>e<%@)=>;hWhfr^1nfm*3Xp`b)<
z29t@h9Q=iyYkn@M-=AFHWf++fryQAh``VHYTd;9LqMpSsN@nLjCJv6RuJcI^k8gia
zjBN5L;6r;{w;IkM_R_uYMEf!<C$r9p(J4SO_xfI5e*EwF-LbE3UNzz10r`~53E2BR
z6lnHO-*Y$a04oAwDY%p;v5asb*G?>=K0^0KZKP~O1jX8E1_*6{o0Bx%721HF@g4Uc
z!%)67Jw72=rwzc4hwgvmNu))(Cm*?lueNlIZN~pX%I3Dl){SLZ%-g>_{*=11;-Q4#
zl*)vtRO9$5Emrl@kNtuq&s@6n^tWis>V){!cq$&YDKW9)=q6|%?2S(M;SC}FGKjcQ
z=j@Q?CBQ1-n{CCxe)a3wknoJS_~3vb{n=|s^V~(GJ(*R%>)?pA%=$g|)L2pfz5kK7
zHFwMijL(TQCWeoj-dgPU>yb0Cx$F-IpRAeHQ~mf;4Re<hmEaWs`wvaz*SU2xM7ErX
zUo-)cOrSu2Fsa1(Xdzq568LAeYq^QjvTnz_4on-jvF}QjF~mJuGKKXE{NtRJZ=gFD
z&tUkL=@IHfo9_F|^zktfDaVG4Qg&c8uS047`umBOtB5J=1-r^}e*qpK`6Y&M4==>;
zLSO^;7stc+?1HE*^Ma=ZcP<@0X65=g9YEj0mX#q>Lyk=u|G<HNG0kkmk0VCT+ag}q
zwW@P`y)NE7zG$Og@BHK6Z(2j%4YH0q34VX_ZjYFsYmZ`2{pg__4cy7(fP&$d`{NZ_
zbS};sSTOu}3%JQEbMX4)@~Zp*i%5Q&%V1Z&T{%kTn~uN4ckjw6ci4iJf^%4=vUA~q
zaF9#dKzxA<q5mZR$~hObd^dFk(t&3e;;v138Cs~sw>)Aiu{zKOHX<pmJ*#~#Zljh)
z6j&PYtQMfLHT>Nq!U??VE={LWQ(v-O4HGMv6fm|dWX-T^yz#}PvZjdeu=~$DCg@|h
z9U`tR-5i-C?_=7NvY02b!ux03Haoc>B^8yS2V?XaU-T;)O;)YO+i)4FC07dXWVunq
z4*~CV+h{ambNvfhR`c(~l98Re*E?P>;Vz5W*7OK-s`@ngW;VL4$#PV#?9Mz0@&2Gv
zxdh#fMnz<#o6{mOpnE!3d@saGAv)xa`$1`7ViLQ<eroo*6T}xHY{$m;k~rYrgSSbO
zE$L@;bzQ5iM-St}u8`m+D>^0*4V9zETp>Zb3|+*x2dD-kg6J*uLjNSsGp-n6I4j7`
z{DDuoZR|q?a|*T%Fc3J_sOJ&@IBa?*e6~lRNIF2^-SXnL`Ex$nxra-FqRq*uBy(6u
z5DqJ`=~EI=1}gdpe;F<g+k@)RLl5l@6KA~g*kjLBCY#rwqVkdmz2l?m1bw*aYt(s4
z=gs@$I-woKSSi}eZS@*K=R`zmZpo1)!YRIKiwMq8+0*inux3-R1PJ^~q+>?P1QT5j
zf>96xQ1uD!(P>3{Q=0Gx0hvXL%dq|1{+z%?d*06p&PmVwVgJs}W0S&O=I?H-9679|
zyCFW(Bs!!BSIILHpQ_CY(4^!|OHAQjwxzZf<}mSp-{HXh+L$CRF){C(mg@4Zgpi;|
zj{j#V%BhPM#l*)wdF0-cZ<f}V<uo%ps{O1+OISqz>7=~z6|+0{Y`yc0J-{bE#yfV{
z-8%_wWWlPfH`!5SS6V@5L2q5k$|=m?@b~&k*_%o`p`-kp3Bw)TagR$rS)ZVr)b~hE
z#=JK-tm$iv4LK*;RGwc|IJ~(uGCWkg-8W3-*Lb*eRJ^?{CW${cr==EcJ$TFc$A?Qy
z@d*!PSQAT1*7Tie`zkw>4~q+5GjD$HPHR?jY%cmZRTdu<78vZ<T~*%t@#HCe7L_zE
z%zx8LLhA!Bvxi~+z>*~EYhkYuClSGXc&xDnmF6*BI`;5EQK`PAvS#b6OQswZ=_5C!
z7u`C}8etOMBZq0wi{tM{JF*PHFKxYh+UUr5QBcSIz2g@w7&Y_q2w!1<hYd$SKro&I
zZ?HLRGofQ1sw0yI2;TSKeSJ>QEsCPTBP-6$YTqLcG0soQ=&X+p3l(ox!59U~L?O$N
zu4?=A`8CBMalE=@?&$KSy4=PcsnUeNuz+C42$BPW2IgQB`zrLE#K08Ldjs(Yi(Rmo
z8YaYaj|A<l^beyl&Vy(PzXO%Bui|54X5w#4l%l_Bz5Ud|6NAx=7upkUi?rO?5+Xh%
zDlv%;s9{i+J#WvNoSgz8u%OxDRYu+#A6OC)Zqfc@#xtmOPWT1fHykC#-_M$=eQgGy
zL43a3T(lL|6b-Dx``EECM$k?(v=h=rZqiP{(xB}mGw5P3TJ4y&b1Z(NZv6LYa`7{y
znYvaTDtMqSYF>DF@2~&~Q<I@A3>9rr=FU2jVjGi|@CDx0s7v<e5{;S^bzqp{o|^T)
z)N5DcZ>&(vUhUV%l#;=$`=m73I*sHy0v$2G3S(*30*Zqs5QPpb?qX~T)wOgOT|?})
zny5_3L(DJ8CuCSr?YxOIGJ<$<Xz8iWs$g^B7(+yYcw4BiwymS7X-o5nl8mki?eVvS
zYGcD*Tq4nzL>g`Oaq%XrPk7yfee3J$ZdsL-XhTWS>bm(gIcbY$Y;T^_T-RuNu2Hv=
zq=*xmV-CZ3g2S1#mA2F=eS}8Zbo8WP9yuFHn`meDi@a?Q{WvMW`<t-^y0En2Az{&y
zwZXochUVeJme-W#&V4MZEkJDyTA8Gqyxmw-y{@e@GpoAQ5FQa9CeIn28z0qHH=|(0
zww!fY@^)hL47Bp|VBCg#fk5S9-H?UYGS^cgNJlk{CLu+lg~E^+WU4@bB(ezg_5|@S
z))Hfm`fZ6#$1-Amp5||2Wl8@PN}n=6b-<ValWykM>udeu{L~h$E`Wd8cYAl$%DDNc
zeo>+1j6aGj8J3Yb`of6hz#wh2*56l#qhqh$QxjOIkF!cctExh!*0`|zAXA*T;Q-3{
z@SwF$UK<i`<>TVxq9@+_Q1+wf@Oz6BWs)jhKW4;;JMnwBBn9%8u>5Sa6#wub?eiM$
z4T#xRktqA`^;w9^UDs#zbv-7;J=kNBn0rHWQKGOrvh51-MXk55T2rqHR*!pWUa61S
z+fT2C5YOYjYg*gBM3FP{#rJAZaAsbzwfb;ztj1qmtycSb<2uWW>kEBs0ft1eGC5f(
zPBa8s{X>ir?VL~c^+aUKQvE}XT#OM)gD=LHQR2O0qosTjr^(MqpK`gzq+~+_ZSjbI
zVh;2b_=39~<~N+8U^-DSiNGLQ9VuYqrZd5b0De!<-2@C$cUc;D``c1!Pu+;I4cUHa
z=;Y&5S}$x~*K^Cg3pZ|PdKp*!XpLAH9G+9t5Tw6_t<FtK%B-D~kz67*;H&t<Upmu|
z-t)}46Az3ova~tkP|+)~L5J|SBbz6VoT;uLb`0<VCk8$Ur8|eY+osil_y2~L5sf84
zAQ)}%C5m5=Njgi{EmxXQ?|tpH4=h_asdMYp-ldgianI!lQ@1W8rKC&~(9U!u#zaJ?
zSIm>Do_X_;is+>aHm+X2xF|WK#PRJHTLQJWK9!eSm0ROWQgMhJaa`cTVZ4Zy3XLGm
z09)VR4!&B-8%pXb7NQvzSUv+gw7Fq~frk}1a?L1Tn@=o0W7w}X;FIylC)KxEqwx1<
z{7vGuS`fsHis=a*QLhYO66I(53(bZD(WMETWN(Z_#0047s>2ddNtKV4%HV}mUf@P<
zHH_2HHl_S_n^Ha6#I07T<o>m?B)<s!P1vTuQ2dpd@k{is@t3QW=(SMEVh!jl^cVD^
zE;GkZ%~+UOj%t0-{K(XB<{uMHVkx8c%gNM5eQuM)6Xk`!rsG87WW;tR_Jnh?EPu*W
z4v%a9Q<gCpzJFv16B;5mJn_Q@d3eHAIxVl&(X6xxB{kS-1f9}75nr&!Bnj7iy*T`c
z4h0<6#^v{&*5jua^j&nuI93%7#%}(C-*5Cu3Eh>$Fyb2Kn-@0kx_vGF=a4v#M}D?D
zrssU^Z)HZ)O)h^o9~%Eb8Z_wTDYybHgScogkzy`}NprhCsXH2Cu4viNVl#Aqz3aDv
zVcUca^{8LWl~ad0=v=${2g>XB`Uhqf$=iX^7tpkGE6*EyxkrX7v$F6Rzk_+%&K*5(
z(%WYInI#hc&}<aazJWJA+To%(!J#g^5llZggyN8bfCJ8TDNy$MeD8yP_)Jz7s+8^d
z-K_X#B#*S9;O6V{;=z_?zk?jDWLHkhO|s8!=3VyJXi3Q#l6Mxtes_Aulb#7@Yjr-J
zsb*`nzUZm#r!GQG&T{6!Lp`1H>4Rxz{!yIYV0xK0O&MnNRgCL-2vryzF<=o>zG!Ff
zhgx=F!mf;zIy~ZikUy3JWqqCK%pJ=VqH-Q_KN9;Jzx($>f9%)6c6%@}&EILdAp%Hn
z8C1jrUzJl%Ks#Jnw-mj4@P~(k3KqV;%jYfaJB<JS!o`a(qOik#OY?Z0TqZZK_-euw
zd<7Mb9re`;|8SXHhw{CB_O!J9?R8{ChBw}7YuV%D9iTH7y_B*E+i=9X=$FDu!TUmG
zJ2*x^fxRjLce(9ql1~c&Y-m=kRmiFZzpl%s7Ju^N=vftqIeZa6?i&*5gU{l(WO+$B
zyGD#^*%6Bt_yz{~pmJ11uA%iJWndpTYf+Zmhkc=6XEC#1_s<HGq=sk_apJDvR#?pa
z8um+z`C5hAXkdZ1L7wu@gB&CFH25GREnx6NyQtX@ek#Exq3wYU1fW$EXYtPqG5UTI
zvp*t4>g!P%IlAvxcN{;TgzK3cY>kdaui`DvpnXK!T}*p)G)_i;iH>%Vus)?58LnkX
zoY>&@nz{0|z*R$?qfk?f7|#M=_zlWo&`~^0qP|lpEgsJNM(j8s$F5J0>#8fMDeE#B
znYx=rkdap_&=1MCCy_>yvrSRG2iHeHIBN*MN7%sU$^8Ty7609nYDSGkh4{*p2~Miv
z^AI|W!d|?{9KavE{<lG@iC%}^L$7Q~Ayg9ply&y4H|V&y=-8X?N<sXF0s_`LQNo|1
zYIZ_CtY;^`=+-|=-^_mD8~J$FpCfd}W6Vg@{m+k@=i-PzKZ1_)u1@`lvBV!ad*h0~
zh{f3u(SmFkh*><%op<L|ifJrEIDd(p2Og;#_@`(DpX>5{5W9&`f)Lgeyf*~ex-*wa
z#ys_Q(5x#zM6%P>P*{qZG0HUX3W`RIow&ETxO#L;O<L70wuq9NZC#63%d{(>PfmF?
zL|v@aPnwz2)v8X=a%Z%O{$nO)&u!m<yq^3JZ8^Ajb)2=nwWZqEvTp2}-4o~5k8a2N
zqEt~5r~qAv{M7keSiab&X&jQ^pC>eUiwYdip7{doEgE;?7L$In!)d>t;pWi(5gPju
zXdO!3xN@<fKO77EPWnOIAq0&YAsd(Wi&(Zo0uARORp~kI$FLx=@z%xLCwAixBws#k
ze;_g;E-+(wOL6wuq=tEZ$ToJ=$v%6KDo`R1W=!~_b1qT))cu`GKMi|0DEzLO^R2hz
zk`?u);1o+@QxPs*5#5)b8rh=Pio8#K<C3`dZ45L(H%Pw*-eezy_KS#K6#6-2eFO0D
z&GTsCdt@z>h^(L{HVY8L*Wjzp2dh*-m#||E#Nhz;Q?)9rSAqB<_4Sg`5lBFtMuUwc
zpPz~Zvdk3JEo2|jg{fpmZSmI|mK|{vNHi*0uUaZqtuA^j*xM%ozudGaJ1#DJcv##E
z=^9_veO$N9A{!Q*ibD5qJa+MZFdWr>smGT+j3yqKGzP*e%5Y8}t~8qbl0SLg;XSV@
zJ~unQR^!J=o<Z3&)xkNrj8v70V@FMSVD0^m?^5O7#O@^hIt~4-_ZoX+zi1P07NWj!
z?JVi#jc0G@>S@|l*Fwn?f3(P!sg@|0JJ(4%J0I=r{O8d5#|AsE&@&3h_rJXkHv+w<
zR|v~;$tXm5jskR?cp5}mz{iDdJ?x&^|AK!ZUkoxX{OzKw=VMK;g!t#_3{gofeXS#Z
zpM7J`j6>;12#fltGtklYoU*CiEAXY?W!$%#CgbODSEbBN=lo&HzpujyG4l+c?UGxf
z5PJSHJ^wU0Pv(8#pZrgv&ms59MbB=@Wg?7BV5=28*Hq(Ek>-p{IjwLz$!HN|8QDQd
zN8`;FD%-ew=1*R<XwrgFqegWeJlF|;Q1t`D9q+8%zPh@$Gsd1C>!<NA%c~yQlv<Ay
zWWmNw7vs{;wX4u<G)h--RyKNq=(Y((nVCfsT3T8vD_dG{2(zNU;nT9pRg=?VV(ols
zq;Ylqb~aRP2u1lKQ9g?C3xnK*YD-W71IN%$z<Bs0y5<JfVnjnX0K8n!uh3Sy_yShj
zPyv12zUHpe#P49W@hcsVhl*y4LLHAwbz1M)3Xvr+ySmJbCdQOWb^bo{<RW-KITe8>
z38&`D$wC}y=bh`;-3iNW<Uw3yiqf0L&!gl)*Vc2lx(^kB*WL;C3l}+K=48DfT_-2-
zCtW9Ja$_HZTY-=Xa0SbRE_m`A^e&CVz;FHixoD<_hgEUx&vy5sIW*nLNC$wC5OQ%6
z6Ym}7TqK7}$qG7o3buGMi&Ix%x?acZlBsm<o`~uWX5by%Bg%&Bc91GwLgo{wHxgZ=
zKOhkS>XYDxibxH(<RKklxb6O8e~khONgCuE4EaYel8Jh;r-`zQGvtLfWAdo}pGPGd
zZH4lT;*sc{@cf*A%Kaks6S)RKSoj4#h;XkY=)}n&DZ{t72d8q$d9NKEo~lal5#b)+
z5&rW=>tkZ{qv!dL@Xbf*zQMsh5DP*tG8&7*m*;Y+$m|a*39)fLAwj<Q1@tw0HBO$G
ztSo*CCtk8mkocG+G7)Tg9_Z`jL$G_@YXAuy4!kKD$2WRyA7ZDbkf;tUqbI%9(4k4y
z5=BBOQ80->tqM@WWxCR?3#)4^0x!DUom%I*2@%Qn7+g>Ut8B=3s45b$x-kC4-V=U^
zh_hKG<C4?r4~(osHBBqm30Xw<CYPO1N!P7xszG%l57eh62dG5hoz0;>-ipA48J%-Z
zPtMM@MaxnwE!C-AMIE`Dplpm{i7ZlDYDLYij3Z>&l-p6%m0I0mNs&d{a<eC&p3^xa
zAyDD%6WZJvE>Z;?ZOSdK9d-bQ-FHpb6vt(E>XA_y!X!@VT0^cJ7*<=H+hhoPXm4Y~
z)U=NLOohbMSFv}gQmeDrTGQ(8`k-i^1U;#jN4XP~aDilB(Fb?crM22DI<0c)-ikhx
zM3I@_kv6rVaqmN6!n|-302hF~r*=DFWe)@ou4C$0CdNAXA=5?XhWyYt0;z5VLkE6v
zSeyyie!^pip2TMl`vyo9wWTv3*fVMR&iO_6MEYd4)Q{agrheX$+h?dnBA<XTji0jM
zz!&#!IE^>o+p`vRpX!<TxLg{bs0p*Sjor22M4(?NEa3C@&Y!q*c4207X-;s6DG0?G
z0^8^1)o#Jp+5+0AIdKfFXCPwJf$*pv7llxHKGE5uo5^#5)ZDn`|GM%4x9bK`zwG}_
zErg*O0E$+T;u`-`aRkbP{9)k1_CMl5_rSn(6W!*?OW}Wtm-xejy!6-~WaOdZ-Q}YT
zCj2k_aYJezF4$Y~{@&{ezF@42;02usvgxlNmj#S-{hI1Ok6@iD@vmhGcztx)ALG`U
zf;9G4R5MfQJpL)9dhO$2jb7xU^_#E#1rLsZ@oDZ6U2p5up=7<Sh;4D}C->S`;eKkr
zi@?frKA#`5{*+)Nz{F$`!T*GS_@Dkeyu&m99l&w+k*qfru|U<%;~{G{aS#77i~*5v
zAj+tk1q4JE#yag4Cw)g!<qDe=Q;jtAq+1#DAG;N<d=eV&>w$j8dBdS6_URxesOEJk
z*j!P#C;CBRIP}Cn^hAHqpq3@_8EAC?<^X~+&Nb6+<`gs|X|Ib%scfbuHfXdV9dQ|5
zPLdrMLb6Z%{OE#ZV*iIK>XBbVd6G|$O4`=E<*)aE31%ycL-V3bfpDurQauTmF}yQ%
z)}yE_)HjkReluiL8u3$iHrBp^j)Cz-P7yQf+J}^QX+I?KFb|CchYqnA-OAd9G!4RT
zw>O;kx6#SD@jOMQlK7u>QjNbXC%|0j+g+wa;{$;u)!uml7W7gFIi*0OBb=uqyU<I*
zsR^#TA_1gIx^fX+8=mjWQh@5MOue>#1Q+Rf{LTpO)*;6Pu{yDKk7OP6aqLi9^RSL@
zX#4-rR{<7E))7jy8m*&#>6U0+-7Zz3F^1A1-7Zz4#+aeqhEwgXyCPi_s+kKA@W1bV
zzdDzILck~Z1(*I^0kSpHUH`=sr&HNVTs=4U0uZP!S}_RK{pGgtFH~j*B-`1oPP6xS
z(0X`^+^4<b4Rrn{20qLWt&Je=1zw7VjHK2Z`N@;<hw=+WMnn5?omL#;%plzm_YPsP
zo3fH)$zWIEhA7~*PReV<xp93*T?!-o2JS+!#P2~3mN1Wt*W30K8-Wc~2(?A5PHgnw
z^~uwU`os1L-k3jV6~!cOzZ&(1lI&Qz5`#c<5MvRfU?UZEuuevZ<ue{$W!O%hLQvvZ
z{*gGA&*6_uOt4%Ms0y<8odnmi&2L^q(%J0dmf;zJaS4$R*dP8<f<Ne<xP9@hMsW}U
zqMi3YHRx{s=9ITct8a-+P4A0dfzB5-C0bH~P4z3#qqke<&%7%<2pus5ZoH4Wo~i%f
zP4R5N&smVMK>fMITv0-4Zx55kEwOJ#VFnekJxG-k0a^?8ojOfCd*9t(eR*&%-up++
zA=IV5Yu|fc9o&2AwUWv+V=K$sA3fJz&g{m2zkKD&WfaajzWr@~P$ZH+`RqGyLM@aF
zn-V`h{>{}37@?<tU4*{z`+=A9NCiWu_R&)F3>L%Eb>e~wqSHleDEb3Bmd5rB8c?ZD
zWn@dUQ9Cvk!O~v?zaNSmd<booi$8%E*ER2NNKFn<^P%HMhWYr&1GDZ~J!bZ)ZD*Ou
zr{%DGW3db>@#5RTJYS6;LiNB1tXZi?-{F4{v*_+Bw^`IUEoE_rp=$JkBV7%-T%0QS
z+DBn>6Ji#lpHuyO@Q3&v=oVlE607_b;wU1bU7??5IQ|OuH8NAA<L^bL5IUi7c1YM`
zQ!sj1=p&h}>#KdTU*WHwJHDzfSaWw>W7$thRYrNCUwOgGIkT6Sjnbygp1<|E+t!>+
zZ`gCF)@HBYf21}MU3wmWHviU#S9YWOpBNjW^XC+bu#UnkADJ{@)J%MEUE`>ocb<8r
zb=@5;m;TbeaW4ogBEujRg1tg>^`l5@Y0MY6IN54XafUUW%l3hL*c7m>jW7qmHgvTK
zP$d*?u%@wBZs}a+IG)kUGJb2As70N(zB0aW_{$S(FPK$twDy`)>`nNeD)ZBAOZ#V4
z6yz`_PR2Z=0=p_Vqj1{h9BoDcYA^5f3&k&Y;~g~_+4yj%FDaV<c*Qm_!1h4<z$4<B
z%lsSM0Dc>`CqosJy7@qa#GCg%Rsinqn0z0lTs%?+-h_3mjv2E#DOV&8bENplG)ykf
z=OTZJKXXwnRihm8PG;aK{2liNywgs+mxCzJ?PsASIoy60>SZyxpb`udRjB@heinw5
zDED-;a9@m%_pzD-OnHv8d8Pn!rhiOx7h0){i#r~p9mzKNsFh;7+7KA0E<^YwPPuHE
zLWE@NG*KudaZg`ngpX0o;_sB{^4e@wP>?Enj5=Cg_=-fW^%MIIN6Dzm$g?@HGrct2
z(UoN6U{W;xl2=d(bAPZTI7AkUpTa*IOL$Jsi8zK4`HG!1Jd@IJxpUk<5p}Znd)?`2
z+tH0S{|Eny0F+_bGYQjEdZ&I8rzeUQ)TAb%YZN{GE5Q3OeDDJ!>lERXXGEQr*y2Sc
z1t>GOy<OzJE<XZ0%z5j*xiMpNGf`#noTAvM5UogCl&O(Qz5VkZT~KH$llxRx=f|g;
zwV|brqaWa;qeKd&Z=M;k<~(1eQq(Ntkb1HvIkqG&fA|Qb4lr^x2OiDy_mN68SqU1c
zAFl~nk`tetkv3DRQc0WhOYkPSOoaq0lKP<;CHc+d%Dgmda(qs>e%iRqjPl5N=CGRB
zjiG)VTUs8K6BAglEh|rij4Fvn_@+jp!XL<<P8wa56IEWyvHodQqRr9fd6DHAnd73A
z*&50RpRk?mqof9oke87tQ~?);<oEq5kWULrjiCciq9?$~otu|z9$3stLu7JmY~vlX
zcTI1$E{ybxFU={PS(x3taAJ+GNF)m|1j)Vm*!f3$r)~Il&hX}IOY6$|IH@eiH{L&b
zVQ2L$r8HD2<|N{nqK@(yb7s6*s|g6c6fPHKRL7-HzPC6iw?g1y?kKyLtli_U_mqGW
z*yX9axmt74glCON*Eu2uxTE=D`1_!IU!_7^@69{D@=N3z^9=aMU~)>-=nZV&7M~Y}
zybXE23WaE-H_xc$O>uC>Cmd#7A!_pGdGB?INCLG~$xL(15V69<sKsjLCAC;Z=T|LJ
zIW{r3$=wI3N)Q=D-h+(dj`D5b^PdFr!kwK%!gYf_e}ElBJOi*!_5ZTx>_4t|5<U0-
zW+-@eNSNT)yZ_gr5$Kj{068+oMYmL&-^5SrIr}dA)99M$KO+#hhCzX_0wy%ijIV`*
z=vM$+!=fuVMu@PvLfkCnkbP=+czpT)z~;cL%qwz<lj#ZTzRx~eTwL{Atm~wIQg^1{
zM*61+4ipQpC9FLIpaV?mj&M@%DDmODhJjS-=H}!Z@jpWIz10eFiw{ulSnE2aNNW0_
zxGN>XYzvjjHbg5V-YeLtphiULYC|d0;-qag^Q>B`@)zrOu6F#|lxw!x%$8t;n)=?T
zkoh?kMpg{x(!0C`+6;N%Jkk23#5sX#G;ReBcEYr9(q&o$NFW(BL)r?p)hvaE{*a=g
z1VsQo?5oo$@B=%KDE#i*!AfsK-cfQ`36kX-j+BH8VN!S*<wB8E&%ECMaj1#)bBt|7
zIUJYMz#R0IXmX5>MCQ%V9Ha$SOqWycb7BN83*-y<0<M=Ye*!nV26w2Z#$(Ju#$@G%
z;~%I%5jS{qxS5x&|9ugI?sZBXB4ZRvQKOHmcSOdJook8k5Jbs!LI%HtK(Y+V9H*FZ
z>gcbijs{%fq^m4;H_35w_M4O)AJS!^4!IBsa`{83)Xd5Y!k=mKOX_hmC%qjGKG(tl
z%nK)xX_Vqd8OzFUBXkqT{M+FzmkO#Xj=2QG4pr_nVud4(oTc~|kK^hgH&I05QqFdE
z(RRYh6=<gw<f9B|$pi;<uP=Aj#t?}JE14mns5Wr23`P4hX(FHJDpK+3)C%7Kf7uFe
zKIic^MY^8d%ZxcuZFD5beRM1xKaEtyTsG7`1n7;t8&_~u@GcRt$N}HN`b6#n{v_aB
zVePmeoe3J#iM{D^8URW{NQfeF!gCgTFkL_7%$OtCoZ3=KE#U!PNwJ;_(s3WOO*zt3
zo{|`3IC#hql$cW9bYx0f>y-N%>A6D(>AA-HrnDaCrIEIglTuSBw%enzCUw$CTcnha
zwzp42FFt(7-Ep19wTqL~NQ(cXPFlRy*co^C9S@({b~Nc6J&*r`r1bo`q@&yR&#-lu
zcWiJR-@0^61v6qpM|rnx#>ZopLYK)H!1})_bPPrdbOLzx5YP!(dm=zF&_yIr2ngSu
zTR@E~;DMnh$lmb+p5+d?Kx;p~P0H4n<Od^pc;4+GOYe0Z+$LiM(CPxGIsOs_b19Cn
zFw#in4jFTG@StN5n?f_4^t>JT7^voYKBiOTEMQMe4ze1X7Pu!<GSoBa;%6!>x96Gg
z7hxbQm7>w!qW{C(djLdrWq-ijH}6eh2AIMO3}u+Y&^ru6?;t3mD4?Pg5qs~wccaD<
zYZ4QUF~$;&n%+z_CefHpHf7T{n`F~>Q+Csoxqj!~_omUr<p1sW{rS6L9s_glIp>~x
z>hEkmx2<I?tJqLn@M><Ez0Q|gHF?hhv2SZ?kqLzw3W>tB2YM<@G;HmFL90Jhi?wVa
zoCUQk@NX@X*B}F^Q7U`H#Lfnd34V$X)Hwi+q00c`kvV{G1H_e>CEms@sZ#0wISod3
z^L`N2baC$QzbUNZA$6Qa=~tvcei~S+Qc{lw7uK`zs8E48P)=&4w5|jV>h!KUILG;L
zZj%72lCUAs;p_D(GlBWV{j*G^G|(wCVj?rG-ZBHTEqd6%AJ~{vw8Spax`yR}Dha>Q
zLO&!8?y^x7Q3QMU+9-WjfV58TPaP&Id%2pBzHfR|e1Ha01%5j4l88MA(Jb~loS!K2
zozo)*IU^o1y$h+Da$n0ru#V)NsXNSGpWeR0@o*Lz1*09SciLjr*$K==;W|dXi>7aQ
zU||zhTc2-U=Jtm#Mfeq@>_GfAj9<$iuyFWPmmds%`i&dh6L2<SAl3+{y7T$)iUfI{
z0O#^u4!!GqyKcD7%jceOS{U@uh~=#*g=XjZ;0+2K?sWLU{)mB}%3Y@i`7Vb2EgE%$
z`ui@+<E2hV<~dg&;F8Br@T=bY2HTp(Ck}Y?;ubdJ4o%!-r5>E<c|jx|@tNo<_+bz#
z;4OU;*`YB*(3IqQaE2FM!9{0=+nL|y{V>thJ^Mb|`f&(j(1@Av{Fc=v6(1<;a*gX^
zM^Dj5gon(DT7FpkR(18XQT2LhDD}h2mhJd({~q+0m$%(<c!`YD2TI0f)`!-ipp=3M
zA)$Fq$TG?_sDFESC<+G;Y{ax(q(2|l%bkMt^6^Ax_lD)>;Y6npIU!#qUhzb@22U+q
zcJAzwMa-`^HHLmy&0BQzk);cd?@!BEU7nR$zHUu<Cc5(Cww>FzywIy9^w^5Ed$ylJ
z(Jh7@bMHR9{Qd`4@c!0k>|i*bxjyCOBv9*=k0X+fHG-}t+~_2-MtH)<5j#f_&31^<
zklzM0Lw0aU#(NnhTcq5<CsA?v5<YmKEhE7Lg(h~~H=E~dMjybvm#B>lD8_HAt>gat
z3lVMxgawtJB~Je=Tei#Tud)t|DcLi>Jg0yS_EkA@Bf+IaCs38a|B0tvHquOv;Ea-Z
z3)I7kzVdj!!u9+zc@FoB4v%I>a#zW_iQLh0389Dr?r}K&w8X{9R(CZliMZqf0s~3v
z!B`C1wV_Jq@z>aqGiG18ZEuWR6!PzF%VT6kL+@EUq(79@y%-nyDy@h;8612vK|dM>
z2HYDQj9Z!5qwOy&UxL2)`P~mzH=4C##F`(u7iX70vgPra<5u7?o|Sc?zePk;4AUwY
z0N?v2A_6aJnz3ag-6M_Zk-dw)qkF#~x=i=zJX?8Wk9^RS?8;peD^$etOr=wufY+px
zR|pZO1rZxgE4pe5ljs{pPOGkdOMG~F)a(#Lgnmj}%sOLko$`Z<l2xsF21cwgFd={6
z^3nd?d-i|0V_B6vAcR>K8s6T2kZBbDs3|WrWI{m-{<<!-K69)jP|wMh9KK`Q%a^wA
zn${9vgyr&fF7pGma~t^Aux<=J2V$RU^7_Ul5Y`5c@bW)&pO-~|h5*k=FV8CaKBy5S
zXB2D)VjmZinn6Kfd%D9!!29SS^08zPYT+sp`w~U{&u*N>bgMPps_++_#dcy)fbH|z
zqUjrtE*y11ZC%&IUryk!bn+W5$w}sfAjZpY>~vw#m<aa|>XVJ`x+gCe#e1jDJeX7c
z^x&0s-Y55u>Fuyj;@#i6gQieJyfx7D4u5f7QCqhPfokfjjld7|?5kZynND8~Y(dZK
z3*-Y@QP_!aX2m{VQ~3b-X6vZj^YU<k<>iKtACdF$BbAdE*j6eR)R&=gCCJwI99QzL
zC8fhWiN+(QJ_)3dD3dl2I!QnY(3hg;I>(JRZ_UQ*$DXXtDHsu*Q6HPvRBX&tTkvzb
zl#uEL!wgpzTzk)d?6H9IQJo?~j%#RR$Mm05GWw59kE->J8kM*ru3qGq=`Ur<q|!2E
z*Eo(dO0%+&yo4=L8@~{I^}7fTkE?!^Sj*ndh}$;ta7bJaiA~Jr;sIK2BB#au6)}>*
zzAlGEp;bwTdO9VFK$UC=b!S`J+FE+`NT~ITd}hG>hGmeaii8C#A?qNrFd|D7bW5tz
zmC%c$w!_RMHH}8YJQk5jCtikECLBL18+$5l==s<!mtPoCv9WNd_Npo-b!z>9+ZTbq
zz^-%*b2!eSJMc63`e0N&8*M^wIKIMTAF4y*?@<7H7=QTeSD!sR^6w}M6{0c239U9k
zpHLa-1>!gJ>!1a<0H4J#1h9l*A+RFC+H@UPhW~0@zeHNT+fZ6vX`X&;Tb_MVMq$V?
z{ied~i6cH!iu5=dA6<bouf1rWHDxG#Y92uTeKjZNfg{hM2)qg7xkWqQ{`9ka&`A(s
z5T}Xrz-I(+jLM!nw@Z{Van#AJ;x;Gg4Fpq}c_@2xr-FQ%icfRrr)S@l*A$YZL+^J<
z{C=cM4r|T1e`1%6wMPaxu{1Pp1M;2Xk)ED{f7u)xT#7?Hi)tBSr@{P!vw)*k<kCar
zOb}b1--n&<!|n5%_-<0zj%y1pb;>?V?OtNp51gG)9B5Oc_Vknx6Y=s>($P4zO&Jwg
z6;fPItbC$KsTJ&D<^RQ^4jc8-N#n*9$r|d>C$HFOJo!>(M3@*^@C8rnm*%o1hanf-
zPB`GY4_WBFgn3#j3+Z*>M_5n;$Fn=64+>T=7)ZJp8~}Q6N)EdlNxst}{fheZ^!gR}
z3(|qtwSfd*x@jUgPj~)B6yV)uvL3frPQi^+Dsl8CuNITPBGXM1%R>JN)gzyAZ-HGq
z&Wko;5!EDwI7BqzkdoKlmO}Kc8^4q~+*_tluqsAP9XQ~U=9OWgkvTb$p~J3lU-m0r
z-I8x$IE?{?e!TU)eY?2#ZfX*L5V&*qRbq80^-im!0spQF9*p0p4N~DZMtGPV+csb9
z)kuDP#TvmTfpZHPXz^^QbI&53Mefc=kyu4DkXmBzLfDqzhAE>(G%Xp#hjMiu<3*4h
z=``tT@oYL}ME~x6(xBzlg>M&DFAtLL`$U!=n?(kWtS(|=0xgjm#ujeW)i~Dt<(<2e
znG{l3l9!T+-dcsXr-k{)kiw@J|FASPdOfykg51DEJj_s`zYH<Yq4PL<K7JR0!%b}m
z_IuGQ&{+hxgy$aUh(&<tbMGO8-$VC12+Cx?e`@H^qNVD)r?UQI%aZR+DIM$2j=N7h
z;|@c9!?+}LugYXnp$9|aeG{<n?YqXt#<7qEiU_x$lo4N;l@c9^@<0=>`NL88Rk>dd
zlSh6&OcZD~cU(?m0MqHO05ShX)&0lGx`Fo6{{rpXeI|RayAQP2+`^Hi719Lf)GqKz
z`rpocTA}me(@&0)n;ll>eH8L1n8_f=OFdVG3}l9pu`}KCTKop^dJM^(-4d_+LNS*W
zsR6%$N6aE53(6F~@zfA17}Gfa_R{2o$))Z7-1z&r={pSt_2ZHr!oD{>!i??>wGpJ}
z7)Vb%_TAcN=|KbVZ9Q9*U!W~rg^S7-_XF4@<s`;#g~_(GrUU}h#O3oi5)@R4_=oTg
zXO+EOZRL$YlNQQuS<+5Sz9@n%MBqUQAWbIs0~rYtB$f^xb-z@%qPp<q!fKGB`$r9x
zii2V%4YP!6wK0AyXN05riMiO=$X>rR4BtR67&(?s6v2(LmPC9#Dk=jh{-M(8M%h=M
zn7h*Gc*3m%n105Ub5E?akJ1Im#gf2gn2&Tg8J$gsLRV-BS%x>J;HI*&X7F$2?CN;E
zR-p>_!?V#qJ+U2my|5YVp$ZaZb<?1G3V80H+>bPd56Lu-QUaa`@J3LLfHJZ<vZNjc
z>iT^FBGE5?PkcWRi7)&(jj_HYGFYV!k%>fs-zKJR?PrXf$#Q$gYj>0<y{8e0WFcx*
zFuuR=?E#OkGwJok(IbCO!fOJgyz-C+pe0E^kBlzXE2UyiksqJ%O_`tgiBW1zS(#{(
z?s2KI>hB5h`3g=fW&Ty15%}!`u})pG25ReO`K<8VYajVd;6gw>fLip<uynE4z{K$o
z4M1b*UO1#{`X(H@ZyYT*Q#7KLp7JwcAOh$5&q$DYuH(6$HBY^#c*zZu@$)?i7?m&a
zQt(-4_$>0Id0*tK5A=4X-%K}^MDfy_OJcw_oC_+d#DIU&myrCaQ0Pz+2C>)@Qs^*J
zCSq3qX<<EGk2iF$tb(Ne`0Ja<G4d&a{9A+gl+Rqjix3K7iP9p7|8N8eb_=b@<jee^
z{n<!|2w21<cEtzph^IlVbsG4h_FNE*c!#{ED;X3`ZCJ>iTg-NV1qA&jv=B8MS#iO*
z)L4`ls|$|G__5#a3^QP;2AgW~-p!l1JHMnQVqpX_ym)tX&A{j=g>vn=F}uePn}1+h
zTL|mttB+-5j48B!>4_;^UY=i_Dq0($5{;W}NDoU&Nnto{@x7Bb;AJNk-+{)Tt}hA5
z$|#93M=x$JJX#kP({}Hq(KSQWKi>5yg61QMuU|>~-O~$gCArmsQGrRnq}JDnk&hfE
z@TMX3)3*iYkfbEB{CZ$P%@TaAP2V^LNCq=&{w5m69`%_{BvR-J2Zc@T+8)T4=0QH{
z8FWuQpr}ASvxK+*iH||+tb`(=VXMaM0tl~!Ttkp`M3a3%Y$$6EQ0eUP_azUVmtw09
z8X5H3*4g2?IpNXa<JMMAsVp2ex3)qp5&MS3APHj*E*LU(peQYkt(93K6xGA^35D?y
z(ukbJLnb;F4r;x=G&j+=G&VRcHm)LRQLb8FGPAneo~zi~J`Wkxa)~UysJ%SK93PdU
z3Dm^iA8(JBJt|3NL@DU(x%Bkd@a#na@%G_IEA@F06eY9*`wQ;Ka#9Dt$4JRN2w(I7
zgS0u-Atj!Tpx8UVdK#-01(zd1vnOAWb>w~!E<x3XE$_<%Zwts$2;;S~0&WYGzrSUJ
zN>F7^b=h*rHD2qVD#@W1=Vi)%;=BPr+_FQ4zks<~be19m-=GlLjx8SwY6|9S*;k%j
zw?Bfpq*uj>NFRhKPNjF`MC@O87H(3qZxTP+EV{SLzNy9Uv2WfR%0~nhf&c2`zS+&;
zzJcWa^BX_uustZ&H#wjr1OFqVBtWl|k5Nbtzu`x&L6tg~D6T+OoKrHB^F3XXfg&<W
zPWy5*OLD|)Ah}0HwJI4SA-CYJwszUM6bZ|hU?QDg@HyF~UBXSM)ECDz&Tbe3GwuRl
z!X2@~nIKsJP6{5=FuO4Z3Ta4gA9_G(e-fGVm<oir*_=mEC`5}`fSEkXLLa6*W|ux%
z@p;@>Ykpus*_e`#Qd*O5HujOJ`F-ZhaYg;6E~NDbq!t)r#C|Y)B9X`?R0H$K!=U@R
zRQ<YE$ghu90bj)5ZrJ=%=W<^|;*#WjhH`zZabw~g=Hdui{)@t2d}Y^O?=oK$aImUs
zUquZ$A2;6Q9MG?4CF`KoMs`9EzNCj}VLn<&%pnSgqvISSqcRGE!fI_eP7$H?!wm|*
zkWHJWz18o28LCCAs~47zV;_NL(0+lw>#ny(FzhE5|1je4<@$wmM2r6N9F%<#`TP{{
zV~_Fpy;P}_*6{8=7N&&4&e`3A28MH--HHz=!c|KAj8v+cHf!iTMN7rMAbnn&txlBD
zufh^k*YQ~hBO0icD)YfDGl-Rr<;<e>pamfIO7|*h_K9MF>X2V~gEP>+eYzI04?Iue
zpOY9YktJLuTMDt39H>nviw63@<wMBRsZ))QuL6Fg$W1YbuWB;M<UOL1xz1t;cNc$q
z5k178LD|x(0ck;@sb;Yi?`b>j6?lysdCU+R)YdpB^X$sk^X6&e%Nnv1lCOW>c`)hA
z#e)vEj%^$M_p;jiTG|>LKNVRARAp#<%M?u=^SxrS?SS|F)i9Mm1uMzt90ztFOXlPQ
z)|m612ACdt_ra?pGodVg(?{ptYt6FX2Be`iG*yzxAj5<<Bry5MY2yxJ^R#k73Q>DN
zGWk}i($TMnQ9QR!3%s$1;XUAc-S89NE6#*IpK{neu$Ln^op4r3+NqG>ufwRVOsg{q
z1wRWwWRM%66-ARPI~lqiDdH8qW+MQmG*W!;k&Ae37*iM%V=yscc*BcFk6c8H!x)nx
zCZ>=HLknI!dKsT+pK6i8)CtS<(fBy3bH76M%>DT1b8l%j`AVZwg7i^R-%Xm=&mdnU
z7ar<^QiO;2AL#hqN%B*P$tQi|cjIZe9$r0^n0x|W5&japw~14-#jrmi&(LLm#18AS
zKavrSrUqFu1OFjIjld{_GXSN=kRMhq-HHFHX6#0j-oR+^mv<~*wiAVF7=zwqv@>d?
z-?{wwwF*Fvl4x}jCivv!IoHYuN}(uPCuZ~~rp!TaJi2(Ba)?9{5vdG}kVu9EY+Zcr
z(IwlIwNkNBqlz?&rM1efi!LDj_;6`#O}N2#ifYW1llUum8B-HxkWE&NfjA6*Pl$&|
z`unIs^AY(4mPEqAj#iV(2YMhm37mAWswh{<W&xvv&mt2m6c|hROUA1}nL5q3l9WHm
zGt(;;dQhx3U^usS@{}p~y@huVu?|A2_VGh%8%ylPI4QLM_)tk~*r3>`wEZH#sjI*J
zE>D{G-M6c!9()MZ;y4uDT#~B`o;WdBms`?|qTxyHLkGpJh41_rkMy~Ad#-7=dZk`!
zl7=M=O)*DYKiBc($G`si@sk~B#4GR1;`NSN$JU8W?K9e^s+TTRPla!qCNi^_Q~G$>
z`>&Am3-gcO<6ibrfd+=!5!e1Hvsj3b_PBk>eDG2Z1`uqYp3-gzK!_qtnwikt+=_2Z
z-dJUgsIFT)9fcMpX5)396ktZcaEDKfQsXDiX*BwTrDM{fb-^ty!Mf<QF-sHlbSe$|
zF`>ZH{zE=D&GX!U$1<2!LnhI|yqf=R;^);oIQ-6WgQm?MHzQ!qoPZhQW=|V5?#|&4
zx+d2!d`?GVhKbZ!Kmp$82uBvczZH@heaiH3gKV;7>+Q$;AHUt2EVJoFr%~lib3bBc
zvpH<|tXadu%$t$X(Q?a~AaX`&E(r1%8j4BQ&H6Qc$Pls1ZGL*={EhuL&Nu4)VEO(Z
z-y~(k?pzZQP1YVAu?E&YuCECsICo%g;7ZyLP6h(Noxz)&l-~5*(33~+#I9pk1fA;4
zOtAln2o)<V>8%r1O&qs#P-RWSftJR+9NIwa)fb6>e(u86D=3iW9CV_F5M$oF<u&zb
zmG^Fc_=#PI%VJe{2<afE-ME14ghnf#djZs@`lX8=xdrgKNR1DvmlW3Bb=95MoKNB?
zbkYUyOpzi4u`Hzi`GEr_=VoLV&Z#I#$b?#KuY$zOx9>zbZ|+!DsetN(%FytbnrBSO
z6I<piYMY!G8i4;A$I>!GNWp)uShe<%XHWni=||9|6d;-ad143_0YJ0G9Do3sSp@%x
zCI)12t6fJ@A9lcf*T6q|Xzij2{xRW2d6QR0&e*#ua)#BK++T@b_fH5eEI~DkOq2I5
zF;AHq*<UGo-J)6bb!=4?ek!V}s=9itJt-k_n>k=9bIwv#jw;}PzN}6vi2y?qWV0ii
zopR%GLBIHjoZ7WF?NWJDEz#5AhwXMuVdvji%RLFR`sk;@?m?FWjwEb&aedR+&)Ztd
zf=m9=jzrm@mR~RY+mA+M`Bwy4D{_e0z4&YHE;vWPTUaWv3=}%~3)FbSUuUO8Wy-B<
z+d~(gFG<Vf#3=<iQSx}X@tFF9xP-2M!}H=00vPz~(Dt=fd1h2fc4k`1dG>krF(dqi
zsGNe7qJ%hDKf`Xg@o(-pS%XLdQWH&f02x(Eu^^qg|A3bUR8L51%Lyu&RgqJ_A?Da8
z?0dDr_14JLs_>P&vg?cLU?I}q`#W|sN5tiz*DX-<+s|hN<Q<m!+zvbA^#l2v^ezK@
z?k-QdzUTkyNjIOhS})4UEGo9;ih{HAh7HTha+Gv_BKoZJliyoAKjD^le$w?lUH?wk
z&tmNb@zK%o1&tL022{M_@%{CS9xs@&9xtxNc)alXiP!IV{xQm<DUM2JjkpzNGQ~nJ
zdMIQ$milb>d4NbC^+ugWhafw=zVQr)L7d)cY7(=AH#*$U$P+m5G?)fYiPu8qSrBdF
zknolav1%YNB=q084RP`g=Wp{>Wz_d{zEy`>LP2<2qS6hKsinDtrXj0R6_lK<G-R4n
z6Qffn4pU!$CC!{<2wkA}547}~<yetstxk-w1j=H3^8>@<xEj~D^aqYo;f?f{I>z#U
z!~HjrjC_jwGugMCe~JEj$6@jz!Uu}ZI@cilKEA*&Quy_26FmM<X)gW&R_p$x#Awkb
z_qx*@BR!X$M)G;M9(q(?hB_V+isS7;ARr;RyRS<|n+OPwz8i(&{}ucn{8)HmQpqU%
zi4*0|jQp!5?fnw)errGCB`j1+B&sz8)vqnFLS~gM)<~I;1J(&Je=@7@BDGYiJ|mvy
z)!p@b7OvNg8g-jB@ecw4f&YL{3H@(Vd!~~{L}r)RNPmH=;_LsF9=Knk!%}P&Uy@R=
zKhqD`snqG(A$&SCvUz+&;vef06mmL%myib--Z285Ts1WSv<rhH$%G`K8k>i)Bvmt>
zC<&J@A4bdYs$NQCL<1pzjsH=AuX)$Oq{ChFj%XizcC-*lc6E8fXTxYX_-w84*{*UI
zck%Szy|*JH{=~bu+g&o9od5ju`FDF(uQ>Nh@PQ&pg(EpXk|2r5D^sGg5Z8f+oN;|P
z$w;b9(RNKH`|7$ycdyIbgWr;<&sFB*C(|mc)QdpO)ekd|J+yKEt9uSTY4g`0zm1vu
zei6N~d&+3PuVCm0PBSW_X*d-{1(?`SqcWB&Xr6TB;Oz>3o8!BGMc`inMxEw+M5iI2
z80o~Xfc3emLm({()pOmhk95F;O_eD+-8Ot)Th8n^S@~^6Nk3bQi~Sp*-BiAj(XO4e
z@Z^+vo2}|oV{+ykXYL%=zr=r!;VgbrBlBoFzo3!n*n;Bzb0>_1=J&(<4UZ7Bgv7Dg
zY2peRrxVcxEwPfj%jQA9J2CRuX)%sh(*pvf>d*Qo;Z^oZsRjlRsw4nS$Q(X4up~rW
zfuDlCU;mp<<w2P62xXM0pd@PxjnUl@O=hd<XG;3=nWD)iJgEC7dq%R<o*c+l|GTF)
z`*<r9h4TAc3i3hXqQpKSBqywgQ_$Uh$r*uI8tj=}>VjKj20Ko7-uC6ouyK|Vt>tkR
z9dCjo;<<5js*H)Fd#CmsiJw!9fm>dO2i5?37MFC!8`!(o3vmGNEXJRDf)1eIVl>%>
zJ3#!U!R$jo4+w8tDRv2%hP)XsWN^AA3r`YSbte!I#%}?7$wQBw!C%gsH)C-8={G)^
z(>`wQN0~XDDMjhz#I96ova(Rv=|`W&U!Qm|FQ?gf>VfUwezoI4h2u$2>Up79`rB}e
z^q%_#IzlV#J~&U{?^y#`aQOb%;=v#h?Ze;v?fmwX4f_t)R}H8?6dBc-wv@67E~p2q
z_5JmmH=O_WPUFI<EqCs1ohHF6JxML#JKzgE_yhhAJ9QQ;n$Ub6#gW_xFQ_R_qj=r)
zC+mo!B6d1>S3R{DWZM64aU_KXDW$ZnX;{<1H1q!wN>U^bIgao=)xqNtfyVzemZZv*
z!TB2W{saRG@(1{P@md~>g7S#uuK<Gsj0vJMJP$=*n8b7W{|1Z#7!-!U0AD-5%%U{a
zg#EA3C>W`7E&g6RJx3E87WBUZqmT!NixlzDBuCCoBgOf2=2}U<owtx(haO@$PUIyL
ziU5y-IJ(3SAz$7}X|MshKz}}Y-?K}sg9@_B?rO6Zv_^)TpTfUwy>%qev-2jPQbR#i
zaeVag&?y?7xoCgTp<9Lq<>hcS#o&O95y{09APtW_lMRs}WFDLDeb3#&a%@?+W3IV>
zc6#BCMr+oHL3x3V7be^?O2?8R6>L#xZfRbO<?hfiWeEk^YW0*`h3(*VBgOY5mvyhY
z(PhxnyXe;NJ)Js^JK~|^{shG5P4!kEF+O=vTdIh{Lx>`xdWfCJV_A6UAt)v9qKCRA
zh_e{6H!ur9p|JBj70Mq*vk-wl*sGf8JD7#*=o7hsy!#QzBaat637QAv$q=owz*l$H
zTQ{Nso!jYrbp?bRNZ}3~9Rcj8GnTRo|Fy7mO2Jb%0e~G}S8%?aosr$zHwf7I&Fw*W
zKHBDiliZDr1fW2CEq$NlmnFTR!IE4z^!R{`jO|PtsNCxdX`Dg=rbN1yDoTMiF4BP3
z5wceBV~Bb>VNZrtl`Om&>`8G}$%(;9ve@E20iRSY(%|1=*s>ers2h1f(x*-)o@n>W
z=?MU(S9$TizFo(LxTIYK26{`tNBuv*3kLr{b*3T}HMkJ9=itqM4mDUbsNn8Ue~Sw#
zdso4CHv<lK%L?=`@U>k%*`7Vpg_jndFukc2nhNj~768raqE)E7;*F9MjKBJGNI5C_
zt^Uv;OS2dtJdOFAdj-p(vLZ3}1ydS=mO|)&dOcnspna1OiMb1=^r`rM6w}`WD0CA5
zh1LZ{|8eo4kd+=-qVmB0c*ISFgJ7n7#?1mf($tG=@F5DILr=g2ULuicgVYdjwRq|e
zZdMoABx9jBbivc4IW#{Y_z#N$1^jaZ97v$s;$JtD1B$a;LQq_swufiru=@xBy@#D0
zq%^4l(FAXF5aB7gq3AdSHv;p|&baC=O;6#&s!q^bI`@FaQ5kjb%}nn*r=|e-dPgvY
zXcjPUc{}4U)FHS0;k`R=kxrX;KJE_H<-#B9ofW{1I>El&GRRSDXDk?qfk_rZ{X6s_
zdc=k_-B}j5E(<2fLRSC@K}g&iTECC{cL$iRf8ee^hj}@D;CwEPJwV)vdj$AA^#5d!
zPUbp!ZsHz+@JPl^f`o|xTI-KNSa|?u+TC^FeS@&dr9Q-9$#JfT)TZ_v(}Ke&)aLR^
zopQAELpa<}LJu7rW@jZmjdMwkcN6CV>}~mIo~t!^`e?@)@}LbK?6vkI58x%5$Q1+7
zwS1vc+*8==*^mIE1YmQZo{^w<&%J(|_k$>SDF!gCX#Y^$Orv1r?0&?(2mQ@Zl6;dG
zSf8-E;Le7+qWAb{*!um4>-y7Z7-0JF>~!LHQFt-|zl%WV0Df0DA+a?|0dkUpdbwY?
zLA~%#G%!YL-rnY}Ks{tK>7cbjHZfZ4o;wzSh#GYcadgdHCC)G{kMu0-3(DlKG+Z4z
zZpKOc_4&shJ&%I*N*UBQj>6ZFtf_V0P<&?Wf~THeK4oOny_xn?{oc;1XkVNWVau8L
z?%oSYNgw<b0iMa*e@8afwg*Gg=sj66pQELJx$w;=&;Iq<2TwJdk1+BLkAC^zoiE<C
z<L>s;d|dxCb`I2UB$EmbVePz+0_5b^E>=Oc8VDQlI4F%ftsPvLOm<G?!GeMHtKQkU
zW%JIzX#(XYRlm~nFO*gEw|_sdY3H7{p~a<hA`HvyN1{@zw(r|JcZb2Sd)tKzJN7eK
zta%Ln7{5F*Qgc_wmUV~jTz&hpnR840XQQEw^Y-B7pKq8;&qgDykD;?tJnCZv!V1>E
zHqfV2q=65fME6`H1B2k`*v!pe#jAW-O)!4@%2KaLN=ax7cAPv;#%*@4lo2Lr9$T9+
z++?|o-{-tyC&{HDgCbsk6)DL4O}=7=0gScPB7*l8!$*Ee7MWVI0%6^i#!jkJ$3^50
z7tzp(ow_wJEO){`V2tdlb(a=4&m0|>-9Bh{Uf$6&uIaI}T)~l=yu85h<}p!4SZBMk
zbL+)dcI?e8n$eyW*UZ(JoAE37wN^8kC+qk{2!y2d&&aTZrP+*jK3)y6Upk*6h3H=<
z%9Zs1V;lx01qmS!&%`e1Ad68fg5GzoBvrQ-|CXc-^3@;)4Rg+Mz>{U+!Tyh{rQxd7
z8$PSFDUs}>qP0joU*;co{SCb?R>TiHDiVey<)dhoflZ0`lP<mCgPx@KLLL5vH9{Oc
zS-2OV9DpF^8BjV&^#=iQ$rlgdCfLAy0SRE|8KHP3X>UoQ+`nxG(_EJ9pBo!)Da8lZ
zM#D#>=o0oNTIEpqwT~HkZ&GGVmgAgFrS<nM*S)1lRgNkO)R#!4!KzfIdXR$4OgxAx
zX)QJMReS(<v6%GZg527mu8Uyok(zt4L`2+uR|leVH~}%*1oR0gtn@&iU<Yi?`W5hc
z%OY+V$|b4*St9@{ej1#htz9q-eYL3L1HW<W)5=GQhM_HvJ-Asb4=mxh62NFyqaDn1
zd43W^pd~T`9J?5^Q7s@#fZrgj5pGt<A`wrKEDKg6Tr4gZ%4DM*Z$hm*o%c>>tnm-H
z4^9rkYtS}4-8WzWGp;HVpSM>@)sRh7OYkhT1-F~?we8Eko>dh*!w<Eia_!7JtJ<14
zc7<b48GhERah8_(hokB;=3thBB`q5%{#wUVjLIB55MFuFkkps~4N3B~TROsWZN1YH
z3P#`SOwU(QMvpWNgLQgRwW^Hkjjk|r%m;Yi57sFh2(ZH;u-SQvuFPYVAf?bzN>4T4
zQXrPdXumQ&SOAkQOc{H51wN0z)Wlhm`p+$X=i&%dig%l#wRFalr~0iRU8J$*q}naP
zpFpGOkLX@Yk#QtsB%B9_%k)K`;kK|qXcVP)^lJ1GW1+pIKyl8-caCb~g8{mdOb=Ox
z=Q?h)`AHaIxCC!!KLz$zY3IGsNxVW^e41V3y)(X+&bcoUzb`FpnSE+(l040-Hy7R8
z`sJ&Nrjp^Q$M+Te8~-=hrm1Y+yt=6M{6YE1ev{N^_7}X2Y#|xyD&&Ik&SOIXlotP2
z3H@OC93Y;eTr|lf5dml)S0D<NU3<r0o&t?9fZ#U-J8-jE${-5s4d-zP<giM>#)7<|
zlSf232s3G%s=<xR;pGuU5vPy`<fPn@mN>a{?K3)(MnLLd#|pR{qDAg`d_B#iN#pT3
zcu0=x%URb*K162Jc#Wii_2)x=XByZ{1XE3rF<!ZOV03tba(H0E!0KV`aC7i^m}yQ9
zbcAn~vI0bhXf(ibL|X_f2eS#FDnpQx;#TSt0xMkfr?@bGrRW?28i#}F2COocAOylP
zN#0Og3+Dnlk)3Py^iTOKkWW|h@o-`>@pJ~W!;1s7Dan%s;#wyQZU{r5`ZQ4orhIhv
zLsiB;&eiD%^OzDu_6IpP_BS{iz3uN7@i+;W0_j2d&B><Aw*<^d80J1P`2?A&F94lw
z-T0Pt22w3W9Dr-zU6CY~Xe~DAP6GR-d*%hvkabV|gZqZ_o`rPh#S&k6mvKmgs#lgg
zf1ukTE(AUU3X>Vr8Pg*Vbu$ua<Iur==wob@UF>c!5|vHT4@huSs|h-ucLzA#p9Hqo
z9q+o^o71c822FL^`f_n6Jk=M<*G=yoPj!NB$vo5<Q}r}VcE``k2vAZdU{(IC!9IS1
zvo^rRFJij$bwgCUk(<-$LAoyb?t($o@Pw=#{RQr)s-gHNVL;WGQ5%~lwZm0^w%3BX
z`Z)`xKDulZ47Y+Sh0LfzRU7MSQj+@N1a}O;KZ1>k@aJb%L3qdU^We0M_NnLaDKgxO
zoGswb?Z6-Cw(;f<Fomdzn{UU-6>4EqR1`aVyO)DckZo@YVL|b51=MX4vUwlCZSf~=
zH@`D7^#cSA_kHqn;0yH;C2`;*+6lH2m|VmTH1ch5)SVJjj}f})oZbN6UlUD?SiV&V
z>Qp2Qn6jW6MUuGd4~<#!C5nAk9;{GD$Qrlrdm4ZB++(8ii+7}D4$U4oAgj?RUOw@m
zn3In}R^pknPltXnYV4SiUxhN4)%cljQA(gy87WttY#aZ<8z@X~wKmUuu%WDfRaVx3
z0V>6vV``1p9z6Hj#n;j7^`ysbGu;Eh$6QE#Mba0-?*U|s7TUthX}a>x>(_CD97*6O
zQ~<e!9nV!YKKTA-YoJNG3x5DEBeQ+v^q7Rwq@sc(djy9<%xi9Y`t@y_4h0=9?O$1P
zBnW-NJh)`v%QmyGAHD%@qrWD!sAg_{YG!79T$bfr+R<4HZr`~2y9SGS*mtxR^(v)x
z4z*S~)0*L+)SF(Nsy|BZ`|-<W$!v-FKlkjvRf^*asWb1nXJ+*4uOOd3k)77wrBb?Q
z&|BY|?j%ah?*_c{TO|IH?}Ee=#X*lRn0pHhc*j~beR@^+){Uon<pKx@@iXY0bLhJO
zv>LCwqdSGe`yk8#uO^k=^gi2l9+&g1N!!F^uJkEb2Jbr4N(0YYWcTy#lF~Y&GKskU
z4=b36o=#8W&UQu|WKOwrFaO)wxSeKT|NhedSF>_S{VB}Yq4<s``@+-zKNLI>e$uRS
z*IDGxy7Nf?%XvJV>a?$${=b>e1GSrgMp^FzwL!GA!!up4?OMzk&7)FuXS9&037v){
zcnr>DCO47HdybCFH};?R-m*2`QSa92Z%n-FCS?(>6efF>&Tm$ZyCZ!;PQso8-+2~%
z{$u+CvOq=ewGcFW32KS@2_Lahkf#J&n(scL1sq`NgFg&rw5u45bPD%m*SL1<G;5rB
zOEwCoFv+qC#@#uh8Gj80p{eUhL1;zo-s<T$D|K)sD@EmGrjl&VGJE9M$#*$RM0d7K
z75hnhFKyscl>9!S7lh9EtpL5>O~(h-{ZzF|z-j=+3|fyAhw0MOG%%MP%mk9S5ID+T
z3f$|?j*ct0HtN@-U*lE={t}<=V~C62NxImr!X7+*R?j`~jd31(Ai*5(NoRBx%?+PO
zvn3<%r)~g-dz?li#_t9f7PJKgQV;GHX3~`53T`d<0pyIiXz7eL^8}9uf|G0R)^mdN
z&~a<|eD1vI+ZQ&C%}-4(SlVyLnCxUnA9I4xd($3Y!LbaO{ny^#GJ0f1_1x6r!sHpu
ztg%BUi{yRE2@B`yZ*-;&=~s6H-+FJBhob1yW}PR?nH;3MWpjn>ZPTzBO;xqFm}py_
ztq~x1ZgIeks1?C*td33XWrZo3by2A)k^N;kg_-3H(<^SJbIc9hFYUDg-a=<%cjxO*
zcT|bPoTu&2_D^{nzdtxPot#554~^tRyE%t{zAK77$)C&I&;D!|l-F6k_1S1NPDW!b
zB#z`dvn2HfBRuI07ZQGyfQqz5*{Fdk?j`sFXWKLK!rkD9_{uaZeAQa%jS;El^pb$=
zvSH|i-v8zyGdQMXqVy+5RV2!f3m>^4aFAaS%7P)F3N}5g9R2fV6RBZKG)_ihErYzy
zY1a*c{><>$V0YmcqPje{$L<jZ(un0F#VU>ba*<hY&C$?VkxJj2%(8(qNr%(W_7eAu
z$Uv>XC|s3*l6sqKL-s|^Bbg0f<aHi-<!a%fd!Wvf*e|3_iU!MQYmRFUnES4?i=TC#
zz3;0FgJT#R?yu9Sa3pi(4Xx(Q%VNbqc`K?<RKkFShx{$533TvMrC6#u<2q`-DjPfJ
zx+OB6y>$KEEi~GXwurvfDM^05Any7Zwl1=Oi48DZ|2PD=N%`_IN9LE2?6v!h@$2W8
z?^-<>XhSbI*V>)h5-w_(VJ4iVcW+^gnfut>(l9f?ErQq(qX2mlGo;y^&Y0#lQopZ&
z#`k;j`~*J0Mxsq5pbtwYsV`s-Ai=}k=mI}wi#z*bsB-z|Gy5M(h8Yd|u(0TiIQuiv
z1sfkqMEm@WMt}66wou=K(Z?Tl_MAdUs4_2nRb72m)nrq8Xb>rsU{<sHVq&hR=KG5o
z^gOfDu^hI+V~~ihQD3LVrx66Khka;-=h5z|4pwS<m?gxX67&57q$om&;z1P!V4riO
zwoO3A6Qy_F;7duVwdKhP63gDE6)p4MUX3K#MU(aqOe)HbZ=2e(;IV0GO1Va79mLr2
z{^JYw&KxwovaGXPF?wirL1t>d`mt#RbI!Ks2h>cfX=t-0#$}C}S&=_KvoNs{*T+Oy
zPlaX3-VqlM*<UlUZjdu~x=~E#d_)2rB+O;@JBmX^X9jaC;5kGT$a7)-2fPx04ChYl
zvw`AR!TY%TAh#~|ISTKCm>a|lB~%_D8rmZjMXttD5C~|P<8wcJf}5TJCqgzc$%(fC
zJ%swsWczpB_3g>xrO-yGg7cM?8r*O2+xYj)0L__oaWFeDDsJr=O+Y46eb-nT(@8e2
z>o6p$qLfB9+@OjT7vPHbs~Z#n88|96VT0q>4GC$EpJ2NB^tukGY|Nyx!AFB`A{*|K
z4U35^pN1GjLMTooYUsR=P|LKpE^S)BWYu%$CXBH;jukcTy);Up4Bf({6)%lVJ>=J!
z*9Q%GPw(3C@(bJcES~+C{V(IUeH4!THn%Ma8i=p)*kW&Utq}JVBk+3Q%o1MG*}3Q*
z0ecL7PI%647kK`ui{~>5&)FRU&);&sA7VRX{=;AR=i&(hRvC#8!23nt^UpcBMd9<H
zHisQY-~YPs_p_Yu7xC}^LHPUU;lIeI8s5)<OabDVr^E=+SU5>kBr>3P1)0ncdee|G
zF%pv4WSJv({QJ%Yi^nG9=O?I@;p4|lI@a3s?Cl{aA9q|mBTv_fhM4{F=R1Zqq5HmA
zJaxwG{nK+25^}jQ6(!@woVfipX%za;>8t1|qf&>9lg3Y{>u<oDL<>MSiy5%?$bLZP
z!^F42KHs40zQm;o`yq2x6J2vLF0rj1?<e%)-+$Tb{e)gW(!X<=o#UhzH=3S7fETA{
z(9Mr;=oy46L;76lem~{!X!@G)m(E>epm2nzKmYd-{JgurN8acC_t>8(zrGNjPjd0=
zD*1et)C73wfE(X&|Dp8wkUqb}<<a-^^FV+ebhe>{anXampU{JU|7EVi<NfgWh4)`}
z(vQ5KVB-nzzsfCezaN(3eE(G<r#yeS8+84j@ayCPh4n+8iLM_W)BS>HMs0_AEa~ed
z^5)UkOKwxI%9>8jr)OiYQbSUiuBw{<x*M9EWtaZ8j!<{b(p^qNI==bFX1W&0W76K<
zlul~_;pXQWk}@A?+M>wFp1C7fjYoSgt#56wi3yL?leyh5bURVpBhgsmXAH`Vh4I|^
zp3}v7T1r+>T7J&cOziKZCHDlSB`eVKJAsx}l$J%_>v#1?yL2Vo@j}2sW%CM4_trLD
zQ@5(Ie5gGxF1vqD)&acR)j8f%3-!^pt>a@->f*Ap;;I9~k$x_i06=lij%s2Pzej0K
zaGyN*-*wG2%L3XbAM}n#64t$94-N<o*7+slD(t00>!J<eQ}H#|X!o94trs_!R)$#$
zs;gsze9xBiv)(=0u8EyHgc}ZiC&YE24hO1KNal*KUlS-w>R4{2*o7NT%T+E`PHGrw
zi%ZIniOJTknuKTdrO*Xj5>lozbn2`PwIxP#Ms!YYj3qR9Qp-VRWS>i2sNAIEzq5L<
zBS~$c7|KYx-xs12Ab2~mw?Y?IPfAt>XVsPVi?>8&n9QkMSq=WM*CH2DE3H(?t{yx(
zJ1Hn6CL$p*BEU~=&!2>D>qDIj(Ia5%90T4!yo#R;&`sG9iWUmGgkm$W0y~!;p&*bv
zTBgGtTmJR*$}UAmQalb##aGNdR31suZoCIgCgn$9;C5Gbq$opg_F8zPD06&3N{@gw
z#5aNb?=av^p~t>Dl^nsQh(+VxRHv#V=Z@H6lTHmS@+dd@7k&lFKI*38=n|BK{f@+>
z>WJm?yHp!x7o+%|%8hU_K0xY?1pAXEm>wpg-DAlV0&0%YxRNuD8<p-Xb+N<9IU}(#
z$;eiK^KeuFYR9gP_n|=)&;wPt0X^^*`~!YzV1J6}0bm{XOlwE4dE$6n|0lum7{mnP
zs|PFlDg1$ypikj$W{1!jTTr3K=cL8o!upEHEHzjjL7EjqhMXR1G8Ccr1rtli>6^p%
z$aDGPZ^h~WS*0#y$<)oSOrNoD0olv?`#bL?J#);M%yhYC)8*8p*E^;OyGqG2Y+_iX
z)RaEBc4*b|I@sZXi7n_o&mDGTw&&#M=d?eap)oQ5){0+7JLzV*V7fQht9TdeHIdZW
zB7R>)R|)#c2izj!$&x{T1R$K>h)~x^U0fQV=FL6vuFWd>n|r=#UjO9zH7ilji}y`V
z*0-RHxovH8<*LnBtmZd5)&vjRwtqx%e*JAtBU;f}gC?VV>EZkC+qw0HOUSeqy*^y4
z5S0d9PZ&FI-q`vKjRBVY8+zUtxpGtcl^4fsDy;-rFS+ryq!4VWT39ia3nwpV1xgYE
zjzF-yYeTqz@lHHF9><+lIdo!=q%e)?rwavsY@WKrnsssd*HIzso%roz^d9)_8(w^1
z+Y=P0J>A~cW+&`<IX&ey;7EX`jBuoC=-QRG!j@?UrC(Q^_WGhB+j&U#yVtl_WD>!C
z>3Jr-S{tB-fJj`lhq&=YHgtz%gAkV{aRzt;`LdWjw+NYnARTOx+=Zl1o<I29hNKil
zU|ao^DRpB)hCh5NIzTbOiL>5M<$<$4e#i3Z+X<%nwr%RjfSiL-k@usKNGy+=)smB*
zp3^eS6tmW#l5lQJ_2fVvQ{A4BGl4>=j~%gb<8reW##9!u!~`L{gZk)Uz&qk;!kWmJ
z+hpTwRV=WNzVVMlB!reLYSyKh(?<L((W>S1G*STHA6OF|rQhJ>ofr1Lz`G;Um-$mj
z3co?x`6I*QpiC;j@ZnwO09(IjmIb#=KJY;pfJr!exYMAnEf;tNwNbtAsZSi^H$`jO
za>;n?NGSe%L9PjaA%vWOj2|GM=wz7}G(OL=nU%FN)movbjSMX&k@P#p%thYZaw6ah
z+$yYW-wsvdiXbwu816|pW1oV~BWJ9W#^cM_NTVQJjD1T@bv|RCy0zYIGnPZ`Lg~|?
zazzq;wP8tKLPFlah=iB3w0`Ob*_nJa)=U4nRbF+&I?=;0ug&70`q@hk`GSVTg1p39
ztv@5ZfbwQ)Lh}nqG`7R$I$u-;QaL1fauN88HH2s6ZgJ@l8o6`rt`A8odcKGt^9M{U
zD%PZu6E=DB@OBswoVH0NmRWu*YwtdJwe5C^Z=@pskkxVoj+ew2j#qA)Ew7bX0(EPF
zlJI@&9oHHPAU0x+4n<z`F&(qW>GG8e$BXCLA+T-QyXDy*Oka6s7(27^kOv!QF2A*e
z7M~RBfw2P{)}e!aN^BL7v{*+{Ck_*P=rit3u!lx>!{0to!Wpgg%5Ax)b9dIMZ#r2%
zW!TtTOmqq9vTe7kta6Y7^8+4IklzZO@<)2Eox9>pcL9E!RPC7NrERG^a0Gvz^e=eG
zxRJ*ecjDk`03?A|#Bhx``>#9=7H%oM5tnX$7k~W9i=@Bj(gR~u{#r!vbIs|k6IV@W
z##c~Q>$FKVt@6N)FQ=zoMIVz(aQ^1%`gi_{BAtyrSO(a+b63>VC+)>{oV71G&NljJ
zhQ=hyg<FsEjJ1ItCH)Itcb*WPqa}3C<&ry3Xt*Mabsay}mXspbj+t`*$NTrf6y9A+
z$UHm*!+WI!H@EDwe^%7iWR<GmM!Pr4dKeWWv2Xm~_RO4}+g=d{@#2#Jnmh1W!x;P~
zezQFy%$Pe9?l1=Cv<Y_@=teP#eUa+EZgr#3&!h2d0P1vh#EjS3@#yS{bT$F?a5id&
zuM<7*?Crr7d>c@Qxzh=NrICJbmSATkd-I=|t7K3mjml{(NigdeidVg@1a@DMCQYFM
zGhx#3vH8z5DYL>w2g0+JEf+Fx-$o?$pqIYNENErcnQBi#2=Bs~8na`Zmn4$4koe*{
zkVWD<(o2K4neEO-KgwH`rzp~V1C7bUQ<%t1(+@)73jC?{c;a)1pWZm{DBkhN)}vn?
zECz{;2v&&2n(12}STMBtuGXPN^@^zbOBe2&JpL{ez1BZU?jMATp)~UNgn8!<Ol=8n
zLfp>U!UZjQ6Miei5*C_YF+8Va_Pz;4a*@ASY4F#dS#;;<rmMO^LA>n(Iz_Y?<g*y^
zKVbZu1iRnW@JIFl*NDe)>beK8p@|ico+et%PQWkiShjOS_1y1opR)4A!W0lxQ;@G%
z>{mN}$?)7#NCKpk21GAT9X@^UtpAJx7<+l>r!x7s{e~<bTU8KJc63r!LQP?S@p5Re
zR%cDjvBp)7E{&5gz7mx|rkYjLzW4!kxRlTy>WE$kc_lq5u6(I?M8a9)0LG;2>g%cI
zgnOO8l;=#{=2g%D*Lc64u5k{LoA}z-TUr~v$`?3gZ`U``3HT#gUjlynO=}iB7vIyp
z&CVeS&@7E<WW9HN0^HQL9&Tz;Gs$~)>})SBOwFvbrlmv<kdj&i(S%;EXhL@YRNfBv
z@hA_UyxXV`(Ph1vQZT;?CN9HUI)@?n4k+pNZbJ}wcUX$4rhAT{PvhQ;>!~5Chlm7Y
ziSw8BXljXi?T->{t{dX@a3@1V*A;u|6r-R`z?2p}G0;VePSFb*j1jMg&_(g+udeu!
zPN`#ii@wMIHH`0;t!Qq<VdLt;*7JvaM^;YMoY`Oa63Ph4&~zKgfWE1io@_Cu$6hKQ
zKDQ?R1!SOzcn7XsL$=t<2<eOo3c}EBuN&NR{P9$!8^yoyT;H%}H~zINmg!80Bv{_;
z+U?eHanGSS0C0L4Wm7);G3mp50yphng0l48bi0Y}5MWP<UL?J`ZQ^{<8Hjg6^@(eb
z(bORY%feZrN0RzP`?(VPRxRj3(D2lWbvD1jXdDtpr-LN<wgvJ#;{1`bGanv!NBq(i
zhia<p_41%K4^~zkvHF&44N^ry&|s9l{Nz20=S0pl6;5fbny_~~xOEX$yK%6iy|i}Y
z**3$-b=!yc7mG_o>B{r_+Qvc|Jzf&0vPeiLDC4gw5`B}d)XO=hENIJ?X%h}?i8bf5
zq$^Z3DfB&jd$OMtq1*N>-+uy|lj2wHT|s#ZKGHGJtMxvupq(H;>WcMSNPwy*L`N`H
z`1qD5z9uD%X9kr<w;<L<l^RR~F-eZqb=buIev;xqSdjw_8Gdh_Ej3uf8O9EaP$&ZQ
zx%aPco_%ijV=Tw#Rqutg>RryX>RpglJw~#s9mh2Owx#$K8j3ndLRF#8MPK4Cp+d#)
z(16;qf(BE>sRQ-(Q!|!kn+A+r^gw%^E72--CR(wQPqaRZezW;2@Za(KAO|8J^Nml%
z>5x}0f-V%OF>~S%MH5p)OowEGXAgTPOovbs+=G-5<TfO)X<R1IVgmLPYNV$TtCXll
zIRa~iXh;(CgI^P;TV}rT{KmD?1L6Htfyh@^RW_k$co;M?muA?*QbzwUu&{AZbIQ}n
zwu`nWCNx8O78Q=zcd?n~XOjz8#ibnb8-H}8t*$V$^f76o4jXfx-g?^$Nx|Vm+G7XB
zMmH824O3riUl^Zt$B>fDkRU_$rlrr>PmhJ1?RR@7Y!0fy?<0AgK4!tdl-S{8Q~7)r
zUd2rV`$h~?!D$Q;x3NRuOo&PK8K2*id<J?z3=@xp7$f&@lCLC{3%q?q@z2J(=>|g5
zR~R@-Caub7x7ztW5(v#xQq#&=PGS|qKpbLAkuRROF7&g(4Qp=-jW>TEe#?kbpfF+-
zkAD^wSuRF4BYt_>U*@(=Ptq&p3d8U*MzK2hWKXs4-Qb_Sb8p_E*|Vnz;AhJELyE(B
zM~=iwmD$CkGpE$mA2=03XajZ^#XkeT)+tlBKpUqk7fI$;P}7SN2mS(ynFUEePk9iA
z$ej!RtUE+20EzX+vtnm_V*aNtHGTlaKU3??+}Gys`mcDhFi;_rYIBpcGJj4RwydWT
z@^0YIm{pUqr=*Uq;nB}DSpy`~vuCuLtP7$lvvb;FRC!tu86q=yu!O{=TYxTI%faEu
z5X}p^6ml_MxiC*VsV5_^Ga|~j-nHQr`IkpTNy58h``x_ScwFCsQAn>M8{V5?$m65%
zD8bZ56#K$i8bRd4yFy$bLa!v~$<olqfoBA2M+G7gq!atnYH<(vU{<!J$c(=?6y3B?
zxm{tE)XP|cp0dRoP}qf@LK;tdFIx_jDxDC+0`HH5KAClky!SFYT=x}~h)z8MokAbC
z1d#KGV6SdPK>7xW1U>pi9!NS=mryL713uIGE-QT?nN!E~NHY+iUJ!Tw7)(|lFnMkP
zGph(`B}xIRhsxJH?o+M^?sCtVHnmdtLU^}c;U9tsfrxlQDY=95pOW5l8k`r9lN2@n
zEgr~8ih+`Lu2`m}$VuJ-c>yFzPpdMWs7Wr6B<TBB=ZB@U@^BAaXZA4k{gW6Hm=EL&
z@(X>!Md}v8tUE9yKQ#qI^1vq}QFe-d6d=>l$)X92fPVz1)-f{9%rT6gjzrdZy*-cn
z7o6R}UTdWHGG8{@mv&v@%BQ-?18RZ$m$T3Rw-m)ZwXA9Q&V37R)`7hLap)%Z>htIO
zkPCO!*N%03(PI}f&RqoE<ha8VY7S(_23RvMLQaujF9@MU;DK|0yiO&;!Pf{lpYut^
z^a7M_)T2N<fu&(zbb`&iV^9|cnGUQPTJ5V{_j0uPHG`^57oHH@hSHeWqwOg20S5mf
zpv@qKCYzCbHnn{no)N8yme3KEVBxbPhiMf|X^<nhX$HQ8eJiB|qXyRNg9nQVE*$Td
zdR>)p_InAG^sX@l4w0RT7xKViF1<K!ns+lummw=PQq}4%Q&ylb2BO`Jy5qMlag-pB
z=5QQ^JfQ%uze^ZM_xTa~AMn4yHuvrkr|llz`*ik!c-;&=s5$3jvQzdy&@%o*NRiMa
zfQL6V%xJEx&4`V%)n$@C5Z1Rjp)dmZnhVK5@!@h79p!wR$RmZZ5PnPCAm^YD3&D6^
zL3{ahiMveENYwlgGpQOP&o-6N;ZK6#@Pf9I!!)z^@jUsr&_8#l&tpW}J2%*?Rn04V
z0x97E)&y1n{o-2+NB~bw{4!eL?aGgMl`A;IY|chIPjkE*TilsRmxvkiK{V7!J_f$z
z-@3b6yV&WD^R%R`G{?U*&79iU@teC{;fS#?|GNOc=<o?_e_?P>QD=zSvb!or7LV%%
z(fGGTQvKPpAu@(*X$iHlsYP!*RBcly%f+5ne%mC+TVa4&K<D3qmCr<DU0HZK>kUff
z(F_q1rcmhSqgNPhw9=1b3vx*g2N$51Jkf4(aj$r$iK1T;0+LfzWzXZ}%jx5!3X9ZN
z%(A|EKVlm*H=f7e%M{Q<xZmfITj4!1mq|Tgpc|>n#e5hK5M^^Q->Y%WoA=K1;A}Z0
z%!gm*WvG*{!MRw^h&pjzrihL&U0POxa`Ic<z`A~_0Ld_47Ps-`gTvzjb4c}|<FP_Z
zur();c5(zIBs?6a8z!o89<c+gd{a>*LRNahM#umbXo}I8SeZ~<Qv)80sP^DfMS*ge
zOq&DlN&u@1y;jPqR<2Zvk?$sL3<^uWdsR-P!YmPaxG}?u%J9wrUpEjhnuyQ4VNpr~
zVl~ZBtmy6&(dhgo{sU1eYBzJD{9KZ<!XKd606^h#V)??bj~C0z2J`^?9K#$7m4=4-
z#^dMlZ{~824PeDA!-)MPgy*6g-wXITgTUt==e}Es^CO&Jh%^Z{Zy`)9r<W}WN|DxB
zm$rrwq=#PjxLT14LFc7PY^4Qm087CiP##%_ST}I|;6J2Ws6Z_ah%f|<P2(ERY=01t
zJ*xVlsLIMDf4GrfNB;;qQ;~=k#8xQM{Wno_X9Zs6f93x3_{I-nYtlL-uFcTEAtSg{
zv@8M6&V214zoaAikD?TI*>9FNccFga{?TFrLPZcm@bljmGWUkV%VMU!BcdFt6L^z|
z9f+zN-{2-D;v*4$Sn40?J|&_XZ$RC`uW%m>?jyaNMNA|#Mf<Es{fq~>h};9c=ozBX
zY8%P~dRe>`8vAQIfwT&?6geJub{`E<aH<f!Z&f5yx@6K~R<WVj_OY$lUgyi*j#{<L
z3(Y9hP#B=o`ZntmwB-oDit(1Yn;$>J1e)7l%(M7e#4L}x1cq3MCbwA=8<06UZZ(QP
zb$5ntYyVIs(Q$=vqo`$pf7=m{9#eq86`^EDdkV44Xw3uj*|Ydr7Qct;*M1}tE8UVs
z{OoyRGx*tLlCj&S^md*=#CnV1yKV`WQ7kq)4K*hq)6L5uyi7C->2nh|nU+6*I5?Ft
zIVZ$l{+@jc{N-+IaOk0M<$!whjotmDE|tl?MaosI!R8`>U{XpN6>yK=top&jhNgwh
zH}!&P2O6-A6)`+inGZq_`J56Nm@7V@2B0oA3TDFTL<XC2<^HImi3lG)UbXnhnNjdQ
zu<w{(xD+3_B2b{n0z(azP!MU?shMArqq)}->!uvuhTdC`9}1gmK)X>@<+%S|!ZUfA
zK^KK+6Ucyp{4TX5VBf?z)LIzoX4t76TZnX`O*w@N0t(|ag^b8NB%o+W|2qbpdvsok
zMHwk$7cU+#L^i_y1U?d3TpocMv%lKE`H6qtsLWW&45GY&>Ug$P_#7pz!-LNO$+Ey;
zY>|e1MmqhUKpk89;l{+8gD~MWI;pDQt)Yufo{o-G&YmA+6|-0IM?+U^ojhybir-P|
z>t|6GQe6J@>8CZ2g8=@Y^^vg#E*t7CeGtK;p`ReKD3J!f3xcVqK@y@3>4xmAp%{NP
zb6}#sUrr3ZRG%;=p~mpy;wiFa`d1647q^w>m9RE^B5VAB(%JXmUzsV;a2GIie^wG2
zwZ`9g%@Sz@F9&i2Cw#0T%!R{zQj3d%Vv;E(p>T-I`G_)rcW{PahxCI*xZlvFCFzZ`
zrj}Lh9CEs`Ke}3u?`y4X**;=iZd;l)7QMP|-p07<+``FsezN51u-~u^Cm%-Z$8I??
z?XE!u`f#3aU--yGKXB<jA@Hei3$U<Fjgfq&bC>iZML(oZn~XaWl271A?z(r%%tP{x
zBgWS+`r?G>>vyBt|AXhEJ5b1$Y0qA`sz}ybs#fxUoA4@zvru^w`M_Lj5Cn~nCSA?O
z_~PeAD2rR?Uyeo9w<#Jp3w{be?wEwKuR0z<<M0wdZk#}Q@sN){TMja*g7t}_;LAcR
zKo$8b&?-|N`|$F)Hfd@8@N>vERXgciC0c~{KZXK+M=E^p13!L@N>MoT0@nQ61~mQ+
zWb|pS%tz;A2Ac;CLKG-pp2WaZ%3Phu6-tK`^wZ@ttcFG9Gb)Ce$A57&lo2aZ)tB~U
zmsD1!mzsb4vFz{~)DRz+KB0U9%Eb@2p8sxT3N!eh2`QPGp&B1_{XDzTCq=CBk@@&&
zBv#JKMa!6!Nc;=`6$v-2FY;wiSbm28v!L<#BFck3vmK||b2o~_t9;~uJYyl%38Fw)
zCrAP?MHlVyy=$5-Jhu}VD_|A~N9OswxVSv>@9y?~<>SVc_iM-RIUjvnoRm;nl9*J?
zh4AmmyQAOOaTVob$KdPE2T4UG35lg8@WCC8?9dy#xxd0ntYl)J03hom8<7(7PbUF$
zpBxE3dTu4AKUoZUISF#Y%O|(27-~yNv%z<xm%(=_CTsS@`p8;Sd}gE>k5*Y~3hm`)
zYt}?gGaxH}*|LJH{{6G^moClE>TiopTo_-ikFiE*V(JH`!AlSYM-}@FJ|eb3egNb)
znhaCKM;<!0csy6QYSk~l5cv}cbQ~hku}3OOJSgg-+^0@@xxR7H>!?7c4&lG>SxiTi
zW800(H_Y_2d_<CHNi+$k+k>F~)BSyB-Q2m(|HosT-@zlt=N>OyZ-H;%Z=>ti9Ut8I
z`G$hjRfvexk_Z9stabA}Xm`pHo)cZam$x%=l|INnFu+t%7^&2&wOX}a8Ch6i3JCNM
z(yQc5yT}k*%fD2qgEiKoBC94?t>S;BHr9YSCO)mg)<4K*3m#yz4G6Z`g8JJk(&CxX
z<t?`0Dx0k`)Mg8<wAreHZ7tA90DHg|$BX#O8y0dFNX#Q2rGqNNU(QU7n$+lcG1^%2
z_8TB?jAN4H#T&QL_rX|3k?WnD>$|!1SMcGPNl}wszd1no1E}LEY;rtt<0Htn`Ea6W
zjpK=fO$RISL@U}u*U>T6@f7_z+;N-;E)I}na<J_1&LxJ5)YOWyl*N_!6?0;0MMY{#
z1wxRnf^}X0tLP&igSZ*yUqi};bj(7NFDWgKwt>t;`iKa-7I;I|wV`3a+<Oex=6Tf(
z9j`W94fo6)(9lplj|-nQVo;Q|=)D;Q11;95L5;^O0}E!nR|MaVm^G_$P?QgQ?HBl*
zYr^LwlWv91pC!4;XA{xzT+220T0V4t>$$8Cds*SEo2=N{c?XnMjv61sjlcXUTH&oX
z`D7pF+Uqx-L`Km+d=x%<kg7liSfWx=h9FY<#<N3hN5&_2z53domXX)dYp?EZ8uj=-
zboD;`Zduwg)P&|uPc7cJ3+2p$UWg+r)5>@4xc>oUh0Y|9pbY3ioW;H26AtrRg=wl5
zvnWcXv=bWuYUIH-Ahf3Eja(ceP<M77dd4h)_t-N<vzARb^zowRwq@V!9KQ&sOdTPW
zjGz6`f<0$n_{=_U&e|+nd%r{a`FU3+WZO`{-kM^heFq`r_bv)9slE+ArfO-+sgV}d
ziX>m)*ns@pj*oZPqBtC1T1b6(E&CPNsWx|{)Wesf@DAO(<E}`q67}p}vtLckiH=Tc
za9k;mQJOO}>8<T(t<!UEfGQ!0U1Q?y(<|LO!&qxtIc@5+LVf!#^T_b|Xoghl<>Kah
z8ml_36mLV{^z6by9R={C8S>}!47$5&c^xO*K*FU1ly9Co_uQGeQzp+lcXr<7vq{Bs
z78S%L70p{z7=vDZV$1$Jw?6jN?gx(UzW?vTmMm}h=+jXvw~hqc&vs*t=yv#wIIpM(
z<*+kGMfER#xA7h>SPHj?&iee_&1=_e{&4ZwB?Liz@Pnsn3rgzGtt>O>wOY9{e1B-l
zm818(|M&feY{dd#`hAO^zqInflJJzcI68wCgpS?9{SA6SNtK9KoE6kmB&hvpSO`mO
zT$;H|OJ}zL$lX>~dNH?tIR4Q-HzOnM@hQldKEAq9uB>6EKphKB8BUCSY<tS-P0Oym
z7^)42ixUnFk!x`-$Pm<d3!j+-UOWUmiKl8$v%A5(0X~GFHju&`&*%Kx$@LGp4U!Rb
z{+>9u&=3DdUF2t$*5lKKb(}`&SERt#Lkr1ho4R6rnm#I2;Gf8wB=wLl6iXG6k|Fgh
zyp`if#vs9APl9O>^u;R)4!Qe<QW^;T(e%flbBJxiUI)J*ihM_7nS48bPh)yqlaIk4
z2Y)@2y*|Bth2vrGAv_m_S~%ppX!?c+7B*qE_4(#yt`W@aqzJ!)lpQFa7v#9kvzQ^i
z&ps<*q2i&a%bMsNZn2x_9bykfL7=u_rj#e-GBv9pJL6p8vopr5<X0$wETi`Hln~S5
z`%EDz>1Z4PE=NTYz-6-9jYk)bx}mnd(B!e&*%WEH(YSF%vIhT(WSZm^8;y-l<mCv@
z)r)+zaMmt}ufcqQEZV0@Lv(f``Y93-NMkf<mE-%Iv{BkXf<Q{np-wOm={-o4q~}-)
zI42j%Dxv~3F$U{T0bvHecSH2*;f*c%cg#AMK2{x_Hz;Gs-05@9J~(62v^ghE%$#;#
zO4-iIwuH3u9hb!`D#~NETuzhYKvWd7WT3xqshBH4X}*qMmR?V3+1l^A_Tr`;8&^N^
z%%*LtSKwbyEj>MP_?A<v9|hSUy?+IwSA2}bw*o0Ag;qd!6X=T0cpd3xJCY-|VB(4T
z;zfh-fwCEU!;@yMGolPXLxdkH(hLr$z!UcE1%PlA5pdx?O-?>b;K4<~CR4}76a+T?
zCOnUPCfFCnaIVT|6v3<ZiQLZ~pG(KH^Jo#y+BMMHFn8Gkhsw!)pe~d;!OBHkaj8S&
z>o4cxeRYo5iWz$h$unVn3MMQ^G$Juuot}O7!bquNN?TZPPEK(6=qZ7bD;_FNH8_@}
zL?|{w402CCVr5p8GU=R5SUmHvnAJdK^6u1ZP8xxa8N-_K)}}BMz8s;bw4a=fii(W*
zUZO8VL<duBj2wveko+96Mg(2RJ1F3b6Y(Jb;6b{HaoebZTPYZ*5{kP^^)(r~$C>Db
z$=&zS!4I<vC-1MBmK8q+kU~Ch-}J;oqlep={-P&}3P$xW4-Zg>nZ{pw|F*<QEi+a&
z%|9}&dfJdWap3V;dmN8owd$3`w0oJ)&o!4xnx_wJXhUP-?PF(_=iPt*ve{>|P-&Yf
zFKc9CNJReA&yLDSO3Injzpekksp_!N+2ZW#SMeP|1L;12f1)pdf3a}8f?<jR<Aru!
z_Xu}0#QSpT1qyxZ#2yHgKy!68EkT5;2=K!+L@k28q#8!_Md<n+^ay8<63q<>nalWZ
zU}BbxnY-a|=!X+(&s)`Rjap&Nus7iE$iZEXKG0V#n^jeuPbPVx2EAO5Qq+LiP>@|R
zbw-)~YULQ1Uw(BQ-a9xu4<9l3LB^iwbEv_-3N_dXWX*&JJo))f03b7MfTLzFZ>z!?
zCFfQvx@rm&%b*3Iy88X^07&9kgufUu!D0Wt=cE0*p-*7PvPwlj2m{fSn3`uyE%*)m
z(#X*14be84&UE{$cWirEXbvE{7-+{P0PS=@Jt`p<AX=BH?#@bTa+UF|stK#szwCH7
zpRM-iIRCXw%;ohfj#f7xy~`?<%ca)4?;lx<UV3ER=6nXimCP$ziJHmZvFY*WTjrCQ
z=a~@_Zt7^Df&23fG|Nro(e?S3&P*d_gK+Fjv^bq6xVo%oQE2F*&TB%!AtCsyE-OQW
z39ItFmxnLHLww4)MtbjxJ_Z^=bsVXT3?fIK*kVrLm|j(Z=;M-(J!!*zA)m8JRG*lw
zNz1wWQlw12q%9l{y*{jMNnqq_CyP@f_~RZ3r85^bGA&!+I^$PNVNGzx!%g@oJ>yh%
z3P9&)fbB#2HpscAaWCG{q_GFSIL-!Y2u?RCQ`CV)K$H@F$(v!KjM~zPO*utt+O|v_
zwm8)k9g!hR9(4I7-4I>FFzrz7CpTVgkSoK?)84&f#wO<Un6m6(U2gHn#kq-LF+)s=
z$pdA{FFdWwvg@vX{!zHznDb0NL}7uaHk^tu#NtUr1ftCDZf7mc5RoiJn%y%_f^fQ|
zB*+x2Yr*fN2UlO##y&ryG%=;LG$pA-Gz$5t^Bqst2P#lmkjR|tFCo3Z*V)9flH`=q
za{e4KPs8WMczl`%Dac_bpXg*7m0;%ScqZOY1(owOqw7TW;}nmU7aX-u7PT-EX@q09
zkgg?=eNZNEt6<tyv?>C+XUO@z!48Md?dN$@A*y0Y4#vwUq~gM7XI$ZCM7&Z;3@9k&
zNU3l-JABd|LyLy%@U??C1@L@6xV&KK=Coxa@O3oAU<xgz7o9u|jokPz&s-LB)pNuo
zo`jYKs*E&E#SHj6E{~DRc-s;%DGt#7D)$YT4{=5!K83vR;mjqG<Otl1Dl5@OffCN8
z7VM&V2_0W6RQ?hW_*Str!fyqLeNikjT8jNO8p#YlF;YmR20#3kTpGFRuHtkxFZLR7
z;QM*3$zL`YJ*bhYXbvq<rpAvwKpsAYUouF!!9{n0c=2?n*kw=`!%>9*H8F&{w}@L-
z^8XO`9`J2d*8{NMl04+C;VD^`CGRQAvL#!V_uezH<0Q5dXE=L1dy-8Efk1#j3WU99
zS*2No1Zc|$P$*@&KpNWqNlR%GJ%8ui_ns^{hJXLx@B95eLLBSrzIV?(_uO;OzWQr1
zW&ekwW$4ELKb0#ZumXRzGk1YS&MnOlI8izmmL7y~C_o0)PZ6U^D{DU<8uGyHu6qJP
zV~^acRNZ$wbtNQ*3Rn^oa2tv*9rSJ2{t~RCzw1V6rrq@weOOh*QK7Ed4hs1x#Fxgw
znKHTF1%`KAIVsnSjoWwdBjNh4k8a-k$ZxRn`s*jks!A$OQE#2P@m46ie(I(pw;z0(
z(hnHo2O&86-28-u**LEX@$5>34@8O}_7q?<f-MVldmIU?lz}7xaWE)ez71#7rZZVw
zbf`Ld<|DODaCnuR?&UP0(OlM<O>lNmzkB1RLmP+v{i4!Rx5rPXvZ#Wd===TCqx}4b
zHy%1bc+1#-*g)n9up`7sBl}o#A+_IUqEg8Q-hRv3H~3L1_Vk-ndiIS|&;4%tfup^r
z-tOH^y?<u!E=v8zDN4m(I(=V@+1h^hgUy-w5Z;V)v-lLj7{i30khuvQmDrH<aVQcZ
zcSRM`eJ-onz)A1cQoFC-qK>-n>#`T&eO*h-lT5MUvEp@JHxPO4CvG3}IQSJ}kY0@P
zMA&>VI}+>*GlZ>XMJWaDZ_1NX1PrJhzAygDkujL3`JeGW-gE_~YL&rU|1wCwRJPhx
z<%Ai3y3l^pTQJ=v1N-eap64&Uv25TYm~<__pm76rb7MbD9p+8sMVW)>(>AnUids9s
zFqw2Htf@x$M?QhDjDmnDb8Oym;%~b)fA#o`E(=}Fyii=)TLVI2XtXBv{=wx#gGGgJ
zE<d?r)BVp`3QG!~e5R=A&W0kFnhy(mGb8I5_1@_Nw|?}|hNaKuQzZlOL==q8?p^38
zoHcvR;RC;;>ZZpSz!DGlnCTBK9~8wwVGl4P%x6#s0<%Sx93BATEQE6T;Mr0sg9Qv~
z$g+y!E>VFJiB%3xj67z9|MBJd1G|Phrky=dG7@zlBv>A{qi@M&M|yCqB|kp)qB(YU
zWkLCZ=C-*^+e0tUJ~Yx)V{^{DX?}g~j2YIv7+GL&sGmx0?{;J#J>0}HAk6t^CA*w0
z8By8s`6YRk)BBO$sP{?ztZ;zVfJ!Fr(OAkL3g67dXY$+cf(3huy<zXElY4KV-uDF}
zhDG)TLGIR@M4tF9bBTJN_+HdLKsIncHZkb~V>B}tY5u!6PV*P(r>t%FJkXN)40Y}d
z|26Ck|2J??yn=L(ykm@c6674cAd$*t?%StP!kI)YMCMDRXXeQjb2t3J2JCTW{L5HU
z64V*MvH`nj)%JO79vfb{*BEy4OZtu_^%eYkAli_iLQ?kWWVoN2b(GYun9~FD@qGde
zU$M;qLlK^;B6n9Kb0;^EO-Mr#cnvY^2uiG8Wg=V@z5wMgl!*7Bz_HDxxgY12?(^l2
zy+oB%tSd`RicxVve(DUH%Fj;`o;>^F-sO9#PxksTtlyO268?iQ<LrO_hzy^Gv^c8l
z8NaYFzonLf?DV2Il|3w}-&Rm#Y)C3SysE<HU?coPU3Q27p}=2QqYe7?D~L<r`_0UY
z!aSrpFu)@vAzwIG1vyMbZvBze6C$3dJftSH(<ssIVPTtjBLI4Fc5=9a1h}Y4JbqGY
z*}94n>ZN0x?>;iol3)mnVf^;;AKdZdKW7`mY!#~xmnJnBYcS+K%&v;V0Dj9-oYXT^
zSr~|%<iHK{4R_f?{Ucav`76H;0`D-;W)8?W7>|yUoRnTGggbhRHy~$XVLaBK<kiX)
zXKF0`bC#OG2&MnF08YxfrTZ|WHY-@6VT3RlzcBg_B-a+l!n4Z`GDrq|5KcqHlKZA1
z6!b}`1{{;Z%DWFy*1kEM>+L^s*OwS?;W%$Ex3&dvd(zG8nrd#pU!}g6nPCo&<{f)y
zEjY8E8Vi%DSTTfxr+({DcDF92-p2D3_W|Ye`q(q<Zsr@TNJ)4g%v7c^Fc4Wocm=WB
zik}nB;RZFkySwo;ziW0x2uP^(nWY)I!+l%$ZCz>wWMI+%!GB95e*0VM?$@h|4Vq!f
zmXNY=U3GDK<V?yAKlrz%;JA!W``9zwB{FUn-X!>6jct^?B5?GEdi>5^`mbQRnk)Iv
zq<?<_$~4i5#)nDXG{6;qE4!47!FW?4DiLHueZ0nim@*4Tlpafv5^)%?_+PbK^9Wv1
zZU@Kl(vF5-1;s=M@k2F!B>pupyo9>^H;jp0l&CVuCbTWf3{4Q?WT7AJ5LV%fFW#MA
zV4HrlvY2|{Oj6QYQK40;xVs<(SE1T*Ce83R`HUgC0qSjMlJRq;T9*cE^WLlvuj*4<
zJCH7rK4$@a#=!?j?ZYDlVrY;vg8Zq1O-e3G6eN0f)<y&WTu@wWF#lk9EtmaBe`m=E
zT-7R*&0n8e*UUiiuWSF(8JP5RigtkD9uw|bNzV)N%cJ2!J7Fvt3uA$d3wwbkW<1C*
z6^0b6bKsDgXbj_Vi;_xBcpk~NBrwU?mD(w9_(wzs{OzJ5CQ`wF$SOjHep}vAvYz?+
zw113h{_7Q;&UMUa-HptajrOueW=0$TZ`Z%nI(oNjwO+@hDO6$PhCQvX%(b76NhyxR
z`}VZHzODmrPzPk3jev{r0s)(WPecH`j2?wPU|WPGkXo52pj#PpjH}q7pe+{;Z}hW;
z(oZA=y59QY$r8Aza0R~y@&cLIW&0_IE-38UXkGEcWG|Y>3``BY7kI*W)GN?BF^d?q
zAXo}}6721s12S5QsX4Us)S78CI*qxxMvjZ#Q@!Q!!itg9yjUvdECLWl-<=Tn)2^3~
zJU(|uW7C56wD|aRTf?uGuV|kc5>Gv`d>;XY|CQ?ZFh9%KQl^l-NaDbim}*51>2Yfs
zQG{@L(6R;so1kzCXE_lS-4aIOOM4<>;xf|GHm*)dot9VF-Zr(i_qI8MFYJnpGMLlS
zHm&h$W)5vU;lETCpej0ZwoqjV$*-$#NjJ_J+`Zwqij`c@#AZN0vHNi#$AMHQ;tUgs
z1d|_uYy8q6VhJPG13)C8mE$T)>K?qr|NCgQ-Pw>?kZ5sswU}niSbS*bx{>uateZ2(
zSkvOnvshE=Z>_OpefVK|c15Q1k)nda&W;tcR?hC5GGoQuk?w9sUg0Asd=Z&qC9EIF
zv!1mMfq_r1B6}8<<N_WqG4Nlwix{E>MML);%yOU+DOcg|AxePFB%A^xzBJ|~up!5f
z>s+u9p4r)ulMAyIYCbcUUTSM|u1_moe?hkFkk-+$LPu#8I&C18#0G{A5vAI9<WXvh
z>xocb8&u8!b8;u6G#IYEseo`RVUBQa-HG@XW6}S+91RRHw--n8qbjGAni0kSMGYU|
z>}GxaRU|b7?y^QfL`=zm%R0%2@hhoadBJ`v3iB`}`Ar6KJR%<0Smqv5d!2~8AsiB{
z8}R~-DlG}<AHY8ru#tkIM*au}t_c<k;4OmhfQ=28*YZzsipNWH`7d%yLo)ma6>|O$
z8iw(Uf=Gmf(#|*~Ba2O$$N4{5noH?&O9PdmzRMNdvkKNPJUgbml>TEFM~AKEkEhfH
z`U~;^tqzO`u1})uX{kjD8Rr)gQI_1bseB-ou7zY2A+lEE7vy?A9l}Zt6=4DH^(J){
zKxdhl3jpgbSm&TlhdV3>&lS9Pgd9tl<s;cM$R&QuArbDI{~{4?Sadj5(o@9%|NkZF
zjd)P)DIjFvTG6F&^R2>1&cP(;GO?|UE8#waHic&!a{=4v9<R2)kbXg)ZEPB83-N4Y
zJ|k^mLL1O(HeJSi3T?ozDLrF`wI=pc@!~5(C@KwtBuemxGTpdL4OY8PuiaKwpv!hX
z{<hIqA=oe@V*A%Ae2r)BDlmr?q%-Zi{5j6Qn@y+7sJV|>t2w!j>ek0jqn3i3g0kp*
zxq|FlsUiof@(XtrhWjZ6+NDjbh2vqKAa%L%QOer6FQBc@vyE1eHn5tz`<duhu#HoB
zw3V{mq)qM7R>rI(&w}mQ{cI_hNN@xvm%FVD#{C?|&AYyhgZKq^KNA~=Fmn)*H{QmK
z$n?+_=h0TmJW0lYeL3EbZN@elJQiYG4$y=@=?7kAkA4IP99UY$+hi=6+c*xAXfqSc
zegH96!>}o6AL(<3WLKZm^CJ|`0j2<IC(%WaD?)%69B!b1!d_>Bj}N?-oL1MDUy+^A
z)>YfPucIg{n<`33D(%;m?e4Fgeq)ohX<%LZ95#1DMY4ZNWws?Vuuz{;-;$luYFk0Y
z6wM1yn_^E+n>jZ=ts~PpyK0*(MTpY@7;~5w_AMVJk+kI&>G(uH2l1L)6Qz&`;h@c9
zTE;q7-#j$%;o*a&R&#NHc`U>+w9uKERy0tyl`ao!X`VH6`_3~11FmajG(|0?Qo~fO
z-OjC>oL$|>D;UHJ+W>gV15Z&6>;bf$PjZTjpqTY2T!9<|pRdOdKBr0G^n{PH4aZj<
zPXbI8RJ6Bu)l56yGPLW4`toe*F>XsnTIpP+pIR5yeB|!=jlUVFo_?S{uW=<CL{VnG
zlD{u_cbs7%Td>}lA-7a!<z)ss>Ka<JlIP6nYFeB1Mv=O)I668aWy`8ny5#n>q8ViY
zVRl1M<7dHWwh`C5MP~L<VKf4XGXxWc0Z<2`sa44MbsNVd)ro1jaNFh<y(-V?Z@w~h
z&CRn1Zci;5EOC}Aoii6YGnh@gPR+DNF+G4rXDDCWG^>B>W=D5oN-qCNbW~e61Un&(
z!TQ0tk;Hf8wSLmzc-;K_A}(rm2AHq@>@wC;F=Y5_w@kK}gvRLyVJ(TZOt4l7W&q;g
z6N@hpCz@O9rXP&yxbOCNr_Z{1PfJ4%UrVPu7aVXhzTw&pY(hpyr6u2w{!x>%<=n3A
z14Hf28!|RHd-uu1o|$5+&9}`La6NHMJU2x`0h^LUC~CP>{DFRO#^B9+TI;i^=P4NO
zreYk9fN>{(gfWs)nJqA0N7IJP4bC1I4_15gxi`A)HC8+D><rpWkH9?9|KwrGk|atJ
z>w-1{BEormB2%YFqB|Z~(zW2&wz>85n=5Bj8#=1@?Fn&&)YXR+g&ckERvRM^*U|q5
z`bx>2xjZ|4@st#;T3g^)wQ5;#W@hk){QwWr*+e)ztZE=Q3f?6$d-o>~Y-rT<$UPzi
zRSDNapwz`6l*6pr4S~(E8X(BZ2->iZU?h1<vIXIQJxuAC2=-I3)0POb4Z%4`v7((1
z)J}p5LAVt}Us9e!q7LA4YK}O=u%{J#zk1l@A{)qKA`0?-9oE8*rny~};TwbUgI;J}
zyl2k3)pPgkC`hmBXr9|w*VJpw<KNp-m7v*DX^4EBAG<N9W_n}Kl!j^SUI+&WWK;56
z`kX~65wTO~<btJxd5MXZ{=xK&#$t<oN}sbZyCnV9`z;9#_vae<{6*!drHOhyxUYbw
zsUYeg`zq*BXnnxSam3nzQkz`ZRLE_-oM#79GlRop1HycBFPAXs$3nDsl;s<f3JQ`;
zR(3t*>le?jxA;S0MXDr}j!U7ie(AO2hMeq#gdC6pU|o~wQmEBxCRKBR+krj{k`Zu4
z5DrjQgoYdp)E9l8)=**w5tLpum1gPCb%lS-Olf^>#?FElrUvOki)VF4-xa6|^K%x<
ztykXFW%T!FmCu{Cfo3ub%{hkXxMI4LW1Un)#2+j6>%v%IG%S3y(xauox}Bk}>Bk}>
zG<1m!%Gy+R%PA(SskAgTC>Ut~VJ_oz?At=!TmmyLBpQSyl!>4tx_+shFiBFp2dF|7
zL!l3b)7`C&y*D<{92h>_TbO52=iD6^bszb>px17d1<koz8x7y*1cf;Q%>QaR__V3%
z@Yn0<GMs>~zmclDrLwq#|5rL>bdgC3Z57TA{-+qfaMs<nzKnrYSv#_J?HB$D{`^0T
z9GM%Xqeo$GAbpJQccNeltMGGEbWcS^k76D8yt3AgL~YE1WdL)oGWVX?sQcmqvjamN
z{<#42C@q^-ipAgS>XJ2nPf~w-5Mll?9g>KygYQ!!pQ22`5E)~gxCUnWD10WTj$~n%
z;1q3Tuo~lsr<y)GICOh&O;1}pSo2d-*KA5pZA#UqgerBu^{?Oh7PD*j;2dLmOGCXi
z)SxPS^OQpsA5o`;>yGa~gKN%gBjaO!fv24ueGqDfIg(tsc!kY)8}r_6x4zG8<967(
zdkVI3JKsD9&zb;smf0rQ$AL|m#_i))m=*Qm?T0_4Z%eW-TV>NzN0<$}PMq8++g#K$
zXdi*O;=arRS><ieDG3*bHzXpz7$-8MF$@W?3WcD=1K0Do9VwLs5ADpe?lAgh>ykn$
zuJn!^oIUgQY}?EYRm#%oL&bS`>el}`(l4BIGK`ZBGtx(L{200<w6$gSz}Ehj{$c)1
zOk~^4R%s8I>1^(#PqaiQAkG=!KBGL4p5XE@tb>S_G&<Xq(J{1S=lr}h+CDnkU#0Y;
z?X;^gzkI<oYJ-KDTD_3JQp#^S(33V>T-O|?ALfc2NIccWbUCXuAN&k_0SajY4w(L{
zRT~cF=ct0a$0B1IyK>XvNT+;?{c}Mi8=CE~?zrLz^aDcYW2>X%%I)pf2-&-?;;{~E
zvzq#n34?qZ9M3?QIMF>kOs*cE!K}y#Fa1xk!k;P$p}wq+(UsfVT==$<5SoRTJK1;v
zqL6ONCnBb)%bX6-P(DuoTo2v>XcXrM%Lz%XxP+oH&m`_Kk$Fh<a0xd=j{I}&fDKOf
zWAnkM6B}>)np%HUtG!nXnUP`hr`fG}s+^<xsQbugWGk|up`$wTIWQb?)fTcA{`=A|
zEZmO@G093et^{i68u@1r0pp<jk(o?r^NsdXg2pKJ+d|Mu=4WQ=*w;imr4#{(eBGQy
z?3B^tkq1oOf}}qL#l{4Gqp~vDgC#HaJadO{{UVdOiCs%|@!5Jk^&bf2L>nuVrPxGu
zDgAPgCj;tGmS#SL{htLN1i1va1st-#NeSEiSvwOrgFh_DwQqRp)aruFTxVjoHZHZ$
zs@tMyT{d@m-^_WvfqP?f@>BFlS@F7f`l&oq{NBBB2D349i9v6grD&{duXGlcwO6+)
z=9uE*mncDZgFOmaI`nh0WQaQf1w({LZGn6<SlAFT>WgH*B#Ll?q5(z#5(X<c6zJy$
z`j+=iqjXz!RK%M4mThMbY2$N~6C<?=^+{Iyp&OHP8>eI?F>`lKX)o#VJ2YcM5B&vI
z0(o0&+IqgIYUxP{4GdAHgqN;({1ewZF=++mD8E4fAN??#>5#^SP@$YcBo?qp$bpZc
z%B6u_YtEq`o+aNGT~U=YXG4}>#_IkCeb!8+rp&=^s(UQ(vs>p6FJ5tgdUPoK_19ZY
zzPRa5oO2?`hWE*`K?3(WEr16QdyeE_BI5}}jY<n*L99XwEP}poVD|o9E%n{)+iPoE
zdaK)dYo@k!6y;B~r{wHEo;kev@Pg$jxdYR(lbH>h2Ih3Pu3OXHuF21@>aK$5P-NHn
zA%<{GN@?H1jCl{Pz9nSWV1Gq>BbZ|VJ}R480y<u-bV|rW4WS}vR?(FXcd{eJ$n#Lw
zf)Yi{l3DW~ZF_ilR@;<A%wvwy`I@+CD^DL_GA-TaubBOt`sW7m*C@t+*7Ws@di&$@
zttW=tdqSyo3)2c;yJt@O^p*S|NUW5Pj!LGV2l|Xdyc^;(DaJsI<>OcnH<PFv2-2pX
zU$emye`-5r2-4}MW&34}^jKBK=eF~gLQPuuoKAgz>QB4*hbZ2;Vc9(8$+cNv!{B4;
zZ(Tl@&|VUMnL0@S3UZ2&i+MO=!V&A^F=OP20ImslCnSS}mR|sp+T3Fyx+7jf9Nhr2
znZb~gb#1dCQs}9zk__ki9Ar4*Jm!C(JE`?xLs;SCbL~m7?MtQ~+qeObwy&5vY9X`%
ze;4~DxIUwwqd$f=$lVj$jIPh=hp7e726MtT+*8o+J!(7XmSDROt;y1!5=;hCJ{eXW
zhh0y<H)GbF{dJUfo35tq&RYkj@6Re)QJ-eo(DIaX->mtLDa?Us8+xc4ZtR*lqwkfG
zsY~;-t4GUw(I%GY`hr<Pt%LFByJ6C~KBk|C@#P%YHAI;3o`-p0-_FCF8xba9M+-+V
zIh8y(v{;)FcHQ;&p~+?Q;QF&`duRXX;hbAlUQL{H>mMaIqTO22{@D19XltA5e0jJ5
z?azM(4;!^=NP}KKmkqprJ=341rV9S1MeFfuv{NhgiC3e|89WN;1bhPQ>;<SNlZXCo
zN(r8NqN|gwDF{li6*Op>#M2e<DcD;@&BjZ%5Hthq!Cv4mo_S_ABzNUymg<AU16A7L
zDLH1mu)<tsDbodo2Wn!>c~k90Yaaj2_DxS0cI@rx?$=J)d1Q){dixFj%eykV*!6~V
zRdIU3)Xh<$!o?N*OIhj4lJxvuN2&22dk)?Bn>YG*7nODLmFa0)b`OYi`2gl(BXQHh
z2|xq_72G!{oCM^~jsI<O?!*>J17kk`V9n+XxL5IwMNdliZ<JWvbF&qa%Q&o=;@tRh
z&#O4tcL3z*YmauT6-;Tw{{7O092FVj3=^Wo89ttXGran5%Ij7R<Q<@DGQ-^0M85#u
zftn+kMl2-58LnFwVb+4FS@6Zdku!1HaBY(qn#l}L2gi!uIK!H8^+)dol85}d#rf-m
zg4(c{FsCNoYds%)@HhLa3!Ge2Uv6TBI(T;b+@H!l7m5E-rObffNSZB$QkXVsp?gKY
zDF1Qa8B;3g&M+_8$56|0z-NKaO2Vl?(Hoay@pc!J(Oa^`wuDJ4pMqd7Qmj>^S3;gb
zL=X@x+<!$*H3<4dX)2at;i^jfO|F)GJlI0~u#sVv>bMd96@~JKH&P96laKt<OGGa$
zd{o6X$I4}j@Yq=`X;Cw%^jRNXiBEZ82pzf8qy5#<{0r#Cr5bqM(KW4g{v&jB&ux+W
z#vR3TLu=1_I*I?%5X%4B(?d)-wNqnbQwyft7Ik>sSG-L0IX|G^m;EJ`fX?P=4U6yn
z+sy9upnV|iLwv_}z+;sUN|AV~Ux!98I*D|FCji;Xme5I&21TMgF-5%I+q2Bg51dVj
ze<wEFp^0z2<&F}6<qcRZDki*Kr5#5K1Q7sIsDx<*8^1m}(pu-&aLW<ELv2IUzG`3M
z9fvAXE0yh?O8#Y&a=eJtWK)N5s<HSz*?*!^zUrU4LDk-gb9Mcmy#RBq_UV#%7EJ9r
z-sGhY5kex14V*wAdt}apt$A@VM3I|^VL4ofd7NS87kC!O_1X;XO1ZCY+winUSzN-;
zup;hnQYG%CpY2&3_pEzYFcsrva&I~Cx>rS9i3jX}c{h`N;>83eo4lP;NgM#hU)V_A
z^Y`2&YG#KSt`pCa`R=T;dUJq$O-EWw>EkAQb7(-CV$f^S=};srx&EcX%v>fjDK9t4
zsigNVIy_^XPw#ewK<ooB0J?wFJ<p3>>Hs*S{`yw~XzCJggLx7A_x}ge%0mg(&C@KY
z|NVRjKVxDAem1LR-h2PcOy&|UM&<zV?>3MDns9B#Eq_33p@Kk7RtQlJe<Txxhy8Ez
z+V*4@GB$J8?A}}V&TI%*N2~md)|%}@&e}h3i|oqHjZiDKJ<8$UeJk4vl@YNTUxo=O
zFYfJgw)ADKIa(PJ9;}I>%X=MFEeD&cr%lsSrE!LX<x|sh`)|&Q@r}+7Yp5#N;7H5b
zQE4wK(({H?t+p#OEk3ogGff?#vqh9!aD8BIRh-cs1B4+^6KP4(^YPNa>xt2v1Dnmv
zRAt%bZM)GrE)$r|&+o6X(-tb5|6P&CKC>1axQWW8{FXG&xN|$m%Hla0{Z=-&chOz^
z%5wf(inN>J9{Yxh56c$ms2zO!sBMWc9{{F%zlRg@ci)yOTBq^INMwjy!?c@R>83C$
zD>}ky4$)4jw&efiZx7lnewGOORZ|#08WmBTrHn~QtI5s(_dj1K$ql3q@Qby<5peVJ
zwt||uCd%R{c!-)36BNO34cwkzmt#rbpKd964bQo;-?K8V6}(?nK5c|X1p6>CFQCvx
z=-zFta#IGLPza&a;FfMxN<GYgfjTCjwS*9kC39Gt`$}gG5AEFCKeR5r*x`ux3z##d
zYk2m~m3;{>gx7}uFtq=vo%i0o>#2o1hS!eF+eXd$P4(QBFV8X?UY>1^XUiH2EgHv`
z{>F}-J9@hsW)-G8i_(JW_LdDhdb`U~3vOZTE%)wiu-of*E+{seox?9IawSr}o%YrI
zPhB>$mrY>1b+W(l>3}&B?jse2f;%I{V;qeqQY$f1VF5!DOy|DvgQPZ2Y$k?hE910j
z-cs5W${@CYqxlOox4;&0PGwVs2Z586qBv)oO>;KF78Dx97IHL|LbKTNrp6W=63p1a
zn#c`<Uz2rEzKq|epZYPrl!JVt{i#p<X}R!$@jH3ak8ywCjo6Qzv-~qmEznpDX8Cfc
zR|!jl_WWWBt^rhG7_S;k&}eZ>95>?E{_w=!g(C~6tsXvpoDZPSLJDhA?z^|F8+2~G
z)>yl6puJzY@?=Z*4GTJ|Bc@JSx_b3y6Yna?Nh&rSS@3*abJp~nw-%I_X4}YqG|J_&
zNS|r$coJNGKqaAt>(6)!HYDypQD}$q5*~&*+^|q-N;(X}HB6|xPNZCp2mYkxA^8+z
zC2UdH&@J|@wjIsm``DMdOln6yWcx}i9|^XapQ{^5e}3)bBHX?su+_C+=)Y;Wk#3YW
zx$E)FWM<00h02l_sCYd;!Y`BROA<Vc(G?JrmXG_1#0HON9BUxs7;)l}v_<M<VmUH*
zd<ASbx<dT`L`)PLgcyrZSx<oMxJGka=079bsmIb-7*=6b>K{;3A8Gi9Q&<uxiqSot
znh*_ThIm}k0=HQ3Z)=3}Z0uY5&v2fBhg`J!K+Osf5E0Li;RhT)6)s*uFu^AJXJn1l
z6_0B)k0)uSQ>ovn)!!YOtqla;=)bgiMsxj+7ht%rJ0a_+Ov5+8@2`Bb$9V^g2fPL9
zq5lBm<$=efTEK-26}ideJr6KEWFHM+LMXf<S8-&Y5{B}FW+%sAIyv!Dfc0widbhaq
z<ff6ZJsSS8z>?<m&-Bwdu6N)%fc@PyfUT4K#p|vDpkD*f|28h?Y+L`dMssl9mPg-p
zyaUDm53U3GPKvv=lI%(3Z{z4fc0G<wLBAH5hd}&#DUXGLttg3d7>&CoI(iL>$i?(Y
z&!}8#j6~%Ak*9?CTp={~8syw<CgHhzFeT6G8KV0R<%hw!uA?^`Ai=uG7Yad-{+z@G
zTE|zwCs9Oqo>h#9L~$E^_=$qM%AiKfgU4Q!IX{o?WdPwP`Af|7sHlF`fu}mEBk$@l
zMACFC9ck#fE3&%dsROF%(fmiQ$Em#bqet8GAlLIG{~e_{32>g;*6!<@n>SRud2{Vh
zUaqfi`?gb&2`}~@IM9o7GhfNJfqtBVc?g`K9|PM0aS2Z$WD-P87JT(Y--oZjX_*L|
z%*|Q|VYGQ)M7-xTQTB;`f4xS(aL0_<o_7#`yC2nim!R^xrh+Dag7H@6MOg8k&<wPx
zOb)Bt!S8jECRn^7+gSuyB7jzJcpn>A;)&i)6njsNec^;_lZOJwwRZ6u%`2BsoqyR|
zQ>T0kd?kGm^mK@zLK`0*+XQ!lo=#MfNfD3ub!+P5nmK*ZLo)|m+<P9cx%KkNRB@LR
z)$b=KOl7sGjnl7*Iylrn;48Vm0{^i2)J~3TxZ{fyEP>e&T1kWgjf7S(8Hmsb2FU0^
zo%Y0g9`{#oaQRvnzp`O!Uvl33!hO_|We@$9|IePCr+b^~lUg$AQdf3O(}IItb!E-F
z=R7-g0?|;M+4XLYeR01fc{)`~-Sw*@6!-e6ZJVu@&J(VJ<^Qv|cjk`eM{ZfM=RRPG
zcs2m7JAi&b9-o|g0O9CYW<XCy1GMB=#&d%RC1~y%cT3<68_*H0vsTvOJ*^DKgY{!O
z0|K)&)oYd+Px(iv6$9y-0m@8eWEL&o=4{x$>+v8eG|QOQFp;iS%SvgpiRxMYnK?uy
zV~AUWnu*1f1Axt6bx~Y$Y7UK8rO1YNg~L_4o6FQuAcs(6{{cD+hWSB3tI6kwRA(V^
z5CW4VMo5634)%t=D%$vle}<wz4Is`@1m~zLCIY#V1}OU_pssw76N;b;IF`K(bTjW4
zVF14JOTx*|2`xZMumoNf9H@H<&T!ew-V-nu{rBPXXqtfV`3Gi`!25|4T}6SQ^8YfJ
zUoy~OQh-E%a{)JCRsDta`QLCO;eb@_X6JfOyfy}nF;eMnFjytQ=P)eYE!kimm^edR
zN>5SD)A}-=ngBKzMYS*PBRn(u**2I*A=*?Yp9!4ElZqO!f)f0AieO0!ph>rV<+?Lu
zqL|?pF(z14Dkrdp*Y{s1Wq4jVG|`em`NZ>;3<Gn5NJq&tA~0#9VSw4>7dW)%juPxf
z3^Q&yL0gIUB0VSBO(r*$@W;VGG8v1e`*A%y%p}5oqyGUm2GAdWekEWvCNnwUL4=$d
z{!VUcP^;*Fc!S=tYNE+uld?6p=Vy!!57+c8+%bK~^Pu0AInm<4MW)mZPikw>S9GHJ
z7wW~YW{<)732QU?96_oh1ScLvD7Fyxf|CO=#^cCUh3eU3-cxe@L@Ye+Gu8VOeaL?T
zX+8HT8hFax_HFj8_vdR6#VMRMbs+np#}o2!077C^m>^ogE<tafV0pz<84s^FTem--
z|0h-K4eeiJL-_L%X{wghUDUTD*FFiHeM3$~FVjWsa}6As0O`~u`lrG`IfZ9MUa;#H
zIzBFJDxMr7eDeW5up3T}Q{0yjZ2*TM9&#k8fE45QsMCXA0G`L|1HeSdVL0C#W(Nyb
ziT(apTE{*|f75Nta_@M*DlTEk!d~t9x)*my_lJc)E!-bAkv$;;X3YLn_?yP~B9ce7
z$##ZP_J%5PT6B)`uMdo09j5$TxH`;z-ZN<XfxMi_=P2a>fdDR<fRJ(^*rwfk2Ckb;
zVRW;H-N*GTvGrId%CSqq^25YR7N2Y1prJ?PnU&l&*rzqb3L+8%)OjL&5>wCxlYt~I
ziOEB5QA$nN5C$+NnnTgDBN7sYRnAF~PN;aZt*v6}mi9(vNJVCv+;H2pP19F>u$7V*
zIOiQ{$Z!^<_Cxub7Z&D(1ca-NO|<oBzOA+(CB^Crd1Uo%OPUr{m-9cgXC)2I*gl)h
z%dYB}mE&0c%wSP)<HE+yeoJ~v{s7#Nxhk(XeJbCPq%%Gdlgm%xzll}Wr{w3;As1vN
ztw$Q?wu5jboDr4Wr@&8B$1Q|drO``1hnwhx5Ncwpl4dkfQ0G1srsWpUr#7@0S~5XC
zcTb?mQ%;vAG2oWZQ`773bIDOOe^!E*`oddCcf*{=9R<HhC7uGph85R{<nL=jQ8BuX
zrFgE#b<pPl^jkYy$F+;s(LW|~8%wHt4qshAhnd^Ia{C3f9!v&|&{rKlI}<^ty9%_H
zCB@Yvb-Cvu2<KjoW|bF70YielFJsuN0^+BSoY{TDx-GvUe&&arQ*R@FW;fv9(K#jS
zle2#nC?WpN%3BVeJ#pYLdY6AU1edr)@dqSmA!(?8ou+}mf;`dz^7v~2XZ<ADo){b=
zY!m?O`VeBAkk<^@*95?4u7#Q~|5f=IX)@9j?y4%P+xfrLlHqTZCWUhu0{LN@Fc+gh
zIi5uA=Kg}=f3iSi;6X4)=}0CfVDzyu({?XDw05QhpfItRkbus&#y*GgH(i}j2<MG+
zO__eVx<q~U+OE0#`nNf4)8>}7{Is*KsOp#mV~Vh|sRfa-fBO1uwKZS;%85+BhRk$*
zYf?<QeQi&PT^&(SF7AVSxPQT1EEsL;=A5Ah0wMA#vtCr{NXQP^5^|L{Uy{rh+`j~n
zmq)E!|1eSz-6>HJ#5BCIXD4$-n%lLrPzhF`rDsKG4?nVE?Kl}hK*KFJzY)kMNRy%i
z2{noQhS|w2fY=sd`4dnHkg3P_F%S<Nv>tV%gvdb8b)uGFIUg+RLu&-M6Ec&3D-{0G
z^ie5L_(y`4y#|GSGN8cEf8G#)T}Cv8up+urC<AouGb{t-<~Sma+zNP=@}}bxJ;$Cv
zBZBoutWg5w05g(K1LoGPJ5FqvDnTLu8XK-PC6zBJEPndI!opjd1`ASVF6moyX2%xl
z?Nj@2F1=I2nM4S~YG;el89#%{p{#xJja*+!{@`L~-fahwe*-<c%9$%5b3wYIm(2ps
zA%J93z#-n!Z8aJfznCi?l2uf+H_#qmc?S(#?c8@p7BT_mJH}<Mhmjp3oS@Tlm*Jej
z9Ar1gmQEQDEmxEXiSi*>!#%h*cUi#UgHvAih_LZUf0v+^_`^WpZ+}Z7YlM7y5?KTJ
z^wc`RJMWU?zvD|U;&T_sA|x6JQ(Y%p`Ux1s6ema-#?*ede1a@t7ytd~SzQuL0_a#H
zwCUCzT@APGNK7|U`}mhPm<knnD*6xLq}uz;lGU{*T}h@12>pC8Kc$arT(e;B4aXHG
z>XvZrA}TFL8OCo{%v+3fAm-0NY+SfIW-QU2wu8FPxbI0);+U2XZ@Z}sGoNz!j@5_G
z-JVtm6{^aGBq(MRW<Ck=uc6INXSQv0cBQ80@fX6>EnQB)6U1wJ$7_3VM6v@ACn$KT
ziKGS)&__vJ_Rj@v(?4Ql_6@s8&~|-Yen^74@a*X#H3V(zaDLPg`fiB7OY+EEkwIP5
zUkFWvG398X00{EvyZbt4#>H4N@{`SToepmx*4^9JUuY`Y6&g~znPIz}HnyfcvaU9v
zyJKhqIQBm@M?B7;JvNojrAKAH5QzxU8$zCxgaK0`o)G9#!b=o{GJB9Rs}7atc_D=!
zedosAL&Nii_V(3eFMo)W>jMwY-Jf%0=M!LO4m$YL&D7E<0|glw)>(u3Y0Sc{FLd?n
z+%vPUar;0Q6CWb4tuh!w8m2Pw!SecN`A;2d@2a(L-2)N$U?85DUjy)v^B@O&Taz7X
z1YSwtfFgS%!(B@r=!nrN<&5pt=Z->hPkkMv`Rv(O-H}i=qq2E^{oHN$&_B$~g+!l-
zs4)4y{Tnd9XW6P%jsi&dNtv=Z9YWg?4#)?g%VedP&y4&DSR=uKhe=h6a{$1Q8+q7I
z%UYUrfq|uoaj(4S45_Qk+7p#l7#<gx5v<&>;g$sj=@#z&>dFK)Q*0@_qm<7}0*_${
zW*k7Ia~yTH^!9;W(K-PJGr*8TU@&;7puow=py1$vJR3YJ1z%>KU{FNY1zon`mWBE0
z7KB6ri8TmGeHB7t57!Y$m=}-q!#L)eDuaebNJ^-4Niv8UrvMsC4xS}&D$o$O8%w_n
z`%_CQl3)dCJfE?ifn<-B$Op8V3AR}JU4BJRVNFX*X?hD4(7EE!Tf=h?@2$1wZph7V
znB%Z!7xdR|qL1)f4Jpla)pmuB@@wgQX4?%t-78k`^Nv;8936E7Gi$r&;ClGH4e|J|
z;x01E@frj$IEZR3Sr|AsJXkQI2USWE9tf#I{r_n?FuMNkxXAnUf$71R&|;M<=H3$v
zpB33!ho9xMQ0l|QpHPiPPRRR!=|8X!azQA6O@K;h3p2W+OTh+7`)DDn_fhT#kOfGL
zH2?!R$OB##PP}Un*NS5c0k2+8I6NJ!;8#+O$GvWiUQ7~}gy7fVsHkBfi)nE*cb6Fd
z>iT2k1tDb#6KnMEfX`*M6bQ>-hE!an6^wz7g?t5w0vFCHOlt*W7+m292@8lCaQMYS
z62zQE8imF;_n)(>!hNYinr|#9UpS4jWh-FqL-~vYy@?Qbin$`C)Lr0HhiDner;Y`c
z$+?U9<euJhL3gC?vPHeCwg-Yw+#v&xcWI_A@_n@}I5e28id1x<|GUVS^`k!aV+9|#
zicbt-uyz2B^#Y7VqPNjM3CvdrBZ8zWGN>08y$6RK3HW?LJ10WXVT*iMV+#xmMgZn$
zwR32$EW;M@zNR23ESRa9qh)qQ{}G17qHzGpAEV{bC)~iCfD972bLs%xG4w21TRnQ)
zC0iX?UD$(?k%hQ>&|GhpTd)EN5FBO6Pc-G{n-cRkZgiAD=21D7R1i@>$v0lRlw!<U
zAgyQiwa!o>>FC!q^_^Lcxh<~U?aF0FjY?R{B-nEX$VF3ouO-rsw2}r)XIbRn3jQOk
zBlRs=N9K7UZ|v&R;yR99rDCbO;aw=qxS<#KuNa;s#6^e>2p9rH05f$rBu`aXA$iIa
z8#|n$in%*b74BP%1BU2>9W?8iHdR4+=B!=Y0f}trFMxF|qaTBHMV~a(Qv@8j2?(~X
zXY>V75J|ze(vKNjcLs+jxIzr87`Ev?in51>hHy<XM%TYMBO!>X;;$7^zCz%H7)Ig8
z`0>W@+~oN%Cger3_rg99BNC<aLtvROM{>Fg0vg$)02HC=pKEvLlc5z;#ok*~G6ZO8
zYd2|QhL-{x`S0@LCeJhbzvRY!O6C>=`F^jGxe*?i2(0J-_naLnJ(M~)GBWaoUwD|1
zw8OHVNjm{)97UISxA{T_ASboChJ_p`+<VLlSUcpZlP!+4`6Tj1k_9$Pvdw^ktjr4J
z@Nq$e!xt9_n~*Hk0>~|bjHJ=^VtS%q95rQMO<4!u=t;-4ndD@x9r=`h2D1>6hLN5W
z02AR&A^<;6MV{aQVUeSfRg_sPhDwTlCIfLeMr&$sqwaJVVya80QGflV3`9QsNk2_8
zI7P_bf|#e*Fe8D2d=U^)5-H#g!odUHM34!<k_1uZf`gZFE{h8b<{OvY5U99esj~0A
z$Y5&Tvh5*3+u6-oe5fvr`Zqr_qmW?=GpOG)MPYm|)sSAqFvt^0juYlQDj)+w3*#w)
z?1U2!l4wM0j@%tkz%U=)cKCz$kK8sq_YT^G>4@<(^#DJGHezC7oRC(y`|UYHQ)cIN
z_v8&Y7ub3RL8-=^<^qT}KM!ZTP4H#Qz)_0aNSqb=NsI8FKd3H5qNw3;!~F}zIf8)A
zX(<x^6bb>19L5+UTV{sex;;c6QuIV1axkU5`0)8RZ!d-mAp`G@34EdmzB+RLj!f&|
zLQ5k5>v@*cObfGN?Mq=hwc)Ioin}xH<&kx#!naxRa|uN=;o7a?r<bfRtO$2~sBX3&
zqmxxtwzV6IAPR=iODtUlxFT_-gkD5lg3yBd06{yADAS_H3WX{n#sZUZyGqa&g>GWV
z8?S1vUN)mzXDkg==$cwV8yK!A(MHH<%dv;=o*Cp!s_v{B?sO(AW8xqhlU3jRP<33#
zmVzpVnVp|wo>^{o&>BNkjae66Q8q}$=~R9vS5JW{hG=sere`OcOmPqCwVH^9{gxO-
zkS4PT=HWv*=o29SBJcK)e}U3q@jYZffqMej0Og6+CY=K0UOf?V1tHj^M>#ZaT;jd<
zE{eCgq5xdZqzlrnfIA(@<%EhJlbuzB>LyR_6b>uc>Tp=8G}q;MdL{W<xJgq!L9X+I
zS`OP`uNz4=ADs5+qIV~M5&@q`a4HNH1jb`jnYr<ZA7=X<z-6vht-mEd=bn2o50tW#
z9MC)XFZt7u6WVP~XKw!k^15Ond2@bAqmUDNxtB1W%lAxwf+U9m{_`NOPz(DT@sIhS
z!j|(0=@H2a-6N(%vJDvR@&y+TAHJ|)d2L?Urkcpmq{1aj3KK&jYc_>h>ewYidv~5Z
zxpVJOgIs1d)n?7Sp|Gc?@P?ULwI;KW%V?srNE{{jGbj`6AK|WKL6DRVY?wC@s&U_u
z@IPT_=d1vxx_<SVCn?!{d*<OxyV=Gv{c*<b{M=<bLPCJcP%*xt{DuC?x?KZQyD#kr
z72hx(lJ(~w8%b2;o2#juEW&VzEXyone^2W3NHPoZT$r*{qeTt7gg_t|3W*cWZN6GG
zWA-BlTRXF}8HX{cq%t|-skLSK3F*yhRZ2^<GuOGZ#=+cqWN>~-`4%d|F*hP*sy#V9
zGu8S1mvcH-ch^pntJ5kQ3iL4p?cx~#^@8evF5(a`hAaqiu;hAH(#o@j;|72W*+A8(
z^UNQGywczpF|QO<Iaz5`Ahn5q2=YgTu!}D0_i=H&43bOX)xc-V=$qkuhe|p^EO9Xf
zjvKJeSoNTA1w)|}z`2#aS?l`P6u?oB-8IrEFI3X%!~l-(_|^9GgaBqH|D`rC5XA3>
zWmjV17oIk!ZYJ-hVwqdv-9(>7z61t)bWcq>gc*voqDU(oV9c$S^!x=o_==wyv?vxB
zlOj;p)I#kB7PE8Ec0CCErD~B2!9GKq$eRF5yd;&Tf(sK&B7*T@!ju8C#2SKgr{A33
zGRvG$m7kRT-Sxm6ysxjn$Y|T5sdSbz>{M%3?uy8ostK^X+Z=H$5rkpHiIb`Y`Seu@
zitG5AXdgq-P+S8!hurwF;W>w=L3(I=p|xj*BY${iv?+<wempHI$*(Y!HYSGhS2wkE
z&>MDicN#OA8_*`yP%*W0j$Z=BD#98*jSUOF6jTLX2{`jmZ#xh7!UcoorU#%TdKY7y
zu0LMs^HtLxe{5QHMekEjPOI3<nDT~(@{BCCmtW2r@pluO@z{aaUc2ehrw^Vyd2r`}
zrT5;u?8efYmLEU99PXIAh21bVU-l8`uECfy?^#5HkuzRJHEyw|q}cKA9|phPy<Ykt
zTP8Hx`5D>Nu1daI{P@f74xkdlJ@2h^zx&m%2VXlay_@|?d>K{Euga#5CQ0w6Ty3r|
zc-vS7!I2z=4@<7_6IKUr8N!oQxBvjoectB(%%Vk$@=O-ra?3oU7XCBN<mDzRUz0B9
zOi{`#C`g=`R1>WU2~jA*qSa}#P#@~r)9jmL4(<`35WowrIqVWBAPoB;&rY3K9g)>O
zFaJVGxmEk0s-;{i+?kjCWq#{!c<wZNek>K_77!U34#KgmAMpPJS+cfE-1I}6HW6C$
z>Z3PWHTn<uhxq?-UZQO5`9s6l$@@L>M0n8$&P)6ms*AG@!)v_1*UJ-)@QyQ=oK!IM
zsM|Drh`gf<V7VP&kpnF9L^+IP9ddsDBmchh(qG{{BO@>vzRR;8mk2L|e*6c2h1aG1
z_&I@l_|OQJeSo_Qr@8*j-#k`{{Eri40nBqHDtZoBIn-DPK@D~WwAb=C=j71N*7Wc$
zd1q3Tn$0?pkXQd>M!HNMF|a1Y%+NU$r9K<Qz)d*mX#mG2pvO(zOF)f2j2;k9%CQkX
zr-xf{Y%ly6vQZw5SNcWEsb!q~RjRN)zaIWae0e?#dE|&OlopXmZVLJF1shx%v`l)K
zdx<~w>PF9J?`JkajWSp>3hug0q?k?GYe%mg)iRsdchh-3okB-5<thei_`kVE$fqZJ
z6Q}|&EEEl0NO&4G|L@9_`LpAc<>fu`u?aIA#{N6Y^BwHV6?TIyPiL^%+VbMn;lt67
zh<wMTavkJ98Cyo~w`G92hnwa6Cp(6^_}}A?=lM@xr4n9+`7Pp;#x{@r3(o`Lnj#Zn
zMTwL~4g<qP0Sv2pW0kXa>fy?|#L)aA%I^G4QBLcztkuKx^Ze-4+|0GQphg4ru#wkq
z-P-MIV-as_*llC0xR=r5E?s|wE?MCDDp9mUp%d|F0UMh+XIF*2uA?M7C%<^b4MXWA
z@AQ^rW#*M8>y3NjUgWe@sm5Zvy|}-Va;W2H-085{9h#`bUaExPuZ;O4{}}g;JM$fR
zJgkq1LD;KeO3b)M!9O-@$~-pOH>a~n6P=n=oTW$(%bJ=qWoBz@ZZ?<Iw|Ky)_2*)%
zdgr7iBs=1pVpH>5Z8g&iz@80rJHd90WpM8aybWjqNGcRA+a$t55nkd5^MZfheWoid
zr~bvM1KJ2pw<T_RCs%xN`gAI2?zWeW@wz{Ks;_)`54?}L_9EOTnh)@2fxR63YToyW
z3b~w~!UwDiy6@rg9dnLYb;}SR3{eya!P&6f!KuZ$km6#e0=v_6`uu!rdVYr`zojE5
zGvVLdl9mKo7823z+u0d7_0gIE_FQmOqs^v_$=wv9=?horbIfLKWOlYWt6qP&kqer$
zY}x7xIVQm{*B$^kYXD9o!0ALdVdBJ|FQ^uRzBB>Sao>t?+UFT9P!dL1lNVNZ%qwCN
z1_0LC_F*@$(=7JZj#YD%vAOxtVak}i{OC~rJ&t;?Ce6x4wl43GH377Z$q}+JH@pP}
z>*|`~(lg>3oAsHwalUFOhotDUfyM{+<!f&P+y;VQQ~~3KySfl|q7hvWHVA$|Jyubz
zg&b=_L4PV!uMJRUYf|e4c&DUkCFGhCOW~HQ8kIJWf8kLC^LQ42S)G@69h}(-l@Hb3
z!7!R!mgOr0rXz%u%gX$Q|24ozD&D~ESCQ342{6$@G*Mx}30cD)60}ajf`AnGU(1qa
zv^*WTvbbSzeQ$nxL4JO8Y^o-rygD+%5$oq47#PK#^Hp>N%0hE%lcCH=YT)9kwh?uV
z8Pvd_zySS{h4G4%kPu=Qq+Ky=8~?s+FVycLk^*1}k3ax`_-n3PP5%82-QDZgO^uG8
z@_NX(E9&N`bhaXGxJqX)(uQ%NO^X&cHm{N|k2eP1J}|#lo0hJvsg27pgX;nAH8sFk
zZ_ADVJxMlhToGX~axh-!CQ?ms6Y+0v=xQr2+tiU}inYvOWl@Uyg5I=g&4V2L+OThs
zD#^CSMMY@~@^z71NYlbxYis+`7+ZQ49Tg}uC8)LjX=d{4{09;$JCpRajq%CJaX=(4
zCG#}@Dfd^P^k1lb1~&nct%$%9VnTu<L<Q|I4<b|&>cQG)kRJxW3rvsyG%<;ajEJ*j
zJF}DJ6}};%z6-M|TTAO|N?U7UA`)|Riu2Pl^9o<9GKB|LCWZ$N9c+(Iw54Qcr4(?_
z8xuH=4bf-V5);$`igYT%P-%;gj@B0xXk(HSbO~noB06FJl$h|;DbY&)U$z9eA~`r%
z3AE<Nw(#F@qj)1A2*H9KV0@7QX3;b-PG&_E)C(awMmbjgoA>~AU~F>R>>F>KRgxF4
zh=^7OM)&DrruD_@J1B}yF(sxr>e-KEeVT}bRc)=SO{R#gn$)fU!|<>{kr~HQY&P2C
zU2?XE|4#M{@em?SW6V0%LId;&mKf;{MdDllUM?!27_bh7PSs}qJDV{Y?x4<4`KOlV
zgbpa8IGv77Jhn8Lj;yf6WR}^qN%WdH2it@4fUjb;p-D|sC>%smkL#)I0Dfbq!rzxN
zv#gm(QpPYhC*fY)%J%XL04_X>30&@yY=V~q;Nur8l!p!m1S?pbmPxut<Cntr(lADp
z@LtzHVH}`u%9R7}dX4*pc%9{Xi&<?|LXAc|?*zj%ydP$s1v;=`nC4&8@Ouo=GO8>&
zY-4arkiwryr4<FvNTna=b6*xX%{aJ&9tzCmFiZ}`Kt>H46XArR;7odt?HP;ZK1LfN
zBjhLI86?ys0`?`~lw<(p5UU*oX+l6S-c1RHDlqEBo4-m4TC7M(iQ3{H8s@*Lyh|?Y
zDp%3jTcZ3oZuV1e4^q-P3O)lqnQZPW{z@1Wl>NOji>9-b6vt3m$}zYZJ`A8_`0qgk
z0GN1~{}0?(7|So=5?}%)8%4YE)C2?+RBX}63SU|I9|psNha!EG3UZy1iiBCA<b#eg
z-j&_7ua;n2^=4g7<`ET5fo=m!`X@c2CBSamaUvMy51_AJ{yXlEp0-O+ILGloY?nGP
z^9klX{=4$1z<__1cglS`%l&Oz!vfBgb@=*qa1W{Y&m$C6#OLBneW@(Pw@<2I+K6}B
z#lU|09`K&)L!wN`Rw{(o5*HJu?UAfdSo$o{k}Prz5Ppyoz=lgi#(*9s{`<6edwGRj
z#igWZW~fu*Bm9)I<j<UWl`RPYa$k8!c%U-kx#{VO{2A=+v8h=(Y!Fkhn1#YWOg2Tc
zR2aB3vNhT~t4?JwB*f;uV&|6OI=Es1#`oZS!F52{8sWpkMDTXQegdc^!v^R$<Dl{H
zHEpQW#m?w)==}YIf+B;=3k$8~Z6*RuSa4V*dwcZ&15iXnlvkvN1glgEO?#ByYBQ+f
z6957jy9Ids-7q%Vdthvol}Ln$hhY){L2l{hJjew=<h}cTdzvm#9TCn^+NskEvoaUl
zn`6=hsUySu6|K|eH5$^{cQ@*Ek?SHuWy8g$a6kW;=A}wyWPenS-E0aAj5Wge`M_sh
zlo2_Uj1PMb<TIdnF!bW$fN}v$9M(pFLB+oauMceL3yt$LXT`LJEsm6@+?!*J2-L`&
z_+FJWjDI)`O7PR*5j?(Br4oFjt`eZPCx8wjV4iXklM89tZk1lh!{(m|=3kBRy;$MM
z=5qWgJN#N(6RF}j?xDy4KPoQSc5{TkKmSFP24Xh}ZM6bzeF<?ZXn`k2Lh*c*%Jzyn
zf_SXt@!#K@Q!-`k*4~y>ZIVuwaIdeSz>yFY5pOlsu+svP5?3|1uFTEl-@)Bd_?Vx6
zI^4HbZOF=!Xt|C59(bRMRFM~@yU8MDg#C*W2><<--r8(mzrYk2?w;JzsUt%X@%hG@
z0E5+Gh~lDJSL7;!L#Y42fH?s_C9ZC&jn7JpdL%F?JqzXp>!V;^;lGCUaUy*Hao{m3
z`CbGGo*b-Z5a!)0CnYt({(*%fHf@lY<ZAxw1$8E^Au}V$KOikirH!|xDrIwO=F?G%
zgs!-_&R90tYHlmZu?^h7UM-s+s!m8v2~#lX#w<sM*<T(WPAjHPSs7Xx#<zqEj0J=P
zTG^1Aq&F3|Cj*GI%L4TLGSG7jSrfM<#V!=Q@~FhBmKy**z|hOKqN(jUnTBgrM1ljQ
z@8F0~%V6)Oxo3PkW1>^Im}a{JrR~yqGsxQ-5XaZ7Ultw<xM>C2Jqox<M%<7s3bG$?
z3M@G|fqaSK81@iso1<1sK!PfK(E<+&uB+=UGsGBVE3z^}0^?&%ZD!sj5iw(KD{Kov
z*<cuGcpI!g@hiYmc$~)M6eN{42(Q4AEU=ZvKY+0swR4y<e23`@iQ@14wr07n#xHfD
zZ^$e~P#~-G_tPkYH0cI^zwzI6aE|)QHQ^y@=q&ugEpDRL!bzG#j@AcRb6i{|ohSU$
zj_3F1j5)56g3B&|j%XLlJj!2ybrJ7lLrNm~;3!UBFSTCSGOe+wAk&$$dD^tibJX$0
zrEyBN-dPqGjv7YVdx4j7oo#E^)z#^<a^h<1<8!Qf+>b!3-@|#PC$@V+t%xEq5(B1=
zEM7XtNbNU3ks#BETg8zY8EELz={sV$q%gmXdn{#B9QL7@xV*}wfP}mPgAR9$Vc9tK
zQCl@our((jIjP9r3_cFqbFg(Rz)W%P=$X^}?|?p#JGkisSQ}1W+D52gixJ=a?*z&q
zq~P(Zn=1GuBm{jnp%EkXF(C^)#{su^j$@pL;Hr=(hJ$TaSaWdZBb`fUI3Z2`hkH`X
zI!t+)l}wax;=Qpc*)fsGkK#BZ@S&_s!?{3;RYu(em8}E#&y!+}ahV5^C&8z;^&mV^
z*B%6&ts2g6h>2umL}SYY11`=Ck~fG?PAIVmCk2MN;VB+ZYA)(1!ZzS@j`c-H*dl+W
z%C9rJ&^KHau*x@v)z)j4TeVS9<+4D(+!7tNxPWb|WAmF;S~GW?O5^`WqxoI+zR)Nt
zK}qGZkhGCz&&hc(SnZ1+{AmAkFZi)h@D1z3y41i6{wO;HHkM%UCYDO80CGQB4G7mD
zOCc@?Xq3dE=&2wJE(YM@5aJ<dnf&Ggo2}q1{-E^P$yQBj!vyuXGuNcn&^biWl+Db|
zHJjltuQlf7Osa3*ug&+@hlsi+>xu%HFNiQl3sz}C6!3ysIA*TjH@6nRe`oOr<-28C
z&z9@9&p1HaTbD0yZCksx-g6HzAQQIoKZxVQ&K2m^17mJi*e?**PFq2N?JWMFa)8cy
z47!O#<_5#{CQzFxzWHY<4M1?Uu}k^8xZe?58Hnj%$}#hI@y{<CT*fXP`te8HYghll
z?&r(7yU~Uy(xEBQOs>VT^5vSw_9aW&8#P%GySux0M{sv9t8Z<sU)H%`K_|ZdQFcFA
zHOaH+GsfL1J^PDK3gbR|?G<hl*wTgbQCyj8uSoYuaZ%DGQ3&U?xvrm>!(%cs7r8zW
zjKEgr@cUOr-nYHNmA=Bi^*;Ra3fOY?u%C_1lHCE`0Xe>#*v=WSpTplfzIME}TKp>;
z;#cXYqq!bG3GcbK$@LMlX)N9+5C(NS5E6a#abV+o<{#f(xbWRSp3zc|P#;hq@Lc+w
zBD=k4PC5mZIl&(DqHE_^{@5|FF#zWh#7`42N&~WL*tOvVN1iQb=~Q!H<;SLKRh;bk
z@(XEoO5JrW(+8Zj8`plfZXN%=^c#Q%I#?gS8~6y=swqRF#cGzT_}vH2o;`4Z?Rz2U
zg;!XBXQk`Qv5~Pp=z|vGL<49dW{nZtF_uKLX2&b+E6|Z|hes|PIP3Znf1XW*CtrC1
zYAKexzTkFoTY)!%r4uSde#5>)>O)$f#^M!-lQ;R43+>Feq#Zu7yzDb*H<I=@*@ILc
zya($QVhsb6PleciO6bqqS)MC)_a9|n65bE(p8ZGJonrrEUi~k#!h0<IF|YoY+2dmW
zx$I?mA-o^BJ9vUes29ojC)rB^T>M;S5bnw_VLlOflD=cXQVjDv$y^hj2g+Vd<^x`2
zXn&JE?w$|UIWYND3GEOWjI}4rc{{h5%tz=y>W0tGdiEb>fuEB8$GrM`&d0O=WvRdG
zL9hPbO7C|)==J_@S@6J+^}FKL|L+ohU01yN|DA<H7yH9}<?=Z&FEAGXKF+}V{{r(q
z!M;T8hVQYa)DqbS_`X{Bp80m{6n+o*y5|?3Kgpi@#ph2lKM2peu5faKKOA39|J^;m
zE6fr?Z#XWrOY6gzc=i8*eUi+>!k2jU{{h}F;Cn77m${_*0X-Zb?>h_d5jq8WSOUCE
znx8}uXQk(XzMmoV08%T!@g}=dcn&uHMR_Sa2ht_BGv}xih>x)kxb?C<&<>H1(0;~E
zchyi=DjnLPb_2GLzn|Mq-k&PI|3~Tl>|A*U^sf`!ms5}9`+?rJb2zThf0X@FoWGr&
zOXySRKgt5D7T3q~{pTcjU|yc@KgUY%pX>R4pAn!2e2;~n>-GNcB=~th&;Im3*h^x6
zKd=7(U}unaEnh;PA@D=Q3gF=fW(3>EUV`?1$Q3eS<{4>Mlm383`Xxf2*gp~W={agQ
ze18s}y8_Ss9=@L;I|$ER7Qf%-^DOy3ZtNv-{*MrTfI=qhb57~TuY<g|QD|pc3B4kI
zA0hAw{YN?Yn#|u$>QtC~g#M!}n7Z-({4uZomsvPpN&jPB{oVT+_}qH({!B9NC_7Jj
zKdBR8!b%tb=O_~=z90G%dcyvRP~RW=!}n(dK07wX+vy591M|n{;Cp-yzh_dY3j%yz
z<6Rc`Dm-_Lt|0UxjCYv<Ok;oG6Q1z>U7(|}7hG59H6H!{F2U#HBYTbDH;asWl3OU@
zSN1aDv&~}rUg7=NpU}I||4py{n_wP7|2MhS()?ww5&j_bALRx~yM?!tnif+3QK>)h
zGlAYQDFOGZ$9@92!-SPtN&5`x{UZGe{YRzq4%P|lLP-5bS)faCy@mZJ^uO%hf5*J~
zUzYj<fAj3`!QZ_4|6S@2{9`7eOR#9edY)!K^0@-=B3>nad{K5B;A$1WPZ;|Wzh@8n
zoJIJ4=J|8%JJh%EJ@WI5vR3!==ivN%7oI=OCX78f$@6DmeBnHJ$76gv4}|g0urlF1
zfcM<<3(ucqKl;VzPr~^{o(I147NIB9gK=Ks`HS@}2tBol?QZ_YzD4Ls=>I10F@djR
ze_U^&KeP+$2l%;%^he(((uXLofTYBb{vAR)-1#7^x1GC((4WxX<9sKzDNL9<4)5{U
zuke24|JWb*E66MG{TcR75iUE7gXaJ~=eb|^yXnhwyvrgzhV#d~#=Fcw9;kqC=20@A
zJTlIk%n!miP}}SuWIli=oF{XeG#}<sZXt{>^dA+^RoG9YW`zlFWF_+v`;UFVJWA*h
z`zOMBbW$K$!uv)fdZPa!^N080bMQU$tvH^-2k8~)(d+ql06r&q{s;2B5#f|gbwB?O
z19%|c@Avs5KF`}d=9dWL!u$w)g1koHcFz;P2e`@iBK*J)N(p`-H3#1d`#_XW>33!4
zVB9WoyxCN(FdkP*)?4WBvEKB%P+L>#KgvAsUN6u79`c-5|H~5ofggDG_mI!%s~+$F
zJM$}Py+r<zPvHEE`+Sl3Q@7X-_$Tm}c=i9m&7Vp{ek1h%L6Q&L{7HEK-=*^#&H;h{
z3H|>rp5Mq{wi9~5{*&@2b}r#h_#A$JJ%93i{tR4N%fh;xgMUT-1kWRX5}rT9=8wIE
z-@|$Pu0T)RE3%K_d$6QH`)TPs2YsWCTMO+|gm#Ia!g&swqPzbn=TGnibi-mT5UIbL
zzmI(&|BCP*8+p$OS*=7b+}{ZQnJTn%5Y;Wf<JJG9EN#;MAa{)SC-f-1|D0EU<X6J`
z&w0MzqyL*f)BjBl<Y$3?<zJEc3hy741xfSe{zm32ynj@BKkSc($@?Ld5cdb?FTf9c
zcs|)zJwm&*{uBCp%9Eb`&q?@){-2QdLnH`!f1&Vxz6RC{=L>oiwvWG`HOix*9sEzw
zehO-mll=<(xt)6z+NTNa%xBVkStHr6LVro_h4m$MMx_3u%==>hV_y9)i+T{~lV1HV
zGv`FS!MW}sS6>$4j03*q$v@69iwXaL^A+gilzScD67g&y^Tl>yzHf>956|N(;Aau_
zY9>-#N8q;10O}VcCJ6D9L7l)DXKd%b7BcFI<wZ;;AYLG=h7<F2&`l>3e1Tvv1=F$U
zSOA-ZiW%@MKy3Ocp8v~)^6_iq?~=*~v8Tt24OiZh$$xsI{a3E5-UZ{IuChZ78=+nh
zzzDu(0wd&A3qC5a525)3EP`s4p7_PEmMI#Vy}=~DG&^|nq`3Zxpi)QGYQBF0uuo_-
zPfQB!p){yrdF`YZtc)Gn&WoS|tjNz)a2}Q-ti+ZD_AJ4DMjV==&jxQtg6K(U5}_nB
zi<qLv-8C95#i<r7IlgyhjRp%qCt50Z3|2ayJ@o3v`CA^Ev!|(=;}52X&5!1Gtb6g{
zH8;L(ir#gUTJ+$mwPN|Dn~K}}I_5k+e~NFBv2)I%q5B4VZ%lta-K8s{(|zNaY0u7^
zSv%$K6Vv>BQ{KnDo(r^txgRoSfwULAY&RaVte5R(RN6bRH+RYFfc6r|o;ok-hJ+@+
zmuQkcFYO)DA8iHLKN0rkB`Od0=t<dql5EF@LadEI%kVwwi1<A>)raV=KlA(v#)8j}
zoy2h`dHw{w=VzZsS>U|vMQSbJgX|^QzU#(654`st<c$-?KMlO@d%|PBq*(X!8$F*N
zdk4Nh4KfFQkGkP5!kfnDPh^pCodNbT@+cSy@gvUP8{gyjI}2y+zX^T{CH%qsQMMPJ
zKMS^&JMnvvjfreO0e<QE6Cfi?y1``6p8z|`WY6PzuZ8!M_qgZZ;vOH@eGtD#I3~fL
zH2!IL&-d=<%iPaP@B{vY@ezN-79-&AEb3<PelI#Dwix&P3H`Y72hV%jibmbGAG??B
zXB1^n5nef=Z#Wxaob&9H(%B3)AEfVUq204Tku8M&r@i{4Y$5c=`AF|Cl8@WYPJwJG
z?1vrFdWic0pBtwK&;8(Odpia6h|iy3+T8nL3E2<c&wK6%ujf(s!FkG@?)`9_><91X
zJ@<p>^QQrRVLzO5?}sHa+z;;Oh5f+F-1|XJ_CpexA6X9=|CHOd2J1rhgYZ0A7yN!4
zfAmqZK4{wkxIw27&w7d{>vLIbrzQSIA0@Jl(0^309f57i4*eGZoS>t_dqx?x)SsJ4
zbe$Zbojpa`Q8u_pY>TMFBK^sP{zP|1ekk-m4?3%;D=-%cJVO8TXfsCoBK>jwu|KTu
zB<r6^)(@Y<??cFVC&5-h_~CWWe<ZHIo~-{Dzz;7@^85+<p`UqvgSh^+?)AS&*57;l
z^IXoPy83DMOL6^Qa<BhIvi{QZGI9N*-0MG+tpE7@h5hV-XR`j%^TPZ+@%=Q)+El-Q
z7m02_mOp~BHZ>r&kFSqs{}TYOxISL}Pq4sW#PxX^=}UaS$9h74*#F}DJ=gPT-2Y;K
zu)TP^ANIf4A9Nbw{lJf&=AL)=_s|vDBW$F*zk9yWU$6zC?u2xAiM$7O5l>xfRC+(q
z$9A$mg#PD2N0R0{m(U~XNXXYRr1{FW5qvHY@HVa+alQnfOGSKwv?JihtN#f}_6Hf(
zv;PT6mLK~7`XfGt_j|wt{SlwS`@P^H_!Rn|mTYn4{fJMY|7pqB0XDsDvV8aZJ@CW%
zGVi(jyYU0(;U`2_6LbqV{6yA9ACDkwyWt1?e?s_&(0>%<0>lI2U(f}G{-dG{UQXVR
z{6Oe`o~sn_Pu`E`htU80xb6bF4$AUE|I=KKM}Is&g#M>d_J^D<c)vUv;7LMT8fN?F
zV74xiDlzOrZ6-zV1)&q=Wg)5(LJy((kXPUFiuvQ6;Z^cz>s8)2Jj8!pm|PzEbd{Cb
zm{}8$7I3G^Um0wE?ERj~h^x<5W$=5Ft9(@uBN^`J7j}cWDves5T<M?aUl(Hu2x+8;
zAz*@qViG}dY*JiMJmrwd9CSjc?&=?NgB5FMe9f~m8C>)f8pp=Pg~pR_{laWl{~WD~
zg>4HHLw$g?fDToGGB&CI52CdgWkOOiLWw#sq0OxfATEp`ag$gSs2%|&1uW{9ND1Um
z!-S&9{C=;Gk7+cIkvhrLQu5DBYW9HUTCz|O880@X`<V|Xeg?guQmE(5Uv&Qhpc5Sd
z>X>aFk0Jx7HRfZW=nrvPG_DO4We-UduCRg(>YaZ*b$ZdvzN%xXQ+$<)v;SoJe^`4D
z_@<8Jaa{X~<Zer{C3jnvWm&f6F8AIW#=T%;V`Dl7(?U03dM_b#LJ1H8Bq2Q^jSyN$
zLMkM=6p~9q+9jdf<p{RczuA3Hwrou9?)(4SA4%`c?%TIJJ3BKwJ3E`W^zs&mI&XDi
zxN8wwd+z4J4VSN6-0@E0BwHVLKR$xnkIs4$j-7X`^(ih$3R)}R4fI*CXT2f3S6F8s
z@M0+m5eR6Z6(KH$%v)odH*Kk}Dlska%du1FOAqbeG|fq)^Hdsj@(kp*zH->O)~%aY
zH?I%Qv+<Em{ucimfBKITDW2ZGQ3kK^lqP%s!QTd&G=c|+1Uv&^-;5q+M8y9FTC0wW
zw~CD#1l~fn{js;HPb`_^5gO)iA0KAE{h;Q-IWIPqRV^4k;|grr47c+N*nBoD;l*YJ
znt|%og)i7OjP2QVzBJC?drU%OycQz*EbCcRomhP}Gp})Y*P{4j)>o<VMHy01X+oU*
z%*&Wky=Nu^_uYp(W5N;>CYoT)9mbL?8I$a8NtguecCZuoKh)bQrmI!8A-roMesH~F
zL&MWmxkXb-N515y$FHlRJd5Yl`dylH_cNz4N9DPV=2b7H$NT$?PF)N!URU?5PYO@I
z9-B~6+Fl+pigk>0vZ0Z{QM{}91mhCmLc_auKUQwgC8Um^{08LPA|BQxS-O@ZJB0xC
zgbxjZ-$GUWaOs@B{1+tqt>BG)@Q=Zg-&c;btq*=t^2LzwD+A!i`trXup!|OLRS}*+
z<{|w)0<u$3`ZTEjVE8Q&4jm-bL4G~V8~4DCOm?C7H2#Cu32ynHgtA7Fl#hE)_bQ+)
z0yhirnFM|j;C4g6uk^zQz2hx-$63oe2Blr?OG^VCE0*@f6nLc!`a-am4Tj$m*Fh<q
z_65l=m0gI2AE=iACw(EnKW?*zlfDqjzbIK}mA@Z;MTC<=Ye8q#!;W9N5+*wZEd==~
zv|UQ{S&~Mrc(Pm8X)=S5#sokigK#YUReTOsb1hi5lqs7lJ~y4FQB2<_jbfXo#o{VX
zMe)`_pE`wh4GF)67WBg@-h})YBp0pV1aAWTW8`iHC-@QI7w-eVG5}6!RmlIAI2LF<
zrTy@$A{;6$y+Yd^IwYR2iD^UO`B5QlC_Kw1iO&s%=YNaO4Ta}{Y5jPHdfE{Clpdnc
zZK9YSK-YuP`so^ML(B`bf5_XUvQwlXKtqG!x5_BI_Y0Dr_K%SN0vV`~-<`rq{|NAp
zKeZ}{@)!Yr5zOj+<y*n82yn4{(hoxZw}kTVfnOEh3#GBY(RPOo)j#YVF>Q$c;Z6%_
zL-h~0Onh#L{^4E3=SU4jjzil7w}a9K^ba2{J~u@F3`!f&KkQSqf9BA)okB3D75ZlY
z{Fa5jfloa}`-kKQz9aG%Vgr0iO8Q4A=VOtN2yilf1o%bEc%%9I;a5bs1a$k=v>nkX
zSg27yZ-KN~Vj5`7fEz2m1M4MIg){~@=Rm##X))q+AJR0+-36RNTDh2ZgQi*WoqN*y
z@eS?byeQr}=~JgH{ACdQ7FuD!C+9`+CgktqJ0w5Fn*je<0<{qE4{(AX0e-Q+Uk1Rh
z41g257V^K<k7vl=55H=`Gj!fL(r&g1kuDs7OSq-Hm~CR*2jdIUz*mAi$AGo~&-LSk
z+&(9!fyMx71L%zFq4?^eDW}lYzIIx}Z=tXI;S^s&{tKc!BzW(k_!8hBqav&P1YZLD
zBJr;h@z_K0D8R1_fD^n3@VBh+*hBFpz^{sMsI)YLwyhQU3N7fTOGv8{)1qmb6<q=v
za)h*@_<+ntd~OInAPW+o<7k;ybO~h+OdHq-t>SYT^tl0iS~f7PzkjICCk1asQ5U>E
zK<Dd+-vrAJ!K<KW5V)XETnF!vq2M<y^i1S5Ex&`->bj*L2ElJy;FRB!@&!J9eE?tY
zhu<U!x9}@kzQAX$_tOjTC6Zr&-|XjOFfIsO7%$hwcF}Qd1;2?7S;_~xBl!ioxQ^Z#
z5`I&pUz7RoR=Txb(5)phRwml)2B%XUdvH3X|B28*y^QMG_oNekE2LAM`<`?%9)xtN
zd;di`)xqycC*wnSp6cR%kxq4TtMm->*H*eYv>&iF4bqdCNQ$??>9+=@OUz#n(3JrL
zR97b@0On~KkjF}A*9$s3eTOjiNqWETt`~H7nlAL|;B;XWkvH_E52}MOmIl>fP#$4S
zS?7rbTIknN^*{@|paDP&EUZit+8vZmb=AS?lorU?A+!KG>pkff-4*aaX#AdZLJPw4
zREPbGbgIkVlTK(sc%JICf00ggTdQ=^m)1HiV1V*Yz!Ccr)Rf?W<gwOu^`dMidEV^L
zBeT|dt!RRyrV62)0lKdhRdB?^P<)rnTF<qj4DR#$=INsj>pTPWUcIc3KDa;o%NdlX
zk3RbHkpAzNfrLIlHWK`CpoEI_VVzE8<lyu^SqWGnyzicLLLY>85&9?^BHbc80ULw|
z-}8KbI+daKq+4VuV1dZYzeuMt)heCzy|rw$rVnDFw9tpOjJ2i@!l5kvYAtK6>4WI!
zmOR!n*P1?vT({)0mao?Ik#gTW{q$j-$6DT6(+818mUj)z(@!6kJc2z2e8UCV4C|yW
z^jQIJ?1P`@0tGmcJycc+yqn5$if_;UbQXL{h4Kc<B&+ABthas+bgxDHa?5kFmnGZ!
z%j<*d1-R97IWTYOUvGtVTycG0fUgC6G}If`4=g_F6mDhLxh@IrEr4+_7=F_NA0TUh
zV-Ohw_R<Wl5j8=3oZ*Iqm@*O93A!s<g_>%HO*`>?TSZ(nKde1FS!(o|7@w6}mzxgn
ziRtZS9N?T-DMRR3D5nH;SA|tM#Fa!Ws-&WD{O(Y_KD4bk(#Xe;PL1P@o+AU4a=BMx
zMS2nxLCe^|yaqTTbpbmjv5#B!<uI>FpYPj*b0w_6jbHK;?6_GpAEut94Uj$pp7Vma
z_dU-l$xb-ICaR*R3yatHl<68D6ckTBxXN-Rtr1>>M++$ycs!v?Dw8NJ2t1$aYot%D
zWfprHXn~{;f?GXD^*QTwYOf(QM4tm%`H<3(AOkIMLPG$zdJb-+*+j1en-dvdGTC*I
zAqDhVk|xXxgOQ+(-W-tj27NAc$med0X@j530h+Sf-vBf<0baw<{^$T+Ya{W1-jJ~Z
z5y)I2w3M*<U+}|WI<#-7^3&C?jMe3KwCMbU^J5~p!%nC|ugz`xZQ@wZlGKudAP;p)
zqFCl)n4{Rz=oqeKuNc_4p+9M%BAGFZ{jO+d`y~1p@e`jbH!P`2HRz@Onh5-=3u+$`
z{O5_}P~$K|ad?g?%2LnQU>@Tv@xPa9AQF;LT_7Gp#HxG9<-jrfF-bOlHrY)XP0}MG
zos66o7iusj+a#CPQoJ+NwnO;RbkZZ>pAk#oz5k+c!j}a2c^2vbH04BfdRWI7b^7lv
z!(&6hzZc;``Gh7&Ia1lnXN3F|PJDGm_$wkD_yhAW_3NPW2kIlN;|p-YX9W0p5e}uX
zf1~{$HWY1e4r1B>+7SCI7UrNfLR12g23WFPPjDH7ke_a@Osw{_x*%P>&Tc|}g*GUu
zw2fQsj4FZy@|y8Fqit*|#Ak}m4J_AyW1~P<os<R$U0Klpl%$r4<-*EJXCD=uf4<Ro
zU3g?xpr6Ky4t6I5CuisTw=T+wOL8M>pjh@_&;sQ~;#+|3?xlqs8;woUIESMnGn)Ho
z;V_UvSV*X8db&Uhf<1)L0-a9*j~_+*R)7;)5a8#<eI~*@i_n5F|N2f`0~ied-U7$X
z>@jLTm<Mf=fsPa>ls^c5tAE}H_8CGuLisOC-tVsur5yqOiU=pNrG?NA+eFGAAfsA{
zAH4{-$SBA($bK@A9}Tpv4CF^tw~)jPw4IB*{s{Ov*h^gLsI}(p7EWUw^pQDYVcEDx
zptTYUfO|>g=`l{I97wJS?+^i2@3FDGN8~v76((uw)7nOLdck;0@m4}4F(4Q}>4auA
z;iSQ01PGbR;OQU_Y%Sc9tlpvNn%}e$K1l)G6a_Mdg?SrlEHbBmj;)u`IX002)_O3N
zIYf^g1gA2G!1XdZ2e(cqHX}+4^f}qf78?N7y9td5&r!J5bNAXJt@;>jk-{2CG=i4`
zMGoxaCc-<|)}i>y0A1JmIU;ic;JF~Sm9{U5Nr2yhIPBvLXu9?{&6<EDp9ub&urU0Q
z0=3qVt${=6D};r(^)V+@LUfhg;|nW{k;QHN@kB4VTp2LZ)5yoAjvkf-Q&Pe+B+@(^
z_|Wnsa*cR>KRA*!Gd|1#W-9GxS8xmfv7(7)4(PC*UXT9JF?j|9)b78}SH}3TCkL0u
zp49dHL$7CD`^$5Id^hgNcSF}R8S-r%kWY3`KG_Z39mprM%D0K};X4MG$9L$uAs^S5
zkC7b0`<dzdKcKxzXcmb}KtkQP^<Od5p~VKgjDEjmFi3m!`ae10m*5w7aFX7Kh36qM
zr-(5K1}|Q55?xOTwBcEu<##P9uN%Gy9@jE=&~!e5Y9WMA^ot%E#*Qw<tI+hMupF)D
zdLIXcY9)jS^EVn3*^yz1`SHWvUFYp)t6q7|*_Pq_L>=`Aa~G}WlY}zKIzN$Su&yuc
z8y6PdRcJjeZWR=#F@_~2h2;i#avhgxajVV>#Tm&f2pu8GV!RH#nBIZdHxl9OJ4=}s
zwH39l_O@3#uH(I;j7iC1^O<+o`MB9QZGToJ^Gk#mKp6w-Mcb+;BuxW8SlSKsN;DcZ
zh~rkNmG(XxyaIB<lDI3zBtM3;bw0aFZR_T}?s7?dej=$CgLKRtb}7Xl?APjxkRy6h
zkkSPVQk~lJ4icvpQoySKR3>(5a#&7)=LT;(SM^Gc;WVMfB)o>8!)qfnNDT;*YD2=3
zM0~%s$=l7w-GXn5pkZ%sAbmiPCWS6wBw5T|W*@~rt&>#`5FdI=z(ArG-luPveH(o2
zlu#Wc4G1CFgwDrnHbNEMNfiUa!V(h!=EZfqWBqDco03cS))49h{l|Pp`w#Z{4&8$T
z>tm@W^BL{ewY+DPF*(^dAFuxFe!eug-|xZ4{d!*PqakR5*_U7p(=Z&j!rj%*d!v^&
zCoB=KO$rOqGCa3RrJ!_@YegsLR=V4`d2hNz=p<|a?QD3*LOVzjgGaNEfPXNMlCZBJ
z0*<zo68{?*GA<BDB`#iwz938x{g7p{NC?Oo;;0Y;VjmeFQ`Y7i<DHr4;Hgr1IwWR#
z$N09D#f%4di+{Wwuk^32g}^y>@%}9UWp~u7y?L99l}|3iKjA7zM|1+Impxf|(T4X{
z*V442pp3~4bLTcp&Il?ZP%{23bp;Pb9aK*r6oH6`4v8d0Mq)Y|SX1zAqA_v@LWin9
zjYR~d!8nArOWmwmHAL;jw)z+hK7ZNDd-F{kvS~ttTc*uQOq?~X<^CwRHy_|6Qep<*
z=8c16e=uiGuU>tce3(4p_cY-Z2qIN}f!+tJGjMIh%hCII8v6JSx<S*v>kUHZVJ2V?
z`lFS;hR$b2L}X<}glA76KM`5k@HFJ*rqR66HP*SUueoVC#_;T{2xE@9y047z?CkJ}
z%xt5jES8id^A^hj&m-#+?sqNo?k~Cj>YjHDeixEVL0M=EGj=e((3YB%lp69u9}B<K
zSSOW4_s+BVr!<7d{fL15Q^myJ5V>gl<?ylm!W@(sLVyU#k6z^_q(h`F;<iPOWCB_w
z`&@hwc$W>ji-oYM@ZXng^G|#o|A;)0hq=yjh2`D1-CPYycE`k{`&X+3@Iyt1kNmPr
z?P_2nl-l;mTE&4!%ypKl9(Tn1MCerR6pkJNckXlOZA{#{;g>0M@VG1SGdOzlRe7Up
zRteAz554KrJ!k#4?5@Sx4{gSeq7nVqoa*oDWtm|*nUDnZVnc9azemK48hpfZVP9~I
z1m?FEybS*R|AeQ3I2?>M`#lz1^<%C7>aX#~e`3K}KmPi!{u-12cZ~iOc9Fz~`3ij_
zWkh?QNL|E~qE?}AZ1Ex|xtH{JMM<zGn19;E#XQDCZlhq{jB{1P*o0@<Li(&9^hF<S
z3QvQC8&DcsIG{AVW5Dg8!gT{*1@kX>7x$F-u89Bqw!v@bo*MAFL2n;)`<Im&Ts7cz
z18@lA5?M?SO2DC)+zBtT1^ksLewQ-8%RQLgE-pH?Yn(Y%aW4)BK24&}TbITb4k!)p
z7;rnNaGQaz8VZL4OCS8U!S~!#170`i?SpRrvND6K1~~M<vzV8VipHnc+9NGuURrbE
z+!|DdXQ8!_b^!83^#07au%jeEZGv1T{7g_Zi6j*jQAVaxsu-6@S2qX8;V=6nIy?I$
zof_`w=<1_q=YM%^F3Wp``T89m=j3PS>}==k*LFnXZ}4Je_`7)vU^6AW=T&&m!@_&0
z4ID(Zs68s;gG9>}=mXSi_hBggl~O3()4<I9{@Vu_y^qq-vGirXL}zpuiuWCV$RCR5
zd8A&n5P5J?FN444@E9k5J78_l+KS%!-1D%f&mQcU@sey33506aKteDG;k0F7^x`#3
zsKHhoRJMf3V3dLnFLh+LMFa9$KgZn6Fd8$+2c5HAJrm+$htJ`&cFv)8C<T5)o#7WH
z+qr}Q9DdCPOV<8}*y*I0u#61sY`Itz0<lB;9#0{~;j{3#Q2aSNlxxXpc|^iVegqrh
z2A-UO;0KX#VA3PT296Zk?B=RriFjlC?yXy6Eveb{!#NKRZg@smSO$*mzeev`Dvx6=
zSA0cJV?+dd$Tl=KHq_Soy4y>vW0?3$=JK^r$2k6wSU;+R(mIKK0a_^w1Sf1Ojk9Qm
zlxte|SX}GxjxMB%*(fnMI1%~kOu1v{zFa=NscFWTWqZdh!hg>U3(F)QZsUTImkypb
zMzHQOo8YLZU|T8Po|RNQXV%!YsHv&7votrkuzMKIoRI;v111#y21o1-EZo3Z5S*k3
zkjviyjRHyB;r#TIy_Lkaz)Lm$aBhOeKb}2#41a~cI+nZ~IUtAS-+cC2>|>7+I)wbZ
zj6ErJrM3uJkj5X3-5P)PWb$(SPyEm2$;VIt3gD9=d+cX4Ka5v)C6`8Gnb|UQz_Kf`
z9@&#Y%Y4VB^^}@_A_JFyi<Hkw9tZ2lQT`&0vj)*M;0y|-R>|v)D4vG^wmLO`55(~v
z2+w;M@h2XmJ@DsIC>6gMg>)XR?noDf-(=p2#$UL%y5ldzlt8#afzkL3_K(7!4}4~{
z2YrTpr1~7*k4BxV-o2~lJQ{`fpRd`~^RyN4902#7uim|T2pHgOB^rU|G9?uM5cCwy
zy>$zXxJBBFund36tmL1hG3ojwAsMU8N@@28_U^$_E&{&!m5#Q5E|dp5+DezoNk4Sp
zgG@62GgukPJV_%bCm~t?Fv&T1E?SwBgWpC~IvqZNOmJzC6$Bf4t{MzIpFkN?p^PN4
z48bxYAMnE@;kh|E$b?Vmbf^ly4c9C2L4$z>I|&<N2!<^mg#M*9K>r%blfc{#oRE_f
zLQh35)WShDNg7?1%!vr)gUtO8Iqo-(r8TYimY2tKx!zG*=-_B*+xy;_;XPju31%3}
znC|)7a>Z?2RCp2h7Q{z2BKtE%bDP7;){bmyoix0*sc_2ule#<Z8Tvxo`C!VQqCgWb
zgtiajNB{Sh^7?)*g`J0N9=c^|RL>2|)j;O;=Ks_n%5V7_&>jt(>L9e|KlYSvP>b)^
zbNr1V+tB?%e=}LRr4{|{`K#`#{tvvFoKZi9`H6i&;zD{xt0a6G*mAszOoEu7mQ0y_
z<go=~98}Mq=$NQspSydK+Z^H(tP5!NcIL_0lmtTDxP82o>bx#GxmNf$X@G{=eK;le
zshoxAqZg+wVh`gTOize(;-A~36JshNcm*T*3I@jq+<usqI7lQ06d*ChN@6rD?1JJx
zz$5SAqp0o<dL$Pggx@=;uKP{)^B&#c=a8#}j%f)Jo;!L6k3^3^cJoOXx@Axbw;vxh
zd(mfk$&}tnY&(-9kpeeSfS%wD`VS9hf&lkq$tYwI5k`8cS{IL4;Ph-e{(yl4BE9h)
zKZS>f!Vis^vo}WB6=;h;2uH<x=3I8YlO?q^crJV$zhiHYV$Gek$X;q}_KV3{4@Wuu
ztM&&7&(26TfbP}F)`M;Wvt?@v5W@NnVNdL|NVCkaC=IvO$<^L>i)TQ7SSItUD7eg3
zVVOZHr`HcS+o=4ueOjJWk^z0fNZyjH;JUdPqHS19B#>62@mDe+g<^>8;=1Dx<Foke
z;l#I4IV!(!5kHAfzLj_wC8LxhZ22?Kpa63m{t{`Qep({26L1FdrXOcoi0T&svGIuo
z>aVc(mx=!cYSD}T5&PVN|AhXY|J*^W<VAdgPvB2N|9D7r1A9m}K;~F4fT4d{h9jF}
zEs0t!VD1cPctjQ238HBu6;0FRcZu3ZfMopW&;r&BwjD3>PNEqH5~G5}z#0?H3DyYK
zoL4xx4S!a%DpV?SQ26E-O=?5>n%z2El{fR?)QXy)miqXFCbn19{`_JTDK`mpmNUH>
zR0q)#!qyTU<V-TeM_7}5oLDMw-nMObDZQ8^=b2{anq;J8jHTs5Om?b%iI>DwLR}1?
zjzn=I-Ue_<m+#5$J5ialx}>YnV%%_`Z+b;eP9c{}v(D2Y)6Kst*wZKvG{j}4C+Gtd
zCUx*Ke^t73N}^k?Q^1-K_b8QrkSWyDT^|?fBR8dV`6)Bh3D?7-qr=e0ULkP--ilaH
z-AcVvjyfhrk)hVF3{}TEYGCN4MEeA~M7W1^>696co&kaGZmDwpvXnS`KV5vfF%pI(
zXc`qTSSHgksUAEktw*T!H8a`LwfMB<3eouhxnq76MIhcf_=4yGFt?R@^v%0rq3b`*
z^9Rqo2j5FQ{)d_P|9xV9&omv{0=Q#O^x=+L5k$fmG}E%4V+@VSe*Bpi|2H_bOfCA5
zOy+)vpg!2DKFJnJ7Un_stA%xqtn;wgQj?+TG*pfI`u?8k_0`joLU=UP7j^Q(=v?()
zc_0oZ)M=@O<(K<LB&_aH;sxmoe2o8s|2r*93w(J%dG~9fHJn{$DW9pcTy>XOuKHp8
z1L8}24v80*CiNV)R0sMZr*}Ws#GazEE<%z_A_ZH&O-Yn+P<~AoO`0rRf^u%1$NGBc
zei^05*{~j&32OK21_OFkZ}#u2a32}<cV1uj;H?In4Qs-$!b7iv(w~XcV%5!6gBnG6
zgmpg+CAr0(qEh_6y=JLcU+<ZBS>9>6ApGGF?n0eX+oAi>`VIHHzL#DsZ?^pMdk4RG
zsHy;c#xpwR8s7tYoiFJ<B9JW0kf7O_T;OOtSG6ly1qEh)Ev50*la2XF4X?k{kg@Ic
z*O7bZ{MR|hkJ^uJo_77}l;a1c;jf-VmH32LT)fx*;p?G%IIk9M;cr1(0|!w@5C|(1
zS>&XrF3@uq;8oG_$dDKul#r+kPMmPS#cx+=gtOAeUSSh^JCil?djq3mwA$#%o+TWY
zfo$wFXsOAL9I2EkH-8<1V15sNUN&$>?uX#RBeR(aU0X(Bh0xB+6gI05mIAQPDeQqh
z*hogl+DYx<+1Y)t{(RsmE0)&}o7)Fl%tUgT{7rZke22t*i`gHzOfC^%^Q~YF06Pb;
z1%0qwv=yC&*d;QXg?+GcfPFw=odOKxJ>ZjV<=&;|e^Crl4IWTP)CqDdjwR551#W%Z
zd_3E_-_P@qzmw6)wY@PpKGrQ}zYp9yMmfsU>|*~_zUBLcOg6==tv{+?pO;>Z|1iQP
zbvV|XU|WY4(nF}{&-(&Dql1Y7&=0=CTw@*w`tc_g#=oQ=m}w9Sda|)#00qqp^LX{c
zDMvR?|NfKq69=c`Yfr)i`-E3~yw|?6^{c?R2ZSS8gl{uDm=i>gM}q=FK-jnFc*0sp
z<Cz^<;rP9<Y-g35ZM&0nc;}fGhaleJ8GM`P(~-NqEAzHrdcCpdy3$UKpxgo|_dO^#
z2!snnq<~c-;)y^o3u~7!7^qkw>zJUdA&5@_XDh!KZhq7a84pCok6M%5Y6=?p+`J7f
z<5B_|@CV3mw3EH76#uF6bVFhLH;zcnna7lCqw1#YEFQk7vNUu!zH4Xm0K7K^@b)?2
z4K!<z_V6My>OiEzi-evdr%Dkk0kInhwIP)etOm3;B>utYlg6%`*F2>)B%!HjOI?`u
zsd8;|eW+pG!i<`_hSsV{?X_bQW2?tx<SXY^3`@wG)DRt1#nluhkGSUHA?4Fknz!c2
z3d<{+6QiP%MwMr$2Y6)x6DR#@19<rm>gP=?$GmvXxo{X38MAOOw24|#<uMvLVm{o%
zJFFTO{E2Q@(l7@pZbIKVyKDD=-RwZfOogo*%HVkj$6zO)nZT@d4L5H?pJK3>kbW%$
zJY0tNq!8)>G+3}8)kf;c@eF-t6Vey-lqZTF(QZxfMoyFkR9t>{%bX`_bg{8IdyhH!
z;}f)AA(dl_g6#Y}WX=mJGr~<K8ROyGaV#mbtbJ8|h5NGC_qJCX0|JaFd01`S@>%iK
zML|0BtcDMEaB*QgoqRi7eotv@B)G8jl@?|~18CgR8?<MF$OvR<Wn`B1FoACZ-GAOV
zYV#|#=}DRMYZ_`3Gb<{JLW+`2TckO&HZ;{8@G>?wMjO1t#<fLwcr9xlePZFu>t-#@
z3J(e^9bTL%3-YbNKex9v9nPB&T~VGja#ea;O*r6gB)-DhF)xdA3OHs3v~Q@2i!v@=
zL(Z;J#sH1LMBC2gN|C!$MfsVyc6_A9U7Z}C$Vgoep@qym4_Ew0<Ka;+)YKpua?V-p
zG!L1SVA6y?wy)h@5U~a9kNtE?PHeHFMR*Hqi4_P2emE)-mKdNew5OQQCyZXcq-F9a
zftdvjwX-^^o1cyzQP#Dfa#%`siO;?VH8XM_cw*zI5qZPhXP1>^7R=Z?)-^J(VM2aR
zLV8<QooCi?v^=j_t4~dcQZ|(0vf{jujJnm8Q;jhFvFe*ZQbWRjh8RnI)()X_`qq1?
zP$QkA4Q(9XH8QoRTpO7cUKt;=oX?)UVPyTd(QAiizj(+!thE)+EH{p9j0%2xR?F<+
zBebCvrJ??5_Wr)5NZmfVY00|g2Hn`JE0ZQx#Y{<>5M5P~O=x>D{+i2#RTwp?+0eQW
zm#M>3K)sm?n#yL-RJQ0&8*m5QY=WByL2YR#<w&-3nUbH#9FLSk=3<&?c(P|L_-)OC
zCy1*S-~vt=;WE)I(H_v3)5_PY?-|RpsDwCsfnsHV_vGRnbe2t(sG#ydNWwai!ZOt4
zF0j0L*4@G9L{Y((6Fv^^s;|CM;d(c>&dnPxT|$0~+*EeTH}PCN@2rB*50aEac^?Sn
zS$c+04Fry%qg<_0pbrX*EJcx$A3S|&!{$ymH+#idv;wVsQ)#DiTZF#>nI4S4Wu4J-
zu$@nqNP14v_5zGK3NUXnlNYGdiY&FlLC@j|yTT&Aj5+FEeQ4*0&0`*1TRtor7cs_+
z_DvbAjncQ13k<K$GbPxLP=|C~TD^SqxT><w@Xn0J^)kgX^+`nuNt1|fLF&QMdVuUE
z^`Nj@>}b>u-n@s0t{Z8+$l*2AonXK@W0nJ{nWLlH9$Z^d5`~^eP_51Bq*}DPd+;t+
zM{5@i^{O7;8PS>10QK^64_R{QLS1rUe6moF+iWZIE!1PWSP#$_@GUkAU}?}HghN@*
z>4Y(BiAWR!<CN-PaBhm6@>_cN5;>{UEfUW86IShF*sPMG@KuQ~jBxUkr;n-e+Up31
z^k$^X;_rUw7v9<$nKN-rC&Nah#6)Yo{L|sUDNq^Q-T#)m!A}84U{MVsp7}nDK`29R
zZa(1du4Xc&vMfHYPKMaX;aORsPR`J+6rZ=zKH82)tlDv#_d^RwG<&ffR5sjS?;+gy
zFZCfca054Q1bO0lzkR+wkN7yoI4UPMro@?4(fj;857B#~CP|&f@ALJ7^k^qVntcqY
zNlyn2-~Qb~eA}WH6+c8&rGFVYD^;oZq1=pWe8<~X$=#zq&7c2`U7#Jl0Xme>Uhv>u
z2)f_Ye)=(g&6Wc!fSf8!B_ln~P3$x1F+pvHE)(RROyFun2O@}J%dhU3mnC%`w<<1v
zh0Z3*FW4pbZsWWyV_SAcCAD<syJj_yOOK0OeYWJ9hpm#&VA%{tp<{MM+p<iiyrO*U
z=%uaYt&{P2Z;#5B3W4sKd_wnR&ng{%gtoqAqL>*({#ZtzTuUOy!tsXmkULTneGC&7
z6ka`U+Nw!$VNCM(-?!$w+A_(Nr3pFhBT=V`9Z@g^-_62{H#LNf75GLhHuJvRc1bC;
zoJ0vT$@}FE<wj&y3EU~1oPG*Hp@2Zi!EIWTMyU-)G{mkOgw2XG#mKd>ptBI92(iR?
z-|U{J=AT)<?!capwl2zZaq{r@l-YXfw~ZWL{N?XH-oENQHrW`boWA>_&c<=kC^(Ec
zanvG58{PXSGUNQl;2lX(s9v>V-5VclS~q2cs~<k$;T>FBGeOgW-^1q`?PVy!*H)H{
z&+Qz~%QX06@+iD<R5CuIk@2~Sz${ppGjHW?^G75JlB~XS`k-}sd79|2M|C?lt%)!U
z_@OPA#KW0ZK(1=|f%DP`;UYO1&2s2$J)B9!$z8bHeqK@sZT;Df#{=bdoYH+p$I%oY
z-#~53&Aq!(;*At-pr3cjoCTxhPHs3+p$LzRijY6<<%zGdHJ<({4_u48`=`g=DY11L
z?c-}!gbdH+xZKjnOBb*iZHdZF;n?JSzxkUyG<VPO-i+PdKkR+D>$Z-YaSVo0OJjyX
zyQYxSUM#YMvRtScFLVzCH4{jc>eYl%lNP`j?Qgk6>#q-z!%`V6E6`SojfxpHzH9tA
zd=+KI#TwmPk)h;NN<?f-u-+6YwON%PKkrNsZ8Co6GXDDF*|TpUzc-GNh6+tvR9YQP
zDjK*(ZO8c3s_apY`j=l|t4wfQY;cAvvu^5kd|C0x1ElTm;!i*M2o`QNAAkB7w3f=T
z9GJ8}12MNVplw>{kUk0nW=TklK)|j+&Og-<jgJgc60(kvKLnB^2c{+?;b=h(_e_*~
z=CBWXj4rBm%R&MpBLhR0twZzGYP?*g_^v1wuZ=1w&T!YSQmIx+ouA_p+2x-V)!R8H
z;D#9EO7kD9!ea1I2;FwvOCHLlLL@pnMf`ENXX8Bp09+pQfP9E~@;*NvqJvhE-VkJu
z9taAMPN;~?aA55<h<^3!afITab#%tBanrz5#0`F=GNMF6OGt<CkV?$D?E9+HQ`L?B
zbIZp>C)Q<YlR3vPKb5hU-)0-f9+{PyYVeA3P%&P$r(Muwypu(3c(*jUs&Y*J$~YUD
zgM-36CN^wBaUBZqO#dc9Ir3;;OlGBBbnw_mQz|1;Qe%(LTalHP>lL2b&ZgqOnf9iH
z1$wJe&OPPr?K{cU)n|Rc=z21iOn5(>xiU)9ENPWYkVrI8ITA$>>MG2K>A)8`CRv+<
zrh<Q;Ky+d^Sv^3*?okSbpl{Gt7>KNRKDZl^B;Y?NV@)zR3OG*s^7-K4cRc0!ZvJ~+
zTyU?0+lupH+IPPrOVsH7hr23E>{ZLo8?^6w%JWoyVID2WIOdaXP11biOS1efvw1i#
z9X)F9%<_M1rG1{tA42pYM`b3u{TqX4;v+Edr4Y8y1s@<w3CyKme`{}BfoDX>17#$d
zAIZw3)v6qr9Q8NfeAs0|FOqzCQ}wWePTpQlcwC_^ixNkg|26e}<fH_e09ze=k$r{<
zFw;thJJ`{Pf`Ci9Y27HRhQ3E&t+U7%6EN}^6MW>cge1s1A0&&1EhCdgt(0qZ;DIdX
z^%^&R`8!X*pQnogFTf>lzpqlgf9W~+llvLlQH`$xWusYdzw71s4mRUw>u+De+x~En
zp|$n+GS8tc__LI*6!T?&PbLA+UXKV(qxEPt0MT+E2bN3o1Rn|GS_rggF6rvRdr<IQ
zG+u6l7roZi1x*8b&*}Zq<`)>BGeHBk&^vT@DslS>GSMUZplSW%Ql%A0g!DLBz*G}~
z1*8tgXh+Mbhmc6}WEw~Q#W4azA)aw8j1yp9P%8OHM9ffT7UOU8%h<+k>sp2>RY_x)
zZH!&`z(V}3Oz~_%Dn1omP^g#(u_+Z#G0XQZ-Qt<Um{1gcZ__4-p00~8Ts|(N=-Oh}
zir5BAcz5f#^-U4;jukfC{dW7oRVF9pS11uFwv-h>DD}h<dzLc=lXEk0w7-j<p$H6e
z)^J|_E(SiWtbW7v<M@Fb^AkTH+dzNqmYfmB*wzOly?Kw2;>ki_c-$ZIz9vlNuF0)o
z3J+{_a59<yA;_#Br6&QuCE(!z8cH8W0n7-()xz)w#`7eog+T;ZQ~w3#Tr|RfjPWOj
zh>O^!Oot$r3})#`K<G!4$N0PDmCidQbAG-k7hlUQlDf+67RtfV{W&J#g>BC|*Drmb
zGR4*XUX+<x{A4wt>@ifyY!mQn*Vy?;s@liHn7s{fP7&E$|K`G?3M}`L>sX3Ht+OBJ
z=cNea(yH1X4K>83rfP=3QytO(p0EwpSWv1D$ni_)jNH)`S8fD*0nAt+ZZbWiq7+tB
zs^OfEM#(72Xuu<^Lc`dT#kh&STb3V_hHz#WT{I|aG+-C#OsOHWZZZ}LQbdrF8msga
zgfwc6PA}uNN(4tB>fsJ70J3j)gpPUbgU}v)^Q@zXr^8u%_YFsH5BR-|d_!-4JxeP0
z=(^P~z3>Rc(%x7iSGWWOwUYb8{0y|I#V$QEb@%Z45qLA+9)jG=ccY`2>R)H$Ga+k3
zZ1MI`<m&p52Y7B7eus?VV|pD^Cw!C9J4P9xVM%;cl<e$)_x_lk5$Pfq@14Pk$lzyV
z@>Y@fs^-gGukGA<7e9m^?Sj7){16@2+kj{7=lms3f^Av~Q)n2cbnM0;Emiq6;D<oz
zjNiX&p?TSM^zx|SfbDqo_5ghg&fU%|*pZcr^z%<Jd(7{~8rzs#=Fw=%7^A7Dfb%cR
z-370qa^&A!2gGYNfDHk5qFG|L#=G%U3xnY=0UCx?407^0*a)elAaPm2yHErYg$&@7
zlz}G@vgJC|kB56S;|o(yo?f;Dsn0z!3Ad<JXkUa!Gm3p&ouckpsZz0X)%bh&+D*Ia
zGgGVAj;tR=BDZGLsT|lW_YE5!+;HYR(kw?MBv@;mn**Dz#y_j?PEo_X8eKzg_y;ao
z)Ashc(QC4Sp+nUrg%Cse3(&*BA^_)lY63W!My4Tr3Vu{@`f|LRR1+Z4YvW@GSA(B8
zNsK@LMclLahtv2%8hb3hXS!6%=Ea*G(oo`Q<oe8oUdau-IP+TKMvl9fcq9`ozJVgS
ztusFT`uUk*0h+Lx&wu^F!9ytUhnc$I;Gmg5pg_u#q3_7Ka&?l1KFJK2Lt2?NC+=ey
z1C*qJfq-NBBd)@f6sbi;i_A-b3f%bPi_UfA&+@~M1-@sicsf4{9}dm8Q7Y^fx=4u<
z1%ZI`qEJnAo^6m_r;GG0bRe)Hcj_tA{<(Nh1RT$-24DKAArXP)Jv&zs(UYPIN8RV}
zPH%aDAd7;XeHcC98=doV(lUg8835sIv_3$SD%{V+CvqW&`TI1b6EklK=?5Zj$+<`I
zaHD0QBZ#J}bK~9MLolEdbwm*Zsfah}Oz@#p<Szvm9SxrqrCN^fgu|;J$Ccz`r$kIu
z9xlwUvh{IydQo8`fYIYV@~B=(ms?~Y_{A<q(%H67A?B+MDGgol!T<7583dN5m-~J%
zLYeYVN1KJc5_F2t4F?e}zF<!9qd`+}0)H6~LOmM2GDhjD(ZX@%;0(!XSp+s|H&_Nb
zp)sG<-g)Q(zBzRj;t=z|PU%jhT|c&d7wZrm&D8cpfA%%A`X@9Sug3XJ=b(IILw%W(
z^B;mg73}Y#vqif9C)S?TBDE6uny`NB=E^FFI28wyf|D<px?S3wmh{_+j;$+D%*2*?
z`qGCx8^$epGNlv0P+y?;TR*~ib8TsWqM^F&H`IXLkR$G4T<##BlO@|%bnY3~@FG5p
zamPQn*3R67((P{}AJSgZKMSCLVn83trrMB}m=1^16GTl&8240P0Ip3WTZ~SS`aXz{
z1vN+$CxfqOe!=;OC3Cy*Qv-$mX!s+7|AnQqm&Cn)%8q{yPdD8<1#*cg<jt=z`HX}4
zP2|$cj+#-JGf<K<mw}yDQfZ!?J}E^X<l+6=qabzaRvQAlR263g9cU}R5ayNXv@Mj{
z$Rt^+fjMNLFsah@&mLiEmg@SHW06Uuc>XsHtPM+W!jzI%@e9l3!7d@yE%-(XzWv<O
z&peOpQ{Fs6rdEhdHv?iuP3W?-cX3%z)oQEWk)FBa#b?dQY4PA_nP5U+Nu9Is4xf3C
zX6C3rxQvuY@!m)3qy%&nCRW%MCY`eumsX>@-=c)f2RegYf|Ge3Bi_m0YX^?U2|GOr
zZzlcZ4KZ3`VI;v?zo_GzVk3}7RKH*#5iLF)K|jUAhi;`%LKmsY2e?E$vPYn%%6RWz
zrc5a~lI)K4skWw&#211q+O~&f?0GWevtNI4^7C{0`PaXNoZMR`ReCKk--b!^tPp%K
zgz^NJ7m8o;c8c*<3oK#vIp`4PN=S$~6fW+#2Kq5z9Qg+O5tUS!3l9_L!Z3dlEa4!j
zL1KuO3s6j{RtePwTfIpGlPlsD?N4m@;yQ;PnS)R&gUJAxwKd!@bC{blZQJxSKl{47
zI=Q$<cK+khj&|?%wGqSdztNt;jTatj$3K<Z$a#ggyMsJ;!xQ_zD%=0LDO36fGmLSN
zdz6ixarElO0v}xN<EblJJ%9Gm%A%CvF)7Zv)K}Xd!e1H6Ro>`vjaSFoul6q;mlEpE
zq|&i#u~~!>8+-rk-r8m%kqt>_eS{=V<fEI%En541s4!Xo=6nkN<+W2UzlK~>p4bmG
zr80k2T1;m7S;D-%b67QV_ZxI<8JU=$!(Z5EWjS1VA9*5=53V>SCfe>J=7@{DyPZy$
z-FpM>AyyHP?Ym@MP0&+e0ze0Kzr7R4olb9r8978+2kN()0Kj4Hyecwj;<Al6VL+7i
zBS(Z7>m`%YB1FY~Gm1sF)5=DH0$yq^wvM;XJePx7h4AX;%iCuz5;gDu1zENL{uA5#
zI!EHK7K2XRA{j5#mLQRk2K)rkul|XLph64k9<h80GkIzx5owBnH6J=3@kOAE5C-al
zpsB3oQmrR*UpH6IrJ-tby`L`FP+yT<KhE1Pq|_!MzB(W(f9aXD_>Q_0GuMB$|A`H`
zatC*B1us*S;UC){x={V->WA^T$QU0tqelBy6#QmY{^lBlrtTfz92o4uO1&f9^;4f}
zSr}$8*3~yPeR?_fm9b^{KJv)WH|OvFYHf#?23LBk4CN@`q4rnOl%a+z*d2vWtw_tb
zWP_5&!SD27&s7_eb3p?Gc>&+tMBvXXcn(O2r#|!|$RY69pV<8c7l>2#;1n*9dt?tT
z?3u%^+5?%0o(;bI>6A)kbkM-)x6C3asw}n;sz(z=QWH-M@}Vf6s7Go}lKhtKoH6s(
zr$#|kCEvOXjlxB$aF2?sJW!kG;_8!eZp(x&?2?R*yB6lQeVxoMNyeS4b)09@<f=S%
zWI@v8Y11E0)|UHeYSMDbGmo8(e;_U?e`(VwQ*=|)aBv<#<kU#cn@^!@b}kZ4fL;zJ
zTobXp$MmTOaS{{fjpyK>b-v%j-wL!Fk0Bq3x5hk-f5vlIW_RVp%4GPUjrib06CX;3
zkNIT}6!8w>nZbCZY$bOcY$9tUJK?2$ttLc4tw9XT5E$4ANl+k!s-k8`ku53pQtHYa
z8y`y?Kww(~L7rOWhk#p&|AJefzd)d{;7BuwMrgvW1k8(Yi}^K<O!2^-kdP^nIkJ@-
z_k7vlV<Wc<O&gUR<mR8El0_lD7<pEew>X;$tBZ;<E1qd<7{OE=^b8C1K%?Tabh^xv
z)Ka}W$2mks<|R3MI4G44%3>wHTAbJTbK;&oudaN3;mqci2}c&bynQ>Dl<Ti>vUg5T
zA6qj@W8>-=?i3idGB>gNgV^NS)STSZ>U=%JO#lAeCrkX^Tk_tfCA<xq(9Ga}oxsaO
zqf6`!_OYeeWx1Z}rL$jp8U-*??8(~8^*SY5GR7w(KI`~|E^gfTRlzoHP8GvF<j(&X
zkraoYPfN?&x$*Mxg{yK?QpWBN9Gy73MX_k{$yI(|u9C+dS&9BOva+c<tvo!~*^$u1
z2#G{m%<BnFXtXZ6AiYwiBsc^uP@z=lz{C&OR4Sy!ui)P&%(OYBo-k=-+$`5u*aN3g
z;pQpRzFjhfnSHIsspr{JcBizVY|;<72+cwXXhy=J&@0lc<@h!H4`L?)+Pezl!`R0i
zL0^G?=ncyZo|;C$W@$10SWF}`D+332^`X^|;Lp%)>^M-x>486@;%t0k^{#ieAKU`E
z&5tON{b1jewxel3TH7XmOgoy!I8%+LY2uMSQv={)PwzTunADkix5;2=!uSv@-7;dw
zadQR7ahV1tFM?4fUR?fw;iHmB!zQsE?T^nighv==o@}3rTJA9AGrOy2ez>i+e)Gm}
zW*Q>G4KvRo1@qpdS9fkp!+A5AVyP4xX2L4qjy<RE;C(Y^w(dFj(#_MaWN(@I8_&<1
ziSH)ix2Yb|>&;=QFGO}qq8b*ADZ;HmIX3m5jYqKsT2>6zw21Jg0|6GtMe7h5aAb8{
z&@*8bH;%*0=RPuG{|KC%hNijkyy{7G4sIVDGizeQk_X%8{d3E-Uce&?T2$8%Suku4
zUaoX9A++Qq8oy^;lk7YAgVXZt{Wvc_`)HfAYuB!Q=UUdVVov=q50|=D22I;-?`*>Q
z(hBp<1@%ql-%ZZ;CxGU<uXDF0cKo-nw@5<#^h8$^YW37a+ZlT@6O7Zc{9XJOvjs-p
zQ}64gPRiBz`?n7LY>Wo<cfumnD!YW9Orw!4SnTKGpEb?M%YF6wR)2p@ZW1hmBlCMW
z4{P{V>aPq+D0S&@!x~tChDC6QTJnxw5BwkU^#))Kw}Rv&dn&E-J!dfRt~498<6F*K
z;wTL!e!WDgrJKv7#OBn`&<LqO-N<1j5=VpKmm{k_);$oQi7IXLRX|*fAh}i>6W)8^
zBJ$#L4TdAXJhEtbfKsI$=^eMWz~9mD;cc(u?@68d-W5pRMaHL~MAOpAS`?5csR1z-
zfK4$b+EE?^;Xo9=ZKY9~fCqFRuR8Jztm=DRJg}rQ9K6{03P=BfwQ=4fwJK%6@I{aO
za>QVON{njW_AtDT_E9<QBbbemJ_35Oyil;lLlbFVJx_3*HY+rARvPWGBGO|m8h=e@
znp&Yyr)9!r%i!{a`UC$K{0aK|Pb{V9dFaI=v1H!UQjFeGu!QL`N=EnI<_y%2QNqIh
z3}I(Sv;?>X#Rf3>I7j^b#f$iRXg0L1;+G>wejy(wuMY<40_+!%``ra%nQFoTgfjIM
z(?rsc|3K(Pp?pEch)5y6LiAm)<DVV13E3LGhe|b~G6=~Y6W+V&OYhuDmC8e}$%xZA
zeZR+22kzBCozb9jva=28Jn$i{%=2qn^|p3SDnn>s;I0p$T0_<gW>w^0q<b)<^wo<>
zJ%RpYef4?_{~1&{f>t0qLF<TAuM73s^SzTUE`wILGS~adO=7)1JkS|J>tNIczKS?n
zuMc+x28PnA>RZ=5PwK_?gmBOHp69{y1H4RN3|Q}4u=c05zD`OB2}vOzyyM<0-cv}k
zr1bqtxb7dhXC*d$?}GlhUm!2*w^?7?SW3g+{ngcd>mb%UMZ(;jgkd$BZxLt@fhOfI
zk<)M1>KZLK|B6@O<>ucQ1)7iMG0G7*03V0{0Q42AhX1e7$9RSLSDHMZQIPBe+Mf&h
z{_bTATRAxl?;=Z`lv{!)8tgJ8TbNKl^j(+eX#PfY+ufP?3wjlOH;Z3)cP4puBF;lA
zfZr*J7Z7M-WKBZYo=)a>YNV3cGH8WU&m&H5ZsgmE9Z9a>drr^KJwLN5^zk4#&C9At
zs)X$;-yYro`ole#kfAu({!CGWprLp<VB=Rt3D}s=DBEx_egdDr&dqxt|IxkTee@}+
zKuLfSt32cxfPVUZ_loP_&ou8kJ`c};_a2cU0)GNqqlF(5eljGVvWydzoycFzaRa#)
zbLk#l(=v#KiT6PF%-uk|3BAMn)4i4woeSY+7Jdx&5whJ<;E}=vK+clM9{CqkU}B5|
zt%v**J(T>Tcjo2o(th;zOE10sk#<+!yn%OZHIa)9=RY}o_>;1Iiy~_V-aU-p8<XVD
z%UxXLynE6Z6vfO$QPvRro_Q+s#CHV-rPSHQg_FAm7kp=~7;q1&+1)KT813S{fy(@V
z`@y~uGIlg%2@95OHDC;YR)FdNaz^e-Y@~7e|B#M$y|KD`-Rd{qSk28`{YJr43%Xxe
z@Z^&VxWWZb&3$xMPr<AsM`p1v&U&=)!3jOnCOo)xJiBrH){P`44cEN-%{Nzfzr)3n
z2fE*Z@9$?FJvxg$NWObkv$Mx<-8#N!^@N9rsb0eTiF?POTT*}6UkK}smU<I!T9L>R
zx|I@o=Wn4Ya`r+0xHy0ILHW3z_MY~%keHYdKX3jwlj$y)E%@K=66Z10vjyk%Ho>?7
z1)1*Q7q{*s)j@-gt$8^E-^_dlR0a>}WnO0R_%oU(^)MSjzj%}C7f=sks}MAY{ww?@
z)iqwR);Ru*6*UjkeHu!6jgJQ_s3e{~Er>@z{%Zz9_k0M>_Jos{9)94~3o=n240S!<
ztN8zo2jdg><H4x=2JH8fz}i0Gh0OcG50?l)_|fZo)<Lygxcx@sym?0BMN&6(_Y$&~
zEMWE$i|+k(hy}*(;DMu&`_za&wut(E9fIk;fnjD&`vtg-e87%5u<8=-1}uQ|I%8gL
z>tkS;`S6WjvA*LIW&EGf9tIgNy-dFQt|?D}^6h%#h+e7|b*w%e1@uxuC+&F=bd%Q;
zezYj1g3j1|-TK)9`VtHl&}m;JZ3LY(fqmV0)1s7m`4T*d&wfhqr2gM@t(*6vX>fV}
zldg61UR4Y9;S{a_Kg<6Lb2m!W5M7IQI|KkD7*B`LUqlgs5Mc1_gJgoW!x>_5;b%jg
zY{#lYL)Bw#9mCX}o$4@0%e_;ms<TtYy%k|ovnn{4U0!1o;bjvZVe2UXm=zQd5pF|h
z3DyYkm;7t|lVD*8hjq*rh+=@WwsZ%No=7#Q0Weakf%iGj3w8nESKy}<V=>6}d9hPs
zp)A>A5g_@I30S!Rh~r=DURcj9H6JTWYxT=sJE~~Z;nA<v6*MK}#ROE<7me6Zoe~vq
zlg3or6u+_I<B1bCHxxEjR;45~7{cZ*HilM4dHSkd{d(5Ste6%W6k9xwfAY_8>4#?T
zw2GDq0bx}Oa}9Q(g`*=JQv(bol~KVJNi*?xX~%k&I4BOEUcafWCD2$=Qk>uts7k$X
zHcb_(N(g1Em+?Wdt<nCzFc%t#lkwnz@PESz!5>*%q%$b8wbG(nQv3l<`uq-v1y2xM
z{}(j1RuxPgS7dVa^mVuK3W*(gY+s9WdT>E~{)F0egR8f{+J<9Q4?b4lSF<!Bzh~k9
zh_ww95+ah4{IB}?wuHsasq<5EF21IcmMDEtkpE*EA9wdDttKxAXH{eh>)4M(Rub3y
zIqb=u2DBY3$sqJi$BUrQ0Y*Tv@3)+bB3!Ut5$v$kVyZ&KZ%m{cK0#LY1Xu>o;KgVO
zN^My%JIUbb>F=*{bo7g#yQuwiQ!bkS=VPjHXUC9E51q3*&AjHrXHSnEHEs%G?Cs|c
zFGTB5I!Z(9BaDr{ct(JyHoL97>gLJo=B<0wMkh99fis)XePAEDg!a6dd-UOtzutcw
zMnx;E^B)GAF0rrV3gfg->7aga&=Nr_0XxQES2ydOaMtrD*<tF}*Y5&1s(#&%q6K}h
zyIZ&J*~N>Wd3wo`XR4PpH7)5HIkIc82b|&9@*&*Z@K1}Md1mnv_%tn9(loNG3&uMG
z>tYgK4Qsds#1j+spVyj-f*4b*0yfiA2L&){xCPKrOlD+691%_cmYcrDLVpsf6@4(}
z#ATCL_n+0e_u_?z2cFkz!%WPpYzawhOBq+6;H&ji`gqkGx18bHbLQEn`_5>cq(crz
zk0ZAr-@c<-o!nev)0*27LYnww=bpWe=>a7PDwXM|&sgCA*O%Dv5%_idZnI_lenfd%
z2v~N&dr{zNgsoD3MusG55@`|99S1NfAXE$ABl#@mPfH$tzreg||B^Yers<P6Z<;i%
zWAc{GlRI`9QaWZO>4KAI%t;IoxmEuCxslm#<EX~QmJOTRT3g2~UzSqWkhFApT0<Lb
zry+LWFQxlw+kzy+#Foj(a0volL;5bB=#ilRinlttH2+_6X|ZvrzB|8jLx-<JMQ=iJ
zbxfq*z8Fd13l8G_D~>F*?9W`qxUo~$-OYC3VFMrbDNe{tuI)*%XUTTHZt}~%dH=Qp
zjUtHk{tfpfKgq&3z@RROAv!Y`r4MMyK%aE&#HtI`QmwzGKOrK8K3c_n+50N~<-M-Q
zcQ5^FK}^LHYu|ix(Tx56tSu8%J$%f}wvNRUS7t}rc<16BTkDt3-FXVxhL=r7J8n*|
z%BX(n{bf_b48dvRpK2^D$xZc{%cvq+vr==1O<hos>~2$esCB|aW1A6ksxn|Q)Z4fB
z6D|Sj4O%|scR*x>nCP;OxS^id<_Z6xVwH|1axY9^C_w^@kR6w>V&<-spPspJ<$)qc
zzvmvPYWT%p6O|gHcQq^<v#hmZYI{XWa#pUR&B#MXk1S}M%+21mYw57;?XRp~xU>k|
z(b838vI=G#4`vwN*+0OCN1XHMuFd0<qBB!dGhOT)HZ+Y&2GcR{H*jW}%1@L;!kT#j
z)cd}^uvP|TLSCSPQ_JXmS=`h<pV(s-pV(sqykV&)Z1<*nxtql~*1pd<*4fH2mh-1h
zvH0JExf|R2A<pBRne%YYgNf`tLyTqqNU)twXXym-eQO`Gbi_cw5M8V`fCVNX%o-6#
zH#u?6XMQSKx_f)PA?k_vw~H3eD~k>fiu8&p`utL@&Wla{_YZ5|djjtt-t^FVzu_Yb
zOe<ky+`&+fr6>V+XY8N9#oarmvDvrc$maB<ijuL(^8E7O;`Bk2TwyQGmqkDP(SrZg
z)9zEBJK_iPnS;|k{0VRFeWmwTo5lPtNxNj8NI_DWM64HylWO5hAQKs0yra}2*rhBi
z3X)-UM*%;O2O10{rwu@QFlGTk_O(+-N~8g0NdlElWUCvIWj2dn?s`6IChiTcT{)r9
zyP<9U*rq7GUY#>}%zFIzl67lZI$DaO^<hTG=DgNnMVFVRm%a43@`*1VJN=kpe|~W6
zV)Y_?%>(%zF=owm^eOfq-GyxA9c3x0?3WAbQ0aFW!?Pm1cC4-I{9yW~N*|tEvw2Lp
zTZH+A`F`_8jhD}_TTq)fX415*HGToOa&>G*(bAGxK7Nt$fp%&|WSZXZ`zePCH>e*f
zLyg}p^O+hKoc08-zz;j4X_>~{T~gZ!*W$6~+@@T9>ZDEnyY1-VYTh&8!)5sQ+S;j4
z09C*^O~kKon4fLoFF++^1nLPY<EXC=-6#rRy-XjkwjQyBvjUF+9}GZtTs(+I4o^=z
zwAO3Wvbr4glS?M7yVcgQw|vvaB~zztFY@?m=ZMmR!qPPh7j$&aiuYT&r+)X2g<sBi
zd+t)S{>+1Aos+T;Rwz#|I)wC(?RvcBvAJ_+H8jjk@;W&?yS!mi<H(sawy$WPJbRSg
zM^h(mJ@CK-W75}v`yBX4gAD%x)_n3I{wD}L%l<Lg93d==6GJ&Q|ATHq$0^|~#I^-8
z59|!!^GjHcH3$ZGOtg#`CE~#g2Bv^u`|rEvf6$sA)5MnsVWY2WQ6#xZEY<nB7DQ>7
zS}k0nkKiU!xC!!gEsngdkiV~xn@`any<Q&}RES=~@wo~I9lc?%<|^!ib-JLSLhyEa
zF;{7?r#C$zkOc*$u~!T9L1{f9<lAzc59TT8yA2SJ{}BHJ-TOqjD;d!W!2?_-x>}IQ
zDqR8<6|-0f3na+={$UQ$Sq^zN?JH^VT|R5|gr>j;obBDh6J;os-{U4-IM2h&_Q=YY
zr)FfY4os>^_A@vu)Ub&%=a11Px=PfsV8_(f4d8Ji*CndFx!+t}bTT)0XU^VU#Ri&3
zpGZob(t%fwjwxu4nipnO=Q3eb(?NM}ot1*DNM{Dt-5Kei@-V{r|GE+8gGyVUz)Qxy
zrX-;`1cF;e{FiNFZzhAIsbkU81Df{pY69Gjw-0I|;a!({f0WAk-GaVF+@|S2FcXk(
z@l+5F;8_BsU-J@0VjvBEO&+D=3m%us*Vg1^d1QJ-&&V%x@N*nhvvL=HZ*kYEmX2}5
zV+s>ZafuCud55Nj&t6f{@b@F=&)&^l?U#-nE)RIOwr2eJ<@|zajb}=JZdedm(KJJs
z%jWBrPi&6BZ%s007Il?P&y3FWa&cA~lY@L$n!eIjH!c0>*un#BklZ_V?~V&q1v_-l
zJ^Rk$gFt$qJF9!|a7+35V3Q}hGi9$3@dv7EVGC5O6G{_JkV?W>AYCCS0z~i=MnhJu
zEO|_^4Al>~`HGUV_G$Ra_^Mgs3j9560s=?Qn>4y>(nRHks<`Y(gOk=ZCng~7^T&6d
zS=Jm>pBkMW6y&$8q_s9Lue!0Oc=$&%D{A=UDJ5l}O|2{#WutLeJhHQ9c#{37r1;2u
zJkdMdsENT(PCqq!V!rqI{4%DfwXCSPEF-&WJgOO2wTSSQn%-Zf@ALa<Y_wW|R$)^k
z^aiv~sb&b<vxp$VD&yhK(qhU%MNCKt!Gc5)v>I8UGLG)<BV9@m6(@cF?{B;qmYh}G
z_4xQpfA_q5ed6nf&Nh@z%u6U<a;2yxKz;D$jZeNW8);ip^xGqk?ON%jM}EjKB7azW
z&A84ng;~J{G=8V9`-cnj<6|-!vr1;?s=0q0y!Kk1+u@ce%@rs{j$f{C^U)XQXuWIJ
zUt_;L@Y$ZVY9H6b$N#=!J<sgk7dg&#<bel1-@5fUTH4gTtyb+5nc}aCbRm6Q4TyLO
zVrK+_Mg*33+I&mRg#}0f4ZwAR=&o#NYhP30QM^5&!8J&xkEx&Zn#^@^N8P_tCqYzr
zhxgJ)&YHZ=R61gQm8qCR-F!B_h(~AED)lzeW9z29q7H2=@9j{@*OeEdI<#{3h>k~R
z{(1D+jROqW<e*-97+>Y!1C>E{OOkatJ?sV-`2AovC}8c$;7p{4*#LM#^<7Y@Acy)|
z&1%T(fc8l_{`vefW8F<AyncX#R7Xxuhu|VLgZMZ@a7PHaxN`0juP<NxbV~KQhPqbY
z`c=E?Gtj#i@Za}_*K&zH6Rdrv*zE?xbiro|zcyWTcLqBv{%!5njjvy5U6Yz!gY%4G
zU2DL59@=RFyFnYswpiHJB3ccA8Blj9L}xalXd|p0_7I9<Oby;qmTOjyw0xV7muIvi
z(4KwI<B1~z1MvoJSe87@l%mm~?M@C%Ra|3WAZpRvFweWnd-}>4#x_Ki*}W~mi5t_i
zu0AeMuMc2YJNG)^gh4u&p0Ajy#`qvzH|*14$C5dwOYb+bMt%fDzjJ{-e?T>TQ!GHR
zia0e1Ml`4uslOH~PuQ9;erO*Mv{UH}YyonExP>N>&Ji4HgwY~vEGg?;`P`m`Yo9hB
zV`^}ET4-2kw42G1HJTr?bFa=EmKkPB4GWG=aEk$tNXOXF3N#ws;pIh{E$QJV6rqo)
zn{9||n959DT-SJZRp;^N&C(98Jv7P7Z-jb6k1bbep806%`p6*ffYeZvm+xHXwaiNm
z>NJ%c>3XK3XI>9kpC0e4?fKW#j;$x#+c%K5r{HC>`TQAb8&9U*^;YY1)@yYTe;gJ&
zgjJb7Z<M}v3mbJn^8`l<Kv9gpY`*y$ycjPrUt|2yVzij?tH26;03XB(^g9}fn$Yjx
ztzEbqf1`8=^Qf+h!JmgzCOD6D<avj~%;JMfHeOw{_GpOfb!5kA@nZ8gP|6}w3Mmye
zqu;O`ih2Y)qZ>@iL!;~QSiOS{%P=)ESq<{AQ?jQ#9DQXq^<#FgnJd?082><zBf$55
zEB_Su^wnGFv7ZMH(z~gqC~`f@@-6)hJxdv7yc*Vt)Dl?kroAkPIXeFMtu<vU*UxB7
z&(Z{C6?w^1Lu11u6AESyFVuzPrl&7>W_SB$|G<po_{gMLaX!_l56?U6iI4k3;MM2_
zvx{<jytY+2hlfQLr)V|ozxQlj*)k?3z9BazxzN{Ju5bto5AY2ydgb_zg18jl<VV)8
z#GkCGDyh{6`ljw_nUpktThmL=t)CTo34c*pgr+`OThXIm*4yPhq7IJq34@hD=yT9H
zx#KV{gTPKK%oGLf3z{qNkO3;EWh_!oLu7rNPMqeFO}wx$Cuo_lUqK$r9Y4O|EvF<W
zr%;V+Z9steses@rU0_L608@2!`QhTb$>|vX;TyI}@2i{86{*3SuDCeAuVgR1Jf@OC
zxT#cO4}&#OQ_8-V9~h)79d+UJ<lz@i)#kplJ-JTd7HGcPkb#~L%I%3N(Cc&9+ab^#
z@Q63z1N<@YjrWGxVg%i}3)~(?C|%pPFna0^U=o&~V;Q|l?jnORs&ml@rx8fO-Hrzv
zC4$HpKokn_6F;_m&7a}VPEb{<bO$@jj^b~!e_A{jXgL}F7ZpGM$mR`)N7Uk9@gWF|
z*@PO+YY#q$s@Ag(TPH@u<s@xK?#|3U-1EX~@l74_pzr{%S9WE*`pg}8cr~7l&%KKx
z@}I_2@T_MGc5b`K%r~zvui#!Oz#qPYoA*ACR-yHG&&Hj0aK#wf2yt+Ff0S+KcS>f7
zlnWifkm)3q<v@_2Hj|1|ZwJCo>1jPghn9igDX~!yRyL5v!7EUqgWi>KR7In-tBj$U
zEW<)a$U6?ENswoI)2!a{`RdBgy>6TsK5ma|sBdbzF=tLg#oVcxZ8e_hDXo9UdpEVr
zm@q7Q7*XY#iwgJ69KJTD{R5Ofb=#dk@jthY(;ITin|s`Roo3ECGd8Da%7e%aNxJtO
ztIw3B#UX}E9oI51wRLqC{#Uvdg~;*ovBO88@PYuX)Gx%}dDF5bo%vC<%kj157uL_j
z|4c1dT{<-<D#O#+MG>B=^I2Srf+l~6+V|>5jel}pS58<&-b<*YdDz*ml`#pUS1y0L
zeN33290m~)Prwf}y?6K;eg?!R2M<4;EJz+}vJ895-~oAhI%_1%oj6)j<$>56Neay>
zViq(&I)ij`h0WB0#t2Sj@PvvOS^1jJ_aUFaG^c5<zV)H?ZGj7ORG-aHR5*TCoSd4G
zl9FMJDwU4PnIp}4Yi&p4c(-SsE-NeSm5lYYv9-_fj{kCAMdDV~%SjuKJW-GI?qNo^
z+_ch&N9&i50L9CHeT>i1Eq;*!rA#3@8Eq;oN{NZd8CjiQqSEN|<Kjoj3R>1(F{QNC
zcBQ2ibsU?S_r$t&D-ziFiiLG!@hkt2w(kIF>RKP?+?$)51jr@<!U{<UVQ-MV5kyoJ
zQB*)daUt$K>cVYZ&stkYYpb@}<+F~quftl~+Sb}y>#N<bd%w1CR3X>@ch0?8EV1wR
zuN4Up?)QD?+v}8=z}yiTf)5KoCq%=<MIL0whY7JLOa%3y6Pz(85JSm8(t%E~V6q6R
zK~M}4;Bi5^mIR?hJunN5++#{9x2zygTap!Se>gmIur<)HBr}{^`}+2$ppBz>yzxWs
z#=!hr+<%fYceKVmlUs^%c5;6tl%jh3)%P{(cQsb49E@jmnO2E)MMOF13av82GOXzt
z?wefuJ9PW&#iO2ndU)ogdkO{(;+W)2d%}8jT*cbI6g?7I)R|Zo8Cir?2cGr6DV6}v
z1(1CO4#30H<Zf6iK4-rO$VtLjP-@p{RC4-w${%EmpY_91ropG~8Z$M9L6fe~MTp&G
z$*}sEd-5K>CwWoR-{L(6O;1BJW>wj2S^Jd0l!mJ8F)M}#w0{>8?_Xs9<DLic_z5_!
z1ANYhhQPpz_Qcw8jF@2xDYNX_W42gPA;ZE*lxvt2nl)#R9ujRhx;iW{mMUi1VyY(a
zQSPc$%Furi+Bmr@oQR7JQ^vH2!4?$XqL_o?Qm}~iUM*fz@u@p4T?%$Ltu$Z;20t2Z
z2;$WOOmYBOoTFjHH-)jAbPH%1P!|j^f&%eELWF_$N}+C;Vx`SACNlOAz~N;MCZ>)!
zII0>|=1=@LBsXDjblwDgfJCNOR9AZpkWQW28pOSrU{Qvk!SRaFkLT2{dpIjV;o}op
zJ28aO_;V#WUnA39HUCOhhdt?c-($GFd(eZv27~YZfjMIPZ)#sWG<qdb<gHVLJ_RIm
z4UdLr@6rWC$?wzY<Y7e<pItm=ka57Wl-8P>{ZE9_>QyD2Mnm~TvGQp9zhk(+61|Z^
zMMx?bJJ``#ppAJhAr2tlJmfy5?H~@m(!fZnFyQ|JJuNur4ICo0Kj5fS&?h*s#5qo^
zc)@mIZ<!A@1?8jHNh$^!xc}$}&Q<BTL-K$CC3p1xgTX-$-Y=4DLz-wM%0YQ@6AJK2
zkykO&tv4S$yZniX`Kq8$^P@YfX2wQMA33rvBd4)$(b{Rb%Fu9~uRQbZinPq-Q>RYJ
zE2at=rbsL?Q0F>-4>MD@>@%xTp-5DSs;T`xQVl9H+cT+)VMSD|J;zt3MlUWsG;(AZ
z3Jc4wTi;xnmlW@>RtM*o*3GXPSX&#;eIA;eb~Y+*;N%#8e?wU%)-^P~SK0d^xK}w6
zxDJ9<x5^dqp+V#z!R4q~5qj~JDI=7)h?Nq4?6&JfEI0!W6<I=ZKjEPCurz>p>zENC
z31akqD7N#81a1KvAr%1$i^EW6K&d=iS?k02u;FX(D@fOLzFgXQS1KAM6EU(a^z`_A
z&8+(_npvNv<I@TX(i@lhu;zD<7o>)D=H#i;W6q_Dz26)f&FzmFDhu+Luk;pWKNp*#
z$_=4Up;m5ZAyP|xsCT?2N>t1+#gs;(vS)^fMT7DW;%`E8IrXAa<_A&b3-?Z>*%0pX
zfJSa(V<z`l2ul}bJo(e9NMooyMGhINA~-Chm8ht<Ld>=kr~uQK@=B%(rK6ZnfIr9l
zS^gxogWFP0I_l0i@vYlX=T4cA^6!Hbc;19!o&()B0H^?ysaWD@M+c1C^foTpYml4v
zVqp}{sok099!lZ{%ELpI4|7-b0X791+^Ne7s=2y)PPuy9ab$GqCGN}<Xo~didrO<f
z!QzC~9g8i|=%jr`qD3A?U8MF7kh5gmIwO=Tq^7#Gj=hk}r%(AS>+yFT{`o(^E`@`K
z9!)y!X|N^W+aX*L!)iDkhUjn(7&ab)e}R<+GJ)|mQ7G9WW|Ku9XE272D<<lvo!ryS
z-ae{8o5&;zre8AIwa9PnSDA8OKZC7v>=;Qjo&3UoxuEB1b=J@&=vi)x+3GDi_k!7y
z6p1oT7N3rs_Ia_fd9+_ebSO8s^NV?<&{hiM1fRQ##<6`NwiqJbFz_BGFQM3Sfavky
zVttm5NE17@9YpE?dKSRPA43q`%>8j;QT;4jQXaB9E9Yob{OG*wS;dhNAy8V57=cc5
zl4vc(ytFg7P@1Np?v2*k|3DqlTJE8zK9`>VZ(9CLQctc5ufI8S?39G?e9N$Wojzq?
z8JZoe(x8u$QZ}H_AXtE53{t7MtEyix4!C|k2l@eUc7n!ze8h_;P?J0##9zrF(4vzC
zK>_>`v@&nmfXYefuo;J$lg~XI;CpfQ!qcZ0&VIwnJ)EDYvT78O?;FN#lUBZU=9_QM
zzF8^VHqP*Vq(Wm=p?vN|dEjm;eD|65ty|mA?6!ZhI}+u$6-wB)?VqZ)to~@*s#V)Q
zTD?X6$@Vr@QrL#!y!8&inMdG+1xk1xiWpYxiSU%iJdh5Ql_RXsfT$1~@Mc%YNgA0s
z?qI!n_M30cyyXT~Vm=yUeS=5hqHh2iL*MESlIl|)B$OYC!4?nzR046M9lG@!cT#ka
zX~uIb4ljc6fXSI8g;)!qgo;)KB$A0520p<Y0pPNp1O^O62cJFiug4o>3ggo&Wnt1e
zm5a+WGRo#7Q|FH45bKPFguv3tOY+kPRzI+D<`Qk7VbijM&uw{N`k1@_I(hm-KW<o3
zAHAx+rLw+x+_;Ho2l`@*vL(_w(r@0xniY?<%o{$oJuOC_opE2&sK(Zl>n4wikC+Fg
zI?NX-x4xrJ(|^Ss!A6E3)zh1tr%#Ltb(*`nYf`YBN`*<pwPhtXU4x!_?3+#b_br}1
zv~g%<J7*oK^+Eja1A35Id+5w_&c|9&&x7{FVeqtnE?ork^>8N=9ISJw{=Toe&eV6A
zr>Ca6#_7>(c#d8eqNkMCJ%{K;QSS5e_BB+c`~19p0?f{1pBZr306H}WxG~Eep9rhb
zkplrsiyi57+!G3_2@4E{Ivw0&M~Xd70~xLjE54jn@nC#tC>IbEWKD@m|C=>;!{f1N
z(&Tv~M$DUx=KJLZG}u2IoR(UJ{~AB}h`=7aYD7(W`7~p)L5~-KP^(2u=E4z+7K~Vw
z)$vM>Tud>!X+wsk!Qala)Ji*e7;vVhTmNLu%mFXh-s@h^CsK{8r!ILRUKw^|L8kaH
zT7j$2&L~=l|D5kg*Qi1GFv=v3CTy+F;~ij!bXxGnED}fSSo7NQ;~hs29V?8AdtW&;
zJue{8I&AvNA=T-TL!(lgO7jLjFeIuZYWPd<a3Ad$KX<~A#0cAf)YJiugDUpTtr)#>
z_hWMp%{%b#uee*ACl4#AXkNb0+aRxB@&4qJA#J;n=o=(Daxi_Yq$vJXQNxO9nKjL?
zJhJm{b431M=Nh7mtA<4ehdq4ZRBKXbXq>{lZRNaq@uPMR{e2gA{rI!l<r{~!h8Poa
zLp2($CD$6VrusRgK$#EC7#USP?#R*w1!D@Tk?%c{ahYcpKb(->eAk*2^&?^f{DU>>
zQJBV)pr-OV)M69i1qCY!AfP6GED?1_sZ|Z!fMaJUmEeUbu+0kg!{NIyUWe9q?uW+@
zR!n$$Q{vuTwZqebm)%>nr1a`3zrvTQB^F!O+YL()jmAzvv$%EtxQv4T{<oV4UurB<
zo+>EK8o?bMb>u*B#_(!XTHkb6UThK<&wc*PZ=Zob1p9|XjiO~<!Hyl*B#oIIh9}Vh
z8abF%3@e!sNyP{0Cu&rM+kK4_KS$nk<jNph{%6a$n}-jfL0?@%ey`TO@%d<KeYldl
zuE;%yyp0BH(Ub*G97B??P!;!&53l_G?{|RbDA<+w8|;6*;1vd*u25ql{Du`EG1^#x
z<K-V%6Q<)qU|h4OWy^=I+B2)X%GWzc9bVFK_{=NC?c6`}@-{6WJ$+oxT}S3k+=#Ls
z%x}ppm>CoAs|sPZ4Q}67QnY5%$fOCycO!EKcYq$+3eSJ))=$h|m<M6U#{{11`5KQN
zo+v0^j4WnkAOvP>U{@jvcnpp(Klwgua>=pS!O?sY6u*s6apSrY^Ou~$33*lfw2PA?
zt22@oH*TIa!x-w5ms2~WdCk$*DTuj$;nFx|xFx%4;9OB?z+=mYwJq5B{VN;pfBv2i
z7cSlW{*Ky--0C!2h%UIeG(xnidFaTx{6+P;mU)p`!zyaVuUxTYYgr*u>Z22@(jMIR
zbm!0!JCe=0w%CdV=W}wGpJ*AnYsJ24i_e^2-C}NCy}4mpcB#G7Pc9SXV?9iJ&As&l
zJCivGyH}=>$PJJYZuxMN{&b*&14}bVEx!1JXbhkXWDM~~S4OR?E`Y`q{&3Z#C4;<!
zoHQvbrLi-Y-`C9DJ^kpT>qbwFjxC$hJ~=3~^oM;-xdrbcIhxfn5~)jSO1PKfl%-Tw
zec7P&j5Kre_uT5I>xZ`tPOwI0q@-kImQ36?yQHq<+#cPyVKqyxA&oA}U`$m<49JR9
z#$~3O{1g1fG3#HruX#w@+I0hyQZMdXl3Bvuzv%uCQU{E`^z?Vi<ZSz0@$rh(hZ_}|
z`CHY@_I2EaQB^I2XN4H!vqQ8ReN;q5?5ZKp?+E^jezXk&%CpCHQE7#5mTqRWlY@t)
z>$iaC1o95Hfb89a?79uXjW$9DAq?+ht}>~T!3S|H*5geY`35ndqQ7>$n$}xe5t_#@
z*@Lzs^bEgV5B(cDh$tDX*F(R$br5xYhC7G=mP5CGl<fumzJTX+puDr&1{XVlgHamn
zLczx;oGz3y#fTE(0WZ9%Ne~7>Hb|+P{4{Y)h$e$<7cvul4-x~?OOXs~n#K!v)XVmo
zvIasW<Kf`6C3Sg0_SKa!5lFKZm2sOm>*ztjxjC?A#`@Jv6#Ox_^9EP)Ok`Lr`e|j@
zTR;BR5tlf0-OkO@poC-F%L-?#y}$kJfkQ`TEru;NqRZEE5A6+C1pDrPu_DG0pZgBl
zgC@0F4a_oa;_ziVrrM)gLf16bskkSq3Wxm%Ej@##{$h_`KP`G_No-2f?`ZxhH2*~|
zgS*Imx+p*%i@rrKwbj1<?)7hnWn_Q#!Je=@@y3OF|C=1Jto78X{o{t#jen54$_2a$
zr12>^J3Bz{t%n@9@3}>T?#)NJR4WRGax$;mazM8QK@Gv7+kmi`R3HLg#IeVoN>aL2
zpeuX|-^F&7&Z&WhJ*|4h^oc8t0a^p{NAg!LA;kI&esIaKsq2@g*NykiV<nqW)^zhw
zX2ynz8N-bR6>5L>^ksyYx4&z>`Q769F)DQy^)cqdI;b<oGZXpyE!YUFyLU`lroekg
zpyq%haE2UPb>5vP+L)XqR)RXXc#^;m>XC^b9aO>n>*=uVM!%{Ay&`aMV5|MqQlz~(
zd|Z6GMDfJdion7+t-QWG7fnWz<xfX^N<UMcRG-fM^`4+rg;CZ~wW%sesjhrjP#yYe
zS6d_Z<KV-gbViDG{G6cF{QIu1FRO}AUa9s;@EO@SD4Dy4DkhEEWKOf@KZ|u0nK>7A
z0!~n|u|PVFkN=3(fR-N!1~KSZ`vQsa${RlwZo(FIN?T>BPPIv<PRLNuEhD+y7lti1
zsdRx%&X?%5iQ#&&flb=1l1`RcRX%=E3A8yoV!$I6k;zPMcGQf{7vWq9Js+dT^3O(E
zt5yRh8(Rhvf(jsnv*El{@i0Jsh928uF;*t1hpM?GlS~_*u0UsDi-g~a;d1~0gDCTx
zvn`_Obx6nU=AL=^<0B&g0)1ox-H4*IAFPN>A-gg0Sw1E@4bKh&KwQs;+EN#kMW-iQ
z!Yi$Qa{CuA48<r0)0tmU(<kFc7`XemlYjeoLG@sIC_yik&c!@C@z(cr9<u{xmLZ5G
zC0*j5LS++F1TZeI102eq@CCFXVe<^heL8P?$vrdj?i;H8^82;PFN=bs9`|NN>X_Hw
z-K~8pKyN)N3ljZaJpOQQW5;1l0QbqVhE?cSnJn~05u@=-`Eg518fPhrFg^?OKG+sz
zd1+WHlSB3`<zr|-F@bggf55e36^aU&Rr!MkGYg=AK&4>?hWRwY2>WP&Z=qHNs~W7U
z$`6NJf0z4``{L@SpT37e-Z^o0#EXYbwsjL%a7*LPmnS6`2gD{8Pq=)Xo4^g&pP8`_
zUA+3>tD>sqS>d{dG2AyVoH_LZTu2r8!l@~(XLFZtjFS53Qwr=Kj;%JYPbw*_4r(ag
zHuyX4W@GdC2JYV_uqgxb$0?A@Yo}j>?LVWvHh67z%c9db2IWJ6q;wdNw>q}vVVE&u
zB$o#v4NZarKKo8)D~L<v3?kqhU<?z75B=$91yVS&gRoY}yM6JInv$mPuQ!y9&U<KI
z!SCEJ0qN?BY3*xECcO0cxT+~(#}4LRM45qU>Omb3FMg<|ETCx!x3^@@_UN1`8zB)W
zHyY)rOpzuV(zzv1lbm+%IV0;me|(UCZmxgO`1vB)$+8IUN=V5(rCubxo32HF?70U)
zQjYegQ4;r^G>$4_M1{jqI+_&5(iG(T;9JsveI_B_C_+QHTU-<D8H68WiVW)K4rtPG
zwv`$}Yr?}jUyooBqWt$Hri$2L?s;R-IBsJ-ENXd4A?0&_VrdX{&R3=r71^(#<=iSb
z5;&8)Zhg)CPTvQWoE)+f67zaAR)APtxV#$^-(trrL6B=~{)il?L8aiHAE<udG!ssh
zVYQCm5A26v`3QdpMmqC*NdhMh*A?lfWQ|EQCH<!*SP?lXIx?;>Hnt?{-s73(fN=4H
z@6ivMk_O2->#K*v=Fn%OzJqJSMDe<i1Y?^0%lwUciz*^7z{i&^Nhli@H>It7Nt9+l
z?YidK_y59aw*(Cf2#z#vYpCC|YEXO-D?@?FCht6ny<z68c`IXbzP`Jpc775y{3Q2&
ze1pC?2NojHULSC!%vbaaq`sX=WDDXq_#-$1xKtW}k#(R8#TxMa2?GMN;nf~k=3&!l
zI`ft9<tYU|ltg_fCfM-FuEozkP_EGi=`8fUXdoH{+N{E4|GeSRL$e1}{rY}Fe0;zh
zM6Z;pxZi)=ab)nl+<(o+*y-ryohRxlMuvn$Sr`^Aw!crQZ@xM^z#ciNrEQ26)r47K
zY#GCi>+*L)o+pw-*Klh1G;p?u&tPMZgXmyfD{$}oWK&H#i(8pZbhpX6vi0so>B)gj
zHj{lrIP`TIG*t=VBLA>KW7F*CUsJ1I(a@h-ENiO@+d9pqN{OSCR-u+#EvDHOVPV!{
zTq-kX(jVmuu#rC1eBdYu_T2kac@Qx<Nus?Am_TSS6`;egOF(*72^+C)O{pFwLPvwD
zzc%+)swPN8g=hvj`c!Mh-absSk(pr{FxVR6SK(|<y{dyIRjbgCnx|Ds<*`Zw=|FWf
zsWu_LN40xfs^}40R%cXMByLYFBl3gK0q0*M;C970uQcEwNB$M&5U{z0?Gs>t@gI{>
z>dL{=R@f8)i9s@=;+BR*E4Y>6qMT4sxX2c$_V!NN(7KNMCz{Fa5R$RlAlp<)-GH#H
zVN1E`+_vXY8+Sm$z9i&hsp-^AAB%~*5Se5#PfUumKWcxBWM!#KWg#8km&Q}Wsgdx-
zmwly}kKisI=yM4rb55iW0$WZj!B~-k0E2>r3m!nWVX+orC~^{M$zgEYZRpXbxXVAD
zOVNc|167)LKfAeU)%tDRjYm(Q^nwCzeW3Ny-uWo!)Z^4%?u~Ponhi>QNMMxrlB4(E
zLf!|CmT<cY3ao+XgNiuQCA?M;U`e}mmF@sqLWU4{2FhK|d0o1rprDg0D4>f1t-68&
z(GmP!{yo5O9Wcj0-ov{caElGNJAQPBHL&w<@E)q5pdir7zl*%5^wxJG3%mz%c6@D(
zTq=(B7Ib65J5@+0ve*npEw_=|pfwt7-squ%0(8hbD$p8A4YvOkFxIH3oz%dB0{a<z
ztIA7s>v6DVvjBD@_zT&<_t;8<Cb5xWP8<&qj{%r~r!MxxSS6{0<46(yKz9k~cC1Yx
z*MPZP3$IwR*;A9o%u<zJ|AKqX{-BPIl&9tEFG+0D0v&BoQsaKV=b^#e&m)G_ZGL{`
z(r5+uZ?1Ep>LY3#n!8%hRevOsUXllY<V}Ahqico^;x0aa!IzbprSx?AVuYVfLcuF#
z=%O_oik>jz^|!ycxv1#Co;S)ipvglz{wrnjsHv^!vQir!)tOctturX)A}KgTBCkEL
zn{5+wfpi58!ke(5<coEr75@cNf|Atpc>&;mpsXd$52`9c`U1#7<FQhRiFA5QcfQig
z>(X>M2I#QSl5eCjn~+b%hy|yb?%w_M^x0^PePNx!5M@yex0=z?Sj2U(p{p_(g|9wh
z<snu)_~GJF-qNWFb5{(CwwRW;PocRRd;a>YIWY~T%9hkmoi(dr;t38lmCu`h#%yD#
z2ot5GBE%he#@Lz{{o{j0!K^w^69lbj%wToEz)~Cfed^uAk3Tr_@EWy}YR%?;dHC<S
zx#PB+xrFr`&_HwyY=@E8!8ngiJWqb<J>Um7kMou=jJU$k`5@R5HVj9X4je_tqzAZ#
zZ>`yJ6_!RW8as>oV-xpNKw|Px6tYWglgq6$w@)2s4NNLYr^@X1y>;W?$;imO;Ol*1
zLhGwY^3Y!rvuFG*KfI-)KEG(TJX((a$Q!1W=L|oAQZr{SIrvf4@Yco0Pr#WigkAFY
zFh4^7UIx@NpqaychzGVl2sY2*+hP?AXG2s0;YPR96SA{lUFZ}m&#MA9nlyUoyvn@M
z^9JXQDx;=w6Nfj+AJYd6e$EoHc)<dA<@<Pm-(Tuv{=Pcvj+n5x^1*QfYu1Q@9+R%5
zLmrnfwUx7K@&?Zu+3}E=<(^H*7#9|SuICMieSEORGH=@CgaP%TCeBivWqUSwKp=f1
zG`b|Nyx9JBwNb4tt>hvC)kBO5<-lR+Ly&GS=2jb5M$aWU=fIrPNIdE6jy3r6F3$!q
z#i;18-V=y`nOZRYBsT-QyLvz!Bp75ig(R#o*VA+74$dDvw=%!3o;exzz?P%614oa`
zk1s5c%W8`U_&p(y8&*>lFAw(hv(hQE=5Lx^H(e7S7FSjkH?V#St9&A8_;u4s+TIdj
zOiW-+A<W3ZZ8dq7vuo|uYJKOqU84qD;)djp&55sq3Ffi}I;PNCnvqf-l<se4CGE9i
zlX56=7^X{+{e`iXKx2GG=X)#biVx7aiq33fg3%bD2?>B0=V2hwHPC|=(({bD*91FH
z9eN%TpI8TjDS%dDJhhCqJ|2sNJ>i%_%(aVKx$mo}a8QE#0<GLuqR;<YP|$>Y*PmZ?
zXu?~QM_iqHgnIR6V=>X!^d|fMf&%JLp!LIof)De?{B$_WZ2u$*7ouse(YM}bRzp1~
z12RQJiT1>l$HyTk6b;Fr_&K)P1C_}i5GW`SlA;k|RAFvYhu7EvYx3fUp<NxN9n>&v
zNXel2wXx<Onm)>DS-PQiSLMvPIWa|}LQ4y`FREK2N}%`5JAU-gGwUbLJQ$xbY2W4-
zH;*yKy_|VbACg;X4G|TU=Y>{H82#Fdi|QuS6hqVo8*`D@p!=SS9LaAJO$eWTPyCF^
z$5zzMJFsKNpz3pN)lJJ@<gV0aRN0I69>2b#JiW3i$4l(haO)B?ow-PMMm9h%%`DR0
zz^A*dB)sGGXu27TAlPBS59J+eKW#L>L<4vg&;}}D<gq3tM8Hf;yPD9_*a$0bI!j|B
zXz;IC8s0_2xEp*4M~YZ!^S_pvz9M8o#RI>p|GptBJ(&Aq`NVyYK&VZL&x=%Ks%z*6
zc7-hs^Bbg1mnTMrh0}wxMl6_rcVffO&(1Y#sEd0j$&ObPp&N@Txsxh`uWxaMAvL=E
zE$+R~{jDfXRaTjpA`Z0_ZlJPvjEk<AHLmE@jOD|*Hwtq%P1})odd}e7!1nP&0@W&g
zbR^t)k{P*YPf$q3BR`0#ysURC225J|>(C`l&=GlPY5slD@w&lD>&MA2zZ#rdc5E}!
z%eV;)x;N|5w)lx}+Mi85;LU8FSC#@EKDJdU-23c5;2y{<=vEu=)eKy(B}fzY#?%9P
z2#Frv`yo^WO7_%IL*qROz;*aa5IB_H;!khH{^L%1X-@Ft#cTSEE4fj7?(x2(CK{$1
z??~v}*=xjzVjQs`u4Ue$&p<2)2A+X(HUxmAm!^*#Ed)k<!wh|<^O4xzf?gEs2zude
zPd-3Jg%F^k`4FI@JhuSVo{Ixid}c|oM=_2%1W{=T^jty@HuPNbtV(<gs}3g!UEB@|
zsn6HAV1gMQ&wLWY>-L#A&iBOf8FQCSYn{4s((*?YyXF*xn2QR{AuVOi6NU~AHW%kb
zgw|)zYpHGsizv>wgjCL-QapHAK37_3^;6{!;fCRV(?&0zEm^W*;o?<`XQPpOXIEsD
z7N(c&-%wGtaZ6>!z{0eWbw^5Twyv+pC@x4VZQnE+4Q!cPKVtHjrf5@iYt77-NwMab
z=>x}uE?mJ~6+aHMC<f4mPzMH265A+Zj=SCm2!SZ>J9IYKiQVtdgf}``Sb&+ukN0+U
zV8{18-?K?G?iZx@dcokJ9&Y2L8Mr)s8M!=twF;jn#%TrMWQGpPAzqEx^X4rpb{5_2
zuIK%Jmj0thRx!fa!gdWlauKiS^D4m3fc_wz+usWVjkhC0$3D+11)&!mXd=BAXrciB
zu^e^>Pv)s2D1JCHD46w0fIh$Jarnsd_TTh0>Ami^w{{-tnHZg8d;Yp7XV8=Q>w~*o
z{%Wu5i6*L^zUa;^H(&35XDlxhn12R<4@We(!!K~-oz(u^v)VUBJ%}b=(cdds`^QXo
zaB(ZTc{?(Jo){>|)BupD8Q7}*X`1x!w%jiIr2o_zdb?Y8X{o!WxdS@U=yvz>QaK))
z2>Y5?7tID<$_BgABIE!ZTIf#is=X6-ntf;2+IB|tNBH`C`7L_lwj70NgL#UlO%twr
zll;h^rp=#Xt2?FAxI1I6{?dy&b%&fq?$`y|*@3Sryw?1Ww1dFZ&31$2VUN{u5PXQ*
zFLfurLvmhq7esq*e-&VVsVe&2O&aZ6@8l+H5!_>qd6TEFFn<74aS-KBCASNOZ*wj7
z|3=5uUhmZYbA(&a$4%TWU(4i`4-@NTQ-p(ka43oW3L&?H;~3$d>pM_n8qZ)9Mpjnz
zbtQKHjAKDh7iZ61)9vDHbmVq=?B+m^yR}95UUKj~?J&Qe2zC;B{IKuo@UnWNM;G?M
z5#yibG%}Md#2q@EI_aBU|L_pO#5*$@w6dRc6#d{XiD&zHg?gvPgSNznC4N00s|?4U
zy~_{5O?&Q9+U@*V51mI6Z6sEM+=a(A<l+@QT|?eKHfy|-%gX<AJ67v7^?IE-`1f$v
zJmEV7bY?Vp&BXnrebJ^X$2oZPjy+sH%ZyVx{UV$vzx7+?)8ThON+#2t+wMT`a|3##
zFyoYKOy5afbG+`lGy48768%4s_)bMS{!bISzhZ6wxi=~UNxjBlK8F060XjEI;NC;9
zD1Gs9pZSXaO~g0#mcpQRx+~2)5prf(fR_8u*oPZWj~t0uq$u7XUkodM#M)Xnj_pg%
zDTpUNX7)im5d<}0=Zv3YbgYkz47H~}4nA)8$V2|#TI!9^ywS0pUu$G~)Fr<{`YWmZ
zu;0;2`s_V&LL_Am4K$89Ig+u19vNzXStPf@R3_D`Wp`<$QuVszQY%_xD)mY7-R!Nb
zl1#!a^k!9<C@f4BPA<!<>G;&(7c542Sb@KT<PY-9!u~&%+=^#~G&J}gLJvSXOxfYv
zXheUMMRr;MAdSWa5dDc8K-?0kVknyKo9Mea$uQ7cr}Lh|R4Jvs!#M)O9?Vbx_y9GO
zd4p9D;}pa0yJ`XMasMZf_kk2!T^4!cjV?%uGn`0CC-#Dr{qX;cD>*q&?14d{$Nj2A
z2l(T?royZnX}N*`qt`J$NQ{T$>q;>bks&y>+uWN(=a_rr(xJh4q+D<C-t4V8TNcM{
zvN?|vpIm7yU0pXsz3qu<Q@f78iOvpyc?^UIkD2*$iokrq4CcNJBbUYf!u`{2{*B<m
zJO{X#y5It!_5`VGLJvb4JmURTvnzUqMi{|!du#)~BNBMuMMK~vW0y3XP^lsD8(a_I
z>}BghHV<)3m*_l*6{#;?6+6<z4-;Zg@erXqsM*xhwo>n85LE3MC;MlpWb%M<c$N?o
zvpe`?Y7iDIcYGS8H48F)>#A%f(61P4_5Tx0`j7?L%(A%7L?=hw9!W;wM6wqt`IET!
ztQT%w^|>g}0>-=ke^a9mLit=Qi@R|R2*s=B+Y^eNayvrZPMzEt?{ueMZ@R|IOCkcA
zLR<j!#G_uRDWHdmbL!V!a9m2p-9DtHL&?o4NAPCkep#|((k)#gTJc@mz`M8?xo<R4
zrnriR&hMNgl*)(F(@JB}LY_`wJ=${{vrrMYJG{U+dgc$y2Hu5yK3Cbo<A!Ys{NzF{
z_bWPR$~V>le=%t?^aVE|NE;pC=cblI)j?v1Q3TtfHq@ezDO0kqnA{`Fq{_LuXmEgE
zw7(y|7CDz%&dsxLO7&&=zG=`Ku!p7)>RUb11=n=?hcxr(UEjJRJ+I*X^P@3d#zMgB
znaA${uhsoVfcP8aT<e{3;(4(BM<6Mg#Kfdav4`V_Qw61QwAt-kohXJEgw^$iV%Qj&
zMk~R7jbaD|cE@q@yuR#qrv1YmJRc8}<fck_e@IpjXIk&I=>I!a`cNLS`m(s2RsS==
z=yz|YQhJh&|Ba5_)e5n-P(WM;bj6c#uFd5_>$c0U6>8D^{s+-A*G_WJedIF7?s4bd
zaZzNLbK$ruwBtIzS{%$gZ|6n73;mJM4}<#yNJH>#cfbp`r1odmyRLtW-2oorb2Brc
z&rpY_J@Do#8}i&b15G+K^lS>3)Ikn_(1V$I^hvJMo=_~Fu9M01k5HEp`^4c_T2_Aj
zcB)*fRiwQ0`LY?*ZtjnBZ{|>;@(7XHEH{dBufE3p3z@f{f_vvWuETY6M|TP5A$}fU
zfUUZMjl@YUXcNF0YqA6gFMR_IpyP!an)#vM(Y4k@IH+{-^Mhiz6A^<d^ZX+zE?BP9
zsW>zB#yftRD;LE+gS{J3O{@|fM~}mXl5tWCz6D&OIssfKQ>BXLc9_i3q6-~=-@@zU
zE%XmMWf=6p=SFp$5REYBQZ_|M$0va*?C8LLK>(a%TA}w1dx}Cf4^p8z4G*b_U;wTg
z-kk_kOGmSc65<MrViStCT=cWOl*|_DjW&Hfic0pc6m=#PmBhss7v8)o7Q<>lbq-Zp
z10&qU`p!?X<e=e6e>VLpd7d6`qIZ8H={|wH7=Ai}r(>e^0))G6bO1(YIsoI+9iLGn
zFZx;cTdV^ISv)}1RY~NE9wCo+!+@r{BLSMOJ6cf32Rbs_1iVaSGSZEf?wGlM?uO+Z
zBHI%I7}|lhivX_AM4?Vn^n)U|Cr}qc^^aCPQxDhI@SVoL5c<X7IMkglJYq3Eeu179
zgKMN8lM#ff4^|Z|-<rXFrwk5Oa&P#@_zhcFi@sgl`JwNmbx9>-I~Bb%G8cok*kRih
z^+&cZi;5+Z;xvW*FI0G#x{iWZofCWJb8<(sXb|)ag#j+^v1Cv1iw5-p9n8b@1p$#^
z*oEptXb1TQcgl5>;oCvNi#W5w!AKq=-Ybv;Cif}*eZue13<3|ZR|OfG;)zKwQsZ&z
z{X?!N$zcaN5O&E+kE)|@65L*BuwL|(l-m=hH<<yQbL(5_ey7ga);q;|p<Yiq=g$+d
zC&Efq-3jX=abGIwjwpS5!uP4I{>&Nld@97Aic`p$jP*PZUP(bPK;{jJAJB{1f{Y(D
z{)6e`bp?(INuR6m657M~Q9h?37QH-XPTEt0FTa?(C3nJ*F3QYr$idk~Yu_siGtZha
zHsp;#XWET<(;Let?`a7<hC(grVM9HwHk~X(nokpR#D!w`uZt1SQ~=&9YK|f8Sd|uQ
zLn=x8!x39}jtIY?ry4%s?vD4B;1mk@h<FBQ8t6cnA2SkMJ+OyBu3vbHrnzHxU{2r2
z0Lbnb6y8OERcrbN*8SWda_go;|1|WFz;#7&4o`(S;*biWU+)CH-rN?fSb9dik8@&s
za%FfQjkODUWvwSQdeJ28|1E)fA{sl>K{S^F@zBwKnvA#C9)jBb-wE8a)(~WcQoufQ
ze}}9j0pAFr9I?u{FroNJZFyA|=QDw9ASZjt0VZmKXbitm{N`1D)i{<tm}zOIU&OJY
zdsW}j<ABT0_{{J%RfIutxu0$}O#b{_`|4Hgu03Me*+)+}w}^4N)Hil+J^%WSJ#Ndw
zxYxN$jp2A%nBa?ussWDxT=Ow9sbapL0FOQKH{|dx1_{&g^KrrpM@gb;?$x#@UtF^i
z>0dcC4X;*Di3@1pUiGitws&+vPR*uqqZ|FVZr!={+y!J@i!Sq<({KJbO6NmAi(U#d
zuiV)D#w$%5iv~J%kN8>o1fJ&Mbq{$85R^RBvCI&=jeLyO>(@!-;|J6smuuq=5kK79
zoi2X%LS*EdfvPgUuzjnBSNiz1Ux+ciMPBcR*WS7{7i{=-sV+1oU_6SQc&)=2ePq)9
z(mZqo4h{Kg3efLAw>GzPZB{=M*0%0nn-i}xvyQJ(xwSeUs#yQ|=kGSmsTusBJjfvD
zTFPNkk<@G?4G?pxpo2Ia7>Pu_!uY!l^%C^rlOTaGK7A4gOB!$-+_{hIeDdhSPa>9X
zLhO?dcZq{Lo3!%Ox4&N5GGp22@1!WSd|dqIIV3?ouU+jP6aOTNfY|udcJ3qYi(N;(
zVM3SReZ|M=Ddf(Q+eGRxT|>HZSaCGMtU`cAFv5Y)0OpPR4BvOJ9yNT#s8zd#FrEwf
z#-NP(y3c6-ooUVOYsOD{n#A<5!q8tH$l0t=>xGy^pmRL*+7^*{sorUQ8?b@<LHJZk
zn50PM<s&_fzoFnxPNiq`xDsXHH(y8ZUNvgO@KLLG_w&Sh#@mXn1<JW^x!-<!deZnc
z?akBP>2jW=-s8*z0X>Z2c)S;mOph0br<+wuXjKO>=X=^yHSoPq*z*E>Df<2VYusm-
zxHtVZBAF`s+s&gJQ6cw!%j8v)8<TYbVnZnMldGB@eF=rWex7=O`{c?s6#16PI4WiB
zqqdFcBlOnxq?)P~8H>XL(SMBr+aCG*dqj`A^qzZjAX)MOYDNVqAb<y?7!;GE1&3~4
z-G1)#$%bG}NJM1utn9oKN3*kc4{06{HGWq8q6_V-&|BxX?tCLvr^_E^$q#QtNhrNO
zyo#xh%4nXMpSEWQ&WCX`V5=~`7ZJP%ylW)fHJc<f>*!#DHCbg+iOH%g*rE=Tpuoan
z@i=c~n2364;@HXck5&{ERvaJSio(hkJwD@0?xXXs!99&(KcCHo^&g+GzUTEJK0eE9
z)8dA2UwQG3yS5LHN8z2<sIsNcJdeWRT9BpN@OU4<Q++Fk31?DaPY1s34|XT0l2wQa
zx4%2z{$3k8wii7{1=!8hM>Y0Kq8lAzDj9MZIQM>u<j_(eH#5SaO*|rNqo7jocm>Q9
z;CWp#iw0Npf+ELTH1IAf5LP$2#TwS)lG#f{)x7ISxzTYBRl{9@oEy?zZeO@$?VH@U
zAhswT(r?^n(-)lG?cny^PcLlaKD)gnhaTSj(sSGQhYFH>e9g`oyll_dyy}=ku33z;
z)IjuSyf9JI=C#Fvc~?F9=aKG3;)yZBgwv<;yIH^tlM717lZb7`B$XO4$vQrFXlGIA
zpCwrr?Xdgog6VAwpWe-V`{vpu3*mBf9q0@03a{c(d|x`gKlF9#k7F}<{V`+bn&Zb-
zZ7vJlzx}zFb|1!v<8B^+2lKdl#S56<VZsMbr8c^E)b!Brl?yF|yg0k08M7n4q|+t-
zd@CckLGGQyWbnfeRIqr#wB~h-8fJ`-${1I%eN?pR$zi7Y+L4==<c}O(H-7lE*4jw}
zQbsiAmv&Ci8uPc)WAgZq)KT}&n$DM>hySV<4y(*4m|B+@QO(p0%pCnuU;x7`9kZiI
zQZ{s0eMVy9fQBK(xkf`lsmSZyX@?KCeMmkYa_gw!bdSM8lbw%oPw{fxc<Ty%0QeK<
z__5C78wc?sSh4{YkmZYpFsX;{AL5ts9Qbzs*=4H-$1Fm}xyJR8fhhxMu|GHSdP!yb
z_&r8ewkS8Q4OQ;@X!`6^^JnDEM+c0Lps8x3fh+p``lg1d^XsYBxP1QkL*V&OGSm6J
zQ1AdgKdZ;#so=eVNhTyGqgce56Z1J-q8A(h!yBCH_R0Lzq@t1}nJjKxP2;lMgyg*T
z=`em9wlpU*A+_n;h?QA!30X^~Z`wL@Rqe24+b2xfu=<JpOE-fzQCyUioR0=aTj!41
zuzmC_y$-gINt)}oP0A}>MNNy#&PrG_tgNiMeR<1xTX6HVt;grLRYNBW=)*Z)aqK2h
zJx@otH(NtmeW9)f0OCIwIJ}FN^Z^6p6l+XkH(77|{AmFj#>ixhTxDr!eoE=D(X_v4
zp><-PBsTvuvD!+N+758PgfKy<aL3H~<*cvLn`H-lu`S3<2QeYs?}vCg8o6`yCotC<
zjn7edC_hL{Y$HpIkrM!7Ke5fCKhYy5ZR&y1He21k*twL*U#W{;{Yp43W0h*DhzUQx
zMi;H1&&E;8=n=barduq`>$^tyn-B_%l8Aj{udLO_sKWyS+TV>6`!a5HAaL+@S+LD;
zZCpCPSb~s)k6bYf_z%0uU#<DuG(!r_NY(L@(hqL@Y_*Ej_tp&Hi6fRrPQ9Yl22iDP
zZ!tUUOxzKvhz$~jA-}yg+l&(nvV)K&efr0vS=Of;J#c)2x9$QV2x0JcUVI?LjnF~Z
zfCo--QY0-siT*^Pi(Yd+oDoUYN>(Hde`U2kO6iZ7^r`#mY_`z{;$~AK{gqHg>>KxP
zdq6<AS|79aN-QInM1=u~hW~|m-D0_!zH3B4IBwQ*@de48I_N=^2~fkqC4@r=k9cy3
zJD38Q@}HX$oWv8U?C&=ZWA2G&Y1TX*cqePaIWz6Ya}HC7X&2413hRi5m44bls?;Z_
z`su`nFx{9?q`McmDp(w(RRr&xjoC^OFyO15f#GzJIGFqG!5JqOW(8>jQ&u$1N@pbk
zO~VBqgSrZ#DbHDitPxhAY8+@w2T{e0Sl~IHvN*sI&YJInx0>N{V+&96wAA#thU^3l
zB@wGsQa1FhbpeT(FDD-uvz+@H2(HjtUz{1Ip=1&T;mW4QC4q?w_z~{w<;#!(e&Vxe
zMx)UgizigosLg7#dDEvcVnt8_rHC57TlDUw5eQi<EaRQ`^q?WSNX)TorcI6&D_KK4
zHR4i7+*>uIw+?wN<<7BdK#pPrIdbfXB?1in_YNGf&tc+kYXPQ0I(AKrTz2C}%|wZ}
zEYg&r@Eht+6)b&VeOn17v-#{kUs*2J%DA6nWMb{$^0NnhBW0+#b#rlk?Oh^$WMzga
zLgp)JR^Rwh20Y^d1CSTHKCYEe4kJUD8Ee9DKEj22(bf$0Q)HMTW!{pB8u(Rm{Iv4Q
z^Sga)GODC){R2x2D1YX!qPuGIi#N9xBUz;H!L#Lq;U@uhu~ywI@s&lGGAbjx!hppF
ztK(#>o{6>Nr{MKu7atrg@zDUx5X7$Oinrs}yOD<bzzt`h3jliKM>n#R<kjBQ6$Tcs
zZ{+Ea#6v@@5$^>PgFrk*{8Q{2_;p?Jb|VdWBC{W#mkVb-kR`9gjV$m}Zt{!w)5B&b
zf%qDy=z1!6!s~dl9qV@t3VcQrMQ>lq-O}rA%I`Ygao6~hA5-SGk8f})e7XTa^3|sJ
zo~pr`pDT)tPz0e}4hyieZE=ZMt_aMSGjqGs0HEis5z0Vrnui^N{ub<@IQ}>^juU>c
z2gxo7`_{-34c5q=4+$99AF*1gbpo7pY#%yW!U#IrfrriJ0JbNcJ;y7aeNHqECY1^7
zycIKri^wW<pkxC76{k6MQ5$c1C%1g@qJUYHea`#UW6SPpX<0D2ntO3_`D^7mzept`
z@f&_Qyhx!4FS<Njs$~Xfb?}|xD0|w9yC%2HpHw@lxLB?N()-H)y`Zga!B^Y9FV*Np
z8gtn{<|sl~rCjVAHt!2_nZ}?g{eIh5_(v*B%U}r-fDAr>2mCzk3FYzPHnM=9=Ui-v
z9Nr3s*i5$9!&eeqT9SRP3yj=(PZ(Y3q5Q7sftl<XP+QM<IpF7g7)WtpUUyh0CyV3N
zS>4?l50i!4iM#qZ9dn%=FBY*%|K{u8JHNm?J-Kc!&sQH$@>e?iAJJyP{{c&dG|JHY
z<oBC+yXEkPKo-6vz7R26jn`9hv0RWB<V+lXQ5C_7cgDK=MHuFUR9;$o@s#l77IEeL
z1T)s7>-7BeOyqK;R=sMZyakg*94W!s5{bv&0=J4<#Jg1;3oI7VhQACaZdEiZ_APj#
z!Mw%ob<EW@{?WwEx)KX+Rw)0r%?efLDC~9dyvLs%zqde;dqL_=&X*>h@tlqr?Q(;3
z`s4`bOMIgOyGi*}GiWA>I3|oO`1Jeh&2TOfu^c<A_zN9#tya<I&+^%%0NARo^q=(c
zSB@8!7u$0|gxK==Gj}LMwQw9rb)f0}<a}kQ2Jx?Kwg-_M`ya~C+?4B$&KKLh%zy=B
z$jj~AZsWh<p}5{1I#3%t_6dGGYkIhN3W-Q+e07z}#mk!hyz2$__u^+^_d^$bYpjG4
zUJ>sv_KM*Bt+^V*$k}M#``cn_e4@bhQnbNh=~%!!gK^kr9M!3lZ5EtE-Zwl3F$47T
z;Js@+8dj&=_2w0Nh!`W%=-6Y<Bj{-3Jwg#nq6v4w5^Z-$Ryp@?<Xz5IILI&fg33@n
z#OPJ1E<f@JcRAR>ZvyNtJL9l2PJRQGrnbO+Qck~6r#E)tvSR|50SPfvwYdR_yt#ju
zyVy&#y-)sf$v#SW<Pnt68*>5OZ~e?ZCfbkptqA+>deUoM!!;5ou#eenH~!m2eRYZ1
zq&8bjZZ7)OVYGV=+t6>Y2$KRnUr2u<)<WEdJEa_4&|O10v@AH$SU4ea6ZTBP?$3V3
za44_yd|n=%ohPFE7tGyU9vNvPx@9=fYZK55cEh;NTCicDN`!q?IEpg%?MMir-3=T3
zCuaL_9Gt-&r^w9}rRL;t@@@_T<rNOJ`xIy=6=)}{Erg9~{g3xPc94bYDe&zY95X-K
zY>_ut_YnFDI@uBaVO0*a!!VYTxSZrW|1YB^x8qm*AH+{i_V_;tr0lJjb9nuBQuGi0
zba2O{L(E*7%|n+#N(8&}5NZ%J1sBwwJU5xU*755HWo%-AM8t+qs6VaDT{W@ENJ*s@
zGh2FHwC+sp;$>SDSqj@KG?rfR`#|en?t6m-E4I7mv<-!HNkH<#d7H5nk{Gz3_s8TO
z-nv>A1MBd+!RO|$0artAHdV>*L&X5`>1T)TO5kHz_N4N3{e*B@A_+)j%RcD%mAf|i
z9BNr$19-M9TU>iawC;K-Yqm(ejZG6*5tBHyZO+}Q5DW~`?X?d49W^Dy$X0JXoEx(r
zsWIH~o98V|4j{ZU2kt|`^h<Pj#Db{xU?IBD5jG(vhY4E`gAs&HI9z2<zB!S5-Dc|?
z^+_Qc76ZPRxe>AkxoamhnrVqtp9K1sJ{np66B=8+bnEdfi!L$FAIM9uxKV1d|6#FE
zlKtGzyjtBpi{uOf)923GhS4Do7mA#FjoY_%^_J1E&qgRV5A%N|;IIX7NOIudNo8Jl
zVB3d@t%r-89V8aKEDJyLF4S?;*ezf#Fu2$$Dg2~!l+8B&M(YD;>`&#9^ij~u(C>=z
zny@yv!)nVpymcv@f`0?=jLh0DI3w!)JUXdWpQ5H~bGg5}+>cpv(*pxHJTrPNoJn3R
zKQjP+y|e-15}4F+>A&uN{hh`sJ$e1o1`n@)U^RDc>WY;R#7x9N%)mZ^7+AfSGhK*x
zARy@Sqg?}nuW{t^b)UgaPd@@|$;*v&3-~Rh14(eNz~nouzca>kh`Td@z%h?A2iYY^
z?!j_Mw>Xo6LI~RI2%-=4X@cqPj_9<t4<pkpI=zj-7Q*bVh6v|tMnlf1ldsLOQg9d@
z=^8$1g3-oo><7sjlEQ$W!4c{jb!Qk=)o}#LpOM5UsLZ_|R~431y3E5eWvs7WE*ngL
zXaB2c2rG+XF8j&sFLN{P%fzos#qyw(jar>fnzpxdK<q%|6Fi|b`M_qX2yLU5;d?gb
zLm_-4<ghF*{{}<k@G!|KfWjcz2{9;LKYF9hX8(0XG99H?dV5#yH5l$2<n68SkD`-S
zQUkEH76nb)CKX%50t0uAQoy%H?+P@8S;f+At=L8Ie5ON21PO8a2M*_e*PZl6!`@17
zZ>2tpPF`XE6`ny2SeZme`NOXtbe};q!&@<GS70D{$h3|x0fZ7;D}lifxN9`j`aSR@
z@oHa4@~eqA+U&2oJ;V(HN&&fvvF=X*EL{MIf^57m<VM@BcnbG~I-MXVo-ShAU&VMT
z+$fF4dJq$kv~_&xM(b{PI`pSU(Bs(HO!C;!XtObl5Xl1t4l?EFZXQFFE0EcZ0-{#{
zwhk4LN04#xd(J$l)8h0c%7nz?_iQ(hxC<v_xIF!1CILv`Dr)d4EmG9@hbyN=CkgaU
zzIBZ~Nx$y&)k&~t3iHCZFbNDyRF4Na)LyVIUd^7g*%GS`pT5C;zzwIT?v$`rAj`IK
zN|{VKb{l3bR<d(4g+4*$Xv%k2MX{Dc`#SGA%8lo)FG~YPRLZ<d4;l;y%DiPN;L^0E
zuulFG_XhVBrcWin^%f78iw``20N<W8CXkgcN{!kW1{c_n%+y;TM%%_>Fve}eVgz7J
zrMcnU2RBY1u1d7ou6~E608F1ylQGOFSFe(JmmM$|4wib$lpvI8%TNS5aP*$eeTOWu
zXdW`4R4$1-vosA(4%^&0ki*^t_rFQWUUZkEh&4dJ^Vv|FO0!zU7p-hR65HZn;GI8?
z_9MHEcM@Xwwg7KozrE3GDz3qTt|08A!FeYlIJ~-Y)M`BK297Tw?s50?L8&>j8sr!p
zl?d|NaA3thfL#ud+7y<XKe>hFJ(Y4s>|!*Q*NlMyYu}GyeAy@?HRA1?KSBLVv#>Zj
z8bN$1W7&eot469#>YJcEY_?kvUOkwXhxCpzQ6HtG&R;YVMihPlQV+O{fdT=n@`<B%
zfbB3C0$-R$Y9UC>|3=Jj6}MoUGP4c$x*}-p2=h{<s9h33`3Ya6$Wmxxiiyd=fw%L=
zbZX{DZZvm|d!HNi=~-{qs<&0mUWpbVDRfvZeCd!?DmL1r!+au6x0i||<qHm;e2*%H
zAFoA6QPd^WQo}^)e09ln+;7{t|8nclVk9|*1`KT-pPp>As!G&5w)jbub@5RupXQ*k
z94<`u0=Ho6v0IAsGq4Djw@z?~uz}o(iu1=X+@k>MYuxDfP99t!j}(`-zYyXxOlmWV
zrPf0)p@o2e6fIggJ8+!d%6gyu6yOFV(Id!q5se!g)a;{*imy{j{I={+m#D19<n-~a
zL%CN^aer{_82{}^UZ+j<)kQHi+`R<uIaDyI=Yl7WZ3~|i?BZpU0&aCt?#f9`Mp`8H
z5&I^x<=6O{txe^R;||!WE2e{_f!vSx!><K;kUBBd26JTO_c~l8Qa{6K5}_*mVF_!p
zLd0V_zb3ax{J4+>4PtRzv-R7w042m%=zgfjeau{kUP%1A!f{2-!RNf~!5`_5`Nso;
zx`8BOFsP)+`nVecJd7sp9MufJmxmDq2a0*bm?seD4GxWJw%P9Iehif2c;%;Lf0d2<
z4wQxZS~;8O57Ex+D|3qkd<8l}+mJxVWT%Voh@v(X-KchdchjVm5Gw(|_aiO;2ndOw
zakU%$oK;;n>4!tfU31<<NhMYjTk@fRB2}skNc(mx_W#)+NJfHnanTQ8gUCF=VOe=a
zfs2!1Nk8TTGQiLQ&OLx&STlf#&jkwjfHRz{gJy6RSex;d0DmN@FA-m52D0&Ipi=W}
zfwcF7&2>8f2M57A5zynel0Z-13%McaG9^~VQN<QqIA=K>9>nWAJ~sqxfGxJ32gFT>
zVg|-LyM?SMFxwVq@m|Pa+_Zp>`><P$-*VIPHWX2fQLNY}=KZw+fkw63G_vaP0#+5A
zKt*R4FJwNn(9gJf2D+wBoaq&NsZA*A>Y`U&2p2IDjY>?jnuKXD1g62ec8r=>j?WtB
z#?Fb`!A?ZOj#j?n?7$!Jbzmh_Oo;VxRPl*40PO{Nz~;hHjqa956SsS+Y2$^SD*pCS
zz2f86C(+No0P0NtGH{+eFp`&`{#r*>|E(jt1y1+&=I}#H7i&m3rMoqxpXrAIw8!?t
z0AhW4O9L{n2xku<SKFI!0C&6cveuKI0Ja6*hdl;@sC!-Iy|sK@rDM*V4xyRjJ-2i|
zuryHSL{-%Z`0O|6kcpeacgVOEcJlxE&wSi1(yf$WvrT{Dh3QylVLo05d<-~r<ILOe
zC|Mtm4LGQBUbe;SoZTq+_v5~uenCYa<4Y8L4-dwP|Exdc=z0zyO%6%yqKVR6Ek0dz
zlAv-3`?6bb+l)J<d96dBB3#u6RKN8?>Aoq^<s7=!lwij>RuV*U_o7+4bP9>rfkx{;
zA2^}=92fXvZpV0}i-<5D`HUwAuMZ}%o0tf&`8b8yt7ihz?{-2C&$w5Ir3Z^i%RL+h
z-ihGKx|va8r+Aq3<eo_$rfybVut`E10@GOVc6u=WU{$+1Ko}fPe}HSijd30>5x_Fn
zOU-T;E%wUiI|@xkJ};Gru<9TWr?95LPX}G$?$CjP;5}spF_6))@*oKrajU11-E85K
zw&M1U`Sua9gK8mU+yCX57XNr9SkFhd-!(>Ql;{#_E8^&v?$+yUiUnsamTym^0~T&q
zr*`4itqbWiw8Hiu+{^J+Ov`+;-WM4*riY6aV!6hf6{pT`*%ds%S8rM{G48*(m*bMn
z#+^smO<7q@c&1^Jms+|PaH@ff8+^eLZ}JRF@aT>u!BN1{%*UNX0-ZQ|W@Dh-3zvh_
z#xx6$v2?HeuBaj9b4q18sV=c1C$94a0sntR=T%t3B{IK~*(=W}m7zIEyHN^1lu(fy
zLmPSYshEV!K@s5+%h(Ms2PMhxTRh%gdzx+>-+52xi{lqB9#3t=3E8}WgtD2N{o@pR
z>zr|EJayum=UDX$eca}@<-=KDUzu;vCZzL^!9OxSiKk6w-JA%$qH^bx<D>yH-@>un
z`LUmkEi8m&B$kgZ=Z|T`|8Zoa9Q=S^XCV#mLOBk;7oxD6<>s<`maVSi&$&FlGmodn
zX{+^{Q(TkPiry43Kb}-t8*X72?%H-dAi(&{)`gvKoTh(Vi1V-B`T>)sZ41uy)tl!x
z$Mg6?N+#Q8;}J_~z?^Yy(fl;A*jt;`#GQx3#(K+vQz9?%{a|Ep@J#$cCIRnuSRFh&
zZX(aKkL;K~(l1)-hj~`?0T{WrFqbmP7GP6>L4!7A7+nn7xY}CAGpNnRvn9Zl!<`cy
z0lSt?;KDvHAAewF%6~>wDsX6uOWIr=E;u?79SJbcAD0HdG&5t8%@*H0-|UZkKb|u)
zgH^Fg1+*_lB$ZDutP4(+)5`eTlH?BDf@)g4b<?t&A4Au~>+$8aW|0hX{*t>kuYcH(
zs#fdcW>+t2%1KukasQSF?Hs%y<f<LU3VRPuSDN_i#7coo;B()-e8ET^p;dW&hs|nb
z5;3iAz75?E*Bpnv{TLiJf5sUt;|Z<s8S}KV*&HXkAQeuQKhs>G-C>|zx0))iovaZ#
zi1+Au#}@kmP8Sz0kv;4?E~F^o)e6W=D3q*3nLca52XH<MCr8<A69)`{@GNfP0+T=5
zV3wq7V`5JKqKi_i4QUT;*tUd~#Hwp6V?@}ne7tPa*2Rnox)jpmD!|F6oVupSYjDq+
z#=(8PDj1?$U8juo3Q?kI-E_*$5q;<q=6F{fa^nov9pZuGyDJZe+SoL+2esi)7*CDm
z6$Vxope-oa6I&`e40$r4HVboi*k>kxx<znc{T<BgW;PsQHe7x|-hl&<<Rqjb5&&l=
zI*e59qmDOv%hW0#skeT@v4U~BXib1+-lW*Xrg>(6=$u(Q`s4(OR_rTR$z%nyRy?oL
zo9B&7Pn<B%;?GSPTaaI0pI>l4Ba<>RNp^AjtAT+LK7mOW*Cxlw{Ji~=Dhh0(`B8a;
zETOE3&Me*hjxI`O4hYyVXXOZqELJlpJGNsZe4FDKb<@ImlWzVzY2HGtQye{}S$vJa
zittrMI5`M-U;{%s@f~Fg$7$kR5?&e!KSs!e+g_uU(wo2R+nl9jl(J}rtRr3<Xp&i}
z)TS6cBdLol&z-+y!ctQyV!SP^Zs)vm(K|9GO3J8}SsM@D{6(gSmWkdOy!?<!Mzb%h
z|Ms=flui_@3R46J$&}&VGD(0=O?AY{h#qvnjP*^5XIreJDHdP;?)aQ=DDDgemL-tG
z(LkGSQz~VZnF6&P@%Z74Qkk`R-_2j7N(@N(yq!8WQXZeVbi$JPbx%kbJ#&&8{o1$d
zUtnpO>Cp1Q@FqZ#Q61cvrM&sGG)f^8y-TTe0TP*Sn2$UtSXV3J<=X)((AVknN8oZ0
z3n_Gm^Wo^Ch0FNh0Ep&6;Fh@hX@R~yQxU_Vlrkzz_?!R4Fp1uA5}x~ecN&V`l_{d6
zH-E-tXH*#Tj(B&nyYmFm=VS>0U&sPN63BrmQnj89w?dCA!j~xut+yTV-Kpp#I-EW{
z`sP0|(HRvGU9=8(Cawz!bsjW__W*u3f59|o)KZ?lb8a<(A8f<D1wvdXc$SofC?M?G
zxw}1rMdYtp1D6h5VM|A5uq`=CCs$k7b6iw)KtNRWtxc*(xh^W%7A(2|T9ICRMhwR3
z#>Hn>i#jc5ZSgfN2CE^i4*8u8NK>iRs({qfC?IY$d~xy!Q1{QQwAogl!L)RPkN9gM
z{<=HfTLaf4+32u7-EEH=s}*(=fWvX?9q@Eyg1PHl{p^j4&^wcMW^D%zuP-<d*mMiv
zr%C~!w6oj~adiMtOAP>YX0^?>@)<C!BPL_OM|0nt4oFpD_`JSnH_-=S))e@Y%oAG4
zZJhBgM_G^`-bog6Mn)K~#OJJsNfwZ%O|s{G)oNevA?_jk?~`0<&($?_QK{UI#^Rqr
zV-G6jPyo_OANBD;ncM{*pZ#uiJ#Y7_n|v$E^zq>?Y{d<>80H@V<_CG09eP@zXgtDV
zZ$%FG4#S8yUje+HP93|+t>(q00bD%n+(Q^H9v?K8hxJMHj2k{wsV8h0bd<SOZX>90
z7ci{us1TSPeT;lhEuR+@E_HSM11i^X<*HD}!=?sn3YXV}sqIVwI2*oD6m&+t&wqrF
z;hl_JBz&yf7c-AfRXjgER@2ioPt8s{)Y!Ol@b?>w1qFa7nhS-wOKzFJf+xx=J;r<B
z4BYVP9zzQpBbW;ZGQ4ZWdoR5FIWXrfsYgd99=g%Qx_4o^qXj^^q1@v%PGvdnz~skq
zM(m;>l)`wS0E>nDhR4^Qw6jL&&w^T%Ft;W3(s%{)w|>ElG!6}t7`W`O`)4GxN_0(M
zwNM;szifs7xtZPm<@USRN4w2@p$RzK@BUxkeF<0}ik#<y`v~*kRx6j)aeCrTj_Q^J
z#TJVAn=tg={WB-K^*JNP4RQzBF)_yTmK#rXnHb{|F_EnH$K3xRHA3NBA|TI^$#3l9
zC0_8|9Vrc0yAYoq>-o?e2ic{kncEMM+XT0+QjNyn9?<Q;$U(aIGczHigm4J?!dxCy
zWVU@VfMvavZUpc+6P~w(GwGeq9vOZJ1A56rVWCN)+@1y8{d9kF*rLzei7b$u8`}FU
z8!t3MyE6F8tDp~bIrM?r;MRJ~U(T)oBKLgY;!;^oi-EbzQGB)DJoQ1TBwj6LXr)RU
zIPGs5wSRzCdu6KH3=O~oYVKt!tT#qt<Uj`YazBKLf<PgprDw&S8ODme<tiVR9sO}y
zt2QWm!HF66zwzCnZm^MFQ1A$ZCz2X5uT8P{;!z~V{ubVz<8b2n((rL-&k^6Pdh-;7
zd==f=h@it4_odpu>eoCX)N;I3&<D2!Y8lx)?eG$IFj!6{;+~O8!cI0`K!JO6V5Nu=
zq?3Y9Z|pWe65H0PF_;-C^e;);+c!LfgI+`GLmS%LB|h*)vw{A}Hq_9mvR#H{x{Av-
z`WFLQYJn0YMAo0T!8{*C)_ly^_PH<ehccdpdkV??trxg2T3fj<E?7xy#K)&LQgOyP
zJq$0Xasmzzl7#e7f)*^34xARPUTZbe6yty$AG+u;|A6TZ06ud)|1)^}F~>9gF$6R~
z-)XVg=ntI;B83A%?pHuiBDGyc3hvj-woa45K!0olSRJ$#V8wbugw+I@cHrR!NQ`*h
z4L)%=aOlti4-1AR1;pT+!AK2hX`my149iHQ7!(bF@)H5YN7Bwia)vxx1<(G)b{Wcw
zIQYhh_(QGIf_7N~krvaLN3#_LU$FXf{{h+}Xq$JVtH1|-;vPcI)Ra^{If?-W79fnk
z5|-xAAsUG^YKSd+I!-q*j=7%Q+KSczPJo3c!?2i*fMY&{wor?q+D3nDFm#%D&LKK1
zTgX#jPrDTEpdfPJKVHBZf`}oYpy|pNJX`aq-Hu1NXDr-w@KJVI?(^UlLRri=m~FWG
zKo3sroozZkhwrZey>edQAMRd*0kzmVZXz#(;TBx7;c-5R{B6jD-uMz`j0>plEV!v2
zV|9D}2a^Nug5!gC@eR#RX*guDbbe&991=vbSBco;?@#UZPf-*qQix>OBW>4h@IUqU
z-q9q|@z1wyolh7HBjNuLaR@!khH=C9r13JH2z^0#`v%YacYqxv3B)Wz5;{c2-EqVw
zwx1Ys6DFjlPN0l!*<4|E8!#!4DE!lJG?8@4nl(#48<vwZ%!w+9B*xSo&jPPue+Ex5
zW#FR1!3jvw;E=l`%roq5j`8O?$n1}C`f1M3JdT)6`*ntoUB5XBpB~`T@hNlk`eOo)
zZn)(Fe~x$JCP<naXOcQxFG?C~J<xxku4y8c#0?khU^hYSDx9x3aQ|>AIG6h4{?YKd
zQ=Pxv5G!HjYPB4ajSX*m2rc>mh%gM~@CgSKFKBTXvu?VcF}EzhIv>^WLc3yPaByT~
zaPY<z+<Sr;+lLqo)KebkUg|Z<Yk`wCz4Q0~P9t{#=u^o57pl3d0Zct^1g{3r@&5w~
zf~v58=u{Py1>4iLg0CXz!0z@GUxSXN9fBmhqNf+T%F7R^c=$1x>LAWbPgb^zNVr+r
zZhGwPE(RAwkTzpY+TG{^)$Ef5<w=Y$<<)-c1?B*g4L+DN>q#=1I3XwGwfs_&p(_bz
z3*CqNaaSTAM&az7F^Sm|t&nzJQ#Xqh{J^}vWcmH=a|Y5dQUCmX<%4OPlr8R9X0wHR
z>qYnE)<jEbTY2UF=U@(>88~<K{VR)+zikkn)c0X0YC5k;MNil|0*Z4*9ob?$asX%0
z4t+!im}PKBF@Y7_8Ekcujo5|pgW0cy+fL*Q8B*o|0MRiew^#(Jp#O9M6dnzj&^8w)
z#Q*{HT7OfV+wry=jDV3M8c_Dc0^rPo9QqN+p_h1#!I?N$4jp`3AsygyX596Y({aQ(
zM!nX}6XQJ{JQD5Hx;T}71gTzLGB-EU$0ss(?vj^P;Bol{268|6cl$c`Ltr5C^M4LJ
z_fy=`rJV5ZeT)<*(MK<xw{GOfb@P^vmdNl|%m&_`_WV72B=(9LZ4ZC_^~1K#gZN)!
zOC5QGRPg7a)va4i7UEMm0>%;wOStI@&pwi>w=?3f#KDh%MK$7OW@%&x%5&3068ZHW
z1FzZb$`5z!_)y9H0AZ>h|2akP9f9|H$Rnq{3;R$y-%uQzIrEr;8eu<9KBGz%GBG>k
znUn{FMIZV-JI<fqVYA_nZBOB?9_iCR83lV%{M-KWm$qv7K==*!sH}&2R1|DQ!k&Sv
zo3QU()SU#a;`Pu(1sgkhXmwS&x`FH?J%ibvSFq5>NkcAKNYlLq$=RsXY41I}b<FDV
zt6Fe=k*j34i1YDWi~FP=i5szv<Rvh|+S6y4*FiL$IXd@t7tG;UiQ=tMB=ErPFMOVg
z^~ob^WBC4;O~b1<cm0fS{m4^zi^W3MNMOJli_4~zSK`(sx6f_3FNRN@$#sr}H6wOx
ztFhVmk9?z$F3evqw5?#8C!d~L5Uasc>K?CvCvd)%pDE`jQ@akIIV0CDAwO)sAW8~6
zC`f|YpNGg|m3zXg+sX^z2dWU~ytsM5=bIeauAX;YY=J!995>iV{+bY%@Tnul=e4z)
z%5+X;ctrfJtwX|q(JB~(c^=kV6hh#)yj#!@6<%TckZX2`zzm@U0n9lY^idtzM1<?l
zanO%a4<3n|j_3lVqY2oZqI`}H2iL$mE|Llg#2pD-riQIRLCKEQN%p0H#8M~8mFDpi
zpHyb8KWBj+Wp92v5QPJwH7@+3yo2+)Z3!aVm7HgSH!$S6tqM{pb&RlR!2|d9z|so0
zok0#Bf<1UR-r&#0Bpgpqh<6<j<9R9BjitDD90b`qzjmSsTO_)Tnb3jcr_f>-XE|{p
z+q8NfJmGQSKf236nfv*<a*&?*xGXemL&S!<pIrAf0hMb9_Fqgsr2}1O({1xr7vAHs
za&Vx>SvWUhx%hCBJ06~V*w?A_%#M8^>Bg13XmM&DNwwqD6p9`g6aCDe+RrZhyYXg^
z_zPO2JBN}TY3`>g$fyUOx^hSn;2k<Swa@Gvbcd-RDF;2J9se@pd{NKYIFXN~V;RZB
zVGZXa<lw|=i9#X4eH(lZ&W9UJYjK=}eLqJ&%S`T?A*RDEpXE|&9;qx<xAaxVzo0_s
zgJUZ<m-^SskhCIC=95<c0>=3lAJ1W!AYs+{BS}?3tchh8&v_O?FI}ZO-w^&+5n(1i
zp2O4QOND$+5O^PpKo?B~fpr=K(X@`;5}?)aS_}B2^S5}7FRfB)1E)Nv(FO!+{Z=;Q
z1$#%qlrJq8Ho!Ug;K37(jU7KXo;ZQkv4kCdGVvkI66gvS8{{KNOV5ruIh>W?T(N}B
zm|0O8*scxYV$l`YAcGGbT8kt;s);A<mrkCfl1@&XNc<nKTUSJLm@QsvFF%YaDJJr(
zW;I3)XklbTqB-`TWWffR{YP7f^aRy*QW|9A{vUPk0UuSd#gFgYvgu{hHob2)3sOT8
zAk>5ofe?B?dhddC1VIsyA_8_rK|lnl(nOJ>Sf7fbi1j_&(`SEHO!f}{@0ok=mSh9?
zKL6kE^Z5~yy?b}>oHA$5oH=vOnNPF}EI}O`Qhj$)k~&9rC2}YGAW=K1A^8#wS?;;A
zQJ!LLL%E@3Q;=1R<&y3+6;UHtCF!O-7E1cc19!;ApR#WJ{Q2Y8t)DP=?u7Mi+LU)2
zKD=9budX9UcJ0-s&3$XS78G<{qikDEudDyvrp>?G=I7<*x2+l8o?hF3(FT5I$WkWg
z3Rh3St|Py5bdZ$gso{l+FCs?>d;1^|HVUv4kqKnR$Ocw=m<26}l<-?0<zF7FUcU9K
zsg=DDOx$b4vGeVNg7S)r9r=Z^6_<bCeEZuSdn`LKIy*k5Lzkt8$5+Y?_{+cY_xSO%
z51;8=I_36(FR$9QjTPlNid(x<T73BKb3AzE&<RJ|-!|jM+bRa1-6H07i_FmvNcW(9
zeO;say?`~`;XdPZ$}w6nlF~1`Q7TYw?{GRXr}e@wHlm36kYBz`<_NfIfVfn|Sy6kk
zz6%gbn$HvcS1SmRm~YFGnJr5OB<+!fwv-0JGjDe~w_W7h;D%g$QQHg?;m$N$a)aR5
z;f~5a@3CC|{6(jeA83*nmB3nf5vgeGh)QVT&{j!3wIkYSsh4(`<U+Re;9Jxm)gQ3u
z=n#3sNP5b4n%JSNF;(v+xx?%)D>zt+p}H@faf`&SXuJ9&(zq_ZvHxOtLVnOi{ylqw
z-SFnVi=lQ`&_xzg`IDCO;M2&6n#bRK;4uG#ul}z{hZ;1Ezh!epgtBHIvK!eA?1^ct
zd6X+Gl)w2Qf1EWxQ}gX`wm@z;oUg_+Z=4}KCCg}w#oA6iX^BJyaI;55qz8h9C}N;p
zX7yMU7d{x9mlrD?RJe9gdoL*|DKuD};&fKu6MVBWs^(E@=gJARGf!^^iw1qSUUv$h
zRGPJ&qV=IRv_49v`f%pznmtkjb$DoS^*z{rnGzhDbRU|5eC)>N;BIBDCCk7@-!>sH
zIY|qoRlm}U1uMG|fvX*T?zy8Hg9DjA`09?Q<(2ThE_iy!t86?r8XkYLy86k-U9P38
zUvRlzSiMyA&2GL-*$ugAipWOPQ4@0L=^J5zQ8{h1cc_m<urOgDQ;lMoqGjT<g0g^x
zUEt8I>#Zb2OAbz*4P2gGM3OUeh{G}O36>7LUfkBU1nB&BAMlfG={#b>@Xbh4<XeR}
zRkdG#&-1{N^(A5AuVWXx5Wl4n@;5-ca>LvyMbuY<H}dE5!<GyaXMHpqyb+n+KoM(A
zp!m6ifAs2xd+yorDheawddqh<>6F8vb+moA1$SI76zNB0YM1K_tsO}i{CH2xK4Wx3
zHK4dK`6ftZ=vTDGvKy50%@{A^L6v&}JT)u9b^ajkOhunaUHlkNT|wi*%ljhYJ;4EU
z1CClRFtaOYQwK=Ei<~73l|?wr(Z}zj4#&wS_``s{{NWpi>S&-aFZIOA2dYN)@7HU|
z2DX<MKGBytfspf#W(J<Kr!riwEH+E@!P;(jtiAo#X=B^)*_FI->FPTC_vMedT*PAE
z!yWl^aGrkzY#iXc))9K_6gaQnLBFs!eV9+3LHwVMKj+v|oTX-rL`<;gTz1aEt6@4?
zp#q((zyamQEaUj6)+lu!YKKrh8o?zm9L?Ey6=TJ?BYfPV9dhdF-a2bk3eQeS>Dx_9
z=+-yIxTY)hX1a^3D>*qi#ny<wel5mDPO*AXf30p%TtDpEkYFE>8?i3z>a_-x6!s}y
zN#7D|{n~_WLj3DjYlJWC9MHWCbYl##9E?>LDnUSpvaC#)B?U4ug3k9OsMci#6_+38
z7qmT6Q){rcUE0M`ANsCG^Uc-WZK`y$w$>V}9#!Jr@72WpM{s0hs21P6{2ksS4o55n
z$rFQ9(uvQzr8IRN@;O8BM&~oSM1@T_3Gu=AIYcA}eQ!2@N<D|zKzaz@^IM-9QbE0f
zMYDR&q3y&9ZYSoLD*CHhF)nvXRSq`LrEQ0#48#0_*e-nMZ3rIh#VhUAm#tZraGcSA
z)^#I;YE7U<buCc(qNKTeTbZjtYDy<pgCePuL)&hGL&L)y>S0%LPG$pFahW^YrD0tw
z&Bp!NKmvu!iI$aoxxBy{YKb6do^VURlNU(Zh>#4YByGiC^|N60@+-+M7-xD-H^1j#
z37H{}3GxDGMu;{-!e42t#P_(8gIcP=uH?(Fs0448WrbWRzd*9AQ|Ev~7Q1n=l$J_5
zt`W5a_;ytWfoV*p)J^L42$mpMW+g_3bDrL+Wg5Q{5oym(VHy0hlx%xs1Y>C}TctB8
zJTfsWnSaJIlG&U@XUI{0rdczUwLTi+Ow0(s{q~3qdw$3<)*d(cOUFX;?HLib-yTl9
zkStAEFDX~<fH7$|u+ve2BFckr52?-Y>`A#BCr;c*zheirZ$F5Br7rr7jT80vgFvUZ
zEuBuICGXRohxC5f$j4h>fbSKylF<)P0%X~=7a@8g{LT7;<Q^2#BtqpAms!(7e#N$o
zmCcX`g(SPIX`#yHNipH_ve9WFLC39;?hmZr$ATua-6BgL(K6c9{g&V;$f1(xc49j%
z)dSW?haRpMA*IK-8yC(PG-2q_ew~)x_t=2=8*);TE6SJ5Xx+R2fU5G*WBQKRJEWw8
zw4h$R<;Umt?poMx;*bG-tbNYEgD^KL(`}tI=+3smo%>V_D{9iD_{J?glG}BXvI9~`
z^NdMj8umiThm=DFo=R9ejuyb7Ei`$wWm$#9$9P*oy~HpZQwr}&4{h!0F|7Bn9<J7*
z>HIc!0^)R+w7y;f+!Oc<@@<pyL*x#s+CdJ<pHwW}9M@ReCk+jRueO-Iz^PW;>?{9K
zUzS(HVuVMIWM6i|oHr~Way`aScxE11A3@}21Ql?i<44#dWD;enFE>m3{aB*|{HtAK
z233vU_0TQ-r|n~D&I~CvdHwvc9Y*wRb>pPyENy42mR&mZop5{aPGx;ov&ir;7T<|K
z@!%Z?58iSAlx{oN;NbSwStIVfdr{F4g>@Y~WPC}FTc)nvJZmNK7I-2~b2V(+M&=w&
z64ZqGVVl8#u0CPsWXi%ZN^Ga_U0;lY)=awT;2q274Q%@^|8(EX36o|Wxc#<;{o7t*
z>HBAnFYG(?F7AG#tgN!Ea`LLGe(vFArF}bBPF_8vU*)iMOkpREuG&=I<>pHM#67DH
zA6dDnyxUEcZ1ColhwqtvD}Q|8!11lR+%$Rkz(M0$<8|$(n{UN9grTWEDE3|q+mDuP
zBnVK>4|b|q*H)FVMKZ3F%as$Bp#0vcQw_4d@f_x7wGwNWT9&eyewwS5j+$xCP-R_c
zyeqV3pHd7P%M}x*mV~<^!)t<dJ^ntPKWa&)S%R!ia>I)mOUNNqEw}^&7uyI7&GAZC
zZjd&^Y*VZ1-=Q-*<j~$v+R0JS2mfs0>R4*t{n6-k56-@FlEVup<mi62Qke*ig_smr
z2f8K}Ry}Z4NpY%J#lXBTQY&4dO3kd~IAyaE>Wbxm3>?UmB>r`|7B2l(-rgli9U~Hx
zLZvdvl@xN@^B-S2yDVICzIc$Y;cE_pCoGzGVWXj=^!ZVQ2*6?)P1x}nE?3Y2CsN%l
z?8;xfi?jgWLl_2)Hhq3H>^`P*pR7D-K@`92a-F7JJQf7&6zO(KV^lvbb~lBES<0Ul
z1(RQq&%?@pp7o|Ydcr~aS>O;$twTeK2EA9(&jO!W;_nm`3P0*_T<)R2qF<Y!hTq$G
z-bGJG8MqlQ!W9CAtD|VV(DGh>+m1+W{-VpZCM7mM@l{xm$n;v19G9<@#-#kWrYoE?
zgZWA=3-jxeotaKs+Rw@}2swX}&6oa(x%Rf5WWr!9T~Iz#UPW}O-cuq-8@g9$c$T1i
z=1LCZc5V+#MqfmRrKW~Sk&@y{Qu@>!Omc;(%J!tBnqinmMO*Kntyicmk4A$Y$Gj<~
z3gt6N`-NK2ev!~B`w#mMT2&qmQ)`ALB`Mq0FjrE|L8T9b-HR9cizEmfH3qHTbB2c_
z9{9N)Uwib}8mzHSZohbO$8%V+%ZYo&W5n%oe}n6c*A`EmviS8{Z2~`i*3tP&x{KBs
z;+^u@b33RdmuvglBS+VwWwzq=#Z%CToPl2d`pNNw29Db!BjOi$TF`ej=sVQ<6#Z=+
zO9l-o=@I$9GaFI{Vkl`qchAT*<vq)qbRU?X9u*Rj)YD!z_^#e1WxdL~H0?gRaejP;
zE83peruXgTZ91t>_Uzd?ByaAJr`N9GtF(`IOxxhRp$FY_&K-}_e4b}zx9&JJX|)qx
zAdElYWVH*NM*MxO1h@YN6;^wBuTFKS=-FFP;fzna!Iof9p?&#3(YsRn#FySNtdQ+x
z{g*#3=<R;}jFE{i!373i?)pE^nZL`);DW!w$^WxFuO(v!&zEh#7SFHyi?yUy^o<xt
zg_zMh`}d8Uj-%78$RRO?EKQZdP^5uWOa~?uwP!K9QxSXmay!N%@dV5j&j`y&nzQNb
z`V9XemK_}ua`VPB>oZ#YfHAgz;pphb^SAMP=RdY!RH8ZJCh|!+=N8^|A>t=r863Fd
zw%c-ET)6(-h#%N?XCrt22~TGI#Fs`LW5=V8Ets$?i?yd1b8{SyvrMrpuq>@bl@cGV
zLQUvu$e$*<XKXk6s}IndTNv#q7Sv)rN2^U?eaV;+>@kL3X#pnWlARXCB$+H~6iHTK
zf5v#mYHkt>;rr4Iei(x_BPuwgve(>2w$QqK;?=AoUGT{m!#VK-d(K&upIm;3c=vI1
z6NU)M`Lp^AP*QT#`LlZs%;75k`a=&Rr|?OOzu-0VKl9~dpS81QMP;w->U(d{&f9KZ
z{5ezS{fk&@jPD72S9CUO)b|%+_Q~nr^M%u-*4efKzK?(6%C@n8elYFB=cY3(;4ocy
z#`!wSCd)&X$1QuVlk>5H=XHA|HqTj4M^R@OT=(w{Q^)(=g+zLKND4v^IVF^ti-BNE
zuuo$c^$|qcqX&?x9K`pg`1jHcwpZR!L;UaM$GmqeDPX5n=BM;Nh#oR~E$+1o>G|bb
z>5i^JvSL3xl9$?hzv#u3JeI~Ee)>{U`!`=p;hAr}9$$FyQU<s2uRe?kwwYsMGM{<J
zXICt%-}CLZn^?;tIk%hdtqCl`*8a5bok81{FI)LfW?9Xe^+#74ojabNESA3>`-11j
zDE_0Z9m^c}9rgBe^Z4YS7E7Jl+xToAuC!veuzx76`F=jUT?{+L`Yyis?7W})KZAMi
z%CE*;+}n&X@r;gZXb>j`oLFztC?XpeBg=_=58uhU1@%@tc5Rh1>u&j`414B;%&6ed
zsLTl&2^lxZ^GBp)M<yBbAT*8LIe(kU&PjZ702MQM`|{gzo}V{9M~N;dcR0!mqST!6
zV;|2%>R8y669*?_t`};DAK?FrI!1CYd+2YE{j@=~Wd6E2fHikrZAy_P9;RG33&v;3
z;h6_!*3z#N?vKkGW^l!$9_rDvJ3UNj-aE`bWkYBkeH*c1e3!=2iq0E2bba~I4iV)8
z{th3+(oom9_JC}Fd|>LKK%48BTb^$vMP!Z7v}fF;oL*Cl33DEUkR)Ub%gZ@*9Xx1#
zQp)VzoTyy;Mt~{j;9L@u#$ArJW#E8J{suKg87zE8IYd9i+wk@HUi+SfET?p8)VQp)
zNuy4ZrL;+t($Xf4%iNwT`J2XNWsRG3EOQT|kD8R?js8mfz8XAV7=Exl@Z6TVkUj8#
zlRsR*lPq6>rk4%+{HU|}Qu=bIMucRePNhwncI?=+Q72EU9x5<L`}0az@m_BEwdd2e
z?|s!niI;CCMdqElkmc@mD3f$wud)FBCiaNEcwl8=_;BTQW}A}5^Z_fuMrUx!5JP|L
zw)9cIQre3C$3B)X-+eLnR`^%HGFvrY2b+z{|1cVNzhqo6)WpV074z(FOR~C7nPtFf
zB>Y_Ua0#n6gM#|7QP<Vxnu&r}LQL!wsW$i6Iv~Y1)xHfhg}<n$dQR;KJe%s-QNEnj
zr+a;IN!K(F=(7MFNhp?Tz9{>2K+9ocH_uu;apIzzw)IO3Q4>>#jk#y`EfXg!o-ts3
zR#cFhn5Mnr!T7wvJ?;DZXD=RHSvh!9i>iY5_ussTuE$p7b}w*mGQI+wvHoRa)N`^+
z_qbmNj_SE<Vk3Q9AL!cfF#Az@pm6koC5A@C96*a?ojvNgv_w^o&00TT#^MPRZ<&41
zm|>}jYDikYZ8t5NIC1f;&0~kLZS4zkyH|`Q3K!jcfBS-}7MtjLF~!&QU@g@j<$-!M
zjA>n&o;kB0%%1Q9R(}keR5EVTgz+U)Mz-izQPHpY=<rylxHoZJ`-vk8`}a2PN!=nN
z7BueNyYYf)u8yUy>5(q+zP#z&sSQi%J;?^cd5S?nm((;-<5C#ovLs76*$hFL5CbgN
zVQRCWOY;WqxM%mVO&hn*zlT>(^?Apv(tP)=zhe=ehM(rzg%)_n-{fE5=S_*$<Jbha
z@`&_>@)Px?@P_HWZ4nz`vR2G0<jp7ZL;9k<*;6-+_6W(iKB;{Rx}@DWX7lXD6DBN%
z&?Q9#C6LhFym;b-MKk+v$P5b$60&1yiM^oydIc{bJBFhxHqY!*L&`lHn;uyga<ux?
zf5`!MdFwK-WUo2*8<n1_d3cE_-9nzW@Daizws)B+(2uhx#Cc)mi-lN|KhV+yviuNy
zbd7<YM-xy5K_O|iu@Zu2j6LjDRb%rJdsNqyZ<+jSJjG;P?eRtZO}P9Qytxs5A#k}4
z47{rAI>wlZtdd?I8t#+2`lK<(m#OCv2T-bW#q1<qQDV_imoIhuiv$NuL@hDe*K6|*
zg#o<66R@`zyyww`DdW8zIDPJ@(Vx+F^fx1KG`kQyoi^)!X{UoFyR=gj4S);{7kh7M
zRA;k0`}8iCCex<0w!F3IP?F8wd^qV<$n!bnLBY$GM8n_W=KsW34}XW&$6pQG=q}z>
zXEOSmA2M+4{Wmbwy8=bsFdY<R)r#NI;~fOYuPKub_jkK#C~f4^v3GvvxV92KvuhTO
zq$+j=ZrFE@OaFE#^-@!Fmy3T$1587=pw7TK8d?v7z_UK`Q=xnFYst_5C`K^zQKyZh
z$^E4s*&t9qaI^L?P%m9RV))F-UZI+`Xx#YoBvcm%4)77GaT8}s2#C?<-Yjtllux7s
zXkg=d_Uvhj*T9OtQfnbzhnslBtCaskkSNCMMD$-aWUTvj_uqAh;dKn<Yxb@DMZGfk
zMtz@%ImaCL$Y}A58ME_hkNLl;2K-egNEkQKvF2M+3coIx;qA7?>!+;9A3xfAW6DhR
z=r7cd)l<g$^yBPXrp_oBKFqwsega*k_M5aNLRCC8!0g2-EPrZJ2lHJId4qJn=+ny1
zo<6PO?+?ppsZR;QCd>8oYd;@8)TZB;pzE42{+3#~W*?jS=6~sHp^0?+a|Z0sG$F&&
z|No`+|B|R*lTXU0^+~)|?^vk+lR$IJb=aiduJ>MDhn;HnvH2>;)@Qf!NdLLTG8!`6
z0Q;O`-RQMq#h#avl}TYDKn1x@S(!$ObHjYLC#dIaYjz*myZ6{rcSgG+Lvi*)77WPl
zp-~9T3+2!7&-lmu+0aN=^qo%~+q?J3?lm@r*`gM9D=+W9ATq`k%z3bTlz4H)L@wxF
zUfykCl+c$0fK#z06(`W^wic{S3@X@`#tO_x6(hv_Qpn)hfPD|Elmd(p^0go$@zy~@
zmN@w$%v{54J7-SY9m$3xmTz0suIV$LjN;pIe}(gws=-SgY^4JQRFfkHEx&aL!enRM
zy?H98;AxvSPDiY4)w0_LJB01UOx*IW12-}CUKJC=Fbn{h7O1dK2p-O!r}Z>#cKWPM
zeXUS)W$L@MGiAYiRo*lfXOw2(F)!$>i7VwkFhp!W>@knG#cbOvkiJ-44Wjmn>0}82
zo7>4*1C%hID3*S};VaM?0y?wI`~sbQzR-NHeb)XS1G{FXXSI63yvj5gAnN0?`wT8r
zpEWKRqBp^7FAh4dYw^JgEifOv{s#{{6Rr<Zb-RGu4K&EMM_;grppNoV@F5ocEpWIx
z|9!n7K^;wy=4*AF$p!OOFhSUsY=QxqmzpSe;Zv-Z(GOl(@P!pf`hq%|P|R0;yNQYU
zDo56aDk2?pYZtaI$-7*Ps0(z72L`P+4c`mt0E)iIYVPof9y69$?5j?lc#0kl$P>#t
zvu_>Re+HM745nX(Bsv$$S|TRJ<tn>zSm~BFLx!|zJqT`QqMOFq7sfcN)%PAegu*eT
z(g(U+b4S(C6)T1gyPdse(rLbW;j66b_S=RIU3rIg5C{l@<th&fp0PgD%lW`s*DHVC
zEA?D`8rQ_bd{sKuQn(yJ0;V=F^bPixW1xL?4VSGKy(?^Cgi~PoZ*+whyt3Gp5`*(j
zev3_ZvBH>?lo*y9$-0{`%~yG?%PAFTZ#Z45v>p|$Hm0w*Dr`LhUQaO*;TM5ALRlQi
zKPHff`c95z;VdL3#Z?!!H7zJz+X(Z2z3OsmZ%74B_bVRYCf%i$Y@BM3P;rW3(YFhl
zc*^CGpQD7?$)}Qm(tZJP84~*0d@0^)-Lprv+NA}bhsG$sXGk$NDdYD9gx4F|-h5RD
zgsGE1l+}3a(PL_yqI@)24U2DbIV$RM6GeN>gPlh{(JzsRWXz^h%M9>lkV~Lm!6|Dy
zv$RH8RyHm)AwHCiS6PM$+I;16_~-mH`G~_28Y)eRiP7!}Ib;HsirLRRn)FhTK0d5v
z7?qtZ!z~jLZ@R#;T3~_UP>g80G*%Fg>^OV#0*Vi89#n|(Oog_b!U8?&l!6^Sii9{T
z4lFNdF2XR?phE9wI0X*Tg~gQVQyhrLM)01hA9`r!-V~{i6&Hr(#>dW>mKjpeG_^8j
zW>Qdto;`<^<)r5Dn{9<-huu1_s(<q)Ic}Di+pce}WQ|JXGaql>amb?EhP7#u5tO?%
z!<sAC(V*Jp;DKq$4TAW$!8xtk<t8U)7w2_XwWdv?BeK)-`W0|3MlO&g1Z>F#{o3@4
zj^hPU$-Ng;RxBuJ+AFIxyP&rkd3#vCb6!Q|+}!)J7;7G;X?S52qh)A;2D4++OPB5q
z32oFgw@0^}rYKwQo%^SV+PlNS>pXbAh^<I|f-!{5C~zp=?<RFa?YquAa5El4YsYVV
zDh#x^fP7W9jE%8PNDOM&szrz7@Z7Pn(e$QuL3Vl)-o@ZuaDxo1V@uPDv1!c)tn0y?
zrVN>{@|Tj-Jn2lI?oA$wlbBSXzst*M@<4+5_7kGKd00v7jveoW*l&qa_@5>lK(nET
ztqY)i@{x}u>VOeVqT(KvRRs&gE}riEldokCo!^#})VxubCfSYJbtr7o?%C;$GBX=D
z&dh8ijWMw{UsZR}s=*CnV;hVbSe_3KH0{u#Bqu{VklDCVRz~AS{G1P-6x-DT^Tl9u
zmeOO2i~XG~W<;Wov&ErV_$MMTFPsmC?fL$3?I!4?=UFbfQ}}P}KkztweM~y<z-+~X
zgj@2w?lxi7!X=5Ib~sLS`LL|RTzN&<3W!n+G+4YU+L$3JP`;KHk}sN+>60+p_R?2;
zHNTAEo*}u43xdPN@Vof9Uyd9gV(%Ar_S$3GNzgj`m>X$e@{of>@dK<ktnu59ONF5O
z;p1|u<EV?jCCCmo$R=+~b3r;JMbzRvOLB7M9M%Xg8?+;Y@#@rH4<AgvC|msaVKN1K
zTl`(@72PYUU{dU<e@tiyOYniR&J}E}nURvB+-(hZCDuHzlqQ;cK^ZPt%8y7)jF9qW
z#1Lv+<6#s734^B=4CqWlu=I2cl$7;@ky0~*T31SIo=*fk<?a*{hSVi7Lc2uGOZbNn
zMOnKP;l`0pVsDM;P|pfFbk1FclIx?%gv)x?M;tO1h(gk9f{(uNuSTUW{QBuN;mfn?
zquT?Yc-+OHA6w0&TSS(H8QW|0Bh6NnC7{c=VSUov9}m+&7j@X6YM_4Bnl6oqZV=Ih
zKZOy#<C1n8r2b9)78?k0A96{;ax)O8wEJDlA{s<T!1asleb1$k3qPC#bL@I?4#3Cj
z!Z{#!Yi4^9t%dWIKZ5=e;{{R{XuQB^sl)rAzv_-0ZFAjwfkqL;yw1oX-udDYXiTXA
z##zu`b-AQ%u6r-wNW<W+Gx|vOCCmMY?->s}u7GM5v1p1`H^NecywTQVG16BNSA`$p
zgP~&$bPY?PT^2c-(dQO<Jb!ucNPDC3^uo{o**ZPk-e}}t{xWN&-%Fc0v{}L6nW_4H
z)@m&0+>KCw30bZ^`QEAy5vjqE8Lz&Y5g8nj+M$Z|V@KF=R$<&9(78#|P6Le3_+H+V
zJ<N*vTYNYl&0lAj5@0VI^Pe5Is2D|oJx8c5YEF%yfl`wGo*(J;DEA4PLF6u&Encs0
zjZ?>~#Db%ftNYV5qCVxUDX6vL(e>;ybshGt@@NLvWz%$DJ7~4(NnIuX7iKqAW(gro
z72{pI_jB?_f5mfAR_*L7<Z|A_#*rrG1I|j*6159Rc)t?@%5t?$!pnT~XQc00x#SS3
zk*+66Gry*N$3F@~NrS&m=(2&lPA^U*rzS>*-^~$gW`mh~Xlg=`Lsr+NXye}`j1KYH
zgax~BOq)v+g0%8$Lhf63I%PHAbU%qIe@S~)WXyi^EaC7m`vc|}#tnZ<S|r@vw_J!w
ze2S0Mc|<zryrqS4dWrW09kB$Ct(Q?S05Gm$5D1Pr+~;x#yF{)*A7-85Sgc7O?<36a
zW<3SlroSo;C4{wIhvjsK_Jj5e4sO(3BM8$nB-X|JNARzTeIodG)5C=ON$oxUCE<>+
z%^0PC|8Ul$C+o-gDy&2=6V5Vmv=+|y@*#q;KkV1W3dTP09-;p}+nbW2-MR}nujV^8
z_+ZQ)dWBH@5BnD@5$t_Q>Mq!O;B}&ezrzdU%<X)R&<V5o6R;&|KGyx6b#!9v_3TOp
znu@L+-Vtyb;;+`{2@iy?Il{d*%5~yfSD9WL-+)t)d;2x;?Seh(E;y}4>@phr4d&pY
z1(b-I(3cc;G04pEAH_W5pK^X6)(%R;@`M_YfK$}Uq-oJlG!D&ZAh(!0!Mh_hW8Mhu
z83_C7LVP4OWOIeES51&2NQk&RW@GxqG3LgUwqHBNzG)0fx`wUbSBe{i+L)`WxgXV6
z!YW7%f?ljqkt;gvw}T{LFKf?UCi(hVJ3lwJOzcc4@%-n18~yb6=+<W-7C_4g1?WpR
z4U((TeWUh1(JBq;sSOhYW^-p^L3efl1Ll|MzI31A``gw}btJDLI&psUZq{Cmq*vK0
zqMwiY2eIR_w!tJ^Rv+a%JbDZL9c!uAx~(g-frd|A0cCFmFfsVvK-0ZpXL|9d3lp|&
zov{vWUdO7hYyHT71OQn*DgbiA-i96r9_<mO(V1quAdgSWqYg=z!$qJX8<J)})6lIW
z{m8F_%rkw~>5@(&AIEPK%5m>_?FZ4<l0!QQsehI}mEzbUA@u_$NHO%OcEur;rf8pQ
zFS0M$4?Jz~y-<h8_K>*GI!s;tn$)41I{Mf1%q9fB#~$kMSx<`(wbSCmU*6(BMJNOL
zFJEf6f61dD?se(ZEqimAi^<ASY+57r2zijXX2*0dJHl85(`WoyVsJO(JwR974cf;-
zxcm3gMhb%OqEDsf><EPWhlWx%eX8v%mmW=A&G)q5#iy`ANaT}o1i3z}?QaobHGgnT
z$aWIj$Jz?new|4|w!eN;eBpQGK7b?q8(zU*3{$6V<y(2$scp1AhfRyM=>6D_71oO$
z^_wdeE7-ErBit}*q1aSW$QxwX;^ow7bNBGycrVPuhgsy_o2RB&b6nvK9z4XqV-d$6
zZV;Z+C_d)!=*i7{yId6olSUnLG)yRZZrYL-O_oo8riCwD5tEsdNdWX!2Z40tdTdrG
z3tAmH`0ro+@a&;%fC*0O`xINq%OC3D%CY7gIR5kZOr_lajLcb6zi>7RcP$_BdTDv}
zyh#lm-%PnFGn4w1#?V=VPDHtqopw!1u~B1uDNkpI9Spcm^1mP^+51+ly3C(-He&2O
zrmmWKRi5yt8^+ll9y+dMip$lpV#g|9oU@Gi{2E+>7SO*z#V~0S0wasAhj|Wu;?LDX
zDw5@Ro6DLw;7%sL%UHv!u#`XUn$l)$)gv*n4MVb5j^9zyQSex|KVCHBQ%v?<MVhX2
zg1;`2yY`&V`dm#a`78BL{uDb!w$+Q+%jzQ5`q$`->m=-2Vts9z5a?H*;JY`~OAw9w
zH!vQ~kYssBL!P(t4oMIqT+Ic7&;;J)V{Kh9Z}rj8)CSVQ``>dqzu$G7uJ_Cwa}~Xi
z6Qg~V>I@E&!m!65CuP$$S7OuZ(G@zb;`}~XS*9wkS7&5+R$Z{LpgjKb4}sq9kM;%9
zASZr|Jwg~Cc>WF2BZ=CVgbn*6XL2BYB1=j1v35BQGB4`%fRAe_ml}NZR0z-=J5-to
zZgf$l#Hk&+eEj+6k6)I0W5??FrER-*ZM!6OLxjN2J-`3H2USScZhG&%O>6zz6uTX|
z>j>e-VynV<N4f~DX@}qx>ZZ4*9mjQVK#{umG)MqU9jLDh#hD^Hwk9iulK}lI>aRiH
zqofaQt)LPXO7D?jOLW-Pb)X{AzKB*~bI#v+H{i2Oy}%M&vA^-n;o+c&uX6*R<%^GF
z!NvE9MPg~g2e-ZhoV;a~+(}IS1{6PY=WUpJNI(1FMpXM(A}Ywju7ydtDU_HSL<u4k
z^erwD+_<7g>HUd$DV|M9P1QM)@4SUpS@X{=TUj}O)?WVLN5D_;$Qz6&e<izIDjO))
zg+~kS-SXOjRkt>Dqf<=Yk<XU;8GB||>uG3V15d%NfPHRy8Ef~wpKs9z-qobQ7hZkx
zV8W{-7d2;fXR2Xis@<_dhb|`{cr72GAs{6li%yqtAt2<Z&vwF#=_@G?_v;NpQyR*d
z{CD(*tLm9Ki-F#UC3LSDs$e+zIeu@G#*i1tRO{CLWV?fRJ&KN*Hhvoxz_U~GgMtU)
zIJlCH51fJIY)#D%4#qC8I}`r=u&>lO$j%eDFNR9EHtu?V_y~|`l|q2XwrR+KI~CzW
zMJFLi4)+TN?!wd1hi?E0>)F`;19gEKJ-iE%(dCg5<3Q8OKFEcy99VG&e_{;q_dy=M
zSNToUMom9O*q`pU@~*ug<wH4h(}G#;-F>{W1-n|vma$7>))}d-MX0Z9^^5Q-kt6vk
z(x#m~7#`8UR>hk_KeRnS*F)Ibh(-0+JdnN>Aq`_A;3!!U+yJj0-kP{wOAhPDtzOBj
z2e&|yS_?VaThi+_Ai-E*Mr`w|VSutSqKmOQs$1_@xZ_Z$EnuAk?aeJMtvNX9R*8*F
z?p=0oZ1JQAQly}eOqaFzQK>n$k^+=L*tqCDyETKA%pBUMYe<yMe#6lj5lIOdR{Mop
zXkSXVkqn$ud}Db1vDV*_`RNqJm-325@g-PvqV^K4uBh}<LXarE1OZ0nrMh(*o@)~o
z$*VI;>`p0zS4T#bq%tS}Ahjeal36p_B;`sO%o-WhCXIi<oN0lmp`s4%f42)g#rG9v
z+ga~Zq3v=b)~t!h#VyvqFguAK!mXUhHESX<2F<=m(a)<QNvPc$9=iN1a)A`8_EMJu
z9O-=&J9VfJ!g_$=JskC6scrN97M}8%Lp}9j(9QaAqRKL!nqiKb&B|1a1cy?JzwSi8
zIo<Ot9yJcwYaWkrRx=6pM5flD-kx%wlj`@$-{@s9g)VwPjAfh0A|SFokbSkasg-pc
z%y(W~_)O1UUY$05G4gG*7H&pmG!Kr|Lv?-6EVp2j{C(6q(P>0Y5u;NCuFCu11$gdM
zBB{=uQc;7_G0H7Mguz??XQ5s7L1&Dl_Z>CAz^akacl0ctLIs{m{aMx0^vV!xs9J#d
zsAxp!C5u=@6yT&%oAg)Cvp8)zHme1N`fWuPX3I*jSVOVZ@Ctr<VsoJ-evXWb;yeGS
z{Dbd|Qlqu4f3PZTxVANlRbf-Y=UaH{zxXUl+bWF^4~XyZ`=k+glGgcNTw+AdlP?~U
zz(&oAq1ONyM5F2s?YOSNS-d!6mCa!?e&*E00C5T<u-v{<$*=IOYy{;Bdg0m-qm^c%
zyi_094)P>2Rn!D>FtWT<>?Ia7uZsmgbL`JQkFkBy>aDzz?c1ug<&|5v%J=e0UWrd?
zBXeLYzSjEBWBSKzA3fZf?ZYz=dp~}}irPT_IH8N;?5I>Es-p(Rh5y1=Y*lXB>YjY;
zPt=`QR2Kohg8xDo|9Q+kc`I8~8?L=JFJvDad}B82!XHab69Q}zKm#~0oYAMx4En8&
z27g6-?(=>9dovIZ;O!g2g<_d~FsKh3-}-acgW1L%bLZ}$-?5X+%O}(CwNca`*fCfC
z{$&6DvWq$)^<YZtyX&7xt_T1B{++qyTBKE8-xO1;Z}gbbdMFMQV|yKREq1t@BckL@
z%zOIlwNPi5piVjLB??IJ)h875TCe1IvHLqXT@x3I$EWe6S|(n(TRpGTK*vVGcWtM!
ztcq2MJ`>5%^*Q*3auu)Yc}Mk^h;>bMRBA8dzw)AZfnlzqV6OIn)LMIqezlv;E70l>
zqfYzOwokh?ZIl;l+W57ow<h@J+ZIM#ZCr)?nzgvh%^?xS3EKyn(H~BQD=Lat@xf8i
zu28m{4-9qT9OPYWXN1ia$_KLDp#~N;5z0$7t+%+M*iK#*<%$i(mv)DuW-}kmc15^s
z_%a_%XQBJk8i1F+ddUwL=^ZnC*$<{P#tf6jT#CFwWd`clAv}^+U6{)~(`j>MhQqxG
zz3P%zIHZ?d+G_L&s@H0({GTKKVEz_+sbVHpW?=fh1(JN5n1ZEwScuOT6R?1%zO455
zhi5KWU-pzIRf8RBLst!Ee+9=C>hR3x0M7>)nNu%2sxM<{Q3W`|U=E>R-zS*$X<8%t
zq($}6CoOVNT{_rycL$<RJZBHU7g}!utncG!h#IlDc!ka+4$m_`N8`cE<Eymg%W5#4
z7#^rC*tw9;N<mL@0L*BsK(~faGf)$(kUnxCvIYPAdQdCY(G>E9Hm$piHsK7ZBM07A
zy;s&<4h>con*G3m#7O+(>&07NIWeJBpE96%@z*s}ZHY5D>jmRW1_<&JQ=2;)Hwgm2
zue4BhgPv@nB?xP3YS!E^@e^^{B~f-q@z=jZIMeq$Lqs&bru`r&DP`pd)=-;ACu^{;
z-Op1PhMeRb1yV<B%h4Lugy*s##~ct1=amsi7!WYIkQjsrz+af<aBMxw1_6Twe51f%
z5FaTpIQ$V1;E!pG*jt1K-$ycq`n@X%6{*rIYiyB|heO=-cove69N>cRTk1<X`4km&
zO;?+4EEkv?MDUt;gofqBQ?1F^A6>4kgb2t!C71vXv6H48rEP#H@i8AdoxS*fM2O=?
zr7x)kFa#N~+BasmYej#7KNREGLda|bL}0WO@j}2VC=ga2_n*FC0SA4M%d!;&2?Vvr
zpp{GnSu<i%)C;U97<k7~si}$PU7Yu7l7?Y)u{Nf>H~0lib$*(Xqq+IHN^<eSH+`=<
zPWgkfR`hcmgew}}PlvgckgEr6>v2uw!l9x(>bRi;=H%!1Z&${b@c;61_-vkLQEYix
zyZ-t4a|R6k=CQB8e(ak^X7}orpWn1a-_x@yusJpBbl(<D^Ygp)n*H>GehnJ*TLAd)
z0RB21KFH5hsTLLNZ(<njOJQThbeD>I<Q!EM;ep}h0KCK>potV)4rHFD6LRVTecA^p
zU8Z+m`3*SStJm-sGoZeq3c1CJ3ACGtTA?#i;*|SQE3~raa*{)mToK91AyPxhQS-fg
zo+pX1;nxn0M%tVw5kv?mN`I>BVrnKT;VxIWqHIiDU2|FLk{qI4kWeqvA!+Z2C9|*H
z5Mzq9q%|nvlW44LeRrI_OVB#Fnd{oxI9B6aN*9}@BU-2ZTA2E@UmIt${kpijsq(2j
zRHuOSL~~{ddQ)DDwH|yi`mF8DqRldND)@>s<3v87>XVTZ^yaA*i=K(rZjOFt(TY>g
z-?8x7C~0lfvkUKdzWU(}W5?We*O;*zq%JGYJic(@<7ZafaeDiL1=~;GF?Pe<W5(RQ
z;cvk7T|v|jvy#9O*t#GAZY;oxJ|7D@9|oN^syS=YDa->wpC7D;1${Mh;LBJe=&A+7
z<syR2))mXWS5B*2m4EofOB+)j={f<Wx$3#1NIiW*lsgNRI?TagRIra6TB>=qN__AS
zao3?yY%%@Q=HmuV?!|bV&xgu2@>sJH5M~hJUBbDs0Eaz`=5mcIfuFv?j^bC0pK0G9
zURK-7DGAP+<M!N!sLR@|XB?fgt=n2BM7%Q16Eqgg!sx=D^op4>L*fm?Q<6itOK~NJ
zLXjLmtc}AB>q0)@Q11>`+>WFe`SajlSDbsgye6fZ3>hC7Av*6(j*wkv=0BOKHe_??
z?YR)TP{GSX6I}{>KO{LNoV_QhccVeHnj)`pPmgm22g{$wB)J{R)nL@6$O|J7Jpu;r
zQHL17cocRH)n$&s`oXi`p-)|kC6?+U!%^d{(2P@j*2wIIPTCVP-}SqvShMz=#OLz=
z{K|&P+I}IM3t;Q4v_@LOu{P1$r7#ggt65jNs!N?Q>Pc&~tFrn7xUFn4>T_0S^%T`v
z{Q;gQ+d}vG#)x%-ho{s6G@4nWHz_O?!G2-M{uO$Il)XlQUcYusN$|-JGs^QKsQyP+
zY8d-kug?2es9G}=)p_?>QJnXHQjr9FR`TiAEY#;0BaJkPUvXZ%jV><A%CslgtXXYr
znMV%&_1B>zxcKN@mdnyFT;z{6&$1~;{@lHD=k7mideWQIEbEms=U(Ms3VMCpj}EeC
zWjgbc7-=id5k`PWZ>?DuFCYc$<99#Gw6)RU-~va^fBEXUGq12L<upv@nw~l&<p|!0
z{%C6XN%~ZN1R6fbVhNFBok4c#Q~o4>k_~zd|FG)B6~a!Q#2ey&Q?`mdB`a848k$8{
zo$M*Ev&D3#2>eG{x~b91N$3kp2#dvkmX*TPXuf_O$Im*xp1rnyy&S@S<-J%0{}tgR
z5$rI>30O4eSm13{<^fi*e(op6tD&k%*U(`TzN1Q4K1OJ(xjw|si0}GLURTznNm-}H
zjZxdp!4ufl(1yq`FXAo3q8o&<$9N)?&NqByScB*=_6mC~G^$}JAA#&oZlP!BS;b1L
zHx$=G_A?(58hJw~dkv4%15jP;QEG^{#G^Mv;!#RY7P-ryhc&VcRzsB*&|}^?RA1MM
z30X%O6KD?RxKQsh*1LeM<Xh(OElZvHn$;<9aOkU5hx<M0MZSfN){y8VdEg|IR0`Xn
z4ivF)4yg~0zEIZQ=UbK;>tio0b7jm9>ENyc&piFZsCg~y79YB5FV8`pNm}jYxIv&k
z{t<_<&XV9i{*7}+NCzN=H7-nhOnW3O))gv^*B(SI^)S^ErnthT&Dzv(6oQxTlO9Ci
zL3s83I9WpIf`DxrCOWwoeA`4@ajr1!L20~io9aZW{;rMJCZSE5Yy4^}k>z-eDq`Nr
z=Wo<$kS^9&pFw+yCL}QicVD@nPE;P#tsXtnN}{1t7%fv26jcp|_Jjo;8>0t&sT1?&
z_o!?)r<=<)sBr4&qtW(8iG^q9EosvA?NQ5J5sj32Io8+)O-CN#xtFm!vz^85nl&L!
zwu7ZN?0JS?X15-!OhTD`@YaM4X8^1M;zFJ*nXz7aR7s4OR^nm^19f7fxRxhpt|(}>
zV&>^qag7peN5)Jo#6EDhIn%$)Q(O@@Jn}4y<=>xp<c0`Wbb_2dan?>2!*-&EJkL9_
z+hHZ%?*=T-eyXrabhF*qhVe#a&{@-lNnhtP^){#W-m=jXCyrhwHN+nErBOZm_U$=J
z%6Ep=7s|o9=T!_?vSdI-US8|=!-uzT%}><YVx|75gCF+F47;gLga=kO^?p`w^ap<t
zIBST+k@9t%wM)2e2wLjws{ZbSY#xx;@iXVx6pGiUUh|*S@Qyanv3CyM*85rAYV`a|
zM_%VPeR{X;oR?QsIdev3RXz3T-9G@|#XTE2^BeWha2A}jbZV!zZ97dB<I1yt3fwSr
z3ri3f`A>*=ceT&tb5)fyW>!|^<#le`yHA_Wc@CCZyUx9oG_|Z<yRxa$Qgr_9JsRaZ
z8}*bHJDu(y>aBk-_=a<x;g;}l%}JJDp$(x*n6L%6FvMuQrBTX`sM&w_E$}PsUkrP1
z&pmItTyNg9NAP9q*a6}0<aX`ke}@kkyH&5>e|q7R@N;e3o(rG6@QmJ9Gm!_h0WrA+
zdTvESrb98jEC7g9bDQxZn56I0*}x&h_uz#*!SaT-W8m6A?%>3h?MBltW-^?hFs5zW
zF=N{P!e2xZsg{7l6Ta2|;!|W(O5eiikf8s?(`Q*bkx&Zx7BQvwV&1M*X+-4hc-OJI
z_jZWsByCYQJXz{uxJtD>fkKjLEE%w<%7tmu!=g0Z#8BO|STL-HKrzwo0uz4V3@neY
z7WT-MKSIYDd1xiZ%vzfo^l|MhK%w_)eJ^xeU19@erv<uqy%}qWeXg6uChRJIIt=@_
z7T0u7fj=kf-U}U9H_ALvc3Yr(f%zRE9vv~x0kYu8XQ0QU$HLBOM!jE`_n77k-HL))
zh9}TRHr6?<AvM#HUAxg51e^XVB_+x9C#2L&53xFvl$4sUl3YPnWn+q**+^!$hNP#5
zuv;ZpMlgSZKN0)~EmfDLhwxkFMybJU2pbZdfv~q*Lxj(y7JhXx@J{+PZtF-6V)$!g
zVd7U8bLEi$XlQGIpj!!mxiJ?RxyXUmtF>g-8#Pf^c9m(gTAdI`;xI<*gHe|sUKn-d
zO2BZh4<rnR9)RwR(<|>HT-_=<o{plUv$OQ1K{9vpkU2<hih$wm%I=w~c+GqKN+T!h
ze0fz>U%QN;Xc5kR&6s!f(G9B*3hi=DDH%8PVOw1FkgJ6oo4N})Cz$cwPQ<;FsY1Re
z@smY`Vy+QttgdUwue{5(I|n3MDNs7OV#w-0Sr>R?uO2clFQh>8@hh_t^A+<*)z~&u
z5Y}B^EHQ)yww&+*p0V`Qb)U{moCkoocrqvT_vGd-rsAr?sH77a=t2Y%2cg2h_@T*%
zY{1%K#A9#DV+reL>cR7izVB(xZWdJj#2II!vwI!8e!<*(urJ-}J#Oe#LW|R4w2G%z
zZ4lw~cXr{CIZaqip39Z@Tb#>fmlAWDaAr%X9cNtVOJ7%Amxwsy;#i6@_D0kf$La<&
zkwwJ#rYfkks}O`^Np-g{okIb6{_&ikqsxJDo(TJ8-!(}8_W3}u$Y)rxAhGX(=NyjL
z4m(f(vmuLdwc_ER;`Opwo{;+oD_E?OF}rSn^4x4GA*YG<qYVdMajviN&Dh#z;w&?0
zM6#N^Iq6i=69!b485Jqe&oXk;X$t`RB%s6nej&yEHss%8joe}!p8!`_$F>w$TY%!7
z{7b%BS_OlkYMdPA;1jf9wsx~iWUXTRk;PMh)e{t43w`8Hgt_pY+DC+2(Ks+-f3Jcc
z&||tH_ra2sCnZ|ia^MfIgWou;OrBv=-8lGDF4OTuG^aL<@T>fZZ}!Db58=}BbJRTV
zKpM*g`5P~OJ+Pkm8U9r4FFC}FLj0m$rhQ04L(hLQv;6gJCp{|D)YnFom-Z3=D%qBo
z{}@Mzfi#SzCP(Kvx3c>j>pU@Ni2K?e<+9s{;n1ZhSAzXUv1Z_PZ~zLPsI;r&P%A2|
zUL00q$5O<yAx^9|3h1ZVm~Zv`(r$rgTTj-5G1H1jCX63_u!uFLv8GlrNDNhgt&BP)
zE-3F|*o`eG@aG~>#())XzQvmidE<?(#<Nno&tJc1k(u>afBtDv=0L86HjIh5Jljly
zEX*3fq>u(N5r5vS7vZc!Tiu!If26JMH1_vtt3Oxu@6bkhIYab*(>3)~rosP_*z3;I
z`I~)vwY;4|kz{;5jKCab_A}-23>3V$#^m}xGU94;?+;9I{4X+4@7yf%e6EiHw1#Pc
zT>Qb7Oh^OPsnBK~A9^thkccnaR2D0;7ef^-i+?Ki$J6-(DRI&>pU}qdHg+TJK*G)c
z(_LI)+1Q9=!+5CJm;QM-?MSljY^m7p{d$MKHF<*Pu}6Ns6aC?fPmZ2tTdP_Dt?cz9
z^I$SCQKul5*&Nun)H-}f$UMq->-(3|M=YBV!r8LZkT3bs#~ZZ?Yz6IS@<V*3z$bQ_
zzOl)7vOfhzQBQ>>--%O1A7icEO^*wFjJb$Tv4>HBwVP+QBrS%c$OAA5+84IFn2K-?
z0CCIVUebYP%c7G`=SQFLHelD2x6@oXk=+4yVe?j7a$X+msN~b1>7)I|X3cdSq)eH6
zu&f?_QE;szn<A1?zBmr9?E+VuYUgOb^m%akwLkZZ^~Ew#=b<rHKY?)-(~@AJCnHK6
zIcd}<&^hUc>tp;rgPqeKBzzxcA0)<TC5M3PYQAXeAnj!~--|0dy2s$?hfK_#yz*aR
z=yIIIlPC{8#yg>ILAbl=AzEw5mM^d5v6s|w@C)d1o<1vc--?jF*X$+pBn<P_T&*j=
z8wXryxt<H3wfdLry`WU-SRhz_9swU5f>KQw+5qpB2~X-`fHBWu5htqP_!kdtL8*ah
z^WA^&y}mlUYteTl@9)B6FO@ZJ)QL`lk@k46h(6k((BU;I>!@WDq2fZ{=|EvsJ<shp
z@<4Q*L0(gFT53TSW^o_iscsY*Id8`u{KH?KK5pYUAe1$=9e?^4mIq7mUpVv~_3<3;
zQ#hlZWy0pT@1gHpuJ0bY&*fUW`URKkh1E;JQ~^`j4Vd|c)m6ufn?*|t;a5YZhYnQP
z?cken<UJ0fN1a3me~^G7Fb!7cP69U`;2wXn8b{6xV1L45J?nJ-u7lKJ%Ad;*Q_V_Y
z>G{J%x`;2xbOzGp&mH_D93ziI=9vQ!Kf)pN5|x5=Y147cJnqq%@-G=@%s-27w01h5
z*=YFh;Hy@4!+#e>wxzFh1om6|@>kwy$|g$;K=ev*c!5r``kpZ|s`Gq_*EtRQn{ZHn
z#U33ZZUkHqsoS-6z2m+ZfZ1;3fXjzLR2`=K!pG^XuIi$CV9TE?uK_kTE3OI~ycZU?
z$#g9a2K4vD@Y>8jg--3LvtHQ>$TcH;I>6-u>uJsLfRHT_M;xH1;ji_jl<aF-$RbZA
zkbwEnYI4L+%mk;6d=9T%gW>>?6@yL+{MS)PPy)c+yq$mFP9BX;zAZdlMwW$pOFI^~
z9YXJgybC7*6}D_y=yI*w<v)gr(`1+%L}BAWzoL_6jeGDwAf^dp_&kkV{vpP2CI*um
z+?6{*uK2%jCy&NAYf5>ue&bh+=~`o0c;tNmiY+LboYGj9A6#WOMlVNt4I57Yks6C-
zNfm*75cj5HbW2^#0gU8Ashz{|Ck8OlZR!nk4Ew??D$eo+i8FmXl**rD^m42enFFI&
zn@$j=jSwOI9t4cNX$;_Ju=;(;;dplA85-7rca`yTEe0#Qo$g*>=V7NG!3%I}r7yWE
zjURVElV%}Jf?5GP@c8k<2Hiq*{Rwtzad7B=@AM-aT3I^fOSTw4nqtsSV@FV}&j+Kh
z4~vW`A;ZFhV6KRbg|RxyS#u8pi>5f8HD{Gvgam)Av_sG;MKMD=9>MQnvI}NksYVUP
z1MuQHbS)S~Tl*H+RQl4fJvkyRumfrBufn5b!O+k%QJUk_m9W#d@JIi;eCV0zNLT3T
zg>2MczZ^Xt9fci<`!2lC-<%-tp5*@Rfp;&m=E}<0&?mOP`WJuXz_!SSwvb)h-uR1+
z!u8kp@VDMSw1O4yU8N1&#K>)e@iNu&Y;c_NF69P+Mp$^dohKZ0c5(bPwwr_FT+yNK
z`>|u~9uSU8c_J?5J>ma$h03?OA99Au=fbfO?OrC2b%wf2!m(ejz^)vuPDEs8h{fV!
zwh$)c*QO4xc}j9g4M$Ntg7lX(L%Um>D9w;8+@c|{i&@snzbaj=&GnrQ;6uwe3}Rvu
zO1TynVfU8S*w{#oSGw9IW%05lojWgCzF3j$QBVDvB*(?dNxwc7rKmAd%BbNt%^Wc*
zMT%(@spc{3{+O8kygE;f6ma+=rK{zHelmKH72CB0OmgM{ide)a;6y;-hf%tUhGXMI
z!vu0UKwcq;i_k8wrgoVX?KUEqBWB)o3Lt6BjIg|`%u(`d>wS^+cs07_baKz?)Jb07
zsd4=T%2#N(JbzUxN$vy=>T%!@t7k2m3c;)GuOFZ5z)Ph#ZBYjFTF5cWSw2#lXicOH
zB&xGxPcVwt3VTHCVCZ{X?ZxIjK8!-LzMc;uO$_I+t-|?tTf)Ox5r576i*lsVt5{Ju
zKE>akV#4{`tD>W4JDnpR4v&oqXH8hs@R(S7Z4w?E8~)I6r*oz)dL@6G-to8biu1e1
zV!v@D?3D-z3g!?R5&F=VM>;sdf}QMu!<y#0JkLQVyX)hqA<l$%dY-}e4ZRyLK^gEx
z(7J~loQ{HDO=*;MU<d#rN0eYx;2E}p5(o67<L3o}p#z|~1uz^OwPD!`fSLle6SP{y
z6wa1r%WI&&>e8{sp^X3@(wh!-tV<h#`Q=T64*zF-=#b&m)J8yezUh!2!~-xoC~gt^
z!SWjEM}naW`#~TCkD&}0&4G)w)u8~=TX0Jb5A=QV@DUCA_Z`%3Fg>=-2{W9r49ih<
zo%BIn8jz#v4x>cUY^QX<#ruQ&4+IU8<x`d~H<sr^`h(B}9Eg++BsbO$NEKuFT$V3Y
z@K|;ypNkJIy(L+_q=sU2P+ucl#F9lxfaaBYDJPe&<$vI3ZB8zGgyrMs5vfaA84G1M
z(<ivfM*+UE81KEMG|^TlWt{4Eo@g#84|*Qio|igRW3_0s(Jh*9ymEzajD}g^(wn&A
zW<&TBZgjR}xl2k=?^A;jL1?G8kOKsjTwIikTmpN7GcPwMTY;<KzGm89ZErJmFdO{V
zTWs)Pb#Q-vao;|EvA=YKJT%eHzr_xGVsO}VpMLsWnC-!*pMH>QBuf(74VAaZ2e6lv
zN$r#NGaQ-(2s##JCol`aKqD`vyycBeH&^k?8L>{JR1bV()227ZY??fI)8<K&HcJ(o
z-sp&roU!<5^omVyys>HW=FO8QZQcx#z-+fp8LGShDpKK($`jUiP9zJ8&naxooG5t?
zEn8R+kHdEhvTy^p@u8X%-;Sw;Iq6IpdNShRf{OVEB2JzRKd_);!NG`={GZ|TDk>`G
zgtOl+^qI%MeLG@~bnAls;ipbT?4Mt`;6TK)&xX@8VHYmoi<RfY<}N$mXAWr2v#eEy
z1D6yryW{{?7Jh+)D7{_~p9MsyFgy92ZOZU(D|uPv5BOKfPF8;V?YI0zUdHBqhkupq
zxytYHuM*w)9Pfm1PsEH*R^}@2K$o>fo?>@Pe`sEvub5GCaGtroL0`fOJv;TN0<Uu#
zpEhLiV7V+<j{D7vP_o@*KOTukyf(ff`oe)0jBZipE~~0q=B7W(s#dL{zkY8k`?hS=
zXI0C-T6smwmVGN)vG?85$ck30=$%%M5Bj!jS;0Ej^R(WWG?<=TRZ$_n-l`8j=yrc3
zTJ76XG}IUJgmDVlU#E01$EjDJQ7-wX7|`<XlomjP)WQ3c3<g<7U3p8bfsLU1N^Y}!
zXVF+F8mlkk(f5Ay!WIot__esmnHS}KZ9>)F<L%ZUXI>Dh6nI~8H?9O@A;@Y^Xz%+P
zhsyid<3e@#q9)Ay>ddhQq4J8g3ED7U$*^t<SV2~29?Uho0x~^}<LL987(hiOXu+9R
zT$JJSO2d{Wtpr$h_5@gco>!O|Rws^`Mq&pwO|R&9N1l^Tv$rDwqp*cqgF3SB;b%B|
zoHbw#*|sixB@%#t<#(_JA_aIs62F(b@pCVmg5+$4O^yf)bIN5|A*wYbtNX$@H6%oh
zTeO~qhOxUA>F*YH&kC`sA=#Z|XQ1!i#lk|_djIccmB|ygOF8QlNmkZ5JNA`TMXD_A
zrK-J3D<wsh`!>#!lV&BVi3tfQNlGl+t}v!-mvYzB1MBljE5!o^B?|K9N(%HxIy%=W
zvZSobk?7lpHcq$3r{zV5mfbOE?V>07g?Q`qjWNYXne-692>Q3_^b<co_yU6sE5U{c
zq^RE`sF&GPeh>d8H0-WLu|#+5!fx3isv45jNy-lm&6hfXE1<jk0{zp)>%&6DH$$zl
z#1qvT>iuRYI0XL1T0_y!qPsw7Us)ld^K_bW*$ze7!9XEsSfA2Bii(butr2NyS&>rn
zLRBsASSh{_Dpkxe>r#VCih6eH)U&80D0Q7GOBfd&!3RaI>{za<>P_1tCfuuLIzn2H
znX>!QdnZI}zp1EMdPhZpdL}(OmJd_@4ZAo8e$WB1+TlG?<FYb^O{|C13DY$z6J`>b
z%aqOo8<{G;=%tO6g66rgP%6T>YRB3#E8?uh0i+PlNIK~NRp<~&APZ}onh2t>NnwCP
zF2&cyZWaU{+8T{3|JF`vr!rHI@7;GIC0*($bxcn=v2XA3)Xb3=maSX2>;h}CcQ0#^
zRd9O$-ZKS9`4N8PXu+Ai`%f3NTgJ***|K(by2?vSb6Z4*Sc8JBA?ZCzOUqrSj~{2j
zJNQ@ps~xtHF>8u?B_t;|oVF%r<e^`F8M>rr$Cr*LryM!mrT6B_Pd=&K+`G%^BPq$p
zU+UO%iF&a#BPJ%Jv{6Mxb#$-kb6-AO()#dgll#rR>882;Cck#Lb;;qE=T7g{+u66T
zQ+1T}@7%@NC8I-g{Oi!BqD$xgWeaQ8^y}B5O<32IW(gfTHZ1NMhDc+mBa6RH<ZBQ9
zzhXzp7K_$NZ5A{Uvv3-%c}y=H#V$}^C$St`3xvkv^jkX>t!&n&Y2%XNrDNx{&WKHT
zKQ*iEwEs-$H=_D2wVC{I(~`E0hldwFIppv={0H}TDd9gXiS^jQ8WgpYC;a{~@yrV^
z9dm6a>2#7ST4ISQkMtpxA&QNGL>6MgWpYYs_Rs~dOs%}Jb>nHHOUJM5Sd<(qz3=`?
zZKnL2zt7u#bMLD~?ItvCJ#lnc;r5kmHA{OSXHAaOQ2=CsuvlF#+fZ!-v=JO<UY6MR
zf+Z({7=+=ZE>8*zPAd9<Z{nLiNG=QxOHyZ_Jn_yuY~E~@ZL)`EwfpF!%=V%7;NYi5
zk39Pnh4-TW{n|#Dl-@i!Nog3+pb?Aq<?3v{`ki-9oSd!dP}np!O@|^?qs6l$M?V!D
z>;Xb;%UFTFrEXIiiS=0vfxEGA(5-3m#xVpjX46pAM`qoHu)3`~U)a4nyQ90-)Vz|~
zr(!l(q;=_f%d$mGky2y!{5MHXvdc;T-4iQcX{`TqKVz3to|`%I#t|uu*&D@J^O(FZ
zAz>fa@~l|GVjYk9SgjQJAuC+BX}x|^X5eb4+Dw(*`Dq~0p?i0}t$7S)q@VGwyjct?
zpk{R!5Z$bCdwFBy#_ioW6%n*!TOru3HWpP<T2bzV@YP{8kVP@>@o^}CZOd{Rdv`RC
z3M04(Y!_(+#!?X0Q}CzS%Q;Ea(M3h-&vu8@Dt)T<PIXW9SWRL!@5no5C)(1p*(qG4
z+Y)iXPKi6bBQDaVVR*Jkd9g*F_DXtcYO2(@W~Wl`xADB$qTYX?!TJbjpgIHv!iNH$
z2ojJAkY#gR2lm!STIi^^m|VS3dCm)=UMz}=2;mkrGnK0AM>frJ#}zF&QlYFQIxUUz
zP5M}dS|%Wlf2n1S<vz>fmi?AzEiYRxSpErH>`#~zQK%)1f?=#Z>xm4RF+?Br5oG|;
zjtJ%#8_d)!*rPVsrde1hkgQ@-Dq+pz?LOBIpKIUy^<4{@57171-}k-$cc1;c-xnj3
z+(htP|J`Tn<3o@Se}W_D^s5f;H)l>i^>V*CV@q7s!LE`LmwMS%@_lw$HvZ4oU-){z
zx6A$BX`B7t`hRG=(_*gjovSv$7H7NP%FdRXWxErv(nc)|4ZP10ZPHTut1Xk35^>rx
z{FR1eXSdAGJ|X`0@VVCS=zm%7dOk2dK3~tr|Lb#g@xZ`mme1ht*#&<OGW^7RgTy*L
z?1x#TU9Qv+4$Cwo)y3Db*>K||$zRH<{CScq#NFHt&ns*SJl_h>i<%hv%A4uQc`QL{
z#qSJBN8&Kb9Uu_*W*kHj;?7QT$@07SaV5E3Y9Rdy|1I_`g`WVZKscd*LL?D@F4muV
zZe{>I8tg8rj<%EjOP5;aCaFIcO|I^)y(=|VlcDWMNygYcYOj`3vd5&iXptwigz8L}
zTICeg%u=efceQsE=XK~Y*tNU)KdoETy~r0!!S0x-%t*dKG8I4xvM`9NG#d!_afskG
zktl9@<DKbS7?;Mf)4C;IYobO)salixc<F7rlHQK5)COyVrCn0H{P0k2iO&xWmn`w|
z+!7v|A1_%#!}CR@NY~E9a6VF&*<;~}a)-ol_Lwa5k>QE%OL8<@&F8s)=JS*r8(LX@
zxV>QzzZ9-jCWP}#K@IKUEFTfpE(t03G&d;leWX|m5lb%%j{~9?LKyXdZU<qVXxJsf
zP>&OzA^#tSi*Aw$+nkIfYazd5II2Pa-hSt>5j}hF?cI>2dM>p%@uBoq{KAQ?+fE)_
z<-kRol5X9WDL2>rlC4B)*?W68@P0oHPY&-T<>;Snz#|9q;@h;JfQv(pge+LRvL*7$
zN7mlTVEAhqQp|<mxfL#~T-^c@7F7&|h+x0MLfDI}FG~;#G28PH%8T90=0(=t%_36m
z{K9Md`Ijwr+?iBhOKK5(h=oY3=;QOOFuH}3`AqWVZAY$H*jFs}(7AI5`7fX5{`dZ;
z+)}d^p|A2^-r70$Tz>DQW)YFB)&BVOk6CN}^;^+$RJ%vt=KRQlhl-bNI`N$t2i+{2
zt#NWY*iaF=x6Jf$v#i1_ug#*o*GX&Lsgv|lC)U2Yh58SE#(Xcwlhb--cfKF5)OXBs
zJM5lI@_CUl%CcC2oE58H;@{M~$P&l6<#}%Tyt^rWH_6lJ`-<gBoG*45zNG~8b*9+o
zMb<rex%35Bk>TWWF>-R*g?~#V%wW}}9@Y*;9GqV<fAE9}gXhD=6)yGG`oMMd&O7AZ
z>QmCAM~Ug+8a!d+#tDPH9xmbCV!wx%^qe%YM;r9rr@(uO@)*2bss-jNwp?h}CCjER
zsTnDc(j<xFw?aFhJf?llmhxp|_%h%xSq@35>Tcx$@tg&A7d^GRCRpyP#Y(BtE!x*?
z9$yW<=<T;4zPOND0~4o!njRy6G+JrlZX&;p?`*dy>T&rYU|<Q63b2|uuFcct+%5%4
zs{D|9l6;?*D}78l5V%sE9(Xu~?xMYCkKdde?>=RBw4JEEf}A03yIFqc0Q$;RQvr-o
zTS=a8)PnMQp>+jlljl3MHt<)!h{{i!{c046eiL<>)E9*PMs=j>JkLNP{rXisqDoI@
zwWogrsVnSVegmJ%O8N8Jhjfj$jT%*+w#5mx!glbn4@K*ya}XXt-?*SU5T$SW78Um{
zZ&_Snz7jnIzfjtujn<;+ud=MDZ{MPp6&3FO#eMr0x9n3<i_RFxDDsHvU{YickyV?n
zdHt!Cx+W(}4Yg;H>E2lyt(^$7*+R8vOxUBOS=!xF7nJiKC3VrB(@rdxX5u?xQdjLR
zfX3MH<#CFUIp$|2o2yYMaX+`S9|z<Ik1bz*?AY>U$Hy)iG-UDOAww1$C{%Y=*H_Py
zUZzi%A3MHm&=UG^aV^;7>Biu$O?MF~F}VeK=&>J*>sVA~#2aM(duxW(v`J#ae)xfn
z?8V={0Dl~7c=27<XjDAk_R|l1dy>hDGHHXh=o?nTPx4PMu*Uq|_uk|0vKx4$bl3O%
z6f5~gTSWS`2S2X<sJ;tnOBea7(H2$rE#^{%NC!=BY1lvoQch7H(n^@AKk}RT7f@4Q
z@SE8hmX1w>G`6;qZ?CCg!?ZzezJm=zCi`dn#^@#O+AXocVV1!%*;d=qwr!V2!)^92
z&Spi|SfXK&+@e}+{4Ti7)(ak8cRfJgBP4yd2d<;W+a>MrVU2#ro?Wx%Ed2sm|3a2^
zDi-PwXovOh(?O05`!vzYugYR*S+N>53l8ZEQL|_^B3OQPXz%Q^rR4{2*M7#PRpb3O
zlqcRH*(i#GXE$*~Cot57X8#o7hi%bx-L_+Ox2&wUE$c={tlsv|+k^AdZ2Po#(6((y
zaDJ+7ztmW?-7X>8(S&`9wqHnyax~^y)V6<pwE$WMW<efIomzF?o~qfI(mF+{N^VUO
zhC+3EK{w3oJ5yVy(*5gc+mT>}EmdUqlV@cQTBvyf&HFXopV}Rg+!}5aUz{T;KEQwE
zgs?*0)GYMZjbAHCH4Bh!w$f7zuV$J2DYt2lq)0h*Qiqh2Qd1l6gu3l##f!aO7Ed$L
zd1p1MXQ`>qO6c9YQxI^j<kWoPgLwjuY!oSU3DOw$s~hOk{KC5gt$~e=JVvqt^nKi{
z1nSqI=DHI{xHripHeH)V#a7A<36hMW$(VzJ);P6%Y<?zw*(NAnz9G^o2ixqqEvG&i
z9UYzi$#}a>4p!qr8pQ{dd?lfpm2`<VI^31m^4PbH|B|63%CXTIrOnDqmv*p5Muu3!
zM}FA6Lv%)r#8Q+D{>M)F0J456eDH-YM0etnXO67J0>Ut+*rY&2x)}ScdAeLW;gZ$8
zvO#O2pPbq<m$0%%-XO;ZwfR!}7eWO_B8CmeBuklJl?25%3W*C2&O5m(Ivv}Ok=71N
zOUs*;MrXvziAn~G+@>QB0t99|S!jlm!ldksjsGlBBM{G_&$;S(F}I;F{UzgXaM(|D
z+$XNhV7ZGfR+#jvJ4?4-7k{Pas%O>0xn&)kZCQ0V2`SJ$ZvK7XCya8JTI{UDeD?`s
zcA!~G>r|VWk#)JR-AZ%Bl^ZZejI=Zmej1Ay3s!7J5mGtX*p@P#kTKYCBKf6*wrQ!9
zVAod=*n+}pLM%7psqO&fX^rYX=%Ef#abcl$d;9x$pL*h{(WCYlHxfGBzvtA>r&0#p
zzxl~~R!B=%_3XhP)|Rd6)qU^%n|E)P_djvw$Ya~bO-qT64YxX{^%_2M&#p6vS=spM
z$#f@gdin5C@7_P4e`(F0s=L=cx<^Y;`c-XM`{*A2?!bPKm((i_)hE>=tamXs9U@YI
ztUXM1@kV-)9(t%g>7Yt}W<5uvs^4cY^^_p!zrQ$2Hq*JRqxo`c8`Pw+qdmO>h|lOK
zHUdUi0^*r+VAHfo)XFe|$0aHfOnm8WrJBPWe8*;^(+JoAn>ARSG}P&gukIVXNIvcE
zpp3715F+EJ17iYN4@ztdBRk$4sk%PFUw@s&p5MNmJ-_RLjsG8e-vQWE)xLkv$-PM@
zZMxE?BWcq#O()%Dw55QQQC7i17f>jB3q-c;jqHtrOhpk?P*5BwDx#mClg}+E__^?N
zD{b!O|GwuYZPLMzLhJ9Z*fwo)?>YC(=e+OpK5u7@m%<HJ0j0vtOVfGnmIu4SvK9u3
z0>+S$(x%<gIx<%5q@eL@mhDT=2Gpr`iOEjiw`@(kRl@o>W2rDyV68Rx)V8*@pPS*p
z>Adcb4Yo#x@Z>|UurM$30e@QBByDmSp_O+H*J_one0gMK)ehIOiel?N)(&>8j)(=&
zZFLWV7auJ8wrKw_a9k=?Kq@70j8%gRUyZKJfNJf`o##K_1*&?Ve6|BXymaW$+<P9A
zX3u;42}JTgdHu9!*B@RxjmDko-*)Z(QT-F$Fz>Xt*vtFW`}A?I*XA!c1<N8ZCZ1M~
z7v8D0rpqfL#KXd@@N-<v*@S=-D*G43+^mtHsg<l8ZxSIwPlUt;^sDPzMZPwXFU(>z
zj7?C)rC(ortr7#Tu}(t&%2f`yc9oqvk+#|`{i27(n)rI@bCdHs$UBSRIq>78TyLEk
zvOKb##i?KU1=p@}6@ccNx$0{3rpN$@#Q@s&P^Y;n>$O5-%G#}hC-f#v)2horiv)WJ
zj@vr(74|oR_sSy7n8O(7K#@&`T^G7X*_IbUI!{dG1L?ES*xLdZitiLiMxjjUQn^Wb
z$z=LNIOL*KgXZX@wN+d9DPCY@)M)HR)HheFxA>Yt;j4}WPpmW2uWy!0?f2}F+GBG9
z2(!MepjN5Q6qUTl$lYYDv~IVw37`2o<|?)V4q3Sk;NfAeIwGA>ykx?8Dn;|bicdnO
zi3wyRE*M{#OqF?f<`FPLen(^^U+yMoSF))JZCz`wBK84-4V#**$!$~C)~$8ss<>yz
zXP*EKYuD%JciN8K(xJ!hnR`f@J@<*nK{EFz^^d!E{iepL>h;I2Juq{juY%^C!pVC2
zLzt|m7R-OmVXiVf1NaM4bs@IO0K*9U&vw=7^%C|lf84%!jm-jJ-x}CVy`Ei@O=X;!
zCVBwC+O_s&8&m^m2YtnC2sS(ewXMCTI#j&wN)I(x*=z1NlEhbSwN`}d){UFkTIu1+
zHv10w$uLKK3E)CK@!T!G>d>QAGi$0nU?9S?I(UL#0B8m{(d15uaT^VG3x9?d6$Tjy
z2GrQQ6mzucap{`!#8%YP9-%96(f2|&jOf|X)7x5m;#LadrC54h*-d!HLH81ehJ6QN
z0zzn-Np_{MkyaMMCi)a~lA1ordl@TX+Z6U1r9U8%FYKqdlTI@jDi^y*pTgbA6nQ6A
za60KdWsuN;=@P=O<v8-~1=VPV`$9=UZlc-UTkS4JySdZ<xOscK(GT5M*q<XBM5sp4
zt+b;Te$1VI=;o!ykGYA_?$-TKvO-6<iX+5f_<V9(O=4}u%7!@yy#}4;&{{AJYIs$B
z?WP9O%3h*0#BO!qTiXl`R*2&<({(lG1}Lj5=s^4+1XY*i$XT+Zo@8H#zrwk`2na4`
zrG8{Ti35tyzH)n!UeZ$OPhcJ{1(J&k{JR^D%=o#7fC>{w_DlV%R^XHBi7S~3AN?IZ
z3|<FZdlcM!sX}Q|MngSJGVj;vnbA&eBZkN;x?RD~Q5TdKs}3Hls(kd(N)pqi&G94u
z`|YtO+qC)cJz^yKv!6)!yt-`JtEZPPJ+0_+@bcw@k6Nvj54LH;e|+h|-8=XFTxG=9
z#BlnhSI$UZBrSXGwPj0Rc}1?9vpuNJY=f~;J(``jy;tl5+IeF;UNffIvv<8R$<_xN
zrWoYV+K$-`Am6s&!yo~Ao?*nZutyD3IMDbS)9dz3LG2D%<RLA8P2;Wrqs)I@+%&IA
ztJOhdQwk`LDN@L$pxXTfh9jr0BKLVI4@*Gx<Vm9RzDt0DOnB7AD_H13w)*%;!+M~b
zr`A4lP5W7c7DW0khQ+l{jPKY!v1M*<%lMAYt+>V(`)4h!4l#srH0jC`;Z<cOj3W)k
zs5x5d9AgX}&et|<u+m<dm9xL%TRUm5pRN^bC_Psr#?GF5u=E{Z{I;xYmV3P6((CM_
zHN{s{7vGH+yWqklcI5+w1Az;x_R@IajoP)?4j5yx!5~ZnfC1nF+Ca&zR8-p9AmeIn
zaP{$|c&Iw!a<%;xJ;_Fp8((Jx`BNN0LhVMfes!%O!*l&W*x?~tedYWf4i;wTUaMIZ
z9PN4a)s*aCR9v!fVM*zN?)}@e>5pG^E7z-d!Tgev#fwVY78SK^-LIcKe%XAyuKF}E
zQ~8(eeJDc9$%9z2rS`g6XLi=DUvKC2v-W&M8_bpQ{CQ!RElwK_GYm1I6GsLlNUM`y
z;rW`q;?LVP&CKRCGvR#s=q%7VqY)>kkCKJVMo)hMvZooXU!&Za;;Zazs}|+X6oD*X
z0qo^hTEJdD8?@x(<&%|MD4y`~U;vz9W)TL523oN|mlnj%WQJb~un46AW^=Kef)8Rq
z3Gn8TEol-j_Ju@kkblu^ehvPY)1bX>GQAGApg@+E5EC)Ne=x_%5XkwhWb+IhfLEDi
zFkBF^$qq`HStWyMaQN9+Q0weN8|QsO2V8IXWRSYJYvza%GbYwZTuhoZV))GQc4-S?
zW36c@ni@>($?A-nXzOfsW)Yn=BiVU`vy}mw(LoWbo+>IT>xx*^sgren1G-Goe<4O;
zJoq2MuTq1*h@X(gj4;?-*jR`X10ZhRma$4olFpX2X|HjMQu~kYp4y`&rlSQU{n9ss
z<HB+~7n}WD$EI}bh{kC+KV5l3*;W__BP10V<_tdtR5!Y86k>@@P3T{ii-QiSK3MqT
z30MVP2k*D#rG9>X_LhgPNl5qzmqqE`fhnP`LSRTrT9Nd<eTjT+=I&>DwaneJsEnBK
z{AJy*V0t1s&_AA1XM=%$A61-MoRTwkP(>1r$3;^b<+@-?@F3mnaY5oisC)92uX(HR
zHk`>)A+I*p-Bw3M6gc>6Y73185?0^?Q`rYos)-sR6akzj9bza<NNNRwB5zGf=@-_|
z^89Dh2Pj7QEB%6!Qv2%*CqH*?>HyL;%-vP#r<ERS+2y|X(?*ldqZIBVr6)%#T6W!j
zRxzcbXh6*QEpHP4vxMjqa_>*b99lHcd~U;Q(l;MU{|gLA=pNE3;a^{zAfb}CmvqS^
zeY+R&^+-$n@_FfV=m)|jOP%=HU{eMg2tEhQ2N^)so)hvKQPV~I?EGHSM$I;x=MJBf
z<Lj>S53&6|Z&;5REqH~CZ-^pp#(<$its!9QGL4v|@0pM}vutRELI>92`$vxK9;`J2
z?w@q!I6t0$9_A`UO*zg~9Cu0;3^@5%2ev<_VFyD5vWa|<n~>P9U1CBmi1A3~tfGie
zX*R@qUQE}x8-4sn=cjc~ip?f-jePHf+}wnOcI~PTm}5fY+#%4aQxE%i>^-m#G=-CY
zGZ1*CdR)C~pPa(6OZ_o$3!-p*Ve!JBY%*lPZ_eoM{<~4yVjy`{a(${uTtl8xc#08+
zQU79#G}VSxM3J18V%|hyi@nkWRAa<1@dNnlznT1nixdNOb3S{gVZP7WHM5OE0~=~`
zss&tAWuFgQcX75ldc2%!t5`g<LKCkHR|ffI<|m}~PmfJ)*)BH7udHCg-X5(!Ni`Z%
zQ=+0$oFJCs%8Yv_Mt2=IDnEPF+LDs&JAy)!gG>B7#ziKKY1evCo^`!3HPslEn#%fF
z)&NhIb<=FJV$3z6WTIVcDpyZ+id%#R{a-N8(GCm|2~jEn8sC+R0u?-rt}Z<+U%H1t
z079trTKiCqr;A_6hD{*+y&))Q;>I0C5Fem5OSA8IVDWfj;z0#md_8K3HrSXst*n9<
zrJx|vo<6Nhi|(C}`9d*)j6*@vAz|hMPg)ctw)9^(K@bN+yW{wDs5i7Z7&q7iXNwa+
zY-m|lN311|4GpeL420w2<Qo8_!+?x*S>ycoq8%G21_f;Zq4P}}Li}7jHKFZEhO56<
zK#2R7mL6R~d|h}&;G#+@%|0r9IDYX1yg7&#c`leKNQZ(TGg4vk3z-SMqtkTsX-!;E
zkSOsLWz#Z^!P+HJ;_Cvvk8BYK3lkPXy$P3k<!kzs;&EgE*yc6v_|S%FMztTZa7-!m
zsg|urEzG;a959f?t{)cKf~FC-yLt`kmA{C5Sm@_LI%vc`|6Sg08@5BLG*EE>>{1$3
zS+L#FPvZyE(15UkJvzkuR3F07K(9D3bN-n%6(n+lap34PFV2~<JGbw?G1=**g%d85
zuijk0eWIpKddS&12ba<AZ_mDW<r3+;XO<r+?m1C<a9p=McntYDcq^0(2YXwoxJI$@
zoZ-)_z2Q+<7eGazM76gu4cec#_AJ|VysYf_uCkuf=KLfbKeM=~LveA3qQz&V<3G)r
zMjkylck{;|Z=QSbx20<oE#0J4sp6*<n?C+{(~6(ScJhW>OU0UHSU#-v((C*|R(=Zb
zOTkXe*2wBQ*!mv29>)RhTUd=WKT}H0=^ux#tz7_Z!Fqo%zGcCzmJghMVb<L<=DoCY
zV7EBeq@=Lm*u++;os#b8sYv%WR-K0|PCBEsH%yn%w)fqOb5lF?+q3z(zM0v(9$mlu
z)T`^Z4eqfu;(z7$t(w`n^Q<Ee-u=x%MSl@&i)Qlp!iA@Xt(-P!-P3EH!DpacwDh{7
z4?IIU*RJ{rpwS>QhqWU<gG{Jn)%1tqk&e#-Mg<Hr!ok9n7;W}7MRvrv57tj#PgG^C
z+btNpa%8_5N#Q14s%v7;Gp_~|1Qho3@8f^=${U65-XZ=*F&qrcpBt~}TR+>r*OJGw
z0@~!3%xDuI5?v4;pV-|s@x>DXnHd59y6|bJ_zBeBUSIku8@tT9!CJh|=&dp1)H9B~
zjp9Klw~w*@0WD6Di(=#Yb=&w#xsef8)4SIiYl5+A4fN%B<8=)>^i)D4z<dLYA&)z-
z-(CNx6K;5{NgHlth>dU_T#)DE%2{DPXy`EfU<e1MNzI_b!A|5+<IA=s+YC{H>XI-Y
z!h*%KIXyeJjxv}vYE_&m(?EJlcf<Dm;_;}Srq-Pkyjz(}0q2RusAyrf{`C9<L!(23
z-T9g02+&4|OWN=Rb4m+sm!y`V(n%OM3U0a7N%<7yzsTh}aryGeLm4VB%WP)K3pZ;a
z+o}yXnpIeBn+nYD<F95*IN%F#h57q|Xn{H<UHMc;t1xQxS{Ic`>u1`~-^<<ItKSA+
zlh&kiSv|TqAWNVV61sFrfRQyWv2%OHiyf<k4P^Sd_F(s4)7NlMsv;)P!$sX~TX68!
zd>6GxV2mPlcEpf*2KNB!SCL&_F|<5;uwTcHV#o5_!4<_L>16WD^6}%uQ{$IQ9j3tJ
z!CDvs-27l(i`)X_X#-G$#$`g$$c_c?3mP?*!Nwnq*2yN&<0e|8BGpKOjf&UI*2N~1
z0*v4$>p;Z}Bi@g4Bd=T$et~?ldiit+XE8SI@uui}#GV5oYWTs9v4B`v)bB4Hr9D4D
z(Bnm;RAQ9AGMO$(yX%Pp7R=HV2xlh8q;44fy{t}5FoASrooE-po@|d&s$}3P8}ntj
z8AfQA`4wh!#eDfY?KFIomzWNR(KB9~hQn(L8EC{*uTA(oaPE_e`SZ#cz-_r)_j+ct
z4HdEN84sdt;lte!-bew}xEkMuEh2-Y!H@wAg-akGYK+butn0A6yz9WdL!L9obsLb`
z>CV3Wx|XgiY@3usvrkd+XZMg0ckyRx*1D5#SpE?ycxK<>Ju-TxwB+?|%yH!-BjWnb
zy2I=i+o@%GqGwjO{N7111+At?7qUnBBuEF{g{o3WR<cKM2W8{O_?|%|Xn`^&wJb3=
z6<F37mwNyLO$!y6Ujy~Hdb4;37!9x?!CDSa<gA_T^mpf-3x+z|l<IE{hf|+J8>kAi
z%`sVRW6jypvo){U#>Td78yk})oxDa1DPA^S-f1!^2N|oh_GTd+&DmKov2C)<_MdpO
z*tS{Z+RZf>x4R0*2C8YFc(9ZX<;HU}xWzX<5~}&OwRZcfw^_}O<T!4Oj_sG?&_Wf@
z)*V9zqu3tyt>=u^HrM+}I>6qP*6LSe>~%I?@O6H!rjhd;n;RIp2d+#}g$Ww46(AF$
zGsKCPa>F>_rvO@mOcjXWaV(|5Vv5nrY~8H`<gPjtp;;qLDA1b$Xc`2i&>mZzm@mMw
zsfCUF(Lnt^w}4o(#3(%tddgMb7$cSnF&cM(AT_hMzLswl8{l><AXw|agSWmB>LqQ1
zZYV$Eu89#IHj^ZK6Z4l`Rnn_bAw;hh6U_zWA#d#^SJxO{>(ke4NO5tDnq&*S^u3C{
z8WjgF<=)b1-xya{60IgV4z0>_6)?v`gi(-h$rswx0Bz|F<Ye@5q=f5h(I{0>a8yDn
zl`2FUBVDwHfDX}@z@%K)Q#$g~Pb6QQ{EKvi^e{bg=JX@t3VIX*QHL3Y2!k|2`toNo
z#Jeip8}va|@MpZF`+oUZx=&q9x}AKHbS<ue=sj3dE3RmTH<W3x=Y%3V!w7vTTl1hF
zus+zK=;&tAVFuVYgf|T0hUjQ<8!!onMn}`phMwZdUgFC}<BO4zFJjSqqoVd2s$BRt
zs#5U_*EI##Nm`(~1pF6&&~VIUqeotiQ(P4$TgZff=$h@}pd5!mSt%eYU<2R*swfEl
zg;*{iYk=%Zy6TdfbqI5}b(>7f6a%a~#od$XQ|NY6>~I&m>L+*0>F47YDY|E6(cdEd
zeEQ{do2<WgasRjwOpg!}*PnI*iJ&3iiaRRqQ4CNF5_c2&q??;{u)A90mDVnOye4sJ
zo6~K`vP8}J^mb`pny$mc!lJiEhlLHty%pAJh&hM>s|MgV9Po0@aoYil2K$AL<Z#$p
zU?&P^0L1<<H7kj5#Q`ozy9cDiCv@8^0l|cHzpGVTT!*D(fCIGXX%yjrPLF}8i6c5W
zylXd*%kjGdei3`wFt97kVGmWPFb6m&IdI0w1Fi6$Tpz9<>@5suAWe%22gn_dLIF%K
z08N0hLI4v8kVgW_0Wehnc4Sur9wjCq6hX*AI&!yw{FqL{12jO)4p4;}A8fJwZXjpg
zz2j}O`JEjWU~gKMx7cSg?eknd1%8>b<6ZW5_=sg$iwBL8Y4Kt5ljmgVwdId3R?Lt(
zlZ?sYYU#Dfo{H%b1ZKP}b@rT0CQ7d@2Fv5yJK3#QwAgDh?e$t=0Vb$LE@uk7oU)?D
zexq@JixqPD?~sX;TS$4W4=<KpYfX+p5m|5-LP^Hr!%`N>kn&oPi-#7U06237&=?PV
zHoH$Q2w2bZ9EHgVd}sKskf9QECkA$E3?v-_7YqT&d9LLf?c*)260b<Bynljlo6%&n
zhvuh`q}AV(o??l#`XevWvyRJ6sv>359;=`DIPKwAARh1~h0-Qk_`L)p&Z%B_QpZzs
z13n1w7S`Y$B&v|QwX5TS;ML+29%{9R_?S9@-=46>8biLXQ^VR$!4^Jh@i7k%+EeXg
zD3JW1nlRtHU6~9%%|KXHa$(o7*Ak>9G)n*K8b`paPEXOpD1<El7#6aH9(N0Q;>$-<
zW{!ic0X`F;Vh`~iC`^=0^K-j{Oa@sSHwg7uCjD{WlJv}@pP@rq`VI1YiT58>`$iDY
z3?ah3#inT)6I~T%^$|MQO?+A#eAnby;QLGONkwEYiTmtmX8Mx*z#qMw+zoegC6-QZ
ze$%C5u~nQK9ehM>R=7^gn6{~fdxVhTNg{mJN5%Wy6e=3Ab}2lo062sb-W48&l`Wg=
z3L3^>Sz=ElpVcs`8+J+AY6K_ln#Z&~r3zJYAkmW(m~#Mp4vv1K!)xKK7_Fz5sr#a(
z+oe+v1|^02cI<z*QL(wKYd>G5TF|7&Bn7JZLX!Rd8*hK1I5>UABL}BXd(?W){))b7
zCkR;2*<UFhH0cvdmlyQ8l3qytf@5PcVJ0hm3%d>2NTZew?e+56ZTqZG<DF(a^5``C
zPaC12sD@ZTxH-@!PYIpyEQ5QB^N|D3G5&BE5uU<hhPYlnW?;<A51_na<o{ij0%r>T
zU!YN!0&6Yom&yrnFRg4P!X||HUEX$pNw(Ri;LM2&FT4XMJNTQoazf6*igM}ar^Iz;
zv;T(Arp^2}9cKpN;iurwCrHl?p9!Jn31bdPc~4fF&1cq=<8LomQo#Q3>0JDkKtK|%
z^~g_pN$3UThhfjw%&QF8r(mSYjxJd6T&eJqyEqGXA#t{c8_g1b1=9fJ-4=hPZCr;y
zu*oyDBR$}QpK+t}JiNW&Gq6mX#g|>xw4?a6c%t6&<N{bxGKU?<ldU{g@nz}(Oj84F
z3?AZ35F|K{kx%Bk53xnS?DK}tU@0`q&C46#cN1s1tL5MqoU1j@7s~0c`h>{NgoWfP
z54l{tAYSCts$PRAtok2RLqo(11>yy4+j`4x;A!n;H~hdW#f#zvz7>=mOzVH>AcwMf
zZZTOb999TS%OKQ#MwUC&c07iztvM;l7J2M$;V_I_IDZGr?G8OGfh|w|OU)|+o3fcG
z;2W}b*?;)Vl$&s6n{q4v6RaHW81WWf{l9XnG{yQINPaC-_!EtENE|2~BE9JY&{cQR
zhv~!cJx@F?9*293fHC<NU`UMPx6d#(5;2P3$?|V<48?%*2{)fEqGN@2(E7M-`O>jc
zT);a*JFyde8s2vU?Uo73nZjv^nZvtln38oXE(>&`P@kPCP$l~dphG2pLC_%J1i771
znF@?8Dg{Obp*|IKCVq<j9e(;Eg%VV&!0h0kq4EbqOol%$>}vj8!Kig+>4S6Uq$Bt>
zs=&NXC^c7|HBX)#;#=?_f#Ex}fJ`!1wk}}*!KVvG32xTtgoKroW<KH*|G!GX1FkaT
zyYS|p06EC;0&-OCv4+f#_>XzS2y@SK;(P4>Kh5h#NfU&~JwophWf4*Q1~Sk34LrMN
zt!KvwI~|-f^WognA5K1lu-)w~fX`%vFZi83A3=pKXbJYb;5ve*2gNQKM&oj)5Fkf2
zMp%N^3+6Ap4PXilJ!vWOP4Gr?lgf>xoQV%oP#~^2caBcR=d!lLcA=ZkX|2(uYe9ho
zVzPXUd2+tgujtJ7g3f(>;$xEv-ut=_4TdKys5)CvprH09#RgN%gd0fV=gt;bAHkMT
zjAJE`?8;A~&W$h&78tBstiLC1Uk*syg>E21bc%WXnyRniT5{~1^%1NE+#1>n&M{Ii
z)my-K@nO->;NLTPE6qd?$xyw4VGTi<VFW@E0TM!Es0H*+09O{-=XUi4)mulUbJlF>
z+|jL<$XfcwrL9#vB~h_Vd|jF$<fdo7TD9xd%=Cql;zem8XjC6PO7s-sJx;i;BWuNv
zT~A0qgBeXBiPjjwMVe`y`7G64x}%HI`nn=b+2xK);(2M|LYQTE-g*nhGwMhfAx0RI
zXOo(mLX88|b#x&>!35d(0B`Yo8mX!35fZL=k%S*9Sa8LfePw}MyQx(vI+LJsDXx6p
zw}lX?`><*n<<rRf)s@yCIU=1C&r_YWV1dLcrdVMeL>2F8Cs;X1n)t2YZoO9@1~GIn
zE5(jHr|Jyt>I-^zxZ@}l94g*;`}!F1G?5JIq>q>{9hCl@YFS1CQhHTHhgtjb9KY2!
zaD{Y9DiaqVGoRc~3dzcEW0SM!+TX0uWe)dNK>rCG=L_m_26BGt)bl))>c+#z>XgsC
zVvwOpL4!z&+MD>G;*R2xu;_|jDblygEK`Zg!AoW=zePw^a_qNcB@}x<GK--aWzwY;
zfvOJm-4`E-P&?MsKxhJt6~(5h(w}fUc6So6%wiphH6vr`Opp}wT@mQZ%8({W2c*F+
zo1E@zdnULq3iNE6I#s@wJ(c6L+uPL}xYX>tiKjMSXkm7lWtsFXYf)%m;==ABd@K!y
z@+M(ZhCmZT#@yXdpRue_Yud{V)=LlUFR-+NJP~XZ_&gcn+^KEoi43d^&C9B4EvPd1
zSJ<TvZGAocfp_<m?~jru5X@{Vpksh>D!s>ELWD*Ts#>!mYU*ac7LM@p4i^A{YS2dF
z+>8u*BETp&75_?`tOyN%1#4Gx?e(^+!}GH;<Zfsqc7!7CVGT)hGumX?9=_)OEnsFc
zT?rZ4LDSjB_+23*dKWKRHGW%&^<HSaPP$e(gQ|Yx-Pd$&!++^qM}LSCMmsZHjAl<f
zKOo;J1<)WqDebVRPxnb7A(OiIS@hm};<GrWcz#57E1j-Y_6VM@vOe9h<I_qGZdz}>
zV3gv$(BlEkc2~%@@v9aU_a0%dSDUVDc=xK`2IaJ>T`#A$gIX+-%dRsf?QP&te>gF)
zieougpsm*KP>N0mB?_0>AgZaay$#?rg=;LfW36h-kI$OI-lEwfs;oSZPmiqtEh0aG
zWB=Rh#;m2)EgKGvie1C{2<xWEf_{Pa%o)VH+uM<8csaF!BKU(3P$dgin@Cv;>&nA4
z)TIyOBeA(7k589Ara!<^;8JX2EF<VzE)R5WkApuU80P?*SY)&h_<@;S&`GQI1|`?y
zrqHnc`CTRsdp{ap?QPqVd}LI{1*)hbq`d6ms&;Rc6a=&1h88@*KTl@Xxi<h3*&m6H
zU3g%95US1LKgIFr_lHgFlD|JJ)MO+dwQRc=UP$G^1to9sFFagU9s-GU1GUnEs@x|E
zhT<=_cJ%ZHEi-S>S@nTk(m;)oW|RgFm-$Yv#AEe<byB4Cp?Iol9iQnc?W=m+Bf{-n
zvhC*|A0``C_ODF$a2GDA<6B+c?iOiZ#~tqp5E2@Jn8M+760SE!f;^VTYU$!{@!|a8
zex%s7Y9jwWZ9^i+hs!_v`A5E$_4O!M;n}Gk?v>*USCWmF-PvuSjX7yC>^udwb;fpV
z!yl^7(dNq~pw-)1dO5ozNt0ghm`zqfUEmtnUptf6@fy%rfSD)zs*?Rxo&P)*ZC36D
zB(^fUqx3pS>zEDLm6f3w2%pEEv<KD67sA+;y;E|T_Ur9sll3)ss@hYl9&4px!Xy|U
zpnqO{N@If~hglez2$wL4iu;wxo`N)Dt}@j17Z+6vB^f{iK_6Ke>Z1H}q>qPU?%+^Y
z)iGrY>lNiIzVLjfue?vRJZe%SD+eluk4PYX1DQ`IeiNfbazqHd^1d*>_UDB0wLb^Y
z=^@ywui#39iXS{@h0U0M2*EWBm%%WTjyb=l7%aaB`rI6e!S{^S*S!aC;dNJ5^4yg#
z@japXy-D(W6<4m1Pr<JUCk3`Q$<KgR$z<|rob+Ru&cij3L`EyDI%|)(c*V&u7Z|q$
zaT8n@jMuR<Jew4(ciDC4;A6Tl;vJ{M>lG*C<E%ZPE*J}1z)uhcz<Mm}1^97xS}G_8
zakkjI08W)kK`#K~5rKd1!%vXD{1;@}l`fFrf5T4_Qt<sF4_}f34t@tFsJEmyy`M3e
zp7AEhZ@oj3yv`eq=e?vi-#$c$w{;G{2<ZpK953n0;YTG5JgljME&h+xu7hnC1e0gD
z|5d9Z-3N|UE%-yXU871zu%C}KT&eo&<Z#$ci@H|x5Xhfr{R$4AL$1<HtFa!d?G5$0
z$@KZv>XZt7wTSgqbzEw-{U1VVaJ3JGrAm%V<rl?Dv2a3&1vw!wnUG55IB6WDOB!H!
z(PVnj068zd1-aZ0tpOeeMX2>l{KCGlmx1x0uzKNGaw@~IFX}C-rVr{X5|gT%A8{(Q
z{xTig8q2Kr@oL(*p2vi2IFLnyJ?MW-rvEsVNw`>O%T>^pjNi+=v9ik>@Cfcz@-_u0
zKY67CC?Qjj`BnLM&Kflrk~oZ<o#Wx-5@^WpJA3pTvw8lAHJQ{Key1PJ8#Q^nxEf46
z$0y7P9G=(;eji66kArBqYqL-WM=zYO_VSZ)o?oqehXz+)s~R<Jf350_z{U}K*(+3U
zeH^+#eSOVR(;wGro@cOpdapwRtpoOev8Fx;pntrfe`Kub5PuB|A@2<{9EP?$+l4f9
z<yf$rfZ-6@)!{l=|K-NBZF6{?JR@N`3^gu<8VFEo<yf|U+SXl2-~eMDH#8aAK$7-P
zbz#!~Vok&t<`owor+8c!<`27;!<x&kLG41Af$|PXKJ^cjK92=nNSH1@%u5%hcswp1
zu3`33{!dun6~M@679H06a47@Qa+Bj3++MoEQ~Dxv7v0gqHK6L1czNxIZGhKGKgLCq
z$S^NnD}F__R$rZqGFtI6Ec0PH>mbEWxssS4Zi6xfVw%H&i6MKxz&MXH8c)h{93Hp~
zv4wO5kv#YgaWp1^{!#{bhrqZ2VjS=;NLNIPOQO~oeAH41WJI_C4g?YjzrFnqx)L68
z_w#ap=syp7NSDP=&C)$&u6c6{#hTnmae36632Jf?Jr(4lI^j)vF+u&#JL&}S5;^>k
zyZb}p?EM~6m3h51TbjMz3{43d`>-$07CwMiN@!*@xj_O|5Q3t;Xs@b4{7%X#KB$Z)
zNOL0p0p5xka0Kl4uwUBtdy1pW4BB{R6{Ln|eRYTw2utYm?A!qg9N~JK<_h3M``i|m
zsDFlt_4Plh13e<9E}HS^qth2njqnJh54i?Nr%7gjYk+=yVoXfpcs<+_YIlJ9NmvP5
zRIccam2GNxkOXf|{r9hC=L_{0q__)feXyR=YRb~cWz}DTgRioIX8{J>NCtxx3+ogk
zLIxmcEDFrTpIl#L&n0ICw+%*M<=}JG`)r7}?d|Bg!T3icoCZEI#<S<#^23kP_Bze#
z)WnWYo+!QT)Yi^zZm*k3&RBkZHL76<y1sb5Rf@Migsr6-s+O(QU;uFKNP+8%Fvd(c
z8m_Nq*IysoC~T-2SiXHc0=BOnjco0+$Ayf7g%6=HO<_4a?4PgBC}CSDtFIXj9v(hN
zz6ewmjN-r8m5yaG{LXwv2()44a`=J8;w{J@@CAw9vFw`L*l)&jp^z8*VTj>C)=DIo
zP`mbEI;rWv`d$eS8!MlK{T31>(`m+y#wy6L%m=^=F#!JhExeF`$wQul9FXwvig^Ic
zW=k*PT&w;D^BLAkI2#p06sL_}QH$3H^gEp0U>t@ZDOtBoRR}DKs_rt2f`0;771HZf
zyZN%J-DFX;^eUtcX%!t!atsFPB=H4X-vh);`U%$#JOc#4In02kD%hvs3~S=T_287Z
zA&-poa6Qf`Rp(%L*YM8Lr;-N#eHz%?)je3)Qu!Ov5Y2CuTZDH4-Q)TY$l(?^+&$1u
zb#d<O*>f+dobQi2j7kZL>@~awEQ=W@Rh{u}(l^pKcsEuSF(6-#7+6^#*Kfb68x|#f
zOpH*J?HQ!y@C<{2%gokZyg%4;KqoZHgbyN9D{7ty8czmMxK@CiBYV66U*7f3*u02=
z(sxC%gW}@{#S}^34UEW(z0;NV)$~ZojTuc^P3e#YVxvAvqWhGz8Xc3H(p@@Y_SxDe
z#zXK=+_o*zU+{?Ov(?A^==d&vp55-Sgh#4>_VnvA7TZC(AL=+ot|LQsHpU00TbJu<
zbM3Mvj8%(~Kv-RIM^trYwUAzQsD<<@t3`F?iNC$_#J{@oB)@ij4%bs@R>#NT9G}U~
z@dmkCP*Veeb9`sNMH>>WeBy>hew~R<aFZSnpFDT&<Z!Zx_3>$VwjOvL?2#lzZdYhy
zIQO5g{9QWFu2xv_YSKfRP8P`*;~GB({Iq`Hlk!HZHKP0o$R*;N4Q5s5tpvNd(yvdY
z7}2tfCh6$=t^CN_%05z}7+cn(N6QE$|B5a?t*W)RC;tixZt+f9t1K$~>Po9fUzIgJ
z9b-eUs;vqJ`tM#iDSc1;PQF0=3ohQj<HCg<_g}mYNmYgV1xQHlck(3hgInBx@xqQB
z7cN5kZKR>fUu)a4l)oA;|6npHeNb^t-Ved&s?sQm;cV@TBOQIpxFw>t03&OJt28cB
zJCDGsNwF^E1&=^}W$dJ?ccck?f+EACh4oK=gGUR63uwf4#d(9sPo)BXHdvSfSyZ2a
zF|`%ogu*0k0lwiXVCBGeiopsHqNe&xEq(RHlI5lMT6?I8mc3FuzESj_(qU-76=Em$
z<2yP?+<#&g(O1x-6SJgq75^(=L+^lZ62uKcfBzwkQMrO&B@q}!>=}S-szT)_M1rvB
zuy6QGhzjj`bTIl^zz=fXaUNH%APyf;xdw{MU5d$kC8*Rw#8-4|tTfcqA5NXy`>xtY
zW5Znbd-Aio&?&BNrmDLGTIxOh)uBb*<MoD#WANQE?Mynw`XG1do3PM{UBpiAZsq{`
zbPKiE*WV0o`A52p*_unYyC|ad;!t4a1o9Ky4c+FZ>IcVZ{q!Z|F?>hrwHe!Wq4d7c
zhVFuXip4la8&e-22p=SX;Cxr5B}2=i^-*a^OU}SO3(SRZy7V?gz$*x%!Il@=v?+P^
za7kY4lIM<<<cQ@RqNGz%9XwmLDDxD0%{*D|5hb`kLEWBvjs(R_f9}{jqxY?z@a4N>
z59}N-4itoTG|<(bp3-F(#an;yaSI@%{Xx=GIvkvy7JPrNWvoATT-hnS&F_Ss0nZM&
z-4sMEye-a27UxjCI7i^bIrts_qny)c1y>$FNau(>@cSSN->NwL&OUqW%3|Rdk6vfE
znqg;<NR{7b-&@f+m2cMfS;$^;OfD3^^T%t7fcq-Af-5_fVNhR;SV!9$_-&xd@V_!_
z&YZ2R;)Cq9uBm&?byy#~&K0jzhSl6%95%=CA*!(6PUWe<%MEribvPaaprw>yAnVIX
z9Q%GmoCC$;Mb(A+a_6o@sr1T7C{GRhs|n&ElE5S00Wv2QfM<9BH;$XkP3PuwE4Z~B
z3>=uzQK%lH2{58p7#+L3$~J187+VHYdWN7fqy;$sm8c+7P=K%eJym5&hu_kWUkeek
z@^?_`RcTZinhdoeLt{`Io!*P`PxH&rD2Xz~kPKI57}<?5oHipsdC2&z^h3vr!4s#6
zPj+nI@eJr}{_w1E+Qh*XAi)$PJqiC}$XU`A{+-?PXyn}`RUbt@TEf2#?9&VIZwy#q
zL*U<f=@C=7Ru}zCwr4;apMInhh<+36s$jh-I9k!&&!<g*r!*wFb#e3#_vmE_cix#G
zDFZyS{d^Rof}?f8dh51M1g|O5@X@?Rh=`Ef+xYlpd;U)s9c<F`SJJZHZ9B4e|HZv~
zc39H(-K?~-{=Kcaj#ZOls<vd`G5nG2Z->*ZtUlHCQ^Y{w*?!VxD902mJ<RSeXn67k
zR@Kk?1QroY^7;+kt{M59<_B{6zyWFV>-u0Q+qw~J5kMXj{1s-rP+Z39Sp|=!3qB7I
z&?W%JlDBO<B)}l?V&fqmR7={j@z4|U-IRdsbS&^{rol*H&2EH6S9be5_Oqk9NBw<n
z056Uq16InKu6KN`x>{GOLZ-Ive0QGsWal0|I(O;by$fAdyMrfOPp^ufCG<$Rv(m9^
ztr<7anV;X?x%JexC7zzU+}*7P=T4NKyw1LRPJEu`9$4hqgEa9*x(xb>&0%2}cxg4j
zOEkb7P6JMCF6*yyZWQaUd!Wav`H6b2p&o+Xf-W(nM38!?CsO%Ln2yL6L=Re**FQy7
z`Wx#eNd@x<#&<MNhu1p~7vv>|n>!90KR(pYJE8U3g-gUIuD|<${^_tHV9l=9V<e3&
z1mctiCY`cne@)cD;avj#jGEARbMOCMe;2xPyQCAsIN?03z_GCUX2ANJ3vA}@z-8vZ
zkCNh(5v5=$@~A4nH^o4q1K5fSzWs0?MB;Lgm;#nipkoX6?|_bx1wq1rxDDx*YrYHP
zs#2FKs{T|i<=<GU{Ig22^fLdXE-WrSTz^Oj31<%J!{g(^bWiehyqk-pb8{h|czH?-
zJ-o?8PxA}D#>2@FU?x7o3$(qU7S|Gi4yNwn0z#>UN+%}J*k8V+9Vbi>Pki}{_&zyz
zCM3k{=N}Uq`Wm?)g}fFT8sqP04hcCU>G^v?{eyxkbiTg23NM3q1O$~Y65rPbYVK(f
zsb1)-3j>?gpI6TDQ~7hSN5g(d_^G%V>e&wN^d9VW?7cxU5+K|$q6h7B#0=1ewr!oj
zh43qPjN1wC>G3^aHnN>up~o9To}FV?cJjyA-VLrI`%cOqtJy|vTPWV=PfjUJ<rl#Y
z41OyxyG^Z{!_QIjtPJ~maQp)wO*MiSrb>r@{82hgdj0q#=|wwLzmyJh@E_$Kl)hE<
z7aoLjN(NpD^9?<=u;YSpRi3}d#Am-VplKr=BL@iv1>2b+j<_N-E-n+l=&zECv{SlY
za$Ba3ii|Pm1Qdpt$XrM$(}K)1h29y^&KzS<M=hf(@bmN-eix~<LlVekGUSi{grvl@
zHHYeFcPgJF{V2^Oi%5$(<(+1SheWqE`?dKG)>&bz^Zji7F+!~ySZ8c{AhxGb^_N_s
z9H<%jgOrmY<hRojmhrPRo6I5JSU>T->c{A0uM&Lp56NA+4?Zym%%DHZwPLkbw8YxO
zn91Y<D97K0XFa1+3sTO0!|C`@#d>xDJOkn00~>=z7>G7>SkaUQpu|IXijwi-Rhk*k
zzxbiFK@|UebQ4tovUc5ibodCWBBMVd^JaW5{RZz{#<n297%NqM$FGD)P7W}1guo^z
zE}DR>12mv&48DB^o3R&V%?<V*FTg}bIE`J%DqxIMa0s<j-<h<Bq*MCDjM7Y9P)vAw
zhrlP__U+#L-l8svz5H5|C3EjzGkjbZ$btG<=SwG_d1StMSG2EMH@U2jbVS-JO<PX=
z6hq!v@e!XvvkE$wckSCQC8tkDUSQ57W2+7wR`)MW4C~_`wRPg?z9skW8#n6iSqsOs
zPV;w74-bCmIP^l$5<SPQ<Mh%n)j4GpoL*gkt%E0FS!*H^xXW=|OHdR+CS`kg?yg)9
zz>bAnF=XBx3>@;2fEXrnQvfr}=H_t=xux7nz>*ueE!=i)C*&x2kb8tX%pHMQ`3(0w
z_Y!xSdxQHo_YQZK`xx>ceaZb7av=SW`<eTlt0YR|4nx<61Q0C=1LKPcXz_`V7b%mp
zCGAK@k_Y*bdXW)i44FVC0qK1PxrfXri^&SInye!m$yTxh*jD?=0rDt$oIFXMCeM)<
z$t&bF@&<W}yia~6zmrNLQbLu~jkcgZG=OSpDAm(Q$d(;XlV}=kMYCvo+KG0fJ!v0W
zNK5EII)o0Vqal6vBziZU0qY2$qqK|^g9<<_yfCq!h75oBX~H+)%ZnH?(%^UCQUXqv
z|AwDUA@E1|O2cpL3$J3gt92Fp4R3^B@<;7I;aa=~ZtQqjO3mLIxa>Nva;RZ-X|*pS
zs_=9Oax$g(DUz{b4h6HyYT$43lVc^}%U;VAd}@R3DQ$1aRmIkT@Cvk+VaRLs41!;<
z1gFp1>t+Ax)Ed>d!{)#GWe$&3eU%X{PVf(>ssWS}OlU^ZL@81rT-(prxhB_Ws_J_>
z)WoSTYX$<=6Tf`1!)rB>eK=vG;%oUQd`NZ9GSbsnt}V~8So*<_iFw*`e{JG3M)&-F
zS<mXVtqZi}?k+CG*X-S`q<yMoGL>e*$H;x-RTilmzWR5Twx7G!DE`;vnO~IieDx(X
zpQfg2^M~b&dGIkRS}fM@;DsWw!pD-V&DUxnWSd>lOIz+5rp;6;6;FC(XGi8wD6IM%
zKFF6?ELAJ<#mZvs<Y;YsZ|^Fz*(<*!_hb)kxhh1P&htXJrc0N^JWIKMWjTCOIBv02
zCgO|ldIgOP3(63L%df|(^UFF2b9rgFQn}V+du2vGysy=!QmR}YuFCJzD(i0TnuoN<
z-0#p1^wq}yIX2!mf8ZUnkGVe-xaMxsO4~=J4Ofm~&r&YrOPnD6z9~CJSg-O4>suJA
zR+5t)v}I~-?B%^eMn+h-k-Y>f)S$AX#Ukv%7f?A%qPB}hBedYt(?jyhRXyI6uc-3&
zZr?sSe{wOu7Cu<D$710-;)}C|+6j@`Y@ic7YQIA2IZrvOi(5i~D`YyF>*BJ7pE%uD
z@R+aqHdkBXr8QfpYxDDyJ6bAy6oGIHky<SDD}0ffuN}r7miAI+W`^aLyY_l3M_c5n
z1;H`a$K)6Im^8>TUPYGRtF@D<rF~F|caZsKmoeq;1%a*gJLMjJEYUx|Ja0LCsJ+D!
z13$b+dRmkLt8{ZLmhP+ctKuz|rTr|W+E)AH^`4{jU3;4HLMtp5w_lTWzT<VhLRRZn
zkU<uUl($&3ifn}!Ze2%~dd5@VM4k5-U3dG(#YZU3(dlREOX&+1i>O(xUq#Qr;Q45}
z+v>8cvNFA5j(mZCxuv(UV@H*>r<Yg0K5nUgB(H}db6}NjHJ=VI#*STCn$)Y8FMlan
z?=xQCQ!~)gH==!eq4KAYkp8+>%2hgx09CKdf(wM*@Pd@jDUIyVL8UB8)%j1<6;!%U
zTDoq)f|-Y;UBVY-mO_0_4!yiSTIV`c*Qw{4!(nfpThVt?sU}0UG()eMr0aXm=gq^q
zHCsCkEp?5)JdQnuC8$hM`pgRHL|OM8D~~?8q#`lDTl|RocUb2XOf2<JRmQ1Q9dwa%
zbmf%+FkYU8XRVBc7jrDiRi&-^_YbN3ND$iVBP^PMk?aEg4PW10x}=r*u~ilrF1_G_
zsx|P!cjVHtxcq!CYo7h{U+9jGROhuVS^17;-`;&ob%&lyT2IWgEK@DgfS%*ae3BL8
z^!hS=mfLFmbn96dE?+`3SYejZeWf!?@lnMiDpg0F(c)ij?mni}JCUlPUq|Y?O3=9E
ziB-DA?1g1T$m-Hw<4b*$r3-Fu7N3edy(zBis4~y^CtB&W7G1wl7E31>9m8NG%<*2u
z!G7Mj7-0){Kevn9>wphVa4&GDATQ$UfDhi|J^+018TW+^AN<1o0j4bpA|I6yMI1q*
zh?&HbBuI|Ynq-sqq!ZYEdXhenJ+XugAcM(pKyl;AUBp7BliB26vKG+6Hb4ivAaL#>
z8#*{no+T&A%YY94McxK<@B#Uld`>P<SYZGicv3Y(2VpdVM$s5R2Q6tTLkGE#o~H}#
zP7A8h!7vAOa1WhN7t`f*HQi1hp-1Qm`bu-d3y!)BwYG41-?DG6_Mh?wb#=sXjSW%W
z{9so#_}TVWrGE-;_OP|qs>4md2#4L)=}BZ-5j$2h^LI6<YE1Y*`~bmZ0LI5iP=qp2
zlnM?Bcpw0id$Yn1jxx*u=Af1}2Ny;jfy%3pM1l_ir&NGK;3{Z()Iq0j9y@k3epz3=
zEdXTpTK+3xol3P%`L(cCb@`Q>LLqO|2RWp}g(WK&-PxxfelMt6->3jY1T*=-g5cgg
z=Jr_N+2f}{cldSgGP>u~pq`|lsS$|z?!JBR#xL=Rxn)83_~@9#g8YPN%Ec!p#_vju
zk57CxaK(zigunp<0-F%7NPhBo+e}8?YT$Bt^SssNk3GI+$Li(drp}$SwA&it>A#F$
zWZ>b9RA|hqA;SlhEM7Ha#K01TM<c=(vi79L64It+RIXcQ=@GR>n`w?r_iZKqw+S(e
zkS33>yG7r^?7Yr7z1ergg@lCoc=%efdv^s;#Wyt@T$2Enj*MzN)2$lM3?dcG<}n^@
z9#hFoFrT5#V>wwx9;ik$N69gA!iHwh*6|*onNP?$a)EqJz9T<?<>L?PPlM{Qb+n@$
zXdWE;deOeLKP{z$=ukS6j-z*hxpx|!P3J+>?J{~VT}wAYB7pnpZiwi8f<F5XrU49r
z7=tjQfdOoKAUO#(Kg>ib8xB(N*A#pM1BP!s$N{W@XbRvJ+GiqE%<_W8!k44XNJd8R
zr-sl{4LYjNO7i!DIkHrwDOLWdF(8&P0G9dx5X!WFm`{xlRs_Yw^Y<%@?hKF2?I!Hy
zqm3Gc24cy#D0_4YkL*=g$=w2oGnp?bBElLa?J=4cUujf?BSkfYa6FnA;Rx><j7GyQ
zqrqT&C0JWgp$!h4JNN$=BokKA-yBsuM6X-1Ac~J4GAS&iR~LOmUJqb4jfhml&R?O7
zYgA~XD7{NH&}HAmHS6Zx6EIYD7cKw4j&2}%Mr0&><yKUHd4^lx$T(&<v&<ag9_OCq
zp5~t8UgTck&TwyXZ*%W+A2Q3#Meb|vd+sOhH|{bg5<&#Xo#O$HyG)Wra=}~EndF1F
z=1x*X%D}BRl#C+dm_=q9nMLM-t8p1b+^-=U$QJT2IYgdd2<Ca_uX&yPo4gBbo{z|9
z<O}i@`IaG=-^icD3cefk*@V$>Y6PoH0!^mrv^CA9xgb%~8LTqB>7BHQmeF!LjE=JT
zY^GDYRb~}kM>o-JbO+tj{16N>3!S)y;2t!>{_Wsmak6UEyH7Jvf;)SytFF&JgW%==
zCoBWbEU?yu19S@TPtNd<0_zm>YB@NMuF-Jyp(z;{GUVmx^81^5dT3rnf=c71^z?9R
z(Y0c9hsekdqpg*<#rl$eU6AGS@3#Q5%yxt<CmI*B=mlwjN<~&H=g#9tjhQrr-%Qpv
zF<5CzTr#U)MS@ER<eD&c8Pb1UPR_@--q7-Y3!W5C-u>X7<&#xy3Wf1Pk5Xw_6IxvW
zif|hm8H?;^9Fiw$A(3|&68RK-L|<{=022Ap0f~S%1t1YW@Dm|}B$=c$yGjSfAVEJ-
ze^N@&u7ZA|2_VNfm2pW{0gGf4^AqhM4+1Jd7RgiO86u;SGvrP3jt!NZXO@*qjpi%b
z**wt*qk}TH379efjo2L-wXg-VgV?q^o58`sa&S|Kq#mP&6SQGB|7)C+TILUo4YM)1
z*pnh}MSd9j&qlSPG=Jn#+b`4%OeT5e;!JlBH@^<Wn$T96e&I@2w}5tchTbML(#HW3
zRGn))%)x);<N=y^i?}G7x~OAY6Qd5rFOIICro<rLd~DfdP1HSo{auwI>HSR^E-_OJ
zLdg5K8j4tbob48h_Z!D7Vr}Q>>S=W=s4Ap6!4C4PgOBG{V36m5n{pbsDQ`0F>PO51
z@)h?jcZpd*DuJ6q2oDwzPY{pvCqckc2`7;Rq!}1XMP{%fJH_tJnLwsMzTsIw)?PrC
z*eoHNA<NTFg4hFDDTp?ZmGTKWPcA|j^7rIN@+-4}aFnMm)SWR{H8hSfQ!;29+K$;k
zWM57{T1*ExF;`~-uYMt2N>>6mWdq$p?*oO_z4Re^kUmC_(x>T}=7>R<xn2{HhFk<c
z03pnPZzpnKjxE@$k%X<W?b%M?;MQ78Y8hE<Fb6Csjwk}Eh9pt|M`_iT9J^rv07f0g
zC!mh{EDCj=<Z4vaTj2Bg2d&&VLzear)3@v@0KLgIP3@|JJf&S*>cceJc!R%dLT*x0
zZi1`7AzrJoeseo)DKFK=D}|eabrA!ri6=Yy#|A%mBb3^D$t=j9<^3BVy^@W<K5ZOg
zt$4OBnE9lM!Hm)m7%a$RY1tciEKLYz#0yE0rp)NDNaEuIx=7KPrpTnk$d~{hV@^_j
zeo~InCm<%0d~mCwO;9Z)(@!~1XOP(^14<YFYmi5$gu&NM$E}af!icw3%7z)U3mb=%
z+bn_3ojE{hxdpbCgUsV|oRitO7_IY`jg5=ZI_U9{qjjpdE09D~<q)ycn&glUjEUQW
z6fh?4K#2Pq&Z2ef7M2AzgtOn~^Fiy%3*;1em7sOyUGg8`;5zzz<aiy#JFcM2k8wIC
z8q4rbCT+{`P9E(_dqAX4zv@VxF?0f*0^F5Z)p%!(1Kv464>doWgD6MNi3@-x4KWTX
zH8hRI1(8K8qmf_)46t+|=Xf=Xr7?LdEOQF-WD&Z7orh6S13>Eo@R5W61)<Nav%_G_
z4>-K!{KOe4VFW}+oXc-w{|_jiC{@kD^io*B`+J6kdHVAOh26`%-90_sz011aCezF6
z2Zde*VXjKX#1(vZD7Pq!d&eXVPjHXA{8(*db3>6q;&Hcb?KTb={PM=uZG2j17AGZ4
z9FRj^u8*nP*ug>bc9WR*{R6h~om(aa20u^x$K^iJ#2ALG(Y18#+?3d*a&4yX9qvIv
z?sxcRuFWkRZVnAK4=*H#Z#7!Eyg7QtJ$L>K9VzRFei{-!qAZ+*?acGZRi@R#G1nhM
zL<UXsDd@L;!?Rw~eA}d#4wx>jz2)&krsdg_<Brdmo;4)m_Zd$~uQs78h`d{{-~1L}
zl#Pw-5Blq|Lq4Du7Ywn*7(o=nVv93K8^A4gwhBfNm6D0fHiJxCw9R02F|t&)v*_Xn
z$s^=2uvKKg&`W?^US~|(FBwnef8-a4cdsN81rc?y(0EZ_s$nt4;Vg>C&R59+)@^6T
zy6t0Q-B!>M6p_nhIu(%1V!E#Rp%j26HiHZ9$G6c3bW0+RufwF#h|q(vW|3<mCoxya
z@jxs(TDI-f<>NLr@Bq#%B%uI6romSj#RP)%O^-y#<?b07-SJE8d^-#$Lfh&X<e4{z
zG@h?(v-s^+;0(G%dMVSQQkix}e>iHTIJH(#@|#VKF+Loc3b}dR))*cL)$o2^fg76;
zZ%BUfSn5u8-fD!=IC05!j1emv9a4xBPAL!vDOQh))RIHa0m`N(1Qc{mFClppIbKXd
z+V|!OQQiV<u?En}R_?x9+9fBLcFC*E8uBh^mwe=)UGfWRmw^8Vts!n8se<|?!9-`%
zFKJ0q!5UIXiWv)b7-PZ8_yT=D3xNfDFR)<Olg;G5tH&inB+vH*@ddJAWe<=C;0x3+
z38p#<!ckxuNrV{XOi(bv7-eTREJpQ=g{Yp{bO~MG?65_+I{daWUF-ART-!-=L!mFs
zwNr~@a=n0}ezYL_jbyk`$0p)HxM{Y40&F}W?gEG+oitN$K@W<n=>+Tg+W{=<cx0|-
zw-E9g2y>}CR$J?&LB~vk!Y1M?j(~xTxnZ4?riK*42YD$edH7}B)QrG|^%FW_$E}7H
zwcRWYn<pwe*BhkEKUYioq(NUxLn0?+w*z1hkKUl<NmC*UAx$1OdE)H4(4x^}YW}+2
zqG4S$^tBYS7@NTa(ZyJs^#aj_9AmQ@(8U(8SsZ}~8|1ReHVcff`42?cd<yImIl|^A
z@*A^U$oeNOK>x&#213LzM%u{gXc%dOmJ9T`pgLNO&jr=dCO1E2v?fzJ`HT3XUbd@~
zFQl%S;CeBIv0?EQrxO0=$fD^D6t`QW<i>Es76%fmwX_ki!-q}^DP+*!4m>Cmr}yhO
z9lx5?4sqLLMy?+))FG$#y;-F2MQw!>Y3SbyEy&|!`YqsH+zPt`>ZO9x58#6mf?N#Q
z`XH;Kp>paXvJ{x7Ya#3PF0v1F(GHTw$Wda~MLP|ijepyeL_Q~9GW&y#fl98h$QQeR
z1MLryG}@-1YPUb2Mw&eucQ7c5K&vq=&}O5Xidhu?4ps+11=Z21vbaYbio{=s1-12D
z|1V(ylPnL-IKs^U7c^VjLMwjJ5@pWXMcw#SDwVaY5kSG`cAp8kanaPKHYO;G){Y#x
z7QbSe0WfH0HUz8BWL57X<#=J<tldj<7A#lXG$bH*R?D?YvM=NM)l!?*bRZ9swIi!R
zL1Sxh?Be!w4|9)lk8wx2<J_~{N$zFtHSS+FM&_s7dF}$!NBxoe6|xmr2?r4<G9%NE
z1XlYX;t2X6Fajl)++pKoqOAZGQYYCIQe{03jDOt-wu1Wr56G5+R~RqT9`*VK#G#-U
z0xboXnHNF;UM4D~qPAEF^Fl=1;!%*FiCzd~XBL1a2S%d|W||zbwis%1EN^y*z>o$m
z@0wjhlL0A^{w5Hiw)R&o66H-G1SU(OvPGOQO>|T?gQQN*M9F##5q~eIL^FU0(=z*+
zXBPIGHogBHZTpP<xAk=Mb42WPG$7pB2w1^N^OBMRf>zO(`1oA98&adT@rXzkJUz*)
ze>+=(aH^<XyW-+@?TVVxmXJNVFe|rk`t-v7)8hJM{I~gdAR6DGpeRjxYWnmxL!zcl
zpMEqsvSiAoP9wMa#ueF=+W#I<g8y9}GeuxmXlx9zhkJ-S2pL$O;GVK&V38HpF$0Ut
zVnFqbOL7JlU@@S=x+{xf#Vjls#cBkt^#mskjbf&;K9r1fQ1n7BgKSMe1c7m^dzqrw
z3r_w9R9Ht8@eNb-`W;Y&Xw%S;v#}tG&{z8#FdIuYWMj!=*;oo{`5Q1B%S^hY*<lDj
z5d4I^FLM6GG+Q#Y+WMc@_Tt;(N$U_TuR#l}?=tqc>!3H>Vnf5V%^3gq9&R!#3+*(r
z=i<egix>ACf@fE2RrA9S-JOgLT^a#EeB^jX`oF&)X!rvG0|JMp1PxPqPWH^s?A|>y
z+v~2LaHJ)==7bv>+v=bwb-v@@3NHv7ZyjEE5YWP7kgv@dEy$e5&se@TS@S~XJR(|f
zvuR#n&Ndk>#8;z*_DpdLqd-S9tRUxXldTPPv$Dw62F%6sA>$<=PPhcB7Z_6^a~?6K
z!kh6D?9rg80h&Tl{X%9Yp!$WZ04gh)kEIiB(V%ld{bE@&<UaaA^kG_Rlu3<t2RRy2
z%}&{W3(SCK0WW*Fs6Du$PP&tuB177Bxo$X4^zUGPum@Q*1LK3Cm0!zl$vqQ0_K4GY
z2f78BqRnDh^8*m`wzLU}%r)|>RjR1%rY~l-$@H##yb)l;ll29HzVf$26a0%);zIdI
zer;2N3BPuO#zm!+D5V1lZCl4?yOOi*BU>hBkZsKeQ(WHsgg%;*`BPY^!}h63{*xkv
zb~j6KXei|K?_r3bmSUmp3`m^Z_;!fDuHlJVT6za9tyWB595cRMuN^{WJl3dp%9`Sc
zEPiDc2*UKV?0yVnJl55juxETL25oU?KL+MVSxh%ILpww@oN&Sx!r#H6QAdok@!T0V
zlBVr%>eDdU)HE>TbVf6X*`(cUsN!wgPol8?-u#fo1CBbJl>-_9Q{3A?)CSq}x5E{J
zZ!^*A6g$~4#T{*=6}Fe#yEY>)N98$3?aeDU4JjJPt@iETh&kyj&)L{Mj-xC?$w{Wr
zY1gazgga-;E|2VpKdK`%F_OX;R3Ok=5y3Ld+kG3TUL`Xo`+`1rO*Dm^L)Px!z>FnZ
zfid|2)9F0OIFb$LDnWjP2UslR+-q_qMI1zFra+XYtY3vH5Xh30`4K}QXNjF3fw%&5
zudSlnnjN+P$s~;mgo(h(5oJ=DGC)Kr4f36tGBl6@Ed}zOL8|fq4NG!<+jJuSV$1~^
zUs%%lI&_AcpiKOKfH7)<Ih%p$Vr7YIV7vHsQRa5$DEJxZT2ki^)+5ahaPWsv&q`I*
zuMv>O&kZ4sc7H#l@maUD^se2~(z-RF2}ArfHWEfskV{F4OAx$>jBQu@59F!lWX;&W
zXV3B_`}Yem|KJVpRRRp2uIXvrx;1((lGSj>E!=i)2e+HCGY{FA70<B@X_&iS&P#&1
z>ro&42Vhpn8Pcv#dujyJ%bY}HPYGsvMg1w{Wo~8qQ~SvQn@+^j<T;ittvYjkBPm4O
z)9lcOpuVjp3k-><H!GL}l(|kyMIHSIz!WzYad9)5TUq$4$*wvTU~JxUQ)sgY@NF&@
zi#w%G(!Se)7=%0P$U;?)xH+MzH>;yB&dZzs<-I~iMp(DTODsZnoY>HLu1cj}7IE+a
zvE0K$@hG339+F?K>e1BU8&o}Uh@XzSXu}4kCO08~ko-O+PgmY*giz_>ocl}o;;*Y!
z)(OOL&K}R?wi}XwkToN&?&XkjHol}}-j+j^Ue-K8Xs?g3Xa+WA5C{2V$V7g*^sSK9
z>K4Rw{&lS2#;g>`z_eQ_5?OZmwxk`?s>Ha?zBXm;8l<oskivS%V21XI-2^qZF@xEY
z#Eulskbkk<@E_V@Ics<oF3d{d%W|vMXi3Rd3XJ0DVzW}nnN?*isfmywetxsV3i0%|
zYEv@n0T@71K-j33D&|c=1fYU6wKR4u^w7*?u~VBDT<9rvB2Qa?z8!#p|7^LS=o)&k
zgR*ky&EW)VeT;{Bw+J#gVgzZO1AN%g)OwU+^8gHD#;2d&a=dVP^HU27dh0V5o*P&u
zO#JIu;r1(A)3j>zAex&{gwh!@G`f9Z8&jU#&mDlcPsiNr829-$i`n=TJR28S%!WPp
zI>vpv09HWFNz}DQkA|#kjUElm!j2vd)PSfUva0oBvYgnnonpo@*{UF`TFX|2nrx?^
zl5>#l^c$P*B<fnDM+3E?kb`Mpy4L8?uyZi&9*rVe3R&3gSV7LnF&8`<%}?1{WzrF~
z7s=2h5;cozbU5hW+CUAk1!Tba98SKN>;sa8vFsNP#s32$RL*V~)*y(qn3jnA0zQGV
z75L?g`P1Nc17r=c8(&N;(OMd~qzoDOTK<Wam}Ukdy1e&Z<d!Xw?7J9pJFtW>+Fe@e
z{^qRkRJXXkZ@xRGvh*KBk>4+i`~sQEq(PSPDzXG$t({CQ?So3ZgUmm>j45|72yCt2
zDM#u&mgt{fp0^x6)ZSu=fgj!@JuRfUAc_}0`9vrp6-5I6l(rYqmbcs<;W}~TnkUD)
z4t0O_)E435KLEpGA(j;(t4n*0FZE59F1Wc_d@Azvrns)7$~@zrXr<Fybp1wIES*;A
zR}HgR+~#<%at0WiZz6Zb1a2}nm7B@U;TCX9xs}{%h%Vg>ev5}89uy-yp5|n)#Tm$I
ziqW8-fuh7kKo+vk0u?0)5p2<*{-7ukLiCVF{nlprvZD%<gN{Ty(46d4OLG#lWyp~o
zGbu)PU|!RjJYW0h6SvDUq3}~F3<^k$ftjl?qi3BUMn@CA{C>?PzJ5s3l#^aLZ2R@1
z4u_Aj?asCbLV>lY4|w(Ugo$FxbCoF)@JB|nBM1p2|ClmrT3GIj{|hMO52E+i(YRO=
zo2tzpmM`YPenmx##rhq*P$X9PSdz8*TCH`l$uqwwhjgbp_VInO@SoV@T6ly`jg5(k
zrT)d*$<f;O-riMavsZpe?#Uk7a#e^no#%ycO_wf-d6shj%5o@BIBv02CgO|ldIgOP
z3(63L%df|(^UFF26IP5~4?#s|-5<ZJWxAVb#Is{^dR+e3KhWfF0ZqsjFIVYn66oWW
zDkbLV^fUFP^aYDW)U4L8qGw>VeKg%|by-$fnO-p`QRh8I*IoKh>0`g5U2JR&op5!S
zBKC$4i9e5BS(?<VmoI-QS?@Dm-%~Tt(l?@gd!h2DkdXemR?1a6i!cX<Sk@}tYGF6L
zAmwvPBRh0ZDT`8d{u6ZtmF080X1bR6tQ_0FxU+kO=aLGOXNl11AIx&In5D7vef{6J
ziQL;9Ii6|*`v=gb4Y|z(41=ErJSzrM6v#}aDE<Gjid-X<)d_Yo+AScsziJghy)OtG
z5t^BGBqT06#eDzPBckzINQ7V62pD9Jd%kj+@Vh&iI#an)nQ-~5f8fW>!w=!ScZV#`
zz}dW2*F2mq($^A4If)|%)r`5HULAH+jlF5a@%*H|OO_Q3bl<UCyX}M!_Yc&#ai~F`
z()I13SFD;?!`x_WyzwmKa=uob`y69QE<o<{?;!X2FQ~K$xzADg!X8V4*}mkAqFsTP
z(T8RG8UPU_sCt1Kn|Is1E=!o#Wj$kN9CBi2pwjj`O!wk5(8v0U>0Zbxn<6Dtpe`(z
zs2@$DsELJ<Bgo0H>uZ<NfpmyN{!rN>vW(tK*Fxs=t@M7ni|(Tb=%e&;`XqgtK2Kk#
zke9WYsd4+&NN=Jm1PB!=V3h#$kzva^>dy=y%v}Omq-vQc>b02IoC5wgZz;KLS<&lB
zNRCg6<_PGo2A<N<!c?ERqJhim0~J_4{tM6qAOwTZ7<?6_NI`wk=EebmdcrV)`lUCM
zH0k8OxrQ{8J~=c*&?nsoucP!Sp`m<e%WY!uZ9y%!Fj0DC-E`$7>voVu?wF^X)x|9#
zz*V6jb6s4v@Dr!|3Lf)Szcw*(MA#p#4>y~_!_AVuiPNS_>UJ?EqbWT`uh%R6mA>(Y
znVC5;(NR%pX1zXC@D&1+!l#m5w;JEviX`e^)XHdnrqT1AmN{oQ{X%ziq&lx{$;x*$
z`}Xczsyp;t(t2W^WtnP`1~eh>L<rCugM+n^;gP{$qCICzt={N*p?^IONicYaB3VQ&
za#c}pT;{5FC%ws?kfE%U3?ir*I+jczlgU)TL~E;~TIB2_GFSCka+17EUIVVGtOWK6
zXof=e5vrta6tj}~Lq7E|8ez+)p5&16R7OOF5KD`AXgI{uj;E*+Is>%E=YvMaa)_mE
zhPhAE!f!v8X=sP9RTE}cxVCbrooP{xP@KIbPVhrXVaI03B1*;<vXr>pYi74vIKZ8&
z+^pK!CL<&n=v5=28_L&u4To9vO&y-KF|97mAc!_gnm|^I{B6N0og3KGFI#WQ%u;Xe
zQ)w}MTe(gcI7smTP0Ms~$xJ5Jo)$}k=}>PxWr@_Xq3B!M#2BRs17O6Xr^sEm9&t3d
zTMJMAW%EjX8Bi6ak<!U_qsCTD?zC-3M8xQcapsA`VrV&dwQeRTCf^|vhBTn`@!uwd
z9jFDi=_WWRBe}8ML~aT<jhoHQ;}$X=%0_M*#Lw>H_A+hqn(QX0xYNw$@;>(=_X*3e
z{x$bKXUlE^HW$pW9>_GwBS|#Dye4TxRs*{O)W90bgeo&#H-jem4wmQaVRDE(;S?2v
z%3v5p`w8Si{hj4NMVkwv4a}~NXag0&?D@@FvHa>ad=xv{z#OP{w6OqeFI$_Pg@y54
zQ~nCYm4qWmxe204ctmv^DzIE@8*gp_%%~@o>Mem74aEvO7;KstSv1>R>x}N2u;oUX
zu8I@VS~AYM`ma$-avW2gUzTnG+ORkzND)spF3t$A6Dv&CG%>;uo^3`M*TwUU@%n_+
zy@-0<2==hPm7t)1i9}N5ko#P4Yh=iAmujHPzKLtr&ATUHsOql91sjFVk;BrmCPW!@
zPVMyT8*VG+c$<5l`+)lxFbDd1?3km9VGcdZfMU<0mc_EDbs^nZUR6{eEeET{D5h>c
zg-l~=9qS3AjRznD%7YMtdx&LTKT#|5`p4umKpPjyx3>Hzs6HxV4cW30Pg{azL&h4i
zucv?((h_Fb7)BkjhHTkbO*b?<yaC}f28^q@z2uRrIWTUSd4oWyAc|&?Goz)15tKl;
z0}lJoMzw8RpDKD&V-Il9sG5Okqf6wL1PH7V-?%Nt4NF7DjW-()Ztx$~b;ndqZajq#
zr*K{W`T~WAH!<)~Y-wtz%LoXn(UWr!UbFv3u*P438J9QTayv)mpU$2Z{)0KX^2z`J
zu+KK8jiXNF@Tw-n9pqiRA7x#$!5c2b!=_OxdsJ#H9hk#?IKvvUKG<whlSyS0*~U~!
z_uBNqYVx>$1V}^Xlzb10=a{)wq#P)o*JN%DWpTXD5jTiAFmr1mEvl2bb#^n<{rKy)
z4Ych4#Q>UGmtChBgBVhgxBx6m236pNzace;_@q_mR!#BqWhN2_Bf`yOP;qcsIJsgN
zKxshh%uYI~<x;72t0smQ%>h|pwC;@?G5%U$%u6?d9|Y@0S2yC<D>!sAP3z)MJlvLf
zXbh)Fa;B?WyG-(uQCZ2~yzpp)&Jw!3j;(^Wf@q(rvxV9Tk=krWfYH>NVNK~Jkz;hv
zN&4Fmof~xB=84Oji*_CEI`X{^Q=-<tF+Ts%-Tl4GjuTB*&oz6p+Z@=`X`D1LPdIS1
zQlky3hFSkx%Q*3v#lriJTw05&(Uj6*;1_9Z-s#o-B3H9f_>qRQq@Z5}`4`AY9me<<
z6Uh{^lGIi*e~cWpWo$h~PLns7QrLe8qK7XT2emPj%(u|J&CW`p%0cf&V(pmMx;rIO
z5*&F3Y`d=o0r0A8Y>F~#02RXR%AB{yBck;8hBARm%hb;0)FALnjhUiR%@a4GfPRez
zlY7FM1tK@1Op498*?<?+UkUIB<xvg3LPBW{X%1Oa_M&P7J79`aZ;Rn#xRZ0_?2Vue
za$QhDS}RDuZ^}*))~kHN`WA+&mDZfb^^mwU#KeecVsnLXu^IVEBtM2)BZ=Zx8!jqu
zsej~|71D{a?mJc<eR4^~|6}h<0HY|fzq`8UNJ6g3<PIUnWHN*+B$Erm8A!rSz<>~t
zGu)TlM??ffK<*?WvWN<ZfUctJqT;Tih{r0R%in9gPXtt04_1@u;(M>Ud#0ynCNl`S
z_^pJwx~r>x_3G8D_g=lK%I?><?c|;JT-`~MYcL|ibFSoSpQrN6^^nVp0hQuEcS2N#
zv{xx=Akto?>iEwOV4mc2a+;hY7a%GFy%xCpSOSmdv|0Hq9%o8$_c7ObD$)tCqu4oZ
zQ#{U7*?0}^K$ez5Y~Y0WjRQfOm_ktPMG~M_L*p6n=CAM<kEzU)D4$nVA-VPgHLd|~
z#%?e}*=AAXW5>?lMCEAXWon^e#MRS0bZdMl1dT_3rOA?f55EUl`d`*P{+s>{QQFXs
z9QoBXjo8IegRif@<L?oR&BX;HM=jBx4%pqXy(v#d<G$zO7BnwzpV>X6XyoIj1&Kvj
z83pDJ!cV`-{K&NwmH|GFt1&N9!!3gy$kuS{xJ{7XHg<Z-E^e>e9;eT7$GBHuA2K{W
z<sFFrly)NfhQmEhaVIj4?L-zzB1yCy18OB%L^^36cQ+jgyPJ+DO`o39<oXhVvm;l$
zBl>^KyJ1T+*<+ac06q%!a!_AR3N)(GouM-SRm(wrJ>|zz_x4zT>VrSsKythQT5sL}
z>6%A{)O2t@Mj$dYHYT?)CX;P4(wU$OM3cKmPAbwkGtwwLen{i(F-97t5w6gQ@mnen
zZ;S7@BNxTz!JF@~YuK~Dh1PI+^B{wKXaEfl2jsJ8=-GsaLVQto+ZsdH+S~f-HW`hA
z@Vh%~?Ke>kULryNB5!)z`YYzw)(Qfj@@VMgb(q&Z)0A!yhzcN#oM#*~+%QYOV(IR+
zU2k3IxaD_rax1R?xEeZudi}>Q-_I+InArG_JCRD`e-5kx=}5Y;)uq*J#|>$9X$@IM
z@bolX{ekhA7#)Fr2FbJVI{81g-UD|w{|ZL_^W-~N`O!!&@d8_C8o`_SI6jHTvrsab
zk0F;Y;5+hN_!8KOv@bu9ujGfp{^q0kYPWqiZsBj`*Z#M30BI!g9Q_H-aL5jZ-*}os
zGdpsv=>k^GF)M5{2{<wxR;J45xwu7O{Gk?feKs|*<KV=x&4Pm9M4-Gtwh`soEXEGm
ztpIyb|2A_Om!~4E^ra%)bQM&Dlk)~{y<yxx?i$d|R8f4x#DWeZQxb*nIvttxhqe$R
zKE(5ZZ4!!87V_r!zrno4HJ~?q-(t|v`fY!UxG84Ns8L<I>-yC9?_WgM{l1ikt2H;V
z9M+Dm;nu?*=D+m(Rot;Fn4ks`BcH2=XQkj?6~6YTxP{zG)<UENp1*o0tmt^0#Ya3#
zj*^$;bKl=4&UGB*ThJjex{}H(I&k%93_B%7nWw<ryHJPd!Iy&$F@V30zg}L^F-cz0
zv4~&sU)LV2X=Y{+OTGcLTQ#G&WXd)*7<%&q;8T8VWN(jMb1DPIY{K5u(iRrE(y1-5
zMb`fhJ_OfF(cjXW;M#qh{+pJ4K)zOQLVgXp6Mj`)q4BQb<{90sy3Iyo<__DZON)yl
z$@Jfyn!wl2Z<DOc(AEAX-Ua8T;<u8+;so`^;{OZYg-`#I+L9+L=d*)VcPz?@nVU|h
z|BiG7enFMKQw{%X_!<5`*A@QjngSZfs=YP!&3@Z$!Zm8iwWcW$p8=PD%r=ZAC#CbV
z#MA7okze3e82rHpbpN$C+3>4s2OnyqCy9K(dt+o|NlD9o^Qv^UxWr-)M9cU5W37eu
zoRN!oNbe{A6EhB80waH4(+*dA&Y>1oYup8q2lsM&xP9D1>;$wYxu>~jxua~?sgn?S
z@D|$v;xq0v+v)o|?jqN~c7QOD5E4$JNF2ePzAdoFCGG}MN^lnlJX>`*xdC>8sFtG-
zaBs_{WI6Z_aQ0!dd<Oed#C>1OcffP-k#qLpd--%#9qjZS%15w$r=-~j8{eAGR_$@w
z%em|K4bIb5=kPaOYr24DY`!*K1}y#&EqM$AKvUj}8SlRAz(+m22O3<?5(vy#i3E`6
zajyNCga5X_;2L)n+<HUBLX*i*Yc#gpoi(ykSwqcLm`phAW2S;E`rUa6beC3Ill75?
z1HY}8!0qU<Ysf>;ICXB90#f?Gj`ig?ZxAxu3HM)V;DN9GB+vey+ygg`(O*BET=jjf
zf1y4gpZXC+V%Z!5>H@9V9D=gnbvfw^I)VE>*V=gm>BMzuAIc}l(`;ub*AA3l!08{Z
zof>c_N?dt~5ed@SsJIhl8+H<i6pv5}C!<O`HB>owYMAvut`Wew>TFQAM+;Z=>@Xjj
zB{Ur+;8i<71*z%Bq}$OLqM$4kjkPwpEw-QO6-jw<S7?~iL{U7hFa+@$J5K#KnL5yq
z*3n4@Lv84ehT&JVXhD3(bJ@WA(vbf1{rbYf7JaYYas~dLzunPmxzU(<d-|X66USal
zJ2CL4YvWw7UtKR~Xf}6k-Kbk{dW7!MfBK8pDG=>yfembEH?%Ptd!%Fp5}fFB3x>um
z&Mg;c*R4klY<}U92Gw@e|IOVO+zv^vy~=wx{X*TK310#3zi<Pbe^D*(zaX7|fqKCj
zwi81=#25UDpk5&D82J~X=mjs4f3TA<-eNm3upJ{=q=B+eHF^wi@5mT=MPw%53j77Q
z9<n3fRgN?m=!`U|=I8$5DbP$?_&?qP&q;?-*aF)-nsM7ETLH<B6bcO{-0d;WK(4mu
zAVA&Vn%<fTJSv%%^av6uZ8Y)U2`IR>9Rvn`(TaDU=n<4q7c8u-*hjYTd}!K>A@j?&
zkXoMpm|yhwxl?}@uiR(gbBm^Hc8)+lsP~{vGkf)m9JFHBumOL#2TmMJ+0wY^qiuUj
zY>lMFJySj?i0;i#Y6)8bwhnoa-o0_u(fsIK`b6;N+l01P>NE&MAy6M$@!!+}_~rH0
zv$Cq_V;}TfG?nAFT=RNB9-NC+OuCYuq!;PO&I-MrjBu`8oJHo41*C?pS*T-YW8s>G
zz0MsSpCo^i&&I;tncgJt65Ja>@)w+kwTnLy2iw^Z=MY@yWLZHYXveG9FZAID{-Fh2
zwie(qD!W_KmoqhB7BbRO^+KG%sI%u<Gi|~j3lI~pJS5;ZG59ZQT|r=*A~m_daE_6_
zM^Dpt>0g4@@jMAR_g50Z2S5J1bN2r+h~psM<URv|nCpBfeb;CtZ4G%-^m_Y^qI4Rj
z?lrTyA|+=->Wsz(V6|7ke$6WL{aP8Vxogi(Pb4kae7-jyKJF?Yjm^?I-e|Me5ZrTl
zHM7$nV&_P??DSX333g(owBIt0%D5sxveS8XhPN~-D?1nAsEl@cv2#U$%T9;Wy#E-X
zH6yfD<I~TFK~vhM2)^Jp22TIBMP9Rj8C-=O1DZS%`~Qcy|Nm9voIa{J?|I|G#4Y<1
zpKMl|INF@p_NN(b&HYA~-uz^<{qb8CUWHLy{NBfr5Txvnkv#A<fWNv|Uc2h=oYP59
zU)yr9#fgvCSI!+7S7=;Ym>M@XrSjvbt1_rJapLsY-_cb4Ro^GzYWm@EuOMZwfD%&1
zV)q7<p`?n%?n(3Yv%&ga0<n9_eEk--bHEPSFaHoZD4!cCtpNN7jQ6Jqt^maIsZW!$
z<QwvD=Xj5&RlDZwEo{ynPjo7B?o-(Rj}cxo!h3k)gJE+AJ+b5yyNOtWf6X!8!?^z)
zhU5LO4&$BO#%}SQ#&)_=a=yV_uK%XI@#zh^fBtO0%ES5Z&!hgoYJMAzHn!WKD=lZ-
zKuwKL>;B2NysCru@5x^di|nou8=M5OmH4=qpXXjafsN01kh{p;s<ByFo&P*}QC^*o
zbLP_6d=7T_`5wk*Jo|`eJN!szJ7bK!6i+9`*sJ#tuH=XRPmj<f)dV}?#|ai8!xWjO
zIm0o)#daRU>M!@1TQL$2PA`DT_E_^D{_@|8zg##Zo}D>rQSwX+-N+wreCUdT<X*e%
zfH?ZY&`zC(;;YLahW0gNXwxB-&KfbGIenPux4_{w3x52?F>ulVd>J8c|LHVj2r>oT
z|9dj7VeBT{ha9JGqu;<Kz>jE4dcG;m6m3a^&pdl>4E)Hmr{%`z+hk?YN~_pl&B`JV
zS$Tt1c+qMl^Bc~>`!1`MuG7a_tx|rMsBjVTi{?11Ge4Fc=9L>GT+GT6*Jou}`TO9_
z3LoNVn~gtV<trcuz#~5&&+s4^#H7Z9d06T5farOE!_R})Hmi6LvZ}E1Cu}xxG=Cq0
zam&jq786v>iHCH7x^)3W?vNm3g-)zqHdZecAQ>W~lZ=*;jlmRikzyu#9xHqTzSHx>
z#Oh6U*=%&3?hIXLvoR8mLV`BNk@<*S2kp|JzeU)~@tmFu;+jFJ!GejH!id$RzePOA
zSBMXb2X$TPJ9Hj>rvcm!L+Jr}fPYB5M27A&JWLO80&Cko`WxY!5py7E01W>0`07I|
z$U%IG&FLbtMmRzaHf$ybzY^Yo>dMbf)P1aemRL-7%tJqst{^wl7B9R2rNcL&Jvr!@
z&i8UmCkLI+#=Doxo`vW2@%V)J4|w*-3ol5e>h5hEqq|os)6fp`knyI;<zbnIcJRbJ
z_UvJNm#`y#pb+q|E&+HBpX1Uj#BPR{E@2e4jd~N`^cx!H!fl4_aoS+)r?2HAxD+l6
zd5qUt(lhw{yr>L&t}e=$$7fj5b$m>86ilRNMCmQ2yh4c2v)YaQKBJ31`IIjC{4=uV
zlTXQQpU-}d{`sY2^pRuFk?USMMg|=dmv0KnyuXy_>i9BO!quPQgLog)zd#>8_B<K<
z4WB<|Xy)STzag#Fn2P*k!r(zT*&!w^AA$uTkRMJMvax`{03gze{?_^X$OiG%(^KP0
zR!^8&wsPB&-UI#OB|9fhvfsF?X6BbulZRHW95!lpaW@Zo!WDn?v`T@G`LXug{JhpA
zA3vP<@zkn7>acKn)z)n@*DZbJ{W)`vZkSM0zH--+zQgMt_FIdv4P_lWE-%}$VfLn_
z14d2A?KF2=ht^OH=x^#aXvJmwuZi9gW64iLN0OZw1bcoUz;kLg(S>C7mKy3P`iH|W
z+{~9=n#gw*-yqw^(^p<aoR`fjRy?6gqBfG*3|wOjm{&&8zw8}6<F;e3bRXFzg`A=5
z&3#(mHgvRK-0kR__O-nZ?1^tl{yh7W&>p=t^v&nG`=>9{&f##e$h6!z*jYPOu%n)C
zL~fBc)eMB<mG^DjJ+v?ROOJf}0D9gW)OE+w4Quz56?DnYz3zbDisWtFyKu?@UKg<_
zioP_le#QM6Sv`joch$B-rvKUm!=x~r2^R?DY4kunNb{b2g<pJplH(`-yCpD$yYX*6
z*O@Exk4cYxF*QH05Nx1A#uV5A1)wk-SXN-p%ZB|%qV2hXV6GT3_-6XXT{jQuKWBEI
z>oz^KXYJYzs}lAmt=hH6ZzXg~N;_YyA3S97%&r{@I?Y&CF@Pk@nKQiDP7h4#9MXNp
zN{{}T&vo-(J0f#_s@dW+^Wqr)uv!%s1X8d0w6afr+bR-n4k=r=qHgcn-9!4VdurhI
zyGo0?`K=fU7XK4b6GJ*ps9Uk-{&|xp9v@e6AOi*+ZF|{3-W2+;ku5SU73}6zVu6@(
z8=O%WX-PLl2Gl?=(J$#~P>K`9taUo;y3#Xse7{ZW)@|}zhgWGnxIT_KR`TaErc@uG
z{m1}%km4|}>C;#TztUf?AeTP_X@YeKxa@2ljbmTV)ceK!jfB-vFMWDqEeeQ#pm(SS
zSqMFsM_GmZfq-u)&!88{T=Ddq)p1?Qi^f*>xOwx!vfg4%pmiZT$B)gWUoD&Y<@B`c
zhZOaIfwyxvkyC2sK5lj8%Kf(iaFH@1c#gjYW9(&A?<0C_>7<&GPamtQI<T^0R`;59
z3(5xE(D$e~S#C4GO%+DJSB=Mc#dG@2G1+L9Qaz1aYsKXT(oc-4ky&OmeSjnM8#U|b
zc2d2eM(ioK5cyl%XTI=T4`rmLM<wWYRM8_iV7s?ZKz!$O#J-G%xx~?9+XhTp_}Jqe
zhZd%gBlKWYcGqPCuM_76%6D!<_-EneeduJRQQXIxLar;<Hvq1a^gicsp3a7I*d0TW
z2$wgmpX^t0^Ui@KWJ_^DUiTl(LB$&vbnhgVD7DMqQj%@Awe5F@--gS(W!T7?N&A!`
zzM?msDAiMZ^nP1b_ln}4nl{Yj+WD`oAdU7)<pPit7wJ<QNeP|K+r(Lcb{;<2agqO_
z#<4|d8ICh}=mDkN0RMQ6UNr#)zWx_z1g8e|TTH*$zN~Ng%xR^4Ha{fxQ)(5xXz|i{
zNq5FA-0Z(~bPIcS2i2f*$@H$p9Xd||)qpOOD*I2=5c281aV1Pc_(eP^D3XwA2zZXI
zqy;JUmKGeL3KWpCaFWjIly5IlxUtWG6*~s@6niQ4Zj1bgeCd}biC%1k6Q@YWNfmt-
z-#Vn~rYYi7sn+yWV93LJZC-VVZd@<_Ev@JfsQY;z-2zuCHqbBVS1{d@B;M;B=Elc&
zF6%I+y63V@3(NYDH#e_ax7lxfWgX)?Wu%*ye*KURC2XXlPrCFCfxDMpG>*}4<bpXf
zmkf1{Bo@vTN$ebW7i244xnhbmj-eM85(8~mNFp5$#V{9NT}UsG$c40l??{8_<76&G
zTzpLC(0z`Pib>w^6Rf0wl@DYX-AGeuTae@GveUUXZe;@{y;|emp@^?~HNYJXU%2RL
zPs_V;oCcv9Un?$8iw~9>`nI@z;QY>qk?nZX7gBMkH}l%@f(ENj)sE3z3(n$(Ry}r0
zjSDTzMsHPnif<@}wBw?JMhHcdTGObaMK+;Dn>z}DV<xqlZrXNLq=V$3a9Pei=mqig
z-i&3(w+cWHYzwt!vg0Lpkf=Yncpm*#`EImgJ2^OqRM|py!DE{#DYmkjdMEGmG>RQR
zDL92yPWxC(&86=4u;Z9JUQ(tQ$ZEPqa*1lx5PgG|unVTTql#ZTjbFzn3Lq`vb}*yY
zqnGM6w94T+s>@|dZau7B7YwA9yWOiM*{d1@*VSKzi7H!HOR!Q8+t%@!JI(l`p0=)g
zo4faBuU4&lEfo7!jsJodL)P)OLSbQ#V$*6WKnJ^<u#K7)=f|mSS{H5;%qLhlaIL9i
zwAOl+WjAzhWynzhrjL7Atn{n`S2vm2u3D_o?zXCyL11B<%68RaRU=h&Qs<{4h}5h~
zb@IsWG)(D33P3H#!q~#hXT>DdLUZfq>6{k{?tQFo8sL2AsO;VNq|Wx&;-#mRvDk~%
z=>eYEIWBr;aXDPErsaK)KPrpU#l>!PUJX{}#F~+ZUl=iB|H?r#N@~_KEAx4A3TuEf
z^}g#N4t29H^NVMz?Mp8eQOl5Mt~r;f;bHaYBs*bTY^)un=m8IFlD@03h;Rn&N(~D;
zhbzU7)It<E$*@$93!ePqd*sq$b|Z9+AEVI)-UGMWP^LB)wG{wfQPVgL#xy%vkm}y&
z&r);|Tx~O|Wyh}ml66>HoNw>`Lrie-h6N>H9j@19tS<$2`Alg8-LTs3?Q?By`fc^7
z&{DJuCqJOrg#-I2cA>UHFy`4>b(8EwS09Mv;<<Ent(>D?lPyqBpWHyY(-~j|&Qzq!
zF$Jv_<90XePm2p}K^LAB&IY}*16QKP<ZDFKLTqwmq&o)nUrfKe3oX6rJ^O3|OK-j2
z%IN%&f?QX;c=6KtN!wx<Zt|pbsbu2~S&TMbr>QC%Pg^Bvs05>LbgAqX_RC93Pw-{o
zsdx!Dmym5eH81UST6LX}i~0<dtU864oJxvrFxYonYtg>bbZR<4ZO#oH?lR{*DmX?l
z@6>(7#Kwb8ZY?K|rM|5=SH-*yt{0t_+cxJI;bytf4$ihaz-%~eo#e6Bo6Xi(?XKad
z$6cP^!7bBo6DZ8on&b!phzfAcvg)^uuBsYM|D@P!AC4YfwO29BIF9Fcamx&Gx(Ika
z)%Cp38Bs$V%kFuvHW%hizVNiJKt}QWPHw3ol9kiaRgT};OGD(Ss;W`+f)Cs2!?B~Q
zyc$VRBq#6*K$~NXHc?!hs#MjegJX>T7^~E2#Rg)NiCCF5kNHBL-vD`jrX%k3^66vL
ze<tClkL?{iYt^w=N=A0ZiNAGGY~l~gn6EWj0QX2J<0D-dl#z^c>MYg*TGjsyp8g}L
zILRJ)tS3&=U5E+lw&SLaFiBU~CEI@80W7q}&F;8k`TZHKda!vop5Fsy&jp$pxNwe>
zXW7ir5Htb+bU!$)iDgJKVLP)N93MlLU|aFa;91JrIGMAeU(ba+pqVk)UkzLPJ!Tth
zU*=`<3&Ho0Y=FuoP0Viz{5s(4aG8cGj`KT<WeAsB%=bhUf*=*{io9wrN=Ldv*@qY%
zB0z6XbI}1jWb%xY)4w8%6T=}a)<NH(r(hXOwwR0^wv6cO_+fkQxn~b6GRmos%drlw
z*&~5`0%ba6IgsQk(Ip97J{^ODRdI_V6U47K2WRgnBf5Gl#wi^@xrTDu%w;hZWH99a
zhAbyqx$^fZDOAP1!HRpSzjeVrvQhlUSCbOEudbd|cI%x>dRK^p0L30CyN*@yi%Ao6
z=3rFB#PlI@RD^@N#1$tH=o^OjWI2-S!r@nvsPMeU@O(La#MV1!LD0i{bLSr2SY6W#
zf*$$}uYW|etEo}BvD7WXp?DrdIM6XJ$^hS!O2BkVmNU)O?QK;_8mCK*&7BxdA&5&H
z$eaaa&6XN5VY5Vsdh!|gU62@x^a0&fZtpuJ9}AfX<^4^TL8`X!DTP#Z{~N3OcZxjf
zeuG*bi4~iI^6pd^!9z09@dzYmCNP9l=eOnlWdog4)z@Kq*dxxs1wrjaF}%&-{NzPm
ziOC8<_^KvE7agY%2PPO4DF(8iYyldL0UDtkgV;BXBy)8O{YUgb9fSw;;479R7{@CT
z4fJ)w4oM;WK<N~$=Adu0zVL-C=Ww1DVvL%WbgtTa`2G!FFcN$&`9qcsl_&hgRHa|=
zoz~vIaaH{NF!#S3*+Le7s_A|3;mZudy!dYO{A4K5;UQ-`sd|j!t#_Z#cOk`gl06@W
zhY;gOvdbehrdg>ncQ2+nTd7iZd9Z%0k&fb61tC4|ba3cMHemZsmXj^H_AV+aauW41
z@4jF~Y<`F1kV|Y<XInSzB+JCNKberwb>-NpWh-kJ_3Fn*?!Nb4Mm!?R(C>!z>%3_v
z%mPnJ8+si^Uv=t6pOD=dYFjWF^n9F$S9!*5z~1?J)<S2TRgBBdCixgk0}%u&jaPhl
zvU%9@k4T?!i~BCN&b_HYOi*+|VPfUU8Hcp`t>cAh^Iv*7Oqaa2Xl(IEj$)1Wx5KUr
znLifv8#PX}tf3F8a7tF65kmfAjBzX&MFo=?ddYA^UaUJ-8dB1ywq|fl_39wQz&Ts`
z^l<#$iS?O16S7iMvL^4+;-yjBhEJF_UfA=+a(?23;f{C>;7`8oZl4h|JHHflGB+Cv
z;{~0R)f*LqAx07)Z1%_n+Kr~$Ed%-;I#@Yj?67Tv`wy(#F<xAy0M)`fIx+3+>DIHd
zMpymmp5db!N4lf)OGgW~w{tG5(3Wp^K_dBV3q4OOM?6^_Gq|R<Pf3qHTjmTj1g%zi
zgIA|!P1v(*a#o5KsN;pP(<ThxwsrV~iTv`@4a3}llDDI0<aPh{hca+kySF{^sQU~`
z8Z>JmQqegDr{+;0v(b&1r)a0p!xNUwT)5+*zJu#l_v`KWK_RBFD(Lq0F<PYJ_b2SL
zvj2Mbog*g<9=OJ_${i_h-Mbets@obds@mF$ZJkW)F%}d2<wIYx=eo%125y(7YtD#$
z`&Q4H^KlPxp@K_`sB%Km>eiFQQ+(S_S=JvLD%=sd(<=isQ;ZIBa-O0S=5{89?yc?K
z){;HzhVET@vTo9>Eqir_em8FJ*P~~@O^XMH&2-IC2zNZTXYWBRTE`3Y^X&N@4|Gcx
zCQTT=^^Oq}r;llz?2efnjlXc=8!a8NpR19BQUR!dh;~yn>*lJ4b_4qD%GFP-UL6!t
zev`xD^qG0$BKvATrw4>R^y`v%e)<m%Eg{u1$Hc`z%&!WKG6o75XY4eX)i4|vDh3a(
z2wk&Aboz|67z`B^6^@yFy_O#CZD;~5%gr0^EL)O$I6DWSyn+uLVhZ9gw6fnaG|gVz
zJvx+MEk5jvw{#5An(l)lr$iK`4B~fsLUZHwShS>7++`7r*g!%-p&hgkudZ*y{T~;u
zUad<yzmJ|3zwiYFX8x?!OPsJrJZ1ffe&JZ@&M{hE2}7G#jl*ZFeBM-pI9?F;XoZnm
zebE!<UXIL@3Twt;q-mVJ3xVYdJ_vAN)yjkLf6aI+-(%f@EWXWz>rOk8n;^u#+LQDS
ziCg*lG1F^G3p|-sBZCsT4DUGY44@Ba;=8L>A6h*w&CqM@c~`&IaxF9s>p6(U8xVEB
z@tny~JhaYu357`{Poeu5ExtFfa{C>X6&00t!Mo#Yg-Al(<M2-lj7HvFHG160ZGWm7
zJ$8i0(EP#Kv*$eY2zPx))+6FTRNKAj5uio5<D(%k=*=AfgC2~5YuA-`QR@)94nDlc
z17bJ~d6R_Yjl!W(Q>RurQr+2_y!*q~(Vs$Fs%eOF&>bg?B9|$<w}X;1U@j;*UCP(3
z1)WE1>m=pigS+-Tti{>5t8qD#*R@qsr;gGJ0dhS0>mR<=_CaiGRo`Gb4ycGI50IGN
zdxLn)l$m#3ZuaW=L8U9Q#9{@O7SP`L;l+iO^iIBh^A0b1je7jWSpgLef(IW-5ezms
zELjfJkrXgkPzq6G3J0pCx44IXJ7xZgF{`&uwDlO$bIP3AZD$OgclX$=?xMvPMseA(
z)=N8A7Id^F+bhOoTXUwhFUc#;NV7Zs?cU5y>I(#PnS4+bx`N7pN&~Q5p%0Anb1GgP
zHLmT@=bjtdF<%_)3zy@KxKm_yan8p2iFC`<SW%<HXxq_4cGxfoIv<B!SaIP?u!^U~
zS#-VDUbqb;h)bu^HY4bLGkzcs(P6cplc8F+(#SB)h>Nozc5`eT?sDye9%m`tc!{fD
zo34-Vl9MCO_C=6=;&i^A){M1J+`np-2MRSWC4p~G#Y=j@(u`OH2E&Z+X75Poz3(mC
zQ@8BG+Qmtsk;`sh-XiEW$CFK<Az#yIMAWUag1ka&h8Ob*9<VqyE)8vn#b&ga1$$hf
z9l{5_^7E(L4jkBi@ys2&c5OK$e&7p><Aoo7AcINCS6|U*90#;q>&~|tKG6$?7)xFu
zYa@FTjYJ)tS9hgfuiMfxGRV{^C)YRM?h}{&Y5R@O@~i2-QGF)vy!qy)X`+qmg7q~J
zD-uI|g^TQ=JgK5jlh5crGRk+acDyi{ygOwi%@ON7>ERxuYYQa4Q*RN{1Z3rGVu_9*
z0mOIGqwA;A$0x5R<L8x(Ob$vK={G9w90{Qpg;_MDp(eL?1N1BR7{@jsAu+zi&-yjy
zXG}AtrQ*^K8?3l8fodat1cG{R^^mpnDLATd%sq!6dUe&-!%4???mgxgyJ<y9kudAS
zE!p{JmQvcViQ=L{_q9tH)#3*`K>-h=53B$}>oC=n2SZRGs7vxj&8h3xleAr0HEbpA
ze)bLj>+$%pQ`$}(aTh(1HaC_0<DWkRUU$A|#k590h!twXv46(MG#E5f1A+VIvL&C=
zpGeyO&0oBQKC^Nfsq#zUcRrqbqcCgQthY%|aheBh(bDjP6xV>pus>5ki<0c(Pkazv
zMJCa^NR3~3=Y(0a9W&_rnl?xOi630J)-xsz^o@W}RnggGGTpX;Z|)ZoZ>Hy_)0M(3
z4W<tMG3jCGRO=iPN9M!ozd%}d<=xvq{c+VTAMRM0vvStG2S{0U$tz^2U%V%>zxm|7
z#q;xL7d~|#z1P$@SA#o{HU=s(Q#;KR$m&(PY6Gp>uz~E|;1}E(Qb%V9Gw9u9ytZEl
zf(sU|nrtA}ji$H&C@8*1w@#l<rp}z{A6I1@e@D{b!Aat@xL-i8XeCZIAbN=pebcdR
ziDjIBa#f#?o@HLhU(nJDB8&a?2fc+bYa9*+A#j+M|24?;;63!Uz8g2T?Lb2I(Cz+7
zMz)pFhoLPecJ4w_=qfEn)SdkFS&$|6!20VX@yCs1seequ3^7R4erON)!+}#)pkc-`
zdj&MRLUTZT|JBA2`ooR%Ox$hHeivehy7+hh0Qr!eJ;iAL>(R@_9{}u@q?~^IEDt#x
zSo_8?>nfJm0^&Nl`VKnSu=<Xaaiq0wbpS~B?W3G9BlkYq_C8(@5H;gkHjBRULs@yY
zQW1i%iqa+x&CDYo(CP^K%9I<AzcF*t<Qb=4n>D4rxNOtrvQF^6sl1clN}PP7X65q5
zZ@#r?*@~Liw~d%SeZ;mqN6wfrLR*)XfsE1MJw-3BJynp@puo_trL}`M{78n~aeP$i
zOna$c$Ye47iarkN+rM|xzcmLZs1|E3i^cLs_ef(Lm<6iw=a-TG;=z3jyPHh=-gl>d
z`Nn{#PahliaJ`=V_@24}w%&jZ;I1RJ<q87nrQmOckqLAp&`Aq{lbBK(h-f>s`_#4#
z#BlGx35U`<wH-Zs@e#l6aE?r*+l5)#o$7Y={Pg;?1p1~%u9W&mEOWoh|KP;~0SaFL
zvbkc)unl$dSFieOdD4VA_R`UV7Oz>JHQ~mc#qnbo=KEjntzXrnC}(+><=wJPt=ij5
zr@-m1`7^TTm9{dq%xwb|(aLU|!|=mlpl?B21g6O>qu*|(-|~<9B|0A_hVT~`df*8_
z9zsk&Y69%3Ah{_5q3J4mFWtG}%~Sq|;a*@U_U4Pk7v6Y-hj2P~dj#SV{Lu>M<R$Ng
zIS^n6=ySKzXLmeiH}J*&w;JGYb=1K~a{kV?VNdW78mGmF5!HU$65Se^Hat#Dc5i@}
zMe()-0QmV&=j{oPi0YbOF#nTP%R|D0d*<iQ+n#0!D`?Z!f0F}zzC-Sq+P5El6smEq
z)smVo{``=5eom*=?>+LchSq`Ti0GsVCibKNwVoY2-us}Q*yz`Hz4B@uFsZ-&SI&?z
z^j>m|?4w6WHww{UT6#kamOpw26O+Y^5Cb4C-9SIw$kTW0-+j+7HvU%e9QZQ^^GS3h
z*`uLd05()GTPzUhb`t|=FLFq{mpn-a@cz9Le6CnEzmnfGUpt=JS<Js54%M^SY4>OZ
zqY{G<fc&&;LK9ZAcm#iKy-FRQa7YP9(2QNVm!Su#qZFhKNtD=x0P3(w6SA<*8K>Z{
z9y8qH7V5w4o;M?Uc0O$Mq2*m%CFZ9km~Vvz0;r=G0%7D7Z773ZekMP-g)|^ucfBDX
z+Dp9S9C|UbL2!#_2!QsLnlJ}fY=b}Af259e5O=x9HmLUwvSW0WKk8e(L_9E!I*<k!
zrVW4Cz+xW!)!=|S1|k_k9^A*j0PHKqGny!fKmglRArXF=g}==$G{S>dI&wYy(^s#=
z{d-180ME#A5drYaD6ioXD_M+$KYGX0&$8!tIMCICK}K8aM^2nEhVD!_e_oz*Q}YZ&
zx%uN53;@(bP6R^wxvnq@zm)$(6-<%9&-lT!pW0XqgFndvUKEUv!KjJ=Ad2(l5DUNf
z_}LiPFpIDA;0aqGyMnOY4H1_n;vx`?dpyD~{G<Kc8HO=AoP}W^J>B~pMnU<ZCd@QA
zqcH-~GuEj>GyH=5#4SL>10T)>`@skCmjSi%lr?MoqJim-Jsuc3`^NyovD`P5E~1X$
z2%vr6@Dk187wszOE*>!*o^1?KqW);8>f2IeM*xuNC|8(AKu{q}iUoUU$KHT;p7Qkn
z1TI6zsKY;2vzQNmqVpwH49GSN`S8#e0<ebI>b7*7Q56Y-x|$UK5rFL9q{KqXVIk{S
zEQmkoq?r^C>44ynX;Z7}zdslA2{46L-w6c2XN1UQja?~9OspI(vYN$+_`^@PJ6Kfg
zRtOrIHj3_xIrlvdSnhHQBU${(1$pj{`8ETbwo8k&xxz^NGBs~fg_C&pJ6u!h2cy+b
zR7oJ+Fw0kniC_E$J_1cNv<^To!}%#~v`GNi#RhfgiC?_;xdotj@I*jzP7{R^07yE_
z6_Vl?;wn{Oik4>s@Hx2rI|YS-K%3<ZRY@w&$?=Ph{3Ooc>mXz$clxeXtF-tqCeaVS
zf=5IXxe@@%_dKFl0s>0T(HI2V6{1;QrZrU^cvzI8#T)=l!D@3xwFH2cPEv)q_yzhW
z7U<Ib^lAF62ettCk!Yh`0s**E6Z+y8BwvXkFteX=g}``V4Zx?PcSgbl0y0Y-7ULJ;
zpCCA9G6cr}F86UNpgkSYV~e{|3d%y`0LIo?^awplI+Jdj4?g_xLB9ZBp@rlXa*P%`
zH}Fu8NAb9VP1|?CH3#wKg+`nKm%ez?jV9KeEn8>R(Ovat@Y4f_I8B&-pn6KiP}LXr
zKHzo6NiWTgVZbC#aTo~f)SL#s*a9agFId+0E?c<y<{s5!i^_{r=xcle-LQ3ATBcaz
z16#=aZk=b38rGv|Xk}}9Xy&q=_jWB8pLOEZ@EBY3<w2u7TNimrh!l$--I~Ne%rh8p
zwwPFZs<jEy?K#@_h5=;@)-UNkWAMrYRaGw>9$7PSDd{9mmT2lhOFH2pn`utJ*~R%2
zMh#fHY4(O4Wy?F7)p*ssmk4pFUOccQAEu6goH4KnS^-ClF_tJV1bwDv1KmL;t`nb?
zDOhg!;u%j^xeNGg@wtgFz4Ve33;*`XS4lUwaoC2dy*%lMlc0srxB|9yKy=%5-z{CU
zqeunqmQpyh<KvGloHSq?DHiAYXk~ia&6~qNn@z848NcU1ueJ6_CrJ0ciuiDc0L=&@
z?O<oLL_yG3KJ1~4$FJZ*0~hhIt>tN5FEl*Tsr!PB#X;sDyXO@Y(^(}IcQ38zFP6w)
zkKEC}ZKgfDWQ!+N*Dvl}F_CnLS`;BV9++Hn!?0aW;3WC!9vugF&w|M*_r4U%R%d8x
zV1+P|G-7Y67e6Mx3*jiwZlF)ppDA6R;n|JnPpA<?o#ng5(c!A^0&kvQpd9S1?wsX@
zRdNu7rly+_sAkWVR+<-joBgAYJ+!G$>9m>UeV5%u5*PO$B=$pmRy}|3{F@dnPTIO@
zVeB?f%2jR~P_b-E=MKePr!O8dxc*}Io^zbg`R$|gi-*q<-(I<LM)we$@Kg60A3PvS
zBd7sudpob~-IAe%weebwBRvQ1STUfF!U-kz{7z(x*h}u_Ph$HcA9&Pc_ns*?RSmgy
zai5Aw^hNXH2v=X{3!(M*9_|4~kQ#p+@US=EsXV^OyzD7e^*#q4>fGky-acguH!bT~
zJ*Gn$NY~>iUGMl)N~Vtu3O~THhUW7-B^g`NVc1|v#@^qtd@Y<WQb8(!_Ihp>{i|_{
z{vCFf0LD@D_UwV$^8{=f{?^`iE%Y^R`H>F$;YT|B#~;bQAATec{Mh*mIuFhgSaAAF
zvhK6b$=cJ!Z_*8KyhS&kdXvn3<1KRIsV+^ONTAB<;zh_BbNG_Zha4Avg*m=Ow?Ia7
zSVow!?-L8W)qU8N*WKsZ{HsC=pC=z&Azi$ljNr)|W3HS&ZgB{ndpE<`30H$<sPEGi
zu8>kbPG2y1^rJr9z$>Sg$N3Cbg*e(19IlWg%D&Oc2@jrpa~1lP&wUoI4!`(3CE^Nc
z<F*AgJ4FKbw9?AlAsnnN*Xli5sp?Pa`roPM>X6FMX%tsTFrTMYc$3#KZG5FvllQ2&
zI;2sbdU1txaGr|6!Hz_p{Bi>~@yhG2$5|wg-9$al&bTT<r^(Ybu8>&%Pv7v?=dQwN
zrmSLj-_HYG^ztqqSBI~fKEdM(iRbf#4^O@;hcWH?E9X09|8D0V<%;rqH5kqJDIr%#
zC!eQ?fFI}5CSyN?4Rq)@Z}uO|<ooe1iPYVh^q%JAt&f;84-O<naThpF>>0!vCxeBr
z11+AzNGTHu;(mgI)_&sn(0bj=KfaH)X_M*5_b=)m@tzLmMAL|_Pkp^`=qJb{Bm<Lq
z$xli*?$|M5rz#yFa^k~t+d{c82_yIb;q12jG&r{Wka&iV6NiXr`B-r%e%If_kk`XM
z2|ddEUziWn4F5^B^OX-^$GIJR1+%(h(O6&IB7X1B4gCE-|IF_-hC<D~<8Xf-Xn_Ba
z4j#`NH1&w!B606PY&C@<3RP%5nNB(FyP=PhHVSpFN}e*E6iWHZQ&m%UYDx6c4<g4K
z54c{&FMwu&=Ot54qMg^gcqjezn6DJ^3+(RbQ?Fx`X)Mx@)V&Pn=qdc-H68iBagct#
z?h)VV#vRj*M@sw4PfF)AKNgRSEam8<>jQ_q_SC%$JPms?YVdicdjxpaXS(q(I>zh9
z3wQg=PnFJler&Z1(68|j<99w(KeDl?VUGtsO*-<uetzSihIPKv-Oc#le|}Or-}!+w
zvjhDa4+)6SDbKX@L#d}q=agqY(v5GtTe$m0;ckEVDe1iAX9NK&@gJ-gk~mN%VPjE9
zMq?4Svbz0zrAO9*^n<Xq)#-z|5IKMBb8-m@GF2t6lnZgy(e(@*<R?8d?pT5omhNS2
zT?Wkcj0Y}Rgd^*FtB0!$4_u_7v5)Q%<P26BR~fEnJa8#J$Kx4axO~w|O3(Tcj99G4
zF_v+55f!gCkyh#^s<aYzw#ox}EKN5)0Xnn9J@+>3@#xP=dd88+lh_9VNrJPtHtf-l
zbZ=`79`*#Xr#I|M{?3}Z@E~b)+J3I2_l^fsd-7frcs%GMr3IfhuDmcYN$lto#3ZK=
z+Q?~RoT-IFx<1HmfIY!Yc1zgh^sd}dlCrwKT%X`3!+l`!N*9l`NcF&RE0Q%(+)|tB
z#s`L5!qOCO<VBbdL?zE98JXzz;9Zz>aHeiN1iULr(gbXJcUdpf8%_dMa(5__mwcZ9
z1D8hT%QSSRma#Bt$&#wDcuDJ&!2WSN6iLj7286ruZs>HFf1tRfw5&J4um<NXEBZq-
zSqjTEkr`a3Axcvu3%L3(=NZ=P0)Iy486<ze<v4jKz-Oek2)I6soh3fHyk{=698{d-
zk($W|WZ8gdAhjomHr76V>E>Raz}m<8%;mO^6PqM`{nf|4oXdE|N$bm~j}zNv(9QXb
z3!Bc_fAAdZAUNfUQ*0cx_#E}ZbO(p;lGg6D^e*c;X0u3^oww&?TSc+x(4OO8)(yS5
zO*d3O66}(upJBEL+HiiKLCJtGr`63Y?|bWM&-$jy!DwT!tUs);r|*C%2iA*ZT{8>Y
zWv`=5cFG{!<pRrb<kaiNJ931RKXGJH<7@g0^-@tPyIlPo(_YwfP+Gn2L&>l~xrN3O
z8uTt&=v`Jij_GXI1y&}Q2)Yj)A4=LJXg>N2v}faMs8d1)o_Lu)fFlW`KaM(R0yQ2A
zf@<pW5JsMl=VV<Ao<p>b4|N|lrn9F2FYC^3ZRf(vN(8D(Wqw%Scu4mlkk;`b7L6I`
zN7gq)LfH(l+K1ty6^yA!<6tz2(xFix4``SmptAl#<7*0)eLc&xTlrZqh|}>&$pk`L
zE4~cxw8qh#jk@?en6pAU1HiJl7ao6&_S9cM)e)OZHLj}0Y#fJWTS*?}$s&c&-k$*-
z0{(!|jp;%<Bo)$`MdZTjYFCNQtQW%*$nSQ7goWow%f@t2xZ&Y@p;a3qWdghOfAssn
zljt#!=qptbSP5}TJPfu5&=;k<t4zsb<a`o)3_b~L0n|AJyus8)v{D-ONRBCY+M;&_
zpO$C~oT21^U>PgRxyS@Yc1Ej*kyu4z3BQx0kz#CMV(_6BYK~Up7g%57SgGu3d{XN0
zz?H~fQkPe_THOx?keL#GtTm&zq+`oDFv>ILmU3w<Vm%7j+nt6A2F$^wr6XGblQB&l
zB^A^h`-MlH@d?HDkth#EDq6DK9dZ0}(cOjHS)$Y@q2*YqC_#Yi*eyZrmkY=4!2m#B
zUfLhI4f_XtIyGLYXF#Q~Yha~4_>Dcq`lR%fhQlSTQ;i*YT*Wi!iIZusbV-TfC7Hl8
zu0cTtEDz<obVf7dIu*Z2TrZPc;(D3+QG7$qF&E^2q@`y*N(->wYD#l9gtO0LOUSJu
zeZ_oSZG!bOu^mYn9hG_^KS^z)t)9|1u#wc&lsX9D#r$3LmUR16&SZ(?&{IM6qP<?o
z;EQme5$#mZ7YP|&{SNp*ekw;mG%M-&Jz`JN$RDqFyl?#4TRGArCV0m2zW6dG6^e|L
z#g`rL*Yn3oqeebDvDqbT&UA<kF(O#-cmdrn)q<~jCiA7UJ?n#J{=~hH&h;PP56RHn
z$K~@uGv9{<*o9Tk;#dufy>Y!a{3npcG1D>geI4iE-WO_x+V>qe0IqIatdG)1H7?ez
zZjja_z*VgupP29|9sD`{RIa|E`1>U-LiW$|L-kRt{+{W8mkFBZkQ>%q_N;rRW6}o1
z8}KJ;B#07d<C%`-r{Ht?$2`+X`Hg=OY%wS|KzvQ-2bzJLpM(!;>?&8KZ8AF+2Mn2t
zFwlS%3oZjmzI#3cSn-eL4+#;mR6@hI9&~k<gVuG7q?I|#K`Rwp8NSQG9*x=`IBybU
z%3v9+6j#5(Hs)ablB6DpU4?wAzNbwCou@SDBlmvenTEgJxZPhG;e=tRzcey?G>OMB
zR5;-;ALDlZc7JJtJ|d-<#w8!21(7<^z{2{WC+)I`k^32J5CTn!y;v=`6uM*)1J?la
z34D`j^jss%{|HT{Q949ZWkC**i@wQxc#Z-ZLz8I;cL{1`Y%-0~;T1e!2s`BrYF80(
z`fwbV1hbVE*d@L-mkm2H7Q*faU14Q%Ih=()kh>0MdPi`hx$)d2ZW=d>o69ZaYPe<G
zN^Ui`j@!i5ad&cm;_l&ga}RJ2a*uF-;hx~0=APw_axZbOawoY{+}qrH+(+DJ+-dF{
zcb@y6`w!6Z5)p`zG$RqjOyWoqNdb9kBdtj`h|EG#OuCY8(6*L*yB=QnX_Y_m`yVgg
zG*IZo=w`g-mRl}yx7<SDMdeTYE~>ucZ-?eLUTgGn4X-!&xQ_RJZsOjrecu-@Z}rgD
zS4|IvPDnT7Eru^wtXM&7ma{invx2O`U+{%4S;4P$eTOT;dbgjDK(|?Y1)kN{d$|aY
z>+9ugrOchBVEQHSi1hACqp$OF5lh6xu4Eci{94y7tP9I|Ipzd4ba33gzZ?0`gOroL
zWFWbYTu(-j(PTWCM5d8ha0dE9QbU%Jm1H$pM>df<awqu{xrgi~50D4RBjhjS3Gy^~
zmK-H7kypt{I5GWg@*eq!d`3=_bL2evp8SV2l1se68~J8@1aIc!_#{4sx9~Q;HJ{Df
z`9i*!@5=Y!%lW?iK>j-ZdVT~ynjg<k;-~Sm___Q-zJ^~WNiQ=<t2B7wr}9GSrF>U^
z`ns;9@pu1n)BV!)SNh!V{rN!K;d1NgFJE8xwb#>R{zBmo|ETmKy^HD}(szgFCFx3|
zuN%_!hNf>zcYh8fk(B1Az>{8s4+K<EKP2->a4${d){t@&!&pTfD8^S%aXA%N5W)2w
zFFIE6M(q_TvCz!>b;tw~=)#-2E9I<@@}EXRWrzthrIfQF7V9E?$9Gn>CVm=XmBjv1
zO4%Zwz*5R}WR&#vNYk_unt88_+%BrxVcRLFus&$FfJQ9q?xnCgr$0A{8^R6eZh)Ba
z3EUKJ1~;3V&n@Pba?80@+*)n}w}rcdyNkP<yN|n{+t2-(dzAYt_Z0Vc?m6xl_X>BM
zdxLwEdzbrw`-J;~JHvg${hRv{EG3Z;q9?&5jF?CaNg&CvU%i!N!NHh0B%gGEg|6Lk
zY>TnvH}L|0mjw@tX!->!AXzr}`M>l+(gkr^dFOdWQr>SNOo+of{D*!oeSvon3(oKG
z1;mH?CwvEaqq%a07d1tw0XTtyFoIG5>5HIJs{e&#tXKhhwA))ybG!f@5rq}|1YSom
z<@^r4V7U<D{u|RkM{`Sq*YE|M)a!LDgWbb)kf)L!ue+Y}ypC!0QQogJ3@kq>4{umm
zUF0&QIxdHQP54W6AM&?Lej{(bj38$7OH+j?6Fk#^Q%QD1Db71@X<U8*$%Er9jgpVz
zb#nP#APSawrI_ah{gdckV17(j8l#ei`K#R^K}uITRbJ?)Lnl|mx6Dz~L>i@PUhA*a
z%@em*OjsTxg4gmOhL_b(c61T$#!Gwk2X$Yf#}UsR&>w6#qVHCv2jR@C?m<a-R{+<Y
zl%l$E4J2yJ&@F0Q!`e;BCqjx8H(1hOUw%9lA`KSW3#PnGxB!P0MaRO00{y|ycZ(->
zfBxAXK6m%$)dv=fCu;T`Sj^`xK0w;;{`~XZeD0plFbQ7SS0kQSeBb~eRLa0Pc<@Ur
zh_LOPsDx_qAYb9c2J2{~^`P$0qMt~59-N&-^>XHe6;oc28-3-}DfJ8Ltk>Xi<ta}x
zNmET0g<_|w*`E`dlDkYon9=aW=*yQSWB=vj4a#h}u7HXUIYlSnJNy^h$zRmprMuOq
zWJ*Z1AcZcP@H1WCkxuI0O1e|0U=Gk#M*~CxgmY0`ESJc&z<naHJ&pMmb3QoF<X13^
z*|4dA^s*_4*RQ8v?k7jZNA~j#jz#;0vyCT(H5)|(KWHQEOcFP)2bdSu)6V-zqG;I9
z4{AKQUswapnX})qh;P_0K0=P}r(dpL4@dd>!viZ7txf;{Bp)1l@+&RhC{eKS;ChxJ
z%bFDeO^QXb!Wj%iRIP>GeShOge$al=Koa-U&IkuiXjjuG7*-dUxM-C}vlZ7C_EFF0
zI&hu2?p!I?3w)XbG@8?Nl~;3xtUGN6zotZAOA5(1!p1Kt1h(HImN@tY-|(06@_yCh
zZVWu4dP=#EpK-+I<*s~Hkju^{F>yATf)AEjrdT!%88YNT<&YutT&acJYoVQ_-<AKC
zKgGY6rt|MuL_Pi<QYl?meL8L~P1i+O8c$esIhJ(CKP!iLB*Cm42Q7SqC7lKjsf27?
zS&64D<ftY62q3`ApIX+ZTd>tEQ%ch-D~FWBHBx1vV@lIWA!Loe%j8dfi$%;TweYj#
zba0Q|S3ZT8EsfumT7<pnrH*KeMVJfED)-c%{L%DMv9HC#W7W$6AKYXK$@=tCy24^1
zSobn0Wk`Byxy1rQ5_cnM!5<N3qWnfV$R9!R2iGc4emn2UBL&KDDMdA1go$W0Swk1e
z`RL<a`RL;thw1jY@{#YU@{v+h!x4M#`CR&rKcd^Nj3-iQ;ktd&c%s}>jVDe#kf`x*
z!pDwO=m&&@Iv6q}Jg{dnF=WvHYaB+}2s5#MP&e0o$O}{G(}Xl7l}_&{dQo^;N(@zn
z{MvI-`Uc%oIKo;XaYI7^|3#GU0Vs=C-GkBFniecbxA`3Lq<9h%HU3?=&9MZMLO!j@
z0R9P~3iE+N`6tAAqzo=WKnSn8$Fu-qwi%@awY9aFh7LP-4)d6QX{^4vzBT3n`&8?j
zHxB2^#3cPcFb~%~$OG=m352tbB~l_WiO*@=$*}Y$96v-@FXzJ#5r5#z=wTiN3D3Fi
zN%_DL7MOqxJSU~0hil;sAj18Fi!w&)mdJS+BY!>&#k{7QjCr{3Ik8{@X!(9pBJnly
zfa5WSMMd9WUf&=liAlPr8ixagHS~qMNPkSAk8Rw^=Saz_8G+sC8_e@h(8KhwPz4nW
zg?wDJM?8>EoRomPL*K8JQdOVBw!So0_qIe|JxqSSjWF)vzu><>EY5q72iz4*asmLr
z(lngajT28wbprZ!lIhFyoe%}#pt;L1ALl)WMKBqq1l8xHB(x>Ts0Az)T$Ev}L|<z#
zF>L+$u%Rr9&*SqT57#}&1MUJADM58(KbFQ}6$a4Z5|&FjhARCC>{r2pp~`X2aZZTg
z%kW)@Vf9k(V}CF@Q>+meiHmsH;8RNJILEUqkf#8&a6JS1RB$uxQ{;NOpYA8uYoF%V
z;8k)x%VW49L~jRuEKWL~l1qcY35ZQd<plOFe~*?9%D{b>3?Z~HeHs4xlE0E7`1@-$
zT}8ixzg6Js4u`**cf`jZ7x4wms!E5?;caztDV>P?ntF-T9nr4`RE!2XkcCVdzC~Nn
zR^%<H#bKdLfOq~bagsO*Xn_3S!Vf1AdPg4sVt+t6h}~*_=_}y};Rv9UR#f61UWG6>
zDXl*p4KtFnU^Wtc?XdL^Zu(-AKc%f~?77Ox#LE3E{Z#T(@>j|e<`=`i_4sxc-{_6_
zP9DW~aX-HE1?+nl_Ptv5UAoTFNa>|#SvD*~!2qc(@S^X*+w1rx8s5kdcoR3_x4ZG%
zSm!r(4ezpa?1A^-7iIxExU2mlL6dCG_8W6+MVkrs_R55Jqsd@2#o9~;Q>2&n{PtV=
z@Z$CBFRWj@_yahiz=P`wo_9n(PaAa$N<tdG3klJOhm<tlUb0HK@I3to1<8%^NiHnd
z7qX!p-H@nwE1I*UbNP9kJ(n|rX@twFVe_W~FSyjKj;z0xe(?J1^aEmf{dHog{_24T
zzQUImz?yF2d<LGEp7{zeqpVc;-wmxN5^WJ~eFtJ{v~@M5a-Ny6j*ivP<|g&)hHptt
zQ~46e6y%9#zM@%@9@=ajUG-541+k6P{oM;@$lWt<r*P6{?vh1K=9|Wtz)QYZTcCwk
zYDm>_%Qsd-<1~pFX<q3pE>w$CPvrbsg)BgEce+Hnm&0i8iC&_(uZ)q_jJJej7#m<^
zt6mxugk+^-J)p>bNVoaYaAB#GjsUTsUcyo)>S1V*O3?p{_QgCwW1?k2oS_V4d;}B$
z8ZS}xA31X7QDyYNv<}WWLg1LEem+Ug!ACEZa--k)9j&Bda3E7BRW|^h-3His344gN
zMp`NstB}UNLZG3uEcy-nTC3&|C3|#ZA<tlz3O)ETpfRqyma;^$$eA0Q?QB>J@nU9$
z>ck9$l?Pmmp;MZLwOdQROo)N@fKik{yJ1kH5QC|!@p0WrWF3S9w^0W%@N!x?`q98k
z-JG=^Lak<v2Wdgp@PHNbg*+ip(q!P3F<oltYU~nln`;R?0eNFu<Q<H51Pq`HuoR4Y
z5RrnHVZgQch(X2-9YaFmgpQ#3GKqRp6#yA4i{ZlOrN^;2Cpu@T?p;+OA3%US=7S&Y
zui!_6R!05yuTD3b_MQpvfnn)>9o2leuKN<7)8<Fg)cJu7<3#>>VH4B2Kv!^SR_d{Y
zfBwkYwMXz(y=u&uRrun|qzgyZO21bDT9>~8DGiLH^6`l;08TGHKBiw`TH^Evieuao
ztMkR)&+;Ws=bAcOHw<!Gqr00CoQ*(ZpZ-6K6GgRn5&k=Kmpp5r=Q?daJ@yi?@N_Do
zsf|5;Us+C08NQrm9~pob+Lx7KJ0tBCJ5tYb;!UpSozHltgPAAU=ybCvAwRmn__`rh
zZcB;n*t=SLHoh*tNT<>%;!Au7i2vBicdVv_*1;bkm&gqGy9C{5s`w(ieJ9@mljBua
zDlPqh*OeB;R#XTswi7Sv7Ks<dTA-p>%ZK1sxKJxz#QLk-0KHRAj$xtril?)24L{S>
z4wwVx<L7x7FF|wjA^c3%koYKOCugB9->5EMT?Z%{$^*ozDqx1dMFPqdCM%kOK92HV
zMR8&>a7KM3XEUY6V)vJ1lOh>Wb~rw{K>r-2kE9P!vD^%?ImBHg$TGTt9}-3Xd?6QZ
z&oztXls<rith(%2ZP`+51K$^LP?cCOWlL(vCAz`PKSjxKu~d98id-j2O+~6JvQ)uG
zm+(UXvA?o2Wz96s1T0bDrR<4jI3w#46L`ZZ|CIRP1urEx04k<bNEoXbKE^Xm&|Js_
zazm*we6g1Br1?Z7CAcmmG6KDUs2;U$06<aVgVp>~Dx^?0`co9S4E+_QEO0ss+JTN3
zN!V69Vm#9635r2U=)!#zD31!@y3ytbnJI!B@?&yGI49+IBUh}uO*aTy9ptJNIvC1T
z-EEC$b+Ofs$BK2ajsd~|*>~bf%Th|IAPJUtBln!JM0nLbA7P2(q7YIoKJ%OqB3AJw
z;xm8^e1XoiQi&`TB=Le9eGP8)%V59-u97}&e8|9aJGgz^<B+KyOp_F1&4jbQqvLST
zRr$jJj$Zg>6!1NQeTU%J0`>!TXSJm33*jTv$UbaV{E<zp>|Gy=-*xuf{5%2oJ%zno
z*=L~{e|06&yI_z$v0%I^eHL075WNH^56!5UXf&g2YLn_AdNw)oEqW;;BI>y_AyKx)
zZ!`-snS?fX8^hCtgsPDE=%5kNa0pJ=);vBjEXerw(o_Te`LHoPlAb>un@KNyliu=2
zlGHr*JV|M#e}<U#u{WKJ3QOUO_8CGThyIa?aiPP^y7Y+1KjjGqV`Q_i_i7Aj;gO%*
zAD(CkAu*rDXOhUq%ofw=UoM=dkCXo2o+kq;=qD$R(@#nAiIb!S`81YKjcZnyEf|9$
z^k*09TNoQ249+n9=Yx<I^!uNaVt#IHY5o^6hsGJ6q|H)Reh?HI86|YMJ0d1oh^`Ec
zOAN1!=9?#m-(fel3NgHQYg!25AB<=b1j|v+2W1k|*X`5(Bj(0^NX5vgm}bvh3T>7g
zH2W2kDVgtZx5=C+#0?FLH#cj3f%K=3o&T0TM*5#W0oYQGpMaBwKLvIIj)MS=AWmNe
zyB9yky$-y<PUm4Ko`S`Sn-gQ(!xuO-4tCHk1m6y9>&@P!-L>H>ZnBM6l(SLcx4f%y
zENggR2*yS%7xpZB0yqbFE7Jzq$zS28A;yST@eoCWu@KX-AIKh966A*^MH}H8=EQdO
zhJ2;`;SuFw+;N%V4C4M>`q+&x#5QZQyG{I<_!)ijLy`(}j^vym-T2tB+;NkV;v%lQ
zzM?p5$gQI`HOp*YIWN&1HSC7TQw9{33@wP?e0|5n#M$X39rH6%GAlcWho?6yUsGZ)
z655vA7qsgTnG+f}w!^|nDSe7cdu693<+kf=h>8jo4(OWK{H;~1l3Q|*<c`{1`c_y>
zOk}~$S;Ze);+D4R+@;D98=7n|7>q5WLV|<S%!Z`Mpx}g(u2n%nVab`T%K2Uc7Tu7c
zD+()ar4MhrWJq=gYpnf;kinJ1i|cP1X|pt&cU?h|uBcmSLG$S1jM#~35eW%FnHi>5
zgZo)xOhvkc(6GwPtZs4fopSPqbl_X$n=|u^`ki0bvwUKgk>hVOnxjpY@Sxxp&C?CW
zu&A7N^A|)#^=aES(@>gjDI(XW@?AT%YnRU3TBoK}b|Za-yf(1Lk#N;u1O@4C<SLO*
zB;HU6Fa2T-XkskHwr6G@511jAQ-u>(GHhVrsz_^w6}@1|M5osU1w}{b1wOQWLHYXL
z#z;eWgr1M<T)R6xxJ~x;181eDm)mCsr|+)q9IDd?M}$M4?7hCcpnWJW=p&*b20xaJ
zPfv%a+F1DBEU#5k^L`ylUQfs|nKMV+dBkp}al;FWrwvR`xA(Y>oH5&v+}R?dU4|(k
z=k<~f{hBAW$|Hl$o{Y7mr(0rAp5?&Llzz!#{Ls*bd!BoZdkfYB{G0okM3Q)jEy{s-
z|5EZed5*kB-XWimugMR@!Rz=?KAKPFtq^ltz;^>GMUXh)a3k_DzL2To3gJ>VK}NOZ
z#}%gAK(H3ZbtSk9cm}*|M)+BnO(J+(S9l)YviZUk9d<<ADZDE&U=AQbBlr|jm|qxU
zjLVI~hw%m1S#QIX8Mq}nN_0q$h3Cd#*C~YDja~Ty$QL%Og=~y*5dst#XS7A|@X?jG
z8w(j2CVt_3U<*8~kI69S*)W&F0wK?)vtYilcFYj^ARI>xB`BZKM%=m^>lX`048v_(
zp3MLcz!vBR3vdL3Q9#mdQXYUbo50r;ER^KKa}fmch3%$|fC=b=;s*$aPqOM5^CNgh
zC8QJ(r~tBMp42!dNPr6PI|GWxO63<q=_pnJF8r~4^avY-116V<S^%Xf1;-T#Op4eb
zt^p+t%N)MO#xX}Nd^5`8&3R36;ugwjq$HlsU6!GQ)eOZM86~hVsGALI&W-^vez>~0
zIIQ#b!D(OIm(n~bXUV$uiM<MDbXbu$Y(}e=iSZ*xq-5z@v>0^H2zunYyuL$2`;?Rv
z4^1u%Y9E^sADO-^&)71&t$x|8(Cdt5-W*P%f-;*&G>eUjFlWZcw(M>yZ{OvPkdpQ-
z1{<&E;|!^ZBz<0LtBkVTR!^3ekIj!y6LNw(8j?-PiOnKoBAX>n=^xtlFS<u}=*L%e
zH1r%cKD=f44YhqU%%-SHht3oh8y?v!G&Yp}NYXB)M}@@d_$TSHK`9f9>SK!RiKT5a
zTegX{nS<I{%;APeL;Ixs;8wx9@(v;QwKpfXEI2bh$rK-IN!QUAQ_EV0bZ*B_i|S@f
z2_fIcw2O_7F3kufb?J$r!M6C27SWbR(hUNi8XlAwYc%O%!_3W6qvE47qNC%R8IvtR
zp-G`;eu||J-DL{Zw}=hu72lTVTVzzUpE!sV2E~%}egk^!8eZ6<Q%b9(yjG{_UD2^2
zEeD3SNy{t<zd_eLJU%Eq*%Z|_BqXF=N^nSGUSf2-F`{2&d{J?mh%tgGE+zQ=mhCzu
zZ;y_RiZ5v&meOKCQi3^pX+~mfNQ<E6mZXd^&4MDEMSuv8tBi=BdfX5c63I6UG6=UN
zbjb+KwZ>$09A7cxaDM-;U2f_hoUCid8=|s08=?)Nr9pAJa9u*s(kC9CIdEe|M(>2=
zu!NZ58A0s<RR(Wr7H>?Rk`dmjy6>I3h3!X$w6nw;jrz7FCA!4$&U|TH=9+?%IWZgh
z3@!|h%#Y3<GN`+$OJcC8YmzZCG&E;fLh$toZ4)vwl6&91tn<X)rm_8EM^>fOm<rdX
z^BJq#=RF^`M~EbYqMB!fhK8p%ADI;q)4n{YVn7&q+Z+;^7Mc(iX4(^E3=Ya27Bxg%
zl^&gto@_RmN&L2w`ksRpWkz?h3@Lv(Cf$@$8j@_yx9LM;tTBctQ&NY_7A+(DHg6u(
zJ6M;SyF4wa&@?zcJY*utGDlm(%!v`fEqew<wlkT6VuI}AZSzyYHboKIDLy3H(2|b{
zo0q<O*0+(J!i?6?;0RsUhyq=w;DJFU#_NK5hjrtvc|pnP5zkcxnfpceTo66o&^{zI
zH8QvZA&Dt%JLe{6CWp+6>pJXgT}EDqVeM`&FBn?ZCOb38Fi$)Y72hnZLvV02-K;1>
zUU*d7QK8Xs9fA{+?zhGplTyQznn$%9niCxzbzk>lbGYfH)cC~o<}IQ_;$!2*XD!Jg
z$<Jk`X9%;yBFy2Db(Jxp_9dpsaIkLRAG}>^5yT0LA?C#bksjHwF0CBK0fSLT3<N|8
z3h4qE^D^QLdKmH80Ev>QkSo*?yusdm`Fn!6zFX-i+WXJ+uM2M&x9wB|*$m4`<`Gix
zGHs-T=xyR()>jRhU$bP>0`k;hv5+o#fb=6BNrE^*{PrU<fRs7b_RnqKt2`&KZ*=!o
zEjx9#Wt9kv<8y22b2metcaGb${m{Dk-P@)cyG+~##`U_{3m2{$M#{T=Ku5p#^ueCH
z>9jX@+$9#|mi20%)2BSIRZ+*5wxUAN4aQu$r2iCrgs^K$Ffqe_l9ojDpVARe(blx}
zQ*;C$@z`TRXZo6Wk>CV&2+1QCDVQx_|G1uoh%MLCacRv+TAX0j3)*}>pzlwcM&Ca>
z6$Z$Nsh+u3lWh9NgY^IY{&&&_uvJ`Y6h`Q$Vmug*G;t_tLG6SfpSWOBP$-PZkKf$u
zo_)5*?x%#GFid=jyeSm%h4=3oaC<_*!j3$-G>l!Qtq&Z8EV$}RNxIMVgSZ5b{Ln>G
zn8tF|eJ<zvmp$OYIU#mj+C|vWM*QA0Z*sDsT>qc0)5Py-n*)!4PVSnoX>z_*%_W}B
zd*_sfG66wn*G`^Xi!Tq;+GE01N>>Y5iY|R>?5;P!N=rM;V!Aw$h0HJjeWnG0VVN;@
zL1C1n-J4qwwU^S0$^eevpu-!xAFr!Besn|XZT0{9SN(0N8;-*76Z@8@Y~R<|xNm#P
zE&Hl#r%tJ_n>wYg@yWU=Q)}@>O6rauuiNmN@v}Sj?!DtP<7*r6_lg&ziSXdz!w*t1
z`o$Ge%DO32>frghTHq^h*o{1n=eA6t9UQ!agF0YGHHBFc$~E8E_uZo4T)yvwXFZNr
z1KPTJK-~BwLjg#Hy?~R7h?59_(_2ks%v0q$us$(`3lV-24nkyDDpK7@5UNCGP)j5Y
z$wgM-rxe;S6iIu$Zox1Tlw!8g*J`IssjZtlxlUMXhPz{L!<%)-yTe`a@RZuxDU+qW
z8w9Q`{R#xs1@Kp4D@$!`(-a7T3+bh%je1tbV8nvyGcF7z?CS&tgyT!)o3I%`&}UqD
zN~Et->guLUuB#JMRoE~xjth#_7en7I;f8YKxS8An?q=>bZX>r9RtfwW)(89@)&?Ah
zbpc2v(C-wx1OzQMtMpsa|I9!`2vLPQW=Z*zlB4*|NK4fNAK<p)u1xYVgIFt&8F&P0
zA6H;jv9e&WWfm5oT4|KNG5ydrfe-36yAHx1`U;RQF4pF1!dR>PxH2!V%+ouwlkW$`
z3JK=KJYn~Um>$tV!p%=_jxC;cd{t<DaL?-^o(e5#3@-_ND&o4H!S$i5j!!F&%Cg@D
z%M5qJU-@13tcIwd=pHd6b_;ol<^&;g^V2sALi<Jg_b)PAJ_ry0z|!~l`t`?O-m>N8
zCr!!8;5kShD1UZHOHWUuKc~aLwd_)hWU@>b)<2(5(zPF7*s^6|N2|3X{g<5l9ZX1n
zN>58mPmwRpmOq6-dPBY`)~M5kwT%i3(zoasmN_y!t$EJ@qir-Uwe8%wZBxk^+vov3
zo2P}3%nUowWk8!zquLDUaw;sUZJ17Hj5XyO^pP#}k2Y`K(;ggbr$y_JA78)a)mKS1
zgKRR5kUt-T;=cskdD8DlS`yyO+KT5xQuSTdw=OJfZSB}`fSi_2mJ`>@7w(Ziq5A>1
zx%1tP+)c19<$e{vy$dT)zJb*zBCI^YIi+8T_u3H~vSv6KYm&DExDYrFxJ<>BV7&;y
zVqj&Z!&P{<Arr&tdeIPwtsW(81-48h_}t>yJ1}pabdD^MKc%~HP#WZBh=FqAV!?XD
zJSFLEm7h0jo^$3W-@ocStA8cpx|`@LbOijpa?^DYZA%_oXgP8F1N+w;&sg|aiCC{<
zX;KsXRAhO#u=wb#`?KJGbbMI1^2n!xBX!?J($|sKk>?eDSGY7z#qW{HEwC$)QDyCQ
zNrdG0H$*;++>TuD<oE_pj#v85Rpa=+w~V)r9BCbYi#~Z+R#IZis^n>MA8_2?DxREa
z-M6$87%Xi&mG*5-<Kivd$#LiwTcCTC%gmf6e=dSvL9&43BbrCDeo1T6y696w1k%bX
zBt8QD!V3Lkr<|JZQj!mnuS}3X+1QjyCmKICWWopwes7$JM!&c5<Da@2k8J&UI@~<+
z(_4o6pQqy(tWJyPEXt_~CxAYz61AWf!|;MUj<OkkIP)_Mr_0ZT&~Fk7GP2UT4{YBu
ztIeR^cFVBXNb7=kC$*~VJNIi>k%j~~IqJ~}+P~GH_K{(OdoEv7n%%C|w_RQ!MRgr!
zS7023JEm4DOa@{$f;%OGWD3N98#@%*qTo9?NeT+%VAF@fSSKj`qeeRW<K(Q6sGKp6
z&}r?8^sQTjnzxYNo#&WrX&F}Q4l=S=+Xxph{h1KaL0czBrX?rGjwh+&`h={m9aBI#
zpSFvXWyVG6GpzJDS!>GzEfsXkPq}vb7xZ%=4xE!uN3rp&TSNDT0Ss`-t_w*Z074`h
zczlqiFkEr^7pw^hG4=^>ocMN5awoH;vu++4HS2@+BciPFvC-X@je2^*%h}_i<2pwq
zEt>Gk&94&O)C5ah&y^(Xjq@*cxyf1_+6=&rn*Mg18=_<5tx;WXt~xaONM5zMQ?%K#
zV9fKkd`nNl{2KEKLaatG$joHWA9BFrDTO^ahQsa~Ga%A!IqbOcF$eB6rM2_(&<i8E
zRb1aL|E{+uyj^n<O;s8U)kr>c`bb!m@349Wp}}yCv;=+(+<WON+;A5->V;rizC-g#
zhifh<2|RAlk2NVhE@;azG{0)j)1Ujwg&WE;+jI!F*attZ`6N_xK}q0ogT!l6dR)lW
zByb$PLf0+1DCdah&s5X5V6H0y=8;pt8oz;?&MkrUr8r)rlM;Fo4sD?JxqN}DD|o+v
z{g%de<Q4pD4c^O48;s4Fu;>ZXSfT61>A>B|W<q2w*$AUH>y{)l4Kzq;j>M812kuZ=
zO*KkhNj9JtS~Chv1u*3iX)MtFXL<8=yL)b-XE(LUB&C_ddKPV=A1#d9V$Ufn-J<(?
zP3JEPs-oiCUmuat@ta=Xbd1P|9%Ft}|NnS<6Zocz?QuMFZ*G!iYxZ<W+oWld?pwC*
z3tedobfZ8Qx<c7$DWzp8`;P1t**6sx5CIiY5#=cgiYV$+QNRU#qCS`BbA@L3pSekC
zK;`N8^ZWdp-sIl7bLXBpbLN~mXU?3FgrK;K2M%0BaUl{aD}VBqp3-FFSjI==KPaap
zu>|*ijVHeSj+8!s{`>!C@Iwkv>9waeY<TKgDYDqt8V8BA&d1Le;2sovX;v8;aUa)j
zabZTp#3u&zCe-B>^rmkr$%&g#NHy8h3+AZH8;0$zT$GcVQ@=MWKgFT2O)T%}yK$)8
zoGA%cssb{!QFgmFN@<rJMaQHmQmZc86c}jA)>#$W@O6`t3I^$OmS@Oinvhtuvn(XQ
z5F91y77Y&fS1SF(D_`&2JxUcLlm{y!!!U}I$U{W<Uk7_R>|7~_ImBduI}=zMB8a6y
z1S@}O=Fs(jv_O!HR7p7w!(rvLfeLb6b>&d2(Th0U)xq-AHt=O|KkI(-)<f>xY@SN|
z3-2=Xse6ut&<5eCZf*f%B^%qsZ1dSw#C|-$KVX2*5){jifwQ>vC3f1%^AO9Rd6$ji
z?9}R}xtU9vbp8w-5E!6O${bo0rmHLISW?!Moo^Jq-n4AuMD2=>)zf2+#stp@o{*BT
zq_JVjl;zD=sZHTq!nLEcBNC!Y!zY&p33J13MVoe{6vR+3J+rB;A~&PJp4<@gXpEvj
zai%yYr})^GnVnmVLAAr$Mjq<v$;c=M9Qtv1{A=K~U&$Fgz?TWcK<q>W1N2UiA?})o
zksDAc_Yjas8S){ug!@`@0+(P&XR|}+U`LG>K!w}B&%dS*=4B45D~L{@X_S~VMZ31C
zlX|}7;Wr;V_bpz~6*9u1*Nn)D4JlHEimbgAQ`&}9#xslN`ss8lW|`l}_g^_NXmi&>
zZuEhtI(Sn-wUu&556TU*<SBxTqWHGd=I*6v`S3MQwv=AI;D{gT2#?Mlu83NEIb=(n
zEi-rWkZRs^Zb?H`PGT^3+lWYCe^qMG<n9e|!==+6XO!xZl{tWqM>!wzN7MfTiej~2
zcK*Tw!d}IPi3fJliqA_RQkS5JJuD_SwoFcwMr+mZM`t*bGaY#g<JYz{2+iTnOp|>v
z)h4P=lq>P(FB>c~&=#Q8lfCcSsgCZA+GUexEe%+`dfK$fHl9Q!qsNHFvU;`7Z&-3L
zm&>KcmH7G4K4yPsQ9ID&0DO@g8_T(vc(!o}#^Er=!~BUyo*4;PR)>?(vf3=P8B8`o
z5`XlUcym}{wWy6+Y&T^(!&O|rhL*MQ_IG<><~ssynPF-8?bXa=XGR_!JC5cGf|G~&
z>D2Wy5i^;VsX)cCO`bMwL3@$Y-wdGn@t4k;yiB{Xd-ZBi&u_!u2u=g=*e=d|&Po<m
zG8gpsa0xR`W|$Nsgs5?{eNO`uSnhvT2eLX$KwNIxBLbY&Vd9-ym}nz32YJY;k({uu
z4c1U{{nwkwYCP8VnQKRMQq}O536xeW*VH8E4{~NC`S)0Th5pm4mxZ`aI_;^6)i#@N
zv$-TXc0qa9gl~-H<2Lx#G1c#DqLwy}WGwg~-tgiN=rf`8Z?^gD(RFd9nst^@$-G2F
zE82q9qjj;Vc0M<^qwb_o7pp`;?b-U+Y?Nac#UejNCKVeLm|BdeRv#uc8TrVdO{n=d
z1<WeuX|O?CVI5&UryOM80=7+fd^I5#I}u<&8WwW`>E3KdW;?Tz?c7?WmL}O)hM=SY
z&uSY;Gte_x+H=61AK`xL_z>iPfik%dQ+N&&JC~>Bfg1^w&4UJU|FiRNYSN~5hsk1h
zXJ%Fbg)jIYy&!A#YEO@$J=GHs3?N}LLBWvh^==eY+R^Sm!PzLlCr$ta4GBVDkUsba
zy%dcjy%e`b^i|}MzD&P^rnnmq?{+t|z^QjP^hvYc-O&FqmfxL9fR47Zr0@W^`FQmc
z(vL}-lyPb~3t@arMk9Z}Ps7H-CK%E>6B*JQpwU8*EsC924nc`zN)}Ryr9cTy0*nk=
z!0H}ofa%-)5A7T0?q}9S+UUvtH&_KP^+mj4x>R`e2Ulrgs@*B@wb@RWFNlpUF`t~!
zRqDH8T)FWd)lA*`9j+>T%owt)db+>R*V^Nsl;IqdpIoDni?x(YR#7v&D(OPw(kRUX
z7G~t%<Ub9mjL!s_4@ywR>Vzn$F;<^F1dUSop;(c<l0r+?Y5d35jUH9kk;~=VQ)6|b
z)xm8F5Jbo}3U{Oi1`R>bG+zD1hi#ii;9=dY?!rOt*<ipgw31enKvW0PG1vo)EO2VJ
z&=%SOlnwpIZ8hPOIc>gHod~n$X7|*tng^?I2{Uw9SkVb8rRSe^XC@XN3*qI^QiO|n
zdJu3v=tD}lX;*P^zv$>j`n$>vcdrsKRv>!d4Lrg-NIw|hEAsY!zA~Sx^e~dm(4U}J
z?S<Y2Y$o1EHi2|GW;QF_T=(Batg&56q56TbJV4kVvby=?T{tOzovDT%1YOB8;iQ|1
zo(6s@AdK}xp>#USJW1OKIn}tF>E<~&q0na*a&|(z#_u@4z_?F|LfF2;^F`zz@Wi$T
zI9CvLj>R8o5)Do6xbHzS%k|iF(mVQxGh~3zHYMpy>>2PcGSq=<R^tYKM#_RlgJ(UG
z7pQ=YcfcdUOa_81lhcGCcQ<o@F9vu^^cM$wQyYxjFC^{;&;{Ai7NH2cjljnTkO><l
zLoLXsVOXe1q3lzhQv26~(H=r{gUNyh_GOQEfy%<Ovt?Klxlf133VbQ?LwqSeBSGI3
z;V*tj$VCESe8j2+FTS{7)lrE;#vN>H8<F6n47Bsj!CH-2A1Vu(k`ie27Ye2RnW%kf
zT6~OAXt;mT&J})@_M}zKrg`ILJ~S;evDPlC%v-YJ)a3W>bqp2Qh8ya~JX&`Dk3Y<r
zcIeQwIpGOD6!$1sW*MB4An<)u4U(116WdqJ*6VV)Qdz;EoXUtIm<n9=*3^$zI40LN
zD?^<kef-S#R(!B_ZmhvKIYOVa7V*waouRDnaOfhGJD%QiB+1V|X$pR?bH>bRuN6vV
zGT#Cd9WE4$g_2;?!!xFLbxcpRs+a&RU&Y<sSlQ&9DB+bVO>&7aK;|fAq>Md(R7vmi
zQ^$>)+IKxMU&*A7u!*(mXx=P|LM*hU2$dq=Sip5(&rrX?nTp}d3Tu0|mvL){870ag
zxn){MslFgCpk+s5b87Y0I{(Dni1KvxaBE8t6Zc5ts8NlNOs#E8mj+d7!WBw&WX0ym
z#h8nv0nG~8SY(SxE6Pu!r7mucf8MejZJaVI#6N$KHi}mER2Q|`?oH5U6w88Ag64IU
z%NhT~XsUGKx{0GUY{*k`@!F*e@SYq#e^5X)H`Uiy6A^u$B;D^bY$)R^7K6<w5f-TZ
z%=`#87_b?^L<idg+zvrT160ZFmq&UAxdXOgmJtz#1LxeIGy0BAEvjy$ljEYo%&sY=
z#g!RmsX&mB8@0<nk4~yB98%HuO8R|tQAS2aw4-%=6P+DrGHR8>*X(M{)CC70u1o9H
z2BbLBMvbiOJDFiCA@kvhxSM~Tr(%8ILm*l!8I9cLk?r=1_N*W^*kIm?Ov6B*0}!F7
zX<$faAU%;C<Fe9<f8KQlJmn|2&QM8c6L`uewO|VO!iPc_O@a?jbj_$jc_*f{yK?g#
zj(l>wQ{|e`KIH_Ra`K~(PNF<ZLL4lC@h*fEN}lyDYg{~Ko%HOftL`H5o8re^J@xFQ
z>k}qVrmPwe>O4-}%`yD@nV%rKMI_X%l%1dA5C#NBbB`hc9i8Y$Zmv%{DzGZTFMtJr
zP?3>esGo_j4}L7T$N?vS1lFgEH9i2-fy(PGJZMpt6|f^};0c6L5avM2lSBFZ`{O2b
zZ>V{~Q9uu;H#N8J>Ks;?BNM%_e70*ya71xsWpPCC_?{k=_>qv>;1eE><A&1(jwfn1
zbWeyAE?)O)PUW!9U9HWVs81Jf!*92@<F~ghE-pUWvp956XksFKE$%s5-1jOax)NdW
zLC*Weca1JGNhP(~Qf2GJ-ZKYE<}F{`J{BF^fu0Oen@sAEY+Q$bm>C}1c+_9isI8Sq
zO+}--#@}~g=cD4W?TeSsD>-nccVeruZ+GsepXSP&$DhwFjnL~ON^{STZ$>MkqGlqM
z$p0wF0PQV1@)?Nz^$q6-;QuKQaW@y0qFU65#zGv;HZ%t<N2}2WpoyJmA3B7Nxut`f
ztpi?JMhXsog#O_YFa}5@lt#F&21cuHrPrfZ4d_^)Ls=l|7irG{6%hC?8RD`B6sUnV
zcF(=AO+*I7gr^%rop8;1vAHiT=5%Br?Z$RSR=f~Ev~mx*gJc0KP=7i+pU!q*10kt?
zlLE9q6wfxk7Upm)9<a5<(@yQ++u;s7H%lav+iw<11z-rZ5Gn+>6ZZ*8A*H%4VQxBQ
z-va;;pEyrpL<T}mw(^kr2d@Jl{vhukgQm6c9sQG@j7MNGfI9-K$@9zqI5yl6n`L)U
zv@e%i-zgBIsUs5vF%euL#m~<U<uZoWl6H#Mq}EkMpBr4!*pgN`YD7XoaHPm?4Y%4w
zDqBIqh*6bkEsYg}&qY`1)J;69y`<H^a6_~6`IL|w5hF+#ITeWoo%LL<FGV}-S+R!j
zSh`+1p~;dOW)R52Ov<97B4>PHV7wDfl%_C7X$VWTG)<7w^*8$N39Cp|E3;%qTVz;D
z?a0^_eqRnVD@%&xhRUk+^fBq^nc9@FNSjfXrBtVOPo3Ibl$T$GZ)7nYS?}#>KmT39
zpg{%2d3nV%+uLX2pNfj66=fM!4b5uZ2*jkSLo#zjn)0H!xDj!^q%@mCJYu9oT=bqz
zDGCkeOLB{(Qil{VzPxu$+Ry;}t=1F}iWrebsKwuCL|P&9cCc2ZkjaoQ<3K~zbWngm
z7otPub$r!O6vYh7jZdpewN+N8L}d(4O-jx-nw+uGnqaL|b@{SNs`WKR$2v{M?Bt}>
z!5L90m6f*Cs<imrVGP7)Q1R=^5fml}2%^<Pk%RF?GMPf94X)6IjF4_=3RPLTy!hZ?
zy-tT_NumPu`hX}2UaHgSgM;HKfmIdSv_(21MCWqZl+jjomd-y&Eh|Ybv*}_btL!ln
zenhIx#FyHWqYZ0=gV!3O!_czi5}7*4Uzep$wMRuevx==@rtpN6sRgOA+$^IZvNj_*
zr8F#SXhOo$#2B*yNM}%FNQlW+m=F<};`%<!v_3R+y(!GROfHTcTx1iA!<|-q*=Z6<
zjnPq2Jc-S&3uq4sX%Eop&MNg|0|LhCmHuOV1lHI@1D|JzFn*Ds=Q9D38WSS~hgey<
zuW!0cBWR&T6!Wg1(hvTX3Z9q;{}3gF*la-VaW{eftzrE)JiD0O>ceb*G$5HlFIOqF
z4h44;mM_6F^!DOm73Ys1KVLCyF}i>+;s4_QZf|ejj%==6>co=nz55?|=HkU?9@)RQ
zo0@|}_@{OFnfiK&RRR82_!4(B^G|lo5iEb<o76_R$;puYN7#>*>=C3ka5v*<l$?Nn
zU58&uKmxdU2fu}4*P&SWd58MNHFesuhW{Wld{edSzFBwS!n$vuJ~a3|B{40`_aNs|
zU=$7-D_Jz+HZBqAW(JeET5bVzcoc-%(kl%R{+xk#+F@q`BgEb^G7#k(e#rh3keHZ`
zoN`qv;{J%=9~mBAx^8w^eoJ`#?kII3dK0y^;pJKQI6huTBJ=IW4G^BM6gYih7V4gl
zN21-!u>cnqX6?=@<zD+wy-uf7Wrdd(4;i$g-VvYFcYHo|Mr~}kE^GMy`-TQsua(r$
z@awM)4Y11V41T{M{>}OLa6DAu7S3SC4dx|{e}t=bzr)at&$)rO5Q8|E!AIQ4jA!u<
zHI%b;Cb1;RnVhXNlxyW1yIfmeb$$G*Yim~*HTG3X|0*@M3psATCV7B%4#L1<9CHTj
zkwm}Y1H*J$3{EW#qXt;83Tvo{=<h$}jk{3#=7rJ=h$<bH#G5-3|AJSccElS!m-qY?
z{2DGpM^VxhI{Chz?}Pszf20%=3toYL#@F$ZaLHT<FKq`D!7I5OKbWq(#<OzNK(kd4
zqZ3*g1Q5}Gh?FC8jXfaV8ebuok%1aJEdq)P$pu1^{JMn~dBEYMAQx>;Ak!LJc|4y6
z;A!#{{3^|qUFHPdQIl4XkWi3TBhAZAPfbnF&683WUpf2|o_TZY9=v;5&-)XRaLeq9
z=J2?<@aBryTNbBI9{hgKvLRLX?nB!(qJTzIl}LlO@4L5Z$c<O=%$E+ovS%yvTWYz}
zS)Qs7n3R(<DWGrko4B_f#lwv5bEvia+0*!$@89~z67ZPTCOI5Q+ITKsYF_e>x4u93
z(xq|uJNyog!%v~FexmBcRpvC;{Xbz18jLQWXe1wZ=_RTJZ^1eE0)Dd{O?ne?Pd`ig
zM;q?utz=vf*<%G~Bf%UIxbOkIfV?D9*Mmkdps}+G?n_5Hf*b>PiQorBvL6<O@VFXK
zO?nI&C$by_Fbk)wNfe%B%jZF%&^{cp)`AQ*!8k;o1fgvrDeM_<rA^<|u2=ZH86!2y
z7x)w#G=WL7k~AhF&0<N5VA4utNr4(evCjhS$Txiy`t~Nht**9ry3m34&XEd6mdO;+
z6-TN{muu!WHqO;7FReOatX0U$Mhc{J&|ZgddT(tVUieYCR-W^3ESGD;Kl*nLb+T=1
z{j%-Zru0YTe3_z<mo!*wjtY>(J85c;+~H?QOtknp<Z~$687~QlGHVAX@e2J7kEENj
zw=b*T+O~cEoTN3rRTJ?-{C$~Ve4aiyPM5m&{dKe2^X#QdmzLV|+GnkMf2}SxE?A#8
zUQh<>Gv-dL@?DcOXTIgi+=S)h>mTf$e!71A@`SlpzM2j*NYFH#jGKMDH0WR8&&bZL
zgUy8<6tdRzTlCHjcN{QYcUlSABfbSOe9!U<C(QN9WiX)RrDcW&_<ywW*y{E<DG?5n
zUVm@7B_Uw=9J@}WGmS6oe5<+x3wFGS3Q_5El%RFVoc#i%+J9u@W##D5EdLLyQZu_P
zQT`_DH%^ODS6gTf7Wp~GJez|0HlId0&J(U*>W?2k{Zy0E`RqUNzwuAYF9WlJX)Mn0
zn;-DTGv9$;MWX8k{XQlN$0SD%8j;8-T#j6&W#mZ18;?`)3H%&RMlZwIIS-v~!JF{U
z=*<Vd#$6x7ouBch2hkh2`w{9hxJrR|^Er_36?p1dSe3b0=^BR}CvhKI<hmrI_E4LZ
zcs9tWlh>#)+_N6w;(EcQ<Ak&G6<(`viLMvQbx(w96%ZuS+clJJ3eOn#j{u#H|Fsu?
z)KJ>^^z=!75lFQ3(Y~fatF5rmW-X+?Am8Nb4*(B9t2ZpvceO#qA6;rKEU?)MASWDf
z4lvUwm-7zq1ot!O#ca$;cIPsXnnWJ(PF!EkboU?JuoqmL$v-^C;ok8a8>_<olnI_B
zrSML;U{w%#y6+xxMo%Z_?ozJ3aO3;Cl|!U9fq;}XP|iSE)SMUCBCe4_nBT#|%CvzJ
z2s8sF5m>w-a-Vy_MGC!3{RnLC`Vn|;uOpNK6}#rf(p}*qr4X3hcqXOXUJ|+LFU^Ck
zKP}H2TLb0wL+7p^DQ^I4Y%B8q0B>4g5gw>WN#5t~cIbz6pi~c}ZrY&M4G@VE*4l36
zA7p-j9=jfPo!P;8fODAhGUpO#u)iWM3IL(x02lox)QuLSd*IE4$%9xW(t*_=ftP!P
z2P+g<rhZFYup=*E^iqly(HRIN14sx~5B2mU;9P8)M|&itX<0?jb06dqNC}dbL9zbO
z;IzOBEVtqarUe2I4}9hwO0Z6(!{R!x6}dE@yd9okO{DDmVaCWrW*Y!Vl1M-_vX*fW
ziAK8{HeyO8Jk@SxZ6Owix09k0geKI2cvr9{*I-yItaXCN1xc|G9h}Ssl2lN0-QdBS
z2)5Mj=}$7v1bkZwKw0cow{qLR7S2kmSa@M=nc3nbwFaC4BwkLA{YF&Y>flV7A^}Cj
z1?cDNg<@$h<702~3)UL^Ocg$YN3PHsV?cmWLtlAB;G->yGiZb3#%q0;Ua43J4+O;h
zU!TJfgWF4n$ZtGqVf+KN2mKXMDsBzFc;N!Rh%6T_AWKiYLg3>Y@0$>+OYkl7^`YhQ
z5%`KfR~a3x<oXA~A38+m2qc<HO=~NBNd!5x>wt2MLS2O_tFyAI$?=IXB3@4W!1D>Z
z&;%&WN1(v5{b%t5chRcS3{#d0SM(RvU-bLrP5p1(a|;sV0CZ=a7K@V{iP7*!Pe>Xm
zleFPo{YW!a_yN-V>`gw*y;6x_0BHh=^j^kCJ3bDO9ap5i6WM?BIoIy6kZ7Bj_Ae;s
zk9Td-$wz55Ml|9A3dipQQr}16=w{rVsE9Y@dLuBGrg88<Z3EHM(psS=7bj*{S7*b4
z*GC%$>g~Y=n&3H!^S+6F?TX-h0c!7WEI^^_2b#X^eMoz&B@EI1z)cKy5*JiwcuY(T
z83UB#Z}}9nleMjqSY&sxta^7aZ|f>DQU*P31dc!qlY9yb@lN;%(a*q>n$XWJI1j%9
zpFG%rCK*1@;wS0`4XPuD>)ZY_sv&n6-hp=v%k`VL^y0;(^T4p`RR$@Oee_mQRF=Dl
z{sQXycB2No`_jUdD;NGhsuwUyc1&kgfHwMnu9v4ie!0V7S#k5Qzg;i9oUPL(ybFOk
zMaD<Bw;5RKy`z&bUTnyFXvDZ%33xYQ=fAHFF73zU-)NMYJKEq!0;IbMKnLaB{DQ|}
zKJlyw0Y4ZmVfA1IB`g@&Gwj#`S_t8wb}P(zvOL-94L^_5=T~%i+>!R#y|deoj6YK3
z*9Qr3;!YTM7!q*jd)v0X_x{$c?^9bBk3T&A$Pjg3pL)m<I9=R(XF}1o_ukvK_5Jq=
z9x2Z3o9CGo%ymv!{}_|C>U!qr08J$F9x=fK6%akjpl3r>g3*^K&@k1i=P)a90)D)E
z{*qBTD^Hj<GmZKQVqqTq4|moaA<r88223yxMz6QvDfr`rIE+g1VOMkvM5(?PhL}%a
zM`U!N)-MKjO%$W*pMF4f{{B>qzji0Kg6gP88z4;WOnmbu2X}|@(AqzM*#wFkK*g%_
zL@M`B&h$sSV7nw^CK<q(?8(Ti2z~?qgrCAz^adJo8|)CRv(f`Q9*6N^R0`nY%XlIf
z#Ptc=0W|bFRHy{KIsiG|_tOvfet>*EnAjlb3I{C@<KcFA>SH{`4Ra|j<j&&d!Q5*s
z(5i~VC;P&>Z6$IuAlV6{3!3d@R*LAk-V21dv+#e<B7giv5B>uApT$3v4qfzAQ2Jmr
z2n`yX5p;af(9)i74jlM~9Mre3<F~c==N^dJCG9~zS`>4B>w>vC(~u8-9%bWSrsd3C
zu=T*V-;(^${-t;<)4@vu-6xdoL$||4unH~iHBw<Z@WGpe<M$ATe-j^s{k9bFncsuY
zUb%u_MUE?1kdxjAEw)C7ul3-oD5wYd>CiO53S`6c@wbqnKQkcb4j4@RdXAHf8p+<j
zfG5qJFhD8rS%4~U5-@rQKsQn4Z7}=_8Rnz;@KO$%rbB)`C<tHe!Pj(n%}ve~<iM{2
zyl0Wq(>^yR@{Tj_fX&7Lcrb#Jr|t&?=J&|pRqH)q;~nq8dpD8FuwVcVzCDKOa21u6
zg){mq$6}%q?Z@{YBiY=*01h^xy17|><NMLzfdO&y!8UjaU;qdh)`|v9$~{NH=LLcJ
z4~T?F7cf--UYJWgH(Jodjgu!dG(Y@cV@uD9B^NI(Uwj1J=sAPt^~~<NcmKFaqiXKY
z%y@4>&$`uDKHtmTP3AW7E8I2k4l|)biVRs{uNHQOQ$Z$PXdp>oNx+K;+S%7}*IaSR
ziZVu|WM28~;%7alPW7OAyyv4UI~tp*)a5vNO0<aXiL(x0ie71Z7k}g`Wb%71UhKhf
zpH$bmahrIP$2<$~jN~}rtp*Fc!+W(OT=G4Ng4VqYE3Ey5x8D}7ka-qAm2tCd{D!e(
zH;gO8nZO;uZi@zI;+~rsXfP<>Lf2D+6B7rM18vJhS6oS&rIllQd&gETQ&VSfXl4(c
z*^>dxc^7U(jTt?Cr(D<A?8PLmUE<9o{uqFfND{t<;`11G0~?6_57+?TO&Fm&t-!k#
zU=xyi&gEgS%7UEp$BbB{T)F}8KXaz%%o+UHre(@SBff;sY~S%6$bTMtJ`bt7$NSEP
zb8chxT)gX{V{xDL+`QTIsp*ABfgq|s{<wMuzO-~>B!y>@i&-v?VaF<@pHclW^bxQd
z(^mmLHWC*DICNU|tnGwn08$~I6H!P`q#Av-?}g0Fmk{&VQ%^mHZ!D#$H5*r6Si1DW
z%8h3-c_A5K4ZMl*-fg&+zWRDkXWzW8xlm=!qqtMh%Y4h$9~2A^-O&&zKn}u6M#C0(
zM2`Z3VU+`iRj*VitqLVrAG8`l@5KA2#3oHR^Jsmlqt})+^6@vuC&f+KG--6p1IYP!
zXQ;n!_7lkYKuaCB>fp;SJ<w6wjB|d1I9U(l%XQ621>Cgd-{?wXY5V?TFCBQeb1v56
zlei8x?<+>vdO8S?cof(1{{gn97>MT&{S$&)fK1|Z-3&_3vQLW{JXXML4k`-~1OyqG
zNRf)X`z`+;0V^k`=GgKkpk}-bW5C6drrHN5<k@mkC$9(`{L+rHA(eF-Hq=!PDckYl
zV3>FP?6uc`hlQLyi-MU^FHY!ADvEpwuZ8DUp-zOJyl+iSWKmN0gcqmcZ&xo#%E(As
zvKlFF2wp>e_}Xh{@mC1+U;_Wm9eg1#4EPJ!q8YLl&F*kQtX(_Tpodld5N%g$l9Qnp
z>2!P{UJCKait)1Zhflr$*!dLpC@gv5`NMCxzL~av|Fn5Kb~HCP&vvT0Hx$k}wY77c
ziW`jDIh=b<Ah_WtCF7$<!5K@!oCT|v3EGs5XyKi=45Sb)1|X2j81i-k0-1k>7vCm!
zyw{})Bw))Oia&e&>XjYaKY*PTqfiT4iJrid@jvl)+y(KeFMxqucl6Vbwr~HSc~@uW
z-hI<LcHdaPuVebo-P1ewavT0x-2Uy3OCN4Wu{%1?xH9nDJEy<0=bfVIUvIzs;hxS1
z_I6I&y9=G}*t2u`^auC4afa)7AM$b`?sE>n56A%^mHjLcND(}Q`pv<FQ^DO^3=;g9
zfVmMG@U8{#!$)^5f9^!X)CrT1Km1mcrSXd$_kVh2M^f&j9ru3t%e|W;)Ma_c$CQs>
z*7wx*&S~4XPw&`{`*uCK{3u#??%%!7w0E9;X!E(Uv-R6Q`t1IlpQ+#2_5SjOYu5j?
zcvjZoO}MS2Vp<m!(Ya^uw9dUy0YbB#yw{kkfPWJ9hZy?7BbUdAh9}#-Sa^il%G^IT
z3pf=5xw^m9a&iit8t8(<dkrsDEIX8$u<Go|nZ8*&ito+dGPHNr_KJ|==JhQB)`e@k
z({g6*>>WC#0MXPvxDuaO_+aVcVfuNN!iGkA@ujv$@auhx=ns){;!*rtUjx_r(XnZd
zKRqdM{yV$31U~dC{@4D7n4j=hM;}^#)%7HTwP*x(PA~5>=x=0yU=D~sqW-(*%GJQD
z0o5ds7%Pe3lJ}Ww)t*yJm!8_~T7{nOMggb(f&9DC@!!t!oK)$`agQy1?zyFpja%6}
zd&?>0i~n<K%WT(SVnil<r;)#u`J9Z37}(H+NTNGXBfA4N?3{Zlvh$aIwfx-3q1pSg
zd$V^H_V(<m49*|7wk6OxXG0e)jLf{Z=IwLqI>x+1&-tY3dHhM=Li#f#nfN&Vxv!C{
zM}pn+??2QT)cN6#O+kAv_qEQ_)x_j@?Anjs{E&Bw`386`$O0Oog!v%ir{RNOB9M1#
zL$PZNN*Rw|#@4aub^P);ltOKHeWRr=QirsZ($&HyVf$G08k>#UR=i=Xho0XT_ydnk
z;p9Te?3@q?8kS?h@Xu{t0!GWDSYZ$A)ZE-mt5GU|99X8Ng@9b{PD%rDI|Tm!-1+v-
zmedI!EX~|pRhY;vb!hlnQ&{4HV;f@<64Mvzrfy3sNU413#e#%D5nmawwr|Tjvsbl#
zFlWyL)7GPTJ3n~<-zc0nJImfF{C9nG*df@DSvz4fW?n6|E$KtD`suS~t;hRO_m}3K
z_{k@W(;g^8^7C8At-}Y8Zuij1Z2m=N2&@Yt5hD3CZ0=0McFs!jx$TO7v7-wQ>&BJc
zxHOlFnuQK^qeDj^trXH`dZp0^tVoAH>p#Y#sr?r>8vpDLfI?{L=7-FBXg9)Pp{JSc
z1~RE*<dA_Rg{&N<K>^=1j4fo$`aR1lYw`J-$`yMcj>c(}s>0{DAir>w7>@k5;PWb!
zicg!iz4Z3;r`|fX1C2ymrh@7^4Cb_Ep`|DqAHh4O;#Trr#jQBW4&bxJuxIu**bn<j
z*lX_%*!}to@UWpFyoL<+)Keg0O?J;{0p|kWeCR;rAbg*2FLJm~*l)trU_~hT(U{yP
z;5Gu?5NgF*A8*rb-FG0}Ge#s6iQxAHMU!|<o(V6w2Xy9<<d6>XoJay9?tucmd8OO;
zik0|KruQ9Ic0e)gi?rUls`naam^r)k9wLgpOMnp;44Xjf1$7s81~Ks0%+~2bL?O0x
zCO7K(p2LUtT#w3S(rqD<;j_m~d360jwD;ipN2iQ&(fCSsX(?qkm>he@m4_aD&~DGf
zMeW0ewUdKdQ&F>F?lWfYxD91V))E-`ex@`gIGqVb<!A3@WR_Ty$~KJSnxC1wp{8PV
zhspxBPuM@W25EyWs*ch4-Q@7_WOBF~Ld(bPb(jp9cKd@=drCw^3OQh!|5s2MpTfTe
zj(cR&+O?Y=8HeLiBO_DEajicWwdUI4j*i3Et{v>^I(V&bV}GIO!<dqi{(t)IU%`+4
zR}LMsV|SP-${Z4vq3cp9E8@dq$0g|X3FBhJ;wzM@E?q`cNYvEbJB}_`RgF6Fs_In>
zjv_mLEe5Ynj(7HU98>01*L1w#u73NV`=-onNXe@ooKxAja_W@P%DGJ%P19WE=qXcI
zHdf{guFp$pm^tOXj+OiJ!&H90Z@l5_rwYs8x6)PZu6Hsu=vYUuGd_7pM@@AecDSpZ
zvgGBL9fM2;gK3c5UDs5#=gyZ|(FQ|wRx(+VhNPZC7`nffP+cVYmGlvydlL8?*0*-S
z?(u8c9&!;p(7xjQ%()H`eSBdT_$Y8`u)!p{gQ#R~?&vmu^VQHtjG*LOhzY_DorI7p
z5H>kuZSBP68`8X@k??^}l92-B9>}HQt5}665yJR+p5*a8!vs&tZB*)IMe<Jfrg-Qj
zZa|b|d<^4IqgDo56kov(OhA4E=sZ~N25K~NsL3M7{x$y=dzeWL<5UOnSOY^4U(JPX
zMmB`<eyyF$fK>>*Ht*<75FUyxoA3dP$JvYRNh_)|k$8EzJ*BN1JFug>EyZ5GT#PcS
zt1~mJwd1q3VWswba-KN0Fh(1Q%E);c3e?6Fj!h)z`S#K<ZT5IAImfH)VPST1AoiP_
zxn%umIIsVV%cGg;EeS<KeJ1wo0#>)HXQI#0qJ);|G_#^y33lN`_=GFVM?}G23e1lF
zu>QUWVeWCy=EZ2aMUNM>wY9m%_m@VIc>F(G{T{rJ%01ZC*4A~fWX6RHGfMD~#hdq_
z2#ww{os`4VdHT@W%xd&rVbIjz#Pk@$*o{B@uyL#bB3A`Z4Jv#Ok!n<DMwt#8wd0Xm
zG~7Whb7JwmN!dSWOfk~v8j?^GEsZg0e#lNj6Jv8of@8P{e?4AnJZOr7OQdvT!H(bZ
zoKTeKWL*E9p@=>)IAIO~1NRIx-qE%X--lMx*fl3%@Cig;td8s!(2<CTuSe2??#OD_
z#fplG&#m7{Y`dZ-Sn&-@g-ARxW^uL8G6R}Edv+Tg++T2vP4b<UZ=Dd0lahkf>fj`!
zE;?FwzIt)YM6sv>!dfg#f}(h9NJkUh>SrY4kp=vO<JcY0QeZWC8mk2u<Phr+9E=QV
zEBFz?A?M4rYAp;!VO+-^5cXGV@CQd8#$te7%ODq@fiIT2&~JF_GjAf(8%Xg6GGBOl
z+l%|~kq!9BgIrzTplQ?xE;HS|(`DYteQfTH$LBI*ug~S3a<>u;BK#hm@HV=!8XbBC
z{&4wf%)B+>5VseVu-8vy4Z$L^E5Lsre;j|gW^mE!k9Y6p*Rt$`M6dSnk2KiFZ6s$R
zXEyMWO`N@)eIRQehCOcg1J5vmz=7V#_DB$MM$k=xF+ks9yBIsd>hJg9a=;o=V4oAh
zJFNQKdL4AOIK(a>0saEL(o-%OytBE%AY``yCxVx#weIkP<Q(pSoMmmL<kAWcLy~*L
zT-K&yB~}C$kuUu0n_+*${%uv&xA2qU`*Q@!h&m88DPzQ}2kTXbv*tC8&d(p+^!#B}
z{e!csGA6-2l+pKka#U0@InexC#jf}8ix1tuYwzA&_oLO0Pa#LOGs0>%JHCSwM;LHX
zO3K>9hu5a0?A)^_Z(eKbJUEtyg<B(>)sXj7#~i~5$oL)Nt<7JzE`M!lV`C#1L=q88
zc&Rn|^yz3TlK9uEt*Ef;=={l=&5nr?Q}RcT&Yu#oXR~JV{G(m?xK&;2&%EJ=DcLo0
zQj2o=G5q7&r5iePb36OauJ$+ShVrN%p`=9(PE%%KVW!F1kTce7HfK`2Aweep)z)aP
zX5G5HwQF6M($ljU<Zf@xt@f_q)Sx}+5%ef}9GwPZ?M3tv`T~7}euFUX4CPB{s4$2V
zY6kN}I4d=P!4ty(`B;cm!1H0X7k4_y4flL15KF?qxa(F{CqyHH5737exHwGHx?O6K
zgAfITe6f&^27GeOFoz1{0hhN<pw-zl82W%20&cMhK!JoF+;_;phX?17==~E1i(DXq
zT_wx9hr!T|<RTxE)1F9f!w0Gd9!nrEG+;I0k%1%RV(-9Rb}&g~0wG&gG?F`7wirkP
zY9s}M^mG!r<bIom&@FL<Bfe*UeCjTqloAFJRbiF_D&)aMKT3#WK3S+pY%cC^m=|Vq
z!nb?KNoKG69h1qcARmCPbdQJKRb?SF5l~nh46GT0T0;)^6Y$F-lUM{;6ao0YAc&nB
z_xHe4kl)OQ?0hribfXjcBN=eY!}Q5-ZM}K$;GA6|oxo3M6$eXNM_K~(&Er)5{y{;0
zLlYMzSVn1mV*Eossi<s8k8O+|X&6imi|rgAuriG=n<?pgR1*-Op_K?lCkPx-G&eDp
zLiT8sU}KbwIRep%Nj~8sKO@BiY9;Z)6p2bptD?goTq2(vnI=pEX5cGRW{7kBDFs*M
zBln3(6D7y__{1hllM)4tNa!b%F<P1tG?pvMBeM+&zM*-Vu)vHN0g*Y*q{KpjETy5`
z$~TP}Zb+bGM*7PF6+u4X!XQ7nJlG%=D5FMYwvMRMSOnpEgO7i7j6TReCcv6$k(y<J
zvAXsNQF)dCW$KU$d5BM@&>%BBHApH%Jb_QdUhzZm5?`)3NSD&+J2BH}5&4;7Z6n1E
z$+pC(EQwBI6d5{efA|57m>eN8ha!pzu?P%inrqTC7Cl1xa1^1ZBSTSGB(0C*+H_oF
zG#zQ7bq?eRp(sCppP(S0fE$@&BQN5OP`Q=+xGq{9ZnmXcW|isv^(o0ob0f3~xC{bd
znFL`PDiVE;0_DbNUUY;apeT)>T<W@i%<D{A%`6>No0I8Nkn1YYwiZXJBCOJpX7vXl
zTp5I24My>@G&+_UnO0pPtZYv0dnF@M?VnUmZ($-rBJ(SPxFHn<Q5xzAH_L-fy1qyq
z-Z(BT%1;U|;Sy@qpoL*mjk$i)n#=*=YK=st(m2%NN_kYKS{I~|>HQMQ0|WI&V}?|(
z4ycU|1R*-=2~`BfKPn0+AGx28>yk<;W<t0kX`l~Rr~==}ATc+X5=d1-I+)@~0(iV&
zKKS8>Ah8xax+xz8r3g|Y5if*M3qpc|gc?7oNoSO+#6D7mM&u)Ae8e3_OHz1*yi_6=
zgr+J*LLX6>k35$ON#n^B(!lW1Jc}k!9s-fhoU~jj_N8QceVQpWFi;>9O8gX3N~F;!
zg3bPBa2^&5RC=YKHl2x%wbdG;2l*7m7-j`J>XA%IWdvn00)^NbkfiVp&=_^*km$<L
zLD97p_lF8K>X-&Wgi=Te)jT?c;*0%xR4~o;f$eF0)QBez5lakGksp$TND!$oSF9Gn
z=w2k!3b-NMCj?6V7MX}ft2ItVVlehwT9Z0HKU<pZj8Et|nqMF-lhC4I5f_U?Xkm!3
zi;)M*8ET6;Jw&3967;?9tCLfHK4xtgpAyi#K#Mpk6UBrCm|Z!+5?yc*%?S$Rp-6Mz
zq9C5Hf)1t?GM*De3dFeZj30<MT>>WqqKOuA26Ku)U*{l$jE%`|05)}Ne4x=9hy>tz
zj|-G;KF;G4-Pi(ixjf>6M=n_QLKqA0)$5Z`!+cwu7C)BrWzXKWw!J-H=HSP)aklxW
z5%cF%Rm~yC#^~1ij*j})XsW9%K3dbDiH>jU-ntcitNMQDzy7uJKT6*6eo>4fDo<=%
z{oQZb<r~}f>}lIrp8eZ*tGAt~Wb&(K&#r<4cQq$jtx3%;&Y`VqzWQp-)<Y`1{lMV(
z_`wJG^WE}vK>u<;{J)``YR*{BG>HFq4`(xsoQ^?c?l-}g>MPFIoPWcrpl^vJh03w=
z#P{!5DIf&5g--%bYn`CS0ABRqrwnq#+fd<+QA9yR7h;5fT;Az_ZeoB%+HP!<Vu?t*
zO<(e!HD#+ngd>~H+bfdxHiu|fdGHqv5Pe?{=<p@f1TZMz-Q!r>0v7gLAy7-d%J14g
z7Vq>}BB=U)1HoO*2xw`}sosi;-cvatx!YGXH?P>9>pIf^<VXDl)9(|@#6gdh0t<`n
z_F{7Mu?7*hafG|mO+fz#69bZY)e^4&%Yo}GYeaa*V`%7mu-{-Hpq%~I2Hf_i_JRx1
z!CGx_w9_2m=NDi`L7t2%PbqXgYj9Aq#)lMlRf=&cYugyY+BxW^JL#D0{kRM)3HQM|
z=6ztTKEipL^8)96h%W!dEh_$w9TAdo4eLht|F0dvGivM~J$ioo7ib}liO_t1;6Pv}
zWYlJ2)ql^ETrwE|A>=*u4kJ&n6R@-l7DKQUK=0H-_y|w#e#PSdt^PkT8UB!+e7j`i
z8|RU4`Vzi^-^p<OM`<CN_>xKE5@*e!@wGE&&bS7X4AcRb7P>4|{q!5<?{}nQ<HnA|
z{!vMmgJk{IK}(XWGjZG`2|edo@-%f1X#f412mSwtG7kXaF9?)c_^N=TuO4=s$_=`t
zy#$){f&8e1xbm<qmoA;9XTnYV6oYT-wU>3Sg_R~hKT~CNkUZF}i3iJr(Bg!s{GhP%
z@$e*yXlt9z{R&7`cuU@hVDCL8th*$h<)NUHhrxUtNSp!vo8}uV<XUNPg8XoTrVWdJ
z;0k2P+#5{4svX?{`ZbOF_R-ak-^kiYFGfk%#T&V=Z~G1NsGIJd&aFcCu&T6e$Pm{_
z^rUO#<Jj?FVggS2n0Lb6e_&D7EjeiBltAR728b`$%9#Kf^(2ThH-+W=gu$}J=Jb|`
zK(87SzXay5fbagfvQ6%?iUg}wyU9}t)96OE5vJ6wU`pc0!D1ZP)0`EUVSE00=+HZR
z?^Jp}+qUhq_a1)eeJcCUH09Karxz`Hx+1k-Ies)3{yNuIty@=x)WhZjQGGv*$@Glw
z)*hbG+|qUU_iC&wWc28t#*cS34`{qnePLmUFHvlvK-Y7_*RCDDZk_AdxmIIwalX+y
zmpRNL({>A&;{bOZ5D#rWXEDUn?d5Fc+z(Rq2<!>{4(Bo(-}Fb$O^9zQf;j+~+CdTE
z{#$^Cp;4#-wZhh8ov`9|A*{IFj2=MyVSlP;LDM~lK0u$L@6k`N6#FK{p%6u}-0V;F
zTZ`tFa_3P4d2VlBR(boIN-qgdqa|u5SQp{PsCH=C3oRtmaOT!2m24WU`haZEo@V%g
zwr3Nq5V$4^sS}}~{@g@K1zt>4OpwX!E=ZmSASc<f0UiPBf?u%NTF8(91`rnbA*pIo
zvV+gENnnY<`ue}&CJ-j6I|*LlfJjH=8|F^?u>d6k9mB^&3`6Yu5!i(-8nwprLK5<Y
zjOfU_*dKS52#Y1p!aca-fM`2#35i6YkXk@Z`%eKU00+rV;*GH24czpCltmCJ*8wG&
zJ&&+VogMwK%Z!ORmyC%>l>pyRQx)p~epk(vTOu1$-JmrHEj}U2;bocrO~HRdm30aD
zf(SlO?&~KU?jyFA*FP?bOO+%wi4?*U3SCo;Srby*_<=YfNt{;cYYtaOpAxAw1)@}~
zEY!!EButCc3PgN!^fsQj$X>8gp-<#5$qfxG3{e<^9hRYr3KSsFDkUkxc!}1+1o_F-
zDnYu93X9??7@LiXw$ricOq5-a5arM6hJJpC8v@Fr&NV7DTWk-Zp0`ADBP_0XI^P^G
z2n~R6cfr(KhIl#-)XXpx8hJQD8!<O2IR&)GvP^B9E*+O~BPmUoz!W5>X6qwRcuk-p
z0u)H2Ja7S`{NfmWBE>Zu1g0t6(qw*`>q}wtt4!MH8MI%hStRz8Y|bt4$;3Owdn0@V
z49`~*zs$EWMHj?~Eym0hBDHy>)Ec3RDsDZ`$b)2DbWS|d78k~sCODGudOA%OkLbap
zQ=2P=71e1Y`=*G?ll;|@^lMH{R6#`uH>e^%G9;pJt3hlJ2#9@Gqzbi26rq+4N~@2G
z^4ICLK00oihi~0QD;0`->`8eo5z&L0L9t<VN%67LzpJLc;wzFQ$V6h5Lb_QfObelw
z2g^*luqi=I2<r4xtCi63Y7M@m69(x*I@H053g_b?2&r`P)L;r0Cg<ouvwK`1H;a6X
z5fUNNMvKd(K|v0S5%(In{9xV?1A{{7Vm+S<qDM#-pzf-;6@mZ}SI@-qK^+vx5?SSt
zdIYwI(%4-UVr~#uLLDiqqNE~;++{;zy#)D*qy~u?eNj{<EyzFGkr3|$g)!f$iHWSa
z4ElAj$Tb`GjX)|P^(avq>DT#wG!sG<iPU^bPag{=N+fkcXG#r`8Y25<2$kWCk7!k}
zT<43n24zq(F(U}DihX1Xqze*I{4n4+K~Z8$Al|PtYWTh(s3Fq~n_;*XNrQrQ5;_{T
zmO{M1zUKt6%NVGbzC7v|kt#gFu-;c9l?g?XOMXVa5MhlkD8yG-S;4y{D+1XO0PN%k
zdMJzoh>l740AWzK>z{~3>o9<i7m<?8Dg2lwCZTiJGtcbmOo;YYE>X$#Nl#uxX(;XD
zF=Y3U&AZoDY(65D9@)I&nwQ>q{izRIOr{pz=PXQ!GYuc(uYoux#PbvMJqV4VV6+Bj
zn36=u=pO($lnQ_mKKwQFyZ7K<j+@Y@q8rmi=u^{i{L7y1`E_~sOr84T^UuFHb?QBN
zb!g^}2`%5@AfK8VA9VG*mI*r+EpF+mseJ?`<5wQ3t?6o64D%Gk=W{jxF!M5a4Y0F)
zz&qgs&JTnEy9c^@t%LZMK?E*0ql9!fV+53tkuk^V;2&-**)(_V+dFr@J$LS=lE&E!
zKS!MN=Mm@gg|i##TTiT?Q89gb#f<eQTI-)HK$7=cTi-{Lg6HUC_wSp(W#+6m@D0Sg
zF>B_Q`TOp_wr=w$pKM-t?NrB{vZPh3lFH_EoO<=6O8o0v+qb`k1eG5F%uDcg{%lyg
zP4=V*cZ1tM{Mnd`7r=*$`oJf49-4?7@G<x_pxvkl6@kxt4pxHY`Z@S~gOxZ3K{P|$
zidVv?6>WjyN})X-WWHc2<IeV=JcECa5<m>SL?mkX4|dN!ag+0+9$jNw<(mFweEq~v
z6Q@2jVn*@2IY*EDr+CJQho(+Mm!F%z@E6Rm?b7!vqMmzr#w^>$S%+tIe0g}*M%%0z
zWS*AxqKQnmm&*U93nHe;hiyW)HV@u`;LA*8GD-exl+#d?ySTaK?CjZRTbdW=*0j`h
zBg4VcgUHZb*W$W&Sz79{zd&1yCeEy$T3&YG%$Wma<x{I?PV5|7h(_Xv3x{Gw&4B|o
zP)CC2e%kA|bNn&o-G#dDLP7+O$ct8P(aD_@awkQw_#dEw;b5iteZTxuI_U2v#NgqX
z?O^RH{9FA7ob_*OmA^<i4Z|wtWmXH9W|l~!pI))Dp*dPwlDSk^ojI>!*mJ$e_m%Qj
z5U;ns)-{)HqyI@~4=)%s+QiKov@)c*a>d~h)ypfJLskyT;+jT}T5#{HWPQNc7T0-q
zV{yS>`Luvyp5Um!dpL{J;>HMT^@mDApU_HS-xT+L6A(xdYR)1ErZdzk1-lD{2Op&S
zu&J;pkm12fd%Y=)bsGg;1@bZ)pjOy64#?OEypAVzr1`|rx_}caBmBdk#ba&h!uZr@
zBE#(wS<m1}iP=60OpyPxQ4zL?%x9TU{LvMBwe@NI7XBXZUpslXPsgwpbnmyQ@aoqn
zxuv{KaR0=$RA|-8ZCS?H*3l{BzMuO1e>6!iW={WX%!uWClZ~|LT=GQJIk|T6+;Yv1
z9h33K3B_xVTf!nI)}^+7H??NT+zQoWYdSy0qyMvcy1&ny?MSeqxx|#JO)eOFainc%
z>)|nlX{uCnQ8P<>5Ho|?4zZ%Ze~q932B{vd0q)h*_GPm+k4ny5IP;zv4rkKF=IY4!
zs^zVXam;J|&vMDLMuKT}K@*D<cQ|jaa#)d|)o`~zsjm`Sm##RnbhfA1F1u4-X&ABE
zRza!W#&5i0ST*j6oev0aT;9-JbL(Ai&x~u@S-l2c3EczWWe&kRiQoGj@S5&?F~c14
zs({PnbwLmIst#9j`o^4r+Hw1?l6SH3L_F^TJ=}E1+n77wW}@wk`fhJ@x=aTK-a;*V
zqVMd$CAaSlJn88tj+6Ip!rgQX)KS6-fGW$#+?5@i-GPS>NI0Ha4jw^x*dd+H+5Gg%
zXPyj=u4yldk&4j)^c3EP4=uOwJNuSQIlXF3&PZEGXkc>R2MD~kJ>^pbhs53hGvRWw
zSBO<^a;RxJBc~2Iu}$qn=hRMI1;k-q%u_M{c3p&@zR#$xS*{gq8KrRRM<|1M4FGO@
z5%{Mv#5<ptj$p&YTfa~)l<jl`A(F@GQ1i(<epJ;t@j+*uN>xV=C#v+EKa3CVSMdVz
z7BsR6Pe(n0Jk<iYrY?9+&{+IP6Iz8Ad#+t^aH69wG`Ro_LLVl4joHGy$?gCKx{%pu
zkh_<~!hnF_5xTwH(0@j_0-1L=up!0S8F)Z4@xqbALV3^nRSmO6N?(t`FLn9)tbho~
zKE7S}rI_oqbpL*mj?xCwQJOoQn(Eu-8a$APdde%0eIOmb=1C{86MEar+<-mH3&3Lm
zdK9o4?+O6)PzUb{0QA7byemLR<n{^>is3<AI^rtJI`e5D+&)PlhE7m1!R>*>--oAQ
zLPHLoPB4ygFgNnqDu3MND_pMAEf+$SKO$h~v+2k%kdE|hdUnDa>G<OSOG^`9&@{#p
zfImuqBO&2JDl!CE#xx1|O)ZuHq))w&KnJtMxe5o0qmFwOXB$Yz=h$@jvo?2m_}sud
zT!l~`yq7vo-U0JAD%kV=-wcLW+wm}8Q^OepR;q>I`LUB=lTWkpqro{>30Q(y%@7$B
zumv~Bz7y<9Fq+&6LJ&Sj2_xxH3)vkrlU)++G?9IbKs@qcp$UvEf%QWWYFIU`(J~5{
zyr3C2%B0&+0T(<Y<90kFp;t&85kN2OYQaFjtq@qb4VYKjoJvsF<py$P<(-sV#p5%E
zHNz@{AwOkIQ=USrx}wU<BuW#Cjm7_sYj`F`<Nx)W+92~~{3|;Ai>VLc=!GTtQ-4+C
zU}ZXb@Fm|EQDz7FiF!<~tZxdf#xh6n+oo7Q0h;|OiZXwQmm$uP;`Ho3>9C~vb(!y?
zIot!eY1jyJjIR`|*U;jRb0hl9yr*!zNHl7iub(U6SMcOgVRfzcdG5z*HNG#D3DP8<
z!=n%%Z5%6*^Q!j62KW8TG|KgB&F~l#EL?52=n5bPoG<Q5?Yp@UeHE1+XV@7d4vqp(
zrp-E)k>Z9OqtD6`U(DfZbeXtBX%K^ntJ%e~WuWG-akI@qr|fKR#k;R!aPaeq5E*z9
zyl=|;dRgaCs#$^>xne2L_ELb^7=ephBG5{CkZUYDxzSX3lJp-gM~2(@-}40EmLdng
zUeK9XM{MGbjTqP;4%!YJYV1~6v_w=WtK15^%36>dOsdTHIOj4%q4{+TnAm2_rZ{~U
zT42!qTnjY@|8oqs;b&UgQv<`8Nn`LxR~WkQGJ0+{K2Iqq*!oa{E@FEMHPhAo?Dal~
z@d1CYP)rJ5UxDI=Ac-OhC*yI5Iwe8Kg`ahO{d-uAoajG+6}mT28@rYt$nP)1I}*3v
zY|1U9ht!_^9An#GhPdpxrr`-w^}FUjjO%ZM_;%b{!9VN|a7zNq!Qy|QcQOnxf)~o|
z;Hx!%72h?VOex_F89FOPUQwcSj42w*D{nYArUNJZ#hScvKtCmJxLwSxVkFk|xXJoO
zV>G@p*AutZiMfqlbYN@$LyBR*7Hv1!mEPn6X6gSyF{1}}<Gx=P55}?HAS3x>ccGZ?
z7c8g;Px9wnpL@ZH9{T8`J83(LtiSy|ZF|N;o)!RcM?Cky91F(4zewlhdFjoqgZV=W
zW-U=S@X@rsSmmoY#k&S~0sq;0YfQ-0*qSm0LXmZ?w5!Rh8bI{7<J$zQI8y$+7IqoP
zA&4yj)b9;H%Y0R8!ZH*8M+;P>C)a#{43Soz$+}iqnEo(M_O1vj92;svwdHrKP_-@b
zI<g5G<eQ>h)n1iBa~q^QiG<gC2hZ^%qtf5Ei-|UpX_~*<2nGMS#|3M5x8OW)c<%yd
z9xg%8)%NZ6f{^eS`ZoH8k>u|o`->n!(3QW&^IRo&z`*0!@fQ9o%!j~{1Hg8a#LgoT
zZNWsMmVw3JBZpzM6NL~+Swx#y`Hbj(scZ(Z%(|edO^GHD!8A`z-xADL6Oq(JOdELH
zKgCOU0aV%B!4C9&b!bzgT#lmV6&<<BK{G!z_eouN@w=II^OI=Tw-LD?iz%(*<<qo8
zK%vWNH|Fr{VZR2r{Cua45{b~BY_t+LKCi7sUvn>u@b(}H6NjG2)M>amFDCYVHFyHr
z@ipF&K|P1ZTtyA7?KjTgjG>(}y+4XURa^-&3nPT+9Bk-}XGFB1CnJpJfR}7MshB&n
zZ{o>9(?+s~muGHG1hai+=nJ{vsoDVJlv@jl^&H~=_6H*kCCrKZexSi8BMt4Jk2I8?
zk%oZd+7ILU;jRPJa8MQYQ&qUeS2ki~a5)~75cnK8aLG~CYe*7$8Xx>(SI)G)j)KJL
zl}V?dUbb`xE~og6&(W+!Lb2%8bW`7Q?moOiC@gK2Xs-Hwq)GV|=a;Jwg0Z5?wVy2?
z-s0N-h;PheX<Su667E(6@pu6!(^V1YL|O0P)%Dc1HDhY=i{~&zA@(u(Ks-$$KG*yY
zU#WCLK4tbnSzMu*7k5Ns3^wB#qs*vT6ykaWtzR6PbpU8w;Dtvm?7NT%Jf##g|4FxF
z(mUSqpU@tV-S23R7^?mn?fo9BiFd|J#;ae$`?-Ep;d6lr=wx~D$PqGMB$<}8>kCwQ
zI<&9jGra#)QswkS`o4Ef>92}lvS8m)O3bIwA^VN*nE=N}epfY;)>5Gmb)}*vyy~F3
z96fU<rg0Ss%{=gG`b!Z$6(D9J(ek7K6*uj%7+3P3derd_e!&T@^J~tb^x83fHaszZ
zf|T)#=tDNH2!%pBpyNEL4(~9JLMzR|M$M5po><78-1o|XtWaW;Wp2Z}9d;k9_;ZXy
z_#e<+0GHsvbIU3~s1?>-c-d^(kuuD@^{*X<afH+1K`bGsDwywt?-tkRcpjeT`kV?x
z3(x{8u&1_V`!|p20-m|a+0tBH*Rrj1+W3;dz>|Gjo2n<K<xOgDYsj6DJ#*~X+zglS
z`>m}x8R>ZwA<=_7PqCy|kkY(M-`%zF3zHFFSk%39SJ#5v^f5*ljW6ulIc?O~%EGBD
zGNz3z8-!9umQ8G{h6F$hOuhQy9lTGNk6{)+lEaZ8+CX>}h%nZNRtetnT7wc+267?f
zgx#iaTbaltC+`#d!a3KG@u<0?cw$ST0oAMU9$zZvncaBL5d71YZ}DUIF3|RT_2ABb
z32hyenZDPDs+>HrxNrg&e{ygx7A8Njcnd1~b`uf|eRamc2funBv>s@uLVTHjoOuk+
ze88R{2X4bLfeV4jz&9`k1iCl`agehsXgqN8kK=~x@symYUwI=LFJS`E41754dM`bU
zERU$k$f(icmzj&dr5(M|!Gynh{lQ>n()C{IDY6nGy%vn7ygzs+>_T|=xBe9f(3AZT
z(6;`wKZ1o@=7FVeO+QflKZJ?w^LJNVcthoV{%1HEfDmo%hj8HRuCU^853ILN2t5h@
z1n%tr1^I39hREtsPwRT8|5+`#U-rY^cdq|z0OJE`cdbvxoo&#c0Cf0!nv8&zC)u1K
z|JPc1x6S{xh6C+1aP~LrdaLPfo!qK4w59Ma^&a)VYEEo6{cY%7+dn(^&i}vLxxbYM
z>ib9S-Jk2O?S8B3sP;|@xRr7%4~$X0_bMQEWUuj$x74P+>i-w^BDm0)o7+eZVDesj
z7W~n61MYl{M8~=v7BDFO6=-gwxBtCM!Y#=9{QfqKo;m@ntZn+%9uK#{>FpZ(draZi
z{`{@CFhO*O+i~%yZ}4{3z1!RFR$I?|2Wkh1N4eA--U&JlAmNaJI_{XD)SMTHj2*ZK
z<7jf1VRMj(knZ@9knaV^$>v25L!40=l;g?kj#NpaRFZ=(WrJoyJW{WGB6q1I=Ro{U
zlG|On`<ZLx1%LP)SPNhpp1@2X8h8#p+#jNo#QD7KeZ&qAPxQah4I_Dapibnh|IKV1
zO^Wjt#Ey=IJ%N?%3=A-cFi;r425%)gKNp5iwA^eWX%HF$=EoT>KQ_kjfa~4|ZeE){
z{f8g+QZ0MKlBREksi+V3E}uJe-6x3m0JxkbpnUqpH(l}k7fzpkmFXKn$1^RB`B5`m
z=uk}q0P6K#HqyqOZ~ddU+*Ty%Yo+**;AQ3}=siP0^QnbmiFp+atUjJV9bmR|vpk5U
zK*o>YGe*=rw;a<FKPWb&hcE0z>9p`Ihy<wAFcz{BkBl541Tz>a;miS#Bf-nHDo6H^
z3Ooeu4H=shuEUe?<lu;;h9C%aKJ;3kLg9B>7x-allQqKpp-!gIo%Rd-5}iW-@L4rz
z3@T~ye{1wwTsGpym*PylLQ4N8#dTxRy<)jO&$R^)8i9^byB@eWYu<fnLY$4qL&1%t
z;3oD}s282Q76|3b6@ed`E!NSx4|GtzLJ@ck6!&B0_XLbV#Vt8U=Dsj`L?0uT>GPyz
z3Msm8JgygKQY+BW5jY1(4f;IHx$wxGi#x_IZQ(FrnhHaFnjv+E<^Oi8N6ZsrAw)$Y
zW=@MYL*V_mtpLA^|J?#{jo&TUhMwMCb>Fsmc*|wSnwFL|j>~w<ylwYY?Z!7pWoC{d
z2l^66FT(Rgy}cr|U=e!fztJrv!(examYm@&Yu2<3&uO`_hdZpKC7K)Ueqa>zw1At{
z{C{zOg|;ncce{k~zefXr8Gf*R1CY?DtXl$D3f-Yhq3KC7G^^GLE*tPc;IsiB*a+H7
zO@K%uB$eHXofHKP%>P$%VqRT(WU^1OrDUvS%OZRgUtP4t(rVr$OpZ*i%S%kID)0H?
zp$}Z)bLJU`^+H5)*^^;I=JmM3FFtgwr@X2yE2(0~c7!YnXRP0l8-Ck&R3v2&ZH@{@
z{G94x`SsEKywKd?Nw(zhvEwF@P(72zjfqIMB@GW<E{LwrA6A_+yD0C(d(=6)&VTT7
z{4Nsj3(cydUAFg5<P|L*7GqhCzX&&Ii>EBN#0;w_hAsqS<Wl@1_b_t^EFxJj-!qis
znZXA=iTEOV{XpP97B8V%CyOFL23eBs#uT82jSbQ7+D-7nPA)(xU?F3#V2e5nY;Suw
zqp)<!*6TU7vs;haljkP4Zs7{$XwUd+S@vTo%hnt&%o^2H-|QcsC!X4q5TFe9#Xp2b
zRu0NfpXeXljvpQx;;0A;EFMdrORhe?uknE7+{|HZ{5K6Jg3UgBT5)Qec4X3cIbzO^
zuS$rHd?KdUU-i^PV}M*!CrpVMiuXkf`Tv-E@AxK;=3!iWMQ6!XR<kYJvYO@IWJ&J5
z;EFrO7%;|#j_K79O6a|YP6!Z6LJtWf5CWt)g@h!8G*X{bk`Ph>>z3c_$t@(`_s#o!
zzJL5I>vXqwySKYDJ3BiwJ9B~>;ufSE{JSP(HbwB+O(exlE^moLK=&L7GLR(LWit>o
zHWNVmH5Yd5E+#YqI>Kg!rU(jrXpw+EhB#2_LqC`~gV`>($YEzl5N!u-3iJ!<5bzjI
z_VHOjb_n=IdP-2C3iqG@Kq19HWnqcq?ye2>kOkbjnIMJu@OBw;Tdnl)^s4eGt;b5K
zcwc`yORu-sa_>j&j_NN@kTdZI@l*JzgKqvoXpSsBU54fa`QLNsv*`Z&#L}g?HVfaW
zRNt;I^{Ddlq+0*sVP+uiIO(_(8W0egmj{Z1j)mYHrsE_y9_(01?^#Dhhf;xV;cjUo
zHGV#UC6e`?p@A>I+z-8tqdHfDZ@anfDjA&@6V|U^Sd8PWOvU)Emy`th_-QIa@m*?N
za~k9gq(U8g{^8ktY6l<5GBp7qApyCa-&61K!((HGG*&nVSka<#@OkC~KB9a8QY4T=
zuQr^R@<bud+YT`j!2OJY7F-pA%+sz@Lr5&bwZigOJhpwtGcQkW^Lp%wwXIyM>e=g{
zdNKdF`|-n*=i<-W@Mm);ueH%GwtIO}^&p9I2>tBo31jBY>d4E@IsfQ$KBW|@d=Hsc
zZ@jmjqIfKP^TWfJND5TaVkd3<n8^eiu{7|hBGgXMvI$cPnN|q8kS`d62{sD7)P|5D
z!K_0~sEzOpao<m7O&Cet`QR6_GMNQAxdoyA`T0W!^k4s|KkJgX&`pupFe;Go2`^a^
zS6NiCZe?9Xm^vXWuQ@p|AS_ks?TU9~^lNQNwZe$-j8hw<Xt4DQ^^K$RN6#KNcIlF1
zUx+ttdND1mb^RrJc;N7HQWtk~>R9XGq@lAnHIA7%eqC!tL{^+{N?}QJVnVtk?&)z&
z6KhLGPYL!5(?xg&p)4|%7|{s)2j{|W68vBF2i+&k%n*PQ!j5ugm^{tU5n#q_0E-nu
zJ3#abo<u<lCbSPm4)~1#pHhMqw7HK1M>E)V5IF_$-_+NW1?S=u_CrEpS;^y((b18Q
zmy{JI{1E1IKrBA+Kcr8@r@sFlpF+joe~*eo@arFbh+jwXAAX49@tG+V6;sF;W&hvH
z`AhlrP*zX5y#>Dhp|iXx&@Zeg1dnss${qt-hZ2adG1zGp1U&-XKwwJZ{XzE#(is^b
zt5qh1DkN#aW|ecY5zvNM5fVaV7hG&~Aqts(h?G_!Dsl+FEK5V2Ot3Oy-pPuI$s%9+
z<;p83-x}0EV%~6zW%#^^{)65+d8INdvwe4JN@3ijP;YO~i1;iYjm9S{KEl)6J9JW9
zVM^-m_DqM>rVTH&tu0ASE%`aMq=Zd#7MQj7@j+!?IaRG&yd5vZ#?tBDTUx7fyvhbW
z?iQ<1s&j)TH=4|DPe~+CxtUFklY??0?p5qVRq;WEyd$$ohBwHXrl2vhrp!z*krIJS
zs0lwN{(}7uv=<~+T(ZEE)rdxj+C;Nqm%=j9I?;CUn{Yz(9IR3mAj1O*9SufNfJo4b
zFz7*!C&=u{Py$b6uuYFl;5I~_gJ0MRNfhNOu<uiW83<<scRz$^fQ^}8@&}y>QxqAc
z&T&Y(+6MPYrY_5OG7^O}uz<D3lY+oVfjkedhAV-s&_S@!UceGlP<RReL?U7tR7&6*
z#9!c!y3w;bUYs?0D1PJ2Srj#R{QQd@vnC9lUE1{QvnBXH>HSRJi>udQ(}c(OPI`Ft
zwo8)m#z!`?#mJU1lX1yLVQU92_BIuzA+6*6xzqgohRyOrS6ve(mA5?pw1>x;eQVx!
z^=va#<?R}v<Hr_fO)40=uCd)y-d5g!ybEf1z0p@Y9=-PP>OC{2K6((lg?Npcu@VKQ
zQL*)@srBS*3e^XMfLU?0(nTLA2@FE-T~*;FXu8ik+pfK}?V2x|jTicc*(U6~`Zg8x
zyz8vJBdhnK0Voo`6OfaK@8mwCwinZ3_>G*_geKGA6#Kigo~RqKYqlGGIze4?pd!Hy
zPZ-^3E{G0GUpB3#diFyFw$1fx`YGZ9(mf~8i`~s}Bj+C+S-atK&EV>q@fibnet7Z0
zDtV%RX08u@6ZN0BwRG~KdFLs&)avR~_#$7moHmD{7`4((rFWMAkD7wt7w5385Xt5m
zp~GY#Ikmuo1T>s*<UoLJF!aF825u5C3jpjMlEfMhhFRBTu)xpsfR#WWs5HP8P>mGQ
zWARJeX$zFS8;5|_L1se4;gtkY;c>u9QeLuP?g8=Eg*O2$bmnp92RaBDpePl*l^AYV
zA;K>dF4UNCRW@<X6O)GwDGDz)2FJ$-dxL{jR;5p?tk18{5L=U^(j==m11>7l^x*ze
z$9a>djOF1)LxxO#;^MsZV^u>&d3uf-q8ht?-o=#i(h>Vc4s=cCveFV`;V&^Qi%WJL
zIC9^J((<K)Vq+pQ%;nYykD|c9vKC`FRovQ?5W%KUzUrJDwJ(*zMkF+~7E|HIma@RW
zB991bxj7>uCU($LDr3^VR%57UWPEUNe4W-y5im48zc$NOQ5zXqTVczp%}*a1pzzYx
zk^3Vxp~lvIlO8%TuCAbQ!TNsv)-Px*s2g|Uq1J-D$CjUNc<tQS+}gbS{Jh%SvFBcE
zIKBL_yn@!c`Q~W7DXw2?ePAH{X0lN_VEEYTDN)1fEfFI}Mp){HMNO$5JA8oDnEWOk
z7+9a$FV3WoHWOdtL-AGaQT8fO9v#q|Y~XzXQ&=;YR0@1OU`LReA*wzAAWZ?UCnv)k
zsI$oqt6K2gL=nSFZ}J38P9z{RK$0c29K`B?AWjrA8SUJo_~R(>{d)N3>n+V}<!a=9
z8MX1FGec~Zy7aBHlCo1~9-1(jVusGaKber%0Bu=raYk8AIj=IlaT}jSSHz<yo<RCP
zsV9%~_{{vFmYg_kEv%4zPSSpp|FnIRldMy5xnfn=Ma|IWtq|eq+PAV_z;<QN-Thk*
zrR>e#2Kqqiyx-;f_`T-jhdPjK@*G2+M5#06{c$yT<D+lxocE^JwN(kHp4<d<m=+zy
z2gN^u56JGAD4bxgqLTxsB>u^EZ-R{-c=u1SL^xYbFPTdXn(GK$hG+2m;1pyL-uNI_
z-kTph5h9{^rlB11b&`GcF_M3#P(YKA3-UX5kb(pogZp;Deue@V$pz1NItc@mUT>y@
zot)8M#Be{~38HV&`HnM=XXz8UtX|LNvPNA*gwDuhL`G(iZ-@Bm-L>rDd)169zbG=A
znjQ@f{R17d$=!&I43H(1;Wm1bSW0$5!a^R=YB>v=80bm()8+W1stIM7xcaKYyXm72
zwHmKSFV|38ZZfkR*995EW%dsSf!@y!afLv74D^QU<BFF|5PdGm%nqCk;dw;D=5K-D
zAtM?XKENO~>=`3-nlPV3GW*9D2QFW3ynK0nbMt)R<iHn*I<s@;%$;Wt)!4CSTK$kA
z_0!gL@NZ?p-y-J)BvW~ZJG~D#o;%lg*rTGt!+GZ2c^GmH2Mez=YdZ2_|Niv+jx`hN
z>L$SV(XPui9e@WQ8@WGJ?9NUEsScTqfxSg$QdQu^phevbnc8kP$sygz!kJApS-FtM
z#2g8EY(rKLu&zo&5W=IoL4*pzEa-l;_7v1&{kP#E!DldrCJnA0cofY@JX$*`A|%*(
zF}q_;Kp?eorvB8#H67TkW<<>hnQ$(o7Z*^cnzt<c0<s@o!a)hpG}G3mNAS4jE!9go
za_V?@O$V!%ExlnGxu63*Ckfx*1mCN0vBr6$ZLCucRK^|@r$Ad{p{)hoZ51M%JODcq
zI0V24?H1Zf+6l8j8UoIgfDd{C)*;YBf&YRYU=Kn=Zyz(gvA7F(w~vL~+}zW=@yCrj
zucCQJaNFK?1pi9ms$<Rg<IEw_wi8(T(374$z=O*bC%YTg-mLj!FDv)Dcy`_eg%?K-
zZCxn~*L1WCvYN|`FTgMWu(Jz(|A>q|tr6xa8{-Rg?m{~O+j^?Irh{}G{TZoR4|+L~
zs=HR?fe!NS``<8YAx4Ft;JMpO!U%NXkCT^&F0}V{W7mt<9xXf+d#IXVMmJJaLqZWC
z#&1HwP&nh(Jg>33alHWeE~sySgn0mN##uq({dgT)FZKefwgl34T0qJNfJtO_@RhTi
z8XP+cNG$ILtg}XJ{n592yW$k7OySW)G~;Lysb}@z!PQs)QnxwHc=KPo=JSO@<(kpD
zN18~zH<(OlRNtyP`-*-E@XuG+Yu&Zp0al;5@-}F|9~ZbhR|cZK&LZfSoP9*V)N$`#
z$K}fhz5r_AY(LuL>^%WQ8&L+nu(9zlfT_E8gte+@xp*JYE$2H~E3q&$5N}RS@W5Kk
zN;W_DU2%!`br;mPc>aF(YpFbEJ)A&s)~xrH(9Rf<JF|zGE5t1UI@!Cf<KoFVP#2(z
z%pQE|#~;Z$?Z+QM>WOb%zKm}n+2zYfM&<RS!!wZ3eG_PSZ`pq-`LCt@r2w+-Aa&YE
zucQC$t`m?pCz}RbT@Mkq(d+nAr+D&hy10D#Me?QcoC*9X=k-NGGeygVxj+s)1(^?=
zHR(ex|2@?Q=n6DmAdUZq+5<?24|n$bzo73d)U}S=&BO`z_nNL~AAKMK7Woh|sTV?h
z@xaulXSm&%f94s?Bl?+V5bapn*f_jz0zJJOIUK>=XH;I#^O)!B>G!dsPr@@@7}JHy
zFd5OLUnT3haFzJGC-n+8>-u7=j*w;Nj7rF`FrW6qPqGgB6Gj8Smk=wVPvMHHcapB2
zadR)ew~p}C7Y79D2h$2UgA)E$HNc-XF#5X6kX1g>*svy<iKVS37WOk-?W`x}yUgCU
z&g=L9c;r33aT7YZX(K*zYtdx<<76lPwc+K=VKD+uCzrI0qlkY6iWqE=5LMBzr2#xF
z7-XJ^1ilg$lw_qsZo`lzD-g1HA<QQ*qp-995BE0aaNM<WJO0vMel1R(`1qFKfNj*L
z+X8~OJf0|TGlr*xCMG83)_2tBCM70@ri2?Qw{}~7^rgHz95p9kG)}-vBO=f=^vdXf
zK+EPmF{)VP4Ut)YidDtz*=z|^mJW_L`Y7buxE$N<+cw}v<q98T{NPe0Y?=7as-Ip(
zk(3p5NrbN9%k)bCHxFSC2`~kq7wTew{sJocr7sRNcK3A;Gz1O?+t8~{DE0O~l#N8M
z;ufZkeOBZz;6vXiAOL&keloJc6ESu8_NzVdKhh81x^;N<j*@53e~J?5y;tztYCPT<
z^MjJ!I(+!n%;6jGE2QpELYxr|l<z_OB}>3Y9#k1Zj0>5BWi^=XDH2O5J6eLL<LPJ#
zJ&Wh@5@&g+9bqbizkpWZiFl$==l7w`-?J+SR}1_l*SAn$lZnR84lxmA;N@4xe2-Tm
zaV@^r`<{EXV8gx&O~mA+-Fb5o9f<D@L}EU<s}U~>m+goh2w7pbCK3<Con#Ev;eG5U
z%sn`B2fH8<8Q;i2V)VjJ1B+ZIA+Lu6JqY5&e|Z)^f*(2i8;U|vzwO5R$rav@R)DKp
z8(KllqUQ2;T!o%!hb=O#d<EWz2DO9A0gR0(Q6(NlKL%~|B|Jyp-BEV31&3I`n}v||
zz2Z$6tPlm_G4Qp%dG^L>!&kT8tHD1adCk35P1D;a4H`Uj;3Vg9%F6QWoQmb`{WHCo
z|KRU_7=(H381y5r_R8u%yEG=)6kR49g}w&(F(%l?tcSJ&Q72}|-2f!R2SU(-&`20K
z#B&2<n%XdAa8F<FX>7UjDv~x#MXxTHIB~(N$Rp4n|JDW9^qP&^Pav0z=L21+x1YX#
z{pq(Uz{k4#GsFX!Z(%(tz?Q6g1b|8iG{pn>aj0MnxMDs%1{Lt*sCD>hI6;MwM6E-=
z@GqrPNy4F>N=oNnq>|J5m!KJ>TwqY|F`tsPNhl&1A{5Bn>uf-;;@T<b3_3FfLL<N0
z&csJ`?qnLHI$wV<AHlV*`Y`ukKpmKZ^Kt$ZbO76!-ArTW>rrsn8O6jCp79mDiTRYi
z0~RtuOTaJ-K1v-eoLFScr~H1LP2a&;=*Ax21!c73O=uK-$KmoL8bx8ALZdJ&B;7<h
z+{%3_HVN~K8gwg0utg)jU6Vyw;KQsxG_8-71yD3KGFuRkO%r%rpw%XbUTOljgtVFA
z)GRo{pzX*^5?m2E!a0$GAlgh;-C7EqI&z=#u<a4I@Xu1YXe-)E<t}b~l0_N@K{)N3
zNRPY*4ZydbFG7L4_}LH%^?gsI@l3`ie~_aD{FLl^@Kjb-1ZaMDJgR&p4S$8dN<-0<
zPZ54%%%mCX`MC5;bD41q6@DXaV9wF!E&Q{77amT+K<0u6Ls+G%OUJ75_Un?jsZpqI
z-?#YX)ztGR%(up=Jet13uT(g`x!&?Fe&3feqSV!$_{IX<uiCdgfNDhM?`p%Ne}1cK
z?&xfYLL=?de|GSLn+>ay{ve|m1TwAGzxEvorD7I*MFx|A8N}75Ad3L3CL2gO6$zF>
zWECJk0(m^Kcm}Dw%}yj2b`_|oAY6fo2<3%yI10~@V2t3K<ZqoC+c0=vmMt$n^;`TM
z{_fk<_&i(IzQGMWsetY3o>cyeWOHRicDkRqj??0CmFDEUY|6Vz%hieToI0^zm6i(0
z%Z{itV?Rz?<tO%v$j(bPKiI#x<>O1|7AB;ordT#_wxpz{CM-O6>EnM$qkgWc*Nz>A
z4-ajbGJb@%zAAMXuh5R4((-Q0Q0;g=BX!tVZ9Q5#WxRH13qCb=SZWoh{K@*S0I%bo
zhB=tXJp72wB=K)VFdliaV8{Thu}s)|ON4jb!ai843xtb%`p!CT+=RQ6nVb0R7oT0g
zXO~QU{PC$v-p#dFSKD**5-Tba^Pv3kcd&Tv-SI%zf5^sxuPmi4*+{XguC%o7aDTH-
zXYOAV5)>3d>eK6=Unclrii8z-Vh;v1i>8R$MJvH?&uY;ch%E{{gAj(>2pi{2FyW~g
zC2b|P796+=mf7S^aTY^lQ$S~pNJw?wgCik~kZyv&E;1Fk9qu|pfX!ar8Y%Q|%_d4U
zqEmaYJAl^c#82Y?biDFP2ZTY;z4pQjuOXe;C&2o!UyyMd{^dFNgHT`6vllO(MN<5S
zr&dv_4bx;*mM>bnYkE3fpo_LnRGJmlMn7id^;LWJthx@zM^|4rzrJG0lI3r_v78+7
z<-PD{wuNZ5AvQP$1>5NbPG1se@0t?3y<`olTv8Ap54!Lt-wRY?9A1Z5H&^U%Lm$q~
zii*mbyR=_iTtAp(f#JeD1L0T1Ec{9kCGo>Jz=&wh9rGSRh~d1jLlTW>-=Oyr(W<c)
zgTXS^d8`Z%42Y<#j0k{ZDg4RZTwL7b<mgHd6MR-^dTf+sAYBL*C}1wozjDwJ4u+9D
z7W^=^gPwUQKyxE_nLjLgR&+`9j_6&GT)!u}{!h@A^}xFeq*ikuc&mkTKm}laxqpOu
zUkspoFhDNg1rjg-p6J30=QY6#z=$5~aAL~;Hjeb*j6cC0<Zo7Koj3!(y=Zghk`rx|
zzMciXF&d-+tQrp&XS(p`8YJ=`>!MARJ4xBv-jDy$=o2u+=!g12Y9ny2|21Y&ZGXiq
zK5tEl%?6lO;rvy;r%_|R2hrZV2A4RTy3vJi`EhaifNwM_#+dd*G~)vJ2BDf5Kug|D
z4{mA2_&yDewrIdWJ^-Ia6g&d%Ii?|s;Gz`62|-SObPO@>fXnU{L;+SNU<pF-1eOLM
z3etJNR^%IWErI&|Ut%k@0k9S3`>y>UWG$nCHLMxrVb0m761=VvALg?GTjzjf1X-!b
zY*v^_NaUYxjO-#nFoS^Ak8lr;U8n?GPYL5k3rCP~LS*tjDsDoXY~}}O4hvdMq8)iK
z-AQBW>z~kSyuzO7!J95xgWnAF^3;y-k5tCD)fPXrdB@D`VK~s{7Z$uy5fT{K-rUUe
zzrOlWCtZP~*-25zamDLhbj2PV<fJQb?4>K^sVE|~9Q(UVPz3A!i4z$FBEx67&?o|+
zb&eII2wH+KN;N3b-xdGh%ArVCh{M6jP=vem*YqkBQI-DOU%(=e4<I6e;Q|p+xONi}
zH#&(B5!f}=2QEZkVTPz;WKJmR;s{2Ay~?yMI<f_P%O8hWE*F80To%3f7f2D`)c~~~
z3i1!|f_c9OcBU@4rUHP4$-^qlG-SfCJD)QN&~)<GB-MHCgzn$rO%$wMCJp~ByfxY<
z>g)dwaZfEk+&4xU|D#r;(LPKrQ7r!Y)s7Ab7KQveUVXI#`SE`a%bvMo^Fzh8ZRAn@
zNN|{+4Shjyge3B71K|(Q14(UuezuieSN|QdP;Fhv5<rke;*O1Q9iCc_Ry#?B6Kk>=
z7XfR|lV4iGAAyI%;o(DY9nQG?;lwb-nqs@Xc+Kyw{wP8t<>!!_v?SZb6-98ad=+3?
zxJEid>fQ&zcrU=aaLyIqh2(H|=`VnH;Z^CB>0crqH5L$$fhdLB#80z<poi(UjQ7$7
z$-JB*d}3(h)U^ZuNn~b3^Vy~Bbc!Viiv-N)UxIx1wNw^A%@^<m_orG`qH$ktIzI7!
zQ&IGwqRo%Ydiv>Ek8Ca)6kYV(N+d<nmCxa4EkXLYxFACuULGH$kB!wC;&u^ZR1~^t
z+MaQhUk{ydegCAD_{zHG^rUD{=_|Ddt8;U!57xdS^^8tRZ(eu1si>%lemTf$(Fa-M
zz-+(*rc-f*_Y;YDi1QLCT89`20R>4;&WBiJKx^PgS|^-<mJhbb5Vp9B-|ljjZ-pnE
zieEUwJy^@wt!Ci2p+l@HVlfBIH$nJd@=Mt8u4|y2#La^O%wUKi0@;8A{JYJm<n8_G
zVZNZdNp(Q<0}n&tJv}Zc93g{KBkdG^bkzx}&XKQJ>HHxpUd~PcC#a?2rSLi^jpTNE
zV1P3K8EG=nMnN)EST3l^g>oQ!_b(_!$xTa~i|BUli4m`>r4f%s_%!&8DT;UZv&CMB
zy@E2RP_4x!B!+YMX_SP-O5I$>xJPAk^b&Da$}*S29LmcQPA`%TGz{^yyEXc_C^?l%
zFB3xmDo+o!hnK>`on;uQw_XWR!qmD#I$kW5*D1V>i6PYs2d{B8M^{eqlY7?=9x<{s
zA*;sbvnIxx=QrM%m1H$)gR4_KJoK*FE3zyJbY#9|YE*(O#?5C~;<Q$6VPa0dXl;Nc
zGF9yD?M@wH{71d9X}0B3T<w#Y@3||LUbgly>(@qAd)T$kqjgIrA00n%fJW_RkKY^U
zDi+hyP?=OB4f5tRUM>>ftn@lg;vQfM&!hU4P9JP!65Nx+#O{$ZYohwac=*#%Io=Y+
zN=4<msp-HZu?GTY_uew^Fc*eVsI-2bzV2>KC`QV8G|ISgudoW&pr9DH$N@&9osq^F
zjQ%MJkwIEUsw`J}>+JGzvNXn2KqYRNU2itHPOh{iFbNsCHh)F3LEYk|H2S&(8|5Jt
z#RjD;f$??qs0t3vQ2Qju#aAa%ffl7XKB4&5@|=FnY4yVwaSFM&-or%_=&$#c$3{(=
z>g`<^85u0jokpE$J2rVq-C1cyP6mF-RY|2MM@JcuIXp;LnTd+%_=p6uRxyM9<geTx
z>{gH$$U)CUIEG}9WcCLu%HhD>P7}=&EeFna7tBg0Mdw5>i>^Y9v9Cn8M0XJlUJF1r
z0;*~&N(W&`B^nIgMJJ$H=wTRzf>4tnwz=nw*h!Ib3C1@)XT52?XT5j->FnP=_fL8M
z|CIJ`+tK@6?^$m<deeH(dV8Gv!wuF)uHnfCyM9qr*9m^&!4zcdzUA6=LhpYt<=;F*
zuj|gG>^|u(P%Q0E(RQD7-}>Lm)mu*YE0ACJySnT1e|V<1fq%>1bE~^A*{zXL>8`;E
zgA%%af9v{1O%Eh=-=NlX-Ef@hI_XLI7mxfsQ%~-D^$(WUbL)RA*Wb(e7gg?lr2Dt0
zR^18RzujF(Xp&6Sh_`V&*-r$TqyhbNG^}DWK!R2w_~V%Y_Jk{iSWHLAY!3tlrc|)B
z5F{Efo2k@YvJLV}7#m0;hCjknPT#g*YuNpC&z+w9<V1K@m^B5%WAqPvQ&-0B7YaG(
z?o#`z*!rGx%fX7!2tK|yB_<kFD#HbPf-Ui!O=&bKR6%^SRb@=DQwn=RlJ#7I-Jr5{
zcG%SVL>s<nOEfBN_&hw2WPQY-1T#`2oA3bpb<eM>pmPZdL!#}R4PIemQh{BHi_-^L
z@bWl=E;d#l6we-18KI08E0kh<-)>L12c;{5jc5tU!Ph4w*fCFDL8}uCYHN$t4k5ek
zdSwFsS!uK<1a)5hJMTsroMn8K2qimne`ScX2I(zUVEYKW20LXzt}LvD*gAl1G1$^J
zfG6<Dup(Uo{F@6z<%<OC(4M)Wo0H>cGuTT3BlZvcoWQ?0xtM?Ay#9$$_L9fmyS-`u
zL`J(7KL6|d8xem0PaGWZaAwX-+ttDfyqjg~{_SDi#0_24jWPfaS1@>s%at<xvKdw8
zrzV?$mm6DXm1^u=yqwBCuCZ04_N*LGmK<8WaL8)c;Fzk(P6mvR?<xrScAa$7IsC!{
z34eQn6LoQK1Hh~91ih1ct4bx@TmF(B?k&+P)=ll?-V$>AMe8(iQG|PQqk(&y^;}q3
z)<ba@;)Xny>*U|&geHGxP`8Jrrq%IG*0B7`uVfXvf#U};7ve3INOW>>H}B@+;tmdS
z^G|n?K=dl`a2`GgXE)$|)Y$<u<iO3b9+5MvqZ3Uk%Wu+(s)5OWVZN|`SJnrqQ4b;S
zCQlDOK+}Y8Gpbs2p1y={lZAEjZEo&PzAYtI;M=UQ-A3Ts@>>MHO|Fm`oP3*@bNBAc
zx#<lF_%-hr2jDTEl+iy0QRyjBQF@B-ZB-e)d>iPk?_Xh$ux_vdk^mK?B_Nm5$t8$A
z(!{^Wzu3gQ(Ydz*eT+V4-5j6tUxGViT@ybEr=m-slj_aem9r~T@3VvsGotDEJhz0s
zB19A*vHb*U>vRL>bowU9*opHqSl5t^Gj`$*O%2K%3B@fj`rIAiV>J4RAMr6xzxx?`
zN5)sme0|ALMm<T+;5eV(%5SAw@V)LQA=h4U(B02yuLqtKa#JnjdC-TV*F;`oD>GZr
z+k@nbXhM;NHb69Xa7aVW#a4WF9?F}C<~e-l(%<nzoR{=H;kR=meRG~e`I2x!;uz-Q
zSGWsoJG5F0I!Dr4J8;73Ah*whs68S<&q9-s0)jptOnZoNPrP8V?hWqV5GY?^Z3)2!
zfcyz7PEJgWi`Ah0C(#VaS3<*0=6->z@7Q=n+$z3iRh&YxeE0X??_RE;e(xMj6?LZg
zx)v}6d#4Ab&-(i7S?NJ<{Q7GIf00V#FVgXy?}=OR0=$49wwD<g9hQMt8pgt(A$x8;
z();`4PwMA(Hqpl@|BSHcWc*2E<F_Lx$Yc{nN}dW1P6-Z9)o2`Is)^su*c%%Od@0d_
z`$M^QwiYa`z!!ki&RVc$ChnM>E}22y?_5X<R&k^~WQ!npe9#do5?R24!U?=H0vWU0
zxb|&R&4ZU$TeSG@lZADdA747ke_=rGu;E3?<=ZBQrVNw<k)MsE%_>MMUd|803%8eL
zl~OaO?oz+kQS#dE-MXlu)OWJ5fjRZ#ievW_PTnQ+q0lw{(sAl1$6;M<?$FUiv-#<$
z_(}fbNx@N2X;CfS!5v_4!s-R$d4meb>@D}UgC5>!vY8;75_jNa=WdWB4Rk3VxCM8l
zf^Ru5r1=spR`K8AmXpU|%hYN9QyDB{0#V|-=y(Rc^jg0}x~>_|BYorsdp{O&`^C<2
zMk3qifku}^uox{G53>JhPzB=tpTOP@VqWmb&jHyc7sND;*vP>QWl}M619)Krg)&*=
zBiP(P7UwFkAqQ3id|kq5f_~=2u(LrdJY`D-mcxRAjb^Y%W^GWSnruZSAGM$ihWG3b
z7~m##?6c@X0_m51qLkqP6z_2REIWVPHp><+lj&v3uo&dB3oZ5Ey_kfYURGZ0$iTyE
z0u)OB8lGRVZO1aS1O4a40=4|ua(*#2qhBSGzeu?>;<gFn%g_=u*Vno#cGW!WDMz<m
zh2v#Mvj@GMZ-!*L)xt((p`Sx_r51c1KVN1lkS0k3eTU=^LDg{Z4TMWmLHScjU*6re
zZP)Jl0V`;CYw+Mfy2#zTR%EU?i0guU`+dFq)b5&suaS;=toWO#tfJR{8~bNPb;Ywt
ztHYnmh2tZXQqA9_5+Iqtga&_5A9Js<FTh9*7pwzej}mmfF321V;%TR2KAYWJ7X;1`
z$p^+H47{#jAUa|$0Jv)hxNxt1%=zV=I*-4{-=9B~=f{0qH<ghZ9=?vop>fwAHb|MN
zb^MZFU-;#hi|Dt`8XwD=9XD?5SYz>_+}cLqn>+UJ-+`1P+R8(dN7<j>g%G~K>v{XA
z<WLlR^7gMMe)$zIO&jsWiY;4Kd@(|(cN0FuZD+p#YU3kV3ii>U3;G^F2O$V3@Ec^0
zgPjmF8@Ii$I~n3$2K!$4{rBgAwBfVsH!zM34mG(JDA{^YzV>lz!+&*h!+PPy^S}Ro
z0X_Bm1&4aWdLifYA{Kezo#J0u2WYmY!~UH8q6@%%d2vADf<Z`VgLtFnt`iGbC#hs`
zOXyGt#R5Vy=yXE%1#LBW7bIIMAPZa*;|!A3446$eLa5<}Ksd+)mM)7YLT7{`#odJx
z>7$@Pup7wW5H_cB1Wq#8MnNQJWUGZ*V6!0_5j@=|l`!cbW+P9FfBAXZZzomZL1~)~
zP=(X_1uXwf?71-B?3gxR;v&zLut*vn>?UUNRbtoqtUS^_O*$_*@;8~TDJo_@$H_}T
zZx|dRWte_G63KkGu!AmMUWTYm?<-t=<Ep|VX)X@}e!7OHQtrdsIJb~g+MSaZPC&^y
zlD0OKl1fi-OjT+#sKji^gtp``shD<mRpw8`i(Si#<!A=Vjbq)mid97@7+FDlSW@Ec
zRSbKLSF3kYjCS$>eobK^_*rH(0Uj}mTAz8z62tto0`)f5_2J<gQJZQf<Kj20xgouz
zq)Z#*1rZT~lmm4$t-93r0uZ-_@hQch;Zt^&*~EDT4sKv>p33x&@zm6XfBdT~O6EVv
zJ&srYuJGjg4UymZMds>KG(<tYIxufIr}Ri3qWJS;vtNe4M~r72%niM`O8g4+!BjHm
z{~aeU-Yb3(_4sSV5jvS?mf+>wbg>-PacO{I5}=oA8Bjw#n3cow46s8N2M%?KFJwR|
z9oc-Wvgq_=oGN96kje<;$!mjw2u{b%c$hBcq7`3t3wU_XyzwzAWY0%(v1ha;5wG7I
ztcyYODgQ}&w~LP5<(GEt!Z$DYC!$>%+=f<0#9TmhzS#e{#Zyk1WfkZmzmHNUN5?lu
zX?(@LBTOE6`~}9N_5y5}ef_<e{4ufdTwoGf3p6JO&*h#IyTd#~ygU*q^WV50WF-c2
zW+kGn5~L*dQrvTajzc7Rvf~i!Z>b??bWI?(965Ou+zCK*_d7>UQh7$LV@p5)-KsSj
zwRCGhfMbgm|JZ*F^$YJYra!()o$rsL@zwrgcn|6qpd(D5x~N4##7^s<YQsrbEBN1r
z4m3lpIH=M;*Jgy{3C9z36#~bl_|DOjM{pb*V4imQ$BG&0CdYQic4`W~ilV#fh%$t#
zjS;FzEGeJFySPgB2f<gA5-iEUUlbTqL9k~T0$U`A0Zq6h2+`E@<tiOF8XPxJ8G5II
zHo&>_5AQm6j){ROd)kEy{LdFI;8S3GaLoB7evP`{<J{}wjC-X8Y6jMEKsf~qIl)sa
z@zyGQ!4A*>b%1+T3lq}-@7lk==WPvm5<a#cmF-6>8yeV%3wKU(CGb}Mx96Py^lDt^
zkUHyg=j1tnL-!aFLrWE)afSDi>0Ad&l5l7#v^n0EjKCO$s06s}3x=&jQ}3m%8@2#V
zWiR4oaB?pVFN0)e%(7w2mk(Qprrvo4elVOY0}m}^?98~&a*JUvoQGh~)d%Zf(10^q
zZn3B1iY7c<<GA8kC2py@aqkK05Nq(!+{=rNWzTASa&~tn0edWp0+_rFFzMS@8t5zY
z|J+-o*SdQQ`pv?&H#AVy`}gyQyWj&q{B6EvKecuL{{8>ZWBjk@m|yuC$341`I)nz^
zIf-sTn^>@A+|BJ5>LP}kxd|S`!D5F49-44sG8S-k|D97@@$Gw?sHf;Gz6gKK7qNfx
zMR2y8D{kV89Ov0ld=d53y-h2rr}!e$SHwoLyIfbo4+>U5gmS@Ne&Eh!!l_WMRG3oF
z@T~GReBj>A*913k`J`w^9hqTYyLXevQ&}Z!*do&@sWWVI<+jsLf}a6@7;#q6-ik~x
z>yZUHfLDtMW5;y~qhPvIfjb$&%o^fv0VedhVKN&47n<e|o1JmVrfkmljafdXtZWSV
z;%3KJ3x*9_5Y2i!&UPm<C+pvM!qm8GI{G#4cZpXbUp{3@IebS$+Nwqqjd<U#6#NSz
z58xLf4`BUl53ETvH~}|%#{#L7jDxQ38W-$3Cq${xNsgG0`9s_k{yIrvhIFC7Lnr<a
zfAv1qa&OUd09D|-H{JK(j*CNqml3f#834{gFy77`zw;H9jP=8)V%movTlfp7;h)E4
z5Lo9XR#6LKB?WM*!Sk5+!EcKXSQUaF08_V}x*d#ItRlNbg_J}w4K~KT+X_s5x{!Gv
zY_M<PBPjTz(;uUWdGUE@;>V{yLc!DVZ|Bb8-;mq6bI1+9Tc4R(Pret)vlX{KMg>0T
z`PD-QAvHYp-JqeXai$M``eX8JcRptZr(GFZfL|21v)@1))xvtvxkdsOL;!G~3U$qo
z@ghR>VQVPNT;6>vFCH;8C#RtyCugW*+Th&WhG99`L+PCmhouwWg{`^Czdq*4wAZbB
zaxebw;sx;A>U-f5QZc)QEDa5Lxr2x1<}?g<41?#FKol45H`J`5V)?gOwWR{TbNC|i
z#oqvV{01!R0ZoA}T?an%sjji5fZF>J8VoMU;UDQVh}EfGDP-1xZ6<8&)2ZcV8m9CY
zKO~|9I8Ya1SA98tFY%N5dK6QR@0Guc2GnoFTkw0g-`!YGEAcRX7}|x0QM=GCYB%37
z{V15rYQX4n_1(K$?;_0@bmJ&~dklt=BaEG{`VhMmr%fEJr(KZ&ssmQGf^TiwPV3ZA
z6%b@tXgh0Zd82ynyYzO)M=g{e{@#pA93Pn}znYf2eCy|C{u=$|0AMdHbKdxzq6)wX
z<y~q8-@rdzh!#)pyhs&H!!wafAxe5|I$F<H<FWJ!e#vA1V_l#YcAed1a7AVb1p+q<
ztg-}RBv;c2`sJGWbG{YYH@EtY7G$B4`D-nozcB}Y)8hDuI%3A((@Muj@3z!Xe$X*v
zr$07bfjE9?0e$kW9<48YjGB&D7E<8Kc>(`4wW1I_uP^#LjJ&&HgmkVjETI=%A!H#)
z0FhbF!s1WI8DIw|2bD?t@IyY0O8$^ahJ*C>Mig^95pTI&kKTOu-Et&0KU0tIC*DTW
z_y%e>00)4Cb^)-OkB-5sj~*p(`3g1)-kpxWLhFwnC4EAR+VE+RC9MLhRV7%b5N<-)
zPYpa7VfM&^379meOAaecW-=Xn<mPAZzWdotHf>VpfsQkW4xQ<kf)8E9hfvK6u$6q$
zmG5qZhTiz@3Zv=#iay||ee}|)=;%|Iz@YsgsyTrM;KRauCHM*MPxdoWqi7^pz&PJ4
zNPo%l7^YCzoTs+HSc7G;K}R-AKuiT9VJDR$KSDqjs}6Qp1OLx~8Xh$IFgnT7!})Qp
z3&8k=1Y04i5Cp{60=xaJ1`Y_en)_4jC3E+5Q&SZQdf8hEig@Zg0xt^qhZ<{PDc@LH
zXsy9NX#9QAd6%q&w`BT+3QFzn;V$!1n?2LcqCI8qXoGth+H*F|)6Cb}p4;ML$K#%}
z`33m7u%|sW3WXvuPDRD(gSF}cae`c@TdjIbrSNR^<SQ)}`o05MEYy>5set6wI$e^w
zK&=hd$5E=dM98c03=3*7a-3;s5dT}hEgD<-mVW+zK+AzI=!ZYyo)J?(LxJBh5qb_Z
z7%b$iz~X>p3if`1)hlcWATeji;z-FoGaf&TW8kxREIsm@ueW{kH9dxp!tq7<6_x!;
zzUJ>xdNdsG;6I_n7HR|v*#7FvJMicHBmB!~Qdx3>J*5mlB-(>-aYNX{T~R+^)+R3%
zjyi70DLjWif#;k?^XX^Me0+;3MHg{K=P{-ey?`?XnBTmAg;TPn0!<~HT3;&K=e)0-
z35&Lj7_nv3=+T=f#io%XH*FX_Vsq#FJ6c9;-aKN|7N%sx#*HIJZ`$Ngj@<Of$kFRI
zk7(JldBlj#8-;!fxnCgGv)RDsSm152XaxZctT|zgYX%7o5f>1=u>*!fpMkXpaRFvw
z`|OYs>m5FY$3`5VFl)oC3CBksFZ6Lh0-QJ#MjV3#Jom<~T{k}2x$_g`SUB?7$m1nS
zheKI%98MQ*crc-G*Nq#yc7E~+R1e@d{(b?s7V1ajjUuqU{agJ=@BY1pFx~d4Bexc}
zJy^*NXw8Gw+`!-bpX-U=LYE(`DvH62dTL9H`u1h|f7hGlJ}~}&>)BUE78Q*gQCvLY
z|DlU_7L6QPR6Jq?^fT}o+*`~Mn12B4LSYHo{SibOfE0vebP*pQe<qfD>rO*OMbn7F
z?OWPYXI9sYEiPZCv20#9c}kmSzqrKllXWqX=tau4<JBM6wvHPeA~QBL%#5+P{%5vw
z;q2L3Rvn<L8yb;W-9R>iFrqB{Gk2c70A9LNL6ccYU=2}s3Ht~yhGSQCV5q{G;DCxO
zf5D%f@C3L3?vi*2Lgjd2w>eak3~d|T6ZV`te`g_e<%Cbfq^z_d!<$>O1Nx=ToVswz
z{PF$0edLB*!~NZ-Qx|+Nt~hn^5ytf4tO*@WzWD*mrZYHs`l69z3?ZrS?hfFaJ@Ck<
zpWPNRv<d%wl3FU!Ra+CZvzARBJkS^<PcIBgmM$E6{FTo2Yj%g$XYi}3F>mf#Uwz`z
z=r%Uf#mHZMp=jRXHR8pSC{Gu>MLcuELrVxxIs@;6b<C%*jtKzk$0U%c4<{HTP-`n8
zP!Jr&8KD%``c82YGB_=ygxk;=&|`5B8$t<<R#`ye3gXgkxf4iW1?hn&l7r7Ws|DP}
z2p?FCaf_QX3a7dolh4`2{Ld2CRBJ3Xvb=gaj%Y^Kq<${Li?cOiG>ZTFlE*Pb2TTog
zT%BB))hv}4RZaHNu}}IHPL6wq%KGYF#OHbD(%rQ_0ea4Zp0jH1*mk!es(gG!FG2NG
zd2zm*R5q)z6@iS;t+=3UNJah#HOqf=44s0I5tLOrYs~D;huEyS&68ym>j;$@nxYgT
zEY94q1D%)1Lkbn<C{>1&CY0gT+%YkUtwd;+AQ%x0$H2!jD-K11NgMHWA>c4{9Fdeb
zC7M>UH%rZk9elPSP^s~U;Gg)-Tfk)gBsZ8ne|#O|3)_#{nux7jKxSHcK)5wA%_HEo
zYsiJp<#W8f+`Z(!?3{a9pUrDwSmf67&}*A!H2I6YR^ab|Wa@$>uJH+RXct4dk9dgG
zl@W#CKgV5T^|1c+ft67Z)ED+Zayp8JIY=%{4*(GhS@Z}(SeSUZYc5HP?pd$q-B^)M
zd|Oa&#0;5^7pZ?*{nN^C1JF-Q7=G&=5J2=VL;DD0iw8B%_)z#Gykr|b#;p<SVI3wH
zsX(>>{0c<Xf;Z~TMl*0H2sS&JbP@`tB$)k3$LMU_8pF2pj_qs)zVR--m|o`ihBi8+
zj`!#=n&q$H=dpo(;$HBApQ<V9)}`0!r2C>z<8S^^$I_i!w{3&Y97bK?;~+T8V!U?8
z*(}1;GNKCn2zLZxS(3GZ0VG?1%fOEa!h4m{1ks_CK)40LK2SU&_y@aP&=LWELY4?n
zEAGgFTqE$Q7xLG1CgYjL+yiU!(FNwkHTgILErLr(&B$K^51~c$V6@tpa$rH8F2#r^
zpeuO`?vBk{a3IBqR`Vkl<e@8gf-!}_gBF#*D)yw<1L`$S&`$KBw*YlUklBI(qZ3`g
zAd-BX(ptc$Zsm6{*mQv`6=p`^Lxv~$069`w^du8WA(C7{08B^}j7BAEQbi&`2y3@d
zCGErN=PwvkKc8*EpYiALnlDTP`j<!~nLb&?{)G#XM4#yH>cs>MZV1jO!Hd1L9{$?s
zuts)-Ph^~T|LsA^F241RnQ;vl>ouw6Vpn%m<L2fCRtqvPkqc0GBd@j3*)+Z(pibJZ
za0KArkB8(<TWWD-V}{M1S3hXMd`IA3{KDmG4}({*i=R}VIp00hOBXJ2Q-eWXOrfn2
zRHagxhu%)nqd$lk1lwDJ@|LFgrQ{@!r#-Y<LtIE$s4*%?qh%G+@GSJ?*S=?;`qf2(
zKp0Ai?D#dVgIxx4Kq7mCg+6qM&MF4Uw{u9s#$OU4ObG6#1eFi?m@t9<kL$QI&YB#L
zX2&+X^g-l=_>sEI06FayZ%;uQk0@OhzZiTAzh<=64SxZ-+Fts$PVVO>rzHvx6D8{W
zF)b_aO|5EK=y#Vc5jao9*SKZuF9QCNxwtQ!`<%-KDXSo?C$d$Ta%6&{wi~iKNR+AM
zI%fFX0X6gH)eLN>j!i8oZ5vzJf8sPgf0D^9E7NAo()vUW!C|Q76})RyxUpYG#?Xkw
z4Ejw=A&!jPN9D4<1Ln=Isaf!lV|($GiTx|bO>|5j=>NqRZJ$pMF6>Vog)MqR!W+$T
zVKrrC6aDnh<Mz$`X9Qm<QSp7mJ;go>?eKtB(6Ikn1`=XGHrVpWooePM@^|?4^l`d4
zIGb+fmDFZxxMOD&l^w)i3>6#s=zt6+ntJr!d!($Fz-}lBd`1Kitq^pYpb>(W3X_aC
zT*53v5EWK5G{g~LfYlSQnEYDejP_uP>?`Gxn!y3<_xR?QU)QgyY8W<PStGiDe30VH
zZ|axU4Q;3{_yAA2h|f2TsVXmnn4gFCoqGXgHBQ=cTlx-m;MccqM^xO9kt>#tYKTM-
z(`)MveBazMX4&#lL+Kz?adKbms-?5$E?H^aJ-F_~zI4PaK;k1DfvGoso%@M>2UhT&
zKvf8439GH{U*e(Ix%z@QEoB!_DU|^y#V?@p&bf|#sQfG{quzU*s^JfJmOf4m;vYXq
zj{BVbT!_zcr`hMgjw**>OZU+AB7#boF@<#kL1X7o4|ZyLV9<jG2+WJUgz3}{{p9>0
zg3hPaG5aT5&E9U+EvV$~4Nz72*|Uq$)#U6{wUVOZ;?ne40l{L_FhH-E7~B~><n%$C
zUc!hO$6o#>n)^ZFw$g-o)l^C62a6W6)5YrQ%(Bd+R9j)vd75TCGzCKrsqlyR!)MX+
z-!4s2RDveCbj5)GMAj9f$+vG48eD{Ta!-k+&~pKxnFTSYAn^l63CNdo-3lsJLDOd^
z^v=1{5|F})1B@=nWTO?(0fd@yPu<zXjT({FZ^5L__r|s^2+KR(Trnv+$Y-A<;61Mi
z)m4jdKL1-;K|$Rd<OUJCK0wlOt42?qY7Ov(T8werTvSoFl)pNEN}E<15E^ex5J%#r
zS-}d$(@!fD`n>*0vliN^bE}Xh3M8&j<Gy~E$t(|~^g$oUw6)vwvQqH8EPvqopL`_$
zgD2*V{}<=Xc;6RJ-^|CsH8X#>&jsn@4fj8D*}xuz^@#;=rxeB&A^PA=SxX$}z&Q{-
z6PYHg@zDr)5||pmK_A=&i6|nW<%y=Rd#wWAmMw9h`q6s|dQP~oxop^R!p+Zduz3VR
zLx$~~uni@wDAmL)T8q!_p0M_1X3%7M<SW}8wu?#dhi5FSOsao8J<h$fM(bC$J~k?;
zcHZXs6y;-2j1TqQ)zq?~?d>69YK1PX(i}GAM%%ipYfD3Ixs>W5{yLkKl!#uaTwa#g
zoZ%zqTgFSZiOq>2!HWfWG>O)8yTIRY4Djb5PKID_oS8L%5(=aaLL<qf2Nfp99pvL|
zsbK#PLjv|YljWG8x$43+r`-f;BDc$N<mK~k;v32F?k?jh2d+r8mWAvMSv|!st7Ut1
z-SU>g+O_7T16EQGzuXx;K6zSJN?NqPpDjK%Kfc6f$+VSFg=4>xeXmZ``<6E@tSyU<
z3~f(JsxwQqS@Q~qEE-^{X8q%WmY7^oc~V1rQgpaU&sXM#n=>t$G12*eYfYm4++yZS
z!8<PTlSUwD;)u^=QemNi&bdpi5;i~pbez}F;@%d*D3K7oYj4BATV?MBx42+V&2oOb
zd--G4G46_4wS!VK7pE`UwZ_e_ET?Q<WBS<il*aNo+S19dP@^`LG}k%q@g*@4nJN9P
zF&U|OY*A|Vkm#_aj2d*H%JMnmpCDy}#M&6`fVP<Ux>bo9hN-gW7`5QQ+>kP%!EPN_
z7E~<`VqI#!NvOitQB}Ix&_5+D)Lg-DN+}tfouJqDC*!Oeu5n<?L*OblI}HrM$w)6`
z1vZDYMPRc9945$}j98Ed2=<$#s|YNGCX)*RuCKkq&ssUa9Fk;STU*$&JaF{(mQ2l*
z)d1WwYvPK5mE&C8<CBr$&GRqwb4zTQ7F$VtezVOMotBa{4H%8A6|Tl5K^`7HzHGIr
zcF~Z+d08GBb6sLeduU{IS?z*h<$n4^_4l%`HrVo_VlymRm3(VVet1+;`%u7HNuRM9
z18o}$Rw<JqR^@8Zj{m1o3btA(4pyRMMFo)WZfUABXeDfNF$brEp0*3{ESUhb-Db4p
zS8%FM28R$Yf*?*hF#~h@*CMehq2K8LYRuDP9QE7jy!A~@`#L*aqkV_Z*qG3?XyA;a
zG)nVsQDv@VsIsc1)eobDaaDm<*+(((hZmH($E81BpH#VQUTsoT?D{f4ZB1lbR&eTS
zlR*_ig{lH0mg@pTaz_4Jy1~CgdDiim*;~TT?yvXO21lE+C)dt6K0_5C^~jF%NV*kV
znXlI^uNyqK>eQehA9+xkDLOg^)y|UpWHcw1Eq6RpyEr%mXpL4%9n2hQ4Ngz;^x(sD
z-Q_8XW?!FXfF&gwe*a7HW_B-dE&yAYp9PkhKm$-R3P2zXNWxf>k1#HsGclRioYD-E
z$ienuu~RcGP$`(|oWmS;4hl>Tc^KKmo83`pbi+P;a^UeF(q)0h1Kvu740f`{hqHl!
zun*Ag;qJz$e1c>tBT&+?m!jHC;gO1_sJajb9x^bg)T))aN+oU)YDqoChN9Leg@*Rr
zg{+NeWdd_OL=h1`;uzjrefU2NJ4+w((X;h#in72o3#)bY4vVmrW@hRWG%2kpuHjtR
zzyP0^6?LX!;~%)SHq}^}nPq9ErOarlB5FF`&dA#&jK>-T5zzJlmkZ;$JEjD&AFdU8
ziu4eyXowERxx0$cFmG`D4g{-fvy+p|aUkFkD0GlW&;`O#EsS{RTgV*L%@z@UQN=Ft
z%V{uVZr8R_c_ie=liQBTy}bi{{87L)y;uFvu#LW6gJ#uQ(G>rnfUWaap)m+!3U7c9
z^|{)!wkjpSk4iwBNGz?+pG;x4pn_RwGSeJnTNyO|Y%Ko-i7C=B_Ax_<-k>)i6V<PS
z_CGPz-Epcu*ULk5vP}`7313iMfH0KYUG|Z??z<+;9Mk9w(B-(1T2N)2eb`GT?Bx;n
z^bJ{)5)W2Zn9KfZyCF2w*?2+NBG@k?KoJu-`Rl8`L@Xd36080mkE5x(mEAStt13s2
zuFQxjEsddSrKQ0*t!|XKc-z>q+sGF;;<VsWDVi@H1qLGj$2cm~V!IuE>E+e=bKD~R
z*@!buYG)DK@UXM`MR9-xX8;9223>&faYgKZz^{}OWL<o`&A^c{L2QM{dKAzCe4)X}
zF@aRbY^Sw|tXyI9kzL?%1sNL<JT(j;=Q*b)d|=Vj+qRufb_p#?*)u&hn3Ct~3KA<d
zX4ib=X?5+77hIfEUr|v%=OSwF?`p-jE6f^ZNr5h3P6fwK_X;t}vqD{xPjB1yG&Md`
z?sc1?q&hQ0?{yI)&ezOVG<hRx*wknbnhW|>f&2^x<fr&Gh@(BCr&7a^H+70N`@;Bj
z*$eS6byAAC?IkB|2K_VAuyxE>7y&LI`%r_dMI>;$;B5%BRp6shn4U?ai8>2(=yjb^
z<_|Njp(u2yvj&}z)mvtSqhq)ts%>Tzu0Z=K3Zj*1=n7s$9m5w?zGx>t6_YsuJj3Kq
zoQTh$F}^C4!Iy#TuIYZQ7_l`VyG#W8$70bU*nI(bC3G?v-3ejsp<~JN7buk4c}j*K
z`F5`ufF5-*3xt>nyb|12fus)9OJplKe1zc%x*8a_<dh4xk_HJ7g~H)!Sc=4hM`*Fq
z3$~^L;7Ak)Qkd|#K;Xn^b@R^0_Ti4puf+JL$H+s?1@=<PtF^dbXj;FOnWoT5hCqKG
z{8FHISpSGj)w~ab)W-B?Q%H$-&YERo;`J$%(OPkN=5L`W42?3?m|tvM8XVfJ&?wyL
zrFE~czGsT;zr{yo9(xig)~sJ$JBJ^dls}<J;xa5Sv~g-mF|`jreql-VfHUWit-meM
z;OD8VR2pq@CW*J0b&ql{8lEs^c;X>XwPN7}lr}+MQW&91VBPY4f(OQy4q)&o*O=zI
zl9+9+YS=z$4QA+#6s(9^pBUP%TD+NKmGXU;2YTPAv>~73DE#BTJ^f3j9bUZgp;u{B
zUT|vFlvPe#!C$b)*>ezKw-~HdcZr^KjuU_v)ip4n(_kC9T@Y6gIN5D#0fRsRLPiku
zE=eOFOI#oV`(7vT;stII!mkV50CYMe$Vr3<C>8)kKnTKUz1rJKRCP|c5oRCgv(4%i
zO{O!*Bxn=`U^!nwjwC39N(ol9<fSV1c#xkTmAP(Fc*~>xPtRXuiE#ClnqwkB0#xiC
z9#BvM6S#YPo5o#3g~?rAB>q|bQvI6Mj$2Btry^1oK-b8FU46X0e87>%XW?PZ*|6&H
z@(Qr{QJzd%jvLG6c&aK?cQ*&A*hUoKoeM8!U45f1QwxR_R23B|f(O+a8nisWR_qz5
z)$7c8p6DyBDKLPZjlXFO3e8N<Y^{A1xiR-@kJ_`!T(<kObbd^5jEmGfBzzZs<Z;i3
zq<$)Osx>JxVmehWo#`H<U^B<x3_B3!Mg>d5<w5>_;{Oz4JST4a&<0oK3&V5J{bdN>
zbe9*)G4HEY_|EdvD{3GJxW_d&^x{Jgg>iVg(LOr?_8RyH_`??ehb&JdWbDrJOm^qo
z7Ubt=N6UalJbC|R#zky|2$n^#fAe9{dI9b<uxlz9QA#qFh^Q~s8RNofOG%CpLsig}
zY6#y3u3`ju(gG;Se5sbh*D8l44zPM;;0i1q8F<kMj3MC>11Zz&B)w*M4ft~+OrjFT
zD~S*Q&f5FtWL)%341=`d*w%Ti^G6yYl08a1g4{+%g(5UTKfXGA{DjPMvpp`-sPXii
zS2|S}m*gULpZ!_7c~~GWj0iQDtUl)0m^d_4%!E&P?KlM{i+Ryzd9$Cvttd*ba#vE~
z`sRVPg9}o`*jwipV2V@+2b#jzHuHSE!1QQ%P0s3lYb}<xV9V+qF=2j#Bw^~YHeXM7
z1==@PH}WV>L<3*41&60bMdF1n=<|nDytKX+92JybvJ*Wt&9PTCwxu>LBx&e0iPG!w
z)tVI&oid{&HACrPXowCPr>ajd4$tGfM-J5M7mV2I$!dyIvLY3>x_qMdFTDSmm}f#@
zcD4)q*@nUjWwZb%@DE5nu<$Sw^*ezU`39RkVS6p%X&~k!?5!ZavuNm8l16Ns1u(!g
zCa^kWU1Dd{Fox8y2ORQ}5ocn-n}->)zyLJBkC;dNuaPyL_9}Ydj?~ts_6Tc)(HvYH
zTVa^<@xlG-%y8?d7tnbdrMB@)^mxqURo<?(iMq6ujB+ZnwccHB{ggsm*V{u@&x<NR
z$+M%XwTqMay&i4`O?0u`j50AkIG}nc7w$LSx5%guilF}kt_;qkPnRVJM61s)PSFN<
z8RG*3hq_rx%l5TI$tWdCxt^AW%H;S^sPznX&_{hDlS0GrEq&Nhg(i1pMYYoInqMF*
z_wv-Z#e(@9C-#!ZMW)*;_E<gfS>KRY&QtKc1hy}t7A}xAz#ORp9w-?6$Ho#a2>cxd
z0mdR)ZURex(v4O)!g9_`Q!EK{C4_i_Jy$Fz2N!K%G3Jz!39{WdF0dK`T>TM~>)2kk
zAH~we32Gg3_rr4?ZzfUSdEnSB9^j*FkTEpSjKAgG=23qP=OwxKMXPe|&@Q~<OS&SP
zPYI8U%7~1y+jk~#D2$S#M5MG}Mz2l+87f6bq3^Hb%ouz^Q;8US<)qXU3zdBN8cwXI
z#{Lrd1OCH`z0eEcm<pi>=O<(qBxZmh588_YxDuuXyiNsz9>VFPjc|R$Qji1Tu32Um
zWO}eEC!Tm+1M~uE1$2c@4IvajL1W{<*2QL$nK_x-xhoQEDN2fPeH7yv=E!;H9eQuL
zhD|_wiyoKbvrKU+gVJ5`#=tPg{#CTa)A2EF^z?Onw3=Sv=Xi1dks}#3dBtVaiv}zH
z0L&AAM-#qur%m|lxX^^q8_bafD~>T=#{53GVE>m@rTACN<UJ`%Q3cp8oxO_2Zr!~H
z=C8gm)QEyW${y~7A!!q^s>npk$%+T;ABAa%Wq@w609%ON0|yp(KE#3NO<K*Gffa<A
z4mby3>;nDpuR3*t;}m{#e-+)78}lX_Rkgqzm?+14k<w#JEdJJiI4_+?RU~CQj(kZU
z@Zi-+%;q~etB|Ol-5wK}5orl$eo#l^$RxEMGx11)5-Ha(BtB)1HMyR|R}fSA?u>ez
zc#V2KBLq|7-kHfUIP>~dhZX;EGx9=SPDWy3mcXlneKo+X5%@U+Pyvui5U=wvT!Fk2
zO%|L8h^He26q*XVTLEDKoI-2JwH8^4xR8KYPyARADhx`cu1OrSag9yi<LlGXBm6`2
z@+bJ?ce1<<p)=OTHz1v{IXgPoY^@rN3f{+mUNQ{HG8+vcIfM0=@a>jdOK4a^<^1?x
z$|J^C#nm86F(#*<Ei@!HZ3gvX>&jE1zPVGD(VVvK<oO!y;>^_4%#MZl&y6k*$3^Ak
zL|GQNJn}?VYHHS6|Gd?+`h{ooCl_RW+a$Wi?O;y8+(hKhV&|^Lt`<Wp!ckAFL1YUW
z6KBJnjVEN0b50@7cE;H)CL6co=B24~2N#3{`gmxwk`1;%bKUVVKINv|3BjLDtks8C
zXQc*sDZwy2pkU(I>8<_8x$phnI4HTF-e_$w$Dj}!^<o76`cP^3m;tcepjxS+B_Tye
zE~hBG6q~};CD~q~#`^uMvIqNma?-KYDfY0)2_7_59{Ay}*e_wNu7eArrf@<5ViP;5
z1)2H?;Dp7xh5hn8#LE7lpKFl+z!DFcwmo`ChM&7c5*p+Qxbxw@n6`$Y?1InvH?Vz{
z%HZxI$wc&Oqb^IORyP!;QRiPvHUz*sd*uWFy>#HeTlW7K3wqK=uxR;_T?%>~kqP<;
zRwaVxOZLYZ{8Rj?8B`g6Yz9?K70uvJ%$Pxy!m;a$DxJkYP1ZbrDMRAQ{)l(NX9wPi
zTJToXh=#+r5pPFL@FgitXc%e`t{?^P7T`36`I9XaJi>!G5B5%h`UiMDf<(mmu$dM_
zp~6^$1I(yMV1)$vm0D1L0_Bi9FUhDQh{*h@@{Y$Zr|*`?ky<9DqvVRD3wTseq0CP!
zmMCLm`y(%(&1#JY$GNK9lo0dUUGBXtzUf(sZ?xLOh2<E9j1{>lW!boOE<U7m@j@Q1
zoJ8TRt3#pua-Yyx4>zS&&dRE)7Nddyv?oI>(YuMgrL?QegkR5?blt2_$|Nf9u08@>
zOa)woozp~Z27EZIX^CwU4X4CAI=HU^rkVy`&8|*|9w4hNV&uf8V)N{ik|dczqtp7;
zczwP6h{i0I#`?$k>W&;}56qGkMg~~JKNq{ckGOs=zVXa2{ME<bvL%NF`^Xe|46>a5
zDLg>xrO&hVfA1n<)Az>KnX{E9uzzsB{Y$Bb2eDHl@>daiOTYu7Cl`@5YxjrlK7n78
zU`5uY-@1j(<O4bu_@v`dyi2$khL+>d4szOouA`5z34MgFp%36u0{Uw>9G(kD*Gh3H
zx_${=$3!_Ry#J;X5Bt8Gy$RV&I1;@Bg?!Le*mWTjp;aRGJ0TCKdm$HCV0G0D_AId9
z@uzO_r>VkQ{~v2#0@u{>Jf3}dFM)6;gm6QE5CViNK)CNC+=qw=hzH1};(>TkOTAB2
z)Oyvc9@L_3tyPQGvuf2^wQBuZYpqplZL77dwblY}{m;Gx1o3<PKA*o4NM7FCotd4T
zotd4Tp)%PWSEzLI{x9<9{`Ko*O!Uv+>h*jN#t1NFZee#E$su$K-Nd#y7v07#=r%eG
zA<|Mv%ew)W>*3~q-UD|J1pLqOho?w1^C^_WFY4OCFFJwh@baF1=~#Hif{XVCxZ&gn
ziHXq2q#BtJ-as=_vV};;;=6bE)bB^Cr<>-#xfy@=3BH2VpHSynO*0ku))S;&v95X8
zLF9w49%NP2HT^i!ZX7)SaU8Y1s71TsAMjKNG<87pkfR3wh;Kr=JP6vkf$z6Ma!JQl
zWJg_M{i#c677D@V@Gfv<kiWNB4Rt;iLM|?BK^lA>kVCw(=T`(e*uPAI5Bl9pN+D*5
zIs;0Mep&R8=nIX2X&bC1iIHSthEf<-Qkc7NFU|MhTwY*m>P%>Xso)3fBS4!?D4}WB
zMpGeWf;Jjs-ya30d?S&F5>lpu`{;@>9$`WW%=jbB1e6ILCP0_(!;?_tUItHy&<11d
ze_vo`M8OkAW`ZBlWn)|p51aBwn85dVxG}m)T4YR3DR}Na_BBSE;Cqma;LE9aewQhO
z`Ahb{tsshqL~6V0X9`3DOZX72E$2(z^|8Q0_{^6;*uISXR|=UjTzu_1F1>gWZM%LA
zwO-2YXu`N@7BzipWA+ZbV+W)y$JtLCDFKWFZfb%eC<`DR;V5t@*5hWp61iPLPIvFJ
z<F8(Y3=3}fJA9K$zJgP3BE{9Kgr~?_cURyH@FjNB9V|IW?Z{Q$?AAvlp-QrIpw~`-
z?!?{%d84O1*+K%@3wwk_ehQqmnuO@|(I1R9@^^Pq`6j3Mc-a>KZTD0Z2c(5YR;0vb
zOrE^fILg7+%QrQlC?c9dP9su7VLydBmEz}Z>mF|0@aEW3ZE8q(m?k}72=Y-YO+uU<
zl)kBnMfNI{)wq*I+5TxE5!Fc%dk@#f$!(Q-IRJRL0v>}29vrAjPqN!V^d`=$Vc6u;
z!qHoZ3N@%!fPz8nM<Un>3Ds+6a7m98EF~^rP5{1~l4c`tojh=OA)Mz=R9Kf<m?oA^
z$SIsM+TTo6Y2u&k;^CDsCU4@z0V8vK{hSAhO)6-k$P`=U<g5XcMkpAuk%UkALBg#R
zozH;s0pqDtg$;GK9%7mrY7v&>U=x}?B4^V0!r_CJ3a3;bmjW|OZDnJA-q;GQx$!7b
zU}a#0YiMfLxXJkynNEz@F)&iePx7Pq&LNd!yT{QD@P`w4hWW#phc8fvF(k_53yd|K
z7RsT|jUXg9BV%YIaMPvNjZ6y*ODdw8#%`^vdFwu^96zSMZvDpU^7QcV<UvODW7k)Y
z&dm=G4UM8J>MO?AZKh7uW#)tfahVZQYp2z%+)^|4`zqnY@tf+Zw?u`7MGc!YVSM%a
zw9HYY;grGD^fBvS@Sh6cp3psRWZ@>9#qfKE0R}@4xmG|FX96-`p}z<N_JS`t9~T)p
zg~V{b{%&%K)PW&)f;&sUwF~P%;Ht{gIyzD5krAnKd{+?R9g*Yftu@aI3(2&K^j2qT
z{Q?>MP@W$V?(RwjI0m}Q^THgQ_}QW1neGs*rwoh8SZ0;3iOe;P$Vm&12%wRZA}d0h
zNkKA|eCkwahGld?T9_tKfPZyQ4-Zu-7)RHzoXij>1qiN)usnApq1D=mbbp^HOO<Dk
zHrq@)AU#|e1MMhNBgWhMOEj4|QDP597ZH-J#CPc+ZMd!=%mO^)+}yn<@CVwFb(hRR
z{fmq{_afTr3k4hIroXH?clgk|I=<Lg7_%p*apnk>`-6|p#)Gyh%G&w)FFw>Mk<eQe
zRP@z97B;lQKOg2~4RA0qH8GCc`}x;C@{S#!#eh(Q_3yd9UonZgB{64wcS`B0Af6zJ
zMhxflx$Z$h(Z68+aW4)SIKk_WyUw3ZR)l_j9F8QOJgQS9K>1@~!O4{6)dLe1Qm=^0
zWg!=Sa9L3v?q%WYCRIj^Ts4Q<AA0@_q|E1^K9Z)2`Rq92K`74D2x||qXXGk4bCABc
zBHYv5JJ3iOHDYn_>D?KN%A=Kz#J7!)!&#ZV;872P{e&V|`$q%J1TgNDGuTN4EbbgL
zcv}D$12zO7I8s0`qQp=%ngkYcuilUKJP2NHE;k^E7O-H!0Ra!fd+wTW{pW#R#x4Rg
z`*goWXM?;&E@nnn;hMMDXZV}(3xfQN-Hg>i^C#k4NIrh9#?Qn9)h(NXB%`W*N678X
zA#t6FnKU74#|I(t5)(@&Ya>Z)*a!Q<ot$E0ot)U+f5y4Yn?8Mki>odL6{b2k4ajqL
zKzD>OL6=?&tZ)_^xe20!zT7EKgz9_9$=oww<|O<ba+y3kP$hCR@${Q95jo?>&v`*A
z<F4P3z|6}vE#R%a0a=drB6llmd!6#|Dc5v68#A=QE&@0|DjJnU|1f>7v&(|%ZzLzM
z8Yf-4lXGesnahMP?h2}bA4#sc?$byL2S_6aS>d@9CW305xfIkR_vyHd3ORos{l=b}
zF@rsYu3toZ(C!<2C{qjPejr^t<%61(=yz-x>qFVHKl$Jz>_api&!Vgi{V1Rx6FAS(
zXa7sseY%D(P~bd#5r2tu&<7|O1)%ryvFZA?;9^;@4Q)e9R#K<n>m2kRR5A}nAK<(J
z=secoYoMutQiN{z;M2n41N|6IS1}GqW(bS0ffxZn3w!$~Y>nktF^?+U_P%CD(U6(5
zOG;knSL5UCK{O9frBYC=Emgqox;XfarqYr(W<lFz&*iRQG}pETU||Qj4qz4=`rv3r
zgq8^fLJGk|;w#8%D*=l}FdFAC#ZFi`1Lsp(Pz-)&&(xTWn9&rSlz=8)i(j*dJ&Jxd
zz2BU9g+C9^>!Bv>4L!!@@jeCPJ-m^OvSEL5?fQrkFET~%``}N5o$K)S)$AiOj-b;6
zY)yu7bn1bMJ6C2ny~NiFC6MS}3D*QoIJ_P93<aBUCZ)Z01Fga-AMb@-rlKaa7Oh$S
zQP%`~37;+d4aF{4!f(J^*e_5v-a`eWGRmL56o#%~HGYI)OAE>foxOAzzjxsR8gN*z
z^%7X_35fng>W+qRat=Wxxi!o}l8^;*4QeHvBBJ2*J_%zZgg6;92sC5}j7s>gf$gR;
zC%m9uU~1}thu|~^V^hIYJj+3ao_%H^GO{>>9;<HRsjF5&0%xDmU}F|m4m+H3{cgtI
zM`fk_F#;LB#Qx#Hm@&3cJ@0`PWzN`BMhMDpn$j9{$=x0MYiOMVnv54X+{cA~{)yV&
zUyh$_-i%C_|MnZ9=dkC`nLCUI=7kiZsJlm*qo>dciYYK!sFWZLLChUoasbR6p98pr
zve>f+O~n;Umo9}dOuK_7F292p^P}+>>{FD24}xMEjGkgq;4Uf-kKVQGk7VqOHYDHr
z4!d;ou22hfGdJ|8Mo0l?10^m{?(fAk5o)pSApRX+!7K2S-8c}cCfWYbhW2j5g0@yH
zL-ShE`)K1j{s?@Oy(_wd{|u$9(J)Fzxnpx5^b8w8J_2i`#b?n&y-mXqn+EdrzyL_(
zP#;2#;FlaeFwEy~;~A#-Q#0JO8MWZCo6!t26l02--o|6lE&SvWjzz~GA=4l4A=78*
z91eMgpO8>&GFQM}+W_tMKHJPgj1n>A3^=Hs3iyHeY>kqEA`}~N!8o)7r`^6y`PAV8
zu%7C1!5Hf8+qZus1vz%{&vhL_^grm&u8@;mCodi9I@viMJrs4F>;ka4zOF!DBtBCC
z&PWM4m<I>S7*cpp!v`m%g1N#@L*K^X6q_O`E=ocd*(PcRc8^7$IF(tWgK^k{noF%W
z#pwy?8atJmhgAt^ziE*K?Mc82YAHJ&U5dlGb_6%Q{_O+fL{0};yE8=Z1}z2VJRE@I
z+!w&%h%<6H5df+W(sMf5%K;IA7#o3)lD&os#im9wJW?ez5^Hg>j5fDMW$aJxN=l43
zTEbVT)kgpv8-;dBgcdTqjZ(^~vsNLvSZrh_Lq+T@C~G9gn<W+^YqUklH#0U0L9G%a
za~W=>++7sxO*G!p9C|2J^MQqdr$-397;mse#T-{VfPY#J=Y1ji5it^&gOGaza#lGI
zZ!RO0D};f->2Nxguaqh6kQ`WEA@IWfPjL-wM%O&W{^-(Ew0gn>wEF1?d@~=Q{^(SG
zK3=q&ir5Wr*heVq6kdefsg##*N0+!}5TD$~J%<{=5)DW0`KL~?k0>$M452l^%v1o(
zpv0(QO@d?S1U|%6uumpUVxNHIs-;XPO`=S3?N_brPn2ydnt&#}L)o$S-@#<-l^d@o
z0ui$YqRq&7L7W{YjmWM%88MJXBnLPAH8yO*F^0W2$cn*@7he(TPR0$KIRcRg$^$8j
zX;Yy!eu|%ng(A8DYixz4E~p95axyi64T1vNl(B{^%ajBLFCX1-q%559R5Z^CtuYe}
z#r{%}sUygVIrbuB8+0X`78ywqg~U=LXbYXPVJw~SJXG&!YHWiO3P6Tg<A?YGEN6OL
zAUh1;LcAafa(0+dgrph+nsnh<7m(YR+;9p>^MMY!A%EoWg4)43(F(2=Fg07z4J91#
zP%F_<Qep_lEAbVs-C@rw1WHE1%^`+}9TNm?!>!OdazLbgffBz7<&xG{<L|0U@sm=#
z8kxcHHsC)|O(`-htwL_q;Opz4QpRFj3?4ucUW#h)AE>GnS=Uq|>r(wExGKWyi!tW#
zG5B@-2|kRFo4!IYuA%-gH;F+wgvb?IZYpafP(Y0w0EP(-6>PxkbB&^0un;ZM;HkHD
zS4=Ymr_-<DCM{Zqc}|oOM2V@{XHFCkkJF+VH+5$-Oi$~sq8Z`10sZ3w)#g>yM$tvx
z9XvG*tz<EI;vyX3h9@XIIt<Obqq`_dKA&<O&CtRVU5=nGDB0^2&k+g;EYjkp>nZ1f
zEn#m2{C(4zEx@BP$W!JAF`cR04uW34=L|GtO+0{lGlsKu{Xq!GY<i!dhy9=KJ7nEQ
z2SAyXK@AyTPk0nQFw?`Vi#~dzeOyF9GJDG>NvTjJ`ZiFuiE7RCR;0>w3Bt;e$!Rqs
zQ`4&O#szJIthI>&VH41e#2|Ho%EK$k2VZM#3{j^9TMgzvj&e112os&2nhuc*b1vsK
zElTl??)=#=WAceOONq;q<f_WF)S4QFiPq87H8L=>v8%{GEZR49(Q5@)=AgZ&8ZvyN
zokbAzV$dUj2E-<O9Y&IvZ4eVely5Gmvj+n%_{Wp`Qjd`#Fhzg8$Fc`4jf4epw-6Tv
z*nxVd0NH}*vGn!vqWUj-XY^#Irv>G7I#4!rl1r}KJzT3(xj5O#U5q?_9vGB7M)md>
zT2S|aQ(bCse2!yjjJ>Hm+)n507VYifpW!HTwl`DfFDweujq%wGH;!%d7>fnPaWMl1
z$3zc8ErH31GU0nzDqL?RfVnv^Jf*o->R>Fim*Ho+fZ{;0r@gz-MQGw{;$`P$sxH)|
zC)$lnw6`}=dR+^P_4ar2%!|L{=3y+fvng*)4Jr<lc-p%exfvUK7<<{eTloDewx~2V
zc2FtEtwGQ4GXt6RJuy|_QlpgC5Edu|!iYlz6d@~NDq{1%W;Dk>gg%h!Ko(4PK7eqP
zlzhouga?T|#94OCKtVx)Tpsgd!Tj~D^9S9DbywtN3NvE&whzqt>`+9UFf&i#9(!ld
z{MPmJ3nos8k;@D71v$}sKQ0>7zBf7tt#o!uw{k^_z>)aFtZBj8$vG&eT!U}9NfO=U
zll(mG?E}?Ljy?fn<Zg))H+)M|j&gD)YlEj{;XRdsE0@Ww(wtoC0~B`lK|%KR3NT6;
zUe5DxnIXVKi4ZF>2x2Zr5l$jF`g8gt!CEWng|k{er3i8^h{$Y$uaMshSu+y!00Gj#
zJrXeqlvXOpu@W%!AfSS5%nQl!D#Af<kr^UbkT$gX&@}Hazx1AVsCsDH0zq8pEEI}A
zpA{M>n3vJ}yNr3{JN!8ch3~LzBm6@jYgFU$#RG#=BCGlAH~#Q%F1|QkrQugcrVK{!
zcxuWPcHrCP(M`q0P0{7ZrDI{4#`ATppQWd#rJwe7PtA~p{~(v{@A2(_77pq4J=I#0
znp%>B-$9vdSgp#{-1F%qoePTc@$oVBG<Q|iI=kp5b<ah?IG|%8oZ>f7knCatng)*w
zkP2oOxk3mA1lIEq1afil*5qr#M1(3K*7{G}jY0v5%p>##qC$&gaub7UTu$DEa<#q4
zLOp!x_9-)3X>)TrWZ>$_ZNp>o{KeFS;E6kTG?b?J_<D#$Rc-a-_si_u?2N@$&Y5W`
zQ{QJFw^UWFSWz>wh3`LMP_c{H)LLM=WB8PJ-kT|K7TVdtY?`2}Z<{<XS7Tvs=CiYY
z;(I}^F+n0~-QfDotz!eClbr0N?lHdJ+wkv|Ez3q$FKZz(NpG(e106IVk4r!@&EY|s
zN`v%;Iz9q-SG~WZ8-Jm|AfZVB4o3l?4nbDGsV#&U4k^fSDd0>vh}#(^%)@O)xlr6C
zNDKj_A}rg@S3QaU$zza=EhHH9c_pDb+1?_o$+Z^}EGT|!vbn`_Wc79>?g|$hTe}oC
zk9|8=GreI>S<UMD1v}D~j2oYmpSgQk?W(Df;R8P|(QFG>ug(dp$tb|l0inZ&YSg)z
z=Cs7b%ppD(x#XvfR29ptOxz|VQ7P%Q8DrRn(OdKCi*hTyO4bHPwH{2LC^a{?EbxCk
zKCLP(nXi6r1u|W^yK*C%TI!k-FmF@c=)B+*fiNj!_Jnmi_70k`N|!OVeCvkI69<NB
z-i}e4+gn*D<%@$OP*X)*N=8EYm<oqBji$|^j*S_fooW}c)KOyTHrdwFYD`ht1gc?k
zUGDJMaQpl?3md743tnT}<Y;d0v^uKrXxiAaqFNGEDdOx{;wK<uHWYH;E#|G^?Sh&s
z-|-%EybQzz%7K@L{N@~qKu|4LAKEZzWWOCY)by)_GvZ?2Ar^<@S~7g_uA6yXkXC7^
zfd1k-_l^vrPymBy5Eo>uVWhYRINop}<*9pS013n51|Fa?Jj4Z98JK}Y>%)la<qQP0
zz=Pxyj5~K-FT%UI0?;trP545fIIo$Vr7e?0#+D3>3O6axlr7K>oN_*7=HQ4yCR2wF
zn#|;fj+mz{YB)DCz9BqUJVu-3uPxdo`eYVfF)}&5RFY_?w6u2#$+a`F2(r`JP;_;+
zW7r}3OqOq$&NJ$~;F#7^<yF-6LvF;Rgo>v9rn?Gay>kLapoB4*Sz|_LXN^XsjVDBV
za^sb$0i$dR!^flz$E&T=ZPbFXsSYM){&uMnr|8U-YCP(&R_W`TTb1e@e4IX)<?ElV
zh&(mJZhTOjZ)8E6(UIxHbmL*i;HWZRlid<n92y=KUKp~VEMTC?w1R`)L;MEM3>h|l
z(x8x8BSQ1crXbt+;j`M!+6trm;zMht1(C=&rE+wJJmjF!(X4>*e9x#;f<xihC3A#L
zx{Z&etxHT2uv4IIx>Tk?3HxVNBs7HQ%PIm>yb}s`UC68(m6cUD8vjxooG+~nNb`)#
z-D7dEv8uo=_!xcG-ga81Ys7h@W5LQmW!^|?Ws0?}x<XfGoo=g<*ttdK$V|+9@UIqo
zb7R$s!L`!-&^lf9^gjG*0vfp#_V`HtOMOj7Vr}$_?N)-mr!*lJ1tNZM2$><#doNf>
z0<ws+85wTZM#A?5$B_c(gFoy7=Mf76kJ#=zxNT9)-6hS@MS0XjyxY!>y^TMZ6-O=k
zeC4vsU#wd4<@$LkbJ&~q_V^=ykuEbPW9hDWk+TervkxFAZXkLe=UrHwHv4OogFm#z
zRW11mS#gwLCEm0WA6a?z?9x?NKF2H2fVnZZ2ZqHCY{B#F>>!CuSz050kJEMUGBaR)
zrbE58!MtIRC8iE?u5zmkOdMD;^a~11O`@lepgA%>q3j{3gWOxN{JATT?_JjYCHENL
zprz<%2V@u|_1?MF8$yUkvM}<AeCAt)@<}iUGh^F?!}S%lr#>{RO&GA+ynR`KWBG8m
zNUc#}*{$)B<1N>rkVgF0J<H*VlkSxH`)i{-OGi5RFDox!RTw+UA|_B%wshF=i0t@a
zHMQbi=2J>6W%JozZ5jry8-ar6&OOKe78tgcf2v;V=`6Og@(Y_37CCH-`AxiY@j#WG
zr`*mrr)ZP(W&{4EOs8xJN|Gh}uJB44j_)^2o3?3irmusOr%W|yA>KJ@^4r4`)v2rN
z>s8c9qlD}sOUC1v(Xp^Ee<=thB29=xdWh1=lHIlj#j_g))FOPIq&MdL8oA)th=&hC
zrOY3Ker532T?<)KtQZT(?8RlXg#+H)UnR&SE2UPZ)Cl2-l$9bDLav|$yHIHcVFp4b
zH|V5Mv;_Zh*}k35rrRB^;0M;xMyLGGolxFJ3Vh?X^29m+Q%2F&NP5MAyT$%8vXMj^
zoeVm6OnDpMK#JSSV`xr#!*%H&t+;(r^wftBr$#SAy4F9W*BjF7%d~Z^TSse48*~jf
zte><ZU31LT2M?ykG~@QxC)PLMa;bLo*48?085d8+V=9^DyaMp=mjWME@Txg4zcqI_
z#@!8$90LQv%FJmbA=Y4|TXFGNL^`TLgmPR(SSA1}obo-T`cQP3UeaJVu?&9+D_VeC
z5m?4bXvM(73;}hJX;5j!hxZJ*R%tG#jD<pkALEDMRdh8HItVSn9q~JU%BQX6PF?sf
zWYXniVouStzz9i^rI->4orG|knGjibLI{Z5=?PfDf5LJ1mItWgr{8|V>+e$@4;t_P
z_#?8skCrkP)|8!O8$R_G{+GZ^05K!5Gx-*Z+@^Ll7Ff*MxORqxKwvKBo0&<rAnjYo
z*;N45aI75hUPz6++aGSSTC{fKEDMT{sJZxYd{fih)5v@-{*x_577Or0aM?D^y^O3E
zU^sqj;F;oXo*~>K1UDu5%W+KzeA06bqXowsNwTBVN@O8DTqA`~dah9by_n+T2VC0K
zV@BM%6}QPqC)yHy>(+>|>UO6C#}z33`gOctar}T&yLv3#5WPjDGujjfH;hrYyBs*K
z#O*h3ARVPhs`jrvBS8s`T^&U&*RQt}b#yi2Ba$<<{?$p9X|rafSHc~m&x-N!>0SSn
zth{k!WywEX(^0JW>}YaF`m9-L;JYIJZL(J^fW7!oh#pM>tEdWU=glU*SvOBDvf&aX
zaM~<k4){-EaUnwqs0u#BP*567C0JC02zP+IMV_G=@aeci=wi3U4UA($N-T5d?%*L#
zo6v7H!Fer#kV}tBc#mT+8z~=}Mxn6Tv>$^pjL<e~>>&^siyfTJ>_V(5&!jjb7ix+n
zW965ZoRk}89G}{rw$su^X5?jIRjRgwd~HUK_%PqZ32Osvsa-maMn`_|(^OAI;lX^h
zn6@%^RT}wQmbjz^9O!Zu#3y-D)**JL&W?&FxYWiE9d}~*^b<VH*byD`H%(5?4iiBq
z$sbty8!27Qt!OJ>c66+<vjHgE5Gk^<W|!Ieqhn5{D9J&DHcJE8#ay?ksTvb!3v+v8
znsPNtgpQzGqIn2g<ZDGs^iX_|+@2h7JmGCL11I>|p)GtP8rZJa`0ydd*MsK;F}`6u
z9XGdOe3Xz1R<E!bA`l4qh)aZ1m&jBGCkHrd;iq>pBK<hPy1@|}<}qjZc3ZRHJt1D+
zBe+J5-fXc|sEdN4HJZ#=>%82G)a5LjtM)b)$RhLi?7$n<c(f0F#Rr$G;zpz-mk&!x
zEytS`S(#88&D&>bMoDI-8ddIY3-$AJLNZH~9{|y6m1?w(al(~Kw2_@&<mu<==%{it
zGZ6*`M4}101z9>(bxYVg9%`&nqIEu<{ywP1|3GSad2&j{2pwgoR%_aJ2mAXwv-g&S
zhpbF0&Pex(Mf0+M!ef2VoBFv5aV86Zr%TED38Wx|P>^gfoQ_LAg@T;de<D0h$e<=P
z)4wN6Edv!qUwnc>gJf}q`wS16ai<5E1yvatwZ{0j7%$(N%<M{EuPFSRXmnCWNLZz=
zFp|ixm>gYgb!JA52w6pY`BY_PRr{)<k(KeNl#Edo=><_Ffn!W|S`FHhF>+Lfxz}6x
zxV1VkCUaD6R#cF`1jW83cY$dfkdZzve)ER-(Ynlvnhbk~jVNC17ZjaUQ<D`P<R`{Q
zH#)l{R}IZbuZ!KVIewIZZ%8bG8ARE5@`B+!dnV`=BfE3Y!8sL!!Kts8rU)Sgc?l=*
z-T9pA4xB?gXL{<ub}(liK)OPrDj0}Lp5S*ASfY{GAV#2n!cE3-#XR6~=tjX*IvYiG
zNVj+j9eoucC&E2!!|`>bj5k+Au+uDKozg`jX{<65|8Du5r!|ply;P0@1-~)WE5P-X
z1ks_!PI%+k{M?D-@^dDRi1w6+o5wgMTfja|o5~?F%#$ia?!|}P!xh2K#-WHuxA-~=
zm7A?`q>*zNwr~$KOLU4f3#EoI8PIFKuR~NAmWwyL8#{Y>1v?AFyT&WEfhf?j)!oPe
zZ5=RaLSA0|IM&M}G+b_)gw*&-JXKd9GPO@s_*-bM;TsT;t8_GSZ|&wafg{j)DB(4j
zQVO9VP>Wbme4)ffKR>mQcGAF!Ko6zfF%I;TF{BV>50xblyl60}gnSv<+~AlIqS)b`
zz;U8=0&bR|p~)_;fx+%#)lC&p&USEyyVy8WeJxkxpFo*qqYw#RSs<uS*GQvLtps0+
zv2;%hRw+d4YwC27k*r9QB#Ke}5}M?n6pyz{P+g2|ppH5<N)+b*i(gcbhtk<190iJT
zb*O7@lDh_N6XR=jacUEj_|R+WVAD~-DW<7DXH=FR8cn>XC<foKM(aWy3o<o!k$8nQ
zD#*_Ck5m7lPBl#->*g@tWEwM4vd_RJ^EbrC(zp$m;F319o%@Bh!$&0V`;lA&8teDc
zF9D4$xRZcz77y}TaM{{PmJ>d)1%&#Hw>-fm_5t38cmDAE)BC6p4f^GuF5HNJ!w*h;
z261^(*mIc!I{U5*$4*{E;8?rx>G2B?i6=($jvT|k;s>zlIh*tcPP3n2t>=^702Kr>
z!ae|OYQR2)3^oOR>UfQrT@T<A_<EzjEa+SVX`DDzdVL2d7}_K;!a_m`6(ofw*`c`@
z$zMD3Z_sVG@K2qeU#E9p?JA=qI!PWiJsdsHC`e9el24k%RsMRbv+xG}K6&QqReJaJ
zj=lPa^v{rZP6lKE^rN(r%eW_g?i}-&ZhnTlI*&Z0H~iUENoRKMHT2PQzd|U7BNY1k
zpLNzhrdN>rpFE*AKIk|=XLRl};PTv&iG(;3Cmsnm;}&(9oJ@3Zei^I`D9lQ@yN{?~
zB4<ed^_l=TObvf$YIb-|-Pt|Ut3Nw7<(GYzam1V<LuSt&GGq?_&U<f2*B2M;T$u1$
zad48{HpDLk&GJ=vjGx^ZJ7f;rHfIjW)ltz4hD500_kVyx?_px39-OMdflm@@!mGF4
z_&-65Mtr>H2rv#xJJ48IQ&CYd#r3q}^<B>8I3h!%Nl({kGX58Y`15vG7Y=%VOi=WM
z!a+INm171Dn&Ld7YqKT;TFJ;T;7eVFbB=^3C14H1uCkopM-a<F0{60esjG|eJBum%
zZo=B*@%8Vjx}jnYcdn(YI^qo!r7<MjP3q~6qwigTJ<Pf8eP*69A2P=BjRgXG{4wND
z46cG5v5P3M0zyX)q6F#!#InLi>JWs~_#;gj<V+7lIu=YZ@{!fz-6$7n^!&34AE4f4
zo^a=Q4C4k7NMM*7*4XYfg$O<BT?fZFS6!xCN}Qv^s<C5N*(@76blI|@<%{Y2i3^uM
ze(moXBznAjVdA(A8#;1^E?F{k=#qtceVz9QH-~u|*bV=qxfwp_uT!S_>ttrb{$>%{
zLB7&|$5+1ij;~~+sT1AbQFc@Z(8FHOX?mlZCzl!aVl-}?*rqzlhb~@ITnNFvapH~R
zqk^Kf{1ln0;eCGE!hw0UBiB7g?tuYz0TH3$V!<x1&))6w<VwyD4F2LEvTkt8C*e}6
z1K+~O`n0I;h>m=YZ@y@8BG-$)T?a-D@RB`fZt3O@0YHPiNF?KSkjVTD_0aTuuwm5g
zv(FVdZXLRMND<2Z-bQ7zxN)9WR#N-WU=(ysC7S!j5;(&<b3Z?O*6u6CQ%6^=y@g^l
zDVfui+rIowqsy71JV3@5>}yKjw<qbF=Yy1B8bHBVpqYSnSK8>`8`eDiDIP|Rci)!i
zJIssUS004F_?K$I%og|Dl$rbX&-!wJ)ApgO%8F?1_xPkHIdi(I^~*;ZDm7=CqJ8Gf
z53iI=8B<02#o1H`x=zLj@@)T~X*uqdq~zMoWz^6v-~;Xcf5d0>e?W)GX8b0zTc8H*
zjhu2L<`&c?F(~}q+9+WYz5f%=qjMYX+$@44V;U%B$G0K{M!+&=b}Nd`yF`YLp0sXp
zdCiPr@ii`TZE|!-+~mO-nGD_{u|BqP&z#9`pfOvD3O{wBC3Q?<h=SGOs(027smvR+
zVEEF~xG;rRWVFI%NKPjTazJ%+Zq559GWM$Um#*b}@vS$bw2vSt$*^AYuQRRSwd1&t
zfXuyMg6m&ID<o{)d!qBN2fDi1CXDveIyr@^$HZB?yJ%+>oqkxbVolrBDQ#_2rnb>d
zB{{)%R!;uDp;c8Oz5$NrGQa$Bdt$xaqdJdH*|`&LX*2XslUPvVGwhZx{rZ*}R;b=E
z(EcjFNw*^0GQ-El$lRU7BjYEPq{LX;M<$n!ONcoR9lYB%Wy(&vr7EL9Gi=R}Xmy~2
zrLA9K#njxQtmI+k30VbMUHl$MxVgZ~7dkQ_dbt6S<FwFIL5R?;S94I<2pzX9nt}HW
z8;U=eF(bG5$M&t$8hnGsPTt;rpWpoE&q4mv?%Zzl_aD=^`oJGmBi`ONwCZ=lmtg0R
zIqn7>8N#@Gq=q(xv#1G`$tx0R8MTvo#q^To&_TmqU-@Nm(VW>IU0=7PN|TUT-B_=7
zqUO<)3y-Ww&|O_Qx3b($E;~1O&BdDF?ME_;X;=lK@O8mg%tsKLGs56cBJ-Ks90Y9i
z4tvhL0to}1>P<^9q-@CC*Sih$BThI$zcoWLypU_0XVZ{dfqWLqxXb!w8hATY@YTka
zC8ZNr2s2l$Iyb6tUSxtx5fV4Q_JJsGa7k3C_1MX}@R;nZxCE8w$u;tS*5rr2<w+Y`
ziQH8#?n@^&;wyLVWtZ-(OGy;UnvTCdAQ$u9RWZ3=m@}sH$5#jABNoncKPoPsG-IIu
zKq17CFG2P*GE1{l%YsT$RqEvM1iSds;DD|}dnen?&MOMd+G68vC9<*e8l4#O&9}&R
zU*qzDd1H-l78g<031M-A%7%Nx+_mKigg?>mfFG``n+Nr42J9z;O~BEGvq-rS1C9Vj
zfEUN6Fg^56SwaVG&my27N!S+zEepPZJQC(`!UUcY{^T<G$ni&CZ2xjc=25C)#8O#Z
zB7{ov1ASA6%n&%cTKLj4C$DiDwa_l*qUW>)j*hmk&td`!vc}a7SgA2_vrc#MiyLI)
z8ak-MUQqvWP0?7&H6ZlT_zAfc`<4uxkLFG(j~o|Z;tt6Jlpb@-X!B(M<x|EuMOxcg
zcn^Aub`DA`9F|E>6clHTNs0{~vexD1Y#;H!cwev32&shmXo9&sv4C3_0`VgLECC`~
zH4?%pY)H<ckO@d?8XNvBCp_lzmuL%G;q(js>dn=7uPXfMpAa><7X2Kq3dY8ek$-Im
z%e5ndc1jKHfIwsj?Vv5C78tek%gcC-(=V&v#9#g5gjS#}kcp-0&!^A?+W{q;tI*%U
zs&EVuZ7_fG@%z+GuJ$Sq$pH)~%w=Us-Ne_)Njs#x2jM-t(NFN&jVmyX!6Sosaq!GJ
z!!z)J*vgVG=TYatuW|j}J@A`UK!4<%(|Xheuk|<=o{7aRR0GoqIyv+MnOYH)l(~t2
z1#83|Y>pQGKK{P0jK255UGN|7`xW0rQcy4<*sCjp+zIz7o=@jLV=PE}4A&n28J@s?
zLM5XmZ2K(gEOnM8A#}a()3?We#(sh)P&&39ErC=&T5>DgHw?GXM!n&qjo48HKI%<~
zka_`Mulw}v(MI@Jb`*j*D(cN%@YUj_l$>F~)`4*bhch^ZDR~s0gBqhCx^lPt2d4E0
z`OOZ9B11e|h+4X+zt;?o`&*Haq>Fe?6tTObP-8RP$V|8?|AE{q#&h|P1OgthI`rqD
zxaEY4T8Bvi86CmN&FzjDf-ykO$oLRXyCp)4MC!0*%fi$mG=2*@i{_UjV|DnFCE;pg
zR6ZZiO;3G%)plEKmZhs@R_r$0tB+g4nZlp%O538dZEUim+oX4YE+oU(1A{Mo;8rzG
zddbP;<$N7IQ<!9oAg9swyDI<&*SR)g3xxO1*95%iK0q@cp|jl}QlSO_Qq#j3U+=yk
zc>6NpJ&*zmgPiHk5oH3_Sf70{FfpNQfV)5_1=qb5q<)n4&u_#|UlSGCc5_$kfXOc>
zEb0o$h~|G^YOV`qT?c{%(zh>?f3nve9LY5gN7IM^Bf<%mgPu*<?f@hr>ItcMLaF=}
zfP9b-$AuH|Lfx11qKj)sEL~kO%2|;Tmg!@x^GOJgYa1GYzX_slzYHaNtk5GicTIWv
zxTZw~*?C1PGD2e0!onRHdrQYCrQ7BCt4eTtZgL+w0Wy7H4_5St8DuU2m)j=c^55w{
zamzL=W-ssq;d_Ck%<7Zv=^gyn_jSXUyf(Pp)h#SAv1G#gZ<z*~hWT4WTkJd$7#ue?
zSrhN!S~s-i-CBr<@AK#xcErQflHK#O5@U6f!@Yds0t0i+Bfh;R2nsaqVx<l$i`;NX
zb?BYAC_O%N5Uk5D#^06a{t{;3WN=4PIme-p_Y^!*kmwE)74(OA=G&PNHoIACR)zkF
zv+}x%KSVkGAj>S~o3nztap@NPj10ysU|})(@+H0?J8Hf8f+LmIMy~@9su7(5);5TL
z0e-Nu)GvuZ|6U}06-BpwwQbmBt6_P^3cXEf=bW16c6aZf$YE*wP6P(TG^T(f%DuXD
z*8cnbU~b#?Rp>3t#;8zBk-dWbC(=D&tQJmc9u>>HOf#Z_5(0b^r>7@;P58SvElKvL
zS6~tX`C&oH;nbHNrXeYQ2!hIPY#{onKZV=(H#F8<O_oOogr$^ZRUMt#QdE2Cy{eJF
zv<y%>l*KOS2YKt()^QT_om!M+ACQn0Haslw?Y;QgcP;Oa9X%iaT$?enX-3~U>CqQr
z$ifWS68OZip^@_`E?WvWL0<vf4)#j4uWM+!i?xFWE&1Z@iA8dAk+GBa%RmiIvBaZi
z*t&w}_4}Pox$-Gh=RW7ry?9UoCyQR%pXZ{(dWZ$m5F&*11mnZD1DR1oG}w?$Aicp0
zTG1;&Y)=kv`fS3m#-$@`{)L}Ut$J&BUH!T7(*jCDG+BdcLsH_(t0%7B7ZLk1$n4VT
zIdP$t%O@m-7nL?2tQ>TBMNZPNk<^8T0$<mt;!J<v8rFYUc*yjcU2!QIlCYvTANcp@
z1B0^5p+FIsVd3HUms8mYBLH6HGVsc)@EBBce)q-P0ds3#=a1EdB)i1{Lk!KYI6Py;
zQx~6-g{#-Ri~)Y<o94D}Kb&7Yv>I<2=Id>dViTB@7hV>j*?IsysZFcsK;RA{KB5=0
zzyY#|^yA>(av6MGL>_PpME4Q_P{U5FyBo=Z+#hoMTvztV$zi&T5g#8Lme#c@+`>Jw
zDl)BVa;%^EU^=6|uD-4x<Tcl}{OjuG@4wu3`SNDmn!%W;`QL|0Y=vY|Nib(Js4y0z
zdz4cjn(NP8_mU!<hZoc{@biMc!&UaO(Q2$T{bB5%ukRan%I(`vj6e9cA8fTfnFb+?
zA;P=fq-HKaZ*~oT36{XVv+5;S3@aW;HYml~ZOcHCnSS%XA7t3M>-P@^Y!CH4v1pma
zijP`HPTV!{Hf8l+!Q8eeZAEE@u65Xn#FV^E?;I%IO~$@A&&s%Sum6UAP(J{86Dmu9
z$l_LNlKY;7C%!-c*x?luus;I!v+MVqT4%j-{iC{ox8{ddpI*Mo>aCA9RLp1?+)obU
zm#DpJXK7y2@gavNxR|fEa;a(>ax^I<ap~X%ViWg1d`#lL75{z&pcWAL(V+mgl?JLI
z{4Z3uUw4-6LeDR(!y7QDtbNzsm!YhJFaYazY9#wQ+KV&$(>drrK-P!OqzJN*<Rg%V
zYFz&pFr_mZ4t&}yUD5J8eiE<oE})KKqu>PeUm@PRcjS=R6UCo@U}S7cC2ao@OqQ4E
z$z_P@y+-%uXajeUs<x1FNG5gn1jAlP#Irt8niM3%t2Cbe%;7(A?0a92Dx0$u*_G(T
z@ukalSv1brdg!a`g9lMx4hdBMH_{*2SzFmM;}&w>w9D#!m#xb(_U$_3?d5<!j|bKB
zWqx=5_u~My(n(7B|ApqR*x@IH*+YEEe*=y>+qH<lXgk2c^pd$Ukh!rWYxsYqZZK4#
z=yrjDawfGQ+1k5xN*T$!40cV=a`L~xuAMh&d)xRq=XcMndvi_g%mY_{i3rR{35*&O
zR#_&~R-~nmi;FH95E}j8Fl*XSoTVH1_J@O*!Yzw)6C=|WZ_8r_qS#cW+}S-oF5b;0
z8<&QqtLz;zrVI|%ctIwXm-x#cD#`y_3XnXSpp|gahjR$)$>7R|Rfkv%|1)<%%JiRx
zCR!zywCuEa{q-$}8piKJo330a)%blgB%k_kSfZWy&fD*a-*?@zJY(;cowZds7=<Q8
z4n6H1+HXvi;C+qx_ZaEd`fe=-_PY%06P$*I<9H!tH6@ege;C6L!wbItdO&!1!L@4z
z5nXLKZu<0`6#9cH)XWz6_g_&O{p|Jj_NKr8ZfZa9M%SO*VwRlSH5?V^qbj_)5U=iI
z1CbMby;caa9qBGmNTG1-tE|NNKOHc}_|c=6f#?d^z`wKsEn`bI0Nr}qqWvrpVjCJP
zL#YM?3b9FEX^~!Jul!oPud()nBkL^JEWhBFiwF1b_Pv9{KK*dV!1R<0BR|N<U5r0`
z@1_2OU&0UOmog;Akl7n7Vgm&3QqDk!1<_p!3*xIp8+$G>Zv2qx^J`j<Y!Po<cWG?c
z(yf|_9oyGS-@f$8v_&t&#?Bv?nq*}vSyr}6r%nBQ#N5$tR@*G(Q%;ZgB6VP2-GWr~
z=|2i!uR+q9S6gZ4wp?fLQLbNog=e6qemxJ`N^NJSeG2{}_pRuQzT*K21N)4(C9Fsx
zAQ!o9T360M{7*Fa3=d2TrmR`};2Iw-vd>5uxArZYmFG{qHoqSfJ5UMz_<eSh$bxAf
z9TqtBLc)mJzVccDa<VTpob|_T1ZhH`z87rfcbin)DylE**MADJw?Er8Z>HtG)gzK5
zSwr#Hs~4A#zq^0Zv|IkcBfh1E47t}2xc7D*%~`Y4^<(kAckty0^VW?X+cq*f8Kt@?
zL6G(4UvXau;i#Ncj$WZ~vX{C}Q046XCogy9dFuVHq`tC|;N8zYhLj7v9468pp$~F}
zD|$tAO1){s$r#R;{|ZX{a{I)>v70wcTyXGu^W=}-e{JdC<@m?gkhJWOXxq4mLBnE`
zCaq#dIXJxxCOht25mWHNimaH_f)(!#W=cMJw>UFzD0Q?huW(Y5r>nb)Z7%Tl4hb)7
z$_b@>J;C$VN7v+P+V<ltz=F&s;uF$ym1~bt#2I_9K;Smc*gv`Pvz>EiSq?5<J3K|4
z3J%z{&EHW)!+#769e({~!0|3hG<w|Lwxc;~3kJzQmh5js`8EOS%N4Q70Aimt$pNC~
z`e|zV^_F;^$+YL>pE*);0+2I-i1lXGAI{%m2H&|`6ctr;_lKhBuGgB{>GXoxv+3z;
z*Q{CF55!tT%{y^oE@pApoD-kIktL9p1!<hPgwyKl(C}q&aC8Is6f1a>1(*>-h9rpT
zlath4NG`zaLEM5q=^RFH#>r?bb&B1CK7|vSpA!7YGu?T+czv>V^~%`QD_xi287iIm
znI8)y2+xGbnV&lvnK_Wqi;QV^d;0x;9;ud0?je8q8-9cQU*ulM2KF1h@~^Jr<bO9D
z$C*9!X^0<%bHtDa5cZk&bam`vP4`mkHXpCPj}Bn=%p=3S$VC`Q*OGh50b2+!7Djg6
z*w)!b7jA>FoMKeB0L@r{>h$>av`gX~;l=F1n>VwSd#NY8=+kWCBlawd4&3MNMFm2C
zIs{I+@E|T3(%OVT!UIO=&#q<nncZORsQWj}s0`}V{GSD=$iCPC6&n4l?;}AN%jif3
zG49ARXd|&m?^q^I6Efpqp^yn<vAifZXH;ra*Ww95y2!xE{OJ=4M&;$?!Jyo(sLd_N
zu2qJW<wgdM$xY244^f9?e2|GSnr_nL%H>oOM&qQ8yNnZHnu6BFp>_KEc)7wQbTsjm
z6PierK$IoyitLWRVq+PTY+x!8iqS!emsAu-__~5OO}L5{!~JFu2LdYy1XOV`#|SdN
z^C2o3@@C1Ppe}j8id~+{HtTd$eJcCC?oev#p)XP<q^3?drHf8YCAwhnGxxurx;?|e
zoyMeKny3T+Er50`1o&_K6FHvjKoK3c;`u}2V|p`0E|H4H3a(NglqLaa`HWH{28et5
z1i1yDLZ#M92wwxMq0gtsIQXd88&{>KqP5=QW9)g|hpDL_o=%;Xk}~a>%s<!P))s!r
zI&A&J$y@kErF;TKeR(!$92zHmj)xw=i;bWR+Up{`7&i&ge6-LAzfR4<f6>T%Ax$kr
z<_!L879Vn_Jfx7#5}Im8QVKt8Ht?ST4{n|T_z=9V5k6)c#NHkE7zb}LY>BiYUJ5@h
z`8hm5VyVsw!|CHNI|#=LgyH}AP{nMkz`ElHbOeTxCVM>ayBe=~#r-sRT6>=8+JX~a
zJOSF6p8t44AAP)uF<<EOPdMxsRRB*#Qm3es+#KH}Or>u^oD7UIapw_tnU#j~pUFdn
zscaxy{^_6?iCO-@n2)H}AiIKMM`^-<uzK{Xye&kjk1yf%ZG)>Msn22$b=<f%=I)Cw
z%r~=+E<Q?a;8R%9<{8{3M~}vb6~vY8;NZm9`HPrm-MkC|X#7R&EyzG5plZ6tAtikY
zk&S+!SBu~t-Nog+;PytqsQ|(Z)P2~x6x@4!vVPTYH=C|&e3i}OufNCC5yh00wlSKc
z)Pv)9R;&Rlj-z?8U>@TSvJiF&K^j75@G?f+U%@=~5Bwu5fG7`psKL!6?|@!!Li|xa
z9PwC1#p3;tS8#v-cEC*lFU^Z~4q{eL-NIn--DM@zudi%H56?xxN%~+nJb(|9lYnX=
z$Y`P9WY;J*1l9Ac7olu5zCEq$XS{=-Kb0!LjfbGD<J9-@d^41^25;Q*inc(>BhCv*
z)d_9M1Sj#HMO_bZGj)#trn>9W)UNkY5nncq(&2gUqp8T~5N^DUinid5z-)v!i{YF{
z51k<OA%yyc7!&nTE@dj&*4?;$H+n`Tv%h0g^n_Z&emX<GgW7wIJ&rzG%eI~C-v;2O
zm4`sK216TNPqEQ%q}z?&G_>)Ut-eO>-65X=dwzd@&bF=N+Sn+#N<RVmSn9b{33>ZC
zIN+~TaFxB#mEGLDfR2R3LbE#Wja^KK0j;l}Tnu>};y;1OGp`Xp!B58!oW{Z7QXPLO
z$YY4KK|*2@!}b{{5yVU+pSY+35Xs<EHfTzr0-eqFNvl?TcdMo4yPGRkjc>Er_u8))
z&Odq$AAk0DR{F4EYxrX(xvEzEwd~53Wq++wxlVE`C}6+3Ic3Vtp{dD>4Lr9BaCrCv
z2MHetLFmwpL+7al&CUEh91dp|kEI;|hf4=hJTh5yirtPTkH&xDCyj<V&E?aS!Uw&z
z3+bn&q%E+3G!U=K{Cx3SJoB@6?-@~7sU~&?>tlQR!!J<r^`{^oZl1dqJz&#QYB9Cw
z>Dw8J`!4`|a7F{^gq3s>$a@*khGa)la;M=SoDQ-J6XMAEWFJ@}C+|TXyGz^+KMd>u
zAR?;aFI?n)gq2UHCMV;VXRH#L;wRMgXXw-9<mv2;YZX@$u2x)$y;^e(?Wwpl0)Kz4
z{3^V=Qsq-~X_R8*#d7M@K>T$^)tF@1A)gM3Io9e%Ovu3JgGuVj?w>%20~|p<kT-@O
zK!ejUG6fV94J!(%p9-^^54*McaVCyb*!m@Zgw_g3ltEMM134w7<QA)121KFYz|iNs
zK*SSxc}EIx1a4!0M#Yp09YKXS0T^<II8X}oHM$mcEiN>|GP>=w6FTNV`b0Yf$N1Ml
znvklkWY3nPR|rQcC}t*C%Aq#8Tq`*C_b4YN-h;ALF163tTsHF=wSU6wC#>!n)jslV
zzsP+5{E+Ne<(3Mk2lMwmdD0snF|<s4Py#7Ac}EiOkUvDT1ox8y(sV=hUO1^ijS@t9
zdkHu^LIZ<Q)PR;%?04+1mUurU6Qc$>V9fZOZi}{z2#o_oj9~9Z8i<GEcn2t!TDW(H
z95P825;^<)y5J9H4~hHX3Q~l^X<Oo`BZm^W8VC9_eJ*gCODnY${Ly@R-)HCd9y>TW
z>!T?4(WVnw$zdgwI5$x>>M-AQhtgkpUb<;rrWPGq<4`qa$qJk_eR=g@?cj~7ZCCTT
zrHYg7SlB`@;&z#7B-Rp#4ZOHLUk^Ue5MGhUlP`w)+>h{mSyRWo!Er$WA~w@3JO2&b
zrK0wVUr(rrZhX4L=y%AF2*>T6=f?RBD=An!Zj#?f6!FREaIwh}WP^_Yuk^tYQC3no
z=u7&8r4Nzu1DT+NWR&EbFGpy>AM<vY@(<T~C+4z`O2U$}PHdvYQ6FVZIdE*>7oY7r
z4Z33oUXy=yt7=10SaEgBbey<i$&@OGHRzBwbKPd?7l!rgzMzrb0+~j5B>6gLzmVPt
zYr<ha(kXld8pFZA-ckFoxHZn*;BRajloLNN0uos`XlNXT1Mdb@M#bJ%-9#tQO&Xue
z4oe;sU*j8|kg=9J=(=>Kb7=N}`1tTZyDC#!F*+nPyz*Lbt%|O32#ijR%bmI*Ifs~A
z9PJ+qE`a_;>}EoA?o@WD7B=_^jGUDP4ChWJ58(iAB#4KRJE$eN(DK@1hr}XxhvdNe
z#>(+!fddDXrzun(IoS%8f6Tb*(fe&zoK?;#PPAV<jXIU^TJwD6()2Wcg^Koc9g**>
z$?%*q%Cfp4AhvM1c_E!XIdg?_!IIZFxWFWirVF_pKmDO2PGt@Wh79Kr>IM;~a&i`*
z0uz@zpTt$%BneaXr7DTxOUMaVgweU}MgA%uje5w0QHe?Mk%2>S^axA4srDho>Uwk}
zPhuOCo8sVJIWf@OLuxxOB>ZY7bt))hSH9HFLo!sRkr(8q$zr6oij(dRvH{Jhwvk4n
zs9^&vB($-Iy?1~`zV>{YftKrqOX){?n4xX}x41x}0d5ZjfF|VRpeC1If|_iZaF+;`
z0qCW%cy~r{P_mJoC_BZ&A~HK5!M`4>*IDb#&2`r6(3Lv>6rX}%Q{Sj!k)2U;P;dsy
zjipZc#Nl0;DH><j3NJ~Fk5%oWLOb!BUa@z5ogI9Ch*dAQw9Q&mW)U7E@fzvs1o5?a
zR~+F3VxyfC2GU1hMX=(0N1%g?6&`$zSO}Jyr&2>Iz5*A3S{I0SAARi#vcz}JG__`R
z{7lQX6i!(3?6>9hW9D`KOr81yUq%V-Cm{pzPs@k5ZoQ8;e)8LAGs>Y4Sc8p^z#6QE
zb7qM!$gfz1U%e*FfGEAzWr$AeUZRbU^jV@`u~_$Au)7w%a^-$$4ez~*5AC&_!+hBU
za&a9qo#b4CS{R%`X9avFwKC+Lg18)JT~cRrG()LW{E22(J|<nWY5ydZ%H70<{wpb|
zvxxtXg}1p`CkDFH#Q!V&6l(2~ti@cE1=lJF22S828#o)%|BCQa-)CR>8uM3~OQq)g
zRmPLL_IB-MkZ;!`$cenbQX+x$i^h}iaeUm}-QC=rIVh8Lq?pT@q>e*R$OWn%4xu-j
z%MpwDfD@brXHGK(M9VVt1zTPmQh>~9MaMIxk}6iIs8WRr{?RuTicWCC@_7&t%QVxA
z!FE$}cAG(+g24j6lAboiCnG1(E@YcZZ(Q_LG_-+mLuTUPxw8)+nKkE#os!-2to_K5
z_GeVKQpvV|y=BLaEnibQ<)|g)!<RIVsA#5A<{mygcg~R`Y?-Qc=U;#AY*nciuef@3
z#bWfNe94mXie}ChdjS`T5hi*J@$`{-2ap&%#fDFyG4+C3NPL9=BnMYB0K)D8#C3W=
z*miiI4FIwS3A6<2d;$~!j!NkTi;BPoK+Yk+0!S4A8V?~SyoI{U{KCc2kh5HR+0QxX
z41yn6p9ow+BnZmC8~fgb>Z1Joq7^>nn%?j63Hho8d*0f)Wa+!>9*%Lf7TJ-{8_4H1
z+-EYMU-SoykACNkTWdgw6UnIWUGFLH-DmZL_hL0MrfzO4NY8yg)$dubN^U1IrA_R{
zJY4hc(j_}L^uDr=Tme11{`qD4Hhl(o0s;qmpCN%!;8r=Z#)63B^0e_~acXrO`9Ysk
z>|+y0M-%ojrLs3cKck;b>{a}7{kL(*!i4E8wX>tQF(xXz&JXDvJLroCHQJq+hoHB@
zV%9wyU&V3U={ZBkAX}aO9jkRZD&<0K3n}}A=qH%JeYp%zR@n=>gaVcQKQy>hC|(=%
ze;WEX<Dv%j_!(yIf8sgeX$sp4Aq^n<34XJm{X0%$P6&km(Do`|iZ1)E;+J>~=4~5p
zqj}67B8vb+sMJiN^7O3TJ$-4O0&i8R@OGsVm8eu`h=NK{b?s3o_}L(yvK5N1JsiLA
ztnsH1Oa3|FLgot@DFY@#N6|kiB6DAn;2`{FHky-<zUJg3+{)X?`;d-gwA`8jFhKEA
zz19FvL;Nbo+VUVeQq}cqY!qW|YVS>DWbnQD=_<xtbsPWw<e{yflTs*zTF?}-{YxZN
zK%0GFA=;RpWnknSq2r$J@goCJ<Pwob)z4d)FX>L;J#PPlAyNl&*b@Q7Cl<P1q`Jd7
zyDt?TKPZ)qqawdE%9pY*ada@H%!{Frfu{~GJA;5Tqd)76ptsxEb(YWponHcxdbe**
z@a^3`nCuJ$#1S<P5@a%8Dm#8qKoV-@H(eR%TWYv3``FY0nEMZPI$U;EDt$V?Tm?Op
z084N0jDWUXo~H@ym_*JF1L4|xwsbEALSu?MPz%%`B3580VpS%VRwk^M$b`Bkva}RY
z*G($eO17F>_s{a`nwFND>g80D1-Z?Hx-PP?BDaZHFB2<j9b3&-QfsT1FRz9lZr)yj
zd3zT6hj|N_y~wm^ScrPhW%@SEQ7pqUn4=VBPUbCTPT|n**-WeK=$y_E?NlZVy$wiM
z%Ai2QOeQ=7{$Todng@9-37&*zq|^XeM9JQa{vDCj+&lXBt?zbpybDa+wBUqFbz(si
ztVCnk{f7?iXVGYd0<Sx}{UiQ7;N+<vZ9j`D6%f;*$A`a&dIbF3Gg80^T#LOi;V)9K
zK?()+Hq4P(-QXL+I!A3$D)G~9ph2!t_28#!2Hqk&YrR$tveM~i9$_@<^X^8DE7+kb
zm4dpU;BW1gVk=ebP*_GT5D;O^>z@x7HZwk8_i!tJ57iA*xO<V(r?li-LAZgHusPaB
z#?E7B%WUylg#vlwf5Go62WxQAO|`a*&S#sW*##AmGHNP2Po`2ao+_0!JBMnt)^^;Y
ze`Xg_Q#vKD?i+L&eR54gBu+l-7j7$gkiyWn0<X1|v9qCNo9JjeYicU>nzaL}f<gEf
z@>bxX?1E^vd6G)sc_dS$)pxB@b$sJY|H{s%CUwg6cpH5Scq?G{1WwU#^N8#F6^OqC
zgVDDD!+)YcZ)gZ9x}oV!3IdO74>1sLAi!{k`SaEK&mCpQQDBfMz!H;{ME_x?DU}^_
z2_N@*?q&HK#N1J`3sfq0KFs%cCG)weV=hRRX(|=)ra$O>mw}gL<lT!W4H_3wmVoAD
z&FYcn2Evd#gqIa;B7uWCtblj$yR!xQNdy=V>wm*nJQdD`?&4u&K+fY+EC%_%8{~f^
z{DAZ){6`UAs_=J!19t0Q0Y@JIxSoGku$%@+-B5JaL!S!h^9J;GTE#BV_r}g=wZPz$
z;o=n13-}TdPq?1H82TbH<bax??f{WsGEgsj>0H9~ip~bh1C4Wz9+^As6AOBgqLa6*
zqI~Jn@``1!YE9dEe9qis+oq~2mbH|Zw=5$#z#90x34FSyWbFD;QZP^1v7V5MsZc@#
zFMuRt2hRoRpCj|GhtdR5K@f1rdcdecr7G@?4&cMXZPaC0b8R7G2G=8}S6UekL=p1^
zg0cFjxD*T+une-By6xE9Imfq7Lk@}t4ugt{W%vq!N0(WAGHvdWqjMS$Saxn<w&+nN
z2=aN0@h18V^DD?5Vj+NEi-=23BFKy>Mvmw+*x208&Kw(~zsX<7Q9BF|<HvO!L!05)
z!~{D#{u2HYJG-v8sNY%3eAW_hsK-x)N@fRW#~lB`f(-><45mKROVDeFTBz`1F!`ZA
z48+ZPkP3eiu~6w2H3@I}h)T1twY881e}p%gZ*zldX!wh3XgFNkfUPfGg0$5SFI}Rt
zWfpeYgSeG$b90NBh>8yi(=24%HB_v>hFiI7-=OcY>o?zESM)vLPw_<fq0s<lGiX@E
zLqU{_zOd?NM(DqT)@VRKXl>raH832j!zcVlh*MsM*d#%vvJE--e}mUu{xZON#lJ6c
zVICN$YcxQKYr-e|clz4AiB>Dw3%y93LZJIE6b2mn5EyjW=huYm>3y&dWYeS3^hg_n
z;zTCqI3>0Ms{N*<mx0oBhJtC~0<&BWs?yr-`~ZF0GR#J33)T~8h=?>$!i4KdL!ILk
z3VIo7j$H$d!Q8y9RMN{qpxt5*_T(rS2R2hA*i2@G^SSoOY5*ryH9@325*3+5GBhV8
zjTw`K@f3VcCDeJT{wWb`|3{zOVJti!(epgPDiT={#TJ6r$@39-D)(>_nwK{PZ&9fP
z+f`owhz!poUI{$!2hYQ95%g}Dc3`DJPHD=|TV{=CqSviu-bT0?)f?e6p8os>euKZK
zm87e+s})vRc#Jn1+KAP+p<i8Jq^yP=rJ3Y$QbWiHnuF=Oh&;_N<`+w>JYjAE{{syC
zV(xj)p6UyQL1O?}s)veS+z+a+`dxV$PUxv0+!TSEKdQUmmm!xJ?1S#)+x$^|G0E@y
z@nyui7QKup#oGpSItBen^>!oR>8aEwdf?1rl3@qjv2X?Cs||I^Dr@!eQKOEp&a(1b
zGI;P3KYY?wEVUlx<%vI*PFl5(|JlA(lcW;&F}FH@yfwxhf%-{DgnEsO?W&F<<ML8}
z3QqcQ7P3A!59jIR!+RT<6$Gh529p<Eab4$m)<K6(W#!%d(Du-eg!J8&$6pgwAE@s9
zEI2~HUk_u5z5(3yD+a-gdvX1Nj3rW5Z~NOJQZd>FeIpThtdEGXF{dd==42BSvED-@
zu`O1mq^OE*@m{gh8+n7?$XT2F&O5nlbKV$~_lA?$ST<<zIy@I|$8**V9t0Mlp7+p$
z?tY0`MqZp@2Yo_cdPe|<EA$HeKIq?DFGx~e>J3dpC8&|~X50f2*KZ8|R6v6*8Ecp~
zFmBuu`{FMQB6sD*-)^}23Pu|NtrQq1g1*z-pi*UPG@#8iG^<pJiN*q@gWq6e_px1w
zl~`<L7xFQ(^Be5I&-Uia+&aM=ptt4Mb*u;NtG%eCq^Ls&?<(r@J4@l4sctg9w~e`2
zxe)QZ^X=@s^Plq;T6vihn)QLb-)f^bM1d(dUG2qR$oa%wdGQy<R6qlS`2GtB@qK{s
z-{XT|zyYS`2AB{BlMTU#o(f{NG{26iP$)Wd1Rtgy-mS08r?<g3^8g=!{dpL#oPU>A
zai=q^dE68-0L&fi_2dGsUvQgY#pl+0jtN5HbTyBE7vDQmGPEj0<ZWucY;o&@2d(Sx
znR|rB%awLEHpPR?OiauM72DX@DdmabZjh|`=otv*NI8S=DZJuLExb({9<;VTxV+B8
z!$)NUCw;tUTU*ceHWr!NsMHFN!%&p>9-*@nube*94Qn@NcFzkA8b2sdrT50Y0NLG*
z$DIM^$+%fVpLrRi_)rh?d+Q0%i<g<3dW%A;hL!+m$l=UUWMk$Qo(OK2eJ_FK<KeOH
zG6A~5#M{C&&PxGz15UW>u!lkoiz3)*^(GmN9n?jM0G>|L*TK|JC!);~SBF+k@#L;N
zzJBQxllQP=%4t%97ZXh3$%9gYR&Y>}f$&HktcNx{lMH8<Beg0|$`mS{#DB+rXo-j7
z+wdA<iCtjDy={r!hQKXXwAu3iG503$RTXFd_?>g^mYd`**+T+ZZ!RZ+1d@=jB_LoR
zEGhxnMFm6_K?(>$6_7=$ETSS>RJ4jqsry?gq9V0uYh9|XOTpKDd0Sg?t3{G~hu<?Z
z=ggV2+$FaE&*yI>Id_}+KHq1VXJ(!`S2}m^<UzS|pMcBXd*PcoIfc;;L44rrj&JaR
zfD^|Ke1)dMwEjR4O_AFC85xrfw%y>#D3Z!i)}3%JZ8_S3dP4f&3vI_M@F$l)zGiTN
z6J<AFcKibPip~6Q(9}Tem(o;d@tcm=F9Yyx1V5LievN+#E)Dux;iyX==bR1qh@&HM
z9{V~5HIlJFLLwRaX{e8|)y%T`^l_1Y*S>$2H@7ZB%1g`YwdhE&#9s&|F?&E&K`&RJ
zkDNPb^4_#RlLY-ve6n0B%J57s9MEuZ5`4#>KP%ni8MJKJIsKQzt-1;ZuX+4(5ewN^
zgM6F(=z5^TyM=iZ%m1#8MAH6jV$(vJqL@e$co=KfcdD!;h4*=K#(E?}p9-5+`Bplz
zK+kJfwhilf^cD(DES4D6tPWaif=&)a6J>`_E$BObO1`IWx_j)jN53nm3kD1NJaofd
zOWch)Q^wVLZwrS{`LEo$^GffxVYFW9vtU(4j*K#PUi92VkKYvtcs-c|S8RAABd=oB
z{8~ksJ7maQW`8Rk*??;;p9N60t792+I&wOiUD?p<uN=K+-Mxze#niF2rxryb-meLY
zQ$e`eQ$Ko2zN;qPy>#D>M~fA|)E0303I@&J@@ht2<?4AV3`J?Y=!!}L_Vo=b2D$xE
z=tc5~`G9K%@HNsgfmj5KWPFrm{F&HOhd4UqvlyXA2$*Mq6qL=T^cnt_)+`^Lp6hAM
z9otg-!|s~l?JemZU+(!guDLxJENMYG*Zbhboc3XTJeTzwGPX6{(<ie;+4@3pz5n*L
z7oYm!;<alp_IfV{!*)+!wQPGqtv|17#q6fKc`K{(;Ql7RTz6@!+aK^|7H>zn`F+WY
zbLt1rTn;bJC~O|^$c5?o-oS`ivqr!_>UU>OrY~{sBeTXZn=`8hA1T*Fq&W?_`Gy*^
zCAjMs85z@;D9XQ^KRC-%>hk$q{!sYBd5;GRva_!}8kY0i8TFpwAEv#eD1G4D>%X}R
zf7Q!Xj7HqFY*o7_Ge|<fC%cL(<ziPa{N26i+m;sa!%2W;9AF{)>6RFvt;dmBhmA29
z0xsOX0sc$-eKL2#f!0>%fR+~QH#-frgOw^bwdC8gG<K3Z4<!c{r-{Z1N2gXKbRS54
zI!+Z5%Oy-zCw3oH)6x<fjfSdDBng}WMystRWQ~|5e93+KIHM=6B;<Lwn>^?+cvcVZ
z=U19N3BRp!_?F3+0z>BFW8mq?afRcb>Eq;k9B1nYxtG@=b@hX+fj|ufd4YYYw7MWd
zma0pT(WlbK7404G4P_Km%Z=+|OM}6Ecz<SARwmraPyKs$(69K8kmt}WG)w&Zn6z<y
zqg-8(;SG(u9g>{%z|>o^BRwJ>@2<uEo%qF!4Dua%<o8a$l9P5IBLlyP25Z0fExyU?
ziS)>c+%gSjkRaP-&Piw<e2;cIkqyv8at46&&^)-88@Yq*Sm*2XzHXyOlh^|9m*Bg3
z<O{9uZ*L^;Z)}%7Z5-21K1<#Yb2jpR+CJS8(t8Nm_NKMMdyRdhHHRFF9P8nm!B>&K
z#V@=;bD=+S@45C)3c0-<`X%qR?N_}2kuD|Dn&2IGozfbka?tju+$K4U?P>UVdz_Bg
zCqjF&0UzC4v1i8Ex~3CLFB~<eOYaUz=Q$_IW2`!s$Bb!gXm4+59OHbwu^rkT-KOe{
zzuzRQxHGMP8W(H0csq@P%}^Uq`!}^GTAbLPCLeDv_Mv74Wc?9rinnLtPDChLnAp08
z*3yfHnv=-vi1%gm5W#+h){AsQQaSDVx2|}qcivtC?4sU<);ZJMzBol1c!S+0?9afy
zy)?xdN7nwhN_0yjwIkpsf_yM4i@n6vPMqG&nzEwMq~<Eq(IDv@=`wk=JjWcX<k6ar
zr2nI;(PI_7-!4{(G6*r_6RjQH{XW$jWOmQ`H`%?&gN_FG)Y#^@nsl>Q?OwxYvK<kj
z*t#8By&o%Xp+g!&RsKx)#oh$`#Tp+Rf9ylE?WcfWY~2<=@5hQ?=#bgI#=nU#kt2hz
zaof;Y;#SAS(pb`s4FV^#eO*42?Tb>y>)lpbZWSDdRct#z619I8_f7gUNX$n8p?x)U
zsq!)ZAaVCH!MEdjwkWA>>=OJ&?TEXv;6DlDyeNTzO{+AzB6+Oja%sGganETQS4{d7
zdl4lRpHD2U4G@dm0-%JkTa;f!qa)zj#Dcq+^(weacVf5Lqj;_NuIB`ZYug5hMScNL
zlCeZ&z@P)$u|#LX&YjG(Xj(A%x63lNk(2*IZz76#&x@#&u$2I)g*H3DkoS?X*qSfv
z{dP8vh7`Yj49U}laoZr3D2WiCKGkzaHP`DprL{)$e$t*@zHDqy8}SftPe_>c_8=Ar
z_)M`}%=3(`Tk;3qiylI?`9<s#y*n-MqufF449C&3&Lrk}pT;Sj4ncYi<F+v;ip#FS
ze)#-LXGZUXqvxFS-bj8-`%}3$aV7F&?9ZwRy+5l?g#MEFX*}&1dylUv9R-(KNcL2n
z32+<|vwOQdPQ;??PPb$=4s`unGlhh9XOKX!5WQs~3JR8I8uPdgVGK&xpQt<WTI|oN
zMSalI=1_vA!<c9As{~`7$X&eN<7<(l;GxUb?-Kfoh(P3CmtWJQXftM=a#KlSw_*>X
zyyEkE&vu%&L7_>{b<WXf`J<MvRj@i3eN{ljAYRAAW3>buJi;W-;z`{a??m0Cf-b(L
z*r3!{OXm0I&@qS1_e}Y&SfZ-WSCD2dJg)~j)B&+Oz9_aXjF3F<;r-|VOiOdc4prZ$
z^Hp|FI3cEpS{C`$rO~rXeZ=5`>G^>!U=rUKdx_V(owRm1tb*GB(#9>OKhwA+ax9|J
z<>xHx2E@hZGz;#QEZ-I7kJr1M{5CkO;@bgI;}O??f><nKvuDFj3pT`9)F2R))c@n5
zi2J;r({SHNjMGY70>H9F{a+pTP4*+^-J&-22+n5+T!DPd;?qU0Hg&$3>ewkVV&A(k
zesFHAKzJauiyuk+S!6)884;Te8+Hn^5@S&d5ahDt7C&OXWRK2{t%N`=#MuB&k`IXd
zi8>UywBe5{QTIM8ecY}D_XGZn^9FXOxfI5P<ml}9O9a$HpB><&ctr+9)<hkP&)cwR
zr{qM$TGT8M?6%<-Ho4-V>F)D7dONmL6vRS&0)dcYA>NHHI<t+ecZ)oti^wD&)@H|i
z#ggICFux`5?Z*C?Q)_~U<W9fV82Gx{p51(3)H<4{Wu?45KDF%X6xx#w_)M`}%r%Xz
zo3l#Z3rEdUNWD9To$V`{=K6-#=W46lvc`qB-5C2+gPst#*qV4PWD%AwIB>qLqjyGg
zRH{e&xxUzkc&%%Jk9k}qt`5HRW$4do(u*laiKiK3?`ADoQE;ibx@_Q3z47&EgWrn2
zD)?c6rZ^sfJ2N%Sk-0Z;$=fs8oaj%YG(ziqZ%(i})_R-f#s;5B*q=cHA?AzyS$v6$
z1>u?P!RuB|=9fnKOu7>#jH^e!x~|8x_$V}~xe|3W|EcVJwT&Atmz{67iiX<_*$vu_
z!@Op}c9v^WxxL>e!4p^eaqwt5NPvf%gpDVWT+M77339c#))5Dt##Ra_Ehb}wmifK5
zuNU9%^_{#z&F}ey5Y}I4!2>C3VYaC6+r@2B)QS+ZdA^Q$KYIMq5_O?NwLd=3GxR5V
zp}`V$Y52YXk272>Ej!R14di3CrpssYdr_)*z1vD_#bFiO4p2h*MKp2b=i6D__qqIh
z_sHt|DajwNcU$?bIIQy90aEqB^>5NgJRQVggKNR+`<xa{3pUOK_Q8B#<j3UuA}gt&
zvt=s*PAhE*0Vf<gM3zL{`nbt?65Uk|+A2X~#t81(opDp_QM}fB*T+p^UsQ-2rqLs2
z6F-uS9U=p9wZ+GAoei!a9#;5}%4yN`Vu&x@8aqT*lB2U_D*;eGd}y@U0qzEWB3hAG
zU7tFCcHzKmR(9c_dt<MNNW8X3XUks#pcek@04LSAh$XI$ZF2>kO|E4A6p!}t&C));
zxovWrA2H7tr7~P|U$SL86+tYtYi4UJkUH<N+nY96gpP~Pd$hf2*a76}PvUux*rMTD
zU(4k?o0#{*BRb#b5_(kQxBZ;e(1&0n!kpEnKVjCY?r#YFCGmGLn~mSQC5N>^!KLOC
z9=_8mz|r_t^#}9Jupnn#f6=vRo%?8N)fTt(>?eurqP+2X7DjVjW-A6RJXg6Djh2gQ
zbs-7&IOF5t^N2)vtR`WHCuuB;XC3j;C9sqPtXWOQ4z6Z9_In)hu<E0gw&5vysyasT
zng`KT|3Axpbj=Ad!<74QLlO{m!=6Rk7O!<SpdO8q+}N(~nA$KS%$zO3C8_<0b`noN
z@z5o(r1-2^4N0IcnLb5?B69ojj$4zRU7O9yYR=u_PUI*#GGQdvEiC~`Z2;ybXGN>c
zlf?Rr1oNcs;<d5F1bD3`X#=>Md5@_3?xIg%sR^XeSht$2jWpUi%@{s!HmsY7dtM@X
zyZQj`JbZ!-e6qTaZupAWOT6BNv6HV7>HBOP2Om56bk7cu8vD5X3DylnY~r=fhVA|n
z2gHfd6HzNcN&Q#sS@c=)dBe4yQ*yQv<Fpc&0B{oiL>-D~4Y7}}!s%MH8aQW<Yth!8
zyTxBB=n`9-6{nTGgn(7Ng8iA|pU9f1SMhm!Hf^<R1<Z-HXxWb76yjezl<}Sy(c7_|
zq8wJ@QxPah?jvFotwoeY&wco`S~q0w{niOKw+k^oCbeHt?;?ui=!Ef`M}kB^`ADLz
z``7_aidSSX9(GX<8#ZkXAOW!!y$b}VV88KD#(Ul#y&c;r3SuEXfk55jU$hZX8c|0!
z{Od+yjUEZi+Ae&+x4&5T#8O;0>K=MK{!<df!ag^9JAqP=M`TxIU9=nVdGY-=+ORdE
zR1{;eB0G6Jw)&a$U##E})@5|*?6lQgK`n|)MPNA3if@+BK6AafzDGVA&Tx+&4QIK(
zZ5T7Uu@R2z!Fe9?Ub{08qArCo>?5rWJ~(xzYpv1qJfuCl`W|C@d>+Hw;|nolC!C?9
z=Ntrlrdo@5GZ7uFwHJ<>PbS3ffR9C_zhrBs`ke&O#~L5J$mb&+KCHvg_UzYTM6WQi
zqs^1_(U*6_1<(rygbvmI?AJ`=_s4nC>WXx+xLWizW}!c*g*52LG}jO{6u);(+5{-L
z)Ld=0aNtZ2v3+gsZJ7Cq{p(&TYwF`sztd;XAMp>ZJ(K;35l+;f-ntM2xSjKkH0Kum
z2WtD{_b2utUW@&44z2w`&{vCnbO(c4U_*Z<{fQEax{TMmMUz$(n$%p82LEIB8;5VP
zSMgeqpAQ<k0dv0ff*;+0nf>bhC6HgVpE$kq$}U^KwJckzN8V#P99VZF{uCFFp<iLt
zF+8vD0O;$MR=?)7aI>)UD5%vn;Yl!;6D_1WY;l`SfYM?%c4%Szq5f}M^CKeC*Eb~1
z|M{G;>t7cC*J~aO5yil|s12L-3Eqz$$+S6$*dg<O4S%ZfhOagV`33hpE|``(hz`g6
zUzg8h|DuFqED)d9M_Zv%LEp{fIIM!(0Al_hM}9-E0^hne^^@be|8x2EJ!;+In7^eY
zf4tsp<>!0nIu5J+Hh@$-!rF<!;zS*Y_AFu(*wD3L^(;<{rUhGvV*W4kWAcBo=Ty+y
zvXuy@m9|8H;cSl~UK!XE88ck-h{@x&;I3-eR_TF~A2B|3WBe4EvhQ8U7Wit06$p=n
zcJU(#9<g6hTLx@aHtfQRK7O$KRgD>==|zk$aJI*wkCe}*Bu8h*Rzjc_;%opX8Gl9o
zM9#!(JsaWHWEYmK{Mm#9a<=Ek@h2h@uXS{`{Mp7WQ{p0QK3FoCq<BRJMIDRJ+vC;Q
zOdKxE{;Fx&Hon2x9t*!IuHAGGy)D}*2@=<A?F3TiKX&t1kzw5m`20t!4Ix&@X5T5#
zMZ}hc_|A7!c^^EM^Zir3H*K!3*L)aax4|ZavEQ!VhxaGUUA1i~E*+^cF~=rDk770(
zzjw=wCxO&_$^(nH>NcVPM_nsm_hF&uy2FB;qO}>&@Mx_cZ_{%QO{siYOwW9X{ASxX
z$S?L1uXj6b+u^V(-UgA1hp%1ys9coKCAc2!@K_DQ22avh7SBSGvy~c3&YIP5Y~VT)
z<~|};(O>mQpjByb@8KhqUh>1uHHq)UW5B*=AvSWYSy5<l&^C4?!6VwTcpVRqRX<id
z!o1n)&E3j-MBSu<E~S`b9<(jDQ4vFLvREJ@jH_E7i8M>H^E|6j*_rZ>&wG-iv$M8@
zNG*nEgE(od5cMivr-IjNjS2Bu4buv^n|Y6@|L&rXZ><TX&{*$Q?Bnxh!$>CXvKc&{
zubc2)H16hndJJsZjMd$UH}QHG#?DXp^jvctjzb><wCSELAQcan-!yi{wK5^Yuw6H>
z#$!&5o>$utlr;XOWJLlxJGO+`o)xE+xI}=p+(WykjEO%{hjF>IT9ciDbN;v<t=>s$
z2+g@!f_0Zv(An|Ft=<l&mA^!QRlI`znefJAE#C8qt<erJC)T288-i1af2mk#JoI*K
z+gYof99H5}5Xfm-_cGb981+PJ5uevHK|a&w1|ozb^Yofqg(06v>i_YWOO8$$zZ1qy
za{`nwekR2$G8GTI_#PWJ?F=9Ru@<e11iLMB*CCD{v2G#SxIKD1wo?;?58xW{i3Ca-
z??iN>jl|Uj&ql4*Z0~h(4cjJsK+TUeKBvfk_t4w%&)qViAQt|)r`iaVf;^%I;;|m@
z`4qh&p*(y6-eN~K@_20Z^Ixp_F?bHQH9KwDc}qe;Es9G)U~<-v)clZp`oO(uL_LVt
zdIb<J((ZMj)dKZr4ltUY9nx!pOnZ=`++xeZi1(4UrK<PA$24B+z<Xo$`g+Y!%Kh<K
zkxhSmeTVNw2>p@zSW!OHSeepXhwtzvLcyixa~L}~8sGNk{NnOGm(LkKw(@PMMH0k^
zxqd?VML&<*JC|RNt~M|@0Yq+UZ@kt)0HorHx9*o39<GN(v~aVqE}aW_Nd2kNK1{i+
zXd$Vgv&?}Lq2#P_vq=b7wI97^#4z_2@rnMbM`WIYi0-NmhP)O^phvYIy+4!xh`q$K
zAH8=WV%qpIUoFyNqFwx8_7fM6h(Wv-af*1jB_+ZGW2vc@N@s}KkBG-)KVr|KEv16a
zVo8ZmYOHZXvW-9gUH)t;uxt#=T8s4~`4jECJNzYyTc*iF!uXX`-y*K=;^o$uIAUnY
zt7evoA_l4NHrALWoI8jX+FkS(YfVWCi`gcUM#~@K)C`G;MZeS67kGt*Zl-)Gf!BKI
z*2&JM-^{=NC*j%jc)bhR5}(7`;Lt|`Z4PAzi21KB|Bs2seC<leR&62+Cq_$2?E(t(
zhaXWhB>IV{D?7Fl<Fpc&0B{oiL{#Fnh)}mCyHXDu!y<F}cnMLr_!AL{*CIMw{%k5e
zbevZH5&%~5rndGcdPF?D0-K2{By_kIvrHH;So|~Er)lmU7n!&sEnFvMJ2g41v}<OY
zNT4L+x5&77En?R5A3iSHh9hm5(MrDT!V$esk$HSE<fLNHBGbvy3E5)exM>={dC8I;
z;H2YsJX|7nQ6?KUlZ7iYv6|lP;%hg@?|3NVJ+Gs;V>?Ab_z<oQTnPl~7XKn@@j4m*
zNy43({{-QVp7%4`w<&&zXhf9puEqB!;XgG&Ec_=BC<S|p=K<pLqHOl^@Yo_4QA!D+
z8vXPV(?sFWLC*VG_46av{<<e!5^qUKP>b3$w@D;0xlb0zYrlRZ%3!Y*oB6+1Hb#tw
z)&lbMH_2Ed+CaRXg>1ySYpajxd@Quq`*1W`F0R)MnsVRN@bEcSB0R#{k$Jycz>_qV
ziL<HH&{^hCiBNLZ_>|vTYbe0g)^fP*0Ds|lc}<+>g?N>4?ynh@Wwl<!laxP^Gtr*o
zKCiD-a^CD#-xC>L0>mm_VeQhi))N<395(IhSrg;68fF5#Da87C7TP_wtv;1liUfw6
zKpf3}`T1It|BJH3i$}WsT8eK(qfj#hYb_)<-=wx1kHO@~gt3KNu}$2zESDyXok{VE
zwkuwzg4e45M0ojfYNBYBg6)b7i@NVF`fkQt^K2u2ttB@W^?u6cJjF0i5+x8N6QvQK
zw_0*CpEDbEB3JuQ@?H^Ta`blAo}wgL0>uqKfkY|TlZaKk?yfvmZ%9!dt7F6$sM~q3
zXkY({bn(3<MJY9{S(BFd((1Wi3N?FiBNkux<TVvGVTvy=@d^rSVw{RUiyVtpAo0)%
zner!m`jBvtQomuBFLxvatmQ5`f2Q0eo|VVLYrAfjXuRUY>eHMAxpg=FwY%u;*cK+L
ziR93e7xQvQqVX&#|Duh=lSX`A=bu}1Vh7~>b2~}oZ{6g-yXfusPf-pl|EUP1%41l!
zPH`PaWL@-X@p)Yvc2<<4Vl0l4KtU<R|9EJ-{k%S};<2gwa#|JF4S|#9uVS1Mtx<g5
zpfO&@#aF7h0on`;Jlp2WQ{3uo$A=XBM?@oPq<iRv{E6!(B|-Q&tc9_J0;M2NJf=n2
z;=M=DX1O-(3@jzZSgguUK`Hr9JPpNrKDl&u+Ul;L7R99^a5wcQ+F(3s#piAG$Bi&?
z^h@Aa3Buohw(k4mrL)stcLlZRk2_uhfm5>Ac=jiHps2NY&)aCz&PcnfSc{z|kk=b$
zUH`)W-ktoCOK+#`|9}XK;=4fza;$LFdA2!cJ7y9FJZ|l$qP(GMKx1=ObA|P(vQSP%
z`G8Pa`GCfTvQT3~eQv0%N`|*L)JJ-ueE7e?_%JU&&$BJ~%gY8<=7(gj+uujd^$h*=
zi!B!zpNL(eDEQ(?1l^@5((RuO@#OYR%kg@vp8eTp;)7tXpw#Af4_`lGLjMuLl5Dxa
zS%Uoc3|(q`jIV%}wkZnQ5f0-O_ak44vj|D$B{zLA#PGnCnFgYB9u{_+hYCgqP|`RA
zF*+Llo2<N~C?^!<ok-*zdLcE7Wc+w$jQpg;61g|yN=KGwyK{|WsAD8ys-i3xjG+aU
zfsS)?JWUnlkt+5B*3-m(z(9y)l@SB!iOS$nMOmn<9{#yKdHJ60;n>rP5<Aj&{FHo8
z-*orbX^(zaP!|jq^m*upyOy{cbEb@|l}3O`oE?UD!tdCq*t{!u?z|GMSB^y@$NDT-
zRgoj3jGY%fH__vF1p;1A=D-yj-pI(SST(=)#c=pVFsox|=-eSg=E4-4%8(5*tkq=D
zZJuJ*Bx2^xtXzc-qQP6-4fXjTF8T3PML>)u&vt+1=soN1T?}Zaj;)Oy0ePN{M5K}I
zH((!8KYB{Ot0vvObl;9gixvOjoma-@Nq1Z+wFO+hf<g1Qyqb|$xq4nL5eRH{sG<<y
zjTc=}Nkn^n!-_#}zc(;sE<Q$OkR9_K*=c)04-*~J95i~xk%H>Qq?O8S(2PkdR5V>M
zE}DyJDQ&O+r8Ub(r{{VabH}#S#wLM;lWK;yx1@V~xf8cv^^0Jzqy^<%?}Inwv=8ee
zJq$uW+;7O()^tyw%o1hm3&r*R+t*$kb4gtnM>}G!i`TBbn7HxuRm-*))cW(PR?Kc9
z!q?4PS(WF{uf6xDONYDt0dHpUc9fgnm%L$4J>g{V%;oTg8HLRQ9=R|*-y0Y)3m=;`
z3k{t$V#F-)<4I>uLOk2&nA~kY{_h2{uJsE1=e*`WcGN&?t8+k03-%i#mf-;nU&N+C
z?uS9{TE_sg|3(8e)qP^0q=8CSJrQ)))sV;yov$iNN9S?ke0^G5QFUV1Lp3cevC-V|
zB&wV38b*DzA(0azg*vRLYDmq~x*90cuUfsU^SCQw@h<$fO6Xg0JPSF>@$>R~u0J|p
z9V<+tmLCzvq7GDxNMsw(=xJ)`N8R5z1hTlsVqU%co<FZ<^Y1F0Y0m7B+nHAJyUlqu
zekA3(7Yw>{2EH#GMl-?Br$-|Aff@S-&zGEeUk!D-Gi%@2n%5^QE5FaRZ`8Uo-I)#P
z`BKkblWvhmf<HAv0DMJJqR;N0TvCh>#4-b3h{pYB?1kV;W2`t#vthhEl1I62MI<y+
zcZcB`>_mPq&pm(ez8MS=1Wbx>#+`!}NX}ddF=1q%JCyCzgpu#el8Q?v?~XnTvEY?(
zSZY)hdE_mVdi6voKfNK-O{BRtAEe3avz18WBzRl#^KK{b3swqv$!NibPwlVU!yZ%8
zDONRF5tJ_Y=XORs-fLDV%HeAiWz!)=xniT&6Dg{lfpVYfF(8zc6)GHX5cQ~?UL>DW
zE!U0i8XFEfzuf%PX&6M^Rfjis<-p^EqwD1AJbzZ?XGp5<C@ie*II}G);y2?1)jPTR
zrLZ0&+4!E9&;B+wYkz@Kx3j2rI{y4%A;Z%26#hr;j3U6i@d`ybv`JB}IjktFt^v%b
zl_1!5h5<m*&qBTZc?7caU^v{Bv-z;QN>NUqcxtorOL#mMAcLQ;aMaR#EzMC+8D!&A
zy$i<FylfbPfzom<+#6I4W3c2YtM_aR$9BQcv@9IGHWFL#!C9VCm(S<&hr$=mdpuZ>
zoqg@mu$<@4sP_#2P`WK5wGjtX?!sU7auuTyH!WM$?#T?Mdpv_a*;QOA7rT1l@9rgI
zs)nn|(U0IFtTE;QL{>9Hsb+<sNoI5eG#zCDRq*k77lt7@>{IGF>x0+=KzQ4S!#(wd
zpn&kvYqPTpy7ot6yTHnp0j5k(`>JI(1xs?Ee-wgr@m`b(_;P|JyFMA@@uUX<GMs7A
zFr_)NVXUXw3hPeqxI4Vz*CC_q7mmFc=2sCsCn1AqpT=M+ERs5O4Kv|!@Q+|p7tO>e
zo&)Ij899yai{RHG6!nY5UevBqW0!~n@rU9470e&TI6555ZSZRIhl=tFh@#XO!0Cx)
zYLf&SO7r-fLA4H7P7Q*$4?)DV4aO9%WOEJmbM>BI8Eof^6Y~m!WR^k9ni$gncX_#c
zfF^jbVE%ibX%E1%TBExo&xga$NAQ^O@6Cr#QrmAw>G=D0W`5)o<3(27J;CPYzTGe!
zCLgGnK0=<dG7q{3`FpyF6}C2>xQIX4_36MK0m7GZ(TT=Z;xzD)e!u)B>ZiY%<fU$|
z`)Ws{qm?o`OJ!6Wh3xoi$kWm`ku#mWL|2||MvrG)nM@k@h%|-6O%eQN;=fXxAuyoK
zdl@Zvp^y+fC=<qCBz}~^xck1l&5@>#3~FG=W@CgtIuKJJX4KSdGlmU|9ve1H9y$!=
zBUjU+yQVA3j63_Tl$-^@yqZlfl*>L(Fe}aJDnAB;alqZPcW))OqE-slOy1qu91go)
z+C90T0-@4suRF8vU$(%|RbE(l?Vn-ja)Evb#y0tV7`tj%js-|Gy}&T0We2J<_=o^V
z>t!D3<o5%R7aS{hIn%O&9%owFi<|PRg9XUdyy(suiZcDK+U1fnA8CU8rNjlJ=%24G
zEG&ndV9Q_ny8PbiQb0WE7S~JRaA))G$%W+z#g>35#D>T`w${V^(IyJ36L+T!EHY;_
zIg@ERull0N!(wTW9~{CTPq6nDGzL<YQ=*GmoQKUlufng}djp${8XU+V+ccXvqh^oV
zWIVoz>fGEkMOP(-X^%0Q#C}gF-6y!TV^9YE*BCuAKvn_&OM?V?VXzV<rb85y*dRAN
zUv~ha02{bS$Y64_-=-1GApdL|`Slpd<19?C>5sjp^}!gDDs%MZEO=^22(`r2==bqs
zrJSyDVTrXOEjCd!ethJ%V2P}v&0m%xFY1C#B6_Umk%%RhwOClfvZ6c_pQvYG0ucML
zTrpFM&zQ-F;_>EP0b}>t?(wG5_aj`)hQs_k?~26ZH?E;Bwt>5#d2rr9Uq^4nqtfJ$
zs^K*b(}!;x@3fB5qIbrzN1A-<ahR;Dma*A5otMF45zRlvbur21%!bv`iip?g@%Om&
ze>-8J&!znDr9J$z*BhzuoQu1V>s-%Rl2#09e)mE}x$xcQAtd$n7U5U!yAQuo#AAcn
zA6b=4WZPsC5b1nJ=mWWM*SQ{!!KIL_RqqEi-gh5rEb?j?G@m2=4Kv7Bq0K>Hssuka
z;(8ivq_3<}rT^^sXisSk<otocOO8jUMI!ROD$J@%Puq#l^ao~MZpZ&%09%^gnPVX7
z<UU;zjWIS(s`xE@@kMXj$Z5)3DVx!0$1f=i$X*gIM;{kqGHP`JPqcaX1NmOU^PG2@
zT9`gj?(I5MGwJ(KmZ$-7&J}@-gwAd>_Kh<@N;qBaBNITEC(;c1?^*{)=+rL|ET1#`
zH^J6T^DeHC(umES{jPIkq_gynJMI8@Ky0xGrhYf9xcoer`V|gXwPGiM>nX-x-KD^L
zh`sCcKiSb6u#i4-cy>gyR%Q#vQ3nhk8u(Z6H%BVL+6(GI#a-(n5$DEt&t}$GK4;#h
zR;dl%bVsJ=ybo_=9Rp7=B}E~?0A8_k#i{{?3<F;SgSl~-t$w6H2~E`~WU>IZ)ym79
za?Z;dn2}>ZLzch3Nk|R)7FNGLgSRq%v~@|D&f6J31}C*y|I+e$GSgv9wH#g=YL#8S
zUgh5Lf9bl8q|wgRw@n!YDXYJCxM|+HoSZ_HuEKMk?s>>3dy3t?P~jfTmlBu!&+4JY
zIn9?%7{02(<H;btd=-A)vl;T*c4|d1J*z19xEspZEUi8tk(GVO7wO{xjb!#lkTujd
zH&xWDuSJmhZu&Sk2LNv_kcY3?fBlkCD7|;a_SeR@cixnJNt(~syJFxt#r&FUss0*1
zp5J@?z=|qgM%uhA*U|~?zr8K9w@(_mc;|gr40j2yb>3ur%_57(O_1c0I(a(hM0ClE
zJg#R#QU`BhGO4e5koxYXhH@rkL%nCSGHzf+Z=WyilI+f#+Q+}PJ)?Iz8nxv5{cDEH
z1^R2QrRLXM|Kl2d#eF*$kCc49GjIEC`-IM$vgV~__^K)fj_;jsdd;;|e~rp=rl)Hz
z=%s~Nvx<t@L_<9Roj@`Db;W@3xaNL$^_5qTs`mS{s;1AG{q#f8S9H1yoWoY%zwNS-
zJ|$zvtK-|H4|XY+Y`yB_+7Xpi83na-o|(P+A-Qov`_Z3+666sJciq2om|IXntZY}~
zCSv1YM><}z0%YPI9#fmqwjNZ2YS#INRaIhC4fU?MI;YWB9(v}2InzTCzrT7ENb%hz
z$}Z`H_VKUo$WVMEFWYwi>S4|T*Z;VOt-OEN!Vxmi{PUyj6W~*;XFoHiuy00H<%qQ>
zuUfLH5k4i-Ys3qS465Dt*X^FJ_o-&V*3>G>iBuL_cg;1C2&5>Nm^hakb<STA2n50#
zH!U#|9(~0~xGldP-JD_Fm-wu$IfJFp7qyog>cJj>#8{b$M4fZF(Zsp)B0^xSOeZkk
zL^ymzB%IlU8dvDvG7y+XR1JecS^~q>BMN;taa+L=Ngy(s6}08q+{f>W9*rLL`TO|f
z;j#HT&k$zT-YbM4X|J?baM63$8r(NFUmotmCrKmF7&Iymm-ZS%j2M1m^QFB4Atq;z
z&4)Hry_tBR>d@n>P78~ysS0izaSh^943rdIo<!nHdv)pzQCQlmH2@4jgVCdjMUTxl
z(v~6*s;?ys&uPT_APS}t>j!(Fk4exljyxtFV)Nt6Z6{n@9%A$3t6bWvu>*gpO{T^J
z6@`sc3C5*Vy+)%&^NYlyC-xRW9_AN`#ZT-l8Y!w@$UN`xI`SMPFo1Ye)w*)%APkX$
z=$K45Bd8hW$uAC$b`oCQ$9$*Th#9&M!*4=#=V00GlMa*L@N~JKyiVSD*mt@T+}TY&
zNNmvBCv+9jdts)9@-&x3p3Q3Gv>)DTbOba=9Lw$6r*%(yqJT)}(%THG>=yd0f;Dor
z&c+zT00KltQ>>$Mn?i+3kYxZ8@aj=KcK2ZEBEjrwvSN;ir~gTb%Fzv8kj<RD&=z(3
zKOGQ;F?S9j<n%v{jxYVoh6gXKZxbE_eVd}XI#8s_O0$I!!B%uaKvrTjIRYni1TZI~
zR7{-^ZdaM65U+6;hY{(b!LhrIbQo>03V49r&L&riYY&<Mh!&~~XsdDX13SA-rrS8y
zZ1y37U(lnbIL&X(_M1>sqF1M?6N9gd_Grt#?*E!EdQ!?oNGX8HWx-)dfQsX{YP^cw
zt(%cqB6lxcaq%oujBV0IMq3h7k)J2G%s6pS<H0Imd>d5fd^G=vJ0I+(h5pk(lwtIS
z$kL6NMC>*vK2yN75S!UL&@-@(HIn(EuwvfSTv6`S(th$h%dWKvSmh9;)&uApa4_qA
zCQv@|jSg>aT2XCY`ybjT;bV)}Z@Bc*)$`Ap(7U}UCzAg3Z>}bf7feE}3*ilU<*qcZ
zD;V&lP5g8D$N*U(&n#W}Y1P>|#o29N?D}l=<(ID>T5{e{CDZ>sx&Ca|7j4<aXh3E7
zljZ&rF9Z~jLF(zA2zzJEL<WW!swzBg1<~b3m{JW0v9$(bvg-O9NtwvP0{d}Kge|k?
zh5KgQx8#fi2Vwg?a%k$>nRisLCc9^ay`NcH7n0Jwfvhx_v)BANn|oFUoYfU{BMMLY
zcmkB+^l7~xJ-nwQFN{#1VxK3Y^@;KA1vO*`?V6>F`g+sTNbCcwxXnFLx}0F8^)-AA
zL|q|OIi;vVu-2ee2taxiV#w>=69Yw6o9E2$<#eTG1-#C*P~FmJio<Ld?T(piryhzO
z2LaN)S#tY~eKl9We%hR>G;ey}MN6+?`)KXspJ;Vw`ilDi{*FE9;rm<rD9XU|PT)zm
zOv<k$g*C)37C7(FI0fC40!R4K=q0P0)c!R()p9y0bEI^WDkkS0LYox?LZ8J6Avp7N
z$ROgTxd}v+B9Vv<PG-NFtpd0*NGl2vEvka0kcKh}JVF<6nCA2IoOkF-s!BztQk!4~
z+-{HqeI1F!j@#J{)BOwhQhA8G%+UbAgMgG;ASqd)ql7kjWjPp$F^*7B^RfKA>@0c6
zm8)LK^iP|zu1em0;h5>!?vN{gV0BGVj)d;PU(`+aD}MirYu89u;OM_jK8S(^b=6Jz
zu8=!>`k2{!oZ;2eM&*~F%hBg(CmPrHf}p=9{Z1S`W5m{<uC=gOPh1IR{0vw=Fc%7D
zXKBk93?1>OhI)C(K((I>cgs~fmyUa7)s<`3zUT))b<^<|=pHGjsHS?9bI)uQbyIbH
zezyC;lm9|apv{4tcc$0)gMDV>gZL-72fnc+f7G<q)L$y3HqU#`XB>b_^=(I4sW$Pq
zXU+qDQda76LNt2M+G;o<3hDm{WR!<zQ^@vW5xcYCY6ed(D-Bl?x1f=Q-~{g2<2<&o
z!{+aROOv1Q4*@5t%8$mP8$dsoQ~5=t(g$&A)iIKF=nAPP<*R{ZR_ds2&?KOv*fcK*
zSC*B6FHm=Gs3*GtENpt-vse$l5w!CYd{DI>O?#TP#R8ES6q87;5obk06V(hk7K0UB
z&@<phNYyi6g^hGW)1>r+cv1@@);a{Sf@N5_?6w8Oej7feDBnjS-z&<ga7y;@D1UqS
z6tRsHXEwQSb-m&k2oJ!|%St0^#sF(MV!i;LLkuF4S615GM1nmFs>FJ-+_!%5Ier!&
z{#45DQB&Ov?&Zp!I`+ana@7sX#=e5WsPwfr+s|GZEb%FU(2ggi|HaR}`_4y&Jx5Jl
zRpq>OX8SZXI@A|tyZ><Hcc|BWkKDI0RGyJp6WoYt4YdI$TmNe&SgS&fx|4%Z=LYi$
zz&NJtzLlEtr}!{__VX{E+z|>WzF^79v)kW%4V9wsD}ZR)>MD89g=42?gADo2Q>%7f
zKK7$`-bH8q7TviqSd*C%D&Gj;@W;P9@(01`rnS$!73^Z{nH8>+Fb?I@y1F2k1Vlwg
zSl`ou5=Dm$&*Z}JM9cpOi*83QeXHvvo`&DSZ{w+`14*~Fc|)1`)$*_vz~Aj1csGu%
zY9V!y-cal2FYqg94e~-V4`s9PnJMU(s2aJ^?%L_s=R|r$yq-N5d+>DpE*SkP51M<k
z#~bO9Q+3t(mH5_w;veu<1l!1Q@d79{Eac?_-bP1+4*V>%HV<$Tp+GdiI~CBrgQua}
zQFz5LxjH}78)~}^NvNX(zw*WAR&R*ZNVcrPF}xdH3241&4d5jb9zY7n^?>K%Jrr8x
z`sua!GTix3w6OC0t8%J{2sh6~9(+BH;?wwAw1)0movHWiaQ)oT$1ww}6|7O*wIVF5
z`&QIA4Z|i06k<}K6#!`&L30xnuMzu(AJ`<^0fX$ucc6gB)0>R3P;wN8lB0KbPtJ)T
zRMRWXojLrmvEvF0E28_uv1?YHJ-8O3zCFF}4COtVwq#XIKJSSZk2}4muS%*LIO<Ai
zeONwB2IA5eH|JLe=s3(uo~nMzN}irwQk&&;dSfG$(U(rW8S<b&fwKP9UQofC9rVba
zto}=%>CvMYKDcM{CGDWQ6)G2f*(!xmJnEcra~_gzCS(q{(DDr!mv)3Z!@DQvRv}c;
z+XKZ`i<WGJ)U2YgaNO9(hC2gky=o{$u6M&EHF-~QWqNz|m1+l{y()GM#Mkv#jv82p
zP?fJ|y4%z8#CemmDzfCmP(9WAN+KmxSk0MNO0vTouhW@TyX0BD#wyk~JI(3r_3HW_
z5klF`Q!gE@DD9U_-UA;j?$P6!rTw!cuLnXh<)c5?#%&Ij52{IOwzQ;<>e*@?th5yt
zZw$tfm_5&qETZ1WTLtwpK`nMbi8GrFF|8$w1lt1Q<il1SD;7hDjf4_8&0d~aO6?_w
z8r8fxf>mjJTnc;)0ACsPBYcIGjWEJkbzHZ+Vqh5G2X$u;Kou+0^`V(zc}hygf4}${
zXoKpN$<fzwHj$${nj(6&7bInihKhf!zMh@{kf)?(xHp;w0j03{E2(3cplXELC$Ur-
zTA}iqtZzX2!&eBI0@QURZ4n)jc>xd5G^&x((5$DI6y%0NvMa5m+&lKI=qi-us}B0`
z3-|?Ju-b>Ra4V?edHkiXCg4Lu(NJHY#)rR@uZJz^+G4sTJ$F6bk`DMh?(?3i9@f;9
z=A>KF1-Igpw2dLq7PN`7fQ)SVc{r;@+QVNi`JYuSWUKm|VJipFt!kk@`W(mk4y`(t
z%B;!jhYScRPqcl1-SM<~Q3%OU2hoaP#~|M<cDNQk?e@6Jdcn(0o^8XQx-5Sn+iyST
z4ZJUK<m#)B1n?bDrP9C9D|^c3LE*%ZEiaWx-n1|&P(kz9ThN@nlLyuI@Oc7}$@8un
z8M{2N^MVU@2GGB72EBr5e$j-(y&op~^PZllX!q3*JaF}1`~|7-2=u&R)zXQc%us&g
z$r}R2w9x0|KJtd8Ph2^qIH#y#-Mm%xMFlh0teM#XznE{*`dQd3p6<AW+BD?d@Du6<
zSs|DL=oStsFx$}A0Q$8c^HVV5iOT{!p@8fni^Ol4>?J}{4f%YN{JuK(yZV7+*Ijq)
zfvdIUg1nk%mJX7{N8;ka+)ceI*l4wHhU~cj!=sOGS+L+1@=sdI=AW^@1CQ4oJ9Zt=
zE#<4L3O!+rY<*%@q;9t134NJiaUWP_P-n2)({k{cDeyS<Q`Yn?geTo!!m7V$6}&K!
zW5*PDT`{v0sFgC7NO$^1wr)PgD`i~&9;wzne|#f55CL`1O0cl$Z+exCrC*3R>RAm|
zHw>PqouCDh*$Cp<HnP*F)xlI8+uS<R^>3}hjh%>q;v6`ap%%gXt*J1mAA`8@V{#0F
z^jm?ScTRGha8wX^Ar4g1^EP6&vXh=-QG0bxQVV+o3CIZx?V)^%lm}TkP$^*?3w`o4
zRN$T=w~Iw3R=W+!f2b)8=H{G4s(7dXCV5zm&wZpePG!JA2<3<96y|&+1~M5*fHNsk
zuR0>!0<))=8kIOhY!`Ut@-jB`S|dP7Wkh$-b7GWNgN!6aWD2Cd19Vdv<@dOZwr%S&
zx^FT->%1SJX?6?iW>iKo(*mot8WUKpXr#0eTHZ%#gf75lbrS^zn~3Lnl;$zpq4Ogx
z!vzt+Xe`>4=82+N8|^X(<}z?TlH^-jjZ~halv=BeCdu?1ED2c7g(9}oJB>}g9XZ{D
z)I?b|7<-nT`~$&Ao_i8%<oCf@1L%j<iIE0*mA=Vbenpy`HS+XMsLXs@G!!TTBgZpi
zpTX-!6Oqm=0l(|%>STS89D}VXKp&b9QYkdI>)F!vGHq?R>VLWky54~1W51<-R~?DC
zmuoT;S)iYLpq~@4gGyylvv7?gW_)mnLhD{ILlyFHt>=%po4J=qBAwMBDXD%Z%M*6G
zu`xP>ZfFC7%`Mk;V=}hXbYrr4MyH4A#$fA=Bd!~xor5@Wb;ICW%-YFy69Y|{uv6vy
z@Rivzz?{vxvGE{cbh>GvlP328JFe4|^PHx1TAt~8I}$lvpy~$VpIZ0WQ?q6p$6+o5
z1&*g@8k%yak)?YmW)wSz%1%<gNXCze&^9?w4Q&&sEcYeA`8^-h5sO4sIMND-EYn0E
z0aw&(4~<R&93imZyQ%%E?NhZ9tfnAZR<EkT4k&(!bbFscuG6p*#o8x+80GkBG^Vq1
zGV&8YQC$Pt$9@CApoZM_7v=ORQK*q_n2ON$ZMe5OhR(gU6*wb}zBL&Y`lhwj!oA7<
zMMapR{b^XgqkNcyJodM=I0v-0;sE336X5=4h#dy*E%pzmiJdpMcD-y5lyPrRIoN^L
z{`1hj&OM2J#xX?W{${`=8XycFDp<n3)nZBeB#yUwwz<xM*hlZ#OM{$g<R{f5rty(Z
zbZFJ~=?;U*xU;~kP8xHpk?uz#a+4m6S#*w_Qtrjyv4cA-)e1sffn4jbyTSEmj>j(2
z+XWfArQmL`ME+=hIN56MNB)Y81gB5JNbraTzw>2ylx0F5pCfa!X<oe1&g+6*jXd2!
znih@Um=3Ez2uH>-5C`dLKrt(}aAeM$)P#_51d|t|sgRiCZqTzRwKw3%+RvT(Q1%GX
zDZs}qBaOg`wuucny1<4ufX@1|2xrY6sSVM<WJ(Mm0kK$+4Po*Ei~ZbeW=pl_49_<C
zMjeYalmHe}AW#QFz(T|n2HZy?;;^XcX@PkJi`{G)A*pZK@M5(aTbHx78XKwzFGib*
zJ!EFeju%@3tbR@=Rp!XZyvBwqd4ZXQ*v)397#7Y;X>xmk?rr3boNfZ2`eP)HT|hT9
zwlQ0vIjWu{#1&I()K)g&*;X8b{p<3?(KDsf#=f<#?e(eVk1Ni^k;hh>gf~W#y$ut2
z%nD<?8DemP_+p-osxjCuzF1?hU3@9C3&E+6331|`-I!pFceZ1~|JemRAPG5EqA4DS
z+~g=C77R&{ItoLXh@s%Z<G6YGbzKUa$9d=C*;ijZ`(k!|-SV5IwzVUn<fE+bdFS;l
zQ<Mgh?$Wh6axbyfFz4w{?w_JtE!-20E}oOMIlj;WRz|lIgxe{>Tuj9xp9;tNKoQ5A
zVR?72k|T?hDk-Bb*L&9cG>&D#>RPVcC*bn;Uic=gFGerZ-t9bx*!rLR85xrfw%y>#
zD3Z!i)}4xS`QvK_7dTON^JT{`fR&MN;a$vLwELe$*qU}~I4Nsl)dH*~!h#st5r8e%
zZ7Bf0d{FD08K>HRTArR=+%RO}%u{0qOiPE2nNSJb6e$UK^wK5cCcg6XhJi~*Pkg1V
zp`fsw`Z2pNNU^pyZ>S9r@ihw>QKExlo{0qGzsFux1{fO$FP!nim;qBWU_U9VWH3Y-
z>oF<)_!x|>s7?jBWQ+>(gm9FMtZ$l*k_j?YI?ke&X<3^S0~1}OPNE3$U>P$UZHS}?
z%c7UXm5|h7B|2}0kDJ9K_K#1{btr<LozeaeB_N4eTs^}5J%n>}-4pM>C^x>`!UP$=
z4&eJ;J6vx%a<!^7R>=b{;($bsl<nuyu}s*srUe+xhv)<i&MNLuLeaXjt|}@TzD|B4
zs1$S^agHbmcYVL19(IO9zV!Axi;DJ*N%sW{s^$J0of%<tfr8#BZVlw+1$qrdZzw&|
zW3W@4j;~WLyCKaTDeckYrWt|s^uWxUdh{rZxYKqmA!}=A{_Q#G+{0?pD$3zzcD8rY
zQT>~(3o|LyyV=1Rl#`0DYbCDGydoGVn|txEgRL7cnN!XV@}B)Jde6BdO(}@xOHV<a
z)M)wd1tp3U(GC&rxMKMP;uMXmSMK2FE2RiXfFrP96oJ)Tk=JZ?pA3&$aI2k)Agr=|
zN*ZZ}?Q4B^$F-xV>vFeODR7SHI#Qr`-Od|}iuR88hBAP~#&uoa!wr%$);G%41sUGZ
zxZ8{5%>|jUzsi6_g8$NcD01wtnbCRafvLA-Lt%i&yKAwcEWQcuXw)Moa?3O_xzzOk
zM;K$sG6IR~Z0{J72v`^`gTqRs#tI&#f;SR-0zYx&$P-vP2beqb!R-$|c>4#^m`Ebj
z=w)Tco^QU{vqMo<tb5~)bt`a2e8gm5z~MRV-0m1b*H8%B<a<aY+;eeYkDmwzVTt5P
zrz5!ZA5T6VioL@2iku#H$o85)mP%=CuSjYPJ^kcA(1&mfu&P(~-4~L#M<UUcq5JN7
z8Jz%)-*)HU)D59v2|IfmDrh*ljhz(6C-?pB&f64a{T5iE`~8;nqHS=_<B#mAcpk7F
zdjdw_F^uilA-FyVv;f|>PPL8kdy9&0AE(;QdhkB^puo2R{C7=P7Vjd4ksY~ZD)GB%
zw~$&AkN2j<)b9>BPdPt!z)(yrgxCZbM@fLFC=E3>R}BbKR>@GS*^Bd3B(@G}46oW5
zYV|1_@&0F?L9;e0zShvrtDy8#+8BW)Cn!eUxyje3ADa7hd;8aDZofXhO*^5?lki0R
zUGFzY6An6ji`fs!g-EBwiyBJ7M)RDf@P56U7#vfUHtI0YEP#=T@6<Y?^{^BIz7rs@
zek;&y*G!itFSN`$0kJ_LWL2A%8v+Mp>wt)!-_%g*nrUrQ6U%vRVniTo1wP=KDc2H?
z!ys$KO^77~Gp<Q#FkQ_f&PWcG(p_NJOp5wzJ9*qTjEfq9ad1DrTR!RfC**<I>e`aJ
zWDi=lT*)UP7gO+N;rC0hdKHCvyVLlW>aL&T7WpRml!I(;X*-*c-N-k^e*Nnh`6sop
zzcIqO)A7qQk4U}bU%>nGVecf-cRL9?n<3#^>UH_}@k^JEAAh;_x1+VDy0x{srd9hZ
z{ojNo@P?&JVvXvBR8QUk|6;#VFGx(BhwqVxxV~@{I3m>IOQA3~Oh&!R0U>JWaPzxf
zC=zlP(n2H%CAp!XJVe23aA#Q=)M9N_DvF9KcD)wqvtU7=2tJgDrl3I|7dx}Foy8xc
zL1;=|j$1z6OLphE|1cP;oc^(__3U1~&Td_X|AC`~56N){U|6AJ@Hn9h;sUTeTuZ73
z0aK2P+}E@UFu~>(Kx}T3SCrvSyoUC!psmPVb_Du=4RA<pq-*?pe1LTA{#bVB<lzJO
z_XHH_808}8;L`&KL(y0+fMFPB;(MesfFYlr`XY-xq|%qVy$2eBfdTfK!xB{6!t>IZ
z(1cs@MD*yb6GFB3&X_P^#=W)p)mwMsFYs@2SD}gMJ@}cpDmSZgJwE-(*I$2vPp_~1
z5|yK+XdWs7!EeGp1Gz5)xr4mVpgL?eWrN8>tvj{)e5j*CS-?2_#S?|@004Tl1Anpe
zRs`ueuE3Ad?vRIchdk>mvvODAM{xyonTtQdcR-i#qXJ#lR_Hef(vm1g1{SCzR?{4r
z?8)Z_rPl29ijOb8@WP8fu1L@BcxY@p{&iN*!*9M06>ZAvZyxTMb$XV&=Uq?z`V4l1
zEQCM3O;Sls;uKvqr(5*UMaUtwvesD39qnTuLc>U5A8pQ4Nt?&-ocZ-rcb)!(f@SU2
z0#=_RQ^m^aL*x*WYOC{e@J6&QC%?J_>hu0kRVQB|Ur|?e`Y*28v58Dp;8+@_eV!GZ
zP*7<oBn`tG;iJ$9s>1I`ZP9IYRqkk2U38oDXy-j3(=yy94S_nxOu`fFm5@6Glkrsj
zL&9)by)<MLUW2xd8iij*14f1MHBf!BKKzp68Q5Dnz4#jlA=Jh%hqeauw%CkPyH_X4
zJy=_V@tRSi&;a~0{NAdy1rtN}ElTenNHl`B5a7B;B0if%8DVg0U=!J0hX5J}6#cYl
zaM33K3csv)#`IR`!_#{RFUWB@v@uw1gY-TGZY0`N0-vWyBnqVK6Vd<!gYQuk`p~^t
z=^Y0HFw@+W7l1Mqjsd?+Kh&jRIDHF!Y>xr%-0g8!4WkqChBAf$4Im%*G)f2|7~G5K
zW5B>{V*tpI&Q=Y;;J|0VW%KBcrdCG;S-mu1L|xs85p}gAJ-W$w@eZ`YE47gq>PC!=
zPS(sPlpVc4dVe;-C^;@s?I%F`&<d8c%vQX+zG_Wgv;yz&LNC|SR%`1<FvALE%QNH|
z*&$+H3<_j*(Eb6u7v?12!s<jb+bN5L=`4~Aw~<PjhT?D*DM_I754T6XL?k4kJbK8`
z1#=RwJN9MUZM8G}N+1)zvoQ8qQIS-%5Gk1fQapcKo0Ltm>)7M)^tlDGmQV;UEK%gH
zH=t}h5U5H24qbmHv!EdJ47&ci^qN4R&+LP5bdmHL|9$1^)hqGe)6oPH3yxYa!?56z
zco9WYvwDe05K}9<T%_!Wg)?V11oAK`y@rfG_Sr)Gjs`IHB>^a%TT~Q#oJ;_uY)u@b
zER>3huEPsMA*l@@;#Ee7D4#%t`@6y{Ko<zF0)dVa%)qnEc^(IMr-rQ{K#fG6$z5Ev
zX`f6(SK~0sEyG=c#PVyGs1KNDg^4a?`kUyBNcQ5{`&C_hxeT8gxqv-*b<NX6$itH+
z9VQ|^z2;RW{eqDwZ5hgD5B8re4F+jTq3{%cIc^-vE+taq?>;%kRP_;BeD(ELv+D<u
za~jdow71`U^X+MbfN9A2AX6Z`2`&DJT_5`df0tSC@v`O1m!ZF1bL6F$j$E_lnrn=_
zoKJWml?Qc5VhoT0p*bunmr_Dz&0L-22DIvfyllE)nG>ML7fD@K#6>mT6mE=Uq9$sk
zg3S2TGW?|`bL>U1%)uIKD0>-7vt#WI;H0z^Wsk$l3UMj=un>%R8jk8B<6F4MD3e$;
z%H+i1TXf=ZR3uKyWQ=S9Zk8|m_~T_@GYE3Vd!!d2zU0z4OGZg@+)MSu5ZH_K0t~~y
zUA*|WWMJMoefrK?GXC#*QhxEtJ*#rFE0%oF_4x-&NO_FdR+x>A<kVY;bC)l@AT&dp
zovStC>;a8rlZF8nd>_b8{0o%f`iH~o2swH{2H6MZ-DGnXbO*yoJz2!~5f><9*sx)R
zRf&JO9)j1a@C(U*gUmbeLaEVRLGA<vtKKj`k)T#bZHV0=f&L!GvaA52W<#QNV+MY4
zr(elQJCKoq2ICjC-v`oi6#q^%I0IgX-!Ern;{A6A{fh5MW>!`vnuTVGe~<VSfADU+
zpFD^6!(ZTz?9Vp4I-KhO6P)-WYrEX-BZM?KKnb~TQ?q(IR|XAkV}kPF=qX(vaCJnY
z=jZlzR_A2&E7~0nZ}!Zb{`1p5CD(_Xdmj#mZ`deZ>f03i!;XoQy^3=7Sg*G_YdkDQ
zH1>b?zPsn4UKxHR1HUyPq6~?(z>TzbPTO_MLyd5f3b5S;S;k)1)i6VWe1on#gJ-d+
z5F{Qjw8Kyza_t?}wWGx)K_$kPFnW4a?9teRic*oD=lp)usMrhP*cxd@?0#rZ=IxO?
z8BiUt6%W=TOye9dhb*fP!zqVy4}4>QICs%|DeQszp@$_jbrjCW*Whn^6iP=V{Ju7z
z@~&}2!jtgpJqjC;AFY>SBOqy4hgQlv$VPbYsqTxHN1F2*>dEw0jUFDD+LGlLI912;
zA$p?)7${&p%lYcRCyy%_GkRs)>WsGI(^|4doORLY%koBV33n}t_~c*saur{6ud_Lf
z&UqwvQQ?4^@*&>Fj(Y-&3mU?u{ez8oi=t$uJNslP{){Ma3$_VsE3OWC0eBE&8nmuv
z`_P}OgEU;=+?tl&C#&l{XD|$@S8-6zbXVtQ#NamJ#EyOg^1Q{yZR2QC6|oyY^vK}`
zYl1a05Z2YvBl=WfQO=y~NSb%`^r+LP6#n1VYyX+8_?*${tG#KF?B3@T70MHGwnR^^
z-$2KKi+kh;hh^j`&enNXOG-h;^5?$z;>Z<gg^G0byjG`@mr>B1-veLhD@2<gdHbD5
z2-fq@yzN@yJg8x1`99b)T(DwWV)?q!XG4g~C%=Gv8T1hb&3KS&1#P>kFTTcC2;<SF
zzEuoI`&D-n9JfC4=RZHbm*BYjs&*%S{TD}$+=DKHV`m^jpQ`8&IXz^lst*%&+Z;5K
z$ckURd?^}8q{Yw9+2(!s(o185HQj)%fNlu0fRkuP&5>OlzUYNS;qv@0xZSMt=7{tB
ztn{uoiEib;Lx!yCmVKUj5y`EIUxQdE5B#@l34E?Ox|cXD7!S#-<-ZfZ?0OTX@St1#
z1GUu<$@$b41nVFxRV2P@b|M-ev73nVW@0b8!Qnr_!#M2<$i#Nd7=?CqtoU=%E^=H1
zgTi8GodZ@mS=7*kg+;%`;jVQB1+mwieR6$Lf9E2COn%wptImpo9UDGN*1I&a$s!{8
z?4H=4e7Sv`Qon)%=f<$ptwaZ8Rr@^h%Tyj3OW%gwopGe+8f^kg&nLlM71$^Qhf0~n
z0cHH|Wh9v;-cHlps%AMa3!Z`R>S>fBsH_S6Z+HEm>Yk;}==l+!bm@j0!{LYbcJ^(k
z8$C5ABkZ0ueDp<gb38$3rczp+lQ~}g>W;@fo5SDk-x>RZJO{$=OV!R%?S4>!^t&NS
zWCAMjWcYJ3LP}n!!jmm$4;{W}?gUhod-bFEpY!qI!wvP9JcuGQV#`?^W@E(La1vuY
zV^kX>_z02JEE5Ts-;f|ijSB)Ax&0h@g}fGFKBSEv5_NbOJe;LHs|VH7q2uv8zG~0R
zsV-GAok35|+>1sJpX3f_<V+o1*U-0<j3zg3V57;-{UDXUeU!8MB}J)kIE>onqnyBf
zSHf|n33C?>9|}TwDnfZmC?m(8;lUs2<I4<u{6TemS#hQj?E244E(H1l`Xx^`@qL!m
z=o$ggaJM}g6-YFYsi+_xwJd%@0X7yJBW0*53lz55V-{x2uqkOom@&0|8#-@$ln4|1
zxi2FBN+aM~Z*-qDaOZycBO($$JRkovu%C&vP!kDGNoC{&GQ6l{JPeuA@6xjr|CmuO
z<qwA%>toAjpeh=RnOxKkX)Gq<fC6NKohi@eCPw5nPj;0AQZmJ=ERd6NWni6I5TAXq
zpA+MI^tR51zO`eB@uf`}Hpb5QG>esg71<Qs=iR?k{wOOw)&k}?9)IM`2;^i0VS7k5
zzlF^F9zi+tQ5%?_qWnQ|jT+<csBe4_pO^tM!O1_@56%xXT`_MNK!l<LW;4mG32GX~
z>8%u~F%moMNd_`!ewe&hw@WxhTvZ8b4Y_`BSA>Ap%<O<*DL|{)y6#;|t?RPZp;@jF
zPG^SXtVzpSFq5dZDl=zldu_dDr$*Hp%>i!!`;G1+v2`lQ^*zX?>Wa!k@>P(73Dity
zhb%?TVcY+r5X8A6uBJ**9+Nc>g{t7D7#`R6n$J_xC*Y4f8G-CfN;(|M&l=i#86|z4
zK>ADgv;IK%@fq^d)?ia#+defXvx?|@=7Ov=bFcw@M{j^&vwtVe-86lvv5?3`e27Je
z{IHwcwSx%QqQ++SJstUEnoNDq#qv&Kf{jesutJsBP+#f#!2n(hShg{a%Zt+?mNi05
z`?U>h8d$+hRof<k)hH{vR2oQ3SkxDdh2UFE29T>V;vx=29*d%qV3<orTIzNlG9M=L
zfuQh*O`lvLl;?ySDt^yG8S{ICu?Yr>N=PVUeoqV(e@47M@?ayXw27f{Y!hNAi@THM
zIk7+N+z+`iJ;UrOgnTqitL%avZF&Odtzn6`nfXo$YJ!JwmKjoH)C9Q*Im2A<I(cYu
zQ6#%)(QEi5Ip+JDMeGsEK{e?94mizw>boc9t#==fUU?Te!2C5Va-RItqN40b(V|22
z40Fz_>LWM{{T50?SKb|6bMPDaXHR}hjxEC;fp*3^4c6uB)ctBT>&Pa@lJy*uo>I=|
zQ*X%DNMfIlAT;Dbj_=wT?t-r_ao!fbh@N9U`5Ntc@ga0SfX!i#7X1dl_2hT>6u$m$
z=S6o#uRQoQIm7Jk3CTj#K_ooHB>WS~f)72YK6>@lyYbKPsjm;B`@elMdga~Z^fI_N
z!|oXk>v9UrOj{s^K^_Mt1GWHGkcSfDN5Vb_q!0#K<gROH%-phN=B&-=yF|joj!qjg
zWE%O0a&5%AWX9%AGiPqSwrfj#(d6`@)29y|JauX;Y9pkoA5Xwh2)Y^O7)>)(ZC=mx
zq{d#D&m@%BtS@J@=8D$RV9AD9QQyAOXB$d_rL9-ge49vITivx~<+q+yR$2yMUU)J5
zIjc3li`r_+nzWS>=F80EiF?45fp|5UM0QukzOkYWC83gGD{E?24ugvg(r0~tgp8VK
zS(>n2$K$Ki##&)r@XQL&cMu2i9lanDfSuML_)-mUd6p7nk?ZV+`m!oVMY#hGVdg=R
zg~Rh*%bp;<5cX9*!WRT@ZE3kRh<<^}P${}QxTgib8^kxn&fpt@PTVC0(TZ3M{e+x3
z_!KWkI}kV(>V>xB75I}bbOGKU?dZbyq6>tWlnyKVaHNa+iFy+Pa(9AIlLLj|E($s1
zmITv5PI7~R2T&gtbM|+2p;@u1QG6eo1>uIgMsAkS2R%SS3`Wa?T@Jv4uXZ^?_y#CI
zA>)>+W00ThMV8Tfb`xvWdKIo+B;BA(2l|ew9ggcDfc+a^NAKI<MXT{y5JMFFI{9sd
zMIs-*4&G1h)v)IMNJRcqI2`TI{sKNdPN&1F2+YO|oB%pwRJO7LXug3+yziapmA@d6
zzO~1&FS_Q*ujH*y{)<LmW54<I?%@IxWHiti@@R8GZJ8zoN>+rU^{`3wEZD(wVS79}
zCzZgPd@hjkIM89xR}j`Ei%pDFft6H%jcA5yMKdXg4}9J64L%Ss7^lfz@Hc2`AofdX
zD!ls})jrj@4z^MUQGE#1laZ)r7&pa1NgO~8qZ3(6XoR!hO<}eM0xN!y42UD@m#-}*
zL*?Q_!nm5P4wz)1`sTYQ(F4+kyYO^$|J|`RJpHb_<*lIm83(^HjI>YDL3;6PFlh1d
zRt<lzy>|EAc>3UP4$_Z(jUIUN+piA}0biN%3&OK5EAb1mde&@WTCf2bxvOA#AkWE<
zHA9FHuB}Sw0R0-g<ag2E77s3#hxHg7yKhuo-B~00^^^L*ue0DmG7FKm@ei-As~dGz
zzkVZPZ^Ey$-~o{Zd<fs;I_Vh?dTXMUPeF%^rE!(S&%<QDm*uG}pp(>1OY9;cc4rhr
z?19MDyBea|O0*62j8{uTVq6DAH;8euDP3w*`UuYo+|tr=O9;M~ssxpyUxd&#_LVz$
zT>xKzKg4K7z&396J2Tzwb2SJx6rx6iYccci2)TvZhsWVRz|T1JBpL`mPtL<z@VD@@
z1^pD3F#YJK_~_B=uA~3vZMo>8E#x04L-+(~fxc1rAp5}4>)89Z5dMu=Eip`sB_h&p
zp-UN*2@9+Vo8zg51>zb^$;cS5u8M+}rhw@!CCwF`(<4XT?@Cj$qfg0a!L9!jGqzBX
z(3<ofMPBq%N$KImzrqjuQpYLt^+9b<HYJ?r<V0r?g!1U<bA^Ce-q#};PUJ80;w=Os
zIv-8)^-v_d6;=yLOa}dW=NN2J$aY<#EeiHWmfbbBy>o6_u;3>0FZQ6>D$&2D4jVR=
z{Dap7J0o@{wXsj#w7|?U`^3~?M(c$6w}!Q+R^djRpWz^LHnm`o=5$7c;n;oSj~@G8
z>*)JqN5@Mu;mbdtfnC{A@cqYTZ0IWG!|gjY-`ctTLq$2aqvPCPm=F>FSa9Y>*XzzM
z@MS+)^My<UGH4i30gMMWJVMCzdbsmbIL}%f-qv-6^H|pvW8guraJX;R6+@ixRN^+^
zt7Ks=?Rq`Z`6=Aps5sIAZNNXZjjl1!!eH8p5leu?N)ZdR6Qb2JVe$=dRn6JzR(D@@
zO7D_ks+;GL)gAgwSZn6EJGzF-?+p$3ac9Yp{D@S7JN<zn#VCT07Y_;ek-KDQVWm`p
z;M;|V_Qc0gq^E{1)A?f8VDvz%?>YR)fbx8F&U3!j%FJ!sGArRJG<iUIA$|g$s_<{y
z<|nqOb4e-|B6bq!Gchq98nNy_vT4haXRqD-Y{!l{^LFf<d+|;KAZhNFBS*Ge`|PvV
z&fBqL-rSummo)ZWV(pu*POF+FY#RD>4h~1}fXr`RxFh;6LvN46v-2SZdO`L_za=u_
zOS~K15t<Q}sC8?^Vz||i0v*ym7*YsITIfIWHFDmK#ExR{E$m=Q(vEOP?Cx;vw^CN@
zq?FY)RJtgFq25*MPi-sqYPbu?k6jvxbxPBurLmi&qmsL8uyi|26J*B(u-Sh=Jx@C9
zz|ym-I;&(Ioh+S_$O#(`km|@gwCyr!c1`D@8n?9HpO^2K?sG4R?ThVmy`^rHoqoKc
zA|t~!uDH1K$&3o3c{+Yiz|a@O7e7?#K@QAplDDsK8^~$M^$%nF;Z8Vg2&=QSpYcNL
zxDygf<k0&d^3Xm)WQWewM<h)m147&_J9D?RJGsz)*G_~%g+w9ST|1CnI`j84H@eRS
zTtU#bhH406)Hc*tKt;~E;nSZ-BIigyr<CqJFZ>4Klzd05s}YENMHLb3=D-=`-r~9r
zc<kvYg?)3ryF`+A&=gyT<b$4!z;NIbm7VLn-f-CKb#1JK-<|6!D_!vYzEw|k^>a0M
z^^^A(r{j@wwR~l@jL%N*T3juoXVZ&|)6vs%H9}}p^oQ6e*^95Hx;)>}0s9t%p$?Vm
z5<EhkRneLyeZ+<OHV^sASmnd8+sC@}xvDz4`t53Mm6x=%M7N9GM31r#U_J}&Ujpr`
zwxaEysS@f_H;9OyOF%N8J6z@Rfn=v|CB3;G>*^=983e+$tVi5VL;;<kzK&@wpR*C>
zA5c(8Bv9|<L_6W-c`mpMVgS#;(*hs|Y|lT4?#~P<9eCgRNC4fBX9Obhu5c#YRqw&f
zaP%$d7$)n(skBXkxoz9AcWfKS&1g<+r~__Y$8pC&ZQra7UQngbUXOSz&?6=Gjr!nb
zh6jAtC}t{@5WIq?!8Zfwc#Z9o?<!$yON?r<eIGi2r}%WXHRwvV5BNXe3n?n$)E1w1
zOmW`oY@m7+b~;(}BoiPfV&t+k*?DUux-1MT#M3gv@~#M|72O}$9vh10pgDLSur6p=
z)4B|*#tL~IWO3+yu{}zNkH&uN`><=6a4*)DxS-;QPGE+??f0~Ho1vbOEIpTKRV7Rs
zs4ZbtBzjc|8m!ft(5ezvTk=>|CaWJY)|8-Gdc6s)DG_Q*44D3ZQ||&bIL_X*28Zmt
zbc3nxyw}+~HCAy(YVYeV`=EvHX-gvZqw~@oZMnKp$ppNlRLKOqr1ZY-Ry<Mb)Gao7
zg%qi4`8%BVzYf+yNqGR><Bn88MIb*b1+xV3DY8O9cDsp-vGPu`+eP+|8%jOf7XIY%
zYd5Z*(()#L|B+>vE?oZDrp;^4Up=pE;@KUGel}xLkD{nDas+vB-SkNvvvxos{^5f^
zyLm#}$`1U%EkFD9lUr{-XY^0@ZRtICNZU^qZ7UixW$Gn^;cENMD>slFmtu511i8>4
z_<p$Q1Si>qib!Rp{9A<S(lkMt9Z!ZVILnd;``56?K&o7rJgl5ikfndV&s#j~4DP@k
zXF_AWzI^AVw@-9-o_KqcbB0CC&70OvZuu+f_2{zs118SA0Y_gQIkICUl{q@wD6#yz
zg7lh+s2Bb?dtrJ(n&-s2Ypz*$!V^15h#0+s6ER`TPdd=F-CKWs%Zd&7-YHY&4+0`)
zi-f=#&odj~jAuWX(Gflbt&xOgK**#!GD_!$Qj=cOBz$S?YxrxXOClsZegkEuASP4n
z=oL=<N4TNSh4>YwUXaR(R<^X@xu_wDY{=ogT;2}r;bEv>0@+BO9Vw%CRAk#p`Ru-l
z;#?*y%(K0hKey$lPX%K+!KZ$@<+&r*u6;Tn{WI|N+G~$=+%R|Eu3huy-q5*|{3eg2
zwk^NCckSAHf4k+{qx;va*?;ufxi{{bH*eRC@Y;=Y;TpysiO;dp;A8;JNh82%S-v`>
z>8f55alXB{qif@s$P(vY!;8BnIX84|fH}hf#}3za*C<B@+)ab5?+fz;a@vYa8eq-~
znV)OB(zU8jf%E!cW@)%<5$xXWfk{y_>>-pD1f;ioN*8?Dq=I%yvt#$bSa?04I9HCS
z*%+Gzk$OR<Y4*o;Zn$eJ9N|NMgMa_0C~%`+>0LOu*dak7O6)QTrU_KG1824YMg;4-
z!x%zV`q7+Srd^Pw!XYS|q1DR7%CrlzA5??nvU*e|m$|lwaoM-|`AXmfex3dOeI#<~
z5S|F@-|v5$p9e3X{_HQ*a{X`!Jr>5B@t+Q%{%D<oFNlOgJ<wY1F92_afA^AS;a17&
zU)WrD9<}1<3BLq8%*l!!)3p0=g0bk^@Gv{)C*nzwp(YW(=!R&{qj68mzw)DncBh$7
z(RU5(E)5zFpu={!1M5Uq!NgX0hoLg<!YC?JrnZM%rd@Dl!g4XFlj_vN^cs739ntHh
z_)qNb<Va-GA^Za9b<v?1Y~)B2*Aw+#iu$v^Q^Mgbhfqs6jCcP=stChYGtqJ#{?l(z
zzk|xVM5j-%->RBH)y8M>^F-CsYxwyN&^GbI^^Q@l!_G0VLeH{SD6S|Y3)^&?swXO=
zr3ch255t$JE+q3CC(Lp>x)v^uME>?SSXDR_4uA0l*#AZ}0v~}kkz==Gkn<7eB(@h=
zL7RhCsb{KZV@RveIM_Ko3FLevO!m0&NV28FeuD(hfuLu>Z!lwa+j?TUr^4hm_5{4d
z)(_PAHi_6IgJtI>NcB+&))rzj{rP$R*erLAYfKGHs9nK~jLs*Ei(TU~GAcUg(m;}S
zVClo$POQJFq0YZKUnFvuz;~b&x?Sv!Lmng)y3^eOQgx(N6Xl2aG!-Vz?m}N|fN;_p
z4%F&ruw%`>bm<*mFzAzxr_1gDycNGK9OD)aOQSy0AANxkdAl#x8&+14qx6i!dDOKX
zEZPBckfX83VvkAZ!Eu_ya+}-+vX8}Wu9L2JX_Wz4$#x}1O?NxWN@+ERw(<&lGq9Tx
z4?f-F;5)3QJsX&DlkE)rd>naN*d~X%0c+gp1XBa~bo|{wpE~0100caeqc=Vv{}s*x
z)9-GEc|DYyQ!D4zPlh?w3pDem>umC0!*~^fyST+h!X4R~@Ri^TKf`})X_4R-mvAob
zda|UqJA!W@E{J|YR`bwL$Thw}Th$|c=>5|<VoJRy?Kw`jMBaRm_wOKYn5~6_)r;~n
zBR7Z(b=zr@{C6K7D+oK*=R*etVGsJ|!r|DTBG@Z}x%^nXl?uHE9rT4@7Jd+|rh;FG
z$NIA2NE^J9+JcUSMuX%?lEX;aKjB~~aBz%rK(i|e4gv@|C&iIj%?1wgvcybFKK9i^
zIu{S0{PGc<iHA>i9KUVv@po^#^@P;+7>)+uv@ZOIwg!>&(Z`S+gtNo&A6^r{(Z_y%
z;`rX%-aSFN&@llQsUS*>B5CJjJy*ZyP6Nw)And_U^1B0(e3T`kAz|0Ybi*C?4dSLd
z1fBk)wkoXsO@5!9gX&5#9>LF6Acq6aDGh>iO4<oob$JL*(hREZm5D38@EiTFmmH9F
z|EZ^^s_t}uShAMjb8XTf$d}S!1l6)pvgyM2)W|ZcG$@R-!JoejdvRrEuWB#)U-(T+
z!`}DwJl(&p%G1;RCvu40u^Y}ae-1ccG$y&NdczW#jh^a>nrujLKM&(4J|Lhz$FSg!
zCa`OC2^2#pQ3_BV4^<ES3DoGX!6cw<g7r>%ewO+Nu&%DKOLux>NBupkz0z>_?Ji9#
z`e997Ra%i}E5&5^oHoRg#a`*o>Yo1CQ7`<KhI{d4Rdt@NMQK%aKdd3}Ngm)jq2~c?
zCRM@ysObQmM>VKPcD?Ha%>zzoseq!uB`xrXmm9$QnQZ@$y7z#Os@VR(Gq>z!(>FaN
zfh@_gY(kSXK}3oKM7k(NY=AUT1VjZ95J6EOg5ndgE24rG8~W7e^9k6yKYPQ5g7`#1
z$nKr|zh~y&-McM`@4f%$^Z$$4a`)bu)91{YGiT73(}BLQBZ=r1(O2RwLp?hkR?m^0
z$L&AHLy>+;2$tD=x%#LhCA143v+8h_oE$6R3j{)B@X@NQEbq{L{MT-$rlxio$Fla9
z56jA`O2#gKKl_MjSj_e3)XZQF%-8kIjLgi8ZfCGgY;fJQ9Diy$pU(5~Z#r$uLUW_g
z?*^-1C|*)%CQp6Icqi(;Q{+M2fX?`@`($Sb9(=_8JeVwi+0U{7jM6}T@lW`(vM+Ws
z`x*akPERFx_%r-dz$5$J+WdjOR@)&nEYWW#I<u(2@_Fj$>>{VkxUQ?ur!$OvR%F3Z
zijB_ofJa|j(ouVN#E<jR2h`;k)D1|Rw|B(5TE`MxeP`s}d1(Xc3i9g)q|f_t<U6>k
zG+1ABx<!9yq<m0Z4L$hoh`rRD2_xI4uT{R0b4G#@Q^hb)&{!K3##iCK6_33~0iNhZ
zwv4<4ezEf%N4}XukuVp)o|oW!$JoVZ@tMYMr5C%2{Y~jTl{0<={xR0f&d0xIW6Ye9
zBj?Z`megk%yTpw*DZS`H`rUrNyl)QduN@XrT-)lnJ>QDzVaF;VT;|r{>e$05sjD+O
zR97qC)YU29VV$Ej@al{bB;tIByT7TfHn5->31<sAL0CVtRz<8pxBYnN{5HVLkMzn-
zGY%PlrsvnED=Eg|^!ogC#igXC<@QQ5{!r4=T0`K4UTI2N=s6d)V;shFvfV>zGzMJF
zFK~FEca*CO>k}T$%u}-HpgxQOh)<XSKeza*?mV$;w}At?cRf*=^ndU3J^b?zJ}Yzg
zd2;*FquZav2c@Cgz=7Sm_aDgb<=?%!^PjIUkM<&5i@?c$Zr!qF>z~?__+szBK*k&6
za~DSgIp`Fu_^{~ndhj82b^PS&YW8GZ9oy04k@z6h@gY5WupPMN$?9t4S=`zZXfQih
z^GiXST(iysEig;b0|hWjIxtNR^uw`sIeJY`{$NdwBXCr&sd3ilw1+E2HZAgb5Bvms
zM8@Ii+4M$^r><Umv96v!a7_CgXMIi0QQZ-!sgcjmZ+_qLq4p|qM#vLWX)yzWl`7Xe
z@Li09Vl}kbTyA!JNW1n6-eBp-RY^T?AhpELvfkuHcvrGh+m)og{~^698H(mF(nj)Q
zj63yIf05G8_@T(3p-f?K1s*H%JGF<3icme|i=v{yBptX|uvC(i$k}Qq0fsM$Cd35{
z#lPrXfI%Ka4#DI2P%#dsmb6Q)zx{oBGY<H%F8bq}{NH#7Y?MWF@J;p;K4^EQ=z-IV
ziY~*75e{9_9(MSP0*|t{m8t3eBI5_8U6DUUH}2p)v{6M^8{6Hy$I+;5rE$u(0vT7=
z9F46hQgLgFqM~NemyRp+hrx?p!app>px_tl&|nF;fNg6yFs{B@cspX7l(|<*<g+`;
z7s6&rgrB^kn2h6!>QP5-<?kEYSdW2&w(Q%tW$ZBita3jqxn<wbo*SA@a_el<6Ib&a
z969<^Jm;<Tb=BWEk`MLmzy2+L`_J?4(sDl<)}2o%+_z=RJ`X>?=kWLV&|HUuHC^)2
z6PL0;a&i0M#`SMy@!iQ887chT!na1T6KCA=j~Ngws{h%bHN%(cPthS(-U%Dh6&1r8
zL9YN6G1>xNfQyUd?O1Dd=GZ5KEGUIVp*5#R$9N=G*|2l3K0BvQYwkIUzv4*EAM)G<
zo2rjlz)u)_aKv!~hYfG&anj^&?K6#E@^tn-@9HQ}ZYk_JV#V-2Ck{V(VE2<w>s*+@
z`tbfWS;)!T<Vfa&*}aP1!S7b@_^88_hxvBnORcKU^{^=Gd|if~eDWZd@8V%s6}lWs
zKV?;NVTWZCuJLs}iLQ6LxZ(1Xm?4lizN$Epy}$-uNjjyGADJ=|xOY!FE9ttVe~>f_
zS5o3agfPc`5j-+!kOQo&+(^<y5aj<e_os{;KI}vyUi(a!tLWr{f#a_Ou}>Z`xW~}R
z-F$haT`~)cdXHEMA{*buzf-V9-dWg3u%p#GvkJm@O4dd6ZnC;_UI%|>p?RnNfaJ`C
z$JeaptBlX@JwMFFDXf+~#Ktas@QLYR7Pfff_L={q8>g|JBpnMM6fKgBh`ELufQ%sj
zD@r=()I5s&$;lz9eT1$+O61(2E+-qdFkcM_!5-%$>ZGKxbdQJcPs>YdXL2b-r>t!L
zM|nBR$vdXkFW{6#tJAlyUVX<RulJ(cr@U;Z7ow`)zv%V8!OmlweO)799vTfZmE(~h
z+dz*4I7xLi6xc+dJ`#Zr87`NT1N>lG7AwR1N9}W?k#M<!z(L8#;Ct}yb9*9iIpfjQ
ztIzd%|F#N2&_+8lGgyxm*pPkqVy}1I?=kquRS3JrIh@%12kWFKW&$?bK}EfBx!_`_
zD&9Q49vd=a*x*j*k2t&q?EKu?2-t}a>t`(P)Gm4D4I5)v@#osh=$BVfgp9Z$=G8)e
z2FVl9!uEpJ8N~pOSrr*vfrkUx3lx=)6eXA&s(n^>0uzit)+B216=a7bs=Vle0gghK
zYuLbi|FE$xM`6maOFBeyq+^!Lb<y?zZ0sO#F@C)C&V}ccSfVwHpXWIx*;(isTEJi8
zZ@GFqid?RNslVDeGk){(E6aB-Z2Tbo7sAZAA@k{l)9?4N>B!6aoi_*^PZDE@%_gei
zc(1rP!HlB#tckTm*^DXoWhS0D%L}CG%S=2^>s(&6;D(nPqcDSEsa$ZUI=4f9hv{Wd
zt<19NWd$APYA>#qxIVIIa)IyCyDeO2@>%6O7hU&$dIWY*BK8XFpRxVoY2|um^>D9u
zcy*RmK5g||65Zg~=?{4Lqx|d4r)@k<HKRkJsE^%3s9-2uL@ctzWhi2&(k>_$^{t{(
zeN}zg)ux3gFZ{k^NB&+Eq7`5vQhILk3Kl92@}a)!vC@{#;)^`S<nmwaOq=w`>eb3}
zRvaaZsYwlF86an7v?>Db#5{u>lGh?CPvQ_~A&fELCty>B+m+I@cE$70uPDmOEQpW7
z3_ddsZ_apX-F5EgSFCtmnYYa}36cleSlH!MsyATAMHe1e+>yJkUL2ce!Y|2hcVB3W
zc)mIeyg1<m;z#l)8_yW)jZ~!0d6{V)@0&)5Jb7l0<b~<6lo!?Y+W1L`F;yEs>Bhge
zvjbB0!RoUwCR}d0k7W`vri(J2Pji0)+l|!?Q<rMtkqwWu-z{iUl!dULg6FgGxn)g?
zv=NUGnDqCtC7+fG#b?vF%~#qDL~yKp`uP>6oZ4`!PwE5gBF58Jv;}69)*H-$$X%|a
zGLO63W&z`Bj0YM+!%vqE^}k{yedN=;s*(K1kK0*@oX0PVQJK?jU%I4Rx!tpmxD&`x
zmgC^$mzCwl5{BFo=?`dUK<=gy{7whzT#$mtsyGe*VGD0XjZDuGBNn^|b4apFplD0x
z(pbe^dunG)?swBVl&pvyqO$p_-nD&7+|Hu<<4>xnIO+J~vQeQcqeSa+8M{1R`VXc}
z>5!T1N=<uYX7!LwE|05d*z1b1vTNy8H%E?O7=I5xS2bdM-<;yf{fCrfq@-k&3>h@q
zm7SiQoN?#GPuVP+(9$UW;G%XF=iH{Zqs?bRc7vdeTxX_j{0V6zC##|CMV5#bG;svA
zDEBbfDZ|CDOU{X;!<4Sj$W(r>E3;DyyM>>d(kUZ_U6|cXSQs1b$xe2LE2EQ(Pi42d
zHXuoL?uct6ai7V$f4Puvc6o7B=q9!)CDWV2*KcK~L}9#WG#c`yqai-k1(C4%hyzF_
zY$H4@sTm}ofh?Yo&>(2tV-4>%C0%+~VbN8y3x`FUpbnK+JW^Qr_C`6vS>ikcL)!-{
z_|-*4Y~kFeI`UhL|Fc^k@@{vsftfp(%Ud??kz-pV4kBkLi~|@*L$DdF$Zg3#k?{<2
zOmgb7$)5@NymCI0?_d5%QQ<oqqlPuII!o^;EWG->;*Oa;<ebC8NVxrv@((g!zLG6O
z4C3mW_oN@N<1`LlNyU3B<c}9V-I1NeT=UquG$Ftkk!RXc7v|~28R^dUq#YZ7W!9#C
z?FlX|FITVd6q}a5EW?#tR97%?+&VdzJ!Z%`-8<)%b}Z4_)rv`z!-Jd}{tr1aPkL-M
zW;uM>mf3Qa(~#`D_*_<v^T4ydD!Oh`B&^*{SpOP?A>2a3(<+F?7E%_mTL<&VLSO|u
z{z~&XjvMqUk+}rL7x5^ooGS4>l=fYYJ<2y6pI=~HZLBCLJiY?ut(3*e!rY?c#~5pm
zH?Em_T!FICxVqpteSBWWTw|qjS#EvPSK3d;waTRd<oJV!^Z7lF(fUuwVRuXIvh74e
zc9dguc}7Olr3D50s*H^CF--^f+g)7hB^h~n8R{jjE+|VoG59{s^&dd}IghBbOu1uX
zHW&7PC@+vqcx_EBS?JIYRJX8G=sel@RhQL<Av4la{aWUYm6biH5cBk&-czm0%htOR
zs=%DOWYu-YIjS@zGwqU1g;bS!WG`iSY&B-WeJkqze}}sNIdWf%h_r>`FSKq&`KJQx
zup!NNepej0kSa@R{Q@tF>iO%6jr(J-Q30`-s`;pq7;{b7htPSV`6d_SIjzDjm`CBM
zU&I^+BTr*Bk9IOo%7OgQI!mMDUifY?6|YH4<Hhvtl_1pJQwI;4Hf_-0scg5`_#Ee{
zP>xYY>?yDC8b<$aT?P*5+O5AH7<}%uhC$~}32OEm@PN9eTfYHax(<Z7CK?kgcVd?>
zmO+`*t7B+L0E2dUDSwVXSIW*&=0*3bulB$AqMzjjwnTLn?&AXRk#<=MNrO~5<?2yB
zhWms)UN|(bf1e(kdyG1@-2621G}b@5bH~V2b9+sh+@4;i1U`;|K)}E|>y233qAKIU
z7RIHr%~wRNkZ9Tl`gQHvkN&VWYoj^t3wpcs>(>Q83Z31`+naq6z6q!qj}EbY@;z}V
z5ZnD|8v#gOsg~{@6NWyCVZaI5wW#e%<!Ol_6dQpJ5JMNaXcR6%5!)C-WR>yrGG0B;
zQ_**Vum1`C7mq%3Ktr$m9xp#JBqJjRHlxS$83mc|UpS>-Ww+7CAK!1(?3!MaPV8UQ
zWqaBw@EwHwfiEVd;4+$F0m&b!-DH&H;1yb722i_F()tYYlzGna`_IAKpgxW)<CTym
z01#K<+yPWQMAo6E>LCN>rsWAe0nbc2DW!U&z6|-I9f?lT3W`!omQM?E<P#G?87y_E
zcZ?m>F*jp_u2uMJ+86h(KE8qdYE_ld9@u#G1^LODxBaU<(@M+Rcd6=sk<lA@9cEui
zd3vKV2RR0Lk|(msh}m1HLXFXUVz+K54(#3?X8}`YNP$>H8ZdzD2epH9oKn$_hhqMq
zk~xz#>qP?4h*m`bW~%v|Y=IhdScw)_nb{NUdUV5X3guG7^kZ-FKj=qum`(F+fsfS@
za@U&Yg9lW1q$Pd9krSd62T7^<DONO%CwwU1fLaKw3g>p9h7Y@hCHrE9va4TI1VQ~C
zkQQ}&%vu*@59cF~uE?}iSa~HL$?oK*M60f{vH?;!sL%(B9^n(}ADta-M6gbYawH%$
z3UE*!9J)tIk|=Y6HJyy4WA#dHY+KfJ^vcStR9?^PQ?n{l*{i%Rr3x<mYYZubRVloV
zy_z~%T(3{XeeBiH_1EY=UWezf*X-1!rP{ap2FR4)L0F<7`Yo>Bs@L@I(xpHBv55r7
z623&hv7BEn;JA`qDd4!AEl<@ui#z-E3!Dmwmg7!>XnE+4D+NTC<2u<emeKq$XpjyX
zK!I9Y*(wOBsP=7Za18badm!WW9q$9JfU(EY-4H*-4p+cJauM=6q{AnsX&64ikKnNh
zII)K4Gnp6`ml1_T6v7=5s$=zo;Qv6XEFy4cD3wYE8a+s>$S}bap1idOj>%;<%K?RR
zBukA6z?jcjpdTd4)HgClgy+q?S+I&VM$1kk=Yn|(Qv~yPV@PUVO*M8jHZ}^8YP1@_
zJE0^RiomVWY5?yfZK5Gd?AQlr2)IK3A$vvOv&i~!VzwKBsD+;(GvqPG4rt#(?$~nC
z1L&KQQRN~+rc`E<bS(#x{48k~?qfK98p?i+unX$9QeX*3@jz7;9z;X#O3`3y;JO5M
zf}Iw!69jV{JAr*vE#eVjFOW_Pdr^s+D~DRcB%T48*9sc&|H;N45PqH;o*owEO<ylT
zZizGBL2}lKM7)kBG^o;R^Z(w9TV2Rr>*!^iR6w%cu6H}4EWQz8QP_nq3Hypsm3Bn&
zw{W?iMdq{O&3x8;qwzGdE)99o10^S<c$7utHmkW*v#Pd6RII9@&nO*5)vM^B2yxJY
zIPyUp*&sP1U`v$md@+CPqmTF-tmh{mv7Tc%fAVS0nfBxpOkD+N5B-6cKmGu+e;mTg
zA;~g(3985pXqHTE)qL~`>&f5z_$j7x{`8YP$h3ac*dfs(H6~h&!Mm%NF(=@oeasF!
zG4`u%z}7fOZV0&}tl1lwi7hxcc{vNaCoQv4nMxx)ycd2kjr*5{{TNX<z|8xHg~vQv
zSXDE5L+rDUI~j_<!~PvFM_mp6Efk5$ij{d|_txL#=U;ohtPDSw!VG*1U&;;xk{#p1
zAl<Y?y&7}jb6yv>H{tk2_JM*4F?}#^JSmK-ULeZ|OouSM{u;FDHSzK~eT~8MLtK61
zHAu{>^zzyp^cAX+^f`RpN!lPYH&!~d!lBkD`2+8OtxovHC;C90#}Ma;bAQPDp5zNq
z6*J9Au9c5{j$qG7(#iin#u-@B)aDGwzx5?a{Y>5*&yc+%PTrzvk#PIPu4-)Rq>W^9
z{|DVftH^nxRxAA^vceqy?r?N_`}VhIxH8+X>flkTDip@r-;tiIj?XCQU0Fq!Jaj?)
z{#;!*cWHK7sXnyKk?yaq%Egy<P0RGFIyh2LE<q{oSX!kzohmN3Z+aT{fX1{h^?mId
z<U(0BO=xjIOyEKXmC5j9o>&VqX9n6gIIMilQ%|qH$M1iB^Z)(dz0dJFYd(vL4r<}H
zY1m1*Ew~q-JG{1d_IZn6e>XI#wf6}Lmh&X6SDG=;P&yof)#M*bnrYuWcQ5th_itYF
z<Wp<V?^<sV<D8o8Wh-A_d>(pGJD`-wj}J^6ciOqz)FNy?x?4J2W`Fwcm@A3?tTwG3
ztnqr*c35tmKe}W6HMASJK7OZRn#Su70+4{Zw*I0?EBb5F<C8VqpWq=fJYf+M_9ALw
zm`QF{8I@RG{*L^%!-pw{j1`M|8^uZjrUs89!Od@cROC<9l_f<*#&X>*Q#n-e#L8+j
zbB#qFTT7Hz4=DV5>Xv^`iFN{z-=le;tx465<wZrx63VeNK2rQe!FLjHgyNoywQn3*
zka5Z^74!1=@@B3u#FhV835;fx_M(J<Rl$UPCIyip%6sG~j1v`7B{<9*tCA`qc^3&=
zV&2i&nIf4Xj-Hr2d~(fZzbURnu+6B1c+cvmg|?{G=-0dL+|$NQdw_pNFi2PfM77zA
zUlTBYzU|y`r%l_&Dqyi`{WMHBuUunH3_(~^#fm^8DUZ?ON>Q^>eal<fR%!-Mhx!G3
zCM0P*xD!*=4tHYgV(A-(yRDQqutC^w{39W`F-F1`CmYaX@~BO2`>d6&I9#`-4#QR^
z8-V1_#@h!BxV`bt2uo>MOkpVdpR{DjN&VxPOS|cege9&;iKin4BJ~C_w`3#CP1`te
zSL1C12Hqy1i#90HBgTLsOD;cY0Kg=Ba%}VadI{)~OA!pJBpcQRa8^XpD1}&#9H>B*
zFU>_RypWCFwZS?`0PRk{ks+mCIS3JYN!f4Y3N4N4!}O|-V>p*oMlju|i4+!U^g*?s
zbLH5V?_CQu!(ga^!^%Oa+(w47PpZ6u0G*O_IUJggfP<T2#$GY5nI4dMlQA&+6)h9n
zXW>67olwNy8#suM>QjFIuNd>5#6Wkkdac(RxDqH{j`xSPF+yi!`@vXX`n|%%pb;SQ
ziuMs`G1Tw(X&K&EAfedZ;!~D*eQ0@9;8C-E^rNl{V*4TWEo_6GCnC3^Wv=)r*wFU+
zZi#p}>#vl0OU&@CZ7lm{`9~r*M#vsaur1Fg96li_!Mb{}6$oX!M7B7m!_yQcgT^yt
zhKCE1Vc^t8QbKsDu5FgN;N+*ghjEJXaANurYg1ym&RP?+_a&0SOHz%4G-9%!MBaC(
zFMeyP9+-s8@69w;1|HK!7Fl>f9>sbXX?Qd)qEcn7uRuBQQCP+C7eoqt1bUPTAMGhf
zUjaC4uSBfNS$N9SdowHE^dCgrCa#YVj|kcwF@6Fl9!(7x6_JOZ4tgMBDX5V+LPk@{
z4ouhu?9xsbe4feX5$X9u{2}2t&6{bb(VRIZ{{>n02cH)k0}MkY_NxQ;+Xxj1?+bX(
zkq)|u2&&*d#TLLOYZGGp_?#o%B!leJl8BkSQHaJV>=c5JH_nuM13(@kMgZMf;;~;H
zD10haF$lci^ZQ9)@E=RMv-t~0SM53b`9acRi7g3T)0%eT6cNnij^NB6?S{OR!2A?C
zv&S2FRU4Cn=PzjfLJ!F2VF6)>tl%Rknx_ZgRVUMFLHcoMMxmpG0uR$sLfYCCSwmxf
zv#NcgUjv$$ey)#EsR^ICT_Y4iWmGhyKx~wd`7SJ#<zNg4gLbVVR;=Q?1e?b5`vqBg
z%d4!nAkO`4yuwdjzI^!yklB~{8^{5vG5Qqw(=;_jP0`ZeaQ0!fNTGOLd6}*T4+jrx
zY6k1XKjoiES^7ZF!8#PkCS^(bl{Rc?y*Y>AfmO$G?>Jvj=}d>}DV<f-U#RX6mc!J3
z5zNJ!vy)D256p2284a}?<yB*#0twy32R(<5Y!59yvrjMu{{%f~*Cjgw7Zew3*VBS_
zFjxHoN067R`^~d!t$AQanj;CQ)#&maf~e>Q18`10NGd3Ll$RYPs{MS6&-Y?85x4mz
zulKf}6@KFzZ$RFaV~n@O^uUdwtUsm*|G*gYtFFvoZ}1vnhot_Cet{JwuTh~B!B-mH
zk7J=7uEbX60VkE;HhaCV9Hril?(+HW{*AcU%syxaB)pMdyi@2sA~?odm?QK=&t*cU
zUsU=P8K?4r<Rj9&7q*tpt%h`k<5}R9Ip-v<MO#Jf8*czB<XT5awR|ToMq5O&i<kch
zU1-`8Yv`d%G$(mM%)7;@*@E7oP(0CD6ip1xedG0E^&e|$DRhMp82RrFp+10Pyj~C+
z4`bV={u1|#<uAWL+QP3$xf|4_T!2U$Zq5O%p4Dq(XMCt%umvhG(W@+svEac$7Jg#9
z+}bh^V@J+d9>yCw99LNAU^*IS$RPR}d(5$`)Rt9ZS!gj*MMzVKzVZ6A=xV)_2uBT6
zP1P1iWRF$Y(@Pv#dY;JV$+c_^+!I+_T6LqKqsNhj%BQySCTp~d0&C8+RZ6Wws!%Uu
zx3NG$VwVaVe~Dv2xJ{FDB18hA^r1wg$L$zEbyU;Ls;8d^M4QT>P*D{sv64fLjxlyq
zn_HVt)*ID&!6)I_Sey@2CnAa*TDP_qn2l!3uTnFJ1cT`%&sy{aEl`6LHJ}<DF0qa+
z*7)o#CeUt^AL?4{s1%14E6nOK`d!~hyE1VX&kO-TPzXL)c?bP*BFjnAyQeiLvuaLM
znVZOJH<-QHi{6krVgo1mCTi<qO`2m$FDmpv9oR%}dxc%6vQ3i^Y}g!n<y~dfrl<VZ
z`+V2apLrW@MM0_!^k+8s5?e?0o%n^K$`iyVls_>t=@gtNbvkx(VWvX+w(YpcZ_+Zm
zBi>A0BHpAm$LxuWI^GDgauYjx2ZkYd{2`d*!@a@F4~Zg0X04(yj*0FMw=HoE<7?s!
zJIto&J8|A*YElofQ+EGe#shqv#BMzN0L3EHjHHrKwJV$G96M?1hIxx;%(!gs-KUhg
z^um%!Q*NAp`Hbm{=bYN;$#m+4rP@?WhQ@82zj*wZG2?HjnOJ?o#)~ea&r?TLoP^~+
zVYibm0Ze%UCXsOyhN{4d3$z549SyzIQl0x-1u%H5b+5YFRIa^=AT|DBsUM9q9|PV^
zNfk-mAUS010Wd|jTcBK6^{vT#i?{1LTZP`+)P$1E4sWYBYNsbesskza<%xbKJ2M}O
zvQx~_dL;G6X={I7X6%?-hVU=Rk%g%Bu7B97Tp0o}X|TXAb}Dcv#K}CJldxGF2OctH
zJaqJdYmjks>k!F0PU(Wm#&Z$so$t;~cieTCGkxw`DJkmrr7SI#m42_Lutp0k>s=q>
zQm4F~{@{b@?5)Xqa$1)kQc`~CVmxcvQA_4$2)gP?l}T9sv9br-BuQ<!Nv=1)P|D6y
z9%xlSTD?K<<A3#4KT9!gOC&1Bn~8oQ8RCY%Q(p~zISKl5Mw>OJ4S2>At~TgSs~B6%
zwBGe$iSSE|xlIV+6Yx8cr?pS`1Y(YBsX`<M_(t(65#=+ZV?8luQ1lJ4z0iA9cBPJz
zcG61-J{_G7MgEA{w{<cT4Z3mqiG)OeKz&E`6@tNpNnPkS5ad@XFze`uLXckq1QQr(
z+hIRoD{0<wEO9;_-fdvCzSClb_1-EEH7X4zeWw;oT#^I!A>FxBU26JkbVd(lL&SkJ
zVxWl_J7G%9IGKIj(7DnI_gn9QVb+ktS6H9eV(U}*TG;Pn)6Id$^w|c6N;X*+U{JKA
z4eV6sY}4m7z4KT~$HU1v+iOh3D*P6#Aj<b(JL{A6ZimLADd>hiQ^(l)JO<T16VR<~
zu%wQ$dbHkSVTrvG4>~s82B+}H_5ScLqz0J$jnA`qG*WH6w)0ne#`2_%`>juE*Jus-
z&|<G~zx7Fb#~i|t+aa#m+-%Fwx3M?LY4i6f3!Cy*2Fg8t@v*Q&8OF#izu~K4z1JHp
zEcn*gPs)Q9W&v*fswvhr>pe7cuu!w!1&Zuu6X75#vP<QZ<01AdpnlTdz$0<Syd6?n
zVH1-~InR?jx@>zZ^fjT=9Q}y-%t6d&J;i(iFK7b_M_4B~Dh=jojmG7+=o2Ch2F|cc
zRnpC48s+>=!jfabBIeY#oJHC_5vIGnj-9?1u`98IVnE;pv4diLaq!EPr%$|U#iY|$
z4i5tpXR}1%=~u3pIO(dZPY;12=8}K~{+CCbfC=q#Vuj3EE;a+o)N}0Tra6k`t%I*I
z)S_!NO;HB+AD`}4^VIa@>dvK}`ZL;huJ2vbFrvD*Iy9Da!LG;RKmGn8!)KI~_c@`m
zc-n~iUcRdS?q2DYBTnpG;j3z@ibG2Eiu!t3`Uu$la@S02u#43iz=`$p==98deM%zO
zuOToWkEMG{kQ=)IBp(}x3y4*1<uf3Q8!=*u4Dncc(&%Z0Js=Bfaqv9EE?3)#!|1aE
zJ0NyM%^A4}mTDWbJ77h`pI%txQmS-+JD1S}dE?_jxhgv4-uN(?;ztpET2Y8_mMq1`
zESiX@C&?LlE7S%Ac4VV}ZDVe3U<M>F8&IVA#SR^$3A9U96vg3c=hux7U3@~3%lJ_B
z7bh!Kitr00o}_cA{?MAvMPWU`GG;X`qpviW1DLU`RYH)jV$t4&$->%7WR29lFr^Yv
zC0K32slM4Ng^Em2`H6N)30W3!ZG%h*xV)AG*ld!WejzOsvCViA5(ve3G}fB5Xv~DG
z35%jOu?g{To3NWvJPb=rn0Dc7l3o^VT9ziQx5dIQp)oCsl?9XIxOgzdv*l58b&&-V
z3N^K)R{CoeQG9KctN1X5WhfDy*u54^>fV+q6#^<aqIF6M{}{E0X?~r9EC`wh#*r%-
z13}&`66J&;r>QCuaOJ59GMtd;S4dvWka+C*=Ulatk6W~8?C|!b7filtCA<GJd@d<X
zbe+8&$IL%|`#IxS$;l^<IqtYy&l$(RKY7rYUc76Zi{^Yc8qZk0mRVAXFli0XSo{B%
z@l+4T84rxkad1k6DB1A_;m3$vuy|I2ye*pV(B?5Y&m(r`Atr(Iz~gYsYrOPWT6(2>
zBFDB1<@iVG^91&;w?iDB@R$87T~#^h1O5J$$(48~+DE|@U)o!ODVDN{V2ZmhG<ZiW
zP_!Oo$^H59rQXV!3!eoWsQ?A_X231169`pWw9L2EgZAQKuy%?lrg_dt94eEnT)1M+
z1-sMSmFZ6m9%$*twD}J`kv#iM>+6LpF1TP9-LhTWB2;GDMGrmhnthhgptzc1kg5zH
z-0)_4Wmej=A(iR-_<Zd+OMiwpG`yZ(nVG($g!HHv9_YJ$o_-vCkvxo|S0e2}6w(r|
zPX9Z4#Y({ch+c6uF3|X2(+le(q=&+;(rj4HOJn?Eh>p1?LRu*!9^nx(JR0b0eOjtq
zOm<Q^!6RC7k(JDEy%z^ANY#8rT5{k>k>BCet}j+sbXD1i<PIH@*$Bm7=0qLYPn<hx
z+OrKW#`hhP`F6EysS|sVe9kgtDQt%)DAsmjVUOjv9pW(TvA!zJNTMOLV7A_4vD4m;
z10AX^n!pD)#X$|QQ*8WZjAwZw+A|=&X16J(A4U(vcP2~X>&YPgC!liciw{<mNLdX?
zx2Kerrm*dbzrBku;0s(|Cko~TkwPlhxMJ{#<v_?n2~Cq~NA@RT#l(&W7?JFRi1-4Z
z6#0{Nh)CP<(0Z4q@DXa)ViyieUhQfRaT$?f%xMJ?;)i8td&ua0tb`QMTsG0L8}DG;
zc<ONMKW|vc$6t2t*vainr=E4gN_O93d@d<HHdgxL>c!XBKgLR{`<&(Tt)F-r|E{Lb
zS>E8sabz&kXEJe$$D0;$iX}okHA#q5TlMArSfm1L<7tlFUish&Ca_oWY*Sdk!k^+X
z2z(&hCF~R6hwxe2Z@tIm3m-*HAoC^6RB2ZgX3AJ?8G<N#6@opMBY-Z({)QnAe~QNl
z*i&f$$il|8zH#kU;7O$Pn+BK+tuVm+;{>o%ghj@E<H2d0@5kqYg|VDh`JGM~5pXLN
z*@2%lccEWPp@@LXiHHEkQ>PPicX!~Y><Yy#=k6&Q&E1_Yzd9FSk4r8saj*%xzrD`i
z<ZnCq4!_DKI8c0-->36yN|X5mFlSEGo~zc|`*nVwgFjp1;P<I`fK5=M_!7d+f-*d|
zg|Q*X6L86fy@+tN0Da4tYr9&5Jn%tl*aJ8Cw9Vc0wfdRZkA)ab*r!c|gT6L9FavQB
z#ApyBp^4>;T!aZJf`TyNkZirSINA6R+bR&GQI8(=>om(oewv>`D2Na?xnlb?<=M<$
zilr>P`84#CjTxBaFhz&7Aru!xyk>nd;?{~%m0avsL$Mi(4=D~sp$s$QqjZ`}hwv=2
z&eVZrL$Hr9wa2C7&8#D_uCao)B4E=3{=trBkk+_A9wEdyABM{#;cAr{wuotKlnGW_
zpteq<LK9XIcR&q({Ux!E(^8HbrIgy@Hu_r20$T5}b7uW!%W5=Dk2CQCN!r?fJUOxY
zwcca>?Qs9W#yFEytAE7K9A4-|v27=kiEHb69w{xY=u6P1FMO!&OMK-q=@SKCq|8Kq
zi$^EBKG{Dbt{1IaAKG<mqWy~qf<`ME;G;R|eORY{3G38irBX~BTh8jBfOYiJL>rc$
zkBuW>S0-}hj%LIcxc>~^IAm=-)dWsl^rD8I5Z*v-d;z6A0O^aCAonPoOOn|0jHPY7
z37ft%k?SdkBA9s^t^&KYUWJx|S?~JMSPu<ZhblXqR#cS64kK2c!h7%@Deqe9FLGl3
zA|A0c54$_zPl@rc+=X6&-G#sjLx%;w^&St8VCSMVo<bO~ci1~A7-o1%n$ahO2#uk%
z&PD4S(ppA}a(c``=3?aywmU^LcB2|wzhs9$n`g0~X*`qO4qXxJAFMY<@eEq@U|AX#
z9De>WmA@Ve({|CUbr7L<QE<ePD_pCrtF;{ft1ci*cm>3fj4>9q%8cD~js48Cvi%O6
z<&zt;5~3L&(9q7s=8+$N#`vr8f4ijpzS()yteJ*AY4M_WBBwZN{6Ngsj2$?S#wxb4
zA@-Uw+k3?D`J8IpD4sn#-ddmJ*MM)*?;)Q3P3{R05L$WEf;9COfkZYgf?wdGd{uGo
zwumnpyNsQ*LdgO=xwx1e;X18WDZQ2B=qlIQk>X;W%mRhi@Iqd|enOy;rSsoafb#1B
zO0+-lE8G*6|IX4Qt|{q1{P2Ut&y>5Y+H>)!81~n~erU>Fv2<$MA8UBx#XXhu_$EjA
zY=<2cfW<A&rpgj|_96bE4t5qY-s>C{w`3HA<K%^Dw~kpF_*yGlis};|@IMN}yA|^3
zz)6;}muK*dpG<z(+BfsQ6?c}{l7VyHn8Te_;HVII6lC0TYg!?^!S%)01ioI1)&<yw
zERA)6Bk#%=I~mx)y(k9qCt8;>Im2wfgV@a-i-9!+2|qL^0X{boajgZ(L5YzIknmaS
zlIo@~rtx5j!8X#zz&4e*xZ79Z64QZCv@OB0bHh}jx@S@cu-_y`y37ML#j0$Wqu2nF
zr+$tNAQkGq!YBzc_oQIIiLKqRgfgkyk#>hPMco&yK+68-!8~)FKOFrIZ9*Z25+5lB
zPv=AZ4SQtde#l5$8-m(497IN`ZSY%0KRzB<0}vss=spu;Wbf0|w;0^4J`>=G7{8Sp
zPI>8CGtSQKBr}X*8{uvvL`I8Ol9qi@8!x}WLzB%=(AD}xDd3N$7cLt&VTq4#M-I5x
zz2(C5w`MS3IQz}YJo`U?yYz9(mrd~b{d3lDm@QMiMAD~4?~NiyS4asQIsB^-9hP}T
z{sb+%P)dTXQOGU~4a}rFPc1qB;%)p7J`6BC!7?7YXm+uq+@DstX*=J?(s$finP$<X
zylY<e6O(849O3tms-Ahy)84B5y64VcQqz6;1<%y*e-UNE@Ob17xAHQP3n8a+0LEKk
zrlA6mf_yt^FgxLgzW?R#+dHEB<f73JvPFFOEkpg~j`Bx${QDQCfiAMF49bagD4RF?
zTVK~S|MIh5A27V>l9^TBz30s>D+@MC{tz6rK1FotC$*<dbg|YHB)hCd7O`N}CQ2n(
z!)l3gwec3S!ti^{Q#IN^$Hc(5O4$T(w@m4%B{<4ypn2)bLKbBXB#s_$vo!w4a%ss0
z8`-LWiWLcSypgbyoYso?eH$ojt(=6ExXm(a!Klt_S$0hTP5uj7j*zPhZK7n92t<o9
zStgvw(pJ4UdMr)Ps!VU-55hLw`>}!D;>ug{62tk_e8R`dQg4e?uQfLMufTF(I;<5o
zpoczMV+C{+IC|vy1Z}YuZAGwkiEj&TEpRI^IgCvtVrtS{*q(o3O|BwoK+@T5<lcXo
z{LmKbRF^34A<=dAZVL)k``BN|7YNhDgY!T{W_)Yh{_nCRTI2s;riJ=PLd7+T+Dr+>
zCL5^XNLetg>UC)O&60ii81@XA|0+SCt#b3f$Qfu+nv5s^+r{uOZ9PeswZ)?Uze(7(
z$lw2frY%TiVCjEJP>ey%e>hKr4^<wjFDeFenPVHzwG>f<R_<}02A8gQ_C*izgZq8H
z{m~w0-u6wEX~vw^@99wGefpf4)uW=E(V8XaKUbIE!f#@(Y{QFmP#%pXmK#hT)#jyY
z*n8iGdz`2F_Va@__nGDKeT0mO3d`8<Gv>5@4}7i&@48ilEM(0w75muMYHMWOH_RG6
z;+!mavhp-DVL7nTF{<|STA#7~$c`6Y*l|P|fxRs|KEC_@`|ti(8RFwf1G@L<-@ixK
z6aD@z+YTMtw#DyXbHj%p-mr%KVWuU<=@)Y_hvg%QI@xprFA}po$QiI_l<RBJqk-9v
zGDP-h?7-&{fF#_n(qQXU01??Q&SMYidw?(1SZx7caxd{0v+GC=dig(JU3cS+>t1Ci
zz^VD?eV1N-`K9-X&-Wq?<UaU56R_F#bgweUzx=9QyRKU9_s_au^X3a?8GpC`?B(~0
z`A-BqiRq9S9zeqXi8@#(NJ!*oK!^?^;L&nzu=oL6U|~FXJ}~KH?O7qwjw27wR%+44
z&}qxU%P(KJ1$6SK@R!+fDV13%d?(+Tl2w_)j^i(j+Q5BSAJol_A>6-F<@e>#tvl&a
zcAU7Cn(C7x=aF`}6Vnli8!gt*Rf8dVN{B=BY!&Vp0teq}4R9y}&4b<p>@$%UOnCy3
zN=$#vT~neSR00l=L`W@BbFDnwy$OXgh+VO&!>b)J)ghopNhg0G6su?np2U=m3r~oc
z(ZU%GPw@UI=?v0VC6hih_u2uS^~&|T#8xT{L--T2J`z|fYnElbvs0stmY80db1ZAV
zYJ;OKw6MdG$a-1*Tkq<;C>s_K8yP7*PR7hAR`CPqfmw4)HXCtAh>~p~32Wn_1nI<N
z88>0oBED$uStCy?F5bRs5nDMAAB&2wj3&;WYtB4}xsU5VsaLOSp6CDW(|;1`Dhge+
z!Pk;)Zw0<Y<Vpaaa%VKvj>ZF!_}Bn_(?GvosBh5XC?L~hD<VB;jPUjx^F+VKSisOo
zaZK--WBJh$CslPWE$NBR%!$wb;*vzy+4?A5Jv?Xl#II_P8QQ(qoM98btnE3pD?caZ
zlBqjUxV9v-BrS=sk-SRutIcXgDS9HD5?xp8qV2#dF_^_g){23UehzAxtE7{Jt1Z_&
zVdx{F?Py!HBif=EOB2NbV&HFyQ*DPokrH{^1b>VrYWiCu__0oqlm!2Ojd`jR6)=&Z
zZEV=~^mLx)J^H$edP%{@eLlz8UTum$Sm^hAwE-wJ74fXFXypBw`@MVS!B-AGj>5Mc
zkG}5pI?hJO8~c4wN0UkrlD#o~*bJ()6=e@qG(xjq_^^=%Z;bJ+^dUozYT#FOuk=-;
z+q7($K%^kwNtKZaz52SaM@nAk7&yVkw@N7*mTsuln`|b$-(caI8%%w?S@_!-Nrj;b
zkm2z?JXj=z+ZrQc;cq$%;{%%>LLy#&QJC2JON3LXzqq&su125g=@y10!(-H-qc?O=
z)Yxrlq)sf~i7jU$cS6}6Wg(3oQD#JpOA)Xo?q854%oXypOc}yqJz@Va%F-ory|md;
zpd39Z3fNfKTB2Lx-xAX;5o|GZ3#@JxwwCCY__xG#OT^O{x-}h$BBaz)=K=LrDQ{7_
zAHg?E^2ruO&oP|`6457^kqA1PK-njEY;iPj&_8L{2tJHRCUm}Xs^x2X?x91d5CyTW
zVWq1YVFkb`%qJGa<R{vy13OBvKHs=LYjf86#^>ea<dy{s-TYKcJh!<QF1STr3*91T
zsdNk5h64&trCVqg=3lVz>8BSi@cYj^`$oV2#<S0iy#n~BBC+S+T9UQnSJo|ueqdfq
zIw3z<)p50d`~6F=!OGshuE93;dmd<Ndf*-uzGl;2z4!4T4mwn?e*E57`6gVMZ9Mhd
zb59u{k=2KufvQ1bMKWO@^|dr)3%Z~h708hn+2KvM?E4cHH~RW~hxXla(>3TuiRhT)
zO7g+ScerUcga3K=j>iv1^p9*G@CcZZEsTR>J?#}QWpO+9`&;hvXRr5X*`bm&s`*Y`
z)21fXnE7-H<N;f;Oos%LK>g5qXF-mvbwWuK@I;xr0!QG|Dlv1b`MSnx*W7tz-9;l)
z3o7-|XN^0(vN+A*sJs8L-~V<>L6y#bX0^+5($u`-O5^g!Mk!-7jT;*u>2pm^rOUOt
zVdEVabS^6?`F$zd#=b)!V=J5Pu5`M1d!AXyMjTV0-C%smrtmju4#tv3VT>i1+vAIQ
z?uiLwwl0CRVAD0eYR@<P>dKN-Ejc}V8LP#pRJ$xYUCk}2RK|SE*Ru=vbncj4(YqUe
ztU%odk07srjqKJty8->2+PqYGSx-yKLVwZG7X?fBJOyG745=i?B`B?Osi;GY=WzcX
zWez<@Q60%WQ_1u_KI0nfEL!FD>ivBPm|2Zbf8pnZehR+><j1KDJ@H)AKOj&zP)oVQ
zM>4|>LxWPt=b-veyY;b{K@6oH1qZ=Eam)j;uDT~xA)tREdeXB1EG(tiAzdo(NDc}8
z6Z89sJ|7$0f9B*9Ycn!)G9B$YRiE*|i5=!o>D+HvzbRvScg}L>X6dSuzyAIK9mihU
zvtPcq35Opj69M2PFWWz@zPf+^f^Q0nrguN#n!)8+B?X?EVP_muSy@@Iy|8^=-sSW9
zlx1ZV^f=zw2V}G_utZ)C8q9BAs?7n-!CRt%sne1MWP(gb4sY5VZ}2iAgt`)JyDap&
z7X=?tbgMta=m+rV5BekBmUJ4UuSM>0yO4IFWuinxJs*7xHOuFNO|TfsXQ)0c8*KWA
zjnjY?_Gk{;E3jIVJhqnx(&nI&^<}U&E9I+biaiSM9f!Z|BrtZk%vuJbv|%J%X451M
z(cr}aGO`EK8IlpgUFeKO*9h`T&4Hw$zzZxg-$_IuFqO}|7@Cc12zPoV(i*Es+Kp9$
zu0n3rTO?gY9FwF-q>e<(KFKiT-mU{!s6=nu!ipf<#Cp8cA;~Kn{@^{D4eOIlFNBVu
zeF3`A4;e5~q;4T@gL8zWRtoEF;Y{tt1JzWw7;vTTMFK5pOnL};u<3ndySu%7Hqb>3
zg<k+tCVTZNe*l%uwa?_M2s4@dGTVx_1s2fyZlQ5>uA!*9xB*;)CVl4f1-$YVvV~(H
z^-0P<lQNTVvMX8=k}d*z7|5Nq9%z3xj>qu_2lp5>sE4}8KPEW1yqpHgEklnvW~lFS
z=mN=TL^~7}49SkCCnh1~o;*m-q(MD`g8_rOr^lc%<-x(~Gv!LdF+=%8Xwd@S&|~~#
zz+0Box%qvik2)WI66lo4B!R3Uhp;OZrL2`cDX0T~YkGF4v=9CMThg<A%FphUuXq~p
zz5UK~Usn28?AWTRJ$I%9zH+`*c?7X^I{gc+I-IiAZcLo_2?$~6F!h2htWzGjXOZ8(
zaPx~-t^DVh^;4#-UpIB?I_>t$p2-R<K!xYknSWn&)eHYvIpw<Rrc7P8F1qc|8bH0|
zLwgq4_CHr%_2TA*e*dC-#!$P|e)h_Lyl~Z`zh`QzVdNHMJ#!hFor>m(u1SFVJ-}Uv
z6?Z8$I91#Vy4G8>PWv&%%6ne^{i1thKV<5ZtGo-WuJmX8fxFRz)gv6KrnFFZp#4Qy
z-ye_leVXWoh2Acsrg(*<Y`mA_Xd6md<M(2`I~~+Vf-*b9i@_^60;X-dd<ENK&w?Z5
zE1D1GlJ}*)#HeI3#V0?2CzN7Eo)mn{o&^>~%@4#ZIHmYS<m*@W^!tx}v)=FTSsgBC
zNf&#+iDA8GwN=wn`59^YS-~R!t&3-CS>PuywNI8+*D?#o^LT?Flx;23^1+UsZmY<p
z%Ced>v?VwviRz$1igckZWO3yP5&215LfXdXg<s!9JfM@;d-T)DcZj^8`&P#f;B$36
zx+f;T#RbO?VJ<{-BFqiYUmX#&y@Ds;P;k5bmEcj6zHk19?bfy;&TpO=3@(^)ezzrl
z$N;o|X1h=9N&)+>Cq}<(y~Uwt{RbLfMSqZM3JtC@vCmuV@+K=3y&;1r(3WeiG9=dr
zpC~R?htY-s0~O&Z-M(o^ak0LGt~A}G&!j7VeqLOhTtQckR5?E^q@8)!QDQW^juN8z
zP5h=*7-3a;T$DI}oGu#kjrpnkpMF&pwaV3x>0)q1a73zD7m2_D@*G?JsEyZLWyODf
zPLMf2JW@rlCRY?28;YBT&^3K#(@k_u-$B=cPtY|5W%=ovI;@y-JA<7GFm=1SopQW`
zqDZ?joUSQrm9=!u7*1I6xpa-qWHUuB_*`VUQoLF2@1eR$s8~;uosjM#TRFrT@lEV3
zXrYdhJ%yP)7}`vbpr}$*g{8Rg#nL%4gE{hB)Q*FgnoIV)X7zofcDGn4hYz*oH%q-q
zg8h6RvP}E8FffMYK<p_ENkE)$&nFu%W|UT9zXM+Rg^9m8%3Q@q7IyFCDt2B?uW>(v
zRxAs()RzDj(_Y21QsHZ{_KKh9^*V75)RCc)??9Bsr3S65iD!#gYF+;WOo)~W*;~Z{
zdz(%klR2)s>3Ht^Jk?!;iHSQG_0SyThtMB95x@U(a#QrH=(TB)epPvS(;_5mqb=T`
zI0U@H`x4fywYK=*sTpTJy&n15nO|Oh<mYnWKAF#T-lK1aehdSLYh<`h49eXZ4Oyi5
zmeSPL;F|O?XeFk+rx@qxjBnhQm)n715EJ_tJJ4;;d%8@iReUMQ&VMDRq$LM#Ps_%t
z>>gK|HW`<k<*uGT9{<Cx2};4W&wVm>*_zb!z-=z)a}M09O-aknN?ntu-^wPu^4;=R
zlT}wa8c7b^mX^XwU0K;_+LYwfR5X&D;;Wn7<=RoXYf`ha(gU};QmKh#ZE9NTnyW^9
z6pf#`ZwL64cNC`p0!$f`%B!jFNRvmw5cp{nxyEjZ8iD!=f(V4B7`X{e9JKDd$Hn)g
zWM-!YZck22Nfy8;wNttjC=+)5aQu%w31(-qHaTs!D{xzS>Y8O^KY4C+9sm{Kr=>Wa
zbB@e%@o!TI8$4d_Qj=d@{@p7RSbmqub%Jir)Ko$`C)K4*P0s>Ja!0-J(TJ<oq^1RK
zO~&)l_(21D(kvG|17`9t`0(Zu6K)bYcqlXz7L#PbM3W){YpVSNIymo%!~_g<vG#;8
z7-&cMS`(|lZMY1mT-p?gF26bg6Twy&D@{qmopyv5m`G_;2`TU}aI3^N7C%eSq}xa?
zRdvVOT**TrnPDLm{0j?lcd_vZcohh&iGReo2uX|(Sa1#k%i6nUOQ{4Sgj9|;#Z{Z)
z(&mBtx7kH8KT=|Wati;}l_{h$aI2Kc7ff;0rn-b}z<ky1x<b1Q5sewb%EC>Qt|D^k
zDJq8fp9uK*IzksaAv0eFH|pyuNFM8ZQp6w^lTb00uFjVsECe~6xX~wKna49~ks=>r
zwpz;IX}Ye+F0S2t&6;I6;>4ArRTKxCiYv4fm*z}f#`kS5uFa<3SzhRO)ggXQO<uO<
z8v1$1?pvyd`h)ZQL#uDuEk3J_^jT@hawcch&z=88IxA$k?b`AEg)IGx@9LdyXO{Ts
zJNkw1Z`Y3H(l7Jpil0W^S$pm-pKsT>wReuPeI^>weADe*3mR1th1yDxJm*?}FsBu)
ze(|%#-o!A9wJw&_hrgt4(O)xnOGt)bS}vFaBT_?#ME-+>i4apker`dowuSJ-JlN{N
z#5GJIRR`rUn^ivx!70gWaVOP9XZKkB3;gMvQl|sqOQE~qvO*G3i$7BeFy9ptp>2sn
zc(BCFHh2Z`uWpgyhz13{n7N|=@Hp|;M~Su$1Z}nVQSkg_tKL?_-A3~qL!ZBBh1+as
z+iFjv=p+0#F+8`?YPQudw$=O*JYgG09@hWL!u{7a>_4<s(kAtR-?#;Sn21ETrjsIw
zm(WfKE8VirnkFj7fP@TbYD>C|U9^^Qk1;Q>{n&adahl(Jx^p$+`7nDp_1+wZXv854
zBTSnWr^$1RaD{VqyIkLm<1<rJGsoSS<7<cFSnJM1wt`>3!GGTM$xh$Rg=xv|lW!?5
z-ZU)PomN<>)+|xz5Eo<j(i&Ch&U~fRxmrKQjMGr09uqM$2r5jRWn3-O>RgRpu0PM;
zbUwP7b>2Gk(k{n$<2V9h{EfN3cIxlwW~s3o-6)w$YSc=CVc4eP;#*Dz3_>2mc+z+x
zaUrW3HmYHa$*ek8`<wn2rz;5wkVS~d_${U{!gs0Ci>6OWk$BSR5f?kif}nxy^L$Cg
zI7HTGQJ;RL7w9Muj3l!08_jJNG;h(LM9!Lun%zk_JII3s2e<xY(~Ek)sex4!^?rd0
zrH}D4_|S%XjkDw2>oD8J(L@o=YL^BmWFFD3b+6kKeJ|aY(tMnwOdkzcai2?fJIaEG
zf``;pWr?v|X`oMPYVeS<B!G3%*!$HY#;hm8_cvXl1&!tL?$<n_+o?%qNw^E~Kr}oK
zt8oG++yMb3?$1iPtocFx5$$VGIuo<J4#+C)j%<t*kd;3Y`EF+=O;4JWbV<@uhyplF
z+9aZGc(=Zbn6>S@b^Skmk8aQEPk&?p{^K9eE9*k9C<TxIl=1W$TuiU(3VIEUqF3$F
z@Mn2l-Xrgq&&qaWn;K5R760+;@%A(RjA?jL^6?VvjTaSv0|FV=Cvi>uD(<5P#FKOv
z^yWhTo^!nZEaW1IL4uv*j}|)i^7kBjAv59MAm8*W$+x^?>d~+1rlX4;Wk<ipk4YD@
zbCsT|&uT~M$@{XGu$B8IYA5uY)lO}Bp1fmf6Wzn_Zfc@7nqP4Y(@)0<2T3mGL9K&f
zd{6LfzDGHr_6|0x^As$(BvE^z`{3l$om!43e6Mn;vC3HWo0?%gWIV%O=e0(mcy?X$
zG5TJ8B2I)#g%!prVlE~Q6Jz>bW2`Y&c~E(9s<Fe^p$z#uznERC=CNz}#fDe8i;d=w
z7-#WE0B5)jvxV@pwucB-!s!;rCha%$CvoyPHt_|)eX?z(!8ldfrfkD~J^01WcO3Zy
z6~o$6S(014I^QvN@mYMPv0LfIZeo8!>4pYA%h)Bp-Gp<<cG0s*SE^5GE~33lRiEO=
z^W)jSa35aTzd*0>@1VcSY2Cr<_-p(%R%hLb`^6OjcUjVz%6nQj*{1RyzmMOCQezFg
zknLq88{yxnO*IFnP+E6=h5xKOasP3Y5ii>8k@TzbrFxs$=9l~d{s0??JMqfK0gtkz
zkCaa8ljiT8P^;fyDt=$j=CC=UPwRKtr_WiSn0H-+|ExRt`j=jMiD=(BsgvVjZ5k{F
zXsSCrWxfh`mbcDRR-ic^<{$jYzvf^6$v<FS{$ypW>`&GOEd*~}w(M4>F^%5QXSfYI
z-7TsW70cls?3tzczNf6dE`F<14}XEZ<$ru}`0y8~{*d;?;plF7@Z~EPEV%Mz@d~)7
z;w;e3I15z3?NmHvYA1JAeYU48CtusV>{cGMLy5*BkpN<VJKTnVJF*p2!ayX$NhKQ)
zZ>g_~ZFQ;z4gnRf3;s1>62^>TuJe<+J6CIGqTWycq#>Xd#{LXOyZb!(If#qUr_evk
z?U3s-J`px?daP;zo^E)~;nY3tkr+}3mxS-j`t*hyKFu<WFZ(Cwbx%|BUD@qty^z%*
zqbN6b#hJC83ft?MUDUi@V>c<Pyp`qo_}t8`bLVc&RK^+)icc8R*YDi9{x*J~qf(sa
z99vXd{nROrG)G2us?*u)!V^XuGcSi}g}oO(Hizz;bK{M3#^41!na_tg*E;$oO%ki0
z9ytq@&O|pRJvcE%H4!w?i~J@gu?Q$gPsmDu3a3KRC+AvkllR6`3d<QgAv4wC=<>nJ
z!m8|!?TTKztYOwk!=gTC7jzkR(j)!#3}@O2N><e=H|n2x@%)-Gr>u_ngxr$by3JR#
z{IbG=<-0vfYI0@{ijr3EnAyK;PVBeLWX+Y+b@mGdl^OX=ub*`rk}*zQcl}uT3SHKb
zUok)RWW5NvB7IRwafm#hq}-z<dCHPhi{D{(TTvBj8ZT(z$)>w=JUu;~l6*Ki&yfU<
zyX%se+XF**vX6Jj;*<Cu{5vztc<iGg$=$PEx>};=wwwK2PIe(UzjR8SH@m`FRYrUt
znZ@pA?O6wQPZs;eXKcyj+kPAK8-E}ZDMH(RW#fz)#sir+{}#D2d-z3cEi2u~f9jx@
zAVhO!=5bx09qDkUWV+Lw&YA`NhS!~+TS8)h2G^jD>^Hx$)3S^QlyRB-f#1d$4`i`%
z{AOj`zxn-;jRi^jQ%_d!HZ!z4c89M7FH_X&@zKG?BrT@n34yRA-xLIoh<l0>J_X_x
zQMS~R{TW$z^3Cbl+39?<^?rL+mT|$-YPGT;D>YR*-0;ca1oyl`S^g;9%O<f&_V*W3
zfNVx1-<6ieddt_wjPusH9KN!4?W9XTVMDv(GM~e>?)=-+()cdc+j`wf0W_Lhb`v^%
zn$%}=h0)Y!88j1IE|0k+@a&5fctQ~TR-Dz8PGx=ZSWA+m-REG+a_(3Con?ATik{)n
zoLPlaKm9p$!R<Y3>SI}jIXPFo=vDI_X+53&zW$!IA8vhCZoxwG9X{gh0xT`BzJvc-
z>L_73SshNO`M)XVw*l8*c=1Wj^eoc!Z`YMns3ne4e(>(atVifGTZ?2LWVqPyo<?}n
z`R^1hG!y7T;w@r^ZAV||e>4HAB^?kGUhPAg!l$6bt0BbWQDVkJ(UkaNT47d*6j;|r
z8y|&<5h6)@U67<-wIB(78*sy%MS~m}f+Ty^6B+dO{P%m#{<NlV=!>L@Ng0-OO7j88
z!|il_f$)H#s?xT%CJT|05RVj?1^NR^Tf`kw(AO>lcFZ*#YTKo6U-ny=`zER+3nuq7
z+a3E|nD-W<LJ-)&<BtdH#W>c@xeenOowa(A#M887G_!~RUDt42G~@$69LG?j6MEl@
zP_#q`L^sJWk}f&7^(=Cd9!&dU*sw5~C-Flp^(3b;!26QV_mcNOiwcvFRJD$d9UZlx
z^w5&rtPXu^K0Vv-x6$IA2Oi+>lu|~b-}uZfGi@ZK)8lb6;sTwwX4((Awn%#cCrXWy
z6w^brYx$F)Y$spDP#d--cDk+h*7<yOUj9ML?~?_2y)RyslT(=W*wnMUYO<qCnX~^_
zk~UxWbHbX${s(%1V(Y%`<#eWIr8`f$_`>V6I^>et{CWoyc;CZ+Z*STUk|D&eNKZ`p
zv691LbOy#ULNF}rXtS6kYBs4rkzl{!3TcbG;_N8pQ2vBb91^mUrsRY;9x@Apsn^XX
z+Zd@GQs=|=QHq5PH*nI1n`s;q+Q``Pz(mrrfQfO1K_k1kJB)3d0Re#^y6e*r#zXiY
zENw_w#wErfyoCXb854v7wA(xre_Vfe>sJ1*owsL3;NOxV4Euo*T#mFQPEU+!vGF^2
zD1^OzRH%ZH5X4BR>}qO^`3MO?JW~nzmQ;z92Ah32c(?6~DHYb3Niu&y1YHsegfFho
z&?14%v9cvPJ%?l}H7==yZy{ZYgv4To-~U`<dWD21p?lE+(WF$xBc0T#<oTf8qIk6X
zizK9c`c~Yo1Ui>IKQ!tr6WYY9S|ep*uZ$tv5(>F2q>%AVQ0p{}blHBtCv1`q-W^9(
zF`8RK8TMbrIzqXJ7OE}Z90rM5N^2@8nQ39CgoIfhx>*m<Dzk|Ke&n<EW!Vw?{j-A?
ze>y0+drpRejP`ctJuhb{@6XbY!NAh%)SK07`7gGD04e+z_LA_@4w&TvWDS7qTloGm
ztt2hEuKu{LPmggr<eX&U=cyZWOZr^0{Q{PQasskOKoyccej%TQ@a*n<PCElLZxI0{
zM69I9iYl?aBiGp@G!DfgS>03Y02Y&xeCKmMcgBe)jvqJe;^{M%Ej^FFe9B3$oRpu}
zIZIE@JLR3?p_!Q-2flNPD_8H8n~z^+uzq7^Trz$7vdg#aPNgZw;D%wB%$ak^_v?Oc
z$SKfrDh7YMAhSIjO=o)9{5=(ebBc2seqQ%I-Et@+>~pQwE)h9MaKk8eK+cvuMVs~&
zSOaH^{OajMVt5zi3V#rKpXxh$;FAV9fsAC2oIaj<vm@K5p{k#szb{`l@qJ(e=7z+F
z9iyF&)C`&%PWXamhQtSgn{w{u{HP?U!J@p#5eY4DhzJHPuKWe?N0j8GdKM2oJaKa0
zULD*nO-mhLJLJ#PXZEf+zAbpD<BzSr`Hj&hpL=}AqQdHiH%1TPSNPk651k?MshIDT
zU^YA1vPEscDCG6V8Rn&540)t!v9;6{qKk8MLTq~j+mQW<HwgsOdMA8(S~L~dd_M-f
z7RLSHJ<*Ry-D*DUJb-$hb;RND`YJHZuJ@o4fiNUOTBW66o=$2QP0Cns9>{uVM%c&X
z<$-xrRrDugFw(A{2^OHLsMg57fY)hrOO=KU$Dl=XZjcTpbKhZnLV1{<z^(fPnV7~W
z_po#zgYkO(9`Z*etk|!76#JD2#DkTV#7woq_#i)#p)juj(kRHCN8uZvT_Jtr0bd$#
zxc~m-K3;}7_NQ;$ey=-tk<X{Dao>CU8@v;)eZBvQzq^$haI9wmQe7%uTG>}=ASZe5
zdcwg`%Cc|Yd)r3rr(22D!`&;fpKjxAd+%l$7){Bm{_faz0*8y5r#KhuemWTi{-wu?
zohV`J9Eu~zAet3Iqcj{VtOg^!*c-UIPi0<awr_QF<(Q(P$}!EW-JLV@D*I^IxEGi-
zdX7F7;j$s)Pd|OUz5}0boike7>>c7?RO~D6Hh~rHD5`a5XS<7Pcd){46L4{n-@p12
zzkft^HB7}Nt6_I-uu9obt#wC9REx}YIKs>#xcP3b`DP0NS!{zYa5XZ`H;<mvbSpNw
z>>%ixhTzlGIimxU@XJCQPD+CSkME5K9ySjMMEG7p1f;dut120xwWOJnU8Fn<ITpiU
zb<b)<hpmJgS|_71CB6=?F3iq({=DKERd;1~Pj2|+=mDS4k$v;2z03(}M(0`Y=jIj#
z=OoltNPDWoIeJI8`ye_cS{cjR<o92&{gOVIfY#6cVuI6|##kKnr1`pOvpOLXd3HRx
zmpDb~WQz!iY~{q*M$8x`u93PMoShKSgg;1Ku_lzzcWgJcG+fR&c~&$5_zBThY&<r{
zB;qYlF<FfG8@OuvH-BYJ>eYAh#KS`uds1^sYI@H+{m&t_<5M-w<?hg?F-h~Bd-CWv
zZmvG|{2`;?Xs9kM>S*l!562|ZvxFGc+nj_}#-tWnagI)iZJWlVgio{X(Pa3vl`+Yf
z9sNXv9@98&&cYMurk%$vQsloJi2wR<Yqv+FyKzR>zplB?)&Grh{wF#Jez2s!B_%nS
z{z_5`Rzq2V$6dfYtbjR~G3HgSzsj};nw0Nm@<R1eW6WzT_!<tV!&j8{pl7!t=-8<3
zq09{CW#vp~Y9l|un>R4VUt%As7mf<{Q(qj#=0)D?Qgl{LxBkYfSYL5Fo5vg3yiw|l
z!G5p<XD1EOv$W@hPYtMY@IUhuvx0J;v%J7rU*OZTc;i}*e{1pBYmJS6`)bgjuO1)t
z)Ki007yq3Pqq6`|5Idbc!G}%#@WU%VT(ROqz;Jfb!&;ek0@_VtdX5+WqgAbpe>|6e
z#6OzLKW200&Q<n&%r}4Z5u5ZeJA>aNWH$U<j{V6nJkf3RS=qVs%2}PyJFjzOYf~35
z9&!2b;g<uJXPU<&XP`#p3@C1-3>aUDRDlK~o3&T(WbHwR@I90-ptwOew{G3Z?xoxS
zWiQs^%_od(<<j4R2a)1~XQ%S5&RenHiuN}}tjw$SRr*_v@A*=`)c9U0W>>H)l;T(T
zME)NBO=MeGH~iazHB{TrbUR%Q-$iGQq&8PO59z03-M0g>TTY<<bj?%drB&++PnoW%
zSzcOi*4$Y-tv6So?i(zjoU+nLEsD6n(9?P}t?N1u@rU_`d=>tE$RB27SQWbz|Ek!S
zSNIPH`B(hwgZz8e?jU5f>>w-t;+01}`Sg+9@^$LA8y<e>h6m-VGJtQ|v-{O=*>pCI
z-ucZeW83xXw_;uUAicA+x2~Lb(Tca_>pjyajGuOwcm)l$r2F~L$T7Ly+#^Q2g>1C5
z(@`~d;iH~cl6^O%b3AwPJNWH9h5gCSVN=+lSNJmiZ+?(3Var$+%V5jz<e$C%CjWv}
zyzv(6ICbylyMLxXQ2h>^a&Z)ooWuUaQS7(j?qz%lp8Pjo%&uY?Z$MgoZ@$4Q_?K^O
z-uv_2oA)0Oe7D1#5Z*Sx)fxn}mKyGhPOd1W8aj3gd1>%wdJUak;T5|lbX5Dpf>8`r
z_zBy;|MqcYiL6`AXR;gD8VaAaW{r9?KabCP{M$Xzu-v(}k<Xg_?RGws&wk=-_P6bO
zzI*%vb|atF2ojL3;lJw*`cl;QhxJek;4{$ve-T!ImBLq&xx8FeZ{Y9jyu;)1^{F3r
z!NAU)_&pog@M8y^`}8$uoPU-&gf}tw&{HmL>^rn;<*fc|ntswgfA{nieFra}#RFzP
zFX<CxKe`I5X~r%{iVMmWnotTil<5<8@^@b1Z+QI!FBn$e$LH~EIP3f~u6g?0LC3O+
zuKZW#I6=E&P5)VyU5EB<yz~^N&ssjX?~2pk4Lob%^MU?0Y;-b^^D<AZ2bNZU8<uvi
zu~;c!GsxI#r;Tdrwn6Vp)>hIW^bE3vbotcVrpeuC{G_a4*EI;EtM}c|)J;Cqe3|wG
z@|dWfREFVzd41XsD~1NIXE$8OcPZUoW?$j7m2`fo{&lCo`A1(NTGKP?pzt$l=o#(0
zZMH|$*E$(j;t@RaH#X04rgoYbH#|sWa(f(S2DTC~+G)xr2=+XT2Omq^F+Qn_fIE#b
z9xP;fn7W96yn$}gP77?+PBZbfwMh-udfbjPc_ZDRe211hZ(yATj<)t(ipO2;Mstnw
z1~CRvqjnfYrWVr2s8P|RQ9^(!-^pezV9`2LKsRkaU=`Nd<3=W!$F1#`&4+Fjy(r(&
zh-W}RMPEsqwQsav1&&VUL^hlD&CKAh?<%S9vh<m%n?6L}=cA)8J=!<#27i@zDBqbM
zW7_n3>KXoN-x!C?TQ<L|x~T)=MYwNs{MWw0FSu28Ygb7iR51tBLVTmV(bS}DfK*;v
zt%v@IM%9ipckbjLTYp~?t-e$?Z4m!iG$7j==0i$ShG@%^R}RU}L33{NFU0Ag@_FsF
zFTZ5-f~$7&9Qq%KhGBBRgAwfj2zuNO8cD*JU-ExgQ0?3qk_mpIXqspihA9F+3m8aC
zZFQb9MuNgRn^L2zCNxHq!1YT((<H~4kOO4yS@y8r=W+WmzR?H)V^p6Hm`3y0`5S!H
z_wOlb?>@^;KlCS?@X*YUm2Yu*410vtu<CD!4^JIB#J8~Vf9~Hg;|GhkvF#Ux8z%vx
z_D7-h*ZJs=XFkLx{CS9-{_ML-+I!!l{Wth%_Askuoqm|HWB;H0em3#Yp{Gd5zM=M&
z5TA*rNswWZeO6Aq4L(Cis)L)}*svk2sr*FcJMo;UtEzksI%sLEQ38rft<`Hb7)yiC
zsDnvy!+ptT&<S-Ww0FY>SgS^PC-DnC3oXVoA)7#6tI%SyZ(&XDO#LZWNLYi<7)v)u
zyfA3J2EK&gV^Z7HZNYtNp3-4va1&7h5H{U4Q=KN&j$n*_PL<lHzedk(csIC7-i-%?
zZ<^msdWil^Itne!0ib#vX`*;&1GT_9zpGB8&Vz3P&~Sg^IjNN}C3x;N+(Vi<jSr>g
z^s^+u>a?a~H`wfIzTjFptR?KFv|QD&bk$^M`GUzCrU+uf$WGZXnXMLl><rzcKVf;r
zCwxOQAzE8)0u1^mjT?$y<Pq5gXX7-%R`UgHH98dSf`e0lU)cVmP2#qI6Of`+6HH-f
z>F&v)=R@XJbOUQ{0t~xrhmoYg0ulHUe0iRbjklf&KQ64XNeGiPqyxeh2pyJoB~MV)
z1h(2^7t`QfLd?$Euz{39J02o?mwJ|#W)U-RHjNcxc$0%rxNVX{camtEC`#ONsYC=~
zw&P5j(h$Q;`KPO-LpM=3Y@V@Eb|1XUxM_ow9TRSBcQ<v{4I-n1@E|J(#xRV*_sqr#
zcOie_HZ1)j=ond2aVtO3RA)JJqfwKPG>7AuHY5NhIMj%|)f)7*)6D(@XIo^8fddbR
z=z|udF$vMd@&&9GF^CJf5O~n$4(NeO@(}hlh;HU%ButQeDg7IaN5!*17Pdk@i=IXA
zis;#RRQMlsI~v%gol1X_5TIW~zos=K@*}U#L|h_I{R^~}Q6!I`tM%*|vR{`*vOs^1
zGw}0uCh3)t8)RQ$1juDUzYk(AKNQc>ER~|UG8vm9p`Kb7t91+={=z>G@VEE~ww?7n
z@Xr^92e07S>;U`a(^aeK68>#pz3S7$Jcs8T7VT9!E<$@W(&r{Q$u?KJDa0zKL5_>~
zFXp|r=augc@GFL^OW6UQ9lU}%q*nO|JABk0n!p6m=gD)iJWpLxbs0eCBluecR_JNA
zR6Gsc2hao=`-S~-_*0e>Zto(@&j?=ulAAVMy31V{tgv_i0MTINqpMcS#v&=8E(M?@
z`(fVY;tOVVU>ptD_#o_PPYk^L{v$?{;&_Is+;~Qg`icW%w=(JozkdT$pP^q&OUmzy
zZWEa_Sb0gR1y`jrAhqgae&3&wk87tHO@AVJef$x{VKhBMDdo>74iQVicqC*KFp_+s
zwVI@A$acphaxhFcHSWVCZ*T^Vu<;uJJT+?CPpdsp4#=V*Y2eXr&!jxZnW4L-49X_p
z1;<hW)RA;#^PB~c9U7rcy@yqE7Vw$DRV27-DX4UZ{t8TwNh`%+j$z^FKpUWi$MIYv
zo|~zR;&(7rEtR8z+HHf;B>Z|+`YfV9)0>pz9{8u@&orn@sb}^JdVEg$AjUWN+&S#Y
z0EP`4g70CJf{P*ABwZwbkYtv$m>LAlr73}82A@?Ms107luQQgi=kWO#@&n%6FqDWL
z1`%V**5;d>jrw5tsijF>kZn%>GwL#V@_hBE9+jV$gM0}rbV20mkh6(J{*G9Bs&@LS
zX&1XEhpJU|5`t3=N+vC;?8TQs*zO-Wt?}yVBY7Tsu~)a%&lp9#U+?Z~-+J-tnIqZ0
zi=N@*M^0Zfl`T`X&w6#e_L=vuo-vXi!*9XGs$T5)XV{5Vz218E*~25J2e!P3-`F(%
z^0aFSe_ETD`>U()#kPJJ-hob=%j0Y@Uu$hswl<OHU@P-4ksHOMH(7>uA6r|$<rt!G
z6!gdJ54&YN`o<=%D|{^T27XljPU9*@!!wP$#l5?P42ykYUYCZ^&L|OXAb#J)9^_+n
zC9qN}G7xsQe5_F0E(f(tH)(eUeq?8gcEhcQ$07x?09afq?JF}oFz(hB36_zj{GB1W
zif9KNHDL$jiUqg?S^jRpi@i7)RwS?{ppnnJR0}!_u8^G~cmR#{xCIFPPIGL~j^^@~
z4`?|6>Pt4~UD+hz4c{-^92$7!c(p-&$x=6CTG(D-{*Jcc3dz=CBZ7TNy&|UYrahJS
zn(mWqH`sTBH8nS;soku0#rzrV`k`ZFH$2*Yn}yg!{sk;S-w=(h`~M%(-UGa;BWnQl
z+#=alv3jv3+bXs!*|KHHvfK^s;9kJEQ49vtOf}u1g%(;uhd>~Z1k!+nmIkSmB&3J*
zO?H#r&8BR!o89c@fi-?-?v>m~{y+bFpE1^zuI`*U{hT>-hTKY|6G6QFQSZCFL=)={
z&<Azq;ClnlCKKXS8lB9h1t$=oU-15bPuU;JbMSJGBOsD9y&S%40N*rkE6M7l9dV`&
zvYELEA}2*mM>qb9|0g^P?V|2{wSICclk<3aPgV0<XcyY`R(8oHeoy@#)c+hX*|7Bo
z>@7Ti%Z!@5K#|$-jK41Gh*73aslP_81JcZTtGV)y%15t8T`bLhi--L(<X4suSmHp#
zkcDy%mRPbT3feq%a{a6R<#;yQNl8)UqNy>8%Tbp~vUy0Ft5%es4C1%{IRq9+&>D%x
zA|+bTMHFC}<zGQ&qKui+jiM+i2Md|W)kguK<^U`q4Dm?-7875_qeq;9h9p@wVn$yZ
ziUb3}6L}We6?i(&>%nJ$eUcIECL%9M6oZ<CXOQ_<Ja)}+sWc1bz<B#H1oNcUp`Af`
z2H=1#I*@ASy%`yq41vQykcVdlk$H{X3+Nq$BtUpju7j|IQBaL$i|0TgnAO8$xF=+l
zJa4#mY7`Kc%!1JSwYtfvis-2v2N2wXZRyJujE8;Va_GfL@}|(SkN9j*vCoMK+1)3!
z$+=`W=e)ry!T6CY@k<TqWgXG}%~Us{!ImeqU%6cUKuO)l{&kR<Up;wyE8{(PnA{ef
zfX`6fR5w0D&msoOe-tgea>ai~TJHN7A(4E?Mc5H^I~*`LM<qz|dwEC@frI4biKB*q
zX23xH&CwlY=?(a$l_LoZV95_$zEW560Ay@e`qv?6>-Nd$N&jY4nGoH8@>U)`N685Y
zy^vl7pw?Wug0~#XO@p`AT*U9TUgY4wB_Kc5L43e!2d7u~1S+%y3_}Fbz=nv&xg5}e
zKY|}W!375nj5HGV?7au06I{>@08#a2TtZ?+z(D{T0207`_#C=~l3RI9_@mH5fX9Ew
zl>lvq!2-I7;36#@8W|C8feSTBZJX2tTZESY82@J2_XhxtT#52H8lgYql|T>t9<?0%
z2#u~#pAeh?762eh4rGEmqZ3diyu0RND}MK)|08NmTJ9mdg#bc$q+NKJbp&z3g88?R
zBy%p=WJ;8s*5)&Dnt=w-99{se4*P%nHTviAq(5|)Cp}8OuOCjTn+N?0&q;IxTHOzL
z03So)fO!*d09G$7JRD&(gsh<EKu2g{D;TWb9L8sYc=rD|fPb`x8y*mkm4NLl9NMXK
z!<Y#G`hma@;3WUwstI%5jt_zYzyqg{P#*H|_~5h@cv6TcD<nKjn9jd>I5Pr1I38@~
z7!a+YJ{itPki#S_U5$M}Kc1(4g(jSB03hJ3U{b7TghfhFxWE>`shr}~3V|ft@Wbie
z%#j>W@)1w+E9k=kvF?}j$-qL$Nu-+|%`p*4d&1fa@h>)jUM2Yn3FHu9NtWOvU^Qu*
zkhPhFV8r!66g9g6pZ1@^r>P~#?mtD<w!HZUHLlrzxcM^4(9qTRKGaSvy_tcUXw92%
zUTkhAZ}dK~E8qu1Tq(T9`C&pBD}>l)h^6HS4sU{eV%L88v(T{Tri@+I>Hn+$>*>@Q
z_S(%inS-~cpiR>$J$Yv}&qpLaCGjNjr$L(zc}^Jekp&0A!kZcFwJEnkn37Vw8m}%z
zE4lyBsuH{!o_mlDxfOy?|Jy6!F0`@)uOhSwK0nygQ5Iqf?nfTHTE`N&`^Ur8_zn1}
zMo++^v<E#g1#g1$)BlS%p~WZ+eirwIl;W%SN(suuS4&YQ$|}KE!O{)-3V8&%bKsk)
zr6>zuEkRi*s}we;WtQM8{|kJ4)WwB_5%8?vhHnpk=->Z_gmCk}|BaeIpNVhbTQiXW
z-<(Mng=S({t{)B>+!y?gVme~+t?977FPM&RA$B_E_OFLzGwT`BV<99CIEYz)>sv;X
z%|Ln%_GtIDv%i22;`~hZmw-=Q!g<zzhR^5rr3xyTS0K6pKNNPe`xSxZ=sN!wl!=~C
zp7BcGY{4Qn2B=PAK?Lb7Bv^#U_#ePy(4$l<^gP!EU*R!uKkQQ%JOk@ca6h8iI2xAf
z1<!o#f7k!+*I!e~@KX|e_4U`}`Fld5*nP}Ahynn9M4V-6brkrV!#*Q!xPPU8B{PpC
zV959SE;HXVSIPHaWs>=xyq!(026i3t8K{2p8H~D;g<An9REZ#*_3&#_9FqycZ^ol@
zC<A`ZQ6=PmTuykN;IBylyBWEAd43dx<8pire#&886aFXP<L?ET=6v=D_#!Z_1@8C4
zUl05RWA_QJ(m_Jw6IcQ~ql5fKJoOQG8IPXSp))9s+z@=uXUruyQwd}&P8bgh@3wTg
z4AvZA>0JwZr<qHNFJTM$7hlTXep~)0WJcycD&GD<@%Gz_KZ3@L<=*}h7TG@^h<iv*
z3H(#U2nDnS>KWs_&}K~OQD`+1WTh$C;-dfv|9$pLdAs=Dm+*NcI`^e~vikG0NCZjz
z$5t=J51_FtS3<YZ{V(FPDE$0avdQ8DFQ5wi#Krv*_iEIDA78T!KZw97A^FGi%ulQW
z#stsk*JdCjb>O6efNVR1MONmgl0V>|@qa!qdG*zjKfu~$IJ}A+HR|B0$M56*zg7I|
ztHqzg2cplpS8(&sBM+WBb!gOR?tg+e?(7=De9%uy=+Y6wX;Tv2m`Gf~CE|c}`3rbk
z35f~rZ2>G*;x;#KBOVSq=0?ZB-W?|binqBTAVN*>dcK=_edrzV9o!1<Lp;-eD~Kt;
z!Gv`5JuP@v5CJkL1gyh8_%NYT#rxi{k_{e*ms?n-VVz6xZ10WU8+0Od$UoUXnL70K
zsr3)cENW~S)0|g*YW;fZ&*VcovG)dl13fbT(b5<}@iXaT5~fDQB>21M0FNH&dxQQD
z+f91&lDbv0(*Rryu7oMj*eCFZRDK%4*ufnz`QRV=KYVXqt~)Z{Be}m*avN++JqEp!
z`Tza)&+X(Nf>xH~_m4K)AE9#nB>4q6>O#H~oMsTedIU*p5In%R;56Rhe~xQ$QG~iE
z8=Nv&jh{f9!E`+VuU_GKzOJv7?qnY%-vu281mb)ox)Z;0-{3Et!#m&^Mbu;dhQRj*
z#^i?sY9qPeG&I$CE^zN6ScD)W=G=#J$dK?wfOTLz@Bx5Xz}6xdu6yXs{|drQ=0Ls&
zIA(g-0<MacHhJAz=+wu>G32;{Yy_ujaDR!DEA)~xMto|%2$CFvKn^VczT^KAryTZf
zLIA_`_-^4)r7V1fLU>uDxlDeA@+V7uXl2SMQIhDOIvj1)YViX8e^rF%@%LLwbf_0I
zxyT}oMZ2{!?OpJTw#G`$C{G~Bqpb26yeRNCo{<(IUOo}l_z+pGpwiek_|r1T{$djO
z_|&Aj!b=J?AtL*=nZ!XT1JJ`!A+R}xO4FVfN4Pb`pDE(5h9`^LPir)%$#0T&GIF2S
zYR{k7Qkh!3$}Lw5XjC8&6j1GGRS?J<jcO4p)cRYvHvpzM!0B^<(@_B6V4U(LAD}0=
zE|Abv`*xfH#3Tabcg%o78HCj529WAaE-*zXCF<x|O{wl-n9Xt*#z>VCt-+Jt?DgG-
zTS{ees`H(h&8zk3p~2Yo|Cr!ZjdW(T<`qQa<^Y1JkRq7Nbv7S%@N&CJAd3$fV;;j0
zfO|ETA>6{vh@8v{RY$OymjviR?l8qN*LQC^hMy2B&X(okXWV6@6w4Gsf@Y!O3F^Yh
zO$V;;J^GASszkGZH+CTz%B0^p+%*NeV`VlfS0Knm@ewB44p=@LE3>nC<7Yf{|8}v|
z`!u|RzXE+(gpKSGfVF^hQ6QbcNazTfIn67Byby^QA!y}$!*bh$$)`LK2*_Lz0n9^w
z2o<2^5qymg&12aksosVo<LVIhf0dFsc}HnaUP@|iN88f7XD<*$oTFx3*mHKl_ze$c
z>m$VCn8uE1R;k0q_|yiN&!?#V@v(VDwdF@8QBe}4@BMLReaC!iZc6^h)b5Is=80R`
zvM5Colh-ii__CIAQ)W-v>@j2RI~7AKkO}68LqP|7`)u@0W+m`>HdLyP9+;nvv<9&W
zZ9X#7^n9)%F6o}iu^CtKqtwzGXxm0+1u=jp&MQ=UAzb1nNiz_p(KnM*Yl~BogqD46
z>7GT|vmd@O>)7nH`wvtmkH}1HpFLs8@vcX*&nGK2an+O$A4o{B#^Qe^B+n@;I*9+|
zzEq!?m!4WWrX&1y^K;o-&P;L3pFP>`bviO8&nwBDhT_fma`D}GOhQcDDMQ-L!eZR_
z0b+2nvY{Hei$5+)BeqTg^Q&OvLSl)Hg?LuwaRX@}h~%h9+mt{mix))02a3%{TjX>F
zcHeyuN^@n+I6Lyi>@S(~+eT$mUKDZXqkm)CdcVy28krTT%jVTg+=9=T(R!nis!C<I
z%sGS?!O}mT3vyb77qMT0oPv=jVJ!K9n7&^H4q^2EcY(#>reT_paM5k=5;0K;Rcaag
zWl?5CfybQM^mCX>5x!Uv>VGm+ai%m0jyoz1Q!2ujDuhD$oyjE*)b1<^iwj$>45g|<
z<!i}1Qxf5w@MVfnss1s97fGsBOInPMTx69QDTV(Bqs)pp*|17un1mRqnb(#wBaTO(
z7-jvJy}Dw9hY=ehCHNZAn_m1Q^9tzAf+2I~c!D$x<=8$T=S0kTqrizbs7?rOWAz9=
z4$M%+ywc$mdE#{D5pPB-^0lV>*3?&otJhz%ncs|-7io-1x_0EI>?fumt5}kxDMI*1
zd4{wuM-f?o#L7%c_|@zw>+xKh(k3L@6-kvNn3hJhm;$w`YnzL&V1p|{!BR-7R)xMn
z;0M}4op1p;duR~tG$hy+4pvZu={DSeAyS9O%}p(U7>vk0M=t>i((8fl7<}(v!W2)I
zrs4+^OGANHJu*1U;>nU!G}c`b79W0xOhC=BwiM5K#(QKbK8UV4QmnOu>6D{MrevSs
z{RX+2Csaa&k#R&xEfhy7xbojgRhUh={PjZon7=(wDHVgNAe0Ky>VBXVEENo$D=j41
zmH~T5jCVkz#X$yS(CkPlE14k2kSgZ>Ah~u`^lcPLT-vgw3*uf0*J;F)onZ4kC^;o}
z;hiHY*KIl}MRHeMQsp3uQJ#3zvhZ_{ENBeTBtk4=18?~eYfp4jMWLZZf?1oClnSpd
z)I=hwPD9AX(~W5b9UVI`7jD}Wx4I;>D2W#bnJkVDOly!1{_`dYh4E`|o)&vF^qpp@
zpP_ykz%saq%!N~LqGw}enp@@Km}r7Jj>qYJ^u62(GXePyj79i+=wK>(Ux!odj?-E4
zu{&Nt)%<WG+Z*Q9Q5WMC{<BmuH~)xQ;MnL09c|3Zd>Azuq`Ka(rCK#NHDZ7IZm<b#
z7t~pSziwi^0t=+eq2p9KF)tuNu*3=!Kyn#aPN+TR%?z7>Pj}pp|MvWa^Uovw+Uf|O
zwIMcHKLJ09f0^8ZZ%$tRw>dSXy4AZreFqtk@x~W%!lYZ}<1}I##ZkwQ+q(~s>I-?{
zA1k^7_$?J&;%s0D3OZ{2mN1>`t8EKNvxV=Q4wf<CFKIa5Ax;SZOm^v-1eZYf0LRan
zzI|z1M{a6LUQg+c$(bn>HcB-bIkr--zoS;Z_nJUlDVm7JIA!QDbW&<TZ7ibf5z#mQ
zv~5CjNkw<+$o!PK)clV6ne41v7HcAN<<>`Ad1=^6f2Wbf3K7b4+<KB}uo7E9@JRe8
z6Y-=V3mxe1&U;JXfX1s;N@({JWN&0rDB0&8aN{zm89E*LG}%#OKUlM1)X{}h<b<&8
z2Z|@R;dxlybr+n9w)WPtxJ2gZOsSA2;)gQz_^tm(CmT<$FopkuNw2aYbVQKfC#3<v
zGO!j+V2D$vdtm7z*!)Wk^mO~IY{L2H@z(?NLp2@uBi-{CUgHUfLMOK%0re36ilZQN
zj!>|GBP)ItarEo<x8XOv`+$sucl-Xv{sg?_fD4X(VBXWU1d7}70cQp&NjG$@hW$w&
z>9A$zCAf=57iXEUS8g!M@awuHb?uTy^tWZb=t$G)v3VuT>BMMLnk^xl_7-PV-#U?y
zK>d;<5h5bD=^FpN^glmL_454GcO&#=fTM6Q9G*dN1llu!eDP+2PzRWYlQ#>mT={o6
z07GBa>K#zuY)i?nEX*+AT@rny7(azCN(_22?iR@PYkq2(Kk6X{<shY8Av4Fflj{dr
z$YIzkpR3O+Vx9reQ{xkI5-ak?+<MR!M}OC=wZ$<Plx7o8)9eUwZw6hNKf)!Gb41RL
zh=8+?wtw#ePa}X^;Yyg(2r?(|lZK;KG=$+?9K&g&$dt&0%=~o#<HD65hb=41mO7%M
zC^H&&OAQ9;XCFmG8RYmUWumrhyYHJG`n?PBGUJpb#pq9~MDL@Hx~InG6*6ZXd1>*s
zY?LxOx9-*%puj}`QHP8AIbF)r0cD4W`k$Z#(`5!i7L+N9@t>yu@@GOAitq;<i1GrQ
zQj`L-2=D~WyMerz3k4CN@s<5z!jdDGfHvSm(I0Kgz~9J>M%foD<SPwJS_*4&Os!Pi
zv`-~dH@J&i{r}BzG@2_T)96OD)n5v*S$)=w()`wS4TYmzk#_WIFJ+EZG!s3)C~@Sx
zoCcE;R9;A59~Up=f$R!sH-~FaUmsme-^cCwwSf2x4Ic(u=K=r8!m$?#FhR&Yba9T(
z*pC0fhHuU{;h&;LNaQlX7}zow-sa4YK_XK=G~yRDidZCTH|lawT$|B^AC`wHQ69_Y
zA*E1By{;50_=`{le$`}X1JD46X?@=?J@iSaen{Xrp+8_q_konb57<^x!sBr(gy}>B
zaP5Sdo=pqZo&M<H1JmbTpqJz(2|_C;JfV(Xv9IqT!N~HS+LKLX=&QAVDXO}2^Nl0x
zw>iB@OBy?mZF@{dRqf8~z~6m$c<tU7{p-S4OyTLco%s{cF%eFD42gp=Nz7v7{wMxC
zzcavM0>i<_B*ffvuQ_%EZ9p@B(r4rpPf1T==e&C5t_>^JJb$)xve*B}h^GBlTE#LA
zOR<qtV`AzHv5s<&?6IdFm829Uxf+URKDv9ywU_SRyL`a~-&@n}{(~`65w|8mT!pS|
zX<wnOgj6i2hrXd{wl2gKuxMOF6<{z9B(GcsN{J6RxDbQ`nX_~>jX$h-CMPA$lVJ0@
z1fd&CefMQ#jm~s9eD%f6YZ|JYx_0e%-&x|b64KKWMyRMQbM{gbk>04PaAagS8e9p}
zCamv0*QgO8pcl>Y{I`HB3B(A5>-oy10G0;r*#Y;IJ3j(AeemuV`dj?%l~?e08@F7&
zvSs6$jD|xG)Ow`aHMLW>JM%3m4|kT8b&_B7+Ev)iW4!$8?tS}rpMRtEuI<gQEi0^?
zeD~DK5ss49eEzOZ015a#6#)ATd<-EA@v;9Rd9Uwo|69mQ9Sspu3qwMBPjmNqsCcG>
z{S({=)hiTeQ_dHfM1Kl;sGiIvKzZOYAU+skk^%q(6Y(XwG;na5maqf_a~zjYP>{np
zfaHiW;MX8)5Pb$1pg$dvRWf~6Q}gUO(Wx?(F8bS-=I_bNm^1FNg<C&Aa&lWSbh<Vu
zSfQc@|84f}t7DFDy02sUeU%P<Xq3Zh$o1On>A1JZ=~&z~XK|wuoidhf|KP-eY1O4h
zxhwJI<wri>JU7aO>kS%vEi&(({al_h(SBq5{oPB$Tjmx>lQg<Qs1)Mod4-t=J_+y;
z^ugyjoXnGJ_che<<EFszcVH6CJTi%S<0mZW(vPx_8tw*mZQi`yr3>o^_%OgbZNh|U
zbwgajpCaeXTRk$OA0*DkUuVuTyFm8iiQMs0M_@}q=?d6m9uI##Zlyx2Ap2+lw?GQ!
z>^50WM}@uSu6v%W_o-j_V{^JZCswr~E@s)8%zMUQr_Oowy{x*9S4Vd5oHJolO}!x%
z)>gk<WSTFGpO1gUb7tf3Sd{FW`}0xXO8`Sw-}_7=JuV1C05jliq`>lFKMWx63T<3J
z42dR3j>tPU-*GQ~sobr8<fZB)g*!^qV~Q$vPI{*uk5^eYpK^^D`>0c6uyu^Ccwg<9
z^}(?kLp5t|T-I<FuVLShD}QXBc@wZ8$W&3EpN{A7z*`c+M;tbQ1vwOG3Bv`r3z5K3
zo~|S;NzMWSOA^1J?$IfSQ>6ln@PH;>xohK=wazo==WWGbwtI8ltNK9axw|qx8i@|%
zC9`yap@KG7M!3!1ngz4x#4kv0SwPuaocQI#{-b;L$aT21do+}x5xBDZexcp~+(d<#
z$$1uhpLd{=>o&L;4l4BkRMZ=tqxaP8%%`J;+Y~0%>h4wZlDDD-_-2hg?eU_g6t*Qx
zUs~WYG1PbqRgxxhM#g0{)zq0r)uY6m=#S>$g6T6wa(tD~s}}WLrw;;tOhiT_kPYOK
zm@tnPkQ4-kBm)3T;1V9xd?-}F;+jG5AX97+9+#*q)M#4dv`D2?#MqiNNp2Kh-div_
z#rX)`RU>wrtr}Y_%oo9Y->1`HzUJZMko3;&1EpzS4wYx%f9ZsgbL9om!d)_DfdXY|
zo3$_!O&2OnsYspbuXZ^FhSk&^>7mK`NLdWGPZpMp`dV4S`$;7G%l6NTI0r&5VMZpC
zuH?kP>jU;v67DAx1U8JPDIt4S{h?4^+<Tx{F8ELrE>(Jq8}=^qBuZo76kA^XxGhdI
zPNS5D<GPg5qxSu2mA*JK$t^IImzxCcq^P1uOHz0e8imA<j<Hs{9Yy2)-{CKov$mKK
zp0ztr3{Kt+vJuj^kqx6K{4X#<ItU=*U?fVTA4VI%7^ZnSG$P$E^vQ&;Xhc#)N_N@m
z8BUux>UmMj>F26rl$A=r6<!dRoww$h+2S;<DTP(0rYhMKlQvCdFbhrJJl``ypJ9(p
zFTy=<H`391kF{~yb^JmX(cQoo{{<X^P77FVEAJ|hMRyCu`RRN+4I!kh2-6Tv&81O1
z^nbmbGdI>v!8;E>^!e*|6uuXBIxcN)L7D(Pw<G4NrVzhe)bz*%PvU!DtQ=MD*pH5X
z`OHh(E6QV$R+qMW@#;C*k;!zlSM$ofua7P32=LBY;GN`vCL0V%{QnHe+Nu7sCj8vi
zotMwf&3PqsS8USwjAQ}2V_nQSr5FDryYilzMC&U@uE)$p84qpRHa#QD_`2NMS>M{|
z)FeSoO!(HhcjtO4h|B^`{QqQ50#1OdNbQitY$bzp77Fw_pUMNLhQ|VL)`-VI%r$A6
z#GG`MHFr$K2WO1U&6v4j`KH{`<4%iLtddq|dguC1?{ripW_-B17P%&lAIqe7m9=~}
zuBNGZM%V1+b5@_b-f3`Zl!CIt+V-BD{VNNXKe?=>`>w~xdQvuC&cp$Jz*ZB_{{IM7
z-0Vl1@zs{Hw3L?4&YsNt-S(I?iAqxFN_wHJtkqg#OMQMp84}f1SJ4q~9LdYb&o8g2
zXdOFY-M&h-O(|#HDVeQzd(w(hTGlodHFoqg@VM%m272W<(QW+_NMbu17kk9R>L|}G
zz~NfbyE(wzM8gQ=CA$BNe>RNDn^Um4WPbSDLVZkm^IZw8Q9j1M^=<1t)~L=XU~Nf>
z-sxe@<svG=Nq?H8OPG^XZFbaXBLrgSt&eF<qM75JyFl+uBWLH`21o2~LILVWD9ccP
zSa%{E{ZN~Y{}S<{KpmN1y~t9hOK1FldNj5tR@<gkM2Nz@YO{+`rG_GL0`)@VCNntm
znQ}M=#11JOnaRNM4am~>z&8*=u$)>Qu3&+AU~MyCk4P@tLx2Au1C81H^=zy%0=;Yz
z9GAo@A`C+3Bj`9DGoWQ{u@>w>n=3%!+G4D|6@hhWqH~u6UyyNmHOmb=SmO>JnHzUG
z=-WcPdO+{SD5Pj*v|yJkPZtil7A51i2PxecT@=26^d8W^b^dA+5^*;7I<pt%8v&Uj
z&aMP3ZqSnjmBvXeYYH#{vv>df|M~mjy`V1sdgAD3!clF<4>gyDQV0A~g+)zAA8#q9
z()~|9`{Mb3{pp#PFI{-;g)L{E+V=E_m$p59?k>)jzRyI!Jb(Xq5gWID^6u94pcY==
zz5RM<e)ZNnD|5rBEdQ0z?23&$s&df1&)m6b+xjyPZQQ<j!}d+>D^^aqGi&pdRd-Ax
zdZ6z*YK8g1Hcg(MgDHnv1Evv3MkvMGL7)&J3ugyWF2D-)nE{#%`EqX1+yUA-eDk&q
z(9B_%8=F}SV}q=dv1y8r+u-0oj<W_H27(2vCH$%nNEdi|8XvQG{rIZW*F5IfXoKLG
z04(@}5ddcC`iU*V*Ca<5tqKdve&NlLRx9H|A;@Hbb*ibAh%@HZ5{|cUl0N00&AW@!
zBHE62k7Hp^^dDlNA2)B`f2NyBlt<v=e0rcV@Kg*bT<bUSgy9B*7I27t^v^wYC5O^H
zqZ15K>LB;+lmi-k3+t){&q!9ac4r(OtFN<1TZD1X<>!xq?$-DNH%j6h0B=~bp77#X
znYnYyY;U5ZpsTu6{A@>5lT6G8WRRH*cmo%K!&^L!Ko<r5U=nkJ7s^aNYI5%kJA!}t
zSc1-_d8#dfU8xZXrtCR$UM#2FklBR(8Buer)ZsZ@55>CUM&~a75&8pAf%$(0bkzmu
ziXc}p{PFZx#+B-PjK6v%0`)kZ1+jt+Nph<uYjXR8g@Vv%=$`RVg9UwEQ?pQ)WXLde
zoIVY`|9F05-UrxyJnVrZYj_lcpE`u}96mvrlJp_(-x7VIW!`^)EvaZ;mmeExt?_ze
z6$atGg#L#jT<KF6rDj`fTitnP;X_i;FGk>6YGT*qoeKSiwzhPa-yPrq;?Rx0_*qT+
zg?U?D<bqQ+l@Ppg^k+(7{scyz-u+xaTxl(5FN1y_hi)*F15k1>mJr=@qdi({Do#le
zYjmN)(sUU(fA@%!^sf3TMt4-~vP7>jbf+Ru&*`E^evv3A6&J}ZSmsHh6jJa6y<yHs
zL;Bjow&Jz5Q!Ionh+ZP`H7`2?z$2`{aXgBK`MFTfIS6MS2Ate9BTfz|;rldYI`sU2
z4jw_@?432BgT1{jx@oWm=4Ij@z)4&HCs3ydm>41rLr0|ViJU8Q8SsLj0PIi{XweGd
z{(>NAVa{&qE&m<;`qv5F-Kwc^MEeFc1V7Kw^m|}?Ghy7I_e+YB2v3khH-FUzL(Z2A
zgWxWxasXfdJ=@hV*VFi=S3^&(f4QT%{kj1Cv)sHkcLEq>ktVNYWBi1ubQUYiWk~ql
znG>!9_l%snqr#b5DDtJ~((9{S(-xoXS>NFFq6anl_^zbNNOzS+2DTa3$Uo^my1YQ8
zRi}|dCm=THrl)|7hO(^R4=<M}AaPp&+$pv*qQryv+p}Q@7M-Z882gL>9kdx1rjHGO
zQ4p^1RCk*jv|a(8ELCd0Kh%Bn^z`Oc#SW`C%nl;x%W_sUt{B&vYjz=Xm@>N2oUO2A
z$iz&z1HTVvY*b7sA8E9KXp`J|(6$lK1JQmklQk$u!#RON?b@fK+D<*#QVPEB`R1Vp
z?VFeOzx?W<r@-O8ya&bryB)A+zh{ggw(Rx%>OEVk^T4mYw<>#x5qosYtj*i!-U<Hf
z)|mlWhyYoD>;SY184!eD4gR=19TSmc5Q0}?!6p4}2?_re3+Uq#SsOD#SJk_ZlZWxG
zLqb5x467bIo!^J`s&QO4k{>f53;dvi1%q3E2D7E5_r+^NK`ILMcx_NB_+YS%Vs?q-
z4YWd@?%&9Z#QfZ$5h2n;5gnmfG<A#9{baU;W<!*w1%g2m`~|27`Vs<v>ellUP8tM@
zZJ;C{r}dhO+Iz+}zwP!l7~&|S;~YKhQfspR2q;GDJ|+cpq2BDMtld7QpiB?3b(J)S
zjGNszmO2jejU*meVBBHyKWtzSKI-_R4Lh|$-6S1ozCEl?IkIGRW$jCjloCkMt4#-}
zC0mQlxYCm(&@80G(!-J!T4QF;%<N<j_`Udb6b36QJbk(Njc`yf;}P(`pjS#TZsFoJ
z`oE!fF5mR`BYVL8+PQE=7=&xbTFdwl4MnVPZ{hu}rU~1S;Oe1g0$~{^x9`(;!u(*2
zU}iTc3EDu8I~WtvcM2EJTE@FvYo^T!g-~pBbv_?{z1BIph<CLL%DOIXowsgC%++_D
zH8T^rl`<mjU{zq1LgfQbmdjSaxdNcJ_-=z-r9Nv`X(BY^Bpz`he%^3WqruNPk=QF~
z)W}pS=5xjsT~#mFQ!eSb-n;FQ_uDgE^vm}ph6*UXqOLLq!d;?|USl@Vjv&>@m@plf
z+OR=|fi`JSyvJ-(C?nL>BCTFx!9PbG(y8!Iag;=_6;(rDNd;3yQ`*d2sS4TIF8@Z8
zdP$taOr7hr!m_+dnwzO533^!b?_sN<J~kRIV6L2{AU1=aDEKQ-vJC+xcy(-bcqlDy
zQbo(~dBbCBC2m<|cn$rCHZ#ogp-hEh^hkv?&Wl6*FToTYsa|R?HB$eMqxUVUBi<Y(
zu|qDG%oBgkoTl&i9pf>lDKRCkRYpbNzeXO^%JI(mk<UO+i+Y+p9ZE;brHvwq!G!nV
zNhZ}&n>8MNfetH<#rmH_=k$>(X$(ZnBrd?s?4wZIoB$E@2yTuPOAb1=!CnUN#Q4+<
zIEVe7i;*np^MVN<Lt-u+N(BiM@G&?0X!-?wxAB-d`r!k+Y7-M{b{{-$5v<pNOM9yO
z?F!>{W8Rpq1%KHP=YOhxZcDM%kT!N2m6S3I??^fyZ+yU!pMhgmEIQnflG1Rnduf!d
zO6oR&qdr4Zz2)s1y}EFF=XzCdtQoaTz&83L-MX1QBcqL@H%(hkVh;Q|v|oE2=8_r$
z!VdKMKg@-kbU0`xEOH$IUfrdQ+O>Xlsm)fhX5)@%;WBNEQo4KEQ-zV2^mm?raegdD
zCF3izV{|jneoGDhk9lRZcDXIZc2?KaxFFwR$)7)FoLcJ*cj{yGQKho1Y5THOQdeKB
zKiBxLB7BN^R^3+Fn5<Hz{f*F`*s-@kCz1p<xCW4gCx``PbKWFin*zFokn9r|V1OLQ
zAR(W#29m%wW#;YkDimK-k(Jfeb$_GabY$%D_V$Nr!Eu%y?4BlZN>nzDPRm}G?434h
zwQD)5Ur|6m)srF;Rxrl#)zv3Y{haP}_wGM{e>^qEind*O?n=s-h+2cw!z4MA?42i0
z<h_6%0=D7g@m*#l=oymV7zQh`83+~vZCo;s2Xz2aC4qC~aW#s{9FgjtIPtDZLG&tp
zJiflQ^m4?vTRNJ=@nJGUf=X~vy0NwGTNFPhpE^C!9>%&D^@z-jm3N%9*}*U0@#0GG
z%MH6WY_sHqd6fmU!<=BK>cQ_ISf%0QcCIjoZRdEJgAdeezu0naF#T&-RFc)Vejhy@
zngoM25atlHx+dVw#^V}T_@7$S^OabyiS0+`yhW<x(~2#E4cb_hY}U5x)3ft=#0qLR
z`oG5xhv5N7y^Ug!rv`0_&G*(urFdv(lGE0C;<y2Sc1B6hf>@65dGGQ4uOn*-*d|UF
zd@7ho|C{S3ciSAehTy+C2jGQ4b0C48$1Rw60x)i?!_P+T)kjCQmULYU*T^FcN+{YR
zh+ccYE49oWEnK0FQAWITrp=p?Pn{=N_fCT5c#oSj%We63G%qd-nYGCluQJ9$C2|P=
zp{#6@j9SRWdip5;(f{1=7&-j+T^HO3ybQIRL~jy(O}Lpvq24sWYCa<22d^_Yi#G^l
zvIfPKS`be6@qvlpzRb$)`wsshH!3$H>z_yV@0jR{xy~LPGdd};qIp__Gu|S2Kn8(Q
zX3B|qlhX2Mr=&60J>J%WT*|qlYuA+NQ<4plPe1YBl_<B)E^s)Lo<Dx#%&gAR`qJES
z)ILx$T-<cdmH*0#bGvq*_vyq=hbXb)=zfk4eebh3=q5NVYtUTynE-NwGXXihZ6d?x
z!QOBetz5tL>D<gEH@0nDGbYjSl;EDS5#<Gy<4WRVqlJ4V5L1k~ds2hb*XD4sPc3Y&
zMZ0F#%pO%)T)c73`L=I!qS=_F*o{k;uG;U;PEE{1UxIRp1m)sCSiWV+ni(_K*c4$&
zF{*pk5g7=1i}{xGu|g18wj+s802ns!4Y0V0`L_4symhlvvZqfN-(wLRRR9vv8|dA8
z=4WIX-1*j6^g)H#V}h{K|2M*uAzPVoAop6pMgKF0J#m~rwteo*q*>QH15py%i7KX#
zO-|O>CZd`^WJI<r@xD9F0F0uLSb|+(5MH4{T9sfJ0we|afv`jXd6f_?^;xdNkxPCP
zj#(4lI$tq$!Ks?`ltYT}xa@6c?CVq^|7ouOq0&EJoBqK?6#MW+eLb8RmNFBDgYjVf
zi#iSPi})<qpz(;>;syk9;Rh7Lfb)Iv@jmjKXI!m~yKtnqrQ_aFX^D5MLk%fQk^KpD
zAOEormxvON@2Eb!>HRf#>oQ-(Pe45|pLe5QhWW`M!X<iL1%eC(VVqqBh9N!jg*M34
z|Bvs`FI&@)%RkW+X^irQdZ^hOtZ6C#!zE)9uMg8H)v=Q8p|SoO()FVLi+AA@y;2n`
zg--~4Bp*2zc$@6^fY_9i)!X5L9Pw>12Hpdn;^sk*l?Wvn7XR63y+NNLOrT;`{MH-w
zfzPQvS-dJfR2CtN3h#pU7M+TCr7cVjmtkE3E$-kxm1m0JGr%R`=MZ`(vy<#^u#??k
zHXrPkGto19zgMD>_|@?1s3i<PLRC7bX0+E?j*}h!hspO~d5;dG#}EHrn7>#FyRLo`
zJ%`+3u%`%HVH;AMEfYUt#*i?F@#yUV+WiXMZl}o*tds9&Q`-Z${Z+jF3dV+Egy$dT
zg8}{_Ig){l4T%wd&pXTqeEySUk_@;M0!A~e6OyzNF8|fcD3`G2a*Va2VE(#){V<R>
z<#>lF1zA!+BtY^6gM&qqQv~3C*IP^}1d|2Pp}R<G5w<*#(9#&n<yUn0&i^U<I<V5n
z=URqe1KSWff-O=44q<hb@HeO!vS}l*oC<O0ZLbE@BkXSP_XdW%CS~ow_yVO!qKxc}
z+{cCA|29H;s^o|MP#m1z9|D;EH>}JO^k<YPgdeJ@RgtDd4dxbQ(KAE;29nb;R@k+@
zq>@KJc^SxK;gX7Y<aTNZe}P?U1^m|yn-`CCZeq8+{Eg`ho@QWbY^x|j0gJmUwXohR
zD|n4W`m(~y0|7q}>vDihuLX#g=#z!MtU+%pqf8O_Wi9~#XUGnF(VsqtO-bUQH5mNT
ztwAoclF$y;Wbr1p2WXeXXU@2M04!^A9x=ptuv3Z5D3~tb*88A_i}(zPRDO{vA(A>^
zduER;nuj+Sgo_i3aV+|yMerCMsi~-e3<4w-P{sHO)3Z}>Y=1K0o~(@drK3L}$%IGV
z7(qYSpH6@r12)B4^WF4kgEI>}tlu&p13eNsX;6_mAOJOxXB_|*%nLCw{Nf}B>;R}>
zo|%tl&TYrf=|ZEOE^Ps9kb8jS9JDGf=kRF5E@ZquI}z77l1p__NMkxMIXQXk^n;!x
zVR-oJ-C5NB{`3RMNt~Y)PhB3GhhQM)lMC(>MhANOE+E`9U<cVjuaO1%QNj*8X!__O
zl0&i<;Mc>xM{eigulaMo<^^$n(Qt>3`9sjMVsY>lI{VL>fBd87pA<?Pi$B+870TWb
zqL3rG`W1(6cl;WM`F$_eX6w|0JwL&V0n;3?;6D7!KgsiZbN;x`k9#!^7n72b|M%vq
zvR`u!Z<O5T8+MFZF!|6h?+~^sLEO26y}>>kz~_wLk53MpKyn_N|DQZcW_%ENI4$@J
zZTUmZXP?#l0bNM0^iNB=82Z)bWbO1d|BKi8P)XB(*U63_j=MMiKpxur)3LeFT&xVW
zIFldEbf^3due7Z7%fVhLAcyE<I)izftp5_ui?zWXPO|xiut+>C(QqZB{Z%30Bx#}I
zkk0tyA^iE652#};DVFE9Yf$dToGOJ%5LkLfKgy=Q21lqi-T(a+hfH?&s_}E~J`?6e
zTQW%fhrUD~W7B(A<6C3{FVUOSXY>p*e%$XIU&v6OUE7Rt#Wi|UMMCt^9xaM^f>U-P
zsZ!gjMd#$>9!HLwOHS^JSB6h+Dy*5hQkaZ%78R3Xf;u66w8Gi?G-RuT^FP7abcme=
z2r_>**hvgOBvPYK2#fKqCo(KY1XWiOUa*dENL|caPodw1kGfqfS~MEnUA_cXleu}&
z`Jivqa6v*Wnmh?2rh#YW3*GmGpFETnl^vTcEP2HINOV>_9JQS5wEsnhzruaeFj%HX
zA}@;bv}E_gRtvD@!!s>XBn-$iv2}qcjs#^c&;g)(Ns0n=EQ#U*DT-jO5frh9u6^G3
zYNH~fWTaCor(a}|*icbeyQFh&hF$=%_*6U|y_gi8P|#qqCJXmOOEhhh#*W?5SZO;z
zji@<du5ImhTH>6pP-Aht+2d<Zvbv{V95HKBW$pBCSBeL@?8>^OHM!|4=kD_~bFdS-
z{sj1d^)6)L5+{VGprC+{J0X@B3NvT-`3zS;AA6{u9+`h$nVjXdDkA8!0#Vw@e|PFc
z-!|jDXmeboDZR)LV;63UlBny)RaUI6DvDW)4sOiN$*+ph87(gDjJ@W<^3_>YBYl~p
zs=-P)V<K`}@|+3d>*rcX!zP~hM=`shhMM;Yi9Q9o^N0i~2p}?8da0pDwT!)|IPq=4
z>x=I26fMrJn^+{+VRoh^C0yA2@$xy;{0H`IZB2?O^Rym*^u~^D&u*PiJdbiEdJ-qO
zHeY^tUjQ%fQQv`&|9i)zzN@WRm1BEOcy?-+Gi!>wxGq<?!RSa%h<jkg3tjE#%F?cB
zMX{oESK)$X`=?L6b8?}p3OP;jrqSkUJA3Bx^TccDKfpX;)^RE-K!8DVPM8R+GnqRl
z_VAiy1E6k+SZ{9COF*`@!=l$8&h47my<*a0+q=}mJ35+k3g;$twF`E3Rr>O_)RiWC
z>317Z@~&0eTN)Onw53{4&X~3I5bjI2*gcc&GTFwx>klj%*Df@qx<;opv^LajiH$3i
zD(ufUOxU_$Vq<K$mYqBmKqm5p|3c3OJb^C@dI4Y_qM2@o_%?V!Sm@dJudSPbe=536
zZ|iBS^khynk8cxh7+>H@TU4^0xm<<BYv--5EALe4_qR?QxA0PeetVoUylv*hu7<o~
zR+D1&#^n@bXSTP6sp7WhmCP7hI#SE9XjC~5Bhj5VKt5s3oFt!VBK86yar10mBKHas
z-_tifv7Ua=m|V2pu8gZmr5`9+khXE6Hl}GjwRop@F*==f*ZX+YEJwrq@Dv3~SdZ>S
zkoD$q0P)~7kRec2L!a-4=ST6qf9PpfZTD`{S#!GMWTw(&!F}})&hshtbz{-hIVp`O
z(cW?Ze^V2aGbS`ij`kw`oveU+c2VDZ^hSUka_L0xLi%8MFawSBV0RpBx7wI&!*=!3
zC|K!%j099|AW@;_v*-!745;3iR>LPGdZ$!DTSK>sqg~$@v>D*$o(+#C95*CTf(6vT
zv&}Vl3e?S!wHz+SP=1@HycS(vE|agJ=98*L5=%_;m=q`ls!94~mS30S;s;)545WSn
znV&SifL9xh=uu;u?)qfq!j>_->~`PbE?8XRF!u{DGHjVR<>CE*dSG`zdhdJWgPmKS
zZ7it{iZ8F<L2jG5YT@5EF7;hS_3{_zPphd|6<c^wcxKw{#LOvK79$AoS`!Gc_07(*
z(LM7XTsnJNkvxhQ;29lv=B8%2s*y7`-c%NtFQo%I5xYW@Y+^7%qQSP1SyQ@O=i#6y
z;X_REmC&P+K3&RIW-ji#8KK0MDu@%&4rDcN);lGUK|6)Mgn5u=D#F0?_`n2Qck)CZ
z`ts9*0+uW)$_pM3%~>25V_!`Bo_SKm;$v<S)FJbG(T+xgMDF8qMiZF306tUyP9<=&
zc@Ne%D3A#<6SQd~77EhNcWL!;{^RY{6E|EBgkxxZk>=Bw-t~v0Vq9KSXg9~bSv79`
z#EVku<MKc;#W&tq%B{hZzn0vQmYh!f{OrDU3<JEzjnD1*{+;79YOU4(OLOViWoH5b
z6RJ*EUXAJfc9ka5X8$%e(s*}vVMp0kF(q>I)ieI9z=tjce*0+n7;7w4EpYt!8AH~I
zNeu&;HZMsapFxHvp*J5GafSO@CgP}4U9QFlEt{;#`AJ5>A#sTrJ!^o!#TMFRwOUhj
zRdmxRQdZRaWGj7=e|3M2IG_{$O7DmHg1^LaKL4;0Nik($NQ*6Sp{4g5eW|g^k+AtC
zW=Tw9woNaHoT)C<p*tXgoTV;^MuPCL$Vh`jkw$f<pd?|`YX6a3>WGVbwaXU@LzDbR
zNQj_-xdi(!R75Am2~D<iSeWvGs?~;oN+vbxupLY&C{W%^P{LVn_Q>njhc~^0WPiW#
z*emUs)2N?&|Jh#c@ucjc4Na|%2fn@Z4Sq|%<IMF3ANT<8MD81H+&GXUVmH9Ln*_2M
zz^B|e%D^}pn-xYuu%60pP~ZGab?o0(-6hk`rRRURiFZGg+Ca_lFRLDzlH!<6<&7*g
zEr0l~hd+z?<;(dy@XdF&!UPD<khPr^tO0B=un?RL19Y=-HM3+nC+Ib4h4H*M1(VYV
zWnBCUQ{%Z8BEuE<v6+)=+VR1j1xLz9)lV2Rq3h9i3k`2v{qSt}qDxhdk3Y>yYpNX;
zZ>bo!?`TsMx*xx^z#6*{jXbz|p(C=WvbZ_lmzop4aOBkV5{IMl(3m=8AEzCWJ+7wv
z$o#c;%;9+Zefk&r*#Mj>9!@TA{F`v{arPiM>0j`>lg1P^;a55*Y%KJRY^-RQu&?@I
z!}(L^4^NqLqB#DwXFW+3#d)Uak>zVPR}`Y;?;4_XW51u<)?n5rdsB;3>{eCGL|2i;
z6CFKbL4Mx*dGcg?erCh`+O{TABG1WylYRnZfYjUt>uEsg3rTkcE@MM-tDOJ9uV(Tk
z^x8mS$`f22&5`d!a7am@V!ktSDyf(c6w`-ZD4wyo)>%agXVjVXi4+q*k={Y-t4Q^{
zu1uTcrsB$bwI+=*ja%=??wd%HTC4wW@RY=#4Np9{<&7|{E?8Het!*N8^?{mu_P*@4
zWuqLKq&7wt=Zis%sf5}WEU{Ont4uBmYVT82Qnd}(m++g5*#%X0ae=He;WzT@13d@|
z7y4HtEp##h*5WiUakPYFrv;D^ez=>MU0Zj4xMt3Q6i2r>T$DY^Sa1irHVZ$qG=6MV
zRom$9)yqeu?yRu5<%zb6;%%O!(_1#8?>{;GV8c&YE;J#o>&)9|H){Lq8+|opo$J=E
zJ2ds^-E-WpWhx7^7B2oydhcFNF0%S2GZOk?(4}N0k+*XFa1Mp?S7DUgvF6g;N$Zp1
zW=qB4B}-?aJstRq>9NJ*E=}v6lbN(7*Pa<FGZ$triMQ-sx(Ia~S+q3!q%#RUyk;M=
zBkGAgPiMNzT2}ve@vOSIttBG0qoLuU&^fbsnf34B>Kt6bJ|x7c2vj-*SPR|>)&dMK
zdKgIR0K$h<KopGPvre~HLg0V(C!huuMc`Z$)UlAn(`>#vg7puoj_Cd8@H|vDj^}D6
z+*}j~I3;igt0jI5@Ii$Wbbsaycw=Z4MS3n2zCba|uT)d~(q9fUsICHERzo2S$wYn5
z7g#V&g9<GCFAPmh5uXRQ(4=M+*6)d}0eL2CRwS&2pZ`<sYG%vDjM-gdrk4HQ3RY#w
zjx$1U-L$Io|7$5L(VPAqOf$0$y1+mz8mO*?rVW8Q5f1v_sJRS!EQ1IGXb;p|fLYZJ
zB}X$U$XwJOwMVBik8mUoE6H?>O!EvXQ36VhD-Tp>egPRnzFY~vMm(xVHWlLxle!zK
zUeFJQmi)ZiN;Xrb)z;9i!TCi0;mmD=Dma;^hS875g9PwU+@F<(Zbu}qp;ZqlFC!Uv
z68b`i72;m<?qEQ34=g8gI2ot`BkU-FIj!N#%z{;D+X*sG3?!yuThgjQNEoQoqE7-R
zo`4Fp#KHAxy&XIj=o`Z-)&AQ*^}*AGe4l@Za0|@Q1f5K#gv<+iMT6|Pg=5wM%k8C2
z!RZE5)_{=#imRa;AQ964=@A3^1kfPd652U_&haJ7SFbp<uxU!@vs9ENuOr{<&Yh8K
zjmh$#ASm&lpvDct10aqX*W2?yeUW;qpGme)FUg-X|Dk&q&dn|ADt6~}w|8|<TAb${
zNgeC8^9W<)S?Jk*906))`7OWoEhcv`4tYM=1USqdILmfGM+G>8*QkRO)9s?7HVu`I
z!6jcm5ggzj29<oFH;1AFy?(2IzUYJgVzAz&0fu;SkglRcgJ=32I(_?mYG6JUAx$9v
zT(yRcv!o<7#)aoW2Kdd&nEtAb0ltt!vCPm3)(o$lvA#s6IW_0@;+e8F!)7b&$p5ro
zNuxV&E2_DP@8u_se%e0k*Q#rFQga6*0s1-%(3)X*=zCw73Vx8Abom)vf#@R}OSttJ
zj?3YU2Iv<H?pHFTE(Qd}7Z>m*gFde?l`$^*@@&tNyzEK-_u6xEm#w%6SBN@Jzu)|1
zMx5|eSl8&Te3vt4VP!^IcyDcL{u2K3j$G$;i{sJF>o3fm-jSEr(K+wZ+6|jGoIin7
zjioL}`GR}qt=cqqcV>F^+nZ)><uC4m<ULDb4t53jmgFo)3)IE+_n{aN&)}Zopyy6j
zq5_2Kch`qcg<VoRcH`QyH4Wo>RyB?FCk(!#KD&91%{UUBP+4q`G1x{!*Jyvj;46C6
zT@$Bvwy$3~dHS^WHG^LFdRI}ewv=~t*3>swPM=oUI_Ndb1+u!#M?eqK4>k%`rr`QF
zS9^ZP9GEwE&Y5}7o~hIK`(eK^|BBjuYcg}_K5cZSCt9mE__B=}fA`=ks(H@Ny)&oo
z+tV5N>(A>%KNVz*uE@?U%&08)l?-~#uX(du0sk?uGc^$7!fHRS9)l_XTE!5nLc&fP
zbm2vEcI$Xey2$?zoYMxqU1*D7i7-J41#{19H9AYW@hqNs9Crzw4d@NH!yYk$hUhlc
zoQ=Kcl3uSF+nZ7OG4&rjvjR=<%lNto=4-%PG-!Fqn{o@;JP^SEgLJDI3__fo`C3t;
z@`!K-UQ#bhj23hWZ3=V^tyQVjCa?Zs{P=_TbXaKA2s9c$Tiiw+^@S!yI$^8UNQF{X
z<R9riMn&MSGyd)WIRy0@*rTwz+Y69{Ks!HEQg0dk6nm7*bNeY~BmM#UrbCDf9y1l^
z1wq0;%xc0PFFW%*^KzOHQTr`ntL}o2`|pLC31VUb{uKUU_0;*cS<jzYCa@HCF6a@a
z&An?CBmlYmG*bl6hAO&1l-eIraZCEaR2T1%*|<du=%`8q2uu+^Hn08g!krf3{wT=V
zl@(Q;ZXK1Hy~xs3XN|5FtD-()JG<W9bpYMO2ll3Bm2XGyl&PS+AlBl4ry?u;_=XpD
zE!^ytiN)%BVcAu#O-=XURL!mf1TIpiaus;Oc{^OhN74`{gCx<pAD|2T@KDiL@#|9>
zw@kY;8gkhAxtWD~t43rOEOj_iW1~t$O5J5a^TZ3Q*P}W3mpRr%-z-#@Ds}4Xpx<MH
zZSlmrR<%q~v8+(G;0s7T#ihpKrxdeDm)#L~J9~`&51fqznOIiHwZH>k6|6ciBRHxA
z(Qv^YbM{WJZ!9Q?sl4Yro!Eb|<6NARUR4WgA4N~zTAEC+CNB%0Ah9hxyYCbFukh@+
zU`zybgAD;>g-k1i2!wNqNvka~4y5Er--ST_i+lZ7u_7T!=6_wGp`_LeVV0uw_&6$E
z6(OWWj`QK6rV;ytD~0s>2&u{tBlEwh(3pi8Ybz|8L}*&)RY^k)0`EGy+TRpd2OJC+
z*9ikMxQS4K1BeH-lTu->0R$;Xg)R%Ay-Arc$?^v4x#+(ZS;8(@rIbeDe?75WJi-(j
ze%>LXg%K($JuW`o|3na|QI?9e8A7v0LAi|u(g;&Ez0NBzgi2NZ*Nw)+`-1=tqX9?)
zK?iK40URg?U$C_?1qEa4dpn(U&-r^Q>jtjQ?Wm-mG&K~|_O5c$)1Somaj#b<)6;<x
zh^rmF1+fUJbqhpMq$-!gKhPFtsX@0Qmt8i8IV7Jh|8ug)6gqD`dMq~X@xxIm7Yp@&
z@l049nVV{id6CeSCeMTOKFGO|0m=?wM;M5FBM?c6#@nE%P{aF&>>wO6W0PZJQ&M7M
zlRqyns#`k0Mi-tX(ACxH1X<y_ngvVhipu>R<YRIhv;j>^Gm+owwB(MKu>zT>d%=Q5
z;d0^FmX74K>cFQk&kcAvwE*fXh>ifnfd~<eLM@nWn>Tees1$rYP1v)rv(U`x6w0q*
z>hULnQ_w?#NFxUyZy7nU^AI&deh4oP-+hBWS=(B_ToPXHZTFOjLOtRPQ}aY?On6~e
z>zYojDZe0Atuc=%j8(Gwx`mTQrP&{@Ob@5R*obmn1jE`aW9pVyl$%`c*wGbcx6j1k
z)gR5k!2#^Y+|E`9Pb)Y<NJ~x-O7rra#fayjv86%x4>(Q8t%VnA6|4y0cYUsGa1rGa
zY9tEDbY<n&%r6-ut{p2I)g>M~hIuV5Cd!3q2FYneQ>j{`8>l%uot-&n#4-j3M}9Zc
zf-k|?v2a1Wei(u1BezFQUJ79?16qMX4=)!S?1?YA!(_^wGO>|LcSNjI*e#I)RSN26
zOLF8I7JpBpRGLmj6k?EqL9p#1gzDWxf790t&rc#NX{6j2qF}PRLGbI%fzFWx=R^}g
zi+cxIIVZ}{XMpM1$hclk8p+)ts1ME43N(5v##ViJq<ZG~;;;yLh1`vHh_sYN8Jc)M
z<MyyjK76-uHvNrUFNn2R<OZcIy^PX|DOSH=Jw>@(0*sXuLSijdHlKnWn=BH9iSFp6
zqbWc^?^dR^Z!-Hu$U=aYa0Y>q^kr2GKt~5~;`XIM&t1?G1WZmr0H+WI4nJHUB2IMz
z3u-~Nz<v%8Yp;g1`BlSg;6i2Omkmgh5R%p+vx7w!ZoB%SB+DJiaYlq7nJ=3!vlk*`
zT=E^3B)w9qlnH5-#^*_r>XLKp+JsPheK;$p!o#K9ozn1dDh74h<#LTBCs`-eNi^1K
zDJ7P{H}%YZV`4iarHx6eVeTB65VbnVNK2XaM58|47?W*PX=`N(X||D}c6Kt0kejC6
z00uKzP-rk1(-LG(S(MB$T9!!?z<wW7i=SryLaLgGZs9{e;7q^+F=K!@u2z@O7G_MQ
z2=_o+WRE+BZ@Weq8b4i@UD%xystXgQjhR`gPB%uW)y5cWU0Px^RMmzmqI6=B#5+3M
zTU0)tc{S5w@Cm~-tbKHbn9(U2MA1r3WU^Yyip4T*l};QHrH)L>i7|10LoNOR=s23d
z2SamoB<xK(1P$fwRMLfQfIQHDm$SdWMjiY^l6j?C7oSW4brwqO7F{SRutxx$2=-&q
zQin{gj>}2mv0o#hBr>H$rR&GOTDzK}0zyI~H66e*#Y|y}jE3kTNJhQ4KsJ8{*@5+3
za&iiA5%j7AKH~(Edqbm!MpB%m26O_d)$zb@gCxo2!9UxjJrcV}5>A<sgjH%X7_=Eq
z!Sz71I5kQ_2gO=sRi!a4Ah{GAM<Zu|<P?K1+G3KE1+3;PEyyzwnjfI4H^|3(OiP~;
zU;-wfd6+!zTtpKFpuxfu4hJxa#&AR7l^YT^>2TZ(k!<Md3eK+C^OZw7SL|>^t_hbb
z!dDeF3I&ZtYASV2WcbR}VVZSP6>u?Ja}cp#;hPE-3VB=Q0?}0=IHKF7>VspN6)qq?
z{yVS3gn*}S*iX5PO%NuZ3q(|{Quh;^N1cj52KNLAZYJU>bb(GKOgsE-fET`xzp+b~
zi0l?4eGFt$x>#%vmxfbDTFfeA?UF?i2_i`tkp7sMRm3Jp7fJ16F%d*m$m5h=x)jJv
zXioH^ihu0}=x5FxcujOCpf`l_M}lqofc+Y5EGhLNoXa~Vw_BnQ*0i;(S>4vQx>I8Y
zyQ9*Wf_7(NUH$T*W(N6r9DU6B#X%hLxhr$OI1sW~fNUl;ue1UL0|bbA!t4(HF(8Xw
zv?AP|s8@%=nrC=KI2FaHP=HoYi~Kj1Oq4|`#^pkY!rwy%pYqf6bNKJ<R}hJit#D*c
zHWD6l>X2)I$Pq>8^+A(JE{{+22iK;RC{_ITHLZDxdWoem#x%yjCMd#^k9Z54^0KEH
zV$(|!MAr07OAH%X*KJt<dY$r6@Glar)iM-vi|h%x*)<u?^sI9dsneSbDCTrmJ?O5l
zNo>aJE*`}syyx^58NELWChjSIT9CY`rKhJg!<m_p5oJu&>Wa$rx;$f8xI_}kycQ~+
zyr{N*na1FO4(U>f$TY9ZEQT^JSb!$u$$>w=2-;YZF960Ovkw?pV&;imfbOb36aFGK
z)Lbv7+nm}RI;SIzVi;kKDKs?#on}i)4G4b=)|}HI42?9%ShABFqt_2({EPjB)5ipU
zSWJz#akB`BB-kcsh!*HBNoL2z8_=5(%n~T)2yobZ_+MU+w#6(Pksod-k4kivr|5DT
zW1=#06C~5jC2o-+*AbhQ9ji{VEmn;N_J;Nap~|vCQK*DUrD#vGws5i~JdFXn5z3bP
z#Gzu!!!T(`DRCvP*Ao6ly&r-<pa(d;1Kxm_b9DNJFP<n0s8t^Hh5(lE0X!9?U{zlS
zoPfiHNS|mIFOh(WJf?TpMN6a!1z@kh4?qFq?*j9#Vp2ilf)1nb*GNBb(aZS&Vi5%u
z0|c&r0sj1;LrAWKCrm)s=JJ7iE=pJT+X)+I!$~}IyV@WQ45(edJz@o~c1=`PX<;%*
ze1YB29A&r0pthV8(8Oj=F^k2b!TNWWEykQVhB#}S`2~$!Uyw8%bTW|K4M)WMooHbK
z?+&IF{HjkvAWKEs<rBL=*ht_BXf_)#*{{3>PUG;qh>m;6pCbkfq0=WYc6M>7Jx;$-
zrnk{{c7YgP%Qxz6jGb8$nqbv~T5E+WJ{5~Nyt4S~!581NNZ<cSK&PSJcKX}Cy8u=w
z0Rj&YnDGB6zySww(L62dvidKIKppdtcZUx^K3`&w)5$iG88O`=fE*Zu{#K?J6#h=|
zZ_2?_66rVwq5Tr@cfJCDCjv4mphgCK9-<$}+9T0f{Yt|o0KE-TXn_xjgyFBsi(6WX
z%lZF1%yIeorKY$MBjaL24OyyOks>@%HByl)l1tdgrmXbz>~T%mK3{g-2#2$AM4{8;
zNuJRd6*VRjTK@p;r!e(>TR?w7o{tV>>XoY00gdAJ5i>{N5vl<YPMh|FM&RYsm;uA$
zF)efpwTjAcV7AsI-43lYC7BXNjE-d}ol+B9tJ4;h>GT0zC-qDxdQed$M<0Pcl8K2z
zVmX(F2J@yt$e1A1rxc6Kb7xyP6{r?#8;Ek0627JUHn4B6f-ba>E>571+;A8I>=Pw=
zHy;kHBddHKwb=toK&#YvvXCbQN<&HN0KfWtJVjHo!clWe#tQ^uCjLdZrm0y%C9M=)
zNXts_d6?EjN?@DZ5?|LP3qy&CBox8_kT<O<N{LV6$M?ec&jRj9kG$Koe<BI`J??zs
zq4HQ0;%DXFDXps(H#fLbEWJo)&8xLif(Tt>=vZT<L&&@q5m~jgu4bvnRbeVHd#YGz
z=K`e>v<T>Z&gKe|2I&+n7dn8p2PYGpCD0>Y4LMvg&Bv9g5B5Qb%LIOj+M<p|a5LP8
zze$X2g077*sMVcaI6k5#kEIsPoGB3~%?@dg*iNFLnKQGhr~=}7c*x{)+p=s9wVMJ(
zEoMUF=NYOz240z@3Jjh~QKdVN=o*OAZZYNfXTkkoqq&%vG$##u_2iTUvPlqZ2Jz-?
zfE*3U72Dt)z*ai`c~56?PW6bi?5=0!?P2;CH;tsz<fg>E(X#YeBkYMeg7Qf-vKlLr
z9p?Dl+Wbk4Cac0KR%X>V)+gEoX?R*vq(q;Vli+d#9N&XpV+4<aj6oGFO<)K_!Y*J9
z5=dBl#8>laAw34@ft~<_P!S|31|bZD#l0CRIrv8s6|)hka$Q)m=wPn3xX7AwNR%S+
zhzt@2P0vg#oLo0WJZ4aktU;mSmJVOSB*nyuib)B+j#Ti<=ICO5T(C^_o`cvh8+3p#
zq?Eu0OdD^r3<(T5_grQB6(7^ARg)tCZqF!OUO2X9zF-U&@CBSpWMq&?pdj8Q=S`wm
z__R^nRWWv9N3K%sj?#js;WlW%=~+Cx;<wz(vdPOv%`}C(9a*`_nOVtz+w-6|vcSgG
zgp4DaW2o$bv#jlR1$o;?`bG}&ia95q_{yZ@XFyOj!vyupr8w|z<shet^n4AS>JTpp
zcZ7p=AucmaO1v2CqK1m0?yZE=2!e8q&}@N<0zvj<4;Ew(y)@|V1bt`lG-fu-Xu+?_
zckdq|K9RBCLCnPE8;B<aKBO8}W{Jq94uk_FKuEKJuhAd0_>{oeWHN4|bRd28j|q`h
zyEaTB$TQOk4z)*>Xs2RE*sAC#w_E;{NUae)7b;<5ZY8^o(2k*%g4_q9Lq*dqB@%cI
zjxbG03N16iihw7Q8ii7oO8k=avFbWad;-ah{KB;1U)T>rvWO-p2kY=<0ze2zzYxUp
zz=H=u!e_V)#MA`+;G~mxHCk|tXyAKN#16jlFOf!%BrH^sD;GrTG!X^zB;es(MQE7B
zV~mUyvZ8g7E_E^bbW~z!+Io>V_Ho5{U0Ir#nXgK)+fySpu#^+bfD=ON4H2n!dx9!l
zLV0FsW4uZ*3h}}$RhP~vLB@!1L1l)7%wZMN);AaQ`IL|@A``!R4!~{$wD17V`=i=`
z1H*@mMr8W!+1~xXOqO*#K@}v3mxyd(Bt)a6tRmV5>}UIbS$hw_sH*I7c<y^|TH5rP
zlu0I&$z;;or1u^ONgyGOkc1X`3q^Ww(mM($B7%ybfQq<cL9Ezi*Rr~{)!ntOZC6(z
zbNQcp-@KVONr3qKK0-3D&AaEGcF#Tc+;jX4jFmxZa2@<nRAk$3<=7;aO#-b6#wEB(
z$O-7s@fPR6C<6av5BnQ)n=ArWvm{Vt3hG)hx8a%|CPsP+*D#Pi2Jk3)Mk72W_KCZ{
z5s_rEB#~eKtGI$c1C<S5f_EH4SKRGztV64Vg^J(xvxB~tMPR&6jz%MhK<x7zEWbFl
z=*nz8{(aBa>`6IVhVfSvo@2}+c$YuPNGG0$!cG==GqXs5WCh;@H{J~jIwWd~^oxIw
zl)i_yCiVz3i};rDUBdeW7>)^Dqxj=$0T#J{nM^BJ3mC*T>_-F<=p2dJr#Pg~`NM8t
zADDF%>+r2)p_K^t*S%mTiQlu5`GEEvh~v|DIX?!0<bhd5)()u8kLY#g1L4)Ve(_<Q
z_K+~MC4GEIxh~seRkLxS_SkVFt=`u5&*sV!ckay}A2cf<Q+al7Weo%jL1TcgmCW7H
zb|{?OptZZN--s;aX72_olAqL2Z!Fow0OJyPE9npPiMhKhbbPwSY!0?}hQ<43Sx1hG
zjSki8SwB^%DVyCEG(Lat&crfqwzQz8d}@2U${YcKwgmrgGtU6*q~@K3)ZSwu110l}
z>k+2D2k(ZP^*9R6!n@%nJo|U%s7z1R2Vub}n>jihn}>4{#r+QwAn9`-HcBJrDBMQ>
zkiJMifGc}&l~e-jd};}at2IL;buz5kXTiu^D`|iiz)T*@7MR)++Y$N)!=2Lv3z6hk
zXC>r=1GsLo!t}{1C%^Cnth>O(nb>E<ASHHA42&Qq8&H~!>By>lbY8SFT3IN2`|UM2
z5xuj>RlvOPFPvf+Ki+^-&}H(8F8_;MT}1A$dHZdd`z!F}R83NnX4x|ME1g$Sm%TVN
zT2mbxh(FHxXU^|A_?;Oua%RlH@4)dtbMOc5y9E_>Y-2`74x~Uty%KzelU$3WI0Jw=
z$#1ZPiq8P^lY3S49@R0hs7CI-v9a<#c{@HcZPaRlQ=ez#r2m|xa^r7rz$1r8O(P;i
z@Q%CD50YM*hZ3wW;0?m!nHlzM;12Y|+%b2lwf0d3<@hJ{U1R2s*wa>Hn#IagnFY<~
zVrQ9Zh+zTmxP?oX1p}2-eZ5$OmO7DF3pJIeq?D6i=7Zi-li0@T!a4gMf4v<2^S3R@
z@>{Ol<vw@A39FWA+(ll}0ZOn5;njp%gqz`BQ|FLTy%7I(X8Ph8lL}UCe+4BnuWwsj
z0LYlzJ7NTTdSqGGNc;}%GrTLEBQ+zTiWZO>OiNpo1h|LVyhxhfJ7VtYQPT=G-SP^4
zzNxEhBzu}$)Y~v>NatvjacS$Cf=M$LPiM~nV9@t#*C4h%8~SeKXBhA*_e4v>u{Nze
znssWW8W9RORbfIxA^CMZ^7iVd(1$qYsnsAW!d3Py{%)b`*F&(_KJLsJG!8$02wUBk
z2|hsfB)geI>^%Sh$R5Qqk(xu;KL`DiL;td6__MJn607M4`A#eDVY4_rzzVjuSkHkN
z0NDJR7@Z7(Rpi;Bpabnk4S!M>4iw+;(!|74^84kyiR%tcUOE1UKs6T<!j+@k*w|bY
zVb83bwD`$}xm{iC{fQ+d<l(EQR@7JK58bt__KAC*O-kwgO0I}aON&*?(A2WLVT*2=
zv;}o_k$xdb75*ppgY<~xJb{pyK{Ts8KZT|C4-syN%@f_?&tR&RMLk<^2RPU%euPeL
z$T#>-0`oBLB^x*dYLUqV{A4*;$h>T#{4csnd_Gh;kVi806iws{-tPjg4CHIs1Z%{p
z$^9^{w9FK)HAK#hbnJR00O&7|KN=tCA9#FWYM5RjOL;WK-|w;ajbPU<Ogqujb1;Jo
zFJ8W+T>IyP`H@nUwfN^E=_~8j#pGqBgha<~93E>;3NsgUILt=>fB<tM8=kF=i(nNF
zr`BJplm)}i6{o*OtAmtDa!sU69&F(fkyNeV!ot!@(eUY}XznL_T9j3r9+(>JOvqFQ
zBr{NxH<z;*tlAPTopEO8$EL7$RaB16mg-;&7>B)CYBxve915rdR2^+F1TC6vG?^^t
zqbiYqW#z7pj?Aj;@5_rJ5olsuWhmH?>LXnd(!i*c^C_*0(1q<8IU0HD*cA&SruJAf
z1Guv2#?i42<INGdK{-KV8C8UTf}bKGp_UDj$IOXH1=_O`$co2ia#r9^6U<9}I8<yy
zkb;^-TU*na_i|!m^YUV2b8wGvgnqEQ3LFmR1v`6@zbD+u!JTn&aikrzjCFA%p&bX!
z!z~g{-p@m`UlVR21~^cYjQh@XJ9V+}b71CJb75g?TR~wn8dW)TW;gzzWn+R&9-xh=
zs+rM^94&X){S0P2E|D&7Taws|1#PW`h0V=)-|WVguh&9gK<><uE#Lep?bpb}Bnzy7
zQ(ZijIV!mmAQX*}_)p$35_|63y<=n@KSY9j^Zg?DbNFKKM!jO@3iv@=uHO?6F7b&z
z@RN2W4%WrI4!WPVOAt3O2E{subzQ$Te2V}Rv!_pUu4mjtCHT4)%%p)$z*`?SQqGl0
z!>4<CPy@5D_lP{X_XyP~qUWSwjYAFwCzIBLPosvOuh=m?kU<~b#hga3!MkARAF_eX
zo^3_1ecO|RY|?joKV-YevS;6Cz_>uK^?ZwLIm~G`W)3{U!-QUAPLuaYtquUmiC%*t
zzvtVpa@nrl5Bog>mI!?&2Y>u+&*|JbES(=fTavrEXJ8)@EGgLC$#$}wP)Al+sjza-
zxc>g@!NZ3S{>oTff4{V7<;q2u7|Y#TcK-LjJGb;q>v{3To@oRg?|Ud0K<|N>iAn=U
z3)#BLJp-?B{hhJ!uOLV8TIRI(Ej?Ry0@y(3(fA(rP3bovog~@{EG}YClG<%VI>3J<
zf!xMM>2<ENZ|eMQpN|_eX58mC2xG$Upu}L@Gr+a8+VJ!5ybYTj;@*Dee7IH-j6ZNa
z=6Vc&5UjZF9Ui_J0N<w`_@E}4TZ9Q*9(_(~l?`;A{nQN^O2qF3^Kjvw{@0)Y`1@|a
zkb@b<3_}h#VEFy(-2sV)oG0vquvb^8b1%|4zPb&B2Vez+8rcU+l9EcuuWOZXgy=ar
zWByI<kpb5I>1uKx05Wdao>&USZ8J0ax8iNt)1Idtp<!r`lN^Iav8R8OKfFB=w{pGK
zSuC_JYSYti(Y5RLTLh1^5580S#*tnRit9l-5N`0Z0>s{<0qBGG_92u2r{@N>%>aK{
z(qn=@mQF`vhyxV-JVp&!s4PTkJ8%Y(HE;om_=nBv>YCf|<nA<c<zpdX_~-G%C%$#4
zd-RtAbljftU7cG-B#v2J^Bn%ABQ1LfLYIcFoHewob@<iU9;N|Z!Iq)TvScBC3>M@_
za0lT=Ski|%5)6H4b87m?<mAc|J(bDHrsNZxe^YKj&#3Z$)l^RJi8Dq0K>89ZaWUuF
z9hBF7MsabaDdzmMn>Ia5e!JI?9lM_VGFAMAXE*WZBq!V+G#SlgO5j~SZ$dML-l2Cq
zJs|pbBm7y!bdx^V366N9mbV`Pl|-)4qLQR)TS!x7ls;%LXH82gnUPphm)o%a)>%e{
z>d^BlLre+qG-<m8+77uv+YkA+eeE%5J4C=AZ$5yk^#}sYs21&x@aLN)Ms#&lC@TBw
zZ5C+v$b}$d44Bm=wRr@GAWvv7_YZiN4UVqU6Y;bH?WM2tc|C8ZGvASyHi(;XHMuQw
z+D|8*z>Jk1ruj`|a)wmS%2dP39be*&vLdjY1rc>m3}IsA>Y1^*0ii}?Xh3eM*%{G2
z!Z~G%bHupFY(EH-Xl*TGCY@e~zs600fl%(!wC?oCOA4vk)Y@t?OBFRSB{N1ZUOe>s
zvdgsnZfJj(yL~!(q`<n24<K$Uovcx)5I^29yP&=92&cJJfTN?RwG{&K{IVm*0W|D>
z+Sa9!zHltKT=xCY#fwMJD2b^d5D_{<|JkF^K8)aYcl%)8gDuZfu$U$*@uGny`J=_h
z)R2BtCg<T{kBa;6g`+Q&0=A}!QQ-lHM-TxTQpG(O7>Jwj*8=hYSBzx0WIqI4j1VF+
z$w)?7oF6lIpvf_HY7pJQuT_$@8!}~K)22*YHEYhS%eUOo(^);N#*z>?rDDv|d2^R`
zt(-b-`|_z%cOkrb&isvQd!AdqYJShb+=9_f@e%3*)u^$R6Q_>uSoqnr1+A@3%Vyrv
z($WgJQ#0YJADP(_5{&J!%T+(xf1KfPsP@{KDq?c;&zbr?XZq3p6+CAWJvZ~(PmBYd
zBr<20JHW9)mwx1oqhs}I;eVZQ09PbnX&u8YXoZZ-!HKjGU0>~%86GP}v7G$TW3)oh
zG=u$=zUI~nc*Y+%0302|W0*%|>5_>AdSa!3yPxvm4UUPwhFEjFo&#2dqnjK9%evpp
zJklL?caJ(|;kxAJ3DJjoH2hK2;T~<wqBW__k1pCPZ<}@J%roYhE%BRfaj-KVHcfXQ
zoe7!Vl0dJW37J72>>R&2n0|{}QxzW+XO1$5h6l%wsESoZheo=O<AY+&Q6a&hrugAg
zisJkyD9w(9$PkBLY(+!7!4ei3WlmJaRW!uv&8A4JInfV}<H&VuNUYLPLBFC1u_e<t
zfH;7M{UPuRehhYdJj9;o!OH6hz#Xg^@;HGU$<SGi91=dm9|14!xFh&5A`Ps%Xp9b$
z5t;}HsYeXKN=^uh;-BWPeq36^qVCk&UwXv$?B8n28)`l|@#d@dd{dK@8Xj761wWNp
z9X#^T&apl7I?(J;ZFEI&>CuymH+J0nz*g?tUqTdynHj;6t~}kXX?NH3o=;~dY2>~C
zNN4N)r>uDW&-)gqJeKwz$K9LuxA5K{nacsLY)uSvCa8Mkt?OsDp4Bo+N2+!9(qprh
ztUGmP-dLgoOsIv~$Gitt9-aBXd<IN;W}j;fvx59GEvxXVRlra8;jL(!<aHA9?;Z<z
zH9(_KK{SXdVMN<<laj26<2IUf{^8rhqAC*eCMV`wSXQBWVUy9%5We+|x~%G4XtxY+
zWe(H#IdAkvYC{1RQr!8p#T?E_O0+_V(}rNZpLs`^ts*fOZ^=uHw=q&~qftxSuk^P6
z(yb<?A$;d6wK-L}i9RrGe~ny&K5k~h<i|N9c!ed%8VQLHpkHox4v0=1k{|DV2w%8>
zFHE#QF*KJAu(nt4c>)!H^CQer`e<p+WR){{bxC@-9r{;wtq7f!agrd26eki$q8tHB
zWSI~QE_zC^M$XY$#Z^v`&K%Gb*s_xN4|+xVs7B{{-OtJ?m?1?eSK%SopNdkVG&&}O
zgsa1ROu<}2bBVvzE(abXCLVRV5}=t&ZGIU=ZEZyver>Ai=GCj4t2N58b?xnSW0hMb
z%$qlX@I3MT!8_PV@D5@d(Af;2I~)2-7btWCyx09UmG}MLBlkVFlQyx%-C*y@J}vve
z-oI7mQolCPRG&9`VTb<v^Ed_!yLEJSzkZ-E6D^iR^85Gxua4&LB*ye@g5c-cQuG%4
z0j#M|Kc{=P$4`2rWNA^E#8n4GB;f|aP4}FbUkD&K(OdJ!h0CpzVe@TtI|LS33aZNH
zu+#O)85*S`Fm#kDG%>CPQiP3}HIKD#8s8|Bh1A`WWVKfZ$pb2LN_u}-J6ms!ktt+K
zUG4N_t9?j7P||*$eiheVmFG(rg2oz3`Ah_a25fv_3EpAJ$Qgc)4b+9y0(P2e3U;ZG
z$va^i_#sM*5?!mylINeg?aE);9cy2{?;1|&*b^1ADNB(wefb-kEwDr!;uxK5M^C(s
zjOW%|*?O>7<rk>7&zm%DLS931TDd*Jkb7vcgL(PCPaW;3w+7pD*1d|N(YX~N%-F;P
zxp5Kx^n1KauL|<lq^zF29R0I*Va(7&C$H)wqLX5~J16ga@zJjC%+SdYy0UyJ(aR(7
zZSphHU%`J72cz+1$#kKoyv4%zNMenYuxj#`#QRD3u1H|FF!YQpe`{<8wG`5hWP;a*
z?7KF_kYF8HCv(6V6&vuLz$69iLW2`Bz7hLSZnVS0@-ss!w`{-X__NO*zi0cF${|cD
zT7}j!NmIZbejI+(1=+~&*1c!W?7bEFWf#1vQJU*^FPVW))gp5@GwYz;za~_waviMe
zDqmAIz3$h|_}r!G7Dbb~8%5T2tYez-?M&6P$B*pTQ(93`x@X6c<Ikd1OseZIcsXiA
zKay79)%e%!0=}U)78r*uL06aJ#k-ewpt7Y*oa=oY4Y4_v4ivq)KFReKQ&LyA^nv%6
z{t_tnd*9T-O109p^Rl)eCw@Z$dR~mr6o{rAEg2_S_eXF_u$FD){{rJP5WP)e;OPiS
zkWHcvz?gs_Lck)FNr1VEo?MXI3`WTFB4Atxt7e(-WHj-019!>*^M4T8xV?7sJ(W+O
zzb&b4o(@bo;eVDjq55FclHgQJ`um$(chsF(yGEy5H({6DbvbKIp~CUjn8vEy^fetz
z>z?iS{?`#xV-R<-PNNP_D|_n?QGq$Nw5e!%R_`|*Z?0`#f<94kcs|~DFiWjJR`_&M
z*pif4i<fSGnCbElG~(MoK>O-Ay!_3J$$xrQ(NsKaOKF1ZeROsAyfqIX>C$J_s--c_
zyJZ1>YSkw&5?A0iW#^?&!`wHKk9r29gUs2j<O8-OLih#@CK?m?9zoGlMm1Pr!GJ88
z67H6rA6aRQcbzY`tHNFHR$3DeF_D&lTT>!KO_0qg>FgJ-^E+MdauE@JuH`w=jjop5
zU={OJT}~Q1v=L1WRv5I}AP$E*dw`SVuHVV81Z-nefltVul73EY1+qS;qq9@u10CR3
z_SBV)(nSOPN{1f6dY}K2fC1kfM)x2)Ali@kfJAMO<Lmtju*jZr^)j6B+q;z<vGd8_
z8y^eb@Ic7~9=JN|K%c*S2PA$sgxdpiCctZV!%W~4`a(X*buX+0Ut;*Y@bd6`?*n|j
z7Z03=AAk<P0RZ7Iy(Ae7Tm&WoS7LYsSjjyeF4Cre6&^Mo7V_5%554v)fCC_SzyZ(*
zgm6hBQCt^S1L8@HuYvL7ZJV7>j>)eNRs>iE)i&v`fD>OF2=5m9D|~u!!Sf2my|~8`
ziT`!`Y=iX;62;nw3gle4Mm~KZAuS8PVlMGQ!gIJ6Gvw+1oDB5&Kf)=%BZg57vzKdp
zvBbkgt_=*g8%~Ns5k~`*JYNIEpn@dw>)_LaM*<&#!IygoJ_LBYxarR|w0ZbLTf1pn
zVvZ5o^J=~8wI|{gp*gbXK9FwZ^`ED2q&+d-g*JV0?!_@V;`=DzT;OCeM?hZ%ICvxv
z8WsW9Vz_u%gmwfRkWXK@$eAxDpm8s$2ZejmmH-36g%|e&)7#T)p}*&E&Qs#|3%K{<
zTj*zB{F3XeTNesSh$8n7>jMF|1P+1T<kJg7f86%f0pd~5i+2yc-I{=Y5FiH)qX3T>
zHUVDp=?kNPBLV@zkNBKi<IjcO@U)_upzjbzU>p>Wis2)$2<PO}JF<!45co#8=7rM-
z9$)^sDJ*??NPvS}Cp_ha#ft}Dx$T29F=x3^M7e8F<Gw%{L2C<KO+E$4yyLAHBJVLd
z@`aFK$|GMMTM3{Na5ZSy1Z)vF`@+a`lt3ln(+gK$PA7K&Dgg!nM+}-9XM?7nn9l`F
z`SKEJ&&xAnXne3m=qHvs3g69nTEL9Zc3*e~=A*taiQx0_kr<f4$-e+gUn&U{6S&M5
zrhzFX#uIsh{0iDrOfrDdJ3{<_u&u-}3S56Pj_(Vjn4bOl-UBI5**|Q53KZtKi%?A9
zb>Z`R8cJYwI_mJ_+fD3lfs*1j308Pn6SzlAIS~hW>~4Wx?sfqTDqVw^9|`UE<s{*p
z$AK6QF)ZF=awMjT0Fju3;Fzb#O>jcm7Vtri$uIdKc=2+ym<9q}ytolY3?3D<S&EXu
z%*}-M1Q>)*0s}cF_q`nJZBxvp{IT~Q!H=K|-Rj3J_5d5Pt#5)8flgvr2pr_xixY2q
z-u6Y;d^HYFi<|0Sp%sBE#gKS0A!>zkCFw7@=F1@>s?gR&booPY2v{KPlOHc<c-!;g
zMjx1X&Jn>v#YP0nO=v+{6@L3;gY;VXy%81!Y4~I93OyG-1vtF?D3%NHu>e!weghmt
zGX8+BAbl3MFK`Bd#mkFA-vt=RxtBV^8PyZs0T3V&4Kjm(N$9@-1NjugN8t40#<zX1
zj0i9i9P!6ImOS8iAtYLT5d0zVMSoaG8w3vV=YZ`~#_(zQChcCYO|Nv^xJ_PS`cQ<*
z2I!|j(n8!{@iC!;mp_F53;iDGoWDoz04*pk&L6lEMjcudDTHYU50}8NVwi+uU$|}r
zlb1i-Z~+h=W6}*AfJ)%HsXimE55&C!q`s0w+Vf(hzi#s#ZviZdvBAPZ;J6Vy{M=rk
z68XG7JOZ_#ZIAd+U<Tno68bLS#Y-74=J~#pbKzH{(V#{C|IK|>;x<U%c_|UzDSQfj
z=5g=Q3Ic-R^Z&+!LhFLw8n~xI>-{lKt_c06;vhyhfohQQO4=1*AfEySyciMMCZE^i
zKyr^@tPhrWRZfZT5!su{1%XHm1vw`_<l4=#<b|RihTN(Yz!{W$irc+0X1s0s%4I*S
zP)vxeKc0OCGoA<-5uhTU<eFDY@VMt85L)&^Ch!V?K%t<22p$GGru1!}V8q+Dw;kX1
z-7tCVPN8*ozX!>qLfZlth^gVl0qL`V1EK%obK%$vtAG<XV+dlz&)Wt88-Yil1A(b8
zeB_=NM}vcpJSFII&&c8t9-!Bt<VS#PV2B6?1PlqE0(QJmk|V$nWfU=n+_W1M95<pI
zj~Q=!H?qcfuDTAr28j~^7U5IC(ZC$!<q|Jk-fIFRUgUV>>85xQw<~asz(u|s<899i
zgBM@qs1K)5AO^2f27-i_YcYom1O?A60(W?^F!;6yq5|JG>DNGQim#Dlfd*c&1vm!D
z3j_6>K*Zypyj_68i*GLt_}-H{{V^bz%Y&Cw0TX>cz49UMxfmYtbvH&RDcpL49#fp$
zM8}g}_r-_+O@GTz&=l8eU1-*gi9zU5f%^&lg?7d8c%|Zcy(iZRJl^}{NZ=3(k(W()
zCcUYg3Rn?CBpj2^>(i$%W_+c^cNTMVJ`pfMK85y$V=rce-izB7u;S%c@!U={U4h)&
zcoJuq7DLPn)HH(d7P9G&WWa*`l9?HCG<^xOk~DWZD+ww>bi0}To_Qni7gakFlQREO
zkHYKs<NvshSpyl2Uw!jT0F=^O7Zv2<&<m?ZEm=43=z<0Ro3nMJ)u87dKm8_pGE!~4
zIxHpw;wUrmPPU1?gJdt_bKA$b8;5W>KGKiu5zQufD18B7n<{H&mA#z2+7XxbOxcCJ
z@<wMuw(Ij4Ei>Z#<N2A&%wXo}7_I9p+E!OQY*bHU^Ym$-POB?(T0$aJ!EAU@?gMC)
zIViaIOFLwk^5P)p1~{<MM5tgfi*Nyn14+F64RL}d|70|xVALZ*4c_-}lL>!^Z|jF4
zCex%gF%@n!xn6)X*NZ;5D!eJKAVp3-^2M1L(Cgw31)MM%-$y192Jw%d0HD9%p9VxE
zngZaVg#tG5ZaBqz2ucY~uf5AYD4j)X>d^fd4qz@4*h}L!VK0a+lGKqT@l+7&OY_S@
zL=}yPBoUE32S6Mf`=CBZ9h|!2yZd`)9^Tk||I7Pk;;$PN8mZPC9H6P(e(LT|w#{#S
zXm(D~ZF8UdCL%Z}Jk(yZY3ah_+ux7XCKf(Db07XBuEA(V4_U){wtRB;(ih^53FaXq
zCe1tk-i{#<BTV@4+E>hv?6VT6KTG$HxFID0rb0+5iDo3w(rmb72a-Gf3od%XH{q&*
z`O&DW8@Khgj!C13o>-jP)lkyaQCy*hKx|WZu)bjAf^8i$MrSnYSAAMjGI{;bY`fAB
zrnGi;4jHj~K})4I*qGSTk`R@c(i#zwV8hnJ!u+ZYGls>7NX@Bx#%Cn8SM0V$N+j2=
z0e-(?ozgOh4ukX!aGn8uc$|GiB4g+B_y;~&5BKXO5-ZK#oCzo;Y0KOd-hgu<RMQXx
zvXyD%)0t)YBs7Dq+1Un~5Rc^Sf|O=PE&Wcmbp6ng_&-fUQUexfmCqIpIWe=lIBCoq
z;o+|zH!H?Xx&MnVl-gUJ)rn|PT$P{0Z<smr>#t9KF4v!y$%;^vCh9VZA7k0L;`FVf
ztfnGzttB{d!MUyb!XK?z9I1&Sml&lsZ*j%rQTXSF{~Qq*BPBF~4T^<a4`d2~{y?as
z9CB?_u=zMz08L0uDs)Ceq8uU2mgJ=5J3|x4^1ac}1Z|L%kSnanf3>hYyU9<sB`ITB
z{m}gftk(Ujb+YQ3B|rTn^B<E|W<g=*Qh&W#o~^h3=RfPuZ~+^o(o&@L)8F-Mk-n{A
z?#wn+%5kO0sSX>rxT_mB(pOB?`e}=#(jq80Xqj4pubIv-JFJl#I5+Ly<<?2>0owh8
zp63BA7qK70`9B5Oku`$sqyuw8G%U!Cjb};NrfWBF8nv+fm*2?cX2D2^JI>@xMp@&`
zwcmbMpeXq6+qE-~oI(va9yz+o@{Pe$rv@AI%es&Qt~8uF!c6Tw|H=RU_sRKQH0qTP
zl?frP2G{nfo!vd%GquZ?YiGhi=Tv4cb2=nJ`Qa<PoItJlXK6J-3Kwgm!OdhBLN>tV
zj$<ZB_koOTRtDH0ww?Q6c;`KzMJggcyQg#b;#EK4CqfdJPe^wdgU5^sHagNLEKdx<
zPyDoMF*^0o>ix(c|FVDeL;u~pi%s>z84tAGF=_a$d6Rln^XIF2Ce52Qe9|3l51`lm
zQrTUbNlZQPh;%XFEr!ns0GPA#T%W0dl*=R_8_-Ci|9Sb<kg<$xXM{RQAPZ2sPr7*f
z>ic_pi_jc{bdTLylIe)cD#;zPsl5r!x_jrT7f!6iM|44%2(3PYrW~2tRmddyTi7kg
zrZQGS>hrjYgqRr<x8h5qrk~t&!u3O@%Kt$(TwFQe&0WL50~g5&&BI0aC;(JO$eqOl
zMQT-%1lL(ydC!E^u7`6_2Rl75&@#L}BQa;nZsfOQ_NL>DJFaQ%&vmZoojbI&kg;)o
z%(TZDldZZYBO>(nDbE)UTiiAi-xm=GX}-vQ;tDX5WuOz{V24eoM=zv9<}yMdA#a>W
z@JU`&BiyE3=)onGDff`<))0pNxKzrjlkt|gYKUs}TcuO>)d~LUdS-@eg%{s?m2={y
zn!Mn&Y<4fGjoPrxemIxO3Q@Esl8Y3niL0N68Nwm2oInjOGD8(GX6QTUJk=sN!G{*C
zB>mbo*{AGXVDAiv_-l!j*Np??0P^KQHwhBboqWkv%1(rAR0UC^1oAGsAL~mw*{3B@
z_{)eAe@Ft~9w3$ak4-JMqA*KwfKCItB(jQW$L87Ht9at-ZMAzc<FvVn%nNW|mZP&0
z8gIORaVOT=FLtd!M4RZ8I_71a(ydyQk*?f$?t+K-FIfVMQg@?52m@C};x|R)huVzb
zgnb=oKSnactyR4A<OP5vu)7g9XfJ_3eRZmERmUfF9DotzuX~9+4|h?*-;gyJ129W0
z3?LKe075w7V`GYWY~H<7`>}*b3>(UOrx9K#9EeTo>qR_MkAK}77hH~i_2CUh;soAE
z1>P7ZnMo`GUpXa8;wBj48KEDFJeO(WOEO;dmvULEN6PE)Zr}_r>x}l7$q4I2p|A+T
zI+Qh@1a69jOaA;N7@5!{ZKgUVdT3~A<@J<9oz1l)o}<H3Uq%WE5ph+>%R?+?8L~Yo
z;vk~Oz^0SW1O1vW8RpR*U^|e&cu2@V%sY}ug4jloyp3*fk&)ch#E=jK35*bDmeXBU
zP6jB|65S)8S8c}!6RRK9D)3!*9sT;7dk)`q^qY?kAJn04g>I?RuB=Kz<KwH6*J<Q(
z?P5QzPTAX0Gxl6f<)4R)`O}kQhES5L!x=4$KfC<idzVopvc3D^ix<Fh{V-e|%@Cs^
zD#&v6ua=-_#H{@H!=I<@!X-an#Mkh%L^s0NaqSD~!%%~k_RXyoXy0tq?js`_-!&7Y
zxu!M;B<;UR-=MQlh4bMO*v}tXvc;eKAG3J*Baba#vUvHq`<E=x{LcBe$<*pVPzwH*
z;>0dLj`MGpt2BYGl<dm2ndt{IE7xtP%yJ992DLx8ZP%WiFJ9Vp`}$RnqfD(rhX^gT
za-AzvC)Xi#?9eT{BgWtlj;y->-j%$*m%k}pD=7u(ucH(r#vYO16l5j#EHzyXkl7hH
z`?^DbmDYYBS$4CLKa$hI62^P^n=Ah@r{<m%izNZiPB4eXX2fUrs+Bse-(sy?u348{
z6_3UzRRQgm>J&@~LP3#{LFfTPamX0g`)AL#xZYK0A3c>sC|3}^rm1=9(xH(0)EQ<1
z^%Wgt;bJX8ye$~54tG7r{3AB@YFc5CjA8N^h3mHh+!(I5Gt62tt`WJFv#-EhqnK3o
z1ACY6C+#K46?(lMdNeoL4hYqQoKZeql*y-^Y%X0g+=4%{RP^+I9;i{vn*BM>uQRFG
zg8Z$;foip^)nAGpy%-o_2}C8j5vnRYbjgw~+%5IrydjbUm2Hu~He$pXSsru?h{U|6
zlk?hJr_kc{=m)E{_XSA1zYG=N7Yguq8l|2=jXdq7n}BvfutU%)k;Ea`@a97ZB0~<V
zKtyZ0bkmh5PbHxPUNmF$$wy2f5D15u%?=<B+O@5aS<4*|P>C)wt6eMc5`um=@~NEw
zJ43l5z$a-NDjJB}<}n0qTY-5%vbmzGzify^8KVAAIj|q?ACB*;=s{^sg{YAYcK0zE
zZN>}mkE-X7>L5LWyN^GD@1Y#B|FsZ}D`X<&4Kh#V7NTLGqvCX`S=m}UDF7v>IaLt{
zoA~Ju)hv919i+?B#aJPK>W{Y8=?<e@YQ`^Sht<{=Un;Jx4a>$anx#;lXL_qG++c_e
z<fPH)Dg0SfsdW^0^`%yP4LuVr<pN`&wh3;Ji%P~<V`4H;z~41xJs9I_bBxB0%(Yz&
z`1M?kf{Zu{O)kn9F=lOMhf(D(lk2-GD$ubM^r$mX#uODXEAXaN+*wi41*3{Tw-$;q
z1gIl|@O)Gk;+plhzY!h8!W`}zw+;LuB~SrnI30nqh*E`o#r#~2PJ2k{4x*FbgxcLO
zMFm{IQ=a^?B4ofr@ZD@c1c(H;EkRQ|DI_4^>*S#PD%<hsD*c470|G)Ol|`Gh+E69S
zhM}_U)sgldPI~(k!){a=%CgE(t=5F^Eq-^{pEg)4hrjyb@DLM=I$K%}M=2Siev%Hi
zv~-536*6f+L1H2bbv)6b(N|Qk(+p2I@Rx~+1p!i-g86r8hT)t0<M61%he=;KVvqQ(
z1paP;+LhBu<sRTNj~e22%+0M4ur>y?T76X(;R&(Av!=t2E`F}!xAM0GO1;)^p;qDg
z5cE-XB0gxZzMc|`QE1i@wbq>gYRzwnR>7G2sx`*oqYy#jT>D(VD>U<7O$N254o9bm
z;)+JRk<wqy6@{yBp!G2F(Ub_|MzhAYp5PO7pu!9?+XhzcWY}FSv5U3dAQ0-&g}xZ|
zT=u9)7z7ZcW`+TTY5)%|73M1~pdsZ={v2+T`fVw;;-AAxuB$VTyVYnwB&bo1tT})~
z8=m*55xi^JGPG=XIR0xm)gw3t?~?j8?*xws=uxExsqjx4B|iZ6*Q=}0DvjGnCTeyS
z`Y*477NJsn0pBlwZP+l-$S9w_qY3zt_y8SJmvjc?A8?N!w8R`?6Udw6HjC+ao~c1#
z>d*-;*#bzedGxYV>e@W(o$7m)_zFMY!Mg<$7Qa`!xO~#+n2chRxgit17ho|2q7wmu
zp_@T@<OhZ__-dHQMCCqnX)bh?bvPZ>dcO_a-4^C*q%DY)5&&48xQ)AwJx_9-@M9f;
zl^qaPvi)6{jQfJh-8OgR;gaR@$7FtE(@L!P2e2fgiEa62{`kzM;dS9sX|^4W4+w|E
zTjdIcW){a4M#$CZgWko&ROGlKM&=jEuEFUWD$<5j+l;80HHWdiXN?NA1YP?lUI6~5
z5=j-2Z1+ZIc@`-SM%+z(CY!utrk^wmm-$JkbbW8&sPw4xGF5IxD|#>_$PrRdUu{QI
z;;WS=eZV4>jH#!WqR~|T(n6I?7Feg85Fb8zp<#Gn3Cal!H3x7`a}oRR42?gP!B|!3
z)h*mDo>O(m)epmhB1sClYj5KpxP10bu%E<z$RvGmn@e8bl1EPXA}IVMTDVA*4VUlY
zifzI6JbipyH_9L3$BwKl2}7#L;sAq2F;dB)<DLt8jk3{?W&O5>Y74q_ajLR66gp#&
zUZG}QO)LaDAcIon@?(DWo@A*NkUc@dT>B6&koUltnny-dD9ym9B&U;DD8>S*)72)p
zMu!VBOwu2oEMNd;Yl-mFkpxPPP%9UnU_7QGc?5psJ!!#tHJ9c(Rr;Wi2T^N9uByx#
zl{TvPw^3<PPM$vZMwS$QrwWP*pCUc#N>qeC@@S}%k&YP?mdT|R|M{W1Ol@+2j9vfE
z&@ln3jNY(Hvy%%jhX&$HC4s~Bi$;gX1JM@gJwyvIE<~>|28TLO3MR*R_SZyJN}8tP
zB2IbLIY|*<Q~1fiE(-~yIJk&^kY0gtG*<$$E#QDh0T{6a39t*j9}*~CJxG9L?Oqfx
z#8piPVK)Y(S8{c6nY)kJ^Z|j1#tPIuG0ER)4~{BvJzf$8G}b1J>P8!kiHQ%#2RCzf
zx>j@QHLEl-q}*bNMdpMfYjYjSC^^e??M^KUw7ABns<cuD1sU{;H_9|QL5&64P(pfb
zJR!Z_5F`((L+NNjl$0&({Tp+_EDtmLCE$zrx2Q@^s^Vl&S4b8}c$UudYk~fi-k$R=
z4C2QT6q%2?Ph1?Zm)uJ9L>9Q9c%`NTrl5=<uk{dHn7Z#1dv(g63iA(0#;><5gW<oR
z&XRa3#}KG}KzdFf?$u9xX650a<!nJ|U%c${U(}LRRFKqQ2x1h^qk=iQFj(9meSon{
z`Y)g#)XDLo-i<pz6`i;PWTFFPl>SSgRTUat7Ky(!mj!4wveEv;Ba^;aBU9Rbs_4#$
zj?ReiQ*Mt_EBx1Sj|h|j{|Y}}R_K`*^$M+C9)56x>q<*ebVf#WY$!r4>n{)W3nGA1
z+$%-^?qMB4fZL6G;+qC>bE^#-89^M7qSE8DruvXtv+1P7uhXg+;la8>^T@D7{7B5O
z+T!3?28Rb3jT#)yymr~3`^&4cfI9!Ns5wau8M;md*_c0hu>L`)hBq_(G@0D|tG4I_
z?xm}L-NsuU+t_c7P_Y=HqWG(ia81!3yvyzZyu%nM!0%QZLftE1e}4RPAgBumoq|5m
z!f|}XOA5N|9s%D{zs*(Qy&+ZQ$?9NyU!W;ig-;&1Gc5Gbepa~^`NyhIF3Jy#WX1~E
z&Q!UFbeS@o`AhHT5jHl+HMWVUye8&oklct0qg*M>yAcFl@Mm6oS2_;-5u|1|+0zS7
z2uL48oe<VY$gjue;Q)WRlni~*KKTO2J^n2I3V(Is@pBhY2nxM$?p55|F>%6Zd<7{-
zk8ke+-}8Q<I4q=O{^Ih7f4hv#DE!?|KYa(g(7F9tnFnwUPB@yAeJ8pclTDumm|!i5
z{RVu!fsh-8B+b%G__Wl(m_o%NuPSlq`Qe#xE&C1r=A{?#w;Q*<{L<EqkLENTI@aLK
z9(niu4Joe*fS^}j#{Wd&FTS#G|ABqy-ssr8qy5#l#_YVS<GcU>;00`JAH0zKDL284
zI1?dV1$L_f>CLgUTYwEW2}grQSBwX0t`FY8lRtROi6OoL7Bd9+@H@iMP4Vf45M0Fs
zuga6aZx+alPz*k>RyStJ91R8to4|WOX%h^S&VhLFMm#Cv2IWb@pQrY2Zfo1J_q4#L
zr}u7YYumi%^nm<&^;};LW<D1>di9)e#1p5ZW$(V0(E>+zw%&ewYv%xb{qc49+=CV=
zp_}Xr;CBOLv&#fa3H(fyat`2Zl8&A5{eZkLWWW)IRlBJ7Vv5SX0J->X$BrLf#NUBz
ze7AGQ_kHEVB^OHzlOpuhB^Qn;p`U-A7o9iX^c9{L1`s4q4<*pEifi-at<rZTg+TLB
z;6a}VGuFkDTP6D>cSw#%?w33!d0z5{<bBECCErSZkz7MGj~;c1lEIYddY(Vv6EH&0
z31&>>jN*oJ3vdlQP0y(pgO1B2osQIPiSd|1G6!&%oxCv%JRsz+&wbygeb4ysir?V4
z!FQ>?Bnx?vMFxQWKOV_jTiaI$1zKC%*UWBi)a#p?=d2#pV)fU;-;VK{!kXLH&S@E;
z*Eh7xUDMti7T^beaYbZOOIu<%{5^say~nsd%&b$$@fSgIxypdb=m)OxJ|KQreC&#%
zUqq$i?{B`&_kNEzmzIacp+x?(cbV_`^{z8_tQ$804IQy=Z1?bCJ#&WDcaK{;yavJF
zty6mfN~$+Zp4rkcZ~lmuS(DdSm!Mgb(bSze!yB@8?#^p`&U1twVA;6Tgzv4f_Gku2
z&<|#w=eGAj?-9F+eg)TyzPV?BZ*V`GV@oR>F8%|(M9;8H{NZ~MM7g(y`{vqx(ig!O
zNUBd+4K~WNRxlIWx4F)5vIK=Om(oMIZ+7qAo3G$3X%JWZ`wCY(Ggnsclgn`=$c+Ta
z9iD8E;>?iZ>womv=RL!7$BYsFyY3c_;1X9VI{Ez>(TVh9(TUF;pYQm-EkpF37evQb
zFNjVcyQ&wOD>l)I&mEudh+hU{Idj#Bvm_r%=kodNAaN6=02qiwTaYxEB(HcO#AiSf
ztq<?My7^RSiZnki&@VLQ%8T%EH@Dyvw_*40dt#%E>crp2(vO3?p_&W0-+rIss$e$C
zx?yAsf;?-Hux_3RI=l$x5TpV#6mhZ|p{j&63qB3V2Baqu6;6W_$>3tP=PzVvgojB%
zJgW>5zobJ0O9k}nprABH6Ehzlgp$Q`)KCibC=1?0)LVOU{7LxF-mOsM9j1Wa|7Qxo
z2Ni1R(Y&~%tgAclQK+8Q$+DAzxp*!(Ev@$>yhE)(lLDCJxID<!cLu7%;(w7lAuK!d
z<jDyqPhKsicfzug;_|L^(uYmVbNu(O&f#B&{sXV?-KJ2ZIi>)D14c3yVrgro-IQ0s
z>Xkce*$zlU=9C*8**1sVW|BLhd`|7}%a;rPM~=Kt_|JUwSN`8l;UBycxgw$N<l9hl
z4$1=w8P>s2rkb7BwK3>b)Q1EY!D&rg31k=m<sSrLTfFH-#!Lf#JIo;Si;78H5N3~d
zR)>ZLTBW8yX>6i(OiF|SjWwGy9l?Q8O(+VSRyJw-j)|pN)<BbVj7e_`HBSnJVz$9S
z3NAEHKFjK7(K=KHj>{@vII?k3OiVC<*84rwU1OlO9E{nXy3nM=nj9AC1m`<n9na&h
zp(VFH6_~SO8QixjGw`GV$}h(SF7}U$HnT6YC|xMO3>ESMd<*2g%#do#P+AVEFQZ6r
z_2swUC571flwQ94E?-X-N=WlXN?F%vt^@Cr?S;&0DhW(s2(HN>C3k;Pr#DQwNX<A{
ztjmTOOS%*9%Y}cJ$e$w<mD=%^c(c@gD3XbkjmyYzI^oxK2}&=T{%(Ov#Q13~yw=6B
zk3d!A4{4Rf7@9)T6X3#Ak0n)RfsO{^Z3kjP;$C`=zpF6bm)dL(w`OE$WpZb-JZOu5
zd09;0<g5vixhSbk7Lg^r4<+NnlMKPOlw?y78XFXj;*1Ci@;ViYSBqA%tjWo8lvjH{
zf;x+OT9X)N7UDXKq?Vi<q7kyKv}!lRYthMuyRzbU*-%;W`xtd#fVDucR=`5n2vR_N
zT24m!_{NC=Euw0QTB%V}uqRbE&0Ro|?R^w@q!4%{2J##>diaE|HAn&>M70JfTaajp
zRHuVqJU2lYXa7g~fcLzo>TVP%cJ5PR_r2`Yd<r_;h=>bX0IUK<32meh<oJ=@1azSW
zy4I)OZc&CMEEPf3W$)$bo|=%Z2;iGPL!YAPtnm+kivLXEfg+XHh3C~9v`l2~GpOgN
zrZglJ1pge64SZ3VPU7SwnSY&R9g9T2I*mVWGv#JQ=NoGh)4Pid8izhCusa~%q_ZWj
z_LJW6)Yjy2wdI+e(>LvzYSU+D*DO6SF4~Y@)jTN*+If@Pel1FR7$ieNoLAHabw&VV
zWMzM1s&ASzr>WkQ8Vu8m&B4;c^J*I#Yv;AhoC!Wd;P*Uk96l%g66UZH#M*S^%h{CC
z@wt_=T1ql1lC<W$v{7TFU*aXm-%md&&>yrZl9X`UnZ3{^<VA(S!QG~y;h4RiW=%C^
zt*vD>CZXXGNwKj>ko1>-$2j!VKy9O^ZqPRMd&&xA7hwhhkxek{&>!M+0YKnq02il|
zAUT`Z+)z6`26VC5N$U0e^>=^D3U2K1yo_Y+GQ`I5QB1@`idS970g4yg+}oL#GwvjJ
za$;5i4QT4MP*-VK7`RH&w>R~Ja$j-x!Mp`xL<hi0UyrAgCZHvi<OOs9@pyl!7a#q6
zq1;y!lLFH1!M0-8<6Z~%dJ}Pe8e8u{$|faZ#?qK4oi!v;SB>y%oM!cEwG8=fChpLb
zLu>M)1Hc`Mf6(Np8r;55kK3F0KGRS)@qOMgMKSR{8r|gTPL1MNhI&j<C37N7;q{10
zp_rG9V;EVWoad<u`~Zzb&T&Wekc^kWouHb?s0*A;IDrTu@qe1=SWNQg!zJ*FQok=a
zlOCMebN_cMf>YH&`rwFfo|}8y#j|HGescGz?UkB<V6#>#*EZm<XYM0c%a1Qyy2)M>
z8jenf583hF@p<R&+p_h{8+U)Qr6<gaN1Bas4Jc~g%mW9vZh4CEeCD+P8h@Pch0hHg
zS=6RW4Q}}8bP<3gapwd+_@RueH*p3d^W&tB+qRCY(;34IN_+Ou^^;3#?%1*8ju{=>
z7K|*=2Zx&!EUT_4?&vCMxC2@4$l5((NN1-Nl||ZiSF|TNCoG#cZtT(>8>;dP3$56e
z5E0Ruk{FfHGGXd-Xaj+h_&>e^|Hr)^ILQn)gCLKDD*~?=`UH?!IXVFb#|Rmiy}hAu
zlbHnhA>SvxAV2PY(|B+)AC_9l_(4WjZ#c3+<MzT+XEn8$NaA7mfh?!)AA&Szy7H^E
ztdU1r8_|fC^~aUkN2=5Cy$RI{h*4RtmSG8Eo;r2`KYm|eutMEXHRt4^sk06&F26S>
zAisU&*gLyMF1ml)Y#o%X4z?JAG^IzrI==le{5Z2pu6d*?4Yj0KDP#OrsAY#&93GXG
zozsz7-|oopi%TyqnD*E$<7X#_sQm*X+9pKGw80Ox6je0T9ti}g-Pk?db=j<m;{C9(
zs&FQL&gW+rOnF+R3|5b@q<4<JW62{SK@n;Q`tmQCa$sIrURzaRnAsMJ60IR)78N(_
z`QJG7av1n}X{0o~0hgxa?_0EJUSk$47eb+tm3IwY9j#F3mX6Ds(bRm`X$zs9^V%2k
z6%gO_2WaPZUZi;I?odg&0qtmXyoDiBMD?l<?S$1lN^?RTc!U^iZrX_mM{dej#3qz4
zt1Lx%g=2dln5HZWUyUdu0XL(REPm>)-79uqS;HyKeyX^*mIL$dnAMiLJSHfqs<3KK
zSwY*<DI)@9GQVJJXi$JOVabE5W^TWTc5{C48ib<C$TD@SAGd8vS2C0~7y^|;h9h0D
zjcvI5$zr{~QfbIfHYik5gLy?^Qd(}-9HmyPY%8h6yEF<djk!Vwh_{+PV#~_LY5>A7
zG|+BLSvsM9o?029k#h=peEGN`@%FqVyTKS7_G+X`mRp~YJMH#r6sML8Z%}IR$0$9i
zv9YnTFm^~4Bh_aOlkJJMFNztGn>RjIT?l2Ph|GO0Co#LQl4X@b9@<C;k&;LakvmO>
z+wA0(0I_e0f8H%HV2<AGI!LTs25Hsb$3IyU8k;BKSJ3@0rKi6hs;M?a9$GW9Ho&mq
zrL3ek==oi6?r&W8l9QZQ87+w+<4nxgfB*BC+&okfWDW~L`9qb(GFdSS)Rp4t-_Pvc
zfSeA4P1fgHN{S|0E?nykZZ!rlR0n=7dlJ?jzyhKDbn9rMII=T<uf#nC?MHe_?0UiQ
zraishbz+kmvt>`>zf64pD(&c9RmITL*jV45Cfa;^8b{8Bo(9sMHrL%lx;k^HvP>o`
zBRzeYbaW!=r_Ysfq?f`K*K@R&bbZ$KzU(5b5e<Rr%P?bcTS>&c0zGKUEJ9QpdhHe<
zs5>l%EY1?y0~Y`>S7@h*x&sXhH4r>Hlp&gsx(XwC^(wpAI<&PezgVAVS(BW5XL?<t
zJ^AX-!b*CPMy|40RO6CjQ@=Ai%u~50e`nB^Ak)r~g|(~iavf6ypLMU?1_wu{<t;_h
zh727n-Qx8P=?SrMLo_qXQr4!R;#3G}a<8)|-&cGVMTU2xR~fy-EaM>jskzru6$VwR
zt#QNZGBVLU97on~wdG{}HYu@E)pz}Nt2B<T|AB{{-x)>?P=X+WrR!nGjU1wAD0bXx
zNQ51?@!|y3NaL#W%D2Q62e(%&7~9<Yb8%FNJzpQ+TBTR|nN0pAA&H4+;!VwLvtO_&
zphFonxj4OO_(U8dRjpY=O&5(e>?o=WVt*-&j##7~R#xvsrRgEMf-!oBDtT(!2BhE@
zZLKmEVpdXI-AU@u;E3EbJD5Do*-#}lSf0nfhKHxfL(MWG>v*Vi2Ji-Cly~=<H%Tao
zo#`Qn>|!7#(IJ0)-;tKkKT-zPx>aXmVhDx|8mMs`sgcg8Z(7q{IWjvwKDQ<>=dSxe
zjQw<oX@W?_>Lz7)aL}K$if~QZHOU%7YBYB)I?cEq|CX#aB^(`xqNlGPJ2^JBDLyAB
zzE&TOLYQjg5Bz>5#2ClY_z8z5f=f*ZR4l(HLFaK5k}XsQ#k+R3PQ@=!dp;e<aYU{w
zZ{DYV)<Xu=t0Ef@VZsBB5qE#MC;RkgdDC!Nz)M3j@ne}o1ED6xI)7>5)1B&^aQ3e7
zT=kgevl5PuMbTUObOf~`|A}K(*i`{0magzZ&^dG2+He{b;^!Z!kHYfSDYOez2Y)4v
z0J=adB;qj(`bXmgYCuwO9`OWBX#^e)c-#C?=Fhht0gPh2iei-e4N%fs|0Qa~iw>`4
zPXV@W!RS11o2J8h;lBYtu%rp^2DT-d&EceG6Im~yJ47fJ*ni_k3ieJ44`MP?^QNt@
zt}J^zK1V~k$+ktg-uiM&$sJ4Pju<<lb_0`Sjfg#qU{RXzluG(J#NkX8@DHj(Mu%M(
zhn<m9c{DFg{Ne%`mFXY?LMG@P+C^`mi!h8+!>s>hGL1D#Kc6&uU)j})(%;IiRTXr`
zHz5f!DIjk0FDZtS_~g`t;_~0iD}FDlFV5S4b&Jwu^q;4e4JMpt_L#WzzwD?jZ)<$C
zEi*~ZW~OH`GJ9N6q0Q3L-cZ}{W)X6zLb(`EI8VRmo?gr1glK0G<xMA6ai<`@XZ(P;
zNr#O2ym3vGvj;ICXV%O-m`Ky1){6jP&IEYre^C!e;ZC)VT%Y|?cIFFNpXO&bMOM7=
zsqD@FMX457WM{pUmHkpyd0IkbY*p{EfLQq;qJtiHB>!byeJx<3F*993F`-_QQ{B?u
zRyVXZzq;^7(L#q8c4UBalJG}4Zk3h+Z^y%lM{!UEV~qk*%45hNLW>LttWI={v`o+v
zM3uNYKSHR{@EAhH1?``<tHkPrUC*n8tCy+Dcyrun%kF)naxyJqy#a6};C9Xr<N)>|
zBe%GdLEB&_E;Tu^0=!V9y7dC*N97x&AD4X6Y<#@DuyaYCN@fdni$Bu^g6v9F1sItk
zbZK0dW$*rWXOc#)XD&yuMAC_TNF=gX!M@_-#z7XmY%ilVJG}xZs3Cw0s80mnOK6@`
zh@AnkHL_QI_P0EP@lz`{6y2MYpvn$s7l-Gl+fQbV@7Vj{y*`_wV4n*Ouptrgu*-?D
zemG<9lc>j<9DkhXq=!aE;az)M8s0#sL~(-r_9y5E>}!&ey({3k@4Kf7#GR}WfHtMG
zEbtPVD2Dlwq+eGAMkd=`q^UmpP`01nHGYbL37Q{a3n&a`P6rnS6s^$vSC!AWYjM9l
zDzJ$~*t3M%HVhlF<~NupFZ%lHg_*41|GKg>*P#f}o)fZ@iRvqWf4g)m>4$jVD$jgT
z@&RX=?p0J_d!NZo43Jr{j_5a}+hNb@&+a{|oo#y#Eb1HVyI|I?#hnui(^86-SMQ#X
zn{x0^PcB*Q-L#5|_cb?6bp1;lyUYG*+t~K1+FQ~}i&J`-xf4fD$B!%ln&BtNo>kbB
zOZKczmEI+hF~HS?*RV>l8FcaL0rkzGb+NGTgm=TkIB(@caQa<`0DU?<3A1NGbrUW%
zDmHs{bY<a<b@XpvC=GhQ!eDz@;N)rznivAR`gH!q!4CA=IC4piMn}6Z#dM?B_)C+7
zr(y=7wf!|2TuezIZ&UbdGOunK?tA{>aPAh-eXkk^yn-H=y#{)G#UIBjQRKi|@+i4y
zI}i1Kxsf`+b&Ax1t`nrnUh^XLW&_`qT>*AkW0O>;4lD_PnFQ?ZQp=msh~j1rE)@qL
zDMU|e)rzJvG`!DKO*h48VIuQtGD0+1G|A=XbC#9J{OY}TSQrm!Je4TEg^wB{UM4!@
zbjMW@Cl0k728gff6Wj9tPYer<z52h!tAOjfPkhS%F*fB7$Dj;4-URdljVp4;u^GU|
zw9*RPeImA?c%r*}kBkMMSXOqlRAYtJn*I@5uLb^E-&opI^Lqfh5qH$qA%yL?Ly06c
zedDq|K?imwDO~q3or;8Acyg(0mLlo)*O}e8^iUFo%Nxt4gZgt8i16X@C&cv_<uD)R
ziweo)6sjzM3dEpK6c&>;^wzTNRcQ><fPdQ!W8>raca$~6C;DpV$+m?Wd<)v5UD|qo
z86K<I(*7&D`?1btutporl(TPfPs4f*z~$bH47>k{1H`-VMa5QFT7r?8mPX2A-)gIy
zfb%m8kR^9oba+s4G-Fq3R9yAbT`kjhHI+RUxvQ*=`K8gBREUBY8TzZvVd?&|5E(DV
zWwd3Lf26B~_G6fG=D*wp*uS0JxBb4$U;O}J{yWMI03$7r%?r6?%p>hrJ>A(dV|P>8
zSxcYxm7JW!)+5979sqzAZ0|qVQ`Z7yCt<}Zhs>qu>R*(D*hUVh@B}__GRPAv2?jlI
zA!M7NYGOFum;hVc!DfvD=P0pR<(d5GNR62PCZ><DgcU?rR74kqSw^HMCO8`+g!707
zXToGgSztF9q6_?(4-EDKC8IXjqNO22^2_~njtSav<FpeTI=}M#Awvs?_-DjS(2gCe
zoe-1ZKcuiMLD!Y^S;_?ckk693bO}vSU|<6BdLQB%u9d^uI7EZ6ZXY(lMy+W`GC^%B
zU?6f%x&qT6x+YGxK#^<}gxs0@;-j9L1jGXKU6Xdgte1wI8J>2pp0Cx_+T;Q0=>c+E
zoxCj~Otfe|cB_0SQ%+Z?l`16@&IU-euq3@8h+mRsh6QaL4U6gl!R|%%rBX%I_9%sP
ze1vyFeMa44mKk8ddiszF{5rd&f{o_hg8EG)E=+ERQc>iWdn*jb9>BNXCe`m7i9bg<
z)vlkIX9$kKPB_86#hA$RQh45}k-{(cR_N6ox1p)GJ-_D_=9ufl5@hA)r;H@;+G*xZ
z@XLqsweqCE3xpHM5Ah~>_<|Hbbl;;0_qoTsiO*)5LiC2%>dN8sb8~XDQY&UxmruTT
z--V1&MPlc?<<)3Sby8gEg8Cs`!<8;oj8Q4|)8&+vj4>$`+R9RU<fxIo>mFY)%@QeR
z>YCa{C7=wmv)CRrVKm54`n8kjAMCRLBaQ78;J6Wt;(NrDL;v`}2KyIO;pu5PBje&?
zW24eXWTaUaOyA@%s=~`^o1Mui&RNYl8O+aTEBwN>a#kMbNKPu#z}7TpYFJ1~foto!
z=Gst`3^6iiZefu{tJBAfA40;+CDrIR<|Du%Y_TC4hW`Pk<7;1fQOJCh7GKq+zpKht
zWK$b5tmf@|UMzLyb6?qYYK0#cxo2oy*2NT?E_v>R=1Yf<Ma96ovrr^64Ek;q-tBp>
zTVRdMur-HcCd9^MM25_sw?8*2ldaEG=_2aZM6HO5ozq->aOnzjB%eD3YNe9AE;4Qv
z<&{i4lzmS628r3efzODyf~h|kj6r_tN_?llT+~U#KG(;oLYzc~4VN5IZ$@Y;jNysF
z<54;jcf5N5kI<LYBZPY#ItTCY4APZwqgxFDOu5Mw+}T686!wne&9ZYa&rBemY`dQ0
z)fHU?pnIr*Q;A}7PzQ@A+Z3n*8i`IOF0>Cf@O#P5;eWrlxNFY1_}uQ{w{2*x+rPn)
zWJlZZlPh8h0<sLu<rppA`skcRcte`8rs8*S)!fJrR`a|otE8tpC%#Kszj)@>Tki{q
zLHl$Ovr(d14?A}Qru8s?`Ey1ZxOUuATQYC+@rJqSvsqd%wZp#h8~2(zew<W3!RZ5j
zPT+ngSoWX+$<}LW{eYc&r}x;-bpaXR4_de5-1edQOeVY6-OGXC|JZfv%Wvn57<=b>
zran!&b@m~=K<EsS0a)MTY#;+LCnnhs==2w&rrk_R)UkV6lr8}gCo`|2$-EL^B(7*6
zD_o~6206rRfe+xX-n;GI?_NH#@!^+`j8GdaA&|{LKWoRD_4_u=ywDhhGPjmjCY3e?
z#O!-w|7$1TIigkspHQlvp1tg?kJe1Tc<-2oMT@NXolu)Othl1>&h@*eMn;B64Uq~q
zNUn+~ob}AfcaNwE?8H`y2N{FCS_F1sG$f^z1tFvJL!u7BeIUTz7jlwW2a1ZuN6mi!
z$jp`5sim2*3F{_ppW3=K&FZjZC{yc4&+i<$ZAiwfXva{KRppquZ5ooi-r}z|UyICp
zx_ab+vg%@+IkzxpWl5Sjw$YlDQm0JmZto~JSS+$2DUvJH5pmUv@yFr79#k$?vv$CF
z1li@?SArcBk(rR}jf~_5R)bjk{Fys_CaSJim{sb~>=W3O(|0<G=9jR44$1DF#(e8C
zKwD0XnYn<YaESF2VM!!}g^=DuXo{Iz+Hh-Y`OuNJ)RF0<%N!QmjQ*ht&e)3|k~fd&
zPS0s-Nww8WD=Kq`{FuY+Go-lgMsMLXvM&R#=AME+K>#>dD-yCpRG<iS1GuD5zcf||
zGnC1RZ=WBnsJ7Q2t`dKCo$jK@g^fd}+>zjLBy<l;O>$kpCRC2sUl#*7bwXj5G%2(*
zN~h6;<u(@QK_yXw6*5Nvys*arFDj_!n!!_n0t1{wAR)$w0RKR^(!ewuvB!!s>u1cX
z&5pLV|8-!*{S^c1f@>0ExCCvXAu+2YIpLZ2Z-hz0*RU6gJq&&^Qi;*Mn-4T0Z!c+h
zdr9mQ5$Sd-dpK8@oPF@=Xw8DL;ijA%lX=_%&i`~-68<u}v@At!;*?w15~gckS{^JS
zKVdU>;%%MgDEyS#kN1holosYCm7kF%?otZN7tH&xhD;pGdLm*n8pjBRm^+R_us0mZ
zu#5$y_KBr%i=ELFftdFnT=UR)wT1InhnOQz>}br&OpI+PTiZVC)Uq|xlGH(Fi(W1b
z%zv$Z+V+waQ<ovM;CQPcQ3m^`qayN0Z^_Q6DRn04{H@`eT6*pnRc4CBpN1RFSx=3r
zSmX!{H}50x0v|#!@+jD2UIG~gs;EB+tVbhdGOJ8Z6c)ck>b=G<obltNJKqA?(?oJZ
zz{9Zf+3JrJqlCm4ID`vnAPFtJ7x+XAPdkb>d2%tp9w*<N4EUQ*J|cq!O?%;A{0+%!
zLDy2~1tALtJi+H`=)HyA;+wI7WNje(e8}F5D&X4^$colR))NKI=O9Kih>}MQ+DWHD
z*Ad}^i(ZXRwKicOlJ3#r6rO`TR9R3*oh&569mqN+I+j%>r!`cjB+703J14eGwzWLG
zYRtlS*CKgt$+UxY$tAf7<7bXpbYa%$7apILuJ+d%?ZcUDd=T!Qt&HA^5>GDLKWF&t
zAr-E(!qGD$bBnUls+%WT<7#h9FPi^occH3&R(;F(%%u3733I9nSFKu@Rh-n0n`15Z
z)8>pT<mU2{^=n4{{GP0|@nHSbrr~ouM{e3*dslG)XdeUF%3z-~-2p{V0)!uc$T~9H
z7-+i=koy4HiSzM;M@zA}KXq>(dgt*!54;`cNyxrIofkW9eYYP`@vuwF)(x=Z#>Uf@
z`Yog+Cn4Es1i2uP9x|;FPYh34LO_95zBC2z4AEKcIUnCuN<cCUdI>815uaQ7Ms`3D
z5OE;#JwD42wEDu?)yp4EA9Cxq%H*^mn|4;lyIPg(i3R&8`Oqsb;eT$Q9~0F)aUhZ{
zG#QT_xb5t_?Q3sszx>y(O}C8>FGx)@hs#Sx?kDu3V;|7S1~lSFi5P0)@roAG3k*mn
zMAHS)nI9iv3nHnoLEgayD_^>E(fq6;A=QbG1TGr=gf~gy)ybcHB;`obL09){yAQRu
z>^jkpI#(~?|3QXA<{>^sVeeBsRS3*P=AwWubf=RQWQ34q5LDqE(IWM1r)t|ru%htm
zqn_NcBN#;;xDHW3o}%MtEgMpt6fzFw!=K){f)E8?yf}J1dmUm>={Y<%Ib%lG8nlcA
zBUG4Na`O3&kKFJ%p0a=@aj+MFL~&Bb0y{7@KsAEWpc4w9gFNe4Ivx@fWl=vcAQcXx
z*~%RUD<^dJHc<+!y}HDnfS&D-{L$=-!Rjs+!kavZr+AlE0^ak8CKup}aVxqTi33Hv
z&I_nWlSwPL=isl^;rU5%M41gN2Y~YMYk`w)O|R^54HuBjwxVsW>ezy;AvZ#JbB2{!
z7O8D#DijLWE-|91uT@U)oXp!C&?6T7A0%Ca<2u+zPEjvxIyc7ud;G#f*T;F>_doME
zcYXZqX#5e6ch`y{oHroqdyg{91=O#=zoH=m-}Cy2;J*-dW!Do5s7O*!3h$t(0FE(g
z9q`;j>cBhtP@?ei7tgC5g$dC&q{XL&JT35<H^LtlljA@V4vEc6FS`Lj!Vg$Alo)sl
zKAd6w)JqXEKW&p6fF6Y~no|A(eM_be)Zimj0Rw<YZ}xSl(?=Ez_om^Ycm8Mn@W$@=
zth@xRMmwaqZv3R7X}1q38>`R=pi{%_&fZ(xvatY<udZ3wlM^4GC9RB$-aTa<I@@1V
zj<bsddWm%u#E~2ZTJd|XVt5%A`ohn)p(CVIgCZTBcthVs(k>?5;qAHj)`<_*<`s={
zWHiSWbe2YDK}I;e+eEmoRDod-=#PSeCZ14LcJ%%tqUEOE*}tS_)Qon<H2B4IB&~`a
zA*JTQfa8qEFpx6aqtpY)8r5mse_%e6<h2CAg-wP@utlL`(U3VchPW8W4_HS+Mq)4s
z#CyiM|GaPsfA%JRJy^&2X%fELI%+H`!|zR=vS!Lyr!hnpW-$h7CY-p4EU&!aI$xTU
zTvC#pRLUH|pZw*06#ItF+Lp2YMBHZd5qe`+dUO5CoF$Q==zrFboe%u=9sGClH2k{9
z7`7Yemq=$%qPYjL)(8`7+(~?ScxlunKkSP)&a&NWH$3<EDPiHdh?v-lIR(X!94{!C
zP}8Ook`a&H_0onl_+Hv9G>zVPVf&ufGL6QP275`=Sjab#-4*3XZX%h8uUHGK_V0ed
z10#~?VV-mn{7|3^Jo(lfXyEl(cOqUA!sm_R1%+U+X}mmTkja(A%63Xmu6(hl`W6em
z<DY#)cCTFN6MK8*3NtNwbmi>xnRhS7ccM%2DbWqov^FL)>JRY&aiA@`v2>g`Y<5&B
zj$mq|tc83a?R@;8YkZL|2<ADkS_@ep-hf$yw{NT*Tn1zkz)ucnOdj#m&=kYek=D02
z#P*`o2Ck@We9`gRYa9IoQ%yq_&$GYa7i<ieaQ1AHX##SdJ&Tf43g@pYsawD4R1ngn
z+7s&_w2*PepwaU`ajFe67STAuaqQb=Lt730sN96VEOWIXX<R}&8Coi2GdAfMJziaI
z3`L;4$h@Z?ZBh{IykrNa56lgGX=CuE3({qq<RrtIhc;`Tihu4xKl1b;j+itr{x$xS
zPes&u_E6eAD6|iSxOg#rT<d(PgFk&N?L2;hkO=xn*47D)ps!y3gD!$GHV~m`7wx{?
z0s>hO^o)|#O{57c64s<u^q~}`lbA{qjwalHYf6lpP!Zdwrq3+z@Ff=UfD%$&b@ipw
zmW}CKpW#Ub{Sf4c#Jv(7MCPJ5qLqi^ZX!#ArP)nHYEX2$xn%j$PLQu!QJ)>xr=6$E
z;H@4&$OcEl0i|sabi9esiHOO|T_xy5VmY&-_&GU=!sshuupN=)79%Ewv@-iDR_N4z
z%e3-KAVk&KXl2S!|3v>g4gZg~_kfS0S{sM=%*^hlC!0;O>DiRcruSqM(t9t2Ktg(h
z5Nc?lLujElse+1v3Zl{#K@mg{6crm@!E)`5d%gCnBzyQj=giEO6vX#^zfXQKo7vr&
zr=90K{a9UrxyVnySC{9C`Y{ZC^0!knA=yl(+RhKr`u_lh501>%Pk^b%3!1+qzAs%H
z%s*glKrVxqDN@uIuMoh{DCna>l`;SL$We3ID#E7qN*Ji3m@78+F)q18`Lr^P*-Qp6
z!TQQ<eMXFe=pkNSxkZ3u)Bqd}Od2eg20Xb%Mm(w9nId}o_8?5zb(!_1h>p$dpJj@t
z7B)){z*7yd5R1}8JyV1YFoEDO9w#YwBE~0AQj||}Gy0==<cN}GT21*)V@P+d%SM9j
z;0zI3cpmZ>6Z3F$M_mG$Goy_4WoUGTq~;+fPb>=A$hps*g8?(&oqKNX0@bnSkp;4R
z{+Mb3K5P3s88bt&^Zj!mD^F+5Am#!5<=Z!JzJok6k@bsLuAIfcLUKMKo}}d=9iOP%
zNnn8)|J*UK3zWcF4S_{QhRbLH5)!^3=1eSfUGtWV)R*XMkS^|6JBM$*d;$NPYwvJc
zvHH1FtCu@>;P03OGGT_~<n>2T0+}-tfzH2-Zy}cpS<fw9*}L@AlQnBMK`#E8hRqMv
zf?QFbMYe|0!e5-QE@#YU?f?`lA8C?7MgX8f18PEKYerW0SUme8{<k>O1Tkl(pSv0t
z5S*SnBHXRqrn$5bXAPWW!qu-{vo#Wb_u9MS%#w5G@SUvK5zU3;wjPRJwFDnEA5}u(
z1z(*z0rYaB6I)2kQcfvm8vYUjB`&HoWIihcD0gDsNGtrqIesY5!R6(PMn#6`JiMbS
zg7Yj#jK$BJO&$5Z=Dh!l_`m#!ky*2Hl1pQQBKJ*O9Q4o)lldYd9W4(79r-yj#@H0G
zKK}<ZWGoMp2o;?Tvu@i_k*-I#ljhFt!_0~~F_6N-T$t(|JF4qN8aLML+EvpyM3id4
zTo@u7Brft5(3+nE1GEOwB=JYFR)osups17}D`dwevMT!uX1)Bdanq0dte1ap-t?bA
zvtFd8RHr2*7ccTezjkf-xh_C=hT3(nLk=?7kc0MhCja2+V(qz$KY#&hHl9v-hUv02
zmPYFiNTHpYdwu(w{rDKN#Q&8$o-9bkXJQHp9p^jBzy4b8c#Ju9c+KwDckVkAZ>K~K
zD2aW0@6`4;GS90Ww0wj&(BAiaChM+t2$rTbPJH~4O*VG%`hQW_a4R<o&hLnX`3nN|
z0=3St--*x>(}2*(036NVI-Am!s6e{pM*$hjN=Cb#JZY_3@kBx4;~J}6XYZ3IEo{P6
z6)1Me(`Q#KKAt^t&52g;y521{Md*#o`17E!>|e6VLlpk<EU7e$fh=x*7TXf*;ASm_
zXwilZ+c%%zxn%cK*e@b<*{&V}Gn5cZ&jCI8m<;h#%;t<zT7r#Ca<?>9$OoVKgj_Oh
zSs6@V={ZVZbK*94)X(s8Dj{76<uPINo43>sM{FEpN^A6Hcw%E%N>Nfsh^{bm)Y@Df
zV?PA#<8iCB3}~N9P8Z=N7s{FhsSxQNuONyQ$Zf=e(4K7V!*c@Cwmc_H`OwwSpi`=X
zlaqsDd_30I)V2K;Tkt|tt}wRq7FZ?)2PKCD#?@>Zi`ER!BH$6&$FjFT*W8^)-~j`2
zJZ2<NOr=WYNU<BtBiUO+@CZM&HZn=1^pdy$3+0`AWYUc^)QEIm&cy<M$LDRqM-mz7
zAWjjP176AI1Fv$)Gy<W2YTyz9R%ruS!mfcB!JY{JhT$1qJF@x5_Wv-d+>~Fh6h?-s
z+hP(#<T~TDPHxt2{z*N98CN#)+>{RV#<y!1D}FI$8uF}velD`P;^k5#V3{2^V@uq$
zishr3o<R)Mk8xc(A5<3EbMa{DRN!AQ=mn@z7c#`uST=4JV1$qqD{Q&o&QLU99~O6B
zkYh4wim)^RO2hqNF~UcrQ{yt{_awg;@{PSiQyu>1+;id}yv`}7Resk(t_DV~4Y9OQ
zy@PKzx3@Im-*U%1?b(#Gx%4~yb-?PF+^pDo<*IQ@RvwSOpqu3lri(Zn@AJ2hpROv1
zcslw?kH`I)Rp|0VBN89P3D@^s&IpgrX?^Rds}~DnVsm(2a?QZYAX>dLw5B5gcA_yP
z)V_g|h*+vPh*A*}IdDWu^GO@0-p7k7_GzqhT|m#xeBylXGURlzzPu!8WaLSFuCRPc
zb9t_xch<<Y6HY#xAK`4O<bL11b>oFg$WIqP=0e|1v=fDQ)wPypw^w)U>e=%s<w29|
zJn$eEI6$P%0Vc(RCZ^?S1UzWZA(I=1;s<Ph(7Fco8+Yf1?7V)RPXMJiuw_PaO;J_h
zCMU;1jByWSbO)3hwPW-j4bK+l9sITaF^9+fgMmMtBa^c>rS=YDP<a$H;+vUOT2JTj
zeZ#Vd=aIA&coawD?oNg_Z&58m<srd7K{tp|BI<+rB`w8GrVQJ^qIOho>}+$cp^%51
zdxI+V@0jt9x$z;+!{<yH_|!uai+f||G@EcyZ;wVjI<Y*&-8oeM`2co;4@2f7`cj=}
z$e4o8i;H(4$IU^@oM^!UZ;37pAfiV~0Qe#oevgF}<O|K^57$&8tPk`?qw2@*xwYJ0
zV{NCBrX%$D@duC3Z0g;cIdm5|@>hGKsNGc+S5;*yS8JOGo@?zoIKR2VSGOj9@@TPV
z8_uL)Z-Pw)^Y}H8wpCLgp^byYE};#QE&)R_cL0PSo$Srg88E8ybXeeT-%ZaC4pA$;
zJSKm$V%FO7?6Doew9k1&vR3J_IJ5Rs(&2o<+vlyfGc+SJTwG(XW|qzym7C%gR7$&%
z*Mcqry5VG*7U&iOe?S<V)h6hC1NpEp(JN#{4gd$ioG29xzJb-ElWCLik;+rW`%C+)
zIZw3tW^QqB*UbQh6{mFV>3#jV#mh^>=HV)~qAa*3C@+7Ni_#rU#5<nEUq|=dAL)b6
z{&I6oP1C_CF}1$_*Ea8%I^)^ysTs3z%f;^<zC5F_KScB;_`bN1`xIzKVe}VZ1j1=R
zMujA}03;ou<s_xEtV9^OPZRz*>gnXYW&Qn(8;a-|QCC?w_3e4yjvhYCkoQAVm*J0h
z&1bqQLvllk<1*YFY>*TF*Hienz~A>ME!-V%)@OIln3$@&5asF|_d))s?Qc9#S#<e7
zHs7Dux<XSYrQw~q(idQs5X3-W<<RV!HPR}{bPnFYa}IQNQX&;n8bhPf7sSlk1Mlbl
zg8N*OJ;uDhY-ZuU!zdsZpF4~?`6LgdHTk64L;9N@%uMD)lAWBS(b7<o7fxaR<I#T!
zXR^-<83Tb{ce1!*uH6KlNW^NDtPvh)!14fiJdE&g#eCk(%c1e<^vlOx!<<LXtw!I@
zpYZQ={O7a}`2>xSA`AKk7rUZA(6cGFazuia3CcSXW{j(T0{(^Z6Ov<8wrb>GNVDK1
z2np2qA{e|eWcDRcYe{KlPA{053-E&HOHE`#K{7>`uv<&7$iLVXiq~$y`Xyx}+e6}$
zLv0<Lb5e>XwvG&!%J6gGlzY0_;Mp>T+p?eQW)wcop%kQ4I6C+RwvxXelfvIYR_Rfx
zd&<YwO1Tw%t8qm^(c;M@JHurL`p#%tE?2O(`c+yDcS`B!%M(4>-ljj1Eltmea!^n%
zB-`8fC$k%UEaE*~Nc2XKSLqK>-vj+lL>`2!6Rcjcp6ND|4!BvHAsq$Y3ZUpgkR~Ym
ziGLfioYEgwMB*3gPZW<xi`53kRcI5N(|w`>EG<6zz}~}CfqzzpstPvgzFWk;dn(Yu
zt9@=R`mD$L`pZ^}c1Gvau+{9!{)HGv#uRE};{r=<eVe0Kv|Ff{X8pd9DCV~WJD!y&
z*~&tHjFELZcoNQ{Bx@i2(~O^|V=D`P3-XThSaN0%i2vQHK4DGregUykhMI2zq=4%{
z6Bc$;cIJ@PkWm3CXBRJAxb*CnW^vq!eN9o@!jhb%yyYWyTYGxmf$~q;5QUuyuCt~;
zvcG#lUaIeHGWet_LOZQ}<?_Z^l^!xL+z-W`Jg+`t4ufvV<@K>3p(3Az0#=e&6U{9X
zM2NN~cB*JN*pt)%bNKqMhQhj0RVliL=Cs7gEuMivuPYq3ynN}tj?xgNr<zP`aXwa~
ziw=%y2xxb*@o_!6v~rAc^$|_v$kLJ|hk&xYy6R3#&1rV;^ce@kwd#X@-mb2l`RUbT
zQi>uhJuO@wwkv?~ZoKci8+^3{$lvmI^I*T%kk9as5u=rXq~Dx+$!3mlteV@sebr<5
z3v)k>IKlHB3kzaUUTVQfM>%nmkuC2NuLhs^6O_bsJk;4V&D2R_do!zi?E~pR6h`Zy
zuFA|db&Uz^#5aaGpP6qw*gq4(ebgJHkzx=SLnX{0-`Lc`H+aU+KR>K*Z0>|fr)5=%
zW;<kK@QFe0@h~*MYrJ6~-G`?6(7^{Yx(}fFb)b1wW`QZy3o_aJOsPKcUTFT;@d(9T
zY5u>CM@ScnMAz30q&V68Te(N2)ih2Ex|A$8W5Nzr9<3W9xjK`r?9t6R`X~9wuxBKV
zg_F2&9^+uxQdjrYTr-UjOP33o9U15C=tApMsNK=ZzRDi^JI`icU7n5G&7#sYCXHGQ
zJLu;AwI!y{W<Tbi-S5Zz?&(64-DK~)^A%GAI+n!biJ8i4ATYV8%@fGmWW@X-N+{N#
zXvq%4F*QMB-k7hkbdcM571u4<JjqAy61w}D_y8-$($c~rdrkZC?~sy-?k;<LV^yHF
z6=&fXQ$6pI$q!}PNNqhPEk9(>xhQRH<;h)3ADIKC{k)$15vFPicB|1U<iR2FX<}9L
z@W`TxvgG3p01h>=87{E!c&Dd_(%zvwt2Rd0?k;QcOMTEW%fh}qEp$Rg-X_ODuMzkE
zIKFWG!om=13#l}qxMOEWMqZLNm*$^YvDG2K${T8A6UQ}nC_SxRVQXdXOoM$W26RXe
zsqp2iSIPKPN(_)$!)^;Q0<IjmY^05do(@VBHwaGx8?(NBa_zYd1xXnR!P@u?Urlpj
zI9HpQkeC_p<oMQ&$&-rO6T+&e6;0w6wQor4ySCw#z|fpvutIWF_T#HMx#fzGp0AV_
zCpXUA)LJyDxqM35BtkFd&I|Z4=3$Nj*#S#`0Bl2nCaf_aBq11p#ymW;xHw}^XHr;9
zxjNj>!8S|l%jU$U1c&53T9lNWQ5u~c=!;UzqDxt)qE<h>WydNXzl5?db&wmE7MI6n
zSi9FeqFk1}JSw&@DkCX6KQe>xF$YVf5|ArGF$cuR>Ba_}gF!S5pJotuG##ZDVW43j
zhnR#^f*-!EXKj?v?C$!psdm!3GZU(-3o8oTZS8Clf`a3!a%(@lf9Kvue?cy1PcYl@
zOx%NioEc<mv1$G~6pFSyi!_bX&+LBn!q$a8_6bqJ>A|DIHG3cU=(i)!eDwicb4S?-
zkTa5RbAl;{qF_OR1a;wr4VP!H06f_e*oco`{+jcZjT%*-a3(Ql#<;znfw|hTem>Dh
zI!?89JbifTc!v85e|5Vy!h%al%`f-^xh@<x@5K0#IW@(RJ~Llldt}<|wNQc!Fa$B}
z%v>qvVE}eOF9a{$qPsCP5H8HzCmwqkaekI?|Dd%Y(PeqFoZKVaay{L`H`cBiRk~u?
zA@0>jU%wm?Y$Xd0ii+HKV^n7G#KPogI5EScdQaP$qP!DiUysK~mI`tm2GL82Miz>|
z<#E*c)51hCZbGO*)SeUd!$e<4Bl@`_6J@D3&yP|kXC<oF<IB^Io?o#PsV?oG6zSH4
z;yO0vDlK!Y6r=KO!)1D<YxU;cV>44nuWK0FymaYT_-i|4`K{~5jSxtA1^KQ-Z`C;4
zu-U5H*IU@FtGUgqSnJ4z=p}W)(zWeZFSV`BhDa9WA7cLi*fl1QL)sK1+Mub;L1zCD
zA=E!W(w0<Rnt^5j22y!q3f>e7@wpa{K}=)3*>mBsz%zc_!%+QF)Pfsqb?~&Mad@%_
zNTk4-^eUOr+Tt+-;9JdxYu#n!6bh%)st$}N!>Wcsk_@0izmN%3c$(=5D&g8p(;-w$
z8ejMM84R+TDa^6LtBec+((pWykvs&{z8Iv*<fK@l4DUh%wHrU0%joovG9vD!Ojr4m
zDPmSmt1bumz3JshI?JGt6%a)M!(nKnOk(6;5DdElos1o3Mr`m!9A=6I&405U+|Oi1
zi1k}Ksw_#w0=7qr0Xf!-b`SfTOB~rXVTpj!07cOe8>Eeol34`!sdZV=K5ePViK@|I
zBeM<%CRZq|!))5ap)oEv_X$^<9BUVMkCezbHZmw7E-1r^vHT48*?oU4dC}Y+{I4_z
zXpLhyl2`{WSfd;jzV=@3@yEHHPjLQ$WF5z1B>f!xz$}u3FjC$RI+x?2%UPf~?SB>W
zDpc_JAO;_pGLtw2UxH9Cbc#qn7g>P&UOD{;XSpFO?nYczrhN?@IBK~LeYk$+hVRD*
zTl%UJ%@%piuj4h2dww^psFy7REKk5hWH^GD4orgcN100sD_1UUMDCoOSwW?WJrfP9
zoe4N?=Z#MZG6lU^TB(N5pY!^OtPjvX!ki<MjyFhU69vU;ms3sj+2$?Cw7u<ns)gpW
z)q>7}hBoBq7(L&-sg3F!@@&XU;yU&;>|yax*9lrj$QXc97X3+a#{yrPR(legQKck*
z@cRa#EgMJ02NY$3GEU2arbu8<FYLaW6YJh4_mZn^5(<LDGj#Q<Ri17#nIbB!sc&QF
zoKZ8@j>)U4{<A1C!o&5+#JUaNjY#X-h^AhiJYJd~*u~X)T55g5=EiMzE?>~$q*Cc3
zQ-hf&&u^SmIeqnvf`3(a&u4m)8bbo2@?U&Z&s;dH-(d3);6&>gr7LBnFta@bFcJ$A
zh)qQTn95j!-B1VMNLP|XG5+rSsoI8z@xvbTYa{PN3y|CS!H3^KI{3?XZhi;_3Fn?X
z*6b`p?ma#kgEPT|#*D-t_<KRx33>JaLSa&rAlP(3RIQFfKtOYQfxUo#fAIzU-(|h$
z#@E(AfA~E+^lv12^hA8weY;Ac;>xz|DGo<aCGaCsoPBBI)`(|&=7t8U@si*1?^mjO
zR*t^(T5a!EGSn7qlvZ}Tbe6=QJQ;XNtVy0(P=o3Veb&O>2g{nS=<ONN(U~chmQPgY
zpq;q$Fxf)#gGy_=i;^?Ax1)11qs!dc!)so^`%3y>k!965(R#a&7L?V7k`^rDW3Vjf
zN9fiwe;##{4bS8AvMej;kJV7=0yBKpQ*}{t##B$NpSJUQmVPz2nAZ!pZt?mc2X}Gg
z94~r`kcMW{siCZc!{_4Cp-s=%83CVNR8rFGq2b`Pc(VSv5`5*mGg}_my8NLXH-6Sv
zvHNk(j1k$$<>hT_?nv;#tM{*+zRde!{PXk$&upJN(M`5!$<Bk%@6+O)4aJ!?aW{7T
zIcv(*eEh-vFBcMHp43I}1vsYia8U2U8Fn~(5)*(<L5O*1H2@IJ&d3d`L>j=A@DMOh
z^*5jw00R8|%P5gTMnPBuwL~@S8>S$jP631`A4Yc57aSuXEF;iRIO6dKY!TRcUgFGd
zlG`(aK~DGtI4F-zs|-{LY|+$)xsxA%9Q~$GL={!e%D8v7|9oWq)cNzvil(+zwYFz0
z>1Q@i8C~F7J9ft0xl02Pn;8@2>m9gz%98GvN7k&Il9LrZqQ1ByswsxZ8`K>x0=_`}
z7HX^LyeLX|YO&D$gfuTZ8)oy6EHbw!Ux$~96<uPPQ?!m_grYB~`GP1d1GQY7KVRU4
z`f06K--o3BiOQY+O~xMf2Uqw*N`%@FFE$K=gyc4UbD%q^|4JndHFY8T9wRO!(3Gwn
z?kubwsB02C#|-w5xNty_$)-*MSK!ISa%Z9WYh-*B*~aPGsp`0b0{9*;(#BPhKboCE
zcI(?K#KrUeEBIpne7<uF9?P#GZX2wjzw_K}#^-J`*bHXRMd!(L`xD4YBK<9&eMT$;
z)8~r1!UupDpesalVX_L9A=X4s467shJVhL_pdgI;0or?qd&XehFpOU4pKh)dD9<2w
z<qY!Y4S)E`grm(U(A0evbCBfRJLmov9z$8pW4~YFq_(n$wA7MikK<3TT)g@n_cr(7
z)A%S3SQ~uRCyykc9;|Kn$GgZ6X|L}Scmz8AG{_s&5E^77PDh51!pYALd>oUIiaqTy
z;j;_9%V)pFF4cc9>Ues}^qinTZ>1M@iNCsa<HZ*@EnPbEI)1a+k7SnkduKpTYZY1q
zlW!y%xkjo*Y*iqB06!3j*2X7Xzn*}IdjPs8<4z57XB5KO90JGSnUL(}H9dKa+%v+%
zGfaQbW909!j12v+!V7w@ciC0w37Dy&B%Fbj3%k8<3^cS0uh><=dfU)Y=9ggcH(D4T
z9*(Qwe;~65Q7q~KJ!lW#=DT#FL<<4+lyh!wTzN)VScX*AUmqFCK57{n7Z+*?-`gbF
zhtffB*%-dZ+Z8B%1nc3!j!5wHOJJwz#|8#6hkb)X$hJas44v_iZqza2iH&ri*PyX;
zLtiDTN4hdU1n&&U7Y{k+2A#}aHt<km3rA2!^sr*ak#R9Og&hZ?n<mE-_kBQyp%FgW
zKx~E7VfvH#JVJ#6m~@b@Bx_0Bfys7Ey&`QaO<a({elDyBnO#tjgRkc&x99TVFK_%g
zKjsp9+J?uaW!8r666RX&elDfFmT?qfVDobHEoAB?)1H%<RhsWkNG#dP#GomxHOP!%
z{ZT2IB1#CeR}>16F`@&zVLoOS#KjF0^0fe-+0l%kYeDd#2^gHico*1aA^k!Pa(bSs
z^z+<Ai$ZOJv!?$;8~N3@TwLCIP2m$h1&#4`WS+bFhKKv>uhT;SVAj9&(%ccs5N@}^
zqOV^(ijlMMvSGP2_kJl`zK-UJ?(455L;kJ2-0kqI0AoCyLwgbQWu_5E5COw!*)**8
zS6&&3gwm5wxr_X`e!q-!WDNEwYw55q89%IF9Li76U1oHD;fi@1=koLP1%0&%)(wqp
zk>C*d2d*^7f;`Y-S>kX3i=4s6f#OFvWQx|+3ccgfO+Fqn8~@m5XtL?RpWC2Wc)blu
zXdb)%+fbT0#;?DLzq@?i_Q3~jU%HH3UOLpKuybL@xT{mTmz0f;S%=HBaQe#NLo4HI
zeEr|RAH04Uxn?2Nl{cQ)?B)x!g_>IS6Ih=x*-6xMCIz)*pan6zs6|O3Hqm^afaW{1
zqQ_?8Lfa)P&Kf3<q@?V%L>c%co5##_;p*kjXT8|F-Y`?dZ!G>i3*Q=Rq8H=wJlgj|
z>go)kG$OsA+Cl6TVu=O6MVY~-Fj2|QY<q-mxyi`ij;BFEFYA591jK_zMGe{RCX*4r
z_D?MUwf*XSyNr-F;#WllPDa>(JkEo;hHpr~GLu5xn5nNspd`ei%j9m+6d_9kAroR=
z=(x^rO#mLB0&`~^#c09Mb7&4E<CCUfm#{F8+ay>p>^PcNuvLKt$R?c+ApH~eQXORU
zMgd}k=7v}Y4fou&Y*CC?gLg;`Kd27{3mhCounUQLfbAtg`sc=_2m1Td&~#^MV@JbG
z^D0KE%Ms?SN0x4zShsZRl=;8jH~kJN91UDjQx{cGIv1~0+QlQZ^eCF}NM~az6K?Ip
zSVtt87c`>xe5_+E(ndAynme}C&7r21LDTnG+s9*VS*8A`g<~7_|B1J^ev0m=@%R<6
z9o~RiGBTBe`V<f}Rfzk!3N}@k@<;qgQD?)-<TGdx*`z1|f>LLwX*@CBH9r2#BPodu
zx`6lxO1plT(7Kld3S;-IKew{yc*>Y{>(_XXUA=oOw3R_^>4Oo~%&w2W!auHy8|$?w
zdn1Z?aR2TZ=wE!8P`|4Lq3xT_U2a{6P>cSZ@UUfT+u;1|6;R7TY;6dTh_f$f@J5U>
z8<&O~KMLNLTSSk|y&3DEENi)cWM-{6^;+(5f@AozaqZ%7e=~l<GXJO+!&Gaji;qJf
znQ{TL4IA3`(l2=mnJj+Vu14}-CXpB!zZ-y<lhh+kKLSXQ*8RST&kyJ#`hNfYce%sq
zkr}50l8PKX9WzvZ2jM@OMUa*^#%Xh1NN(U}&c+=5ug*>p3=I<@8^;lh6<qs(<Pa$D
zNX-%ldNi11pGn`jNCcuiX{7_vQ-mUdhKi+t(jYHUxHJqclrhoQ5E$a{(W<HmRWI*4
zHYacAoT9yHbB}I55q&O572_7D<J1vuP57vnUs~nd*)Nt@^p@1DcCXnqf5~ar1Ia1b
zO;b;;9UB)PqJoJqfkiX+HI!(T)*eAjUvZ6#4SSM#Yh-y{RQi>!l2~bGKuAJ#nW}8=
z^itTtz+Qk_arPt7xj``7K%%(|E(1}aY8aee-qhve*6c_4$B7O_>04%RoDjPyD!MzS
zdE>N|qn10V9lS!A0Ih8y{&Cr)vb@5Nv%0LZrq+&Li5w?pTLh+;tmw$_iLi%BLcX5y
zm9t@>h+OG``mZM1aLgR^`J}}u>7^+(nqa>ac}!VRG&m~+b}}RBXW)YewHQe3h3dZn
zT!7>UAMzN2?BJyTeD(tVSS0(NEJAh~g=wDi<;?RUsprm|eQQ=71Y&N!`JRE=4yx$j
zq8a<^OGqr{kEh<dG?OQAd`y{Z>D-wu4WA$5;UqM^1~hi(ci!QoMPhW8&8Vt_$%%V*
zT;Du<6D8{G*yat>df!CBPZd}16KPpLs^Y-teDwCa8`e-_s>2B})n1gC_@6Hvn!du6
zgeB=o8)gG=U~_>iUjds7A`FOluZEcNkfK13c`%r~<kNHlzPT(@jU|3adc{&>HQ&*K
z3h)347p&c;(7XtkTPM<*i1j$*TT+e*aPaEqh$v?bCGPhLcCep~@7VzozK=b}ze)H2
z`UHAVy1<VjGdv6jq(QsEJ)p{CYR(p-m_;<XE^Akn?WjOIknq%0x&k_4H%CR!iEies
z8p1QZkfm2<t~}l#_=QrdhA_Bn;ho7gpm6<YBI@am)3n+kVBmyw??}QxKacpzTBY2P
z26<&(OH9|mcxJxBlDs4GQRW6~A&=ljnFt#QT@YGQpd9Z2{ZWD)rvyXFX#0U`f{HRh
zQyKXiqm#K+D1sb9Mz`P}UwmYD?Psnx(=NV>d|o*KR-H2<rl4PJbLX-NjrgiN7wp>i
zPT_^-sSB%GEmgbHGnYPh5`7}G&%(RB<{xNp+E<xTzTrXS``!n{)Weow63*@^8y&F=
z>y}MM%QNtTcbXy-GrJcDIRqsGMleqY7jV1S*FY;30KXalE7<nPrU<K;hKqTbBbX3f
zODCgAY5a>?Wc+qS^M6FBp%_~V<y=4)CzXbFg@JA0D`;XGtK0RlbmI7x-HidKlts#)
zJ2oC$y?^hTV`;jI#$^1RE3(i{?pVFFwPRs;dRm&FrS*id>5f;S%lXXsSU(5UhEGQ|
zjf-{r1@Adm(AhhA!TgCUn6nkjYDQ;=CT(YvNA6!=nw(s+x-=zTmA0(Dcw9zvX=87F
zb?La2@Ql<jd!}kcZP8LBtsXHqUza$icuc5%{HbXLQ_^E&Gl-spz5yRtqZPz5GIXYD
zk-eCT;A3B+UkYU4Z3ff!KWBx>%mC=`Mk<X;O4*L&&N3gN&HGsW-hqAI_@*mL8_-RB
z5M3~KdOI-{uKIIm1L-L4PYn}VzR`btcbWHmqotEFW-?}N-}-M-(9@<}-(LU7cw0}}
ziWz?gcYe)6jPE6|lYj;W%vt*Z^&|xIRAj(gqewSal>n}k>nbVfn$~eI(FX8uI}^-1
z!0`{RD1<f_C;VY(0hgi2UGe1q7}~%?Q9@vZSs(b7_KeAFvET%|I=ye&1}>A|pK%{P
zCbSpxHm(fXd7w5VmfAF6#)14o2+@hOJP|`ZUO|yCIJq!aNc3{OkPgAS#2=PPZ@W7<
z;&i-*_i%B)EAkZGT-1)Lct`hh{0)BhJbu|m&c0aJe^%|zY*~X3h^{WmZOrIk=JWop
z{=W-96a3xFmHIG7GlfOh6c&0u#{o45+#c|G6G%Ulzy-2s09wHUqrj6(aA2ucv{-3u
zjWj`kKdeJ^Z}CFho+}}cZY1ePoN1bTe985O5KH_ic)RPP=m5SX+XazL=maIM1bTZP
ze$O=N_+ws1Ijk5Vy!b{!MzX>U+Z0$Z)8B&7BODLH_eiFI&6)=*XSC6$1bsp3%SG#P
zn8ib~c`AS&#K*kW9Fgx*6|0dt$Esy1(eYJ$>G>CO`)7-C@jr8mWKIgJMG84S?uy3C
z?4MyK?%jAG;7QjrXlBEz$CBObZESq1$9YSYt~eJTSruomWVHGlAEE$yI9c&NayS`s
z!wN5jhM&UjZ|}oM=4C8H?|V3gacS8VtJ5-a=G7JXCM}AaLTl7n2RPA(_!=!eR}^5c
zzXb%a2cGFbb4rPIHXz4J7$v9)4Icy*NA~j$winW{_IT`o6zi|9$i|pAF-fRwVnXh}
zZOp8`P?OPul8jlD5kevs5-h6C;(o;)fc*+`+ek|HRifL8hKI1XFv3o-rM0josG27R
zJq=F`I1$hXX}AOUgI5Qh3YeBSExH9;x}pbX7H1DW9`N$$11y@vrcavr^T0y_$5#}1
zTDzRe*g0p?s)0uZo=sJRqZI%)wVf}3T}N;rDG+{t5-=dSOS(u%en3jLVCoX6012>}
z$i5{+Uj(yMrC~4px_9uYf&YwY!zUHL%^m9Gz{aR~PJyU~DNd<+!u$ZixYn&vR<5J6
zQ%iaVogp|T%*B<nfCWKtfd6DEpp)9@%BDFKaUY?MGto?DSBXo_Z>0Pl3moIO;8^}F
zEMj{M9|M)8n8!em4?O!p<(SzydWxBAj;>p3EEgy(n7f8Y^*@-N2f?YM?5wr1=Kgsy
zu_T9yoDy0Pf1(LwQmo1ybW|eGF(RWNqQG4$poVS>k;5*|4pLw~*EHxv!_wmU5pFIu
zs;QHm%ACf(2d5g=)JM9x2ZRKt9-Fi0i4D)-`wn)mK^^925H1)y#>2`zE#2wkPB?)u
zwkRk#JSk{aygwX2i2E8`o2E*LjezsGWdJ*wu_w_$_lz+Tq$QH5CJ`%>hGr1WSXKd_
zBMOf9-V(TF`fu**UY8aH2XFXKs4qd&yLRBOo;~}*DdaJ|#nCNmr1}uP-O{i*EphzZ
zZ)e;$OaD&p$TiWK$r008oz@>c_;LOILtsq0J#|nc59@DW(osx&<$|umzdd+n4ZsNb
zGVVCYS{&`GHJ!>}7M?aYTWF|SoX()30ZRfdcicF?fDc#?7}kIwbS<X$`Y#B<Ys26M
zG@FF4(QBq74fNY!Fmk*dncYxih+<Q@0JwjKeFWT2=(S<#(Y>@hi8}NAsaOoZD#(5a
za-rmY4(Qt*5am4Qi)e)xoImx&9CG~B_<(5V1-D?>vC1Lh)&ggGNY|M=i!E$Jxm-Aj
zYVjR<MLL%ZGCmt(XE_&vaZhHV-r+)E)~7E}4(e#cc%;_2^k}IQ*{F!dA^nE@B85mK
z2qj!lCCC9j;4=&Y4hf2Dg)_?)*_r>?wqgC&e|)fYec8yhVWX!iI46(e=kp5l@?QRj
zWm&?slt-?6)cZ!1rLhh9wUzPH9CvJf`Qnz{_uqGM!@R}GGp4zsLnv&5CZGeqgI}tL
z!*=pl&D=6O%!{}nG;cy?62Tu}F;ERcfs0p=RJn?`cM^28Swu8(;5rhF2SEl*PD#;8
zpUjKKhs2XU^*clh6t&|-Vteu?EE>m;!a;S0!$pORE;-+Gq5h=N+(cE(Lttw1<33#?
z^grH29i~Hy`raoaa0Fb)xlE8}ru=twA;CqOWtKv4mCjKzfs~wRr<7&|^c9iw+mHnv
zZjEtO9y(=u$QzPmWe6gGZ<CYSxJc8J-1^=EiO5K$8k&!Fu*-m+e)QY}lPS2sZ^7E9
zv-bmIsc8}`jTf{uP@P?NxwT_gM@7^2iEmmu-6|XPN#U|ECdJA7GTtOTI%Z>0#>f{T
z-M4G{oCsa>a|N-?mtKxq+Bd^kD|CAIMI(ITHkC$_0vFIT?{NJ92SkgYM}|&`5{y@x
zlxDPp*~<r@o#E6tC#9pxXqj{U>x%Jl)Z!83T6n!;Mv>#@B^&MVP0LO9=e0GgD@J8_
zui0BDkbjG`R_Rac{Ss|0=(wmv_dCc_qyMjiD=h#|gK5I~%qNL<78Hd<H>kDvQo~p}
zxHgfGQyf|$_Bs`;LO#xHqAO)uUP_^s!gO_!;tHOg!XZY&t|*8!zq1nyfRj2uu=+I^
z3Y``ek)EGWuw{K!+05#^w1B{fAhlmi%Z$Bq*H@2{TDTm^jlhov<wV%eaFTCXe&+PT
zJs+YR)b!G%MmWVNDk~!*A(@@g*0^cH`$>LE7qyqdRy*#6xsNnAYz%)kyx-2pPRmij
z4X{;9B_}2~XOBMgMt3*Ar<2<I2#A|PpN~*u1zLbM><GxgJ|<vCR6{)JH-|-OM9m~;
zkU)Z{1TijR$^6I4le0?8GQ-msXD5Y57bPb6_=Qv_l-9i4lbIwnZQ{6o_QBSUm!MDW
ztt&kXf+I^R$}(+&r_}dOU$QCP!`{(7(!1j<a_*?z1<3RrHEqt8R=x1{nA+W^7OmuQ
zfjwDPX~rvm9&`w3XawNk0@-_Iat<~$vNFL&5fJ9LHZ>V4rv)^GPm=F(Di>Mhl;yYn
zm12?duUpHfEZc_c9c>b$5>m9<6jujpkW6i3R<et0XQ!)6a#kbK;^Wp1uH@Z>s6-n_
zWWQ}0)7gLKlmGtrlQaFu>y7UtSf7A+ZORC(znWpE=%3YZ>}+VC-ZojeXpwSq+w}H^
zPG$yEG=*i<{@M{K+V}t;Hsbp?Kpsh4>IT@6l_I}bf1&q`gfe*sh&b{a48f70EWXKa
z;BeJp0G7lKxl!J*?^Csf`qO<4<)fR=SlNbYf}_>yDA@(Kutjxop+PS0p`q?BL7{PV
zi^AM4$fDHh=wMBlt<{<4(dh8gOLrk_{M)XjPrtf)w}x@^3{gi#svYceanGUZJ!1-6
z!VZRp`vwO3hKC*uYbhMFr}_};$+dS-M@FebJlz=0?$v;nBnQos_Ofq6%pCFu!~r9A
zB(XlckUv$Wu}(a%2m|45D4bI`Nqgz>Yki-ZoU+FGdN_N@Qe|kCg|nkokJ8fY;I?8<
z{@^xx=o_(%Vwo&1S^Ak|965CnoKQ1cc4!ON-w(oI$@K77F}x=p!w!XI1n|L^sZlSK
zh9W4;;F8nT_$N3t3evh&)*P;pTCGd>#Xr+4veDLDn}<gmi43OuAZy=ra+Y$nwG<r`
zF4?Hzl0r7xhHG<oZ<AWB#n*5R1G7NVkkV3tYVqR=OC^8$u~M#N3Sk67t{5g%!T}(;
zd}I(l4S&F!`cvfd=)#E;#GVLZV!4;N>rm?*M&^cyb(jW2p0@pwRqxLaE}}xnTNL&r
zxntZ}Ab$RmW6|R$Iy+A8=xA%}*l}cH`+-%(*)cFFVQF||)<j1OmG@%%wQ9d<j=eo$
zq0@BX%K}3qLKidtb@5xjVM9mT>Q!yySFf%vUl4gY)ulAu^Vlc$kq;+bN_B21p7wr<
zqe~W?-3Iw;Su&g{CgaF%NNo%51nkGqV<XrWE+G2+a1(z;EOmDI;4HCjNeNgW@k;1*
z?nFT}UYA<*rK9}N3aICd3J6(oDAdlq|LxLD*XRT;=^1;O)-|IT!dP6W!UO#j8@8IU
zS`{9Pe#@1!V~cK}GimUKTi>TTM=P=~gKbFW*!Yrt*%TTv7XfaO_;hFvg|Y=AK1AO-
z_;Rlo#NacuI}ab*zh?XHHHVo~#~kIfaSv~RjN_SoMWrYSU?I(T=*{-2dmo?Jm?jN&
zQ1^XBI>wk5#tAIe{DMdD8-l(BTD=JH0AGV4$W1zQA&pA(2-qvaP7D<jvHT=;YC0IC
z*#IZBcgkMG`~B^3C9ZM^$4@p}m)gi)dspfF_EiRbq;PSuLtijKuIVMkfv7C3__)GC
z=CH_0V;R6z^&JmMLrAW6aA9wWv8KKcxK~00`uw?B@d_(`+fumqed28&%us&fR^}nF
zDTr<uutLoi8!vc-kKm#*51Ae8IHVSU`6Q%zMxmCzXre)GXA%uU<mk?I%OvR(TFU`_
z&Y)t2j%J`5(WruzN~W!X68?+6X3He#YwopmbGI=xF>l5nh>gm-LeYHk9-4OdX6A)j
zjnKOc<D?DE$!RON6<ST--n%w1)45OFDTw)agQW^R_xwa`*y|x1N|!JRXu;49A#X|*
z99hb8P*_5+f;&aJP0p_9;l@pHUb*Jk+R~B!BO@Pqgk*0n(?*jKGA2g<21=prCeUTF
zY2Axi&n#RL8eZ}!uE@fFk~9rE{{m?*seKUlz5GHe=`i7E7Vn2WE&)zoAr1oBibW#?
zwlTUL44jEC%ulB$nFPW)>%K8^Ul=;Bi6_g)$p!o@>Has4zp{A3zhSU#|NQUFhTfl=
zYG=Lj(tA_=JsfQ6U%@w+;`j~NL3!)n`sL4zd}ez2j5X-V_x`hQ9}KcRljgn0bj1A}
zd;9G#q<Fh~eT-`|@!a3GI)!g3>x69#)_eS&-x)poE>x~TRiQ>E2ZxmG!|+cj^(F&s
zSuHr!1U?m`|F-M3^6JXy`)ABJqW{kRNN@G_r+Q;z^PCFh57m~{b<TeG!q|iajRwE;
z(~1Z3(D~o(?3|UkwVk!}Ip4Cs0=)w1X%ixUs1ZjfN11A30r>kmseIuoT_P;|tG>xD
zq;}UU^)?P3{!`!Ew`6|EoK9}xvU4XVw8iTWG0cG{nV8H)!O{C{QDt+^=8wJHy;EN3
z9QQz$x8}m;oeO53(uMnPS>L))Rf=y5cz?^?26(6k%2($|bfS*|%Y!$rcw!_YLEOj=
z0_#X{N=4|n+W^vK{BKq>q1JqqRDgT;qC-5083ObhL^v@3h=MNLhU(0NI#14CK)}7$
z0Z1TQBgn+Ak}yy|K+bakc^g<i0OjGsR0*sXY67?$hMIssa`e8;KXZN;N&rBfWAsPZ
z6R_4a@D$<;fgn)6@J5*wv@QH8mfq8K2X#ZNAm+TK1C0y7F5YxwPXvyg)jD-z$IPI>
z@VUr-!ptXL!hfz?eTg5Nb9!nPj9$5~x;VQ6hUV=2y)CD)Vr0GkA3<Ykin5B@!~A?M
zOnDH=b|dNeiz}AuV0cddm|u2`VH1Aps&DC?wR`*Qb&u*dABii9C-sx0u3{VHRLEHj
zFo%ySRKqY`;1<A67Z|_rAb=o7^x+h9YIhQol-bs?#H_%1v?eIY(ZRK-qnDNrRuqqL
zv~w$AA1fH|q(5g`^~{7RG(nO66RZ`k#f^m>PUsUpf1>YD6i4`X*eKngOCCU@aLxrd
zVd9}+qYMEmm3TQ2n-6rv5BQt+jWr4?gv4GJ!nDqY3(VZ0&^%u+Gh8(47<XF-YkSu*
zxqkj;e^A_fy<*&~9c&a}Gs8Cxe=&y&qT+1uE>mRDWtE>I(l0h|yu)jTS4bvc{HoH=
zKE^MGeC>7m67Xh8<tAefcn3m#J#XWHL&mq_(ZgJHM2tuip*Q5g4E%#42StJ$Du|pI
zdvUU6No!j%g}A7(v4~<=QB(6}Bb}~^9#Ac<s92)<iH8NJsTRYZuDFc{pZT&a41XFP
zi2}mg#}j_gS`m3T$b6|}3~<C4gK+RAE+lVZ3BdqLT|)so=zsy&Df~3=05$CjX9!oQ
z`Gp`4KU7$;v^uR2O}@G1H5=#NSN@_c@5jjb|3#w@;n(o1aS@r@P($#l#ttY(L)JHt
z_2tcfrx)+qHGJ~&wD7Z;fqo*s+)cnYn#{zyH+%)We9ds;Zkpm`n)IR>uX)gaaTf%J
zY_<F7BU4ZbZ$KZt4X`Hh*@!{fi1+cy`Wc23r1VejLN*XVBfV{|ktRMqT({uKsW*mF
zNYnN(=Y`|wO!Ic8&4T*-{(Ik;CSEO3`TB#spM6`RFgf`zPzy&<DO@yQpa|tL3NQ=U
z`*Q;3%^IQqpz$V>K9!xgEj;Jg?DAPRccG)(3IdZ7b5|&RWkpO8vu4byS@`O>9g+Hf
zj8yY>h$VYJ*8*p#s%bnAk~Z)!Pz!T*jE^EoOIS{j9;Yf=4v!R`*wXSs@-x#~$zw-E
z%}ZXgdRsQW*tTNV%&aN1%N4HT<6{Ew^L{AF&r*QGE8uOvk5=OYKTXj8Ge}v$6zKpU
z8(WIACHnxt6AC*kL>Eb@1$3E~)@+a@1N`lx;%l@Cq(se8uU|>wBRebmz@ZsXP@0sy
zHhKAd<iI_jaMT-KX()Jw%GiTF4<B~MdqcufQVw$I_``K4p{CUS2fxoVmeND@e3Z<-
zrZ7J`ZwgukW+Es3?B+`SUJJiQqK_axA#;Ph-w&XKv-6DpA`>46_LvH^D)kn@ETOI;
zwbS@*Uo*g6l)1G{IQhYf<=0PO{LI@cHhw1>XuE1Nm@#0XNp1H<2QSKu(Ko~t_QGK|
zG5KpY<%XgSr)DlVeHwXQdJTnNy2Kl2n>(&$;@hRFg{@x;N82>5-qAqMV$#aoxFrB>
zJY*W6GM1j$12hE|6XKHKkgoukfuIBlor-ngPah!T$ida+hs$Y1^GoK2PfTyyn!Gby
zz2XC6r!ZqgI|WRd?>4S@ds-{J`y~Feu%)*!CX_+%h2o`ot!wgQ^rNv<FlErIm++UV
z*bi~q@Y4p{g&1I$E~R5XeEa_8Wy@=?A6zO!k#E-MCsnL&T1@R4a5W9Q@CV<W^ic}9
z325o~1c`~9P~L!iQ_je3L8Pf_h9VdhJ--JAy}I3b=AGp$|H0$KrHs8_G#kI&xZ>TD
zJ&R9r;e-|8h(Y>0OcZ5^ek^7Xr+zaydZVWWJ$~rS89*hL3wf$puqH2Fynp-b2P>Da
zsyXEq@N7M>W{<ynAbv}geFL0RVLy?+0CGiU?+(BtLFWv?JP>b#jcY89<1vuF@aM7b
z7d5>KL9KZ`KjG7_Z6D*eV9~K7ix-@T&g<#T4v)%Rz9uV#!uI8t5Wf0t%@#Jw3diC0
zAM2X0ZrinM$20HOEnQjr?uU)NTcN;+$hlVf0?3UPc3o;4ktiHh3?g|4fn_Q&Ducif
z*t*B<N`5HLe-MD3b(@p7AI87u)B}uu=xR7#lh-K%nuq`NLyDM;q2L|yrystvXL&I|
ze6bpNT&vZ0Hxjt1oy2|*baVut&tF_{{t1pcII7mgk^TMzjOpE98GDTT>Z$dIzP?_+
zc2n&;P~_-=Zs0%<{59o8>>UqoJ=Dfg?~EQ@LA(j_&%EK;*y%vFI@6YC!WNJ=+UyMG
zBXm1+>&Ij)%nf$&lld11B|XAft<R0V5uGbjI#^a)bDZ@W^x^86TfR>U%+tEMI+OW#
zp1AGT@%|Pzdwws<tW647|DoFowF5q@v~XhiK4-ZTbIH*X`kWJU=k3gL@z2=5bZP5a
z=GtkgTn#PGyv=wJ_Cb=XkyD`;0zX4`m^)KPg*oWx?z%KLVL-71Ep$+)6*l>^kA+!n
zp1uV?Zme(+d&h6JrIRo_u~oTBcrH}PP~VowEq%O+-*I<HL`BL~3Uw88a~1it;~hFy
zhXSqS%*=q&Nv8d)Q*vp$J5*T=3F@udTK_=0=d57A23W)RGm1gD4bbwX)%+gBFFnD4
z=4(U{?|KtfvtJv_KMoz@kE~r(cidPVqQ9}da86o6_Ctm?e1PlOtl*W+#5{W_Jpw&u
zED+JRg}aB&&Cr73MeNKK(s+Q+7%4Eoch8`LB*KX?MsTI^Lr`@v+yX`W*A9f;NZO%M
zAfz=Sfr!P(u3)c$e<&f5KoatcC%ZNE3t>D24O5Z}5RrkbY(gx%LQ#<%_-xk5u+gf-
zy4C|7Ik~mv?PE)-6#4BoVb&ZY%aS{!F<l{zU!i&BG2xn!to|QcA$~^Aoc@+u4$o2(
zZ-MvCVUHsY=zs@Nq6}1|-16G0u4z?c>sub5kdxa|Q9r7<)-gY`plfu^c8|b<VvVbN
zU}1?y_4U-Eyu6~Rj4y>?R7|j6a2|H^Eh-z|7Mh+J(%K%LRS*Wc1Y)#M@4Qv&N8@>>
zemBTJfeDx?7&bgXXoA{>-D)V*rxp3;e{mZOzPNrO9p+>Bo7us8<*){U4xJ!3KE~J=
zP14eNEBvmJiuhW5u9KYab{@`$RZT`C_;cL0!5MCFa$8N=B{XNes{;&%(2wAcX}gW<
zNTHdqXK|C@8EUXDz$f4hYA7Hkc+qj-qHpFKA4}XCI@yij$xV6!?k_xb$rAcpbZ*-d
z_+<=5`Q#iqbRPdn9+SlbF(vB?4+XBMuYaiiJqn7jZ+<6x9`wDnq}8ZxfVVD)2ZY**
zG!zqO67;2}8Q=9s%Y4OPFu4vDNdhm3R)^KiI|+hI$Nn=VBqW9WFdyM}=_HiO(R38b
zfmecpUcc8NDr_x(la&62&=CAiQ_=`w@(H@X(2^dj0~1uREt#NFXF5RTEV+U<n9fhp
zUohbZ(Be4M_q71m0|6NdK8bb<h?#plfVw~k^XsCZP(5chJVr<6y%G&cC@g#a?_g{;
zHs*ldPb4F$X*5iWDKo|OD4iek*Rx_e3N38}YJy0R{Rd?KGRQ>q0NJO=I;rFW{B#R4
zVKsm9A$M7jOK9Rw*7&I6-4>27m}-8yp|CQ}K@<0gm^5{z-B@kM%85Dpn?s#sD8Phk
zxMHv=NPLWPhP182_)Ksxo$22sY)ZrGg3J-u(`2?ODcu!H47g%C)zt3efARC!@*{ks
zkPZI8J6Kgh-{HP7yrYiBzo2094z3|XPURlxAl~TYO-Holpg@lj^ca&g!p?%9fy!Cq
zTr|V<ZCt0nOx~vJ9dNiw?IO})NA=g=#Q-UZ<j{!>fI2L$1n%aRaob8iGeCTITn-k`
z8@DBILP5a<@^gILmTl<h-^2&M*t%sL|NRLfZ=5M_GE8~HLP-b6I;;h<dxDt!P3GXe
zwrY)?i-)tN#?4ZSbob65{rk?oT3?i<_TOQFzP(58Q2v13^&#*l$v6p=CBaKU!pH_o
z=I06}M&u3HgN1`KseG9XmlL`3;g)f83xC?@owgyZwS3pixIORXs{^J_t@plK{9LbZ
z`sC)q3A;L!$Cr96DluWq@8h;Kp@dg8eyK8|%z8$=f}H9VPGlM@6XSI2K(JpbNB&?Z
zI(_<B?ih1^+z9|VJ4)qD&|&~3u)`D)bazCEYp3Im*3C>fR{9pU;Gy3+a~&E6eB`6i
zsVe|dHr5I$^_vWU?_q3*ha7K;v?VJ8XpjF1Fb|~t-vW79+TR2CLsI`<u^3GMS=gC-
zVle$p7sEZ#{|TP{`gz69{5o*7WwM8sA9Duuf84;!zXS8`Uy>j6J$7O*z`jR%r45~L
z)U4twm|zw>HMPX}w~&Sb`-i<SsT=>&U0T~1oG>YM{qyxDydmT|$zTX&;eYjRi%ITk
zjSp^SiZ;)CWy4D~<rj@s(e#LTIK1{Fvi>sebTJR3KOtsErv3<)hc;FSGw785Wbu(C
zBN<Fjv<maEYuV`8vqzV?j&Lc+tgg;1a2a8ICA^3JoKrq}borc$u;AdZ3cc`~UW2_Z
z2>CEy$zo~OpTSiT>zjm)pKf#mL!Dq8=*U!5XXdNatnqmX*_ETU-kwut)+g&^ww(`q
zxj(A5jkZ;!S;qfaw&g2E){s@;>7Q0y9IUcDiheklmp&T*uCjKPW^h~vvar%HUuCf<
zLxF?4fEHx_U^c@7T(qN?#N`PU_?=ETqY&srTPArcSj?*cOvbbdTUqDe>yUcH)^o3|
zv(h3xR^<`u>fk)0vMEiP^k;LZ%HBDZI~`YGi`V!#a)^SWL*uNRUEN)>t(_g?v*Qcw
zP<$4H2xR%r$<Em}E=nj0MiLI-^8xt4OAt6U1c-!NFq)0<ikBT7&7CklcJ3wVcJ?A{
z_DX=wMXAdP$#95`wzVa|shoA$T$;T{DU1K(tu(+^XpyVVv<+raE)SIcKNh*5KM1{I
z*n?1qLZUx%p`o5P+d%CNvRH`G3Jl~e7WQCY{-SM3F;QAq7pG*G){#kL-8{=`V#Cv|
zW054?Dvrr<>=>V>>qQ}{e%@NAbh|u{!p4$ld|!cwIw!fRKbu9F3VmNTkcsFrN$j0F
z(i>1?l1M5#s1IdwXdH>DnAHjiQxVAs7C(O~-z45aLew-|Le7#)klyHOTdM!cTInFK
zwUOGp$KsPP?~N}D${od8uIDUl;60s_@0;_dtvNWa{$)o^Z^PpL8HJf-yaNn$^ORfb
ztsN|!X`xRT^P0V-GA#|sEY<kU)Z%$HQ}E;7wo@tW-%7`U?N>zl!$kj28>l1RNemG{
zv!W+J#!&HL7>y(r2n?OEm5zh(=H@xmb;0Od9;(Yy<8M5(Y#bG`I%}ECx;ZM#2YGmA
zT02o}F8xIkw`$~ywl2IX1dfa(<xEzN%w<O_p~KP22mdl$LYL;Bq+bA@sicBHz*9EJ
zp)?-IY8Kn2<xGQ<(b6vfweL5s{d(wu3=lm3V$I5%cgab=@`}lD2I$d>Y4#K2=r6u#
zi0+zXrYRn>S%62dG0G?$B|ku0n>i(7{)5;A#5PNi&ARi<8_UDabeg-d;ANuZ85<#R
zd%`S)PR@uwQPM%(+YXh%z3r%7ihB7rs;buew?AVVN(b2@eg%nZxzOtOKoZ#V*HSev
zCb#3Iw5UmNG$>?TWs_S(B$SSn)?UKjEnRW`=rojsFE@{EST{N~bL{TT)vjy}YvWR*
zmp@t(9*TTlxd7uzH@fPx&`Y%i*=yS_U2R{xG=S&`@MqXxp!OYpYv@o}N8(`f4|8;O
z3Pp6UNhTQ*Au~c#DEu)O>@RUxyQ_HQiWMV^cWH54qMfZ{_)3?hlXt8>a%9!cDN9{?
z!<065w{B@V(Cl&ZDr;&g=e6Ut9hzHJjvjf3x6az#T3g$8|E#S?ay=aR8Eg>eljcBe
zZK<RVz%z|*(9oHXV51dYhKU4Jbx?QH{5q{apqiFwTNf$808k@S-s9t>Ife*G-@vg2
zI7V($=2SN_<4izek)xM_PBK`t=*<46hE*^US^rykdUVx>6X;!&u?A4WkYPU5;6-x5
z--3Z7ZDAZHopbPF&TA(pwu~Jc7<$8fRFQk=OB-MR9lADv4<x=>3wRe8yliqh8whBi
zzt{vg9CE-ASfwV&`K2RDC$9E2=irxO<yk7<*nIpHoz3vPe^Q}1n*lItub-Y98IhG9
zIR?;)vzT-x)|GYy+B&8(d4*w!pb*IpL?B!@HZmtSf=9r@zW<YCJ2^yeL_8(|9^jMm
z(E>iNZiG%Ok21uIsYDCo_$jl*BRjcCVw$~_!Z(Ob2M+=UBS$TxiFcZF=iEFic&G+*
zgOc9Y>h^U$|4!B()bgDKSX(4BL}<l%qr*|%uuH{|&IHOKqm&uysfK0;8QLexAFQ$X
zIN8a&@dt!Z@!aH9zWADty(oZ1C1ZjXy*d=r`qx$oGKmlke+<V!fuj}{rV{Dl9XokQ
zrgC#s)jUC65~AJf36FWYT>`p|l}r@rcCTCp`jKEP?3u$8P~`t$dR_Vpfxt1#?c%M5
zq?srt{qxM|#I)W`Wb_%;Ox9pZ8HH#dd5|RG&bLw<piKtRUc}iK=e-)$s-X|Sd_j}E
zGZYC3qr+gQij~?#kLX;n>Dk#Oc@yiFG-iwp957x5dKOVHipJN-<XB|cHM04El}uSQ
z*V#0GW>%tK=$O3ik^O7Tv=WyC{ff}I{8kPbC#!Y~Bf1A*J}N7g%p3?aIo~5d+;~)=
zM2GIIq&ouG3Gitlw83wn1ZDD%Y#d^u5vFIteV~PrpO8k;JWA%GZF+Wf(FnP(HV0p;
zY)gtQ8L?74*Tf+wy&jNnjGTX{ux^M3&K{@AxVrW+s~#&JxqKR`DYFf-bv6>kFfDg!
z$4<L%i?YYBsLw4<^~L1qlj_JYAQI`<^vxa9J-EZuQ|cB{Jh>+?MLPdlZ(R%i*}D@z
zK?w(Qc*$Bo{b3x`6-Y;r`F>Cas}1ngH{hTAz=3*(`}Sn$hvYMTKXP$*F7lsY<pI9&
z>J&fxlfHp@mTL+<2~7#)K5fE%V3wN#%t;xw&w~*je<kN>wva<VqbIp<?fm9jxmZC$
zk=*m!I~$}wklAmnQ!rGRf-Ztl{xh*19*uVMUy{E0btV0Z1nK|azNK)o<o@x#`ac*8
z?pyxZ<X-we06ut+3|rOzVR#qy{Q%!%`1h3X9@F<P&WZmb;7)57;kE>KjgIrx7vazS
zkUg^>-~KT4B#%43edi*)g3rh~KwXo9Khqa8`;mR<hn3_b1b5*+6nAJ<gsI3NK)!f1
zw&M!fr*p2L-T3y`fcbnsJBmBbyR+d=36DECQ^b3S_f^m2Ka9ttC(+M%JpcJhf;+iC
zeBK0id|SjF-`4-Zzh}gqz6-d+_Za>?1Md76QU8k^)Tc^wBo35c)am3`dmJ#$a*-m?
zFElh06`<SP&&k#y*1_(o!m#6%Z$ICOk)@E?iY(C&060W#VTr`XyxCFoC|07k9%iSv
zOTXH#(^gKf3bCSa?vSYQc=@NYK&Vi#fcc6JFn`z;s(92eg*X`Uj8RbCk_2`;=?5&5
zltHJ<7^v!Ng8T*P%a|gWE}1QvCs{06CRr(2BiSIiPqIUDzvKbQ!;(iO2PIEQj!I5S
zo|8N;IVX8paz*mG<eKCi$@`KICI6IsA^ApfOY$Gd&ywFIw~-ah#84ubLy5e}08Kc!
zAQEOp>fp$z4Ct;ZK*gvWRiSaH6HP%~Xcn4_7NQ=s0<A$C&}Ot1&KrCHJ&a)Z0I=u?
zI)P51=g~RzGI|BQirzr)pwH3Q=zAEC{1f^e-A0&U7#U;5*fI``6XV8sF}{q331-5X
z7$$*9X41jm&SQ$1a%L1$&D1eXOdHd|Ok%p2`Ajdf14ISl5wZSqf2cQ#*J<f*f1NY@
z){-~i#~%6X;^A*FN_0};8u@H2f{XAIPyR=L$hYY227C*yksFa8{-fe=_%8Vl+}QMM
zvBqn|eC-~-Wdfn$X#>B8paB9@vW_=Wpwb3lF?l!zSOwR3><OUoBSIQWF!vWQ72e>%
zB@}Ujge!^hQbi8sQ{>iW9}<BQf18oQa34bZyMN6DC&Rad;wZYO5Tjmc{_wvbjo~&X
z4>#kTk?{mH@}ndS9zYIJd<X%_YyLN(4M~2vI0MmD<Q4HGVN}Y%A}#r+-JQ0Y7WbC)
z?(S;%H9g<G#o0abd5v{Rbt=pe8ByupVr^l8l)(<gby;!UvlzSxK87BgChx|@<khuQ
z_iAf*js6?0ZOPd5bB3=lB}`nLd&&3`eLj4Q(RX+E-+~uxWV>T`jC+Z@d;co_8x`&?
zmfr4(G8y}<O<Gz&N!OUZf5Hd3y6*124dlg!TK8E&?pY2FeZj%@C3TrEmASXbJ>3&H
zPU@>FER4+WZgIZd0-uzg?(V)FNnYHlaO?DT(@CX&UJX^0G-OM2WWR=mTL$=+dO68&
zuPT9$xVy)}l3wR4FBz4TI>&v>6YkGh=ejp3-NXNw60R(1%3b`N^%JgJ=Ab0^QF3=*
z*<^}Ni?jqs;g=J;<#O%AK{qCDKwP$agTg)Z&&Q-Xop*6(g|r_4xSiA8Eq#={0NA=C
z-3wJJsU4S);91flFME^!MxTR2R#s5StXl3q_+a0o-Q8RcdGY=j_pSi<G#eZCu=ovp
zU`*YH-qE9~$^R?YWxChdy9f8rcP}Z4$?0x)WL@EVdZxRZ`I@|lD{&uBv12M^iHY7N
zEtVB;rMr){b=T^@qI^Zaz{hZN_cS?LO<vtMi|NjCt8;J*{@G%3i*=>z2=&7}SC2(H
zm$c-sgAZkOcZa|)hfdpWPB$*jTdK0!;{S-3igU7e-JyRrII6NVJSZfxvLqr%=CaAB
zr@Om!lX_ElclVm=?t1s61L11hiRz+qZN67~cemBAF+R#^J{6vu)$37ncQ?*orP_pc
z!wajT&U)K$Mj7ejFxjV6{J8!phDrBPFI3kv=exW0s?F+6%xfS}H|JYzZb)rtP_sS!
z7o1zVM{06%<o)IL_9g1DHR?`I4Pta?lh0-@0bWd*vY|e@qC(02J4Wp|O<k^P>aOz3
z%97sx$<wpOCrP%+r&|i3-%f=uNcY1F)Y4NQkew};jg9khp6*lG@3`YF{7>syidaqM
z=Ns7T4c%kZ>FLa$+k$*7$NA)yZ#nAy=BMkcX4b28@-;fOYNk)sr;cwP_1UsJZ(O})
z(4SK&BHeBcX#Yia|G`Jsv709bxa*&(oL=u7CkvCyvwZ@3d|Gb1fc%^VG;asMi=J-T
zruw9s8qeD|VWyDUuUpj=K)=Afu2fd|L~l?}>FWmZsemu^ZGjic&NU5TB_;O#`Qqo9
zkWFnJjdiOwwM}TM(+8DLYjBKVr>fNr>Qt-E>iPZegYbL-NcY1!Wgf3zSWmFhpOnjU
zd^Fw8Ey1Oe>m4E)1#q#`rw9Wn(TPnytLTgF^`4vSE2h;eWAK+&R^5*6`D$%g(ZmMZ
z@DoWs?%h7s6T7?fKo-UW-+LT3F+CO1n2G3gE#sLrk^>L%oiS<o1?eN{|G@@hC6zc&
zepr?#k;AF>zOZu&|5OgXay30~SsAMgKoE`a6S8>n!&rt(;GYb3>XYcCvp!bCxJ+%F
z>owIM&A_jYNl6()ewaKQt-r=Zp|{XA241~^x*x=NT3wkZK8&PW^u6?BqesI7yYARZ
zK80D?V5g~|falY$u3wlgavf}gR_5HGImfN}F){h%hsooALkgLI-X(G47;Yx{yaw{y
z&~yfgRu$ryYP=C|szJ-};u<s^&8Wspn)1-QI6M!1gTBeb;pkncxDoDwd?lZ<lL#zI
z9v0-w!0B4V|Lua8HuOC?JPzI^Ka5RR7k;mcyjP@u7Cy?7&#{TZ=KvP*ljJv>$bZ`O
z8}wVG2DR(X%Zv^8D%?R1IDn;S`c1QEh4FV`mhjKKeOq|8l-z?&G`WXz@LdMM@r3!^
z2t0;6La1bjd#Z-M>%coRHAZYjSWWLvF_)A3bM0m@t6=uzAnY{)#mQ5+cH^B9z^@Ml
z4h(|_G>4m@19tS#&x7hFa%a;Y(<csmD#5LPVOQ7Pa5Q-`&tywU7aqqZ%CrU^D<uS1
zADZPG@N`p1#Mh?sWA<bdO0ysH(lC(HA`y5{$a-Pym@~{`BJ0ElV$P6v7`rZB*5@*3
zSSJc6eV2HT{3qzA9__;IUGQ#~<a7AkApsx5C(S=izQK+l-ymOt|3KE!Txqv(e_qz%
z{^VO4;kUG#e2f0%h_4v>)ED@>fUHYChkJ<6wx?6?g>Msl$lb`#P<JAC<nM+mP2d7q
zA9PP5>n3+IeQk1Q0;>T|a(4s1=v(6hK-MKC(rzw8pcjFemv!L@<nH3naPTuPm{Z00
zG{B{QUzZ6+AnQXukI4D}obK{e18ze;`7HrGz_Z_`%ZM$=y5w_<7&HDDWqrWYMO;mx
zvWTI0lBXLWFkJZyS{uQjdb<bpvo@ep2``19IYgt(YKKt&tjfw+<Y#<hP*5WIVe<G3
zvnu(&6RF(xz>sDBUjBT2J%qo&Eg|=#bxh)GlRZ;o@|t7B=jd;Xuh7HdBlWk%SH_1A
z073u`lHt5=o{##ajubZnPcq+^VT8%_90}9c^t>lwPbb+1aep^`ZKR0^srcJKBN1Hj
zH&-Hnt3NpK1$#yyBla8kg5W}AbrI~}_GY+@f@p>r&rE4-%1g8BCis}r-qemUy*?CA
z7@3IcU+_sLqHg3JTPX5uAPoc&n}tpaBoMi2pow@vVg>uue2y8wTSAXXk~!uy(U{1z
zDNRhToATb24)^lfR3`3~RwDI=l<gsCCQ{KryJG_F`X3Wsh!+f!#hem|h(d)IdY^$;
z40MI)+1=>598NL$`*LPN_y3LjneyO&BA5RgS!IUcg<%nk;%XrIuon!ATa;e|;fK8d
zYu*m*p*c{3?>uPD6B#Ew*&{h%&KFae9!}PWyZ*mf1ExGOef>XK8$<Ey@2;1j_$IC)
z1OLP&GiVJBx?tcicXr?s8oa0mUomi70x{});pqv8Isf0SxBrjVp((%ruh!>KGH|cD
zawy&pbxm6SSNo8G?ZYl?>3KmOhF!-7-Vgf;=%54LE3+78FB8`}k%_C4f83i~n6B}^
z`}*(dYE%CI-Pfk_BC`-zxzVOD%0b_+;=9Ic##ckVYrG5lxVZL>R)|p|`hFGPHC{8m
z8tPr+T@1Qpkc6O<1Fai_G!1@B{Pyts1QQ_$nn9inF9yFQiW=-8Bra3VG_tASOHm(Q
zCU^Fa7pC(-vyh7_*0e`}X-x2(Q$NQO;=}aUP6KINjThlP5gKaqmvim({^a!XbdXQ~
z!OxHmb!`|slxsJKL4Vu)Z!}E=%E$-C96S>YOn@~Z3ys?pGL6z~po^CJ1-vai1e}U{
zyml`>!$A6)V`l!Bf%YQ0;&0B|j2HTc?)E49$*_VW`V}P*U&;{ZP!1Jl9Z>VI<lgys
zulzRE4W{dUxa)r<2aL>|UiTy?L)deyhZ+6MWoH0!&EG^H{FU~neo7(NZjiHbn0Y--
zvOuy*vQ@HoXc}vVkhh^|Jk;lgl2uds-pgw<o9!>w;$QK=oI^vd+#xt33i<%f95CZk
z{~ohH&EFirHs(WtQTOZ%4dj{8-sWwyA$T;DjvI<^|EtdpqcctU`v1q;`YXQQE2oY7
ztWlQ_P;cf-ZUAHd#+wF3C~gCW4RqKGf)AF*wL=bw-zUiWog-N%*(upCIRdpImnH8)
zJ;;!I-cajvD0%qbeD42Zy_?F;|0C}`z}u?M$6=p4wD;cDmSxF9mNjhImiOLvY{&6R
zf*ofo3uhCu2rGmDVTJ%H5H=Jj6v~g$GRt0tmf2ETR)9kLD@k<oz2{1DoDd5Ax6l83
zzUTAx)!k>k`#tYDXXg2TlMnnDzWkr@iPK?EhIgETMJKa|f5|)k<-=3(kNWV(8Ox8_
zgQvr<16j9aJpge>FG0M~U$VZ*I(~W_`;U0Zf18K>mw3}m9GuC^{!@M6$8hk+p8qF2
z?R1z*+fEW-{{|~N1quI+FX@kdOk?>8ToK!=O`Jt1=`@%p9>~hrsDFakxTA;*QE}P-
z8Qz|bU;el6otB1v0xr+Q(|`ATCSG$Eoy`4C)niY^%cI|({QjxWPrd%J_fO4_T$ACU
zCuH&o{5_pL{I8#$NaYls{4enq-FgyroPzSFT>k5qPtNCu^?>gi($mE7{YM$40dxc$
z({RGZcAOsLXIj}1ITt+D5}da7iiU<xv1T*IHU~x;Kp!kR+1{>U`?P){FQ<P1uW2X|
z-hYh8o{k5i*N29ZN4{6;lUqGghfK3^hKAU26VMNO{QGwJe6T?mpS~SWr}3Qb-cPZ{
z@lw-xK32S+3XhX%?BuIySY-$$a|GDozf<u16l6W+avC3}k!|{f;tVCP#s68je<thn
zcKSB3CC_L3XMQ3MoQ{9~pYp(&d<;P=VjRjGe+-vS<x{8fq0`~o2~Kl@t4!k`;1tHg
zQ>@05@$i(!Kl$O0+w(*gfENJ5BCizV?ho4b2cd7~Hn0)yJv|=(zpeGp)b26FTxrPR
zBc_M{6nZC9%uj`7hLBE$>Gz=eZ|L)<fc)R`1(4*>%|pkoh98y+vshpKsW3m;H}Gq)
z34aTE`)jPP{=ZF=KQ+A{;PW%}l#^)phu#NFm`T(BE!zHX(f&{22Sl1LoWhk)CjC>8
z<llHW&A&6EZJK@m;0@sGX)cmsB@kblfVI?q%+HV+ck)fv|7IQi@AH+@Nruz$snf~Z
znV9vToc}Anl;KnV4gU0F82Eq2zfOmbKg82Ac=<hj;osnG{}+7~G(W=%XYxbc58&<h
z{1=D>dr-)Zl+wZyP5+@?cv^ksr}D<1`rZ%m#Q)a)AK<P3w|MN2QNT}?*{8$#)7?8&
zrf2X!bNv6RKZGMXiJPZby7Axfks!y6QG+oQM>VJC?LQUkPshjq+xJdemY+Zw|A}lk
zNn@EoJ(yxn-Lcm4{~yl^`TMjD4w}W$Z^0IaBi=LT*e?2a^q+t2P&q|e`qwX?tV;c`
zw)A}$%d{f({YM$qDx*oETho?u>Lle`fH->Qe9omDE%fjgz}iIYdI}099+6yt6iNpd
zR%7uvX50wbJQ1x81}@r20yY@1h#Xp!KIL5c;e{dJiZjn#=?m?C{=&qCzuk>5r|{(;
z(UF~l4<g-zgFDfY%L<n)D`@NNU<9j6nMVqi!9`aGbtiKsGgxjim7^Qb?njSYL!a>|
zvyvIf+(|r8{oQxf4;<Tp`cNIL<#dOH)ORFnQ4eZluW(;I#Bwm_6Pr0GD>t)hAIyvc
zQ%Ar=0$O%<9CiRGJJleBEW`9?=_$1|cu@8CUxm4J($l16-Xk_I7#&;C-R+PUk5&6i
zS9Yzy*LgWbHF^5{v5LaFGv+q6nFjRd55ybH;=Hj^Z)l=v0`)qxb0QvvcPyG)F}uIA
zmUi}TUbyJY%GPX2f9W!-e{t8))<ug}MhdOwd|i9#0&i(~)zL#eiR`^Y?oy+$wRFD4
z1B>{fu}ZgI>s8j3jyOY+QntQ3=sXU^jsbx_HkcLN20KtTyK70CQcJ=pWikk3ifnY=
zOOAvic|ZL8`dRgRAHk7mu_x?z-lu++c_(?lnrK0a<SGtvPV!6+u|0uyC5ZDl$&JK0
zoa9*vW-Z#qti`@O=6os#+E@s)?aT%~JR^E8Gt(S9b%PUTwS%FoFlpKMnh`IjfR}HF
zRR%-Fuw2vh<Vlg4u~ozaalgN!!talx730HG2k+c*>5{fvm}800@2Ok5dVJINv6}vo
z1#_kj-m&A-rLDJK)i|DDUb(w|$(qz7=8Med)P6RZ%E}|hudSawy6EPe*DSkv-M(nF
zd%^8P7p*+Axw0*CPQ`&b{OFu(mK~}Iw+}|6t!Ldnw0lMBq1InniOT}j#q}p&fcjhE
zg3HdM$Hu{H)p&9W2Of$LV%LMg<BZ7{mMdCjU9|0?hqgsg6Z1fVc>pzC_r}qmKeT!=
z)hWJoVBSO9wmlSGn>cnUxg=4m{^t6hAKkoq8kZ?2<b%g^WwGNc@W>_Su~zavW+aiI
zFHZdPJkB_Nmn{>m<LDqFHj9sNA+)f37y>#)w2pZ`k-YWePUcsrw)10R3I*xsn5Vxx
zLjU>GcGQIbKSg+IJhomBLVhr_5R4ZB`pCiqkzqy&j~fU9X5i4m0JH}a!yOMY$9A3d
z9ADx31M_=S|8egCv<Ur{lR5I>Q|njAmLpP)%Kq>%YBVDc>-%NS=g%V^fVry7?Ci`0
zmt(V%z+><fA299#@_=a@U=1-Ftk8?_%pdG%0z4TAe_rpKpE1`Yul#uU>a~OOE?z#X
z+cvx0$|-L=BKZwbjJ!`h@ZBF#EY?s{)lpsAxDEY`+4tgy#0AS5+Eyp_h14CPL~`pr
zKSRBAFc_UxRp<BMdLI9XjM3|}#86LJ7R)DyYv%}Av&a}T%)Ip-n#WxG9m+umiMyD$
znBfGP_Z{3zFvBN*OIx$#@VOc{Q&teZg?G_Gl=B^PEqr0Zr#O)WBnG$ex6l}k^hgSt
z0HdJXMm8p|fH7c`#8mQJdL(&n3YIXy$pr85SvX*nirBQ2DUmErM9H!!2`dgBRnYEe
z6w@NiCQ$_M(lFjn0q?_1C@`}Ez(4gB*b|gKnEYKaQcn>1iDQ;Tl<JN$Bac2x%x!On
zTw}x^QfVcJ(Y*{_;0btWI!z(i+*#?gpseiJwoGX(38n#t%>6QfRGCx>CGs(E5Kl61
zqTCbdelNWfBP;nQ%1QmAi#g03?m`;o(=MbyiZ13;w0An?rZ(hY-faUNFsF@q7dhIP
zx0xF<B|oXmBET|SX0F47Tfhk8H>VqevLx=FeRpE~uYVbzS!#m(>tB;e;#NEJ0t(ub
zeWy*A4>M_I+5(_K;&uQ+r;9RWyqh^E!R#XE63Wc?%=+YQ#4L8a8kS4-w3jXen2PY|
zQucFz6rZ5I#f&t;NP~oT0lJRyGkNXpOg(z2ojQE9n94o+CRA?*ocR!CfosThK#-#2
zG_Za*@y=<1{lyoj2X_iD=}y2Q7%^%~H5M)&3vs$L!9?+Y0#pTzq!~mdU<k>~a$#J7
zA+RtF5lp_A`u0S_BbbkovM`?|n9ol}8D=BXKq$ZX;#8zb4nO=bPCwOdWAqx}Yta6D
zBHeK8$Xt?-=&|Ih1V5K;z+8f#e6^Qw63!{6hv}hx$?eHIhjCL56Wzqd=Hx}hiX%tS
zrwlaT3A&L0w}Y{wd;}9huq~>@gMMM?ZW_^%hfDo}`SdIAyNN$|ze*$L3mKp@_wL<G
zUBSG4JZt2OFGgVSvxh~`WPSz*lEc?rld4CWrc(IHb$KG5h)YXr)m(ZyFY+ZDQy_iv
zNhx~8#$0#k5b^6wK16)+MdMqyj$gER>GF}~S7uVj^<e7B=K!y0pngoPEd48Irq3tH
z=YmO55Urm$cyjvaPUaov9rSK{J30E@nwdEe9}-t5L9*a6#gb|MVq)WCPvtN(^GdUu
zH-jg$o10I`R}1WCUPlMuQfa0tM|w`me?Pj9X=UMmyqC>ih^0~*J5#)9X1*yhOpt#}
zFz23}*9m+*GIwSUEDju}(rK$<4W+C!zMjJA(9C>*gM5$eeJ{t;vcV%wC+9vBx7oVQ
z9C3aU{OGaX<U7fCdWrlrdiN$@J?rF32Ahc$$%~qajcGJ*PHsO&oIbxIIu|$)P%5+~
z7}c0Z;xX<sD+!IslnpXviE(rc9UDKje$-r8sIu?q0h(t|juF?{zq{q+oB$`&?TT@o
z?dv@)H$Ev(%$f%=YyRsD*36tzO<=7*z^YGeU0jC4bl=Hzp@d0VgvcQTDT3t!%y>^8
z4>I||PbP@U1>b%)_}RA$ka6sv{~UYrl1s>(_6|aM<o!G%k9iWslCR|vJA}-As8x6?
z>SXRt^ClpWhk$RAtR|5feVt|-#0wxCzepV02NL`DQQ{9M#E=<OhmUdjzNS8fHEyvy
z0KN;e4X{I4BTzUwZIe@<Ci6#_U!dj@;?-Xy|3L^~-<e$OC598kus69_ir!=F2?nq>
zC11%)p&T5nF|gWS1hgqRd1<mW5hWg3oBW369eb210hJ-asu-zn5Y`*MH>UNZF-}F`
znJq0%nUd_0V$#<~%hD&TPV@;?2x(z`#fH>);)IZmDoo}QTaLZgNPL-WC3jGVlb`n`
z$NONCr8qk`12n>esc*bc_Xt*<ZRCT;zKTXkSu%%sD@q-XCXQ}p>qksce0X<S55`SJ
z@sBMauf#ibIFZyRX6PAMMgk{vf@Prv&3p!fU6{)pMvC0$iOZ%r>z2vHS6?M2dv3h(
zu@eBoI^tn+A-xhyYY;PB0E-LH2Z6|i%mFk^C8wf9Idd0<dXtyt6aPcL!@T{s5$4=6
z)bi<UWJ0P5<{6A50B69FMQlA;ID_QJ$=I}fWaE?6qP$~cdFTPADUZA^k7+{2WCfaw
z<}wGE1G8t(Ci;lJ*|UM#;*2#p4}HK`ahhz|=tXonZf_SClQ5JnNH3aTYzf9TK{QX8
z@~Obl52@^<FXhuPDF^!v$e*Kh9j*^}nejJV6j8!wM`tsw31-;<^G@IYqUQ&R9W_Mk
z=r(Fo@@oPOH^Tb7bKrZn9`tXZ9%5))R?ZVN#|Ch-YAK}`&+_WQXbYwu{TrrG&;0#s
z=GkZzMZQKtJ$gC$sQ&d|9U%@ThmZW~bz+Kn_ulI<c(1>gdH17>&z2^SCXz>`XJ4Go
zhg$~uNI{x`T!vXOz*t~uLv1@HCvF*ISO4iv=EW$}Oh1!+ALZ-Od&!@x?mYMnF_1j;
z&A~fyR(IVPrGAk}+{GOF=)xW8tae-obvmKvo`!x&K4|6MX(WM3pJ!;aGrvvCbK2wb
zgd(m84QAH~dH%YTDX^ijLx-5_Z0Hr~lZ0bB#b?s8d?{w0%(Ev@FKs9MoyD0nd|`R=
zAo=(C$@av2;^&DMon+H7F}25e>;dwd3~ZC|K4?gomQpMT(-Yq5WO6|?d0!$*&q^L3
z=HeY1gw^>I$?xF*1b*N&K!?brfdyfTE@!5bAX=lumD5QP@s#00#DTZ4$+3107xNat
zlT2DbusD$!>2Zsa7e$j7B$(e4zlVKw6hzq5L<!!bI8mT#Nbp3msdnM)fpjqrW1PUk
z%chmvID3F?fE^VDu0gy-0BOe4HqGPHxS!T<G5wwRP#&Z^qseEYpx;IbK-Xsy(P*Y|
zqDPyl!_#fUeGT$8%%~5W_sJD{E%`t+`Ei2LL1KFdLzHMreo4sjo~{sEC{UrNn<`Z&
zRtHJV)`FX88hu!$29OXm4s5g$=Mv+|tCLfNKKU2c_=Ccw=n~gW4A2MIr8T5<(~#-p
zrnUGem0-1b2AAk@yyKK`ky2OF^`(x`D?m1+qzSM+(C86$B>7Du`OR!}Ujp4n=O;Uo
z+lWoXJvGTEiJatHL@d+RoR6VA8EXl23(RaF1ppQ2V~~jG^?~H;iRA13=nYmjg1wYf
z5w#7;F6M63N!-<t{1xd0+m@wIu!Gmbh)|e!Aziab5HA7*W3sfKd<1R+ZrU!6S)MxU
ztfwro=wFRnySla-$#0K|D1UU_{{8Es(dMC{W~|FHkI_Y(0N{@T=0Ifo*JfxY<f)1+
zn9e5*M*6fyH2Ew#@YlaGbBX$t@p$CUX`}i~>IrDsv{9Y1{l6sjAfqu&K&#luFOS_@
zga*c$7m05>iDv`JT`WA0e@Xp?x(^`BW!n&(d3dQq#3fxG64o-;Quccm-17zO#FnM4
z#~%0fE^Q^_KFYx?&qEhS*x#c)I@Ei2E?TQ&ZofMh!xY-`_($9l@>`fkzZ$3qd~fLm
zP19Z&>>s7@<j>eu3T``D>J0pLGu$-c2wpA-`-Fl;+>-NNQH(6U|BK<?ukK$kFnj1`
zC-YTl<JMn9%n4oeH``j{yw$_2J9^g*f4K6l)y&53>n4f|YCFmMU)<VM`{<q<Uw-+f
z3m?CC+d0uigUm}8Ej#CzqhCgu!$Ys^OzigMhHL6q4sZBw{VmMFUr$!U;&WJE`iPPO
zE~vnV1XV)h3~w&$(*-vY7fOdci8OeuQr=u#9ZI@OQnK^)tN+m7v-h0y&%Wd7;fc!4
zo8~S?FG{XjBi=K2@~S1zETP^%db`Ix_}W!htXf(+=bBrVPp$|@8avkgNxz)$Bs8NF
zyO&%%2-)It(DNa#7yFK~Y*x7pX~7F*vnuKN%qPr+$;;8k5oRCy4n>lvl(`kXi28_F
zMe+mY1?C0>i-M%m_>%SmjR?~7Okvla+D7{qFnor;fDkZFYK(CjeALZHXZt9a8;Yfc
z`^dx8tw595%QM5{O0s@FL>|tlYT1!vZ;?3>utD!mt7uI5T=d*L^xRx#B9%Y-lv+Zz
zva9)m`;~1q?DEGerD2CHw3-tySwbyIgmX*AZV{}UT-wr}$jgmSqB-*i)&i^aRmGRn
z@!EzZ(P+8b`L}JeSsX(;Y6)e5bW5O&|0-n&Px$w<J$+$F!S@TpIKO`{#cQboz#+_Q
z)3^e>Nfrs)il~B${rlh9vLSKx^+@<Aoi#Ff(Yfy*`+`&=$*p&>Fatdff6Ho?Y>UBc
z@F3Do`5p_{lhW{m#+^xJW;(#p(q&-NQU5?%r%4Z{FS;M6cneq|DZWyj!X+$gL1tq)
zOI9Z*q6uPN@>*hEly)c2Jt60hucK<gp8{9}b|2S+m362Duy-w=plX>9Zf%2Qa=Q?Z
z83YaJ`nKe9v=3PUCto|*b&&a@4Fc9LO<n@7%1emtUCHyA4Ja>-(;v}~L;J*`Q0)BG
zC#Dbu<q*09SbAm8!oeb-&=jd+Tyr@i;TY1UeZDZ?{^RRc@4NY_@S%$q^v+(faN&y5
zdz$xdT{myj$gJg0B5vW|ZmkGcj5StXi_FM>lU9llI{zd59;&@`@{DEk#%dbJx3^cu
zhi^?x&dV;(k1bwYAKx^w%IYpHv}mrqQA#BKbpF<s%1UfefPPNC0PTnA%7V)dbdd5&
zYgiv&#5OZbmVDvb<;$<dyE>Tzrk!lgP*v3s-if<X_pe1Sr^I|$>i!VU1Le`jC^>NS
zNUDAC0vN!ra32WnS4#Je05n)4WcyBVZ&ivE!BM0Ia)fq)RSocWv?d&lhCgl&pIthU
zQ||P)to!Qhk*OosZyxArjch8NpA!#8+t>Yh@yHmWZ`jmQbM#^SK5;kv^lYA8)jn3{
zs~+x(x4r*d*@GV~9zT2iV0Ft_%vU|TtFGnso69cya>?j8yo-4imca>nFYy<s1*RHc
zR5M$M-h1Rd+MawpmYW;HJ290=9!{OcQZk3Wj=ltD=E;F?9c)hmv?pfG4y(s4FIM8l
zW_b=~)LH@<X_1n??zX1b#OynyXuDkzKJ)AY%;#s1TZ&5O??}`XuhK3nLFXM^M|vx_
z7Cc_GEcuVnfdz?A9z^~(5Ut-iKN>Br+o@pAg5IoyXfy?1dJf>F8n_ZJ1%|Ij4IP-^
z?1RO;<?Osmu9Uu%3jH?Y#ihgaoPCS>VvqR#n&|XxxO~x~eaTmo_kv=#1O3meSgfzE
zH8zV{zvyz`lO2;|*Cy<fLG<jReftC~>_3XlnicDd^`+%5{W;*51Fw{UU>bX<JpmKp
zMsSVO;0|MEtK!0{4Y+;N5dxSpz?%A;Sun5fqE_bN@!hV~gRj-rSKqUI{qwu`KEr*A
zSwP-!?3tZsjGZ^wzO|)SNF8R-&PBsvW^K_z-`^zzqj&6n{-wPG-SZBh<B4SH85f>6
zwkaOf0;^89%Rka^W$mn!Av-e`pZ>>@_4H0gv1wpn6W$Xifjf0?(?AC7DY(P3z-vH%
zVJQlWmW+rdpyH%EMf+?8$%>MmKVJUq$lQHf&gC7L^+e*z#Dc2wU6WUp<`9D8YwvpQ
z@+&5njuF`pH~lGDys@=$;pDkzcCm8!pM;Q}VEd}lbX0+$8)pXbWD&xpi}om#&bA%Q
z8%q{mEML^x1v5|Y+_PqdZW+N<{k*FU?N97kxm3Gc-qtnQ!puwa)9nB+%%1^IaR)d)
zU^2zaHsb@iT_PR)L*nuZzH;uwuI#!*IH#wQyjrK*8%xe3w&c&3*-GvV2xY|5<UMjt
z-il0nQ(It+B=(boNj{T`Qua93v1dkakZUsSjfCUJo=l9Bu>`XNH+`8mH%6~WxBHRh
zHtLL{J7~A<=rz;^C5D2x46EW84(Kkbp1cd7o$fzm{U-Ita>+OGPR0`q&^O2s@UPUf
zxBwUmo)z{Dpk*i~>%ZUt{kU1ZHO;ItY&_jLm|^93v3ahI;vBnLyI|IuzRkA2Yxlmp
zdUosb$h?Zy@jF*+?(696dzjd_IKOtdqo{X7{+Zi<w|SLGS2edpt?L;+v}~fYb9mrl
z(1Te$i@XQ&g$_hlnoOYSfmPznrhDz#ZsZJ~B=7n2o%d`!`|g7W@BXZ_Jio1SPDR_i
zt48MI8)HLTFMXwL;qsMt{d#3*=g1{5>y?qAO1-7K?~2D(bassG+tS@Wn$DNn1Nr*k
z!j?%{n<)Xb&S?u_qxK|!`7E1BK3j-o%-_%xU+OlURFF?mFEKTKEzW8J7v<XVL_*fH
zWky-v+K}QIACvErhe6kX+GA;&LO)hc0R3P|@cnz_yK_db@F*OE@mNF4l;?`kIgIGk
zJLuD!_Uwx;<Vd`m*DT(?a-Dx+bl;wvPIC|A4~D^~)a~?YY=^MkX_o!7?qX0fsN2Cs
z41QvC7c&O^R$YVWH|RHmOc$Jw`KyVE<W<!~OM+;rPF_V!R44BTY)Z+KEP6G)7^DfS
zfk0>ic%gA{QUuw+C#IxVGyi=0pUkHd%%}f+n)xSqWQi<fWbR|;y+l_eZvkxz5R>T7
zgP?@%NfCp=gmrSB0bmw^3kTpJh8E_psRqNm9q*6{R*&$W67a0Oz=Bw7;~8#W^7hTQ
zJ`ukCymgm%M9xn3B$(pFRaYg@^9gj>ink8k^c4H3FS;AuM@$VpeDfQiXk4;xOHF|*
z)hULHmF^!Kd?fvJTeXkvZwB2F+vr$#gmRoxnjqDA)rrim$|N!)y;L0^rt0Z~*d_<l
z5u!XoII;t1m5D#Q_%UV_Jq`zSJ$zl8P3%t)zsgR|XTQt3hg?J_u-(aLXS7A+qU3Nt
zu_n1EkGPlo?ATKcWEPSyU|vbVXBKlibq<tO3YHf1j?-zy6ta^?D6-fkcT(phe}y(P
zTNBJyw7HB}n_&Ftb;{2i_n(_Mb`v?608PWo{O=WRW(S}zEZ+cj_h<BT^i5gkWxbyD
zCE|gP*oTV2ABh140RUM2VK>ZZVZ(+9<}e@?u?U2XeaT&rS~_tC^TBZgFq^zx8^ZFX
zuz+3pC5&|?mNCF%yy5e7MubO|0yvi=#p`lrHZom=0wTp^+`wh<cklwcbV<5Q9uC(6
z-iHWIlbx+S91O>iRs#V5P;gupI#rWGTn7lE#T%aP9v*2}Cn<g$fgezY*iBu`4YO<T
zav*KUh0Pcq;aZ24tip#s$Kn_Y4!YlSm${>yIm08X+@!d^p>&g=wMuN)a`N5H!hB(=
z&k?Vatd<}&Kgt#Dzh*#Z%+Hny1oGzUsBc#eZN1gtml3*s_cq6?%h8g?^OkoMRTVf~
z(FW6Bdo_jS4Pu!dnY-f#i(O*X=`B^YVQ=N2;}Hl5D-KqV7Vfw#sOR;x_p2_7wsy_d
z(!y+HVOsOn7ZB1CnW#`C6r#Gth!jZ(ifi^Tx2S|Foz6chH(5mjos&-}<+Tb~g)C<u
z+L~=K7~SJz9!l3-mLm~5*WM)`;e?V83c2D!kFsuMSr62Q;A)&aMefi<OVgF5Ezo8m
zzkwrC7}h(dLZX1Etsz#{(jriGcgO4KSW%&<JfM#7a;&Z0R!-$!y{b)Vt0FyT))W-F
zd{&FOz-b*MME+`Rj#R_rD2=y-OBySiiDe>x@rJhRR`E)5d=-i!h%PfoEK?SFZs;Bt
zmqV9&ty)8g&aYA$2ugCzhS-otTA(tTii;Zq1+9DeeqOm&t#lhhgSiFOa+@$zv#&=}
zVpVskX(Be&AW||<FI6fud@|n?)Ow97KS?Td4h3B<;Ds2s*<$clltnwTDT7L?X>MI1
z={SSmEG68C&!v|xE#V<;vDD(KjJ9=?zs$|o<P|D8GNBMW|G-TW#|e&uUX)b<KAncF
zPFQOjuibG*)+DUlu@dHB*a)k3JP7M@yqWdKtWSZOF_NY?Hn0a2a=gAB0hU*qK2Drr
zf?|;s@DLLetf2@_6}Uxe>0%Gf;wNA<sZ~z@z%saGkaQ@6TyV}PPxAwbr~%tk)SX!`
zPJ*zZlOkA_RDge{44-tq+AtfNmo}6lkO<9XeSaVofi$#Sppq23!0S9>!VMO29Fq$c
ztTPGq4tvlq(pZ~m%d5VE5v$><;FUawq(suNNVy?Dzk=otJbdkS%gdj6`iq3hdh|t`
z_Z1GhRn7b^r!rPH${bc^UrCRcHH-PVK5d0sVKfMdV5wEwVpX_0VjVW~s?t>k`MJ?u
z3gy1=UZGS}+{q^%lp4(?MK@1$uPR?WzBXE>beS!Z5~-_{r&R{sm**BcR7Qhhcu=L+
z7ppbOJ+|)b(&JeHxwutVT;gnM^i04s{#v7Tw$bFMHd_d>JewS^REtEan58rxA2p2)
zsJzX)-Nr`b>bpo1kyr#?<?Uu|pLX4r&aR~)?Yv07(7Ee6htc}xaifv>m`CR3T`uO+
zv;fT!%9wX4R3+v!uhFPp!eO4IQ458bM^QEN1dZYZ%{(PSWgH&!TR95xIm~Nnl*<<~
z9~!_vAT91c2XT)H4do>(CYBZ=clp8)5LRW^tV&J4)*CMj2tqC>P_bOnS7x8nqvsI2
z%H6rSW~bAYS2h$Zwv<HdI)%+w7%8yCBVwsKDwLXJ3NiF#C75sNr|5OCw%X#X^;x@M
z?w^}rWZ(m-S^hBAVw^~E@(eQuUO9c5!d6!K4@VR>D@Fy68!w0i8{mB!-`SYMl+a*t
z8cPo>V%#1g^(|;t>>4Gk_|a-yfLo9ai)oPLG^T05c8Ahns>v)+rSSldX2k<u!UOYa
zjEpSLeyX9Ws-Ysfu&Kwj*VU7)<nok(Ql6F9WmFZbR64D2q$lijnEflz707$Rt7X63
z$b9<1lBqB(+gj|YPzAMO88Vs8x<>eBUYs_n%OIV+@)i}6pMjHRs*4KUm$<!+RW;0e
zCT@KR&na+A0-=ifaDgvS?it=6am`;-qOfPXEb$LwQUV3!{GWN8mOMpaVK|q(e|%n7
z_xQ5?58kASnpDCT|LTNml%o*0YPDva*<mwi8`MK(Wzk(|X#Qo--@bjIy6NWH9cWRH
zN-K~F&9#agBHQaVbG8T{zeFe$tJEP>aK*YM-95vri>jSPmNQITow=l}-O|8~aSfKs
zEP9i_sQq|_%#hnXyIiNyJN24^*Ti;8=J>0|Y+9b@#+{Zhj+=Rb+6a2X1z9g<y@QHT
z1**qf49Fc;NXaz62SXThmb7Gt6LpHA0CJ>Igas{TJE{9DPJsM}=LIOlaxyG!v2g)l
zpZSY9U<$tYaZ0bqpb~q@@*7A8OLZuNmObFFFhgP$8$ce+;h==@A*3KdFrgf~0pe*e
zk^oyR1oUJdgRcn+Tb$B}GG&RlU2adRe$&6HI^cBEDpIQ0kzguq_=RSXBE0q*yb;EY
z2FbCSL<%XXjcsy;!PP&eqD!ng5g99p=sEccWUF;+`ZchAR85JZTcPpgMl1q4TPEak
zw2QRmJFNK?ts0e(&m$F5o`f&$sqtHEWVYT;2zb`32P>O5wXZjHJNmg!ttzUe?XBlG
zjCFO&T3UxHvy0?Cr4H9fb4&fEl7h-6qeN>E8<Y~xfZNVlBi4%ovw9~QH#O@e>Tx?E
z7npLgSKE-r&bLICc{#_kbjmy_U&1pB#3F;Dp-%~OLez3Ok|Nr&T&FQfOg5yDN)3^6
zEkfEnsDsGPJXG0i*I0@JHlf@|YPz{np|VF;+iBL@NV!?V4dzD8Md*-En5SsrD-?X=
zxX~3A5S4C=KwrG1<<cs>xJu)Y^7Z1rl4!O>ZOIRCd17~adAU50W02R%)jevCjw8z9
zR6dg1Vdk1`K8;nOvl9~Uf!si!{{l%=?-9AmitHA5zNx})u@sw4R-}@IRptCrP_Ufs
zo^v%ZtHG{VV-g!Aaw#Wb&vO+xq+FTBY^#<(E9p|vI+;={(<MnL9WG=<VNq4z2IaO5
zxTG=E&ErnC3S9!OjteRWlu0~hT{Ti*6-h*LK}~g=Qz(H-R4o;adpn}OvLcA#Rmw=3
z6lmz5<%2%qHfuC|mewAk%IRIO^4D*&UdZ||>yxanQyN1`xTbI!a1_>dO;G^GddxW8
zA$$$k#$Kn^>%#;9cQLl6KL`4m=9L*r;$mFIY#O!<tw1^{Mh}N+JwAOC7I$XJBOFOl
z5c?)86oA4o9b~8uc=<G~g31hK;o_B_!HS2Jpr9$L!IYL(u}|=7s$6Rb_zYUw><DwW
zcRO-8v#-q$g<>kTdL7T2XRoVwNovXd+VOxyAarp9=CD<N#V$wTd1R=~o>S1<HEZA;
z&O;NUWqm_;I;ry-YNDkYSAL9W)D2100-rZ`b#;YAu2OLIwko$!B=Nqj)~MA4M;22F
zCF?4<p6u@Jb=^T9ZFMJ)Yjmz+vt6%RRNhplk`lQ{&r{es%(TH?S=8TJ?w6WvLUcIj
z%(Ywcgn7d9vSyLFk@<U*?Sf!zbg{p)u2<aD*jttNJ41d%DQT-P|Ib{ZuR&R{a%?m{
zS6(MK7j{%s?fHY7ryu4El#yy(uRXV}sbi#DW7)Iw*Y~g9th2Ru#>0_fMfL)LiAP!a
zJdMD{*O>xJfzUd4&PGddr5w`ftQsJl+pn>oF<dH%_cS(eDX~l{Gm8A4k(Q>ieUccG
zca9IX&W17uo|LFKI=)laT^m{_7RdEpyMAL?2c^%8l$6V);A6(~xHF$nPtq4=jb*)+
z^)0fZd9W(nMzkHg5Lkn?AS`%U^9-<y<?S$AC*T@JL3|m<DrSaxV#Jz(gdF^YW#(4E
zSvP19W>^v&_+rY~BQq)kU>G1&Hs;(C=w?Wnp*St9FhdHs6PiUm)>OmiT2_Pvi&zgY
zMo{(}%*iuKHN1sU6o1ctFnwXwg8hjR6U&j*5l~bO#lp!dF@><tAYb--_Dy&XC?zG9
z(r-q>AWh&Uwqu-43^Icnq@)HeQc8uwi!igI4l=;439n%4!Nr1A+Hm>U1hM%E38d7V
zU=dlImK;xZ$Ky!T=??M;-kB>bMrY|n<_vAjwToJ&{0^JYE!;Cm=bW$XU8$cxxC4b=
zDw*~04f1TRQ}Ffg%|pE4&+cZvzM;*n&=u;`l4?p~6{#eqrVZJ7<szdY*Cc4N8hk3h
z-K*F5IU=3TZL>NJ20d8aHrHk&&EZHmVjZ6=5)RFIOW+bjt8=e@M9@2H&Y;CIYt_zt
zA;o?04;BkT_nlY4FAw;Q?qY&l=rMR*ZfD+{Ybu7%mrDQP7gy<gN^J-=G|r0c8RXD3
z&5slizHCp^*^^D9&A~Fl=PSQmLuFSNMEf-=t4|lKF3r}PEh0h}(B_3TWFFuzC&#eN
zuXgA)TB}b_?-kRGp=nl*G23Xnz|2u|Ocu*P#nVQRw)cc}BB5rsu7l@rXm~b<!>FT4
zMBCk&3n48LMn!&+q^P<4jc{&AM7mXDuQ>^^Xp@hpZX5A?AABS@W|DI_uYR?BLAxMA
zzPu-9u9e$`f)S*P*(rhL-gczWlN8AnmCDe7LFm>M1#<H8R1&p6FP7(Um~#VxYUa^~
z5Kl%SjzB5t@7Dirb|0rYH{LI{T5T4K$(FB1)G~`@U2^h&C4#dj0<{EpR^1pWDJwI}
z^n{!Fl`l_HtWrt}`LtLhH4%huL4Te^Qll~M+MX8zx4GbLO^;e6G(|7*gq0q>GHP}~
zt!NI#p+%u=8L6T84!$wSA#>F_nMg?KHG_zHHySkrmD*#EXY-x;zWKyIG#VJp!ukxE
zPsl%$H$#jrjQV7G0IYurv{H^(Qcf#wm|CzRI4x6Bw3o3hfnLCs6SNfp$&i2M(>7;M
z^7GX`lg}P3m}}xLt<ymlXz*u^m1WWLeHD2m&mG{F58D74&LUK05N`O~J(te5I_6cL
z^U$x?4CQ-me6i3cT<fzm8TH+}Hazk3#Zzt8Vqr{RDueqGwbkV4U3ACcC!Lkor*zp*
z=os}7^a3r(+63!qo|AQP#v;c84-=-%4%97&o#kFo9hS+Qpl~2c5SN&wF_TDJAK?h*
zC|r&l)2$3I6V1gknx%f0ze!;<1<RU9j}ww+@3A>jw9}>0(jFRqR2~i-G(jsJtBRFX
zaY+d$`N3SXa6CWH?T!ssXf>LtdXJx1T##MTXm=m5No3WF%IZCQo-meQWX>)whzry!
z43?<LT3YPLD;TtDO>v5EGZyvB`DMgBx~eo*@xO@q%T?bLQgXSg)N8h&Y_x$n#JpA*
zCeERg+bABfOEf?Ejm9C@5=OGCZ+viY<!a-s>g{ggey(IQBIoQ~x9*nGigBuLo<grx
zmr=W@#ntW>f@qvv)uq=Du3OqA9wdLpJeBW8&A0n<#+XZ;=FzwQ2T59sgv=An?!=nG
z!FkE+vTxb-#_Ncza{Hl&W$f#N3)WseUM#FCtRcH3(P29YIEQ0}KB40DcIY*9f?v5E
zdn<h)R~$tw^JUvwk@k!zlp2KjH}GnBgJ8S2((**BP<q_p7r`3=;Wa_IMl06<n+;QO
z%i{qT!Re^$xH9x;ejv7Qusj}71wUVEO<o{cR@K>NA)<tN$tQh&na*in9J1+S=kKle
z8r@~PqAlH`3vI^A(K!{WZ=8!Kc--I%sQqK4I&yhm_Oj&hWa2S8)@r@{DX!wmqr&iQ
z#1?{h#2lP`{*8f+?faQ?nP*;k6_Ix|uC$0K<|AfoP66=_#Yx)STwHg&rovgos~ibL
z+E}w(uu5zJyGm?jRxPYD-<H({Ys8MRxC?F`EtgOOGIF7Ua_kAhau;Y!<8feF$JIuP
z@lV+0(9+O85pdzcCs;SkhM-z)#O28bAD=c{0LZ}gz=={W^KkSC1RL=xH)uQ$`u4e2
zk;N?XqVtSF-gpZlTE?I4;yk7_oyUESc!KjFhxxXv1)-Y>^77<)CgsmLPY|335xt9A
zcRcH6;pImbBVyKPyM*h=#mZS|TmygfEM=Hk|DtLA-<fC7!)tw7jsGf$y8XcPBHCFl
zYF)ZCP$e^n*EY3_g@>9C<nFF|YOg-9_5HPC!&TLXgkpK_fx$JclPmTPZk-xZ=i2XB
zGkdajXq{c1Jd9SMj+b9z?q<$R9y|z5$@(=eBi7Mhf{(5lJam0oLs_d~Mcr+%nr_M;
z$5K8tAl5%vvc-6Wu?M#*2k=aV1v4gKXku1%VUH{;0HjLcS=dvI8xIhT1J)(07vOVN
zLxB6N35!35T?t-PtWvOA0T+MB;f9HIW!b}Aa>ULpBAT-mRt~q*6qx8)CC?E`toiX^
zFwff5+&7zdjdxh$+4)UbRityOlICr{aBh)FX-A}%ujyzf<OFA-xv^e3K?$1kX3Y=w
zWK$Yq?=rq1viSa;GPNQ?E$eRc^wiXgjV2x<RYNX|#z9x+&CcuWUQk&q^tQ^(#3ZuH
zwVHL?5{XOZE;(EH=%4-|lo*cg?CNUBzjR%=*BD;CU}(#QJFUz*O`b_3SS<1xonaKw
z<ZbXR9_U<eyIfg05X$8RL#^5RoES3&1{rhCoUKLv!J^J;-vX7rBLck=u*SskyXn;s
zXNTk8GwU9u*2Y-_Gkc#4{-^y}H)q`gP=X<TseyjhEE0wZrbhb}!79uE9Sj-(g>uIE
z%%0tu_h+8}&^ve;Sddp>uq&s}PIvELKZP!|UCcjV+Xd?=3t(GY#@zPx*UW8b*4JO7
zS;w10p=P{4lQ~Hq%A8H#nm#$rGt^sClVddIJd-*k51n**`nyEY%<|y!K}j;DB3eT&
zEx1rjB7FiKIj7wD7mtXuYidk6In3ki0Zq-kI_=FAkGq<<mi{A*5`P|grQXT<DC_gA
zZ?lde3W<;kBKV!i&r&E$VAzfY%EDBcvS)#<u^|m<qM9Z!mej&Qd>i8he2}p$QuNKm
z0vyy9uq0SA#>dnp77>6<aE+z8R;5*?cmSXSs4YO!nrx)Ohx8TZ5hpHF3ItrAu#tgf
zOeYRqXKwJKW6d5LC_n9((f8FXDh7*w>_}WY+A`V_5BTEw-m)@pe%u#`!;R4v_&3Rm
z;0f374FqO!;dYVSgddc}V$B2@>xgB0>1;Bn)#^+LNoBfVtfK@WqAT;*TO=xu_xHyo
zN{iWSPd~iA^auWO6hH7sENgJP;x&Psc%ZCdYjJHUXuG!3+TyJZWr283peF8eH&nXa
zmH4eZliYyclS>M1*_DM7Iex_;H|1qsGFatdxz%8_D~&?8(O~f^LUOyo#S?J7a#BQU
ztP;7JplCu5bt3Z(c6mtQwHVA`Ze*K&;9G%M(Y;SwXDTl@)oDwbN997H)N<07#FbT5
zmCWHE_#uC<)9HVCnw`~WZl%`JuYnHj1AV3@rAO1Ogi!*jPWOgltfTQ21!LF2@^q09
zorg_O@IgB8Ion%_Cw>6@qSktflMaFySgk_m3?lOEWdGzYtJBz=995DZJd0XP`X<-H
z<YQvuqNqx&Rx*!$aU~KFzi`@)eJ+xPv?_hJic3DbvU5>)OJ9I<Tbtudu~Tl(bNhPN
z1}|tQ_5;q=#fhiqTly-JziM5clk^Ydy3A@K`B7J66&)lL-%ZdYtxV}_^d!9*=CG&+
z89Nv2YtzKas=pB$+wI|?D<lgRDK)s#DLD%i4H6e`xW1VBuzHN^2MP^Km00w`2J)07
zxF9&e7N$9B7d?67rvCm-HyZjKIeI%UX|{_MM&gy#4Mri?s?Yb8#e4-?6VI;Car7Hj
zWgD#7CMy_)HiJdArO?CiI4KT~5E_L7Ek%X>=bwAU%D*P7rNnO!1?>idJt&ri{DI-K
zo)c6%{ZRn~JTt#s$2<*PT2<8!9q(70hXekQjJVUHl*yImY=umwNY3lLbI;q>aFO+j
z^Y1rK&9YWs&WtcuzIfB@LQ*5}dIdP{i}{3jpFS7tkOt63KnKAb4c8b5T*W0orGpzR
zBO(dRk??IWoPul{vL;r#k+_)4K_g<u#`@2|BGV|r^x!I#VdDL|XtR;yXdUJSAI{H{
zOSQbF<vgXw%o~!5U5y=ml|_*<x6NHt*6ZKM4|}aV%3o!&F|$aHe6p8(CdQ+VMw?0n
zGQDyqwLDqHJk;fp=IH0@--J$p_Y0PHg$x`MpXam8DywqmRyg(QoRZB-U2a@26j**8
zN9Qy3%oTsMI*^GtwgB`ntk1tq3g~-5r_F;kSnzZQP}>xS0BG6i8bHT_4cAeba!YbZ
z+%O7Ipu#T9(m7o0>m&vFkx7YIB5f!wRL@zxdXBoVv_T3tCL{S}o`U|V(6i5mruqv!
z%%K}@pdgH`{=;{eqnE2xbDubHjcoVu@NU^P2cDR#QeDm*edog$pZ)xjr<f_*O*h$?
zsi!Xa{MmqeYRY|8(**`U2q1{zV&0%WrXPS99Ee_IBPJkV7Yd1G3m@TfvOy2fEGf|e
z_dtE1KEA8OsyTLu9MD)x?oucB6Z6$&WOBbkLCi<Q1y(L~>{T+K;#x20j$W@J=a6$W
z*GDaC7+!L<+Co#rxI(8>5aWoXvo}-6UOM&?wV5r;*VLPI7}^kmLqSSHV`OCFbmRqF
zI55G1V1Sg^hz;cCaFGTZs?dhio6O@?-O<AQfHZjn6$!u*Z9!IPq$pBV#?N(Y1RUml
zWwt}XY*Kb2Vn|&pj2i06KM9ijt2x$(B)K-TgT6^1z{g|Dh}#@yyI&@g63MQ-T=FW)
zDm^krnH0O?cKOW!cUS`v?6?lV_nfSJb`6{EtP!xl*Jf>p8DT-U19DE)f^{gcWR6Rj
z#spTxV$OiT!yJy_mtn&XL&aK_A;8yg2`*;rg2spfrxd)CIxkM2XW5FhVX(Zdz*pI%
z*>p~vV^X3zUI|I~A}jMtgOtmY#`Z!CiEI9%@u?RhlLK8{1I%x4{ms00UpJq-zHYxq
zcHz8@msaOV_HXICfqV5?>ruC@@@?i0LU8cVwP;k8%N#v$+wD^0BR5`+oHX;*-u(|d
z{K$`*brwpj(K0VHfA-3^EZcOz*}QxC@R<~UZfVW(+>u2~Ug4s*n3tao+B61fiPTtM
zkY5_wetF`9o0qLS@3L^ES^Rcv=|D%vGU7F2;=HR2)w){G>XzEY!MIUWl8n|`8Vfg9
z_HT?=^qOO_trvDy-rC>2wlY}QGw@Kb@R81zE~_K2vGtLFA2pDkc?9!YuVZyEM%Qf@
z#{$a?#jV-S?A&$E9*fQlu*10j4Lw9(3F}E5!1Bt6<gnXA5JB|=N32T)Aymme;}{9b
zi^2J?hPbaEI2M6Q<$$31A~hF24asp5I85uLO%0DhbArIP^brS>&D`iAOQ+?6Q+5lw
zn|T1-kWEad<&;PGRSP3V-&o2RF}(84vd(ANZ5g^79>6Ry@Y|WWIm^QQ9$s>P|5qyA
zXL%bke%rE7Dn)Mi==b0Mwd}JbcUsmCT8Lj*22m}Z3FgE;2s1N4Vc=)*#Ld(T00tHg
zACZsImjdVP$2^GjEv2zPtqwz<J9yg&Iji<!pE3}Z6seRNOi?L%lBeW`ObILlqzrH=
zC6EH<w!mTGihOLUpwQV6Haa@X4Am_*yGzir@&dG|zbu|#+ZN3OPW-!2O-t)Cy@d>l
zs+Nt07myb&pQX|)yi;Tn$&~`Wd?M;H8b1r@m9JjAWbEL2*ND+%l}cB?jd<nYXI+dw
zaVf<Tng1^4!#^&pXeeQvYlxd}`bWL7>kQdfD0`*Xu4NjTZ9+*i^UWJO4CrZhquykz
zW_Gqfs3IFP4YJb?KB3H-%QG-Cg*HWM5`z1bfH{P{IAr;mB~)xj%j{*$Q?E=?1<s>c
zb~~NrM8!56^ASSK@gwh1A0LHLg%E3(U~c8^p&tX8jOX=U4(m%z!5T<sfu|rfcl9N(
zp345L8?p{%-I4Wkh>Kt)w@n?y$jkX*%E00EfcAjbY1#mrmAw;oVMc`29tuQ%DiMs^
zDC7XS4;#ztNC(_tr}V%N*mHa&;T|3}g3oC<cj0Gnjl(RF!|kyk8scO%kcOiI0Y}tm
z;U+|}LO(;8yGPAuZdz_p^T#chSpH(U2KGxV<9xMcIdc>IqLs7YHx@-Qd!3^Zwpt{M
z#^Ci?Xr+a@xvlJPwrWevTxP5OTUi@<lz|}BZ;5%26D8jbP{GGPU>Ne&ex~Pfvhip>
zYJZ#%jWO5vlNWy~X}#bQ<~Z{Y$<)+)t&&e&mk=%99u@CCS#h!KiXQJ6552)xzh_y)
zS2NcEp^eS_RrA+a-c$3pT0T<q&$9e;sX#3;NDO?<(tldc;;TQhpo$vA9}}pAT9JmY
z9%KHuhWX$l_+!p^?>%IwuV+4n<24_BbZiAg+58Xs=DqjUl$5M_?>(S?d<{GGw^vs=
zFT3E_(xpwSUcKP5KQ9PY4{U31-*#1S!2rfRtiROLW{4jj0qj_nbsej}V2c#AH6XA!
z!a^q_oPesZT*h$+Y8c3esVj90>v~v`XNi))bji{m_<bW-!NFHFz6V1fKo`b=?^pwZ
zE>ti9A@wl!MX+h$!5e@+?B<G4*clJNg?B;!gZL~qOWIswjr;TBHX-xz5x+{nC5Sn0
zz24@um(=DyXGZ$m$DUdu%n=q;#PhY;P0W|CC9dl;3-aPONM&NJv=DK>W%h|QQj$XV
zlKj@3l37*)kvdyp0Ta*W<r)k-(0Kv){;W4%3YfWEfwqb#`4g%pna7w9>&<rU8m~d1
zokZfCzkkOI(4s>AE7^JeIF!hGzog98p0mYO9WJojJVASfM_Vi}i8HTOF24L~QA1%t
zz0^6;(Yo}u(y}cC+Va52jzEr(Yu-i6WnSXp&<*Cd49r<}A^N+7m(5fP?FD9iz>=MN
zbYo0(({-DgQR#K(ZYi8s#G%S$g*gg!jbN(jk}b*OTl@uYZc@&h5AejY?Gs{x-U;4i
z7%_!;DjU2CCOd$Ibu0q_N!(+BHEK+zn3dwkK)n$qhd9v_55OfRZoh0qS$pTYi#LZY
zN@6eZa+nhFbE!s`Hu5sPX5qSZcgDKTmB+t!n^lKO`u-xdBXiH4XwIsDQp#oQT#I=w
z^Y-ZAhS*f~Qh{ndv#GrW`Bs=cGIZ7w=EW-;nNN#zKBx^`q@mMge}RtCH-Ja;N)`_>
zN?^F-4N41$fbon)mDF!a2FNqmlSaI0{;vdE3xA7a0UUM*{u<8UEx6*Q0)5~N=fEOz
zDhsS)0lwlLZewQ$Mr*cH2+$wjp<`<6BI6djBS=)`R)uOMe7#{wfuUU{o^Q2}Y5GbE
zS`Mt!jq0?r;(_2A+nIdS9P<Y%x{;9E8+LBU>5ZxFkEy&~RWT26u&kphM73mZ%Dz@f
zbK$G|3vFKBBz5NEXsD;Ow11UCK=Ic|%*7=xXIwv_FH!2qgR5L2E;IkET`gpt&s!eN
z*VE1`)~{Z*uzyHac@E0IMaDCnKW0^usK=_6OI23pdGL1=V$)@F#Tryf4(~C^I7XxW
z9Q*xbf4!HG{rS*YeFgkEHx#TKn}4;A3O5KP=E{NdcPwMdxKb>nuzmMC@<sZ5u!E~W
zZ^9aGs=3r4jByuJ%Ey%X#l#-Ojg=PCxG_Ob#l+507i;lg2NHtl04A)epZbM|>?aw?
zPQG})S5dPnn_zCZu^tBH=$u`&fKLkrl6iBc>Q*iik|k>U(&~8~{c<#?)1=wWEaGYu
z!fLLFFxxrKh6l&_0^x=Vv70V9p0$<VG2}V(xi@UgK`p;ATyeNU;1)P`J3QBT){R_*
z2%Brof>E2YK+NSSjGY6cve^x1w7|q&U2o-FpJUr;6L<wRi_Z25EaPXa>w534Wrj{@
z7R*17UqCG)Kgsg4>z}Vm;cW_4p}ri9uqizSm>PSAn<BMgw1h1md7%Dj49C1RrQ~A^
zm~Aj<6KGA`GAXv0X3h9sCK8ZZ1V)f8C)kyLL%pV7(>{MxpeV|<Htg^U<rb3MKc(`%
z+$ApKm9H)srf+JJI5@VVU~Y{u*C(9Q*j%^RVi_&1jOQ5P+kv~JUPpem!x3gg<({0f
za*w+rR1gRhpr>t<b@f%_XCD-<KeJ0DR7r#-o2m!8^9rhw`#pkEzhF}elo#1aCGmSp
zeqLly%C~83Hrp1lLQy^0Xwq9OYF*qeJUDxGS!Lxo=_wB8xQmP3ZZ{a95R-TOD^3R$
zf_@<%;MgYcl&AVJ@t8KZ^VF7v%BPtEoOysmIS@h&t)&e^5HU1r3ezwcrl}jhAG9jN
z@M;<=nMP%8a5lvZ2S~NG>ohIR>9AbLJSr)An|W<gH>Rs7FD>o8q+(*$t@nH|*T1--
z#>3^>z7dotgMnGIHXk-4Ycw`sum13!TbkyScO0~PeJ=QF?ZMq|_-JHYr$XUH8><5I
z7Z=LPWfzR(kW9T^as9S&h~?2QADQg2<gQ+l9ZJfo3ks_7UKWBs^ogg7IZIl7NYU0@
z)!CqHySO-y*eA9wU$|<lgC2&^WKnQUYhPb;V03WQAlOGb^LOXg28ui-Wr{hSm0~my
zEokhWS6q^-;tzT3*Yo89+1AdM1yzOp(Lzq{U~hg~dqGW2L4HjQL@0$}2CxK^q&Lty
zi2q&&TH?d7HX8PFu&oHaaOp6RU=cgu67Hs$0Lxgp80BF~G8mi45_*~(QuGcQ21@|&
z4sLxoDBzHS8H?-~$k6i%kYoEnQyJnEA=q)6eX|hO0%@=wC01PES6EtMu>{U=-+n4<
zcx#$!=nWQkL|WbwD>iU!H&m}Eo8P?ohH^)&EWg=L*tK5wN|}D`NO$)pt2WS1=Sq-}
zUex5v(H_6OjZ)>5FSxqDd_pP~h!-(i!zDVA9Br%{Zy!BiP={=m*?V5s2jp>CVS~)0
z69)X@IkQXS?UF`4p#q+D^IlU-t5zKoK-7s%qxRWszA_p75%xK|?rxgn>z0Z=1^Eeq
z@eGTlslVU9Okyv}$*Fhumls(0f(@jI`P=;<F|<$Iylc}us!AReD+h`wH(hUoK5JEF
z<sC?3QFpEzJ-DUPf0;(MjTtp_rU)8kJ-uRgQJJP>?wsDO`{_?E*3H%yDe4L;OjK3C
zq%Y=P+H%HumwPTi`=6<&3l-*ToOSuD7PZ;+CX?Q74~6VTBMj*Td^q0A`3KBZP!Ijr
zy;)ah-I&revOph)4HFS~JunO~VW!(153pl#1M|Uf&<f#9;0eya4JeiU7P(yjPni4{
zV}=I&qZCG`l%JGEE4CjiO{OOxj_H;47y|Nu46(5xdzkSCi?UHs3Rm$3=O5N6)3O}I
z&Vn{iwvE|w)>8uR{K4N|c>lyjl8_{?G#H~A;>a#S=-gK?6mM8XnpN&Q=eO$$1I*|h
z$Fp`^bvIGXldrvK_@cfmn6DmtbH26I)u2^=Tu=Hf7P~52^V^9VH{KnJwew;eo_B*-
zr$-z3lKeim%Nh#!JkK3#Fzb||hOo_vH0U)wr4WZrGI3*xG*}fWkk-$6py6=wT%M_<
zveXdoW?qHCF_GTQq|2Ty7bx;4cKOb^i0IhW=9t`){KQgTtS_(lcz5-$mX-2lJT+gX
z>e2kI5dwo`CWXT2CHKcask*8;$``G@%<SMQC=N;Km0J?!7Lky=RVESIoGdJvDRMr?
z3L`vj%DNM1`!_6YyVIhY6-z*;xY<ErbQHlE3q=6!33w71M8RqB!ZT?4)Gtec78uF|
zcmX>r3{zpqY`-*@6T;n+Fo!ar2^az?8kQ-!aKSpnfLsCEa39=a7@pIl4GIK^M+{Ug
z9Pu;!Qku3QNvPDUG7HJgSLZaTq%~^OEgHd7twq13)o-bFeY$9+WNro5gh1k1VvW2Q
zsnNIvYOy%`?(C?T>X#N@6Gsa|^VK9*SY~oXbae%_#r6h^v7ggh$_p5ZDM^7_?+C7~
zFYF)nc#7x7Xd7S6p~dRg6kfG^iO;Cl8dVOJ%x;q^MRH=RTw2t6-?lPZqRVU1nv@pi
z!`a%)CbhYrIaJQ7kdI%8%<nb^5p>IxH;KnCR@5ta8lJL68F%S*fnE7M=lUPX6M6Nv
z9CfZ&eRyu}kVWs8^yW7T%nkZ*c4xebZcufoV5-v>Wfrx}q9YZOB1gq`b7fuKn7=nS
zU#L3AJ+Hmm;3L}9F2xtcIWChrSm4s;E5(2YtR46T^(55;z1C~NgLwsu1=ubCfU`oB
z%eFj#BhC3)fUylP!#-LTasaXvH%@Eopckezz*Oh}aDxbb0?^5*)hR}eRcscL_$hRT
zv+|qe2XKv91dTIKl|!Q?BTF1Tp=@_H%)?e5Dy)nSpxvSP!t3UQvz@`hzDxS&qP)NF
zncU(Jhnr*O&e+@y(YZ)k>o8Q5mh~>03@^)X-rbh(o+#Tk5$@22Z|s^{+}-~fYPqJq
zvfH4PRySCR9w%40Ym>LV`t!kPMU&@DvS(v^AU0z0DAmrU0n226d5)v`*i9?uED2TC
zMrxXOgLd6i@#KPCF^f#0uz2ddYLi-JSiWcIz=iJz<6X-?lD)HFXI;<ovtBj4e?fg~
z?wpps$;$^WS*=hR+;VTE#;uH&)-)`9w2rxgSke(LqNGZd+EKZwmvWnm<~Ce5H{=IA
z3m6?(=fq=L-l4MS%d>i*KWYiYeQbo043}hGpLI({E<=QjBF%^~`&58-h+8;<$q)z$
z%SQGr)%+|_@Msns_KAUm;fTBHQdihyPXU&dsTop*G-y`w(uN^*R%yjjnx$h%9K#qq
z0?@k*4r&Zw{1TSVFsVBSck@wMo2=@{!Xmvp2epPnXPJF+-OtLG&_g9kM|f$I*d}c(
z<y)h~{I0liu~j?zERsfgij}rs=33`8T;vsq%11p$?>^oOl4WO<kedZ<0omA4jxyU<
zw4}6N&n!o3a3B=71WJYRS}74EM{@P%P*B+DjYyQU7`M(!+By6#l^~w4uOXUUsK3f!
zt<d@+=)=7olwTude*YOkTIHgE@Yl$)SLJZTxAA^no6A=cBU`&d`o1QJLh~7SS0FRL
z`hdTpug*nKWzRn|OIUMoW5_GY*#Of-bFwFi-?{2*k#m{0%0Q@`Wgpr&{+oGD-`ui7
zU2*8VhSop2%IoTvmozeGi#<xpvYK+Li14R|g4o4$CydC~2a!e`sHVpJ+N2ADm0ce(
zCES#q|0nW!7}xY$v;#vO+8rpB)rwesjJ<@ID1b!Dj7ZsO*v$?20A!6Jg;4^e@d-xm
z_Ta~1=!HllOgI26fbGSCyRc=1tQmzJEN6x+;4Iajk$w(PX61S&5u8E_{UEOtp#%6?
z83F7B<H=0j4a`K~Cgl(f4F&XIt$>YQO4W?RO$AHLWHV{zk26VEgw628`OGtxL$PUM
zTujF(vuMc*8aPXP0`M8s7Uxdl82<>7qLq|rW6Pa7g%EKlFnfc1K49fpc=E+_i*s$f
zY@R@c2<Y6N@`VGdgqzm=k~ptMo6ENr8hAlk1fx&~3jKb*a#WX{O;=DlYcT=AzkYSI
z!t2s>I=s0kAaX~1`T2A$w;hx>qe{}$TdD)jK<Cr4Ewss`$@k_K3XMUDmzE|Xw2Br8
zA&PydT1}YE?((^6PAsQ{RwB3C*&=g{MB2%2n=Idk^m;V}Yz70qUI>-r6v|4ckbo=l
ziDKv2xCU;?l!_Dd=EMv}O&_W;+Vpx7@pO*pxh5!aN59G|$c==~j#Q8Oo$EIlD}pN{
zPN=H1b)Cy)YlGTLsq?IP92j#F=#bg`_9EINq+#q<WN_tV@KWY)21!YPOQR*Lb!SL4
zxmK@<=jL)|7b*loo3tq)5(pG3KA#X37OU+d5lQovz8JnClXO=o6>@?rhPhNql_H@*
z+z=0u0xlBq+VaZz&MWoG9KTA$RZ|jAi5J=)f`xPPWPF}ksCPFj#9~Wf2kFu2JDR}K
z;?WStT*RxB*C?o)Nu^jMD{6uvJRzH3BqK;sZAdSY2&6npBo+pIwXLhi%X3Sme45m>
z2Vk5qNl4}tXbl#+IpnfyK<M*LVv*QeUZ~-bob38sAs7A-#cOl<EIc!((G)gGG#$-(
z`<O@hJS6&g&71iY0Yia<t|nS1C^k98Ht;e=`(PwJJ4RuM^wIBTEdpC>W!9N6W^q5*
zTq&)L<-#*uRVT0&{COF~O>+TEJ!$$*qbE4{GMHM9MRppA;VrmGlP0D_?5Xi^Aw~fv
zhy(Hl)($o`hjg=@)<8R8p}}uR1=_wEq;iTbNXRb)YyfV;XzJoH$q52`!ER*s{UAFo
z0JJh+!;rT@DYOf1j*!UV6*vXC=R0AnQ)z|U!Y|Nz%Ih>rWoMqKKqNUQ#5Hkqmg_{h
zA~iwGix@@QR&E_%wE2u(do}iIe!hh+5<A`IUaJ}%x6ZmL`&$XuIX2&Ei0PvAY)#FQ
zu6<5t;DAaoUga&4JE(KHF4A3^o2~XKYeHTDe=vvEsCpJxtv<u7&UH8=ifH#NWo=--
zZMT+=y9(N{1J7>$e^~nt@FuQoVc(fiw=G$gCCjp!tuD)Iwq(ned&3P^+#ANm24lb!
zQ%r9GLJfp8LJ1)R!ln^O*@R`25H`Ihn@u3S_iSDgz{7v;j6{IlytnWFp8ZLh8IA7T
zbMLA5o}$ys#G=SFb+Rz#BXOC-Lg_zodvoG!3X>}e&|4;yAKISS?6p|Zc|yT&h{H#)
zW`tZ6pZ;DT1Wj)Z{ZAKajTQ@|OXn`kmnK9@PpM`Kqt(Uh23z(%W;SJ9tQ2f`-0CM)
z(P~p&_5i({lWM$6n;NZ(ap^d5t?}#eUh}1=z^Cv`L<Q{P^aD<;h}Z-g+M$Studu{{
zQQ;|v53s)2sfSOD0pU|TwRoo44|b;EZaBw3VkVwRNd-Jot}rMVeu`xYtFM7<H-%I|
zd@BfbhTlR`Jf8w9iNG-BfPx4Y-2fbbLyR@hlMr_eIrxOnpd+A&P|S}&znhyEsEtnS
zZ_V#+Kt@M>wbMp6cICJBizQ8g;{Wcu=lqt2DpNokhf=mUt^WR_6zASPztu?_m726P
zjj|$66d70k*MO<2!Qw{_`TGSnTLFHd3i>s<n!QdRV{c=BLjTCLz_wPajiX;@o<WrS
z=e@eB$B1L`&&ga9lepp?=uoLtDwdZhHRvnoB|M|`X^MK{<<)^Xe#^4u>iIUG&jv60
zRXCC0tNxbL6m_zjxtWNCA7ZF*BRiqNrMP9R6XJFMcgX?HQShoRW3)g*#P~?SEQS6-
zfMMEJgycBZ4Dd0y*l<ZEOb$;Ck1$JP@i!2N9P5vbAO{k%{~<!t^SBg5C<511wi=36
z;;31TgoP6+h>eM)5~~Dt8>6EViVl?I>Z?uKoPrypTH~`su^@}GMF{dM=ifr#LN6X4
zN!901U+_bR!khc)CKUOjA!f_-i~gi^Cd#=5_aFOYuVnShbXwFcw|uvM_o`*vqEO~r
zV9xwfvQy=c-$K&STw*19H4N())NRx$@S)GfutJs$KvQPP0YpEOsR?5!hL&CV=gDIv
zq*)pxVG$T-)zC9yJA%56{$i79Jk7L;{$g_f&eqHoojdy{XV*52RV*k8W(OY`Yp6wv
z6~sE5Ed?paiXG$clox#(pO_f`X;C?0+HvFX2t*Ui*tN91yZ#RPe)=(bRDjl_Y@)ck
zed(t0@A~`yTwGLJ)=$KQ_Ib%lSVK2POl0fZ0I9`Zc6GtT0-71?>JIq_;2#tZ0Ko)W
z8#{?10t8DOYtRgYnAET)LZ-37xFpPS99ij<)WuST{>r&cI#2SXtQ_*Xwv1tJBu8l6
z=BmuLDqcv6;}cw^%~aq{BXiQ#3CVgfKQT$|%-Fz@Zlf=1G(3%ls>*RnGB2D5)uP0t
zS)LS+e!g`VK|oZ^qN3y?5!vWccsdMJq*!TB$(O{_u@CO2bNI!!^aNWq{Dx9S_FgQ~
zXvi)N<m-Ygw-`tFa^8o`En=`UwM=a&KkP$qfj#Iw;1$ir<v#-zT;GZ~7x5WXvi~LG
z5@fN0cw;=zthsN#!tBQ={Xd=K-!YO9^TNw7kZQ1pi7?*av4sqAu`rylBE_h(nCr17
z4@^S%N{DrZ`+=7o7?KKohOht8C!2KT_x}FTePMXQpW)x}LeIJOlgP5$Z1z5z-DY>%
z;BN{(GBVfj+adghvQpDiz5T13M;jZLTzBJ8X(6Jxx@e&;<*%nE>N%)5A@0^)=Iki5
zFflKE(f)Nw>cmu9fg75_G|9BFBmw@$m*T5LE<UCW`1<qsZ4h5Y>CDw~=I#-Ed<I{h
zgU^4(r$zX!@bVFL&~CSB;YHi+Ry}-PN=dQmQ|z{{;CQ@Jt4;PaSbC>5HrQJFlPpbz
z<*kiN-g)UhdVroH<Y}TEH4wl#A4>MsZ8#$pi^T0o83D0EB<3r8BC#z>6epPxEL%ef
zYZ8@G2{8g~9)Z`N;YH^|9|(k>vIdUO33xvJ1Dx8R19T6*RE96*z|n)yA36Tb4RBHe
zuiDTHY7or2^cZ)5n$6S@Q9|}LD|kO<!v5F<h-GO3+k7x$HpFDCVD>U@X6$q9_b&^3
zuL1VxJv_)xb<NC%F$*V&xDvy{*TeUR&%>YL>(_q%Pv8I1{o&tn2O`G{Vzt`X@q)-4
z&R9;)`PIY|gvkScXYkuFexsko?}PZQ3%}8`@cWd@Z|phx5?`R_;dkcV(B*$Jm;3R1
z=$6&^nECkvd_)CeV=p|VR#VxrvHt7}PmwR-tMK<JyjF%j@iFpUdoupOm6w_Cf4}tm
z5&kiLvA(RF1(5&71U|nIp%vaeFca9tfz@|0x4<0Q3mG&qv%sO(_)AFo3htc1${`>L
zD?$`VQ;@Qd9*R-M;8$|af}6INnKZJvcjyd@IU`l0y+y(WAD8Z~n^I7;Ix$-MZT4D0
zmy|0kE}0cQ1+0b~{av~|^pCR=OZw6^w*_pr0DhsOp@9^$3C;ghDpe=M=2>m$Q29!2
zN5`hIl$a&^=nHjpvE+jE)I^l9-B_X1c~QmBN7{cCYkq+G7eRhw%K}?op3R=054;)g
z@4icX558D>z~BlNX3PRHD6lUB{s9c!MqijSO4;2@<|;PFK_)Q{j1c*QZ)Mph7F2#8
z@qM8-T5nQ5e7`gP^L=`&7p+uFrf3rWmYtNAma9l?8C-eWp^^r3AoI*^Ggir!@%x_X
zJoS3;NOfXfyhNu_f~!Q=4TS54@&z{#5@Zy{F6^w^JA)S1xu&dJcVyu9`f0PM9lxxk
z6)TT@E|Mqi+>*5%eYxuVCT?>7WakazFW<0)J`;Tr=X0YM5S)lhIL9)~Db|mmr`YM0
z;Be?e0*RJF%>s$;1D;^~xL70L5fdaZHt1436#JoIjTG`KbMTn3IDn{?eX}exPCl?$
zQ#dep3CA~k{W7=%o&#wT$qcfL$;$@bz_5eqm$Pf0MnB*TnIS5s+n29*e0ZX_xO#lt
z@y5mzXl06%{=51w_1?^`uS-t3x|iX0F1^kvB*s{;SXQlP;>0l$`ur}Y@?aczokN1p
zG$-r48zW;M1TxJJ>l>WH4Wmz%mDI*0414aKy=Zg$E^08KexsyG$J-f~m{h$z%RM5`
zqHY>oiLxH;sF5qp22bncBV7+l)q4I&<_!AP_7YSX5E|p%YT8}bP`vY-B(6xWmK|W=
zy!1MMh}42U!{oFCNs7%ta2y6b1urtPBm!g->&2v^GxCQXeC4NCzxwWmr~*eCeVbA(
z<ZI0Z(u9OWBCF%L+<DUM+__*6T8-ut=kJ;}c0J8^1koNfrO2!iClDorZ>ZCV8<*#J
zeuQC$d8xRh0ayNJCgVCIusLQ!Y-sfdbV9#^ohjT6Vz;y7>u2b333_9bG1)n}-Kpk2
zCTp8Cw!Wd7;Pec>vSTdUd>d+SE1Ow8FiDfc)uri8iz-T|b~E#EhR7wSV7x&b2q@&>
zsy0r9{7^vS)aU$9kmo4<kZ}BGK8pXCtbgy2?vbYkpO>6@OosS+_z9jz>U&BW@(za~
zg8gi~6be%n$E<2&70&F9<Kn$;hN41z2KSu#&M&9FUp95lMEc2z_mt*znM{k@X5PM)
zcy1DXaYgUK`kK~`!txp23%Xz2?!I666e54?&vvU$wz}<<*_%82$&tt?&28xg^P4Nn
zc%&zzb)+O1A2T^2B^e;P8a^Y0OB$VstvI0o_&)!bk8%M<`o*KD0$}`s{#76IJBaM>
z>8+$5<^ghf8f6TH;MvDJMBq4z^;v);yky5>1*xY!WtmDBfA^A8T@4+lqAaQk>2e~G
zh>eet_s#DstVue$Um3%bCQoQs-8nT!--vpCaFz1R(Rz;b(02!r)8fK7K;p3_#pEo=
zeyYKq?9A?jju}G=zq2UFGea&iyjlWQt&SaeQrysbhTh*&GeCbg(6a9KhE}8Mc_L@|
zs!LXzh<+q7sqGOo@LbQpkG;h?d~|Yo5d<3V9I`~ChCdzOXe#)q%f#lVhUXLc06SEX
z!g7M)mse3Ebb-j{`u1*j7U;RVqY{&NqQ9nSei92~m(5*5tj!V_ly3F-%qZAI4dDuB
z2DJlXX;@fbj~u6l!1_PKht262q&OMzM}!Y<ax*rLJ~?4)T-<Emg09w-#FY6X=GbW|
ze=lj)bAjshmD{sD=qZAs_;gcpMrqNU>S?X0z2U_uBPD;gjb7739|gKE4$*x^T}{yq
zGPML8fdH53tyB=;O$2y(W(+SLZ8po05(3cJsgBW8!KX&!Cry8he&HF3d(%IX62-T2
z^~n6}l;{_h-162jk3MeoljuvLM(tJ_g_$%&<m0y2GW?Fo#uVar@C0TXiLJA$#}8wM
z;(y8i4E4jP{l5k>bXrfdj=q~7y#DCS1^)p%^eEeWZa$@o%bOINzj!;*+H?3nVU7&V
zlWWOEc$^USOU8_mOa<y<`6BjF1Dc1V#cS_e*{L_VlRw}ZBoebFE7os$yF9B<yjxE?
zrqNIRw!zgy%#SfqT2+E+_V|HWyY89cF)Varn;+x;RBCsq8Wvz5#*+}%`_d&$>L?O3
zV;Dl<Bd}#Ub>4=Lp+v!%JC3K?1iR(8)|5OP8M$rU&Zfd6r8Z*T&rf|`QoUe*Z!I-Y
zh*awn^X}LTRjN9sZYZd}6T26Np1F_Q1Ng4Pkiq`^WtNo=stzzQy!->o0hm{?-nWmw
z^x*x=R*v=DFu8qn<K~g}o~^xOFMj&bN1vjR`@fmL@ZPn{`^vqXJR*>t$MKX6tXT8a
z{ypE)`!CZ%AvFpbb%+*#3Rq&mK*IhKyci*f=?;MW--yDMbMJ3KQD4nyw(F7~9(?7C
z=G|`X|0oyl+p;`clj-(Yy2P(krif#dj>T2S|2r88b41rtPI5WO$W#^zJQ-MXgq1Tq
zU$BYE(l+ab1RP5T7C$2&e3bLZ?R$=7cS*D9(UrOc4tl0wF24ZP+@rEhs-A?(|I$<3
zS$vW><FC#yC^H+fJLFZh$M5iI_bs#)EfCgM4X({^wAu^J$<GzHZOUt|hYm2h$q8}`
z)@5+L5McFM1c_fyT-+5)%zm7=g654MBKBzs$pgmq-|1-%^Bd4Z&Xa!z`z9>sfdsEW
zD-g8I1SCV*3W!L-vfkt8ocB~rYVCe?_ifKlZ*W_`dG7Ts?alg``O`<Hsgh^{?Js^{
z+sWe{&2{8JOQ0y#V)3+Aw7qn(BYV1ZcU#E>AxY$*!$ytCP#405Z^@11Ag=qy>f@$l
zy&37T9OYpQ#H-nQsD6SaDeQBS8zG=Rp-(x!m`~KvrwU?t&&Jx7y$M7=fBat5mm%Rk
zC-chWDyg3MB|}LX^%8G?Owzb8B>|45ES^&}<ogiEeNFa$6v0SoNS=k)oiJ7TiSPX;
zlOMmpzk31w^4{)_pKqeij7?eomo=-1@7b^Xw2j^|ed>OQ0UldUulZog%G-u+0no4v
zqie~Z7##6IJU{qW!V@q)vnm3!;R<L14`PX%%@M>dZ2`4`;>~o!2=W$w;v;{ePn1_T
zG|o7F*Vv2{ea`9)ztKPRyVjjw+|{AoHtD*_!}oc8liUN6Ki60j+uU~go{AmIx`{#h
zoyex9r4@5#50t3}Htbx~zbJEYeN#nBa@|l#^{VDzL4#YpAh(lKnq#e*Tw;f;)(k%Y
zc@PQmz>KS>fJ7h|7R|~7=&{jkgq0~qC}@#i!NI-d$c$zV6?wX;n0^Y2hqSGuK`W28
zQ|Jv!pD4b8n}Ue1RP;qI7YXTViasyr>gg^lGvsUka_h8R$COWkodj}&8{9aQx$sA&
z%QHoC?A$`=56gG6L4IPs%VD%(>`?}qehib9KddGj$!z-0{%wUiQ^mZlQy<IE>$$69
zA=O(kX<ACVww(|x&FlRh-C3XAhWY~nBZz4F;C$>S0X&ye$ayRj-;YbTTw&T>8H;~q
zz3Gt8#P8heKa*ahGmKZ~!v}O^_=t@DPgQ$PXBYzygbqU3>c9BS|5E8^$9E<rV)Lit
zddq;A*pdQ!1HAWO#=&WTu@P|;AKo~Hy!JCa%}MlE^rj)Sq$sfXnDFJ8H6_LA>1l!Z
z(wtIyar%Xx74-ql5-egTuR<@y-?}j6Qbc)fZn`>En>Qg}L!0uoZa!Cu=hsJ#k|g(o
zkZr}-8*I|pkYY*7OhtiGJzbxexa5M=m{z1US-G33yXhw^Kk?jliL$w{Qwhkyw$%e|
zJ;$`gFtE!Klrir~Qm?q&hRjr)S*qup3nYu#CN$LDDBt=M+s;Ai9QO!QKNlQWFlWRq
zG1Q6~daRr}7ohh(v~keUQ|!_d=TG0d`vw&KP9ul#*igkJ!{SK|TF-<9mGv~;hhdEH
za;rH8SXYWb1k)$Hnve_@9=BSSlu}V|y=dt$Sca+V4%c!F^wXWAuU&j}qF6#r#B!6s
zzvqoW%yKkS>F(+ljGzgd!_DzVu4%50KCD=rS$gsHdUIwEd2ai_HO;ruv+6ItQ7_lA
zk7E1Eu|Z$KQZ{0*J$8c$M1TUxIkpSu=1L$jMukgbb!f@ViC%L1l$g3av)iI9nxMJ(
z7ObwY{pEhmv;pSQzqWF1v)r#PygyG2&6c~FW;1H&oD1iss__+<+HTjAt`>MupSV8H
z<Ox4$Guhv$smnKctjeM?%{X{E!8jv5X9{`r_i7SY5+^5xbsCn5u_aQbh{T>MlU|=b
z+(obJy5LJ{el}y)7DBzH)f|r&r^UpT<mZ=IOHvAUcDAmu)E>DV*L?7yDT39YD}l_y
z9Dr$;6`W!8FoeaW5qP9vwX}y`e{khr@3`Z5-`}>(eV~#jfwb^0RQl+<_uu!Id3U2?
zkw8VfC|0ih^YkfGrf0i1WZ5Nw;jgDn?w$5Fc!e;y7;z{60_9_BS#j|^Gg<~lMZic#
zRlCfaJ*>AKm_>+x;UdjxKXEsG*QTm!Z^i;+#&GAn(Jx20=5=n6A}a7`@jKM}RK$Av
z$JDl#JA)QS#mEVPGi!3=QeR2&P`rV(D1S7%32;DS=d**D2qP?mD3r^Z8z2VbF@fn6
z5}V)=NKXT?23-RS$+u?S2DRGwNqVZ)SKX}KG54-%$WylCR`S5ANfn~#_=LKAeX%}G
ztLh%#u&W9(Urx!4>(>DL#q!g4sg!t~%Y)~c82Ncw6aK>|;!cG7fO%F}3B%Wk*0u9D
zs#S(hGF(>w?|n(L_;&Za^x&H%^ADxX_f|{2)uok>ahm_7d)M!(4u-ntikFQG|F&Y5
zO6kZ=%&*XL_<Tjh1Rv<`fE$;7<gJFhU9d5PU_%7YjoHX(PRNINtH(e5Z2ahV^UKoW
zkSHeEm2ne#=|QxOIzImElQeHt=O$@MW;J@^9(06lYY8Wt<78@<NN}-etQkjO`<us5
zB!-HUP5bC`^wgD3Bz^NNN-EEuqtY3Yp1J1%Y90L(T}XdM|2<#x#EuV<WlwFn#FCN_
ztv<x`^DE9np|)XM8Eyo_6<XlLRS5JR&O@n*RZ4NNIKOHy{n5)ej5L=)6n7N52Sp#C
zW_5Q4W*C}>@+;|QKl=QkT}$Dz2Yt@;JK{6W-^r)LnsKrVcDh(@h4EF-cmOfz0o)`s
zl^!;@hx2!%)qZ>Sajq@V+^mz6^vmX(oL+<Zm%5erm?^3B4b7d0t7AKfZfADEF#W4W
zmTBu&c5YQ`J)0>mn&p(1NwrG)lqeAvKmdQx2z8F!7?SB%N%SjY0Irnu)Va<;UUgk|
zpp(w+EXZkX&&}?kbGmZ_ReeEsJwXH})#PQjwjU_y?#a!YF_Zowx4kM5oQx3`^Y=ed
z^C>%1aZQ5Ep_#%O9=7eN`4?@|NZtcdv8lJDa8BC-au$7&E+|18?`}b*3TvF$<i&W8
z`TPRz%g_#F5`t#0ZHaU31@6liMbk*nJY|%iBft3D@u#mkC41@L=)@BAz>XkDC6_X$
z{hD+9Ow7|LL6H0zXbsx}5qcfVopHw%_)HKqe@0IMTyxRQrELq31mmNJ&?jgO`i-!W
zg^l;or%|D=dA>P6ir+!E6A*<6;~#M&l}agrdL0o^zX3t~D~o6t4X{!R8U@3=aNH1n
z5-1o@-V5V5#C_rzBG|f1^_<e=HjPemCvjSpJV(AM2|+UO=J{}ec-%xEY@V9-El2tt
z)jU9SdUnj%xwK`u)FI}?aI8L8;m)BOm$fXn%d(GsZ(XL3dlbWp`!$35hBARJX~X@(
z`!PVJ1ZLqO=VWZ_u>WBdkDbMEU=HMC`^It8s=37-%GSSlPkB=Mx`ujdw->AZsig%=
z%EnvjDrUD9R88%e{K~@m_3c)(YlUo5<<m%D+Tup-ey^!$rT^5v=K4Z2`ffNsXmvMs
zmgK(HJGBC=58S^$Q3K=|#zq0{o9zPI0YB`AL$(Rb^GS-?D#p3wpySxA0K5E!zV<n1
z``bs(-fFt|RsgazC*|eHiNJp)bSETL((lR>lC!L?p~dLOnU%#4&zO*Z+BANTN+wZ|
z5hiOcoo!4qCTRT~3@%S6PE*5SPJdbRxy(}Wgh}zV!CnBo6Q@^hQb6Shz0xhnQZ{6{
zbvcVtVk6VDvTk<f5(%kYQwxknr&|fR^qVr{Q}vpp!h4bI+g(fFrw?sp@Xts-M6&ul
zJ0B1X%y=)cR-l4e5dbgYhjh7%o0_I97@jf3H&R?wwQ|)PT}=;+Ech`U<tQ8T^85O3
zU7qCQ3&hpsx6bWK+Pd-yuxL0iru$(1Eehs43)USfAdgd6f`yo$$&XDgu+Shjok`aU
z$Y{iYD{=@yN@o_jJ${@Wm{9|v9vGId7*!$YlF4`jj<z1ojHs$!zkgw5O2&jtoq~9_
zo<20>mc=Cqcs=<GZOEaVTbGhVl}2?E61h2;A7!WGITI4&q-gt18HM97$D0Jvyz17&
z0^Xx!r9}I1K-AteyFPn?v~A><sO#QCs*1dZebXvs$kbQcPMI4$sd<08VZdS1<wr?I
zQM=XPYuAuX^wte7;w)=l`v^U!fOr?{aR@Krx*25w;Gj5iPQiHmZPPpRvkTm@=qOU6
zV+lmHfRKWe$gxU<@mgkHo<&_G1-N(>|3qDbS?M)Bxf!*@+^m^B>A8JO+%fPjR7mQ8
z=SDJ83)@g3-4Ptj;RGljkVQ`F2D8$v=5F{soqM^Z3)wS0P9HQyKYB%*n2-NR{z`lZ
zUUV{6r^6}+G;^gX#vC)t1>~=@<`lbz>6<D&?vm<M+eCU@iF0U{vw)bsaE_~L)LmBQ
zc9d6no%z#7p|&Z*Zx3@0!8(2-><a>v(B*%RdvXQ46bu*x@|R&3%vKY0g%w{Rt%t0V
zrQViWS(aXq2%&cNs;arV!r{uyy!bRZ(Kavd@TF-t&xnnTN=ykR^re*56jr_`+_q-s
zM+cimRuNCc%uUU!Y=}+da)halMoX2fE7u#BY9_ApCPqqA@*d^K4mNEV3KrXv=^t-Q
zHC35i&MpRqYHBvM5n#{(3??(w)c~oBIVyx6Vxna@ER?jDn?*=Y&3^wm(aNaFJ9WWA
z|5)DfK1pEKp)SR7luIt9CG*ftx+r=d>Zcs;%$kBm>R4w}Tsr}2UdE?$<%EP5@I&MF
z1XV|V0`d+&lhH~qTSxeDtUUr|3B%s0y1VInGsd*a7}v(pAJRsW4EpEk2=7dj&Kgfh
zY%TU=BYESW=sODLD)bU^`;uR?r^uD#Uu8|#xCn!zJ_#Plz)5naP|Xo8h*E+|Upyd3
zKr74~v99Mt3ML~ni*-<CmEq!X;L`{L0X>2^BxdH!a2)3F3ORR*sibOw_d$z;Q0k(F
zb*(Gti_gV!WBh>})QX<DKQTR4p_;6Uo;qjc_!*LZbKwsKqc(}LbdsLnNdB>5y?0W=
zhdGLc6Lq9;QRiqcAsM9}93)aw)BEWMiD;obL1H1=drNbi^d{oFjz4>bU3H=~o>+H!
zY_YxDjN!uaw}m@MHsYGh7z0`S(m|3QKTZY%U~mWfGGdZHeR4$`eE{-pLdWht_et%t
zThJYDp8nl37d?H9BG95y+muCYdo!TDL6E$d&oOITAx4TbIN-s8A%H=VgK^L3VvIYC
z!hpDg1bvWhV%lDqB;qF{?w{4mMZN>-RF_mLxvOle9I6oqiElXsy%s+W^Ag=p0dtCX
zTl|aFDN%$n_pBCOmu9hMA#4X?*lI{2+09@H=$a&+9ULADKmr}Jq96D>b3_W$Iu1)b
z3b9zRrqE8tS(Gx3IO}0ao^hg0rYs`$!qTNQo#u4rEr^Rok!p3BNZ`ET#8}SSc+8@J
z&p*k1o_vL|lR)RhlJc^J#5@3CW<(|XIM!%F+~+@C{@x>_D_%vD_YPz@wOV0Hn_Fuw
za%L3BOzjqxXx6L5+vM}~_>#X*FaF|-_NtlY)6a?=is%(bjvSk_R-%zu^N$iI@bfP{
zL)B5QF?t0Uh8Qtp!QDONkAxK;X568g1TX9*8R8l+$pq=A>gXTKa$Sz{(>&EHiw1{%
zhD&E&U2f!PAD|zcUZF9#t7`o#cRqA|<I<<;G{d2-$Y7w1+SaV#U`g%+(;AW_QH01;
z`eWsoFfvYDC09bx6nY;0-A;CFKI45zo@8t(CLkFzWJa9*u9h)u4UZ7hWv0L32?D+y
zS_$&;J|wK-zK<U|=YQ9KOALoEaTH{0q~fJQl?_7YN~v;pm0UmETd=;NB696Rw!^l^
z2G(~=Z3^<FYL;SGS%9ZYFqeADHA-FO?1lc8D2YsvBnULSjhYl=(m=-+A2&I5d2*UG
zL>m#$@XrE&E(ajko`&8TP7Od{Jc9WIDq%VpI^!|5x56h^eT8r2pH02)rl$f8iS?ze
z#l1Cu$sA6b(KDx~aahEe#VIeSnOh<h2V}{mc_^kfsjJW+;ZJjNv+6wFR9T!xk!_Ai
zskw`iKDYTceWf)yeWSC@os#URQ%QIeD&6+pC{<-%A|%c3>s3MKhzU6{{G`6x{1l7V
zX3SK@N#-Y3V%R9am+$yaP8#IMvVqql&af8Zqbzm6m?yKVZ-Bh8?1oG@DYFlAFR7fv
zaEWy0jOAv(tBRN(GOUq-AE0&KOg~@Wu+pg<^z~W$GEb6<cOEXQwQIFDEmu5#&Pu<X
z*T>D)1-(i-ihjiS#OAVqJtfb^*JX?;Epg*_9$bG{W$X0`ttJQyNKPpUWZlnk+(tjw
z&@h&rkfYJIufOlc{Bny%Z8-m!^_9H-c7;8Te$-l{Ue-A=w=>Gb%b46BW7eUTn_4T>
z2^v>qO29y57}Aq*>L!M6U*(@9U&MPtO#MbYtMD=~%QnpH0+^ujvV0zpmcdVkoFL}(
zN{R+7;Ga}Frza$=dVqKQwE?<+ppm|>abaKJ^<%j`Xj#uK3-`5E^zN+5E!w)acP@Hd
z8ZahAixqB-jBnL^EZw^D__{Ku+bR_%$aB4gtJ}P`pip1Bw##FrPwB>V{RNN_T_K!a
z3;o8n+N;8IoP6*L>-d+R1M~SKAq-B^JRdAU{ihHi5Zc0XS3_0*+7~NW5uP!YdxZ$6
zl<z;s-Hz=44X|<#23Gr9Aqe{r#EIJ9<^6+QVR=8qZ_-75B2W6`fe;MUqLM3gf=dta
z<EhVJPsxL)72y>Sb~A%P){ruY)uj*v21-N*C=}1AQ*knWJbi)wh_1S$vwm<<ltCnt
zDzBfqaa!3;3;MjIC<Zpx%*p(mspvUW^3`w4cn(i$oQgV2e+apH7Sukg&d92<27`4f
zGBszkw2L0sKM|udsCDYcQ1|(lE+%*axpw(9hVCM6<o8iG!~WfLh{u3E21e?#%#cwp
znPnEhK$c@G7}){)Pgn9ElR5c!#`#C~?3Jhq$C&dt7`x%JiOcURQlvQg=LP0XN-PvF
z>?^Sr2DUD2ev5P-+&wYdpWD;5a@&k$X$iiZiM;_Yx$Y0m;h)Gk1v2o4?&p`PByo9n
zA@TXQSo8Q>PV)fyi?7nBD)(hVMZNY$Pu7Gi&*LsgzHOwXHQD)d>e8|s%LiBkIyU86
z16swow=gHSFtQ{kSE0Un1e?>=s7JA_dg(>}S<V`e?OEU*8Pc91ne^p<MpI`@du9k(
z4rK~U9XpC(c6))h$<56A9(=`t<V5fVqc+O<XLmPeEcj=ZB2p-j`ugP7_>vS^+EbjF
zBPU9aU%aH%+v96vqL&Z2F0P*)H4A~)Wq<#cQg@r!@S-*ef2W{-rk^`8D42u#2$!wR
zHQj)o+*`Yu{yaLUYpv7wWC#=D;vMy#Kc9=z+_?NjblPEc7~0ECXEx76*6&-}7OG`=
zw>xYO(<?vzV=4L*dczb{0GDE5zk?UgsfV>bEu&`vGVr)40+5DLc_B1{xf0fifezq5
ze8!89&5U=Y(C^V_c4a{Z)t`%t>kB82e=~jht_g)pxv@Rl-+u3kV@~}Y36y|OpQWE|
zQ4-RM@@9A7V#3Jm+rTx7i<;NGz`f#_;iogG_o!NC4}>5&P)C^&6S0ty73^Cd_1@Nd
z$DI|GQhidshqDkxKADv@S!Jhc>G^c|0W|c2TIA%=JtgiF$B{J_yLmHhHu3VQgUo&i
zK~j(-4ab~Dgj8vxFV@G)pLv#kou0OM{MVxN`|d|JMVUpMtPP@9C+>4o2kB48p9^-P
z*T&D76OSE3j?#powiCmjpufdJ`@9Gr-6lNAy%{{pvCmHm@YWiLm%>~GMh)a1YdeAr
zFt9iSOY68qDJ+HKVKobgD^LDd6ml3mV`a+KLQ;5=9v}aCO9iA`Q)x?5gMUZDLBJ>?
zYhHYsHc@<G3H{&})JLYRp?@yfQ9LP0PV667(GT4UnDriWEx*i|Ozgk-@|_zFR$*aj
z;OjwHmS$z$OSk{40Oej!Ul_lzajrsTNX_0`|Js+nA*Dlp;Sl|d3^D*#kNuoK>ZFK%
z^ez3Y0+rFm#XslIv-5~PdjFL|)SsMg&}_f*3M*FeI?~hpY^Vz?gjF28|IFYY3>69m
zd;hy3_~XIhXD|Jw?8abe(hTB>jEk=S3`Fw9xo;ONc8EAczlhde*~vfZHeRcte}HP1
zw*m%aLe|-8h=&Hgf+rc+CrmWcZQw6{X5zu~1~Up)tp)-E@gF8T=EgA9rOR^RK3FUx
zL5IMbm<j=pUdR>lYCWTs1Wz!nri-_k{>afqu9kj*{{GRLNLz*}O%fHow!7~_$)tNc
z!_@=wsZ;;)QE%^9dtimUwYKh0+>OV~HCZ+E;e(^ZYwz<X&##FVS8QCk)Y*6hxw3kv
zznUB*?C~$4ttTwC?`pjn4JE}%12e}<>+keVawy2|!KZlB23Pr#6lhXa{jJ2nJr(pu
zr5<^@H?+$b{_-;KEQ~{DL|#NOGX`Whssup895#X%+SFo*JEZ<X0VY_$VuwVHNEi^t
zr<e3FQ1i~xYgH2s?uK&dN`D(c|Jg@>zHQA8XNe<ApP1-qEm-^97oH}$WnUBDma9#3
ztn2K(HN#hKc$YqWXbJK1Spu-LfE(*A9)9slsm3*(ekS$14@xyDCFMoM<(->fv$i5@
z)%@7WuWH>q`fL5*a9KrhK|H-4O>NlLD`)x0rP-WcIbTC=I>zr7NEa)qSG}%UT;VX#
zVZ)6<0XSpKDLjYFF+=_TdL{?U^w;Qxy)~;^X7&sZ_l>smHf}sPH|MxsUcdR!L#So?
zwxBmypZ2K0JF#rev2=5Vb+~>w#~*M9J-*(u;p)s%N0P53t75e<%c^$=7u0oRbuXJ<
zSi7vhvJKMlBw1P&j@+T;tF?xVGM9#o<-4+z8b+hjYy8IicE2S#KC7U_k<pr^l?yzL
zB^Fr0!1{g{zZhUwK$VPA$jyPR^Ds^`OBk#z^T*p*xVUME2Clk4WEovGiY%5~ULk?;
z`2QYBzHRgTn~Nr`Ntk5Gj<RH?rtMH&dx6?KdUN5VHOlZEJI7D_pNu}$x4E`ZmZ&sE
zTJjVesKo1Ysukmluf8Z{F3yFEad4;T@|}rt`u+c_*@MXf-t+|Z2p97uX6ASl)(CkZ
zQSm=SsbR$iYk7>u!z#X)r;GJ)WX)*C@rRY1)FUlb_tNigm3cDnEPA@(j@L7n(0_e6
zdqP`VLql7OddBv{vsNwDMwhw!;#SUWjPgd!ub_X~wPw?iyLUGR$WNYFIeXf@^o!of
zEkShs^G(y%XD&H%0(n(QZgaZJ70mLd$GDn|)yDWTT@=Lp#@kaY{wz*f&!#n<4GU)O
z8^*F7>v3I#hq@TT%l|X1Botw!FlR#qH-k1IED2xW{0koa@8>(x9L9`9%wq670gsu&
z<em<}f;CdeP{FPVF}h_I!w)%A_)&p+3q(O@ul(`nWqpE#Tfm-K<#3c~x2p)EG%GUB
zP9`*=Rfp-j=sWIOLq(zkWMweewq+3oi*+nb9~PdcUV+`ZAnYsj!Q(?VJSZ%9Rr0b8
zi}RE*TCE35GahDq?0-l}Rxo0W<gr&7T4n8eaQ?mang$8auNl8|-|M%CP1<BfYY}~k
ziVCcJ08NnBp;wDG-ILA#?Qr@OO%BfnbpdRnaYmt2scRf0^_f*}*Ij7qw&PXysPyD2
zn=sLr8_cdsh@<yx-Fl+J7V9?TTccIM9Nw(zbn5vd<L^BF<>6ZIbKd^)?)}QN+T*mi
z1N~O9ZGU6&rnIRBgJC3<BNIpy$|^fI*ETP_*r4v|S<;n0N#+na+cQ#Avs~t~rl#4=
zo@%)%%G%-OR;FXy8RiIW0Y8nYSNMSfsX%>57?;a5gU1iEL?9KMZYaC}1*bq}aK@~s
z;X&d+;(<a_Tx)sxXx~^>XU9Olx0&yiD>se}-8<lMDFXILtp|z;s+w9A9*Dm+2qPy!
zt||!Qs7SOs9D@@c2&QEuM#-u8^gyCsuhF>+byGaOQgvRFASJ%LXvlU%%25mBA<H^L
zFZ4e}Nt|C`UquI1vl-ngG@UF_hbI?$%*-QWUWTMLlca;yORz{|#8<ixhp}SNF$ZUU
zf(0I&vm6ELkl}{m8iTv+9n5$D?078j81TA9cF4Y)92{$Iwk=GLomO>Uc4Ov*se1@f
zbZlj8+o~2$(L#Mr(AHWBHP457`+TPIm`4`>7|5#fD-B87lP3co29B>h`pM}xTg#^w
z2eLb?k=GB5p<Msl{v(A>FCtKMPO!%BF{s4Ri8k9rrz+3u6?8N;bx^wzNk+%7=;%m}
znq9wBZJcp8K?pWXzu2-hQ=cg>PKb@wwJcws;E#TI-q%4W3M&+8KSkxpYRIg*{h90L
zB^W07jk<Yx6|2q|)^(qJbv4wX(H0d=(y77Lnel}xiqCf?_S!WX?4Hli_piK7)JtK1
zdJKOYi!>3J$CMdaNY4$aq{5iPP7W+Nz-aO|sU(QVw`cL_pWohKo7P!WJ%577lhyS>
z(3&h(xau{rv58eVN?EL?^d>SLN)=K^_)Xri1W&r$x31hy|MlZ-w*DN)s#b#??Htmz
z)+}nMu5PHWuC6DytjB9Zmu}+Mb8=x_Z#Byk7`bhN2@Nk^!SV0A;GhCAW^r;D1MrM9
zFJmkbvT*=Jpa=FHZi4_W7Apvb7#Q{e1Chqk1|yR|+&~ry3_o^2d2}cJ5z*PBHPsg6
z5M_-#i`7ZwJCr6z*ZTP-dEBjz!`E;9Vp2x1E2C)o-Q|0b`M{6#SDV__Y^hC~G}>I8
zFP+w!lkOH#QCV~21X-$ttil+bJ3(iSo>rlY<8rw=zrtiswyr`=C1?>R?GSy}o`5lL
zYi^Wk(TXI!8!sO2jnnoP7OknPT<9)YUSD*Vsy6e^BOi><rQiL2k!OOtupqbPq|cKV
zUr~Vg1#-L8RzP1W@O2JGDn!vTeu;Ta&|Fo*QJEC8jEYzkn}J{@74JI+I3wgzup1}B
zSj%8-oguvNx_d}tVg`;KGv;d!z7bPS_&!X1%=#mI;-QCOgAdLK{Wq0*zPdFly+`K@
z%rh<BCUgawbDN4K^|y7#HN-i_H_-Q%S5Iuy=qL3lHMc<yYJ1aQ&Ek{<Nyb~PhOGuC
zDRaFhilSO`Gh_JzY23g9QKT}d+@o}gs!|_|jE7Q^arM4L9fups*Z5C}WV%wNNu0^V
zsev75<UR^(RXAEYBw4PshVcpt_tDR3$I_*bcU$N`Ct9j9s(*@#-iVr!V)Pek{g?Qw
zBdb&vM@GrxvylA4j8{W6^dR*dMKddPGKLXhW8tddV3|`aMEiu86Bzs;!C+rpPCe&}
zH<o75kvS<gZdXZrVY;@sgUHD2P*}C!*Bw*y1qMMzw%N37Cc1uf^t3kKMM*Th;z+HI
z-X&Ys?&KA^txb-Ewa3VTfx8>ghJDEI;PqEl<{8H=x9>p|<T=KANrX)_hbn=!|H+Uu
zCCq2pZsFNvj~I&aL)RJk5IXxG*8l%V@x}#N|DA#@nv=Tzrl&HQ{eqI-n!jZH`~89v
z*e|I2H~R$^aZ1ghU&gOhhps*U|K3p;RaGKwNd3K19UABUi=up4M~b+Ccb4L@yWRkE
zNG^qB5Q7kKj1?9vZkP>1R{n;$D6<$3Uol9-J3B#KJR{0~`-9%}{k8ce#OqBjtTejP
zOoV;%Gl_9-rOMDS(G(Y5=z-ckQL$;|-c;$tG)S0JB+(GbB5h~U*#5m<-$Zfb*G(_v
zN;T-q=6m9!lk7>$lFA!g1FFi>vdX%$>hx5HXVyvEB*>TMyYz@)kP3jtH3Vz83nG>R
zpWOiYWpBhB0Q(x@PJ`=Na#CzEeuI>ptVm@Lgk_u<Y(Q<y1u$$t{X8RHozBAbIT$Gm
zpL!p7t+8w)3jywvUgqrzS0%<_3G*BhmV~`NNL>r8T)`ZN9GPIPjHeI`x;Jtox0~Fz
zcinQkU{lwvy9M;~rca;vV6dVyC!;Pi)#sDDU4$kz&y{=P`UmK5kI>J5S>iC)3HImZ
zj5*Tcgg4*ThQ_#&^s_2AN=?5v88@++Y0N~wo>pc(fOz-uIrnlD2hvL4UCxbM&iy#8
z)Vlj#5qTd!;Q&f2yGUddOdTfv?zVdk9{NcX#IKU_=NI+ayxkL>c8%T_XX|lje2H<z
z%?BP>`O6sU8B9|DER4Nhh~CZXvZnjWWv~Iv{?s_KE3(Ixs-0&TLFKkI%SO1+n4@#A
z6Ddbfvn*=2oze5M1>H<8WtbO6fEf)&ypI)TvW#8>_=aae?=>>`B<R-jy)^~n^`Lg2
zq!-@XkmIN<(8ODuSt$WU%KF(zBIl4DC4sVZ)TELoLP8Q-T931}pr){1AlBQ|(J}Iv
zB!6M1Gs&c_%3%2&+9Jp&jx&4|a$bUBjzc~|+9gges*nrvm61jE$-g-UN(%~2YHn(v
zjQh!5{Uzu@gHmEPOmatS6zTy;#R4b>GUqx$Jz34R2U^Evmt0ISM%dkf_UcC;dhz_>
z8rO9@+%jS1`a@J5k}j&h`C;N|IYAn}kM7b+#Mp?`oOYX1ahnm}@eYzBkZ}OUD#YAa
zpM~GmLS~#eA$-LEghAjPTzcKyh4+6<)9aE;E6PWRvv*s9iZRYR=z;#3yM~rTS=*D7
z(|hmQG)kmY>`gIwGR{EWNo$dg;#eqgBvp_h6~EITUsk`hMB4+2^!c&c%DfP)5uXVb
zLflL$=D`f##cRKi>PN5pJ<qZNNC|wXblBk)Yc81H<bs9voW7@m*;6ODvr3cc59nfg
z0{z12{?f+9OKvu~7oI>1i7vD&!Ce^DYE>5&9zZGfrFA8FJq7sz)9%L>4&`X$QZqUv
zRkxnhT6~d>o<!@^CG7Y|d=q6RPqF*LSN93V1bT*JR2dp(2p{7Y1S>Pl4EhIs#aE!W
zEC&nsH_Ge|cHCnx>Mplrc$4UHaMGOkjX#Ed5u9n;pRy3%oagVA8l5uZOQ;Gp=w{|z
zKe}RvrLWv$4?xn29+WTQ2_maKRTfP_U^5DMhBIrjC#UDyk~hAe7Wf4zGrdqS$q*$G
z3Zo?|_uxrsnI$v7+a!sztv$*Wm08L?YD@EU2EQUci>x5uWi*;=#vH@P!7l%J4&XZs
zD7;vnhFMt%s6PTSvcetgyvLh0c>-+hVIVKib>9JyuhKt1n{O<wFVA(~X;Wq#vHOw=
zYBICeeTg>alwvriRC*vqK?qJhz*%k96tZv@6$g7#OBguQPPyop8aoz<G%p2}DR1}Q
zs)YP@*X0$`{~lBZ@9*S8G9o7C8?s8<5&HL-1+&EGZr}dig1gad`aHc0DzLnGy1%Sp
z(bAjDo&^|}+R-h`;sa#%sZ;b<=#gm*0?C~$0zm{n))lE!<mcQ`@K9r@jNwQjDuOL`
zMwkHt<01<zabfbh;tTTgbrp#&TRNX(F(h@@8+AZa5~-Hfubz<Tvio_=<vL?hQeqA-
zUQK<V6UDAR5+%?ia%3Xm!1S3(0x{?6Ym-*TB;Zo^cpRuxgn;Q=m{<O5&j`VP^rTR$
zD8fseCGX=6z+NZIQ&<DZ3^0b(UUp3iHgH%!HuAm_$k32lKDFl1ecHNoxudlqflLJF
z>el+23SOnAbZNVaS1VQ4_-F1t@TsYWC^snN%JO2DN#smL2`V(OB^si7SRB4YC6nFZ
zSbjXDpjoqvW$fs(SPRxYmE1F7W_wU1Giq&RpWk}2x>;&D`O$CJ7q+2?dYy)7K948n
z^K7LptLuC*P{2g2P7k!%$MADtPU#<bIg}HuanKvtO^j=vgmt=*suE6idv#YrH$bu=
zUJmr6Ef^VV(m_vlJsCIGY5U9jziiHPIWB&(q->|wFN!m2ttFq{aN5%CwSRvJ1%~Y{
zxQ{TjVm{xB`<NC>DAj3!c3WPMxO1*m0sZGj3;33zwly_g8KqR0Ht!6uV>JFT@hj{i
zLOcmZI-prL?*^uMhNyv_e|Hj+6TjLaC$MCDnZM|7uN4|n4yP229@h-c5-Ex_(x|vg
z5rKeK(XEk*wMo8LOzmQcfbpY&F&dx4T^unZA{~zrtNvcmKFmhwfeg!JgiL7h0;37j
zD`sm2dIb@=+{J?vI@fJ1nISEe4(6BeH{5j3#^;0H+=Beb-Lu!^{FpNmrwWSfBK6Vp
z{}rorF3C0An>PMKiC$rsOA|?hrLM)Qvj&%EB_+yal4<GYjHno`mWql#N2K2DZkM94
zogeWP?+`i6+9+5t5A_jiYCsu`!OV0ujLZynL1A*HstoT?JkOf`TDq)RzK+&b%$h#q
z@Q_w#u88fd8{E5Y`O*z@7NKF3bw5g|+F?O@4VT~$(NUZUsRQpPCny`@({fAJXGBY)
zW3-iJ4^-{78*iR;z|xw?@T>Q@A992dFoQ^j<sCyxNia4#R<*(Y<YDQ<vJ}0S$+*f^
z&|sJPxF6EL@KoaYf|wYAQwN2hzo9RdYK@uXK)fSr?)4sJfzxPkqz$3_O67!Zo=_Gm
zbZOED8!08aBaNdkO5jS-jSkxlc~kFzbXt+}NRdFui8`=v-zopdC|}KwMaK~zVj-}u
zvYSdFhazyW9ae&M?9AhS|31@HidmjNzW4o%jkdBD&(BXB78-@w=t&ii`Yce<D~(g}
zrAce*^9kJErR&MPkh@S9!dZq@LNZC15$uqJ6#%AC7ycyo>Lt0loXwqo>Go*(Mk!Bj
zKANoMa}d8NV}HY1d4IH2kv{(?l(8Q<%2fiVOsb1*qIvWkQ_>_PrtOG3c`}d<xbiaV
zt<NZrS37ZHtpq!w;|KC&N!i=RkA7P;vD6&Q?a59}ZP|1E<7d|@E^u7QAK#OmHMcY<
zb3GVsxZ#V!b&Ce$>T7E^j}A^Ak&x(w6m5-LK0`l|nd6rQY2+I?CX%HVmT~f+ei5GI
zFgv+y6Zt^jOOtVpS?ii6b(W0{(=`44-{~Le^A8K;QQMAi|7-m0ccWh(4dy)NtWuJP
z61l|cwzkRH1Ie}REvurX>WLlX=&{y+9^(-Zfx*m~TX2RPW1i1gW8ljhwoKVD8t6h2
zNPDnPn19$1KSQQetrLr5J)^r5<Z@}#Z`<8Zy3>Nf`r>BpD@vJGs5Yt7wvc^_{Mi>0
zRoVo7e3Vcaxla&C<8qv~Jh44W$nqqVEf^y6q5f+Kc8tr6eFQTMl?kz~iwD4Oz_cb9
z+PUzeA*&)Oi~jlMSG>=A={M>4e<rI+GW&@~-X(rT6Xy~7HR*O~l-i{AO_-ai5*Vb0
zB(8P0pMmo${)2#<fJ@9WDUZWEDMa1L3>86o4<0rQ_z$X8!`k1zw%O9{W@BAhC3@+e
zx%-hci-Yb=7ZAe=E4e)_tt=&3lb9K-aWBg-ZAhuzJr9Sq01fOB9w#H%xIN4{lG#dB
zm`)ij)|<p(mQpEZwN-e0X;$Z$hCWRn+d6zGurq)B2YTA98Wm@RH?$t{h;x!$$t?7=
z3RmqVBQ-tsDiN9NiB{LTClC~cpLgjd&K}N0#-|Nv4s$PzHLz%BGBW!=tda(h0XNg@
z;0{bQ@Q>4gTsBBUT!gb{D1YHV-;3*R`=y$GhyL~CYLxih%!-NKZ%aXWd+8~$DkgX7
zR!h~wuNQP*-_o_R+UK-%eYm8}uT!-SJiQ+Mxz3vIwAxH|jU~z8$j_UlH!ru4QCyNE
zrlhXjD{1f4<@sqUV_r;!)TqT_)-YZ+p^{wuJN{o80*gawq2~rYOn+$I1+EB{(zdhT
zUfllq*(3Kost_cYUx-XDUy9-(rCT8~KKkf~yL)p59$S<Ly(L#JMINVXB-)rDMmNRh
zOE2EsUQk$>#IYtb&wfa-j&y>bH-i%(oWK<@G=?x*a17BQ;VyWt>;e$sx|@p!8XD<=
zr$+a#TbEg|c*(rR{if6LiyII9B!ze?-+5G9S2y3P7Dfvt{hnwAkus`NtJkDEQYFf+
zfN$5<bmN#cdHa}7@6gyFA_F)mJ01^0pYp?ainD8CLSW`K)F&yF#A60Uu<q8CakU?e
zzetNpN~XoPG%xLXEcKih?fl6=tRaTb-_UO*8D+lU_IQQCHdJ2nFp{qE2H#<y6A@1p
zP>+KzKc+n<GX|gw9s-OejHvM#P00~d!ARe^{WX5{(YA??)0@x`x~-+l5JPW&t(7>B
zc2AqxJAwPnvzwO`_djb7T2o3C5&=De$2MXLe-D*`;Q&6y@=~B`)?L{MdB0gKWZwCE
z=r1qQkG9H`3Y~ZA5?Zw6*_(;y$^^&y_W0ydWl`#9dvBk@t)G6%wq;#rv#j1o$%w?1
zh3?HycH|6{Lbe;`c@K%skl#ZcU4Vxn0(fTVd9hS7OL`s!_(HPA872r=bY;*A4n$`L
zbHx)D(8Jlg=gpue&lq`{{_RI_YJRFQKXEOZf5)RJJ!^i6v~c6jJ!jFx&dysSZKdwz
zs5IE9a@;4+SXwp_)n+xvEA6rjr$8<#ANkUEyUR6kYp8E`@(mzc^tf+~9mUKf^a^hr
zFv1a3f5w&v=405ITDo=4qvP)5<2k!VC!KTujnw?D**dd0AI*Oy=*XX&o<EGX-@VAU
zCbgrP5>2WLJ>wqE>r_NU8#ABG0GJ_dR;a=yL+_X~FmB=uGBLL>3()MBc&P$(LOCO8
z!g2>Jzsvdsj1m|uudiQnL!LXp&#p&ihqo&;hlm!L6Cu}q8J9{=5Jw(gzisByRh`-E
zfXxw6jsBaa<(1EGZ&&2zaG}nVjZ#Qb;y48IxbN;8L>D&qwI^r;cBJafo1ly?^Xb*n
z(gH(8Y_!-hucN$SW5?orCyyr~Ww+<H1l+Ergd;89#TOeamPmn9s}r<>dk4m~fAa4q
zw=;2MVA0`y7Y47wP~f@+mydBOvHR%`deOy$G(W$*taaDqWe5A5DMnRyRgc+V^EnOv
z%+7ukM2%?H7%|7*d_!ql!99M9P4kOf;;U}=nA$h>2qrS?##m=K3cNmx-K!64uz*~l
z;bn}TEA(odkuyXM;a<Y<V|St}Gz+mE^j*Q~LT}#j$8!yqJyy@q-HBcOA{pmDQ8}nq
zwOAni#OF_xH>u;Ks(ANfhURFoKyoqrzgI?BJVF8CddSzp#8QF|!f+l&E(3bth;R%U
zbB?|I81{(!&tw_{h~&ccmm=<<Pya)FJo{MrE#J)6Sj&p&qyKf!_w-gl!AeA}+VT8T
z&Mnu~K6voX(@V>Xih`aA#PZGCkBK(csx9@$bJeOl7gz&I9#<esP0QT8URmAM($Zy5
z_P8t9{$1+luZGx%JdEei8NAJfSvC(MVa-fXDPAgK5dca^UaptUES2F~IS`qG`wisA
zUp=EIJNxe9{7LJ7K;_~o-SjLv7ZN;uE|r(e+Myd*ihO@RcKe)H4&VJY>P35J%`_-~
zrW4Tq&vRutSxQtS(Nkq{+Py<Fy04$Qcy7^9A!>igAAds*Jw70bkJCH2vcsEEsxLVq
z!K%$%eq%LHASmCTQLseU8z-n_@HSEeLC);nG=n>^ya#L|%&hRZ>JSH*#lNa4VHhw-
zBvx8P2UNz5CXR6Yvkgn=8FW5<n1y4fcIr~}Po%%lcqk_`V@~fh{>4vkdJ|3UBtQ42
zK~)!2AW8BS-i2=OZXF_;B<U#a^P1lQK<^EouJbvpm9;Z{cTR8}&0aA!Wy)Fwl)j7;
z$I>sQrDk9_E<FKo^j-xAo|el}<==yFt*oIGSHZDq2bMe#8u4-N`Tx4M?_))K7-4jK
zbEiQ;Z+f#Cd3F;Yhd~H#oP`Aw@0-7MHI81>|6xzl-%>)7YVWL80D#4-2o$*n{7xa7
z2<zck`!-$$1L&h{LIglBaK*uVo5U#?u7n~9Bqo^l@DFk(OdgSIWFz!Hf299P{{W%f
zVVHam-$g(3=;=!lal%B~SFs72`jco9dUL_DicJh)`x-k9Bz@QGt*HK<$8P!hYm|Iy
zPD7$j9;b_TqO(fX&0Vc6jb$Myn`$iX^gU52i8AzRjKUd1-};KkSM{tt+mcc$7YpuR
zrExVh_FALkV`Eh;-bHp$hwz#v4mN}m;6N3ZMI_)HbRDn|tKR@D<9mw(a3NSfL^~m+
z2$LP7PckNaWXF=eYWl75*S6BH(BJ)&p`*Brd%s(ZxcA<%Yy1;B2K?ub$s?sE1R)`b
zdiqP0bROxD_}l#azRcSF!=fZvOib>E)|TJqeYv;xIN$tYj>CvNd#83_a!Sdb+WjHY
ztr6IzZggB6n;1!-Y_BX`FgpKeY^+&jiRDwA*dO-n+3ugwieaShWAp*WuM+^dW-_nT
z4Pe$7j&YT4fUkx0AUvyhPDB3;u%a{5ati2a?~e4nzYkFKqffM%rp689pKlmBO}~5W
zJpFWIzHTL|8<~$1vgQ}Z7H%9v!IwaJy1l8(fan8nHrb1#5~7s*9=lSNc>KOip$Wb3
z7P&5ZX;~GjXO)UHJF8Tr2uJlnc2X5aeiX^IG&5QTrooh}-~~}nT)|4h_y|m#QNjLL
zCA!QV8O{PQhu|H|HGH*g`;FV^*>nyB?|mhe#de~~od@Tg-Zyi#-}<}KG@pKwQJNO)
zyFzK|-{h719ZFOv(Wh7M<GgV9W&LSNUM~I5PMV%7kt-CnhTy}?e-JD!t44KKs#CMS
z@|inz^%6l9q%e@v&k%!?uxiEN^3#G%5Fd)y97uC4hcx>sFBVWnKZp59Qt*s|O<%vY
zhkks+kG&Vhwe1!vujG7uM;dn<@#Iu=kl05X)aZH+eKzT0wAGBX4=AlBA}#BkNH+E+
zRVblWf`4pr=m~)Htc}GGc<5oUJC4&Cf!tx1`~5&Hc>Lg>Q8!%(9B*J99oU9KE|k!3
zKTL0oad|(^oUtbOL|kOX_>gL*gLu=J@GO1Xc;(*KY#I6psej5v(M4%NDm5MXVgvT%
zU*p~hxVUX9Z)FKdRE~eBMz8bAH%^nqCrSyPO!P=3#6BtJ6epdVDvL4hFa-1>brNZL
zT!=^ly+L1$|7)QPDzajIDPG8<+zh|QV|EQhjC_Y~bD+QfR`f7N84H`&CFEgfwn`lS
z_c1glWg^e`zC?iLZL9Wzi#4I^OD~(y)QuAs6{Y18t_<Y8KAK1$|45Bq;}(uxhGM_S
zq(|}<^>bJYTa}rOEo|fZl)9|~00=69zaiq_xyNfZ9nvo-3se!j1Lg+D)dSInyUh5!
zU=C&ut!VgIr!UOgq2M&|c19n@E8kbb4{RRHV)z}_ae(86bvLHo599!4Ss%L^NO^Uj
z%Q04VNaF-z@tfipuZ|Fp#4}DAA&)QQ?2}8spkJ~0OW)1k{`251Dr02zqR1BEP^ndL
z^V-gWgv1r}*5hB4(nlo$adfLv#<SG&I5Bya6c1lWoV=ZWjWe~V*Rco1?m$+lTNfyh
z6U2~M*IF1wJ+%<kZGpHE`qOXe+qVwfSnYpw`*q&VHO1@XIhxJVCh6=Y)L$##_zQ~p
z<*^g=-3L*^8Du;YEmcVxGwk;6sObDQQWQ5>B`EE;OQGZqRb@JAjVujHi>ZVp^<=)J
zKGLkx7{zi8PgN-tse|gIQHub|oFv7_Y`G?r%vF(@1cm1;CQD-VJJIFCPcF~4i%h$>
z|CJ|L#!;s|!h2viK31ApQ;)XKx@BS}o<Hn&aU(Aqa(CdWt#FC8+nD*gGKmMXD~?y6
z@E8M8F}nTL(M`PUJXcFa{?@sd1lpXY(dn)v&iIEWCy}JdnKU}xolK42HrO`z;-k$2
z-fuZ^UsKKfsK!;?YVcG#O*@BhI*)irUJQvmmbNa}X&supS|mUIy?Kcy{?UKiPfXbQ
z-?8S}9%9)KgaaLxGgZnjM`7`@=eAC}>r%w!PJZPC&xLR&Ip2(J&97>5=3m)SvU5^R
zQ0of!(qjns(&DV}B)6BodUZbqCKyjVnt6CUp`Yv;n*YD)E&htJ`#>YUIxmXA<RDhl
ze?4mW-a?<c+-G)RAzca#Glc6K43@l<Hk|$V{L5F2?<sXOim}Sq1+E@o$dsbfYPD9Y
z-QD{9<*qZiGi;*ksawHMWCBFwG-1Deu$8ar_J0D#6_}#G2A->tMs&TIF2Qkb7!G>x
z52inaajL;+%}YUH+~T1Fp79f{eco>=>Gz!0spo%d?)QGp<cAqVpBZ+}*acAPb?bw8
zu9ml~fL-7;Hc3nfbnlHr_!hAz_~7^25tHOGV#b5tnwM(g9|_ULrRxX;@w&0FDh9iW
z?7A>xbNRw0!>)253R$=R?i%DjpALR?r6sM=gN;u<^2aCCjx`l|agu}tl{r@&6<IJe
zJ{c~^V*dC7Y#%c;{0*$%9fEnQf>~qwimgUQa}4<!hECWd<1#U0o@3eoT4vOeP<#}_
zycv=)fu)I+EhrR(OS)neM5wG?OTYIzeXjeKb@vhnwjBIN;jl!MkRn1#5k%IB_kZ&4
z;d@#hSb2hnJg*(^)F>nYX+WRYmeVo!!mq14X5=-EOzt5vmeaqXtlYk7MD;-Dt!u`f
zxK1naG^>JwlmtZ-s)|aAS4!?5wCp&sB2~YsDKTEF&hq308|N<SSlyt?^mro23g+^N
zsYPMmjPX}_7KkGQpE<l6i1h-zUj#E1HUQ*2%f$T;zVXn@^rszvdP(`%k0|!7H_zR4
zRx!g+vbAk!W9p(C+^WEVIV(qNk57Q{1ldgO;90mIg#10iE0VZPh6CaSE1pI9*bnr#
zOhd|vdmno9*h@$S%~M|{hMKBOGL~*>pMjfa+q|E<iMx|s>r2+lvEXAX4S?_q(~Cmy
z;cn86??DfhIIL9qOM9o-%}LS329Z3usn4Y06FoZ4e#cY!S!HBQw9Sy(XUg(gFb?28
z|3Z0SKN-TTSt%TvN~|%nyb$`2xi{sZ-`Kpi_O7QB#njZrZ5vv$9B!$vt+bkR>~X8I
zaf(%9%CENP8_bz8`7r@+2A1(?2dN=z!4oSET89y4wWyHHX2yinG_0&_Hl<DQYCcU#
z$tkF<SNn?t4x;as`qJFyjDmuyhT_~RM(??k>xOkW$TiOJM(_b(+WQyp2H1LJhnwr3
zbMWO4Pd}GuD7)HS;o{A29liYyqm=wDdCIn#3zF#<Cv}d3CqlN;5%NT!|2egO0p2)<
z@j)#DCwVxWt4yymGjOoF6+UE#2WSFDETmch?}Br||6}ew0Nbk0#c`c`H7v`rt!-J7
zwfC|$z2qhDJ>%GMoOnCVB!djHAdEo5o+*S?AncI>rDX)dYAJ1@6iO-O6?m_YQc6o7
zl$OLdzwewY+42Y^egE-uBI)Yt+;5-neCM3+oa3MPFJ{m5z$f)DIxY8A6_%Se8G|<G
zdmr6D)DS8TWnQy9UV*si+y{{_S2l&-k{fED-pijDDz+JddB%bR2f8YXqo~a3$`glF
z6p5M8{k+TRLhvnETO=03wgspYH4U-t8i;^*`31~P4_$^QT+6F7p4oNV_fO_0XIUxp
zc4sL}tm+i<?9E{_(#)ApMRok&QcsaR%5Xj$=Fm>kpm6#V|F_ehdoR69Eiz4Sc9a(y
zcz-G=3{%Yq`wWFSPuO6`76U7@FVPa}j|4^t*DZ4VB<P#nqF_k|pPyB5*sY@Yd~xt_
z9`&}QE)=ekBZnXqt|WHzCG|Lk_l>avxP=gS3vW@6iv;}az|Aft1*h=_59^sbGvG$S
ztquj^^D~2o4b<DB%5aFq5~>ns*AkRYK1PXsA^MW5AT(P!FsyK9SQjCLt6&Ln!>}Mv
z9J<-W+%`)YA8ugElKk`d87Y)ecFezcmQ46EE16Ig*dweDLtpaFouL!P)&6Zt7a^W^
zE}`|Xb3XA2Zf+&S3$g-9v10blgqs9wk~*RRBJ}yJVZC!7<0Aemkm-Q!+YIiQOzE%_
zIXK}4>KjxyFnA>w`O_}F;Ep@@9Zd6Q@4f67Ki|Kb+3h!(3JOdnKlj<g>n11H9sc!o
zcieIP0aGA=?~^`<jDG{K1mH&iJ|2ObYnadufVo@PS!#R<od~GaQg)Xh>{rYI`XAYX
z?1DpHY`mi2%?9fB@uu**4>AujSKSPgJu;pG=H5kCZB_9lH*6f+cib6X+oz;5xvx><
z;YvAW=Y~VoCpK%P;>n+*_G74}S*R%zWFKM<Ghe;Fa<@w;C;cNFUnglbvnRXFrxv8~
z@6gX%o(<JvhJHPB=zq^o_F3@;HVnMIO!Q!eT$BFAbg_`Tg?HH4>O1tsf0^*-0lz@>
z#oYA&F8^mI3%u`~EX_M3i#o_uUc@pN@_r_F&PYCK-nse*`C$A0|3zMBC%Z%);U9tZ
z>)OQlwNYg@`C&8of3tG)KC(^!Y4_1q>xFc^fsxOZ%o)~n{w0q0%0FhzXH_R~9CnPp
zmG>dupC9*~5`56N5`tQ+7tsxR-U}Eq@sr1RT2hwG0MC@>h32~io;KzA6Mq-;#MX@_
z3F2|nty|PAyiBUYQIL(aT!%fB0$V~N&V>MHY2#@#_!-tsaMlZtFS2e{GZ&=b;=MHk
z))CAjbQ2zVqx>hy{?-^yf=fFL)r>l(|Gazpx!p(GEf-PMyMbH&A;){~#y<WHOB4TX
z@*EB?<~_N9ME={(>CbjeAKQJj(|jQn-vz4trikSnNacxu^Caw#Q;1CPJ}PJf`iu+k
zSQo||ix7R{gpkL}02#BGHffTW4yFg~_WVqw<2oELJ%`)6W5CnX5aVE6ivXX?CjV_A
zk1Mio(PO~rwoMx5%7qepAUoo)v$}Ky4GHm)7{5*65*SE4#)6%ZJjh<)B9NZJ;(w~i
zjK$AtKtMa+d+#@;AHVw^fiY{JxZPnFJkYmZWNkURd-~4~J@3Ph%inXb@gLao5#UV(
zoUvuedI|anTlmN1gOrCySlBamktoj&%LsU*7g^c?{&NHc-LRYYA0Nlweb1r$4LgR|
z$s6T<4En+m+uSGdWIaT#WPp$~>o^gbbj2WCCS4CQ#tXfi1vt=(ev2aAFz`rqeBA6T
z&r|&F;IXlYDALvQ>u!Hjx4WZ$%c{vkToI<kseAY2mF_Hod16gd(^{#V`sLm=nQ7UO
z;<>3=>k$d`+SL{9Td}@5o%H{}zDFWx@n&ent4PkA(7E!XuIa;6E_;kn2|4h`?n|Z8
z)lqxys)<8fF^CxcpS&CsIkt`^^6{JJ5~*2J-mw+J%NaVw;D_)m@~o!Mg3MW)pl>~6
z8lCzxArbrhPQhcaPis2#DM^;<jQ2DCJH!eeOY!(8{xWOLb*VPMN_RYx5$WnqwE_Bb
zCwOEKZ<6|?6+C|P>a4VEfpD%BB;?C|6xPu@*<DM(NO4e`=+P(At7leHkxr!&0#DdD
z{Y=f7+c)x{#I&(?6b+W1x6Y;B@|k<kXmV?+$AsEI08T_##VlgF_l($kZ|TuPgSE$(
z{!o4$vKLL}S=58-lE+ne&wF>~$seTJ{o))a?LKKw*!!?8^qDg>rw!~m6N6&aawhgf
z=u7b-bDb`I#zJ4DDL6nRyzH@f^%yvj`PDP&L|$>?M(*7cKTKB7brLx>zj~(l5P^&L
zEco$KsGAEt`I*<zIX=IUG`XzLXRbUG0rPH$mI2fK-Z#Hb5{{kUe8N-x3Mv&0!uneq
z$<!9GeLI-WB;z;iC<Za~<WL3-Xycu$GZ9`i2iw&M29NUs;pX}qn4g`y<W}pR4<5PZ
zvI{ls8ESq*++P$~GJx(Jy86v;URO3B^XIvm2T{AcwWQqAxT@{3OZTo{Ww-O~=k)dz
z_<r&%a{ATcPg)`>*CFihPQAfB&i#O;i_EA)w-1l*kj4V)W-4tY>ykT%F79znw4^xd
zJ@#v>n|tAXGgQ@APj>o{@#^WmBt@%ZT_VvyNy&BJZ|S=}WZ7}q-u06<8{f{{cIDj-
zuKwNhA)i|O-z;5t+^JMh2=a1aFANh|WbPL?XV?z_O~J&F4_Uqr*Fl_vrW6z&o2*~W
zOs-zm+GSgJ#m<H*`Hk5oPxs?q>6QLt6KLnu)xSbD!u0y}TV0;km4i$6)RqKdgSGvr
z#1`z@bl)p406M_E682pvg?+Z>;7(4F5>&X|JT_6kj#;+u{DI-P<Z8=(<LJt%t0z~X
zRRn%>$L_7cj>3bltQaPHcX7tke#{*pejD%oR|~6_aL*6(!@4=rO0$>X90Kg(JB*WE
zd524qzCUbnzTii8rUV8CV10y91|Vr;AnnI4+1NGJb*@~K^&@;4hfA~d!Az<m|KzgC
z8hJL~S3p1BU1py?(iQAjs#o2R@>9N_exkd~#(dBjhM#hnpF5`i*#B}zc0Yus)CT$I
zR%Llr9{YjH<mz6vC|g->pZ;oJMBn)c`(0ITyX%68zGJ|_JY0^JCfnEFa+~NEA#b`G
zXK>&OfQK~jIQq=2Cp+M(Qc7U>oLyz~Z6&x(w%R>fdG?A%sYjLTc%Y(SK&L4$WTf`}
zZF$*)jZ&{F*Zx3x!Jt-CR`jRrzPPu-{gC@vcZM@VndjAP*B7@nGXHr293`85X{dSb
zPbIDFPf6O>bL(K9Cx~|oOVkyXcrZ+o=LCi*#c@@_NE0y^9EAh(8xU&YDJo*Cu)$ni
zmPDCjwDEc>+Wpm681p|pchj}af#QpIZLKP*SXYnMP}_Tlr(d<zK3>?^-uer*!Imje
zh{NKFBA4ogd%kcR2bnk8u3o#!WN+BGYqKUcaZYRfn(4bDC3I!|qp`Q^f@4F(mN^ge
zz7M&q7WiUS01YstX~28(0Eu`+k~ks|IHb+Ozc7#YeWuvsDX(Sz@S3%A%-z?%w`#ja
zTeacW(oM*CyP-Dbqb4bd>T8wCtWlw<h7FhHT-<T(K;hJN7WY>L7j22%4kOffoQ_i^
z5&>QXWF>8av!KD!iGE=?6yqgR(=c=k{dgdRm^L8>l9&^e!QP*cSPCXh;#88_jB7cj
z86O13I|F9K?Edp)T_X%$i9~+ImeD)f`Wo9EOC#%<mtMH&G5XWpTW-4KrrY)~e;f4u
z$fwiUE<LyPQcAmDpk1wr**b61M%A`=EaDHcq_)64b=yw-^}EGGKd*3C6sqJAVa`G7
zhKhEW54dSXhgu_TXzR^em)CEU4PEr&?N42B#h#5?nYJW5+hx>FD0L!DF)a|}Tykgp
z!fd5G)OhE&3OUnRUg&ojVZ(`}ZRXKy`5}&h-3bi`8F-U+nT-fE8Tczz>{y<RJv<^B
z!~@*mP0j2K5cc)(4@MoqB8+rf^H5``_=01XJzCrX=Mv}xcB8waw#2YA*J`)B^S;XL
z^2)2OIwXBWk;Toe>{3^YHB@bX&zsaZ-BtU-B~!2c2zl?!u;n>&WOb#z%wu&bu{fJq
zah36$i1OGknvcA2nRKGX;#iwkKGfwW^M}wLp}%vVgE4-*{}*oK7hQ(~PGQme+~>-f
z^AFobbOkZvrR!J20w2rtzZTr0#F{(p;d*hFj4zc9l=v5XCvoaLI!LQS8b%^ew#KA5
zCp=b5%ox`s?sKUml%qX|ZPWi6(FJ0r1Xbl|_hCC#JWB(eIhQ8<-NEjibSv*T_kHk}
z`7kez_wInYoA{TQo*?Z4Q5;qt)EImaF@zS7Lya3n5^0vfPU+yJqA<Bfh-RC3^7VKm
zPpvLn({jku_kOlu`0nkt(nyQw(IrEjcCER=!>n+a#+Y4WOA8gsA+&X9oql4;pvHf2
zLys`D3hiX-x3<^CH!iOcW;UYT+}G5l(dhbOr&%PElxM14c}kT)L|F<euC0}8rp<zt
z8>#;38zxOz@w}40daW{DvE<GHi@7Mju@uCXiRTgVTtp|&2R4ufV=#CIgvb^6`qq|@
z`%za2w^Y}QQHB3xHEG|V5&PLpBW6&cw-;%h2)=fhSE`3|jx}V(D>(!Lqy;Ep#&XU#
zEX<j8>_8E_LWOsEZQPTcZ#EY?t4e(zq<%RSU$$!+IrPn)I=}HIYU*Hq;fk&3a&^9>
ztvFM^q<V7Z3N>dcFA;>K!feetwL*>K5Y99Fhw0xyUkPdg*(sP+Thi2UtQZWyRtw;{
ziR$snGXBHN70hL&+5$^XUU_R*_HUQH`8R)U^Dj#t9d8j`aQTZywa3{^7uuNLFmE}k
zd+M84w5@#n`2AGp=m3&_bpKnOlUJAL+o8F@d-44xt&krf=j?1JyEqYV%@To|3wBB(
z5igP(i7{8U2;STHTPP;$;)!mt(JFB_51&~mNLVrKR|LDo5~z@4o)QZ4uk+=a`t=>f
z#XIB01r@NtVy+Rsmat!`->cymlBoNEV}|K>OBNTy?Z}_W+j8^aedle>X%OY`DoS11
z8g$Zc6xd9L5Teo;v#iZ>!G>t{^wrX;yDfRfco%Of*KAN)oFR*u*5){ZmbqWQ`AxK0
zBwAXKf5}aS%;O-~hNhLRAlUm*#~3Tv$|F^+s)9A!H;t|^8hPd`>vxP?6LVWt7CkrJ
z$ozgNpmJLaVsx=tmG#rOQ);;s>H;5ZKr8q<p@SaIxsWeL_Cy4+rHY+xMpG1%(8F0p
zC%F6czi%~g)=(nG`3^<ha+(Ne=eCpx=)}^0yAh%~62a4Vs_v|UD{A!Y+qQR0e@y~1
zsMFIcsJl6P$UHtM5flW=-PnmfHa=pTYDnZGoh`6r>h5qu>$a^fs~^^Js3)6yTehS0
z5oL}wCop||WUQqLWjA>t-@_D9v?~J0eE#NG<o!BWCu=vD)nG#yXElA4^LEmgCVNp5
zm?tN}6`atM%o@N!8f?;XlzV4MNu|Vh{(rOv4zvj~kl>n9og9^H7j7NNn?BTIFo(82
zy%lEfmrWT1br~i7TbK{lHuhy&45K)00OO>U+!e5<9*;~yj5*UhLJNfh4ifdlHE^3C
z0xCKo1~#0+J^(v4?us3qv309<RD4s>^WtS&{^KVTlJ>?|2KlAVt40PJuBe)9j3M;u
zTe@RcJaXwZv{I%WjfO(`p-mmZc+R*Z&FR)=IeXK@4sStYQ11}&va}(qLT1X?y4xu4
zfP^152Pi|>#k~kx)*j9P_OqZA1RE`ojbyPdF!A7s*p4tuF%SntDtY0Q^hrpORA9$N
z7$U3?hlWBnyCfoz00f0x*i~EbE9Si=%wH}N^_b+l_FdcFcHOO;uaf?3Wcztb<0Y5s
z_8~p<`DcZGqqe5LjbW}?zNyc9pxkO+^UC8H`!y$n%feTE(wG}Y8w$!$V0aJL@sK+z
za*g&5WfnvlN4oo#TXRKr|NbrIrQO%GF1a)F0p|_(Z`5R(m#m22Qt%Mcn)+LZZqN5r
zmacy%+l=0dZk90rla+<U9;H7DJ9d(|9pu4#0rH`SI1`+8XDAWuz-L5aB{><aHi=eG
zBN;Ne4Kkz8Tt)_SQb<S|DBD)vv$b<se<NgICnRMvB_y@Fxxi+kL-CHnGZ&e|la$%R
z7o6X_x}&TlWR?cnhT9g3j=rn7C=f!q2BvR;3?Y8uPVny#<iVcj;goY3!8-%TAQtSq
zNg_Lz8rz0rv%y~=T;th@|5Qaou-*--e}sRB+ZuMMv->xF9_p{%xsrMRy`vs`$Y2!r
zUhqYvzjntc(*5%2wB8l<7K=U;{m32i<Z1Xv0$LScudX`M-Cj4o=9gOnI<+uYTlH{X
zciqT_SHAYw`OI38E^nXLY687O+|3=NCIvExyK%&Ys~}KHj6P9SafKu&bSE+{qY-Md
zHNKo*>KFA_wXPmmy`r)AKwUvuLAVy)BK-a(Wnsy#q3X(!ZG2C-YqYA!6IzxZwK+@i
z8;g@Z3^*qfyTdPnbH+V@8J!+?d(|Mn+?%<qvNZ)i@6eL+h-CMQc=;&c4|Oex1*8W%
z;)Qj$@STCB`GuGccw>FQ^bW!6(6;)awS}HN=APBhycABdjvUJYOdbD}7<HOSJQeV9
z&Y0kJOXl=Ha$naof6omyjP|*76cg0D(d)V4#<8WYJT4{D>rH(v$kh@%@x7KMp4WKU
zuOmT*B-qF7$j#uDZ4Bq_U3UK3mNh1Mo@@8O?#aegxn@nS+1%Fr=%JrEHVDfju+oR<
zteN^s;D#vKov5d{CryUOST}@C3KOe@Du!!Ya?v#Pl}>IsymX}2>#BUxZ$G?rCBAy<
zze>F&F1uC_?+)%o3d^yMa6$d}^6y&<k9CCb)m_NtYm5eCKC>+f$5*g4Xy^u*GjtM9
zpX|*O8WP?58B%}{6;QMoL3Bf2lA!qTq|&{iBVX4sA$M=>=^L+IQuU)hrc%}=2g-n+
zp_R*b_|+3F`l9~x3gqjDyT<Cr2k%B6UtJ_n%94ofdN0^mVAie^0-9}l7O|~W1FKgy
zE=|}KSa+&j4UNW&-J!lEv7q!ocf7FvX1*&3_GF*2Yuxr}s6T>TlPnwDbPy4MX@o;w
z1lQ5jcPn<BJfbEsIgbn$Dk-Tys`HAS(Z+OJx`Fut^QRm+GBE#bk|G`RxyFEgqRwFM
zd($OmK0;QDg83Vg6}(G7Rpt%_99<czVTF{^$kMh<iA}lb_q3(u2e{?BY|39Q4(AB&
zS|iTarmdEXpnJ{g&riDrO|UN{o|j|whg)A*cZx>?uv;gm%m5eR5GEdOB`RaWoFcS)
zyl!M=@sGOvEiXGAnjAy#9kr)8wX#~+d$PJ?v~K&_b2hIk^)+CvH1ZX7%i`tFYBnL0
zORtc3Y#EXJok-I=QrEY9xU!_1C>j##32pRm=<k6X18jCf(sz>RfY68OoTZNtob;sl
zCweBZA}fLD?;UF&uNxjJ`f+OrD0N2+mSB=ng;_KFD$qKz^80p$<>N>Y8xSE_5Vaoe
z9jfcAE_)8PY_mG_4!;G6&XZ^BCLit{u3Z*?Qpen1;&!n0rWp4pxov!xpn<FnC{9Y1
z1n1wjHUR999U){7_k>MJp)==-I+`jXTPNQZ5MScXqnNPXfqtGFX&UQu=%`;F=x-jG
zE^Y!ZLTA55H}!Hqca}Eix#D)y-u}I7T2`CnI`^*S;6tVykYJb_ivQ)%>zWZ2rMoey
ze=ogOPyuZfnNz|3V^+?r>0*(RriyjPGj*6ZPrPf568XB3j`6yoA^(J0qc9(9gIYQ~
z+`rwgoNUiim<M(<uSP+#7Hc#R^EL1VlH4sly`y!@s*5M(I=SialCfH!yJl=c<=)hz
zm#e#`?kw>*bp~&V(_TpATFCzh>N57zG1gB5xsV4dAzQ<;YhRMYl5R2feKX5@anA%i
zkibqHH~*t6r?zZ)y!FU!!h1(wa8#CiimqC-W!D2O_w>8+ME8yzcb3OICDXZ$UEWu?
z(wBMlOL*T52CX*c7YKHovGiL^!Ki02WV0aeRP!2hnWf)q4ix1adfK5Kc9@KZS$YM-
zKyMAFnVs##zF;Ppghg)OLAeToBQ~zWaR77^uu+rNW`+yF@Kvj~wDfb;nR>UkY-j7;
zw+WAo&2Y2n3E;-56PE4fsl{+YcuR3rsL4@P<|#UPQ+=2BC9d=pZetJcLtsN(GNCg`
zZ^%?LZ_MS-hWx9W)_B5V4V17*Z^)3S0~S*#iZG|6E{)@GqOShm(3XS0r@Kf@5oCAm
zgg7Q~2m<V9NPGp@G9NFp12;xSzp-tzhK-FSCC*^;ze$ioZ8aHfnun;;0R5oKVw3OV
z3YNv&JE{kTsd0zZhyx$qjY}#b63<eBCBW;UD|<2{8FoMA?&Y~d-Al?s(x*-F^7x_I
zMnkK%I*6^*@*ahHXoE~^w%s6&0XCS^#EN(=0v_qZZa5JvMtF}(m@7jb9}W{gct05?
zUieoC6Ss|{bHtfOCVMtc^cD)V@(hOQX{!r_*Zg8L8zWXe1To_1CPWLFmy==Q1>Rar
z<Mbc-55p*A73>%Qn+mh71v}^fGc}2D5rhfbdSbe9-ZUOZCRPm24OXDxxPVx6Vk;L|
zor<>sg*wWAID$Rh&aMfH^4s9B>gQyVV61mZ&_gp(@OUptLS?;6LLPc|Gfm~&cs#Ug
zXj${<$tQ&?1}y*asc>+RX~Le*Q)N~2l!XDE)20tpNaz*Son1A{b*>fhj?S6^N?H-r
z!!o&Wg*;6Q&hST*lXZ}BNMfl=xx@TVA@kOg<m@zZhe(w4W|P4bcX%c$w}p)caW5<G
z(V<OFPl>nK<t_2*G`vG>6t2ZlI4j|`t1Dx{2%Mr5DulgCNMDr8<>x|sR}2!ynay$m
zwgD{4L^RI!+!NlIc(G)2hX(*bwqO#fMeG7P5xG+4s$gI3u9eaC69sa2Ztgn|ANAP6
zHjTJ<{Dv`|ROQT7N7hC9YIlsG4dP4_ljRP3OENyoc*-60>a>DtshFAW>HsbrEf-0>
zH9qeJTcL{~&}b?LFM++8;$E+<85_<<M1kSt*ZB;3k=l5{Z2uz0{h2@jqu3;CC6y_-
z{tlKFi2P?WoUEATWAvs}KDLbxZNv&FAqvp)o@7avcyF5_e8nZ=B;h@EBSat3x*2_d
zFM)BB=MiojVI`9l)<Ck#z~cdMnF#E#$djUnx`0P7!ArA;PJ@cTw4sOlJoD#ComAmg
z=QcD1-M-pwFXMjObrX82eA$l&c{)?nS3LcJ!(HNy^@6!*fAN#wAIy^KYP`Nk2!tL8
zy|=w?c*ClTq*DFOSFfrUminUcX-_N|ZS<8+LJy9mwVU%LtR;rsxUBMo;Ur7~#wix3
ztDCtrysUQHi(tXSC~t_TGe><zOyevedp=~oUeaDS`YzyK_v+4iL8&)dJAEFDd5YLA
z#{D>T<kTrReHiQ*Rud)Vl+Y^3V_qai9XSSJ!uGWrLV>!Wm3KM|KMs?C3x@@D`PN&Y
zXVO17w5`_fi9g9)o)TMOT=!8Y!T*?X9tD}oAj-h@lwg*1=BJBNsFQxhT4Pn$c-@Y*
z=S<cOjt=Y$C?-1~I_cleyoMt_i@gwfICWpRw`ik%qc|+xTDPorWR=3bX-S@3(=mQ`
z3PG&zm>!|`z~0KF%^@^l5hSZ^f;4OvY$Z(?4E{>uS3$yBlKry?y(eF`wrg*JVgqzs
zSveKdkFM0mcKUNB+ja(26Ky($wSNawgXy)}3qwHf6Yed|Yh~`OP7fv;OV8(y8!Dz$
zu8pm$WbSjibn@Kpapt`_#1p&W@;HBj*?8ECXI7p`;*+1>#>9;Ev$4vI>64(F%L~dU
zHIbcu*;-w6w_ml+U%;w99H<`}k~Z!P$fnwGfT#^@H%R3ZZKiPVdDF1LJ#-jwtXS9X
z+K?Nblz}#at7Wb&ZfEZps}rxMTGl$HbZ@~O#f{p~giNA6r=uXZdxGhM4lL<NB=<Aj
zP95RD1ar}N7ChllS+A3@nS_Ix(ExR1yl!-*&tKz+BrJ6cw$OxW@UDP9OeES6Fdbex
z%=TMm!&K6i^iU`H{{z^-Mw9pw7C}0LNfS*<ZmxfeP$$RhmXGRVAeQkqquesEJ0t^}
z#d2G{ek19XkT>4bb$zv___z|Zi^JtrGS_Bp6uMH&Rt!~u2#UR+Y%BsolZ`$f`Xq_C
z2<vmck-|L?M}oG~kT@eD`uvId<zs`pL(0jVz*fCfIo@JcSo*gY$fvq?`K22TmDqCE
zowFr1;Fs1es~ZC?Zq!7^<Pz<McAZ?^Gp2BDY+kK!@6ea@fiwr97syHz7)a1gzsTi5
zyBKFrrN^`<8^olqNq(QvYD#5Ggm<$o<a}*&dE<2};3Syyg38I39VV%4l{&c9ub5~v
zNBVb$BvaXy=M^YcYa+Ntg6m*=v~1PG9;=ZbAbP+aqHPkaaI+>nrtqHA;aB%gN?jYJ
z<r7l(CQWFK)U`FQxDWc0%ZJNBGi=8u$s@N1;?_3k+syWCur`2rJ7EeKQU=)`IXH8+
zUk-7|+?Z8~TN`Q;#xGVhE$xWI!SvTtMw`}CoJolSe%?N*&8E$d%0<hn+ET|fLS%Ff
z#xw#_Z@<u%Pto1t;@0#Yp{0PLczbxR;1YJ^4u(01Et!DUJm}v-N1cono<WR_>0e|F
zkA&8_58}}Jp`4k}8io^BHq04LoJ>U3c0WYb@t*9Is2YfO1qV}yU`P(vxtuHLMu=KD
zGP5Lj#nPqdT=Z*fPcS|M{_YCML4x0+>~DXf-ot!Bk$UnB-d+-Zq2Yz#Y@Q#pPct42
z0m^ayM3unv60)vy!8$Gc6jc(U%VX{BrR8)et+M`{jrEmp^z=~owuJ+MaNCx)-rlz9
z*U_g5`=0(8HF@eFCky7Ei9Er;iSB1)#s(6g*=1d;rn&|PyQZc(mu(oTtsNVytsP<>
z9IGrTt{NMwEH17bs~sM$tsNNw?jjg2MCzHa&KL6NtT--*6<;|2CK!dh05(cbw9>3{
z5{S@2n#U6;V%dl%;47>7A1;cwL8Gw=1s)S(RxU;WFb8wUGc@QRjskm`M+NNupGp+A
zrqgkcK7pMi`HGk<LDZ8oU(<j_9;#S`$eQ69B56!5-+NkWVJ#A&wFTsbX^p{Z{_mhR
zmG}}kQSjTSr)nu8QdoTg<i`0=%#|=^CQT8;zY65BG%h;42sgDugd5BR;Ref|)@ZFl
zzQ>FZvtm&#;Q7DfoEJ`ApR5Zn95^t29KDsaJ@^fBv@-GPh$#5gq=i886|Oih5FuB>
zvJ0TPG(GLWfd&c$Dd77o)0+tpY-h*OB!QvBt2wL*C}FTOfFhXt6$3?+a5`$5q9T(P
z@|CglAHa5?Ad*aMYq9iUf<kK*aPuuZ3b+#pyh&Wxo{m$d1TGKW{W6ISTlGS0iy)^=
zL=lzZ1WQK~v``{}vLyX6Zh{t}0N8!u;K3PoSz2a@nh^lS8Q~0bOSq50xv!+}Xf&B^
zxLYnULvkwYl!_xir4_b#S$LOQ!h9_=n#47R+X_+kU<{;hDPRsU-^i;oD{SOm86WNi
z==wX5yO7aQ)e+Z{`ocfmLD^#PEgo_A)WZ}j#aYU^mimU<4VFvh0&u%HQ<K1#l;iX}
zvXvR0Z^Qk_WcQW&=ABnY`>xzLu>QS|<x^55eX@)H^wA2-(l?vp@#aV|{qjW@ufOfG
zrs`m9a{E=AzgOV3SPh$p$M;vt9BA5EU8wh8)Lx$Na^nGI#POecgZ4r0ERh5_8yql@
zU6}9y0cpsh&`3c?2_!_~4J;mGAWHk*{9<37bA@`Px+hvX)wo9Ic3Mjc^S0$JUwv+G
zFoZM%-PH8GQ*aPlrYFCvajHY*3AxN()y~1u*9&y`Xl3xr*V1dLKa(i$j1t_|ewEqb
zmseeLqx2D#Fg*uS*y@Fl!nV8<QrM`TD-D|pAy2L8o@1@86D?-vx$@X>hyN*DZ)h0L
zyOz3}dmYTZSRkfKM0qwChy-Pm!F=Ej44-_X@xUW+EhDoqIHeoDKs$Z+&6}z!UuYWs
zS!=XnZQD8R6^gX@$i*Wouj<&};Bx<5+#fU=t=)amit-|Kc+-uhaa8c}&99lAjYD3O
zux@GPnpNoi%0ql+RcKI?_h^3M*ydG42P2%jX~bPe&Nh}C7nmZAm{T_q>x!+25$obg
zZ@0y!Z=ilgj0<2;kn?jleIK_HIORhfGoq+Wi0J!HPM|Bg-ef*!rthXVJ5K(IDxZD<
z%L9S8yq4BdU*lXQHZxWRu7vH_lX*{e*av5BV#7?>1g&-1@?YWi$Lnj_uAzEuv5hxU
zySFqq9~PFURqL8g`13SK);Ta-UpB6Z-zdH2&pPXx=bCFam8-W~h`zh2oz%au#RE>f
zW1o#!6|`t@O|WC@f*qjAj#fCA2;{D$b_(>D#3C0cCAAV;HmZG~JR-7q1QKgnZ$1+1
z<jfPMhPX?;#{c)Uj7WEz*ddmo3!6=u-xElMyqwG&W;55ID-g1Lhd7s0%V~Cp2VhJ<
zLEVD-hK)dmhsKoD@?|S85N@%U?ez}-3flpoIDXkhm**nQ2BXpCZVZewU)=R`Pp%Kc
z!!gKt^e1$|O#UMtM)M&I5}X^JA;AAgKW&lwaPmTjGT#-+fP)tXyKM%uHOL;k(5B3H
z7mDES@@|{atS^Cc7tl>Qq3ps3m3cZic0o9G&T4$@0>1T-T+iMb+%3t?B=riNM+pf{
zVCT4XUPuufxo}z>^8f;mOfLP&sW;$!iP_zYahk>1F-gvm_%1G)C}!z_4548@n-9tp
zw-Rh(dt!1aA<(75_4#c0WU<VHh~b5}fm2U_PX>5o4+-Fqcm!gIU>*reIqlve%oliX
zkukEjh$pePNJ+4W&{{#?dTJQ2mj!DuF1B9wIkM~&%5qM9#;NA5!R@~aTHosGYB_H&
z*c!h7I=K(=F8&2auCG^D?<WPm*$ah;O+q;|m@LP`?Kgf6zVi<A$CQ!;-rRB|ejWsX
z@4N#T699PxZ#)4{1W~UH$LQgpWZo-2`^SCg7$bR>k&*w>=Mp@{sh5&GK~XvNF2tKa
zE42+^i$IGS_EZgU1gzX)LBZ^GGQOv_6<Vw%QKvne{KQ-V#q@xsxX22}IWgN37t=pU
zGQnm3m?9Gy#*>r_oq}TyzJ$E)OrlACCL}ZcxB2LZ><7_RC>Qo$!ThkT%woLcCV?eC
z>E<M~9f=Frr;2mxPHqmm2j+V7VYa>=GM-?4iy0axl6i(j1MQSK8pJ0afTv{b6YLdx
zO`Q0O-5Pd1_|p!~&W*y#C{AAsL)HU;f!$o$lok3vjoQwdL(3}V4e~60p4PxEc3A?q
zbQI-O3q+Y+zCggo7=8KqKHch}%U|?LhKip3*XT7`v84v_t?TM)&^@<rt#sTNuUM+d
zd6+BXxhq2!&!N)7M!B4c`h0$8L4ohpOFNsiR1Ect)LhN+o6|2~PH-h{&7cV2^AL9f
zx|bt>tZ5gFrbA{^l5ARlV>7k^isG&Eu+za+5{~UV6VA9Bd|t0FoTo_}UQtnW&QPbK
zZ%=Pw_~{+I^;u#@^({P^fo}A@dv*;k8NGHuwWGXr>5k(vUIr8UHeR5{GW)4tQC`?X
zsDxcHgVlr;K+nt%k+0aJ;6y?@ZJwE>Cjl3*OJY4Z3zCh$f&uDRKCP~xy4%G3^M6Xp
z`eOy*QD>G)Q`g_z^!YMG{qx-3ctJF1Dsty(EXypLzhv5cnwEx^pF?Y{Yeynx-L}V;
zRn=G>C2+b?cYTq~&Rl`6-*cqzfXQBA^zV!6s$;4M+A#eijjO%|>jQY0MD<Y5)!++_
zc!Zh<-9CjGb_9buABl#8ureixJJNQz$%h#sMMMzB8<)cLo93a?hcvCN#v`RijIFP6
zg;H;6Rr;@+YtC<`g_6k69BplmpOwCo*V>x*PP3(+_w2K2Pn7;xt^RSNv5feMqx1l^
z1^WphG9r3l`flbF1$U-n6d3_H#r}@{5cIySDYaJy<w;^~qQ+57z-$Z!%%<QV3xs(f
zU^YOAZw?Gu!cmhs5JZ2+V2_#uVS_Oe!u?;)siWM_06**Jz)#G_V4jDCd&N8~SA9FO
zIS46^5%_rlY@h5Q!&@*mk;)JKLYZLqw(GCowp&mp*}CuLm-lUDu7{8_5HK2pt=EhX
z4UJ#(`W3g_a>WG(m&;&qLTEP&U&OX*tTkdEVI}b%XfOzB!{Kd|s!0MvI}`9FGZ@hz
z05kw#7eVnliw?Iph+|^*BfL%$cFls>1iWAfEStr|hS$gzD_Sm`l4gn>G1&aD!fKja
z(Nt@&JBAEWy4aDQr}4Q+`^L(i22Vh=k7dpMjFo3XtgImrV<5QWfcs{88b(aOH^RIL
zMjd87p%v%q;eHkF$tdLL<_zZ3wcr2#TBOXl<DB39?i}V0wfKkCe^OOU<V;j3|5Wp&
zILElM@I~7#qocRjUMyUhgiomfeinw04PF8vDtID+L`kU~t(&XwJyNr|)zSFwZ<*`G
z!*->Nn=Mn>hcj<nbMk>T*q(W%yp5#o<RD|%$lLhM74W?j0x4*J=}!{B0l)ZH$xMkv
zDQ0Irt_jq2Gv!3HCFho&eF8rOe_+d~BIP;EK>`PUa^cf+Ah1A4+dl^ewEgp;EDmWt
zGy)L%Cd^Iq;Nf<19$lxW4?|r9G6tT@i398)HzyHEn89zkVSF|SXDXM#EM^?ql_tm=
z?t)y|Wt<f-3NXQ0%~=nt-L`Vh0~*X>GdQz(FNu+cTPk?j;e`^P^RE~CzSzCRp2x6x
z!T19;58zkr{ngyR#UFS8F44{89(8HrCwhD0qV|5cWD8RV;9l+hP_*{``|oFNIx_Re
z+sizA<Bji-|4h#fH@r=*ruV={^2^El*aC}wCnZT?rkgExBV-_DV;R#uAY&W_vJu<j
za-Jv8Gn3=#<U{u)WJ60+WK(;8g8jv%@LdvEoI_Z{@y!*})vyE@&+Fq%pb^d}oX85X
z9L_dL%qWu>1is)*2$JcO^mcd}2K)m!STd-fA{S&l0XOPpNQQF}WDx;PMis&WAFT6=
zz%U*=x+6r>>+hv<B^x>$qOo$1yL7dtG~h0GyB*iPI}qM)QtOKpQmLflL90eOT3LED
zRA$#Ji&m}n2ij_<F01oYEfbZs_mt`X+TF2U!}xg{(cly1qU~*w&IzZt*4t6#Ug^?0
z$E+`=e{}u%7d7wSv36<KxHC(>^6`J&_5)sb3vKFI+uaIj)W=WmZx2VAyF5`eBJS`O
zx6*>_v5NSvoI759c3n#o|DRvI&k@eZNddd4E`|K_HBgr>;~d}|WTi!>RIxmWOt3`$
z7c!JVyb3~!Kr#pR>JZqH0QQW8%G}auJQ%RJmuns7{Cu;WdFw2M{B_J9cUH8P2J(uT
z8^2TFd`-yWa<5S4`s<ChJf9{fM{`1PRyyD=t8l_bZbvMQR=>_tdlm`-pFgXUV$jJl
zIAeMW*7Bz4<lnSlthhzgxj+SY0Wa2)b#eQKsb*GrXKCoDXRZRL|20PuXdLT^$(~mM
z&|itxPC_Gimi1uz!v$L8$>wW<`I0E=n?-8~v!2yo+M`fYpe>%MD~&J~-Uhm1`-X|$
z3>%;X1BnxKAjp6YI|Lf6cY*EPXF7cB<PVf5gT*928>$tQhC#x>gXfRc_LSKiv1rB3
zN>$xXy=PNAzR9ECS*KFoToH{qY-K&QW9L6u-?A-MQB+h_vaO|lTKw2!kAZ;v7d+z(
z4BBEP4ozIBN20Y=wO=wTrw4g^r<bo}zO1cUi$r>1T;nK-*#-m7XD&EzU?iu1nR;}9
zsp9QLCkdMz-VC33znd6j=O?p=SdU3M*z6_lkisDscp3maDDcR3^1xwYX^>76cB4um
zVt(q^H~I7Od>%uKPp|X8UAW?n?aW_=pY`5UrhDuAMHzOHQ<UGhq^Ndy+v@$-zI*a}
zyp7!N>3wZ^UO)4Q(c7x``X|p>{rENA`}MbWU;RRVCvuM|lv+`xzp#F3%>`WzzotHA
z=}()XU%@dz^w0%$2z&qW(|I%*+egEM{u{h4aB9HpLvu}Cdv?6<oAp*FdwCoA_63H_
z)SQ)M(8H<ji1N>u6RYPrasuW3+uDXn&P5yz9;}$-{LkJfs^^L|k|L+q&)Qt3=>=kS
zrizLGHi&7q&g1?}8jJ|cjya)|4_8++&sSIffwwU+o<yq9V$VRNPD_ju8cqAAPg2}!
z=0f(N6Gm>?iR1j=VT~Z@edSQEqH5^3!W?MWr~sFsFouKFt4$1QYC@-)a*B(Qrx>TV
zLku^KUWD`It?&g-Bg9ot2N!ri!UkhRu*m@K5yntZLB=9V5PI?Qh(sd4q}P#?-Fpd~
zoD#XbH#^7C%S`t=L}IuVky!WlW{X9R-u+eyq{Gsj>zI3}qf{x3AQ;#TH(c8VFjfFP
zCva^L4X__DjSct}5j*=q9fhOS`&?PD45v6;>@mVyw0>KGOLOi&@EcWFncmYL`m3bB
zJw)HYsGYDz9NudxDx+_lUxVLpzsk$pgPx&&0{LxZgn(d{KtdhFZz|}&L0wHCMb8jy
z6ZzdTZ%{HZgDZiC4yk$`4Rj3HRLpq^9N^0_{A<uN^hTIJBqPNHz5=$y!rjApY!M7T
zO%lT_JE#z|;?&%dL_z<3h7pWI3H{oA)UViiUU2Y&83q(lIxJA2eZ{XQp}t;x4U`r}
zs7sT;jzpNp@3P$maCQN$pHlC$aNzU}LSq=~ASxknK20$HdNF`mmEiYCg!(h{b!2)g
zD#u^|&H!L|jh=)NIvZGxT@h6X$jc10z$+Xjub?8Dpp(FUZK4wXiaU$h50>7mI;j!W
z|772keH>o@^&9!0e?NPT5X-^z4aeojiL3{J{@3X5v3Qg8OXlGOlTFaW^7LAQrzGM8
z{v>xOHV5ep0n8KVZ5A)h$v>q-T675TTJaniBv;Jk)NGHc6i`7Fcrc702aaV}F<OIF
zZ!yB(lFUg%PLAGcFc|jdZ_;<BZCNeYwl1v){&lBq)SWL{Z<$QqK)TXW=2!3&t~>ds
z%*Y40C9DOLF%`)SLa<+qimflm*JU@bh}4>@@8w@ClVt?VjyjVQy-P6sMS?g0`bXNF
z<v96=6F*f$+0msq^D{XDM4WXZFeKqRakk(A@R*Q2t+;%AV?)*Lt6D4TVqQz}B)#+^
ziKer{Z5D+lD{Dvk&z(Br3pRPn0_HlC{hwpLwz2}UXFUaeW<O=8szHJ{n*~>W5F!{L
zAY_LSXIpw3H~|S@gq63jk{ULaE*kW#sw%l;g{P&onxIAfLLv7;?HhHWp^BQc=blR+
zTDpGa?OD%0&GiNv64()A|KWq^dFS(wgYED+hEsRa)#xbrplaB=X_Rvg>F2{(5Ie0&
z+NmhpTH%hGfCN<#VI`8&*hY*@hLZs#wyOu!g931~j~T&z8+ep-_GY&WituLF@2Mh?
zM$bmQ5xTmZFXv~MW$P(_o_j|%Y#s5r%O8tHG}=sEo;NcsFHN8mWR)26RC0~Y^2Kmv
zxj!`0wxlTP@^+4+gF=02x}<^e7g<djgWqbc%0Ac@cROm(!HmoFNTbNgw+MxiV9mKa
zMR`RjY_?E`__>r$m)%CwQZ$-pv>FXOZKj1eQqf~^#JVDZ`od<tIb7o}`z62En7uyT
zQXr8V^2{og<G+2~zFK#2enO6YR4$CL)IdBm#@Wc(38utGKIMoVY{OBU8P64iG_b*v
zspS8?Ag!knWZ$l`GHw~|P)emG*^*Gi8)c@?LXtlaYr5rzdM0gwBzwxXm1JlBI$a>*
ziey|02{T0xmITgHn9nQLXl0}FMT7}<$>Ws6yv_-*%UsS9&c&SDIQJ20vR26t&o@gR
zo+!sv#t!W?D_9UY)R)BlFl;)Ph`1CWeDVSt7vQ~^lEcR&{ZNS;crwo(Ltw-36$jXf
zt^|GzCaR(RHwnT4K_o2Uo5KOvnL~kh^@`$-9T+iG2JVRpuwe<ZIrOw&PmEX#XVsU>
zEnY<FZ4QdB&=l}BCW}a}3nE^YKvF2t+q_nb!{<e5YQC7cY^1KZ$Lsa#s{3jj<&-R2
zS|@9SQ-`y%LOr=!TYja-!Tidc_CT7sP2(_^t?==c)(j6lBGkvyC5`By=m6NdBn_3C
zV7{Li`;X=M7R|7RUb-C763GTlM(+S$BHXT^kThEo^!c1lYwoa|(%e-yv7|WP<Ey&z
z;!@Rr%T+3rEtHfBHftk+k7(LK(F$~4rrn>z^eQQY&>m7JKxM4XctTPKSe@Pf?KR;4
zDxF0mJmIdga&9^8fZ?Ok?CfB~Q^<V$|AEf-W#W2fGb3EBB;wR+m3d#uLkrZlocI5L
z+BV?Y7c9VfW8>nQL|hE<aG1o#iXc@p{g<XDO4bB%@l(acI7tYX?WAy7JQ{C?=o!jV
zHBHPuD2LLYdWyu(IL@v?>9~v)!!ssep<Ngf3ulPA3B5xdBl{6TrBMlNq(v3r_5xQk
z8c$LL(L2{1(A5Si>vCUqSW9fapI$lCj_!MSN!LA2XKQ<#{hE!%CW9P_c8_<!@HD2+
z1aR*}R){;{{5i7>90l9@;NbvLo1^H?2dmES35I&h;Bb-*9#`kLDG_J-CiF{JW5`oh
z24~N3^KCd62VhYgnCF5`tAuDFEXY4w2%X|E|Cj^bR1)usu*gI#GOGP#eJZlbzd0L&
z7_mmd^#kH0AJicI3XHFwA@0Sg8Dwty7HUkz@l-+N+m!Sj-+X;K+A6-7E1(%VpXMp?
z+PO26(Ly>G-oZiD(@e=3Q;uaEo}*Ci7ymkPCVb4uUaguVds@w(fccMqn<wC4zHuzd
zCas?S{TZ`qEmJzX6Sf3~Yo5_wEMZyvs(&sy6Rzu854%{C1GZ<>s#PTHel7DbdKG%(
zcpgn)7ucf^$46BH^r~;q9^c-*<ehmxc?I90uJkiEqxYaM3D5Az{1DXppdyIgyS?Ie
z`2R9~yB*^8LFP8}4%AMZ`(cN&iD4|L@^g~4p%u47KP(DEU#ckVw}#$X*V?)czk=;W
zg&iG*MeX(sWkrQTTu~ubmX|BV6?c>0*RE|XY;P+n>gY_9WmQyU$}1{lndSHs*DH#%
zj(G&V0-lM?pCUYNfak1UVeUmsOaB1BEoJ`m4}SoDX3KGKDYgXu9bl9Kum1#IDQNTH
zR}HcY&_9{#4=%an68L2=bM(_sN!^$&2c=}B2>zYWG5Z^VA%Tr7aRC%zPO>mQ{BR)*
z2`-WVv5*c#hj|3XGl5hf(6@m{SbBjD#1>(p%;Uu>LOi1i{qutl&=~XgOEk=0v^TJT
z7bt~`kY5+_0vQQ(*f^JtzbxPd=Ph7%pGnfu4R-Md&`SpNMA&{1)E_(Ef|O^(V-l?I
zj-Wr#0)8;u+8Pe>(@`(;0R`K{+KY?rW<C-WZE6b_7KYo<0|7@{somwWm!^S&IJ2<l
zLY@OG<!NjueazkHchI{O;8|^+z>a$`N|=g*5Ko{&zkA_@bK2X_2?^Sw(Kf;5cR%@L
z+r&gkL3w$>MSySi*_kJkPp~Bceg|_q`WWg#25teN76`()!3zVUH0k|;15x015q&(;
zG%(NvXOqG!m=D)?H;!dkO`A8HtQiF%<^;SoHiin=Tc8er9S7RKfYA&wmL=QKApJ04
zfeh-9AQdwEzgXTgUgFLlTDJ0<B314Fe%+>ho=qb)6$W$B@}`<)>J{Z~^@Wi1jAb|r
za~{N0D6<a}I*K8m>=kZ=t!uo*7#-B4&FEk?b5hQ2JlRX9o%|<(KU<cAOR}Y)2=1d+
zz<lcCkd=(<EIXg-29ofAKD^i-X_CLhKtJ4PcXD8d>FCERD*9uw@`<*|^{wOM?PF`(
zS4}@#S-G^L0{w^9T-u>E7k5G6a3Ql3UHH<ne2cYUxDWb{1<W7VdtX$AtGX)-Yp^V^
zeD9+!1o@Kenz{1D>w)k}Y8EebVJgO_0aK?AFx{Ji;qn>C3B7T%VFp<{UvDsEmYgBQ
zU6K@`7dirqC@+_*J@Nfn1t#=IV9(PZK%NV2R*3+F=mvC8cfzv<kh&Z;U?p4K+S%g`
zX9O?7IWl0qoqL>>0?W}&GqzReC{V9%X{km_u6yI4Y<ctMH$~I*jFkb72X^)KjU?=r
z;4$Nq*{m27R0){qVJC8ukzoQ6j_2&K_ZjrO;9rF9tainwN)Du=<>$%jey=gbnD?Xl
zzAioe*2U-UnwVM|sGYtk6@QCQTmI5LWu>93pS+FRT5E5v^FqD_SR2dtKcJlova6-P
zn<7jVjfp10P(>6W>*>e~2$r_Dcgxhdrn0fZi@Dv^HC8QRKFC;eqZBPlDUVvVyt8Zl
z<$)S+v;=nQTDNK>x}>42yuumE`1GfD4ozO0n*nrlS-N>&!rV+0GCG>hOqQ7P`PAdh
z4bFg*g0zk+G&NaT%uC~7$!=~-Ri#yjGR}-GK4+@^plx`+ueiDgv(^*{QM;!`VjYd0
z6&0>f#$Og^6WU&)AO3#GU%{tAcX0a7j#HLfq8~7zR9@#^pH_nfX`Pp9E3;KB=WWdA
zsHw8jrlrt8;T~>FWtAltr4JWf!0oQ7&eKx-gl^Z*SmDW8E974{*|Fcb;?hv0vLh*o
z;y{RAfB$2x-IZ0Yu=GEtRumJFIQ$u3t{N%oZtN_tFcm4jN@|{-em#+sL4yrIR3QK_
zC`9o<fXSjlo4EVvrDS4?Eq4HNHzcq=3g;;cR02Gk$_9FP)LV$^&);jB3{0B$?zKz=
zCZ~^3$Ed0c&Nojm>FDc83*4Qg<kNqd<k9S07Yp-3fSJH8<Atq4RLQ)8il+}yPoe4C
zR@}zRAceVvPPS}f&IgxP%s!EPifVzUPT?m9;7Q(`=S0wQih=gTlk=XQfp9nhfk1hX
z;0IsGsiNZOH$W@I_hCfE8F1>TmN|Jf;u1e}>ep19sv+$SDIu9DMM^$SN;2274}hOI
zH4f!}K*~e>i(%p?=01g=q)e$#CIJv1Yd&S?JbCIzIDS^8#Kcc}bvlnbFVAz8&g0SL
zxpBjH>cFYXQ6BhXoM)Eek3rqU>!7@Z3l1#ec)9x$?v_K%z)_MFZnOS22?$q^6c>x~
zSQi^8_!h^?-FF&y%AphZ{s9pW-Vr9%!>3}L?}U;rbO!wyI!@lIWy`xdztdfExGY`Z
zFY$^}vRhtC+cTfC`P8MliUpMZJC2b*G1Y#+j@@B=33i9z1*o-C!(|;!9jAAPJm6sy
z$^&0$f>mmTFqRMf@$cZ`?A+gs^#9jRkAGsa;}TcW)y*(@Hm;5{>+5(BAHp~j%?n5E
zVHyoGhyVQNO;m{CUl$l24y64e)j#2UwS?bDUC|&!Z+b{A(|MS~RA~AWwyJrABjn*(
zTnXPsLnfvWt;1bLrWndURVdsBC1=Y~#0zq0GdR+p+||ka5enV<dKxpImIUo0DyV{z
zQ!oE?WXCpUJrI8(^E+fcdNl1n@e{1S#Iy^*<Kd{2gAcL6Q!G&tB9H#f?eVxTo_)UC
z?RN9d5QZQjxls(mgvHkc6ifny%V$NHO2do<SsGMC8h^!4pPv*7(*Tb@!-@s^4!Ngb
zhiAG1@5UF!S;i`Mev2#>f)Ec6&?Vn-v_U44=Dgq2neWOoHL-vCJiWP-{8ekpWY!#{
zR68`KGHH!TTcnUxn{q3&B~5xwsZ?s?s?=J2OeSs2RaeQgYW2Dbd1f8BTcAmKs+e;>
zeK%gc9Tfo9R3cKZ7bl32sEXX**l5s~ETF5?n5+5l!)!`bcs6w90XIq=H^q*U+9op^
zu+Ke?{J~K20<pI9nm5VDYp3ENH>09L)Wzo&HTb;Fiog{2O>8r>wwQz=0GY#l2;Oc@
z1^GgGUUw)yRXZ-*)O=oBjL}jdbd_W(P~r6Y8j5(!=fV)eiY#cCXn_^xCc*4fG}@?U
zP6YBq!n@$X=iE0PxYx|%QS<Fv26MBJ?@p8W9b->qW&s~Ubf-*Z&50{=RdS_G6<4ZN
z%sOC1>d;%41-Rs$*GT}*@}hwLGDPMqJi84iUyv+}Xap{WXuPp75GZU66grJYXJLQ|
z0Bygpsw5JX^@T?j;`DT};!*Bz2~0MYVCz&C^pbON7DTdE2@<snA3(!OU5Flm32MU)
z_zeYjUv}AU>)LZSuV-keDfRd!{B>V)iD~OrVSvEr&%|PQ{6Nhyf?tN&<oOuLVjZGa
zYXT>Y4q{;I@Y^S|h<=H`zrFyQ6z&Q+fDzW^ow^U*k3u-}0Q^2sj^|xL<cZlZG6hNI
zwb;2>FavbIT#@H;ae2!NX^|x0p<9Jql~JzkG*_rR!G=%uxjMI3i9S)e^W6gBry4nb
zjlwdDS4`mglMVRR13nlYU}?wL*v=R<ECfH`z->%o4Ns!`hSrx@G?}U<TO`|75^39I
z&$F9l`bk@f*cS9xPkq*CGsp!+()3KBD$wF{wdo@+w?f#U5M>FJfhrda86t>)?n93P
zZWxzGumGH#ox&o;9AnnmY5N&-!`wc~{L#`7&NE1;g0-4hR!&*E9;pgzvoh5JcY~%h
zJIf_8z*yc_G?((px!iq`h}8QrB@)WHnSEjKTo5n4e<};T0eH>O<48!^E&v|MiNjI6
zG!`UGz5qfpTMjos10VwEvcFN&Fl5QGyVZAP2lffL3Uj73tKCwe$`5Xt%5m7J>a@Ik
zpW~U4CH?Y^xh7bMjxJWH_^ajC5xc!z?@NEvux=$Qd(buYDbUd{Lj~)xFtRN6WQl~n
z0eL1I_=iQZhy`F0u_q&QoYbdOtlO;Cb&2(6gD9RI@KABFOrtU=k-;kW6Z4R2)TT~z
zBWy!CEGaCW>a`lub-4vJ_k5YsnEL~t!eTJKobM9xU$$w~a*d0cob;!dPAF7d+*9zZ
zsxucfcoXw4^gd$9x^}RA;+!xwZiEkk$6f|Y4UT=ni-dtr^nTQwk;YZpBZ{1=vgHR>
zhHVmo%-k21X)CG@jG(82PTk!~%TJiMs|y?Uph~6XU1F!DoDb=GG!0P#$BUqsAx3ol
z$uH@Q>3gZAAMVxe4Gav-FNb(xD9Xd-sHM~Q(ivz77YppgeFGEZy!;48DoKuym2{cO
zFoggFiHRkXS2)jy4aTG3cNOSIhMY=WVeW=y;kE)_KrL%%Fp6w0S7^C2@DHUs+O&Fm
zzRT76QLv^8PN_)0D(DHIp89YgXsPrHHnKX$cpn42cyyGF)bYT`EJ}h7JqBpHqDeGH
zaZlUs=Be$lieA9%O+crzmk#w~m=tF<*wK6FS1`W8_MBO0wz*ydzLNW(18gs_>4P9*
zX7f-nulPU<Y+!gCs2s6HVKYh?BO<jQPq0(($(6*>3`S^?G~lLMVcES(uhe!}Dpj6<
z-p$-^<W@8ac?D*<JO?4EFW|Fj^t^h$T3|KPW!VyKzS{|3EHgey>B)De^I4x{9dSC{
z=_WpUU!xGz+7&d{Z+FX;mh7x|D3y_i!r>}c)+XrSaRST<`awAJ0~WE7c?THWz}zJk
z?&F9fIiJT4II|UcHqDlPa6{kF>Yko~Voy<A0V}fXHSVsl4Sg%t^z<yBxo0uL&7!`I
z4e@wG%+p+A*SLbKyXJh?<gCViEJ+V|mjpe;IV(w$VNwgYYU4JWr4IX8_#NT^xT&Nc
z9P4r$Ep|;_z9L@aDIVzQSv}OZVeZZ4Jw0ny^lhl?TAibDY3wD<o){)=W8eH6U=x_8
zYd}Vy<G6^WiA_g3jhJAHCl9tiSWHl3=LV|cb-}rk8r>SGx-^u$my}f3vmZqwp;TFQ
zKlgEDRpJH~7NHCB6*F)QN$4WY2^okaA|cYjHi*T7+X8H%ASgDj#PUPWEL6gLtvrdf
zIakAk#)T>-vg$u|H|G=dImF}~+>(d!xqXld0_yq1ZmiX)%sIw#Z6o?KtnlqL7~m1`
zd-t3=ih7U;$3<2-an^pk;b|5MV~y&O67{6@iKQ9B%QDi_)5jmjmrrHIGK3RZX}d%j
zTUNi3m39OWCSlzRuplO~;yO4FQZP`C(7gmg3NZHaY5<c2hd(hq$p5;U^GoUo&ccNp
zV>}^Y3oC!QrOG#iuGw+P>gLUkn;qM6xl^^A&j2rsKR`SWNuyAbIPfsApi+L;;+Dyk
znKFY|D3%7zx{l%_u1F;Av0L&*tFvlhMw`HB<s3xo@fZwVrGGFGI7%7G{mZFxgm-rW
zo-k0>-V-`y{S1~AETb*&dfq85DRD~b(w&x^Y*C}vT@Y?xdV|)u@?q-|XO)7VDbG<t
zj8@Rp8LPVAkidHrnnWs`l}h3}Vn=NKf{KnS9d-v$ztE(uye^RM_Sac;CZ|TNGRU(=
zb96F!xwE9Op`o}!rZg9H`fawGA=(Gfto+bRXbqO1Re)h(d7zhMHLcOhhlYn<Nk8|F
z)f)(p9q1*9oS@unjEP=?BDJJ!`G$L-XaeS`7f>}C#ql?fofsmgX`<@tmcG?l@gJ0n
zYdbm`N3+^v+abV&oCVH>R4X-v$HriWgsjzrEN95Upjy8QycGz%h3u4{>G|+O^!wLd
zODPZVad{fAs*p(%r7a(_rO^m;82z5P2;n3Pf&(=G4j5y!VjM=)5cmq&FNAqF_?_lB
zs1DBCv=gFrEslC+xRvCC>aeAhCs%Sq%V;*~P?S9q;_YmqODmU@@DN`tOmk_a+3q@u
zYpO;rns1`M%z`$+B`UP=R2ga6Sz4FSQH@MoF3oj7G|0G6`>8vrC&)Me$z72c2aB1L
z#b_I9f9WMO1~fD0q0&<w)bltF5Fs-iRYe~ePaiKRE~cJjE=D`j-+mj*n_?!>!BeBu
zevmimX#m*?r$Y95W1ULmmc|gCbPF{Wcnt<Geo^V{jm8lB-OIviIyK4_fPWypiv%o)
z3?z97ris9_rot=ry1b<Yg|0#j5B(Iw^VO!I<4jpvt*<zHcsRQlVB_(9)2T<eJ0Ndd
zz}Wy9>U*(AWJ4yrUIgS!UIIRt3%&%ONW37}H1UdH-Oz8s1ygJvKY}|VP?0fBIBr+L
zHhl^b&ycV182(DmTf>uFq@Li7yCLY0aCejxmK3gc`l{Pad&ORdtxhTC$z5wadCv}8
zZ2Xpz2BS;hP(wQ&o*3BBTi@c(>+m|1d4_%7v3RUeCZP?s>Ri{hY`fFX-O=!B+P&Kj
z4m&DKe9T`I9=c3cQc~1hS5(ozd?>F1S)>8OCEC(;g@)}aQFTKO-|DOJbvT2L{Fr-n
zeMO|CJ1?+1D{Sq^9Tk~38%)C@I9N58*H~QZ&n@dLEwHEUi*0w=<^5By4mY^guX$J7
zm?iT-JS0AKl*)#^B$nf~j8+m2%r-8z#AQODBr3wDkw_OzM6Aj7hKMp@Ibi&W5M%ZV
z&%@%IRJKi%S)8rd;?VfB)w=w6Wl*D%Msl2671C&Sd8wj2UAfbxhBhrX->p$Q3iMKG
zxNNg5vshK~9|nuX@Q}uxugsQ*G`8)Ubl9RGA}^9^cDQrGSqho2y38w8OY+sOE$XbI
ztXzv#ttiUSY%Pmq%G7~MgBh0YllqK!)Ys@A*dHOIT>z^bqN*VEHS_UM|MVyO_I`?Z
zhYuUxe3LE9F;K5jKVkQBp7EIEg4oTxD?F}3LU|&Xc~`jIAh%#gq1P(mTnL!NFUoLd
zn79?NTFK2VPq(J~XhT`LBi&0!MQ)K3-d!R?8XbdMex8xKteJ1-!I6VOp-I@7=}mW~
zm-8#cu10<&&6HLp&KG$^<zk)4+aqXz2AA;4$)nz)UgxxchLe>e8R3RQ(0QAqQ{1p&
zuZ6RA=O__2E}D0TdMnf1%*_|%30gBv-6~6l8)&NM7g*DCe8LuiPiPc2K}Kzr*q3HV
zYZjE|Ri!)A-TV?D(QZ-UcR?iGp6(J0#7bVN$S1P!W5BWvzc~d(@b1DfyC0?%zM!Pw
z-+>`mZ4a#s<j9Z)k$k}|&KH)+wpD#rO=V+qO-0aOS>M~*-dKnHx@e)Uqq?o5%6jpI
zdhp&mI3J;VsLYgA%FqVz*#z{tdstvsHM4^Sx<@AI3-n23iH|z5GvE~88gVX*h|!AK
z`|z_<9ErfM5wSSp#PSzFt9Kpxk{TfXb#~=Bn<<^BFR7ju@;bhoo-Z#R9K0C60+Wr6
zllZ0m77DkqWiK9Ni%u4N3&j-VJL>6L?v+3<jJwXR8iMI~NNc2P1Jmt+0QG19KK0Qk
z%8SyMp7>WY48CJs!LwBE>7J!>1I*4q09^?4b30G-EQ-y?8x9Hp?;_7epTJlt$iw;`
z<YDEKxhR}{5>?qDU*)~$pMQQe{M`ee_yW_1bGDLYNl8))mzaUW&4Tta9oiRw1FcpP
z)R90Z3+o6s^Tgke%!NmuNj`x=9ti+UQZfOTx(>=HfyOzrS1<>e=rb!JpGrktx5rr~
zv^=)y2s{k)Sj{ap%ol(O^<4MHB{^&s!8ZIGH}n48ef^`;mtispPYL*^gT4sl(*Xr3
zf{X|}HH=iicvH%pN(#ZaxlEZTqY3>rPMnWG$e%x7_A8+ER~Kz%lMxs(%f_5}vz9uN
zhA{m!D_o-289L643hKIVqu@-iV;c#8o<^xRah#6#l^qQPa;YDZ`@7-(+LZgd(O=2^
zkKn#A<^D&=j_;#d&M3MY-^cr60UT7j;@j?XUgErnHsKgkhVu!7FRln&jVgCN0uW4`
z%Me426CVOi7+GbpnD0nLMTj{tGI9XF0?8!8t6_e^jkd9O4~(#xh3i`3CbrR3_@{-w
z2-F1t39UY$^*GG6=OlLS!v2ii(tz}y!Q0s-Wk?_)yB$EF+8^jYkGus2Yib7Ht{EIe
z+XnUvmoFFYA4q=IO$nKU!l_MYvv8`eZYn|Z4?!jZcD)@N58_@aD;SbrjUzh<<4_6a
zerL@vW`DTG5^cu(H%HMnxczoD7F4w*f<+Z!{REZ=h7BzaZZj8w_`?Ojez6FgRSCV}
zmWy-<aKwp&Q__e*B!Fd_LXZVR#X?PzW2rvC>c<E490wl)y*L=^O%*8Qih?{Nut<uP
z=MPIeS$TGrTD-BC_ZE=nFN#y8S#0s7F$dE;p`<W@X^OLo!|E-uelgJsMU^Tz_7ED}
zRMiokCBRz<I-<Fx)-ZguIn859U`^-_aHu&sr~_(;5AU`Ko&~~nfl7hjLBx39T4>lI
z;D)3?nA?Om9EYo-BsN##Lrqoiv^$<AapqdIZf;QJE~d2UcBfalB-fK`ujU4F#@gee
zjEhuR=_)7U+p3_bS!vWdGScJ)Dn~?b%CI>KY>Mt&uT^EM5ep;{)i6)Hq*|(&f@hSt
z{&#S0qa?7m5A^l1?#a?nl>}={fo+MBtlGMD6@IPR+~3_kxOvTUdOdB>>zV5fvN5Rv
zWJv>zDy|1$2muPNulQ+pc`JcPZ1Vq*_8x#yRoVY|?kh8sKFMU#%S<N8r1xafNPtvA
zLP=-|9TG}H2@pc>y@ntlMF9atr3j)@1O+R)qSzH(?8;ge{JQQc$z1;D-1pwhB!J-W
zFAhw3@1Ao$r{4Q+F|jt;w?h1+=H^NEcAF<zze^oZD}BYyfJZQmVPPFFg@utugMnJO
zd>#7+Z58HKI;Amwr4bg^zO<B<&rq0_cuuVvHfv&PzY(<q2GrJ80n>-97rn#iXW!~{
z-}+!%AUmwhL)oRiv5jla%f<~|&HtfLN351~#tJ24WSLwN-AT<O`YFQfWiog#Q<^~j
zp~-g{R_JXun$kNHYlnYV!G?B6)Kl@}@7PpWn9iW<(1?S=0A^_GRxoQzC;16#uQNw>
zO-OAz@`i0okay;?Jzr7)>Xoh*e1TV-mkIU(bHy!Yc)_ep8{dL&!}f;k#_bKeY?zV%
zJ=m~48eZ)W*uX;@`CV+2Z3MmA)`I<=om;VO;;fd56I*6Yv~x+jE2!9@U}j<UlaP`0
zsTvD3F#Z4-P6P)#;BOl()!2CNH?6tWUs4mfB7Vxini-QDT3Q<D>VYJdGk4UAL#!$E
z5cf)FeK{Xzd;{cmUS)kb5Xpo=Cg<Y{kF;R&^qPU4s5P|AY_PEoTI@tq2uGDln2WD4
zdV01mt&Mk?BC`;D2Gmv8;wv`VcB`T8_@(5!k{dg6fOgbg$ZS-%%$wPl;uq>0zyq%A
zmT<Ju>x`%RMx2DFLIq)+JfH^cs%4@A>l}#!|5;~n(I%GI><dOvZ1!cNX7??-ok^tZ
zK4vpF>mf$R=4}K<Prl>!i$Rc?@dWxP>_=sUv)GG+A24X(qx0qVPb(Zea#W)F(t1(%
z?l#UNOy`kCK3UT+XKvl#31@<O#Lt``D25v*ZC^sIFl>N+*K{k7JE979ih>!Kkm*>L
z7{?X;bZI=!Z_wi43q*LGG@yr;fs;o0Ozwz5oSrnJB)_G1#=!oD<o`4K8Ohigrh+k(
zjwJW!|4aXxC&gC{xedeTT=<$J*5@|%n>U+&GfQU{)Z7y<R&9Cs>7}i{!8c!Bx7E5A
z4*dk;AY%<zB;3LnhP@Yg*RV9MD1(kBd+?P}bCCpJCBYZrdcmoQ=u|xgockv2UIiM)
zdDiyb67VyDkE)*O=@Zl2CuU>_52oLID<ea6YM)4Sd}_zrGiLCqGiG$W&8Jf5vu9;K
zNEqiKWMMA~u*O5t5pR6?avsfnd(WIYV$_r={cGzdkDkmoOseiXb!=nf*ztqwYe!GU
zG3TaRFL5e<In+@&wu*~u@YXaKPXu5&)e61FV5zP4b(^r>H#sRxEd1$r(W~l_;N3Nv
z=Kt$p_dmvIgub{Vya+1R>Lf)Y_MDfN(;U=fY+faXk6PI~D^gQ6a~E+TQ+1}GVe8#_
z`W^k6S{atjoJI`6HVE8=i_6TIseK{kq+2*mYGl;#m7~JN#XB-I!awLWYNcP%?>P7M
zwLvCtcv|lA&`en;wOoUE8tNBl2h0LZ4r~G7fVtHOjW5?wo$;t=RmpL4|LJSOi=SRn
zQoe`(H$D8!p-ufqRXj<2;#H@fN;tYi$k_ZgjA%06#&deHneFk{nKv*p4wz)a#>g$F
zPmRjzjeM@!?CL#hyST}HvA45uj`8~w{U^`()#dG5MOGe<N+>Pub-m;0p4F>tdL-|Q
zTX94a<{rX^@M?L3a41VSz1Giy+l9k(hxc9m&oAzsZ+3I;S5oQ;X9MtG@Y?V~I_t%K
zq~?czp7c~l&==mOzaK0k#r?yR0`d7=zgw@1yTv)IZLJe*F3g*C7TD+7DFdFl8`NeV
zp0TGHoW$L9GySRky@iX9OgKT*SBO8oc7^_VV#1Nd3*T!edNPIEOMilm-l#R7jMknf
z+ACLx_Pmyi&ZpLcbUVYVpHqa`3ce4cyu`?<RWV@G1|7_0;@CUb>Dnl^(#867$LJ6A
zbCN~QW_5hP!;;V<dXYqsfMe(MWHHx=Uf;ax09m=8tUR!4GrcZh1UnZAhr|N3Raobu
zHxd&pjl=!>aF&X2h)yO3`XPDvEZs;~94C*{e-I;`^*otETEqhDsW$6QE(1<&7}v&?
zS>NMeq9n$Ye#BpF6=uV@4-_ZZ7EYVOnGXgpb%xex@Y0K|H!qNzTx9YG>&OG^>F@NP
z#Q#7*UBKbGrCX?Y;S{N%8+OaG&x5vJgB4y*k&G?9GZ9;@p4O+~2oM3tkDEu{-%mb#
zhHjv1P%lnX;QDtV%j0-I(1z6&t!?d9!qK)V<jei=R2p@6O>h$j!x<CIF2FM~(y-XT
z5ws}izA5iueungv2!_v~goFdp-HvX)^4&S%(uX@oG`}<a`p%X0E#s?apZSn`?&If|
z?%q6Y?!X!{_flhR?{jmriZ|^{(yuKjUpOTvY0mQ%<+Vp=o)1vF4~FO0h!NnP2)KJn
zV+;6P8d&u*LU@(eWkCD`Mufz@YX+>PF$YN2#{L^CdL90#+f@1=qIqV>T=MY7OECeU
zhM%;-6YI8r6|AxTl2E`fa1x54ZNMOgV544XLUD)d0q)2Fv7o(=@HEn=%S3}X6yifT
zpa4-`gaRYN9Ob38WEu@D#z#Tvi<y8yBN~=(q`yBx|6IG|p?xHV#O{0e(8T61znU?z
zq4|q1nj1LSmHvrmeQ6eXBjDM`i6@Ca{Pfd@==<NV*t~i958uJxD`b711pTbR*cxeq
zqK4Hqz$E++db0k}M(4M+k>z{IpKT|(C*ZJ&Io4qQJ?l!&)7l9Aak&jAp%CPQF<_&~
z3xm8DNfQe9TWg-!&+R!bRJR`iInN1&5*Dh{aIG8KH?wW9YxrMvnjSnyzo0*yrh6YJ
z1`_-P2_<1-!OaW8qV^?l`yydUd$X_}z+t+&32i|1LgzroxJg64r6EtjG$wGKn-}2v
z65)(=?Pieg2+LvUMH$ZE<nU-844%7eP3C5C7p;4@lZ%`8a}T~^J;qJ`!207xMx&hn
zRQMfo8RQIN;Xhr~L03LLLZ}=e%S@`p*ZG^c+J?=eMpMO!@a!>(p9!*rq&M+(u2onu
z=k2yHSM3m5xqqA?nI!YfTjYVrpzx53%?&!LAsx=+TRsjo21k&j{ad%~w_%DlBVlTU
zmYLNYuvQ=7`yb$TSjY3R92BDp9vCxVyh92W!l8~q$N6Hbn&Ee}O~Q=dCAEiZ67{S_
zewVcd0>!BVd~e|>oz`ZZ4p%T=5JTY|JL>>j6k+4vQ0n?Eb>-VTz9elD#B19x+353+
zO7ubhfHME+0c&5_#u6wizO@N{XYt1f(F~<Y^%K0bqAnfoNHYkVKA;8k&jV!IyuQRt
zuT7#Cubd@=xM1tIVu3afa_D!H$-JMeH*D>p{?$0X$Sgo-)bU20Yz0S`bA6XTLv{a^
z*u+PV)|=K+8?Rz1+zYWAC~G5u6(Imj7St69b_-`sdx@n7=-mBuE<|PGwV!xxUUioc
zE{Aw%Sh7huZi9r-DjGL>5x4@x?c?<F4tn`G?4}fVoFwlc$;W9NIYBG&#qH(xNbkrA
z>nK3I->q*|BOn&&AtRfiaTDYiqrn^nrBs@?WLCN~Bjjcb2x_**5o4rk#3R}r`=R3a
zVgF9gNA~G<?n6`Gw^O%|p3qKgzVvqU1T8<aW3AhSneV;VJb@cdzdZQ#iN{Ik781Ds
z$YHqig9Yo?&Hrf2r%T(~mdG-p%|NU-GFL@_cCpBQ1cE#_4#NGfTp#PJ^0g<JP9Vl%
zl=m_UC)yuoA-+vG+Fpg%*mHEGnpc?&PF|3zQ~h*)ygJGl?xgo|N;6pe#NC*SAq#JY
zw5FGHHU0Any+-`65cP=(Vm{#y!jpJC{F!i&@cDF)_B_3D<qExVUdwo~<>yF-8<-^E
z7DMz#0}rO}9Rn$geolXYM2yQ+AyJb65<xH0qAWhX;{!<8BrC$EeaRZoFXTMx#(Jzq
zFRc-d1&8UsdXU(jMju%BL2{T#$W7}!`cL{h@hA19eaq4T3w(dtO=i%8r(}Dv<xyD9
z3Q;M8Kv1&2+R>rF%Jrjh&yX2p))5Mck=d9%PqOh8%;GSdgad-?DUM#*%iYg6m+0-u
zB292R_uZAvM{5Soowj-R(&s;Zj{ES;?CS9?^(%K?AO24Bh@Br^64H9tHeQ-jGuT}n
zaDL{|+VYC$=OpD!Sy*1MR-d$UQ*qW@g@<odkmK0iX3`U5lT^xTbx_G_(GFokE$(Ro
z+bwGOG;dWv&BRZB8sa(Rr%xu<Tsr#k^%H4<`^{O8T>tp!CGz_>YY)8g%7L}tkhSDI
zO@O1_n>O_N>?VEr>B_0F(SId*pLR#OQht_lDD*~@EXqSrR5B?<Mohh&zP*amSpT@~
z9*j&Fccgn*9Q_^s=JeK|;J)$FJ(3@Hj=N~d#dtjgUW~g)MaIJEQOGSjF-F5)6;f1{
zGK-#%g(i1Aim}>SEyagl;M!^_521HRFU&)bUfVcL+b{e$Yd-f9z9fI*p97qkwAi-v
z;-Bl-DP3dD=b_5e;LTF|wmOT&SD+xawpX=*??I($5XMpiFwNvsVzq=K|7gdd1Ke@Q
zm{nbVN5s0satWUV;7jU@q3QutsMZXYG$Em_tZDX_+YcOAbc2xBcwu&T-|&&`kB9{)
zPRO*60|pyetzm>ILRzfzpik?gW~iMw@jBihj65zkAT_68?Ig%_fiGrqcsG<}K=;7*
zFK0KEwehbJa%0f}VdThg-|nv?QRMd~&@7g8q~I>0-rB}(yvg^LQlKKcoFgUKnf$vB
zSWiKctl@ie8{0@LrZm=WnfRjc02{}EY7N5-^j^}~x@)O+m8BD3eBoJoj=psIrRFzJ
z9NhBT^{tOFIl1@fg(vnMI6`u+d@p?PpP%MUnYQ2>!q!?oP12LlDCr+~F)P_bXxzWi
z`r`-OWb3h4xCi%>i`%Vxxr^K^sAMk7eDwl(|A#RfVu~}%L@2JXzx|VWVgZ*;wa3U|
zvXGwVe5h8D#dc35#388YvG`+E)NmnsUN3UvZF1un9YB|m9x_e>1>WSmfW4G7fyx(H
ze}>CtYD^BPZK&1cwrwr%w>Lbn6Ys39V<A!Ie7K$QLkE#-)T`usYV<u;&oCQ8GZv0M
z%A;$`Z8}^h`4DRqGLl&ED3;&~272y4Vl38s&csZ(|5$%}kaHJ)Y>(?Me8}k8e#d%{
z`_F@L!9e(}yK=vixDhY`e!#Dow~8B~TXX_4WF-_r=v@-u<w7&mm2e%>feVSy45cL*
zK(*XJ(o1--{lp0JeH(0a(e--B6F`|5g=VTH16JZqy|{tgMjD7^DTPP;$R|C||68oa
z_KBJ&(CsDsznAT?zFj^ihs(U>)Lqy>|IPg~*ZKm%&LH4u;|JO|6F+R<dWfD}$#bjd
zVRD@_&{)<!Jag@QJ>Y=sTZHD7^rZC=xj_#@g-kwbBj00@OgfT;IkzsTO0X`)bx&St
z1szj(^*UkBI?~heci@$m;~`uDCqls`<Pv=WuX4N&Vj;UO4g47X;I)6Q{nK`_d;`kl
zB$Pt^q{F&J-t(6oKL<%#=c^Y=_ZL@Pc(J;4Kj|O~Muzc;Z;YKeW9(}km-t97lfG5|
zuoF*;xcREHaBdrpPXk?)RFq$;v-C1awtjB^o12f%#?J#;m~Z#E>MX3Ul<vbQ33uTi
zr3LBko2$jyjxCVK&tE%l-Hwfjx3vLs;N56d$OGmY#8Y(^_bat?L670*5AX}VpVSy@
z6EM6BU)UP9j4e7!#YG^0?Wg3X&SPWOK)k=^4O_t$aU?`;4ft`C@&ja0;_VuU3avt$
zsyoQbMph(=u~n2@`B!S$L28>W?1D3~9b^Y0XT?*Ubt3tw)VAs@%Io+N{y^@e|0TJ*
zwBeu=Y)R3uy(JVCTkKem@1*wHZ%A53nQv>)L1xDm5m9@qC?mG&h-&Ay(F{>fx3zDx
zA>>s-RBBn_wG+RLS@st+b%*vG_;qX%TkhN{wl1L{BVlhDEkJ$8wsDM5=2K}Mkw7bu
zY@eYZW9(oJb{_y(6hh}^*zZRUq-ysGq|zC4N8eCLNOl4qa^JF`94L?EE1jr-Ope-R
zKBEv~0?Ce}xeIRatfwn-NKMhWT|bIk4(N6ArA|aaMA@P4YFmn)kQ#Cz#V3>vUy=pz
z&G;Tdz%`q4z+C@IFG{QUuOf%NWyNys_Ql%1Sq20c379u_7n~SMU0X-KQ7?813Q7_M
z($9`o7fR@Of8i$zB?TS)*G|RmBN9R~T8=nj0KP9-P{WD^NZM9V!hh|QluwE_K*ii9
zd(69seJS!N)Q}>|WY0{fX{3ROIilA&Pcbb?q?vWY+xwIg^>k-6?K+ZZNtoL586$}?
zfe{4rbNU;yB1J_`$$L>ol$BAnd9Q<%O4?IIMbiW^nWR_--X5!!lV3X7C?c&;SJ3XP
zU*w>x?2Z<Tzd2}Ib`jaH?_s-0QK5?ecCBMN#l<q4mrHUo$pPnk+OI-I@pgMH!K{hZ
zTwH{LxTH}#yg-bpR3UdidhJRPKZ|#i579#|B&uA59chMXC*lwc?kTIHPo#!aQMV4L
z+AK-R1_HyhYg{=0w`~}yC^93uk_9QUv6$e1vID~SlVUs!V25CF-!|+>U6EOe7<b|T
zzjH*}!Kb=%Vvim7>C4E8q5*{yJNkCr+TTeUkod8a2emUaSbhAraX>B<PCDDVovvi>
zjx_=PX197Kx@`B7yE(c1MNBbE^??$<6^$sIC|Gp13rBA3?<JlbJpq5SV`F#5d({q(
znvf_fJ}z54s~gb!pej)yhkqfa{6*YyY!&52+3Y!2X}L2crF~XHAcep5<2z9h???ra
zvBxmkr)60bTC8@zhdfGTRP-dt(^&?`8bYb!uAOI8?h%7go~{(^`shjpKT9a$yDpRv
zyL<RzS89kH+M&IM=t|LUdk(Rn6JcAee^0$R%GnuBMOTt+QU>jm-{h_Zb9`ov_pTwj
z%8GKLy!INRGgZDBWq0&?=JB0mwRNKJ8F%hP9lt{^@L$P_x^m!vHdwF33x3yy35Ecw
z`+j{9soH(fZbgoEE4>FwtaT;E0nYc-tJ1onU%Pyclsa1$eo|;TbRO=*e!EgbxkMYH
zjubni>sXiFPWfK-1ImOiq^A6foY<p*oie_2L{_2(uu2J>L3@Apt58C!3T6E6PE;lP
zwMPd#!V+ab*<L{0m;H97jvS!Oouh?aZoU~2cl6=TF$4H;WQE}XUjP*M6So|>QEZ^I
z2JTE<(u7n+IBG(%@cXMHka|}R6fEo!1+lPm;TTaIkWj*kBOH!Bl>4Y9?#7LxA^hEL
zBaR&5dpWMKksC*^z~3AZviqf6P25K;5M>)tIKhAIvCfflC%v#*TcU02CxU|R$1WTx
zDiO%8k*@MeI<faE9F&2C?IPbtKM_&B6LpjszrUN@$djD|$7;@wfSnOmqufVaL~bJG
z7ka3o0S7K@`OU!^9lJR;<;&(MMXLLb6$*8vj4#xJ-4dB5x^N(Aqf4Ks6BnJLmec*z
z*+|h53xyj64}0{wGe`LCUHU+G;LIV2{XgM^m?@muHN`k%y+TP-j$Z26E9%6MV?g^G
zF~m`8%6r7Gvk!IU$T7Cr>l6oXg6M`;B-^nR>u@>$-N#<=bYnLDawiQcoGDo0HFw8L
z%0v=h(%+6=hO%@*&hBhVp!<tHf#{$y<VNDej!&n$mBlr=7bQQ{0X0cU?=S1Bu2e9x
zAvLMTtjJ`KB0?GF9{eojUyx6x$Am+Q_lO~Pqln+%ohr(WR2{Ltoi>YM_a(0q!4*As
zrmV;)XLE-U8b*_OfUVzkpYnF4c)LEkQpL~qI_oydi1j^Vfr7Rpb^I<8UQ&c|w5YBe
z*ne}3<fw8x1h#(J{{s$pMqkmjV|46f?G6k`R(^lA)t#_F9PoQ73fbkA{J5*#J6fL-
zgB-E2_1o?vF5ZnBv<u|wcKhgzi%@3gw)49?S&AHR{?a!T$_i)5g+nZ`<x~j;$AsRw
zPbVV+s<~Gz=t@zsQU}>@qpH|wC(i(1K<w=S7Ha)_`o`U;qs)kb920KiK+%I^4@Aa9
z?$tVSa=&$zf;Lh|YwY41HZG)5Lx)=C_Aa2qC@%BUzkvl(b$lU4chZI<7gA2J>jO0e
zHpp}W^r1Hhda?Hj@546~%{X$RyhofIBG(;pk$l5ZKb_;(ZLBevFrfY&yHPm8e--WF
zzg_J{iY1QGOyZ_f&!iJxj2&5Z_gjl994K7jXM7=64$;j4FSKJN!=cV38+JfS32~j_
za_mFicb#=N?iB3qY-5fbI>flY=us-BZ;u2@sdc}x$kFx`t|g5+Z~(|TMnMHd%omE~
zE1)rs{+3-ia-c*+y9V#fg%TAV;zB1z?0Ebgd%6=Rs4)><e}xJ1XwRLFHSt}T!XSCy
z@mjGN)DCi}eD2E8ou98b<}HOA=4#APWT*R^F$y_RYz4VNZ6Rm(=17X24qEFHJmtQP
zJ$n9)zKz0BSMC(N>`~NiQ@3L##ZrkwNs|r{q6>ghoM#wH!Sw$Jj*i^lj-#Dp$qzf(
z7^~N1pR~tSgp#o)>-cZSE=L@d_o(GN`KBX3N~EyISUJ*ymvjxWcj(Ky-J>s?Wbe&7
zVs^Lpcecx}csf>>w<C;K->!Naz>@9>%>Vmdb(VV!=iZ{tNwdeu_u%Us{N@ewFz2$l
zd$!)VeLfs_hV@=yzNS+?%)9I(&+)TeDM^7bMtSiY@eYZ!6U>Xe)c|t?!~fRYz%g<Q
zQX?=Qif)58{%dQa%iKWZ;dVY0e#A_BYpg-QLv9b}@Z!BNmmekOhMnhz(QW5dd;c8e
z#IUhl2QySrk8FOsj3B!jiR7Ob{%F@oyaG-R_sFwTmAe!kZFl0`pa#BQ$1%7aTL8Q|
z-LFWB>ltJz@7M~q1i-_3)ge+#5<5;H>#YV(VEDt?e_m;vaQ^%@n5rqscdLOvEbE5-
zO5h6q@cHv}2)pWL8D0r8-D(gA*mP*S60a5qNLM@DA>GC1#DeZSZ1({g$N}D^yi^_b
zySua?wF0`o)u1`x&;}sVwH0hlbD(oecW6!FtBd||%?kR2^}u=S0dcmN`R6Fr-t&Nu
z{W>;38Lq=W>{>b-Vi=vRTrJ&UzaI52T`m8O?LPyzTs!}a<2?@dY3jhfQQMvFLy8$j
zO`UWv+^sf9{NbI-3wh=63@m7Ru#*9I^)!aV(lt2$IL&NSt6&9{Uj7XG3uVHhdRQ?B
zhY8M3emTYRndOl|w6+f)<u}6oNKE+J@W<8U3AdtDH*)j|>+{EssZ@3U`#~dcTphgg
z7S2UPw5O0-@;~Yf-Uu`WTqlTU)WietxLyg)ltrFlSuZR*!OaAG2`(}Q*MXHwI_WK2
z=X-Ne^NEfhPM_w!eyVx-pgwckhL59%15Fk5i=RfP#l?q252UXU<A`K4nR2vlSe?*P
z-+%bQmg@2VuYtqK_1c2LR6V4Z_1E#0ldYFWl%u|!a&P@8d?OCP)7oM3y>0m$uHAyI
ze{n+q{DX`7ytL9PU)<wR_=aA2lfFiml7%Ga@TvtGqhAk`D=&HvuUm3sYI*sT-?vU2
zSK&wAdJ`7N%_BJ^o6MgzRpUnkgM<BIR*ai+YA&p+{d(?m%}v`3HeJ9nCfHjPb_B<@
z#;|^kp#tlSiPj8fR5LWh@vxfkduuFU@DT~!w~c<1HR$ITUwnH^Ik$y=_3U|+`K{++
zfxG*Hv+ZkJCrL5_=C458;m|S^4y;+73B-~cHN!WV<|uX;eWpctrMCUu)29V}eqBKK
zKCc~)njRHG#*QV?ajVaMJh)plXRv;WWT@et%8}H&TjE^ndu!v9iS_fj1O9EJhpSeR
zo&y;q49WyDifu7Ygy~}gax2d7HcX2MsH+Q)UVg3H%>v8k8K+P4?fl5MD#lv>=#enX
z`u^&;G-CZ7Z3>7>bZ-49P6FL!Asty+_7#kGRUs^fgJZrWWu}RfRt5Q$7lhTmps4f7
zb@QDK{yoE8;dJg1^~?Vc)H(IfqOrf{FJIgvY1pVZa+;0~j1Kpo-BqzZrqvUtfnvV`
z#h$7yyfl`F|9~~-XRw$H_bG=>5STH6pW$*dM<C?G$@LH~z#A0);A5J2JiTd>#WHDX
z#z|^9mHwH9p_B1BeASe8io9`B`nf6n<Vhr12ZiA0GEOR<uczMR-}U%IefwHPKipN|
z2llJ5dA&k1GYu(nS2MrP&i>l+^2?bsnzFOM$$04{33r}XVJpmU_}8Efh#ZJL?tp@O
zXMo!%yUW6H>UJ^s*VeVpe01sP=Gva!hYZar>TeGFwcFwa1xZ6k#R*qB^0xOc%qp7G
zb4YFX`sl#EdA0mG#xbxf;|HtqaaS#cUx-Rw><Hmw%)_=q8S;m4wKMTe6A#25j<a0J
zobEwSEIgI@sl{@|a{6>8z<4F&6ld`t7k?%(WJcg4UUV9{;MxX)YB{fkbhrYcs@{5*
z%kZpMsp`GxbZahd7sBFL9`J-S?q#2HR2c*=i;&l?Bk%O-)ajEg1@o8WTw8vizeTTj
zkF1X^^)K6GRQ&<%K}D#@2+NcaRe}pQ9l|lg6@sNR#APEYOZ7+k+iB_Vq@Sck?rCOs
z+CNd>Y~C9k{YdoSw4~GIT%-qSB269<<oVO5QH%BMwI-9Wvi*{a9HRxnMX0Nf=!oS%
zig2(I5p6aR<ik~~%)Rc$3c&?EW*K$ycyVD;m7AvHGVl?-Cpvm>%%F7O<AR4XH!C@K
zlKBz%$}C(Fc$fCU23Mh>gLG!Ztz#=soPjq$9KeA*1%4g~e(uT8R#x`Oi}?wz@`aZe
zxc3SA8U5_gBYU1C(Ionbhv_ByDt(!BBe~pm`q9~oub(AxB=P*)Z=a_(xqRz$);1{z
z3NL}2xF00TMi>+I4qhrHCOmyqj+VkptqWiH{#5de#;mMKGg2TDpM7b;dU`25aqEEt
z+Y=1@xs&5+X=oj47(>;F3C}*9UTl4}BEt#uA6+4uK^7B4gM7%pvgeo~ZrL}MK!1`?
zHwTAe5~2-6!3WsLD3fO)1h*R&&B^%-mgR){R#iGm-hb$^ZUgI##9b3$qHodD^prk)
zG^wkc-@jjw=ZleJBSQ>h%3RjhEm>Cll(z#c?_J(|qTiHwV)p0eb0e*7&(-f4P+9*#
z&5ogT-a@~C2)15M(g$qk;FOG~3cx;hz`GajwID$U%wZYPC8M)&%a%lwbP35!@j`~B
zKdp*N==0Rcw2w10KS>8H7hc}{TutS?6|vf&fRUwI(Jd;)dUfiq*4BrnyilEANSvRn
zE-1JDB>QHcF)y?XE|18a9P{SO^`3!7?w4JS)}L{$CfE$W2XHQwv<iNNA&PD34@lw~
zRko9fl-}jF+Kw3mPX?BD_JGSn3BPCbgr{F$KHNDpu#cV-+{;K@O-fv3?Bwy|=9l#!
zH{s}G(`z-xfC?WK&v~C*JTNt}Ai1u3z>3}Ef#+r}99!!gNcQ<B=EPhr={CF~uPDUd
zKW5D2RZmTxHl`M;g5iM?0RfBm<z@}4%Z%~&_Kx^jiF-l^;Ed~T<UDGWOj7`>^kO>=
zm~=*=qs}8Dci#x2?y+`dQ4zh-lc+~6>yhDG7b{HWN4`+n(!Lg~5%Xqw-tXi~scrD7
zZA^!Xf5R~?5WyW{HpCXTWE_x^{aeYI+xq4tS>OI{+kw;RO_QZ86qozZq1r*oQDaO4
z`^Lod9cW?>-tpTz)Y`o03qDjzKpkHn?%y<i^buZk7I-3sc+}Mm@i6d$`;UdIrJ!ev
z;jqbpJ+vI&tD+Y79$D@*ZC}!h$(GMDc9UMD&}W5tUyO0NLAc`8UJkMCb&S;=5Ag#%
zh!jJR#;@vkZ1OT1u)zt2S34!5GuuBnkX664O+_1BizD4&Po;mk6-T+!`fUj(6D^--
z?k9e)_1l8)uVg#|hdpQmw!}Oc8#XtDu@WB67j#?*50@EwmFxR6<Lp&FUgC`95%B@w
zi`53Q>tNDSDg$3QS__y$<T1Mib;)jN;sZ$+lC!Q_HqbxlZ-HwQ&Lu_fF~8?V`qOPs
zCXN}Iob}JlweNixv?k$fQuHHHAG*>X$wNmV3y|k%troqA=r~VqAgDrBPxq5Pa+>R9
zmDk2%AK_)-FH+KtW69!x9Dt=DC%*iI3!QZ){gcehk26lwX@`?vNy+*ua|0B?>G~$~
z{utwmFaXEemsT+H&u}jxCe{zRV5ALXSZ?(Lny{4$<W|^OjhGBNFm%|W8xAJ{a}@j{
zIwnPMn-9@#q|Tq88)0oa_1^G)a4g?jy_|*Bu)D~Yg|6-M7ESq#<&T70*ZA-F7oo<t
zV7!7&!Od{k7%E@htpQ>eI1>~u@Ev@`dLmvvzLBtdoNaR-{=4u^1t~d04lb)}d1vQ4
zQ3*9!+3~%zbNY~){nJ*irHkhb9|s3Q_sg;5<%LG%Y9H-ZHt%?CPp*1IUYScwes*O=
z&MU=LJE#!obLjJ;-ZOio<`%)qZOm`LpHM08gT5SA%u+^x!(P+X8If%JKVRwWYsd*~
zzsF3Wa`wW@t7eaGY$dao&b`<&h5lP_ZqDwW6V-3}vUq>;&iku2%pD_K&l4tjT91$1
zwDOGu{kO+Nq**^-`d~HSi+Gd*9-vc<-dK~$5zqz!p8h569DzZRFXaZ`a(ZWeOUwLs
z<`0-&k)2a%j!QoF(eh-K)*~tQno9MbO{?E~Z*5yt>Le7jo5`6r(Wcq@aHy5+^7*oU
zrkG(v9@3d4rH>_&?b;}#EmYEZEiG@%nmT8}<%M-1Wh<T62Sf`1F&Da3kKDZa(t9h{
zRg$$i+$7I-E{_|@#ZB5;edN)qoiaUsJ;=vSt6=#l9JU-oL9mBuGV0lu7)&sxc^$ug
z!@Oyq(%<GSdgqPCF-Gf$|JtAD?&ckm_jYtf<0<Z&aeYf*o0E4}ZCF0{?O1^>Y6=c9
z5SRJG=hH)Iudo#e-%UIw^&uq_vS4ryfdlQJKI>dfq$!;6-6||um5I(H(i7h}_gvEW
zv8nNcYNOkln>WpRqJOs@!hbD&DzggArQJt=+F;FYz;dF2d%fZ6!vl-cGr?|nrvy5f
z{~6@8z-h_guFAg27N{MtBMtTqcw*dOa<eZ`(aH<IhnFvGRf6^(Lf~5LZyWI_11Z$=
zKW9WoX9~fF^5({!%WHLO0_p=ko4oDF{HLB=aHzF!;pmpeoe$LYnUd6<PV@~Mw0`}d
zFyGhd&DX|{shHGIIfn0P&di9`d1&+l=WeU1N(+me&u3M>wxu{Ft)y*!TJeI$>Z+|<
zYx?!*T}i*`IV!&UTRs0#kYH_`J$rO=lsQGlR#*nU0sV8wz7rg`0It~?TiIU>0kHGI
zvY6pD39;3Kq81m;tSD`b88###VaTwU)>blS;;SUIO+qv4g}Pz0X-^4TVMR6pf2lc1
zKeB!;`6U=rjCcUnnqvl*g99R_Q^rap>rEqP#uOEe9$i#4W~%vMZ2ZyK*41SCGT~Oy
z*fGWM{mpYKRRgysmo#{FyaeaYHPBJyI%^l#eK@pxw|*2#My`)3Djq$$xM)oCq>T-I
zMpkBJ_f0m2lo|bZlT{L_;!$I64p}>NV0^}ytUi_5J<aMN1w;7$NEhT`b}Co^OQ`8>
zeT-BK->D<TK(uFEJ)C3&*+{S$*O}su#JO2q-YwY>^LT9Bp;*9jHi`7Cj6E6`Q17?i
z=O>ctz5oREB9;RBzXo_GA=)vCcxwrM)_q2EbP^w22Jiu6UN$~tB)N>(qwxqJD5}-g
z#LbHe|Eibxr?IBHr!CyYKJ>7|9$GybiRz{3;X@MQss~3cE(9ZK>ufUkn`|;u6AzC4
zSIp!KB&=1ko9uHAcEff4#MJy^?bK(VmF-BveHri#bJy<4H)tApyoV7ZM|ZYj$;^O0
zqt0S4%YE*wx`Giddni=0ip|--qa7cALfaQE`~1qXh4g3t_+?8Hg8~wlVNQAdWBLbC
ze{ywQ>!x)t9qQM*wrc<Jnms!Quy{)+3zZ;WsI)&S3pBU8rk=$inW&P;Ai&QZ+A3i^
zJQ_`E(el@4G}3>ECe|$+S~j;S-Ne#a8GURbVn0zxj{tKXG^%aoTPw%yY_Y!E@=&8A
z4}rLgE<yhUHlP=RQBcWl7TBPIbyb;hun;Fy#vM;g99$dM+OX)&*-f(+yz@{)!-!V8
z+N*SCQ+lK!Y0OqS83s`%l8J-cR=@r3%JthfwkL8P<RNX;p6w0mmpASP)0A^SKfr)x
za3G2_P2pf=tdNs<LEn;4;QLitvU-QB&Yw(v1Hyg{2BtCj+iMH^@VupWd6p%Lw$LpN
zKv<3&j~t4HaENqnUE@B4nBNUPXu+C*l&w?4j{9Nbm2!>&#38B!0^x{)H1dSn#y{ML
z^vKLUgMG|Jf$nP0^t~sC2XB~O*ndpT&XI-12LBY%)kV~41R>;s^3?26{rb%==>ywZ
zzMh>ONQ{Aj{waI+42g9&1{G9{-&R=?5fSiRFo_HbY&J%fR)l+d1@{KaQ20F~nw?;$
z5~-&M8@pxT=m_WnI~a`TH114Rw^8)s;`JpK()hps4H?2UTpQcFia2q-20SorH*IdP
zo_q4LKMeHAZ3@fy$8n!OBUTgOEG%r<dn;Hu`B;Qybmic6bZaYF;Tt?~SXRm=*qF&}
zSu1hj2nI!K!ho>o+P<U7Q!F%h<PxR*KZF2&7u$O^%HAKjLk%tjEY;A@J#w-==m*Op
z`&O6}PQ=Z4{-o<z!%Ab&lmI@3_;lQgjO2YF#i$ynC;8F~0-+?sAL4PK0d+r-X}EUn
zj|36ykJ!n=7%dF4NT0>ybJX-V_uNeP#}B#ZK!@nx^CGuJMQ)9#IMAFjBDh;lXzZiW
zEzcg~jQ(Zey-FeiC;BVgkZaVR@dWV|cDyTJ$C$JJm;9*~1%e;sT#*9&!JvgLMw?-1
z-rg_KIrdBZa9?|c)hO8HCQV3**cJt8V(7lTx;_zGBMnQ!4tab>>1I<!ugJK=F|`|4
zdRLfwmqi+vh92>FljyesJ2$?NG6nG=*<>E$>(W{H3eh7zuyZR6{DKeAQGx+@!?7vE
z4g(JO8)jyxdwkhBd7Xf>bxs7sG7a4n(`U%UzSGLn)5=OT;_B|X^y2aeS$Aij)zyZr
zGzL!&VrcbjEa}_QH@&nhttyl|vX@U`oKQWvV$&lOVi~{-j@q-nibWbYkh&{s)?cx}
zUiH=@;Pji?t=%jW0=UPbRMar`U|zI0IZOxSxw>+{mv-MlnzP)Tt?onfPeIKLIS$6Q
z=Rs|kgPsEdLbnB-9qL%y&;>lHu^-Z;{Ky{H=)l8a<cKHYBvaVDuvV|0+7SQ5gj_dI
z*nfz+ZjG265jsCCU~GV2WZMAlX`kQ_ah597t9ufCs3)Bn87T<9A)+X{BxKjj4)hBD
zU#>ARLIvN#F1kJ&gvG|V_DqY1hFs>hS|R*GEsFf^gg%?uDN`A9!3R0)fet+3LB8=2
zQFxdnRh#e>1-n^r@E8+J%^Op3WDCxYF!ETn!bfrEn&w^e1`MyOSu}pSb!0|SL@&LI
z3(;s2#qQ}z+@g(RXFgJpS9i-2?mmYE%zQH|p=nVA-MB{Gleipc7m`{VYeQX&D_iC_
zjZTa8jU*(@BU&(qd4#BlZ)8F5g=4ZZ{4=P2a$O(myA2Di9|wE+eZ%6*hqpdbC5aQ!
z_OUmH=EV*MlL9DWj^Lsmun!@Nh-rrHoCsg3lCt#)Zu&rV?*TiOt$cUMtonv$H>_Gz
zsp;YDsn?c2_SEawHf`X1N$*b@ce;3s!(4wDb|li<yVQG6{q(|#e|-Pvsiv6&`Ym*S
zQ19&(dw%h%?OT2%eYm7EXD~iVwgDSyLVQXF4z)ZNLl9qyqq_l&`)cPBgDzA2@3mj)
z8`jMk2_{oFA6HidRGpum$Sr<v-ppOK!w-F8F}c%U)rDV@1IG*aD*6h&NpJXusR#-3
zjI#l_Y4z44W9t1g+Ft?O2z?s-5^VtYn}pqaAt3XzK{9<C!&Pct!px2s+OjlmD63on
zlxJK0GFwNXm`ISqn9Tr%7}3X9(DcpQNZ(HhbDw*8d~!mBi<dqyIM>xnuX0!GXTQH%
z14sT|omy4r=jHRf=%w-N@HU&((|r6rh>Iqf6s0HeAH<0<Zn5-<cwbH*+i!WYDIk>w
zM4INB+=YggA7gYxpO78m5pVt4;O;k~<hu-=KON-eE%=72iMuvih%u-`L_ZufW^&_L
z+912!K9Xc$_+USdf;*xTM^J7|#?UK;k_A9w4jvADHc9AYMd)opw5a#hh~7yT>Bos)
zZmx@79iJR%HaY78hPY^bRUR7Ong3X*QMryAl>&A|uV@Rjq0vG~RtyT9Qk<5|pNbJ<
zgm9GCy;n?nS>zZmw?r$A($`jby42IXaAun>A<dwTr_KhohqD()d`%DqjACe(qpau~
z3E&%jLDqZuhRxHZ$1%)Pu=JAtVE5Dr)u@)>exv9$30ax$Zu$UC?}0m)u6%FN%<+w9
z>W4QbYC}T=?P+ah&JVd>MP30R&hbHR0bb@%m7aGCPgqTV_!s>ec42cR6(3C7f$pUJ
z_G%1sr@i&liW>j#>p#y<Z;6cS9WY_6QLFOPM+kyXsG3uI=B(aeE>SH$Oya@4VBgZf
zQ!sTw(x++>=o2EFBqQV)Tbxyt1PtTG=sFgzIx8?OM+*B6t_TP~L{m&3q8*+tj`2h~
zF^~PGT2wt!=i*F%6Ang!ptM6<s0}uWmZ5>fHFTu)@M_^;q<66wrCvR~f{Wn%<Pu+v
zD{<B&3q8{!y$a!J5k&dW0V91hE-hTuY;}^*Gu;f=61BF6SBMxB4#k{DWc%A%*l<&a
zu^e1FpG%oX=31}XzKb!q#oBxv^p7{WM$;JbnH)F;LBWVW2pFZ>Fj6s;Ffw+sX6E#W
z1Y~GP&=L&%K`&u+v5)9Re^)08J-WqfyKCw9+I($j(t2MN2<3bnMI{07RfrfDq~QcE
zRFlyDWsrBMiui+J>Y^f?;{}sR6T$g_ER3h-TOSEKfG3QK%r@1$2Oem_D6_#mGjIn1
zr4#sY^dBfj*pXSH(YyZ`{@aH7qVk!2OA_5YLU+~mFAV-hqjG=V(_&m|*act)i7{cK
zO7zI+7`x{A%-k^#^hzugR*xGnm0uR7^>o&w(<nBy7kHVV@FKE_4Vae|cbB{!3t(Qv
zKp+{BJ<Vgjgq`;RI@wGlPNjT<Va1NB^owe*Y3<Pg^k4pN{J?-i{(hR=wD7P6VWthH
zz=+Z9^n*&>!AM=X?iXFTcW9z1B44L*=D>a$^CES<yszW8T7E#Kx3kNBp6}f&Ib>!?
zIUG~yFUEwZ0+!@|=I!e7j~qHR6CTRAxS{<-<p*-bKhn$PzLG)t8brc{x<`m;K#_X5
z#K+$S=934xM_XrcgL7g6y|oM;$;SkIh6L3O@o|Xv4n=~bHwVWtVdRkV7|V5_wF`R$
zPfcLQ0<$C!x<i84JtI<Ap(Fm@y>%f;85yNM&aU)#P5k?B%ox#Ir`3^f-Dst|PL$b=
zk<FbDG$bE0M}!dfxb_br>^BVh2b?E^@m>84@H#}%rOd{i6b9uVE8}_i$1%3sYd6{Y
zm~^;Vu@0Z(rmCOu6bAOzsa)y*36Dp46?^?x+d~_c7-7oyadsggT*tqBbvpHaj{fQ#
zqsxkk2%8fYIx93VrMG`K-*zT*66^=A6}E7fVC!QNEye|Ec!3XbiLpC86FAJnEKF|?
z4bKo>ZGSDoGezgD7Ck|5UxUiUEwqOJk@-1-;St)tOPC5BTE(6*CYIPRka{ao=DW&C
zGWE>qA-WUE<7AD>*19OUJfNE&{l!JE^`LRC&h(E?q9yn7&GRFI`gk(oB0R{WS2fYz
z+0iD?JkOCJIasAZ<?L=4-hL|DBy0@wX#d_p7&r~Y#Wl26@Ct@QN_-;2+kfO+BD6_5
zXJ-}43N;kwF&D^Vo-hvyYbZ7{Bj+Mkl}d?<m3ju9x5|Y=6?F3I>ZQbqXh`vwtCsAp
z8ur+)7boQB^{IV~gueYOKODA7{(*k6t?esPPM|luy=~W_rUkz(I``b+qs=QxZxSij
zZdfZM;ImVVQc}HpXH&B02&q<vky&tiqrs9XZaZ`E1^V1VNC~=Ly6fP-p~(>uIXYLR
zK2GE&JUDUgWAwL|pqg6&$t`+>K?r<y$qeeI)fqU9|I8eMJr(=+jV$h8|B`=(^?N!H
zb<R6|NS85;Oip=DrHB&PJwz`Ip)8ZZ6GJHBpk@KRN?E)Ma(G%ST<RC0%OnuQz#;Hn
zmCKWl-4b<%{+kB7J9~vTo_yG?eq<+P`wxG-b;GeK6VkiQ^qNz#MMu)dh0ws+d82Cw
zk0pTfuQz_0FgCIGE1|le3i|V<wCQ0Epg(@Jd0G9!>)(F6YW%EdgQ0Tam1oK6rB;t;
z>bebzb7A%Kt&iBV&kFQt>G=R!CPQ1Q$!=2z#v6xpj_P1>nEfq@g`n^_c#Z`hQ;}cq
zr4xJh?pByL@|R_(C<wjYy}W~ig|rb;M+P%@A{Vx2?v@AV>_6`sSk)sTD8$dz_dNY{
zBdBf3Rgym@>>2N*hf^%|>2IYDOOChRuw`lkZ1w7Cw&m)={tvWHt%>M%SX*%-drC%F
z&kTOrTcFMMUn)R#PTe3ko&kG@Sms!_!4Q%hrcfXl9b^MaK6o$-q;d8W6r)(G;2$j5
zrH2N>nNa_9sJ5NycPl?1oA~JZ^pW(Vb3fEIx%)WRIqP(ub+ubJT}?{ec`SSC)(1|!
zQ8ClaOC09Bp#IG$FI{gPNq%$1%*+6@A#K>|bM)P9+q_i~WOJ0azRIVqvgq4Qqth%V
zb7a}R<7-!K+lKLnK%uR|J;0^-BURC|d&tq)o>=WA8tbAl#X(wy>sWoQ!)}`~RaGox
zseN?%qU4E3Jwvthf6i);>5Z}aYCYWre}#Gr(WT}-IuAGE?3&s3Tvc3OH&36%f`{5)
z$WIkxcz^n6te<gd_}Ium(WRjMs>x03?9KDu;90s5HDnRBuQpMLjpy_=Ngo(>ge>sT
zu{woJh1i2Jptqt6;0#kBvWFPop*)e3zSLiEsA1%Y${zBlwwXf1io<+;wz-DouYd5d
z{qJ}m@&^;ki1O~G``x?DJ9O|UFOBmBeO|$gC)O{DKPCm##OD*Wxt@Vg*Qj~UJwB|j
z_38BSkIr0pd4F~pcWji3b(dLBKn!t@>}anpZZ7GyX5mrpbeKL>r%{VqjHsxiWgypA
zAQ#MGVm2lvLN@NmYColZF@<B&vsHvxeyP5SSXX1s@e2u2J*<lG%8N`2njG}7N1kU;
z(hAKwt|7P~B6N0Wz~}(I7-tZDHnwk%N*2zhxT~<<@`=oE|0n-`VrYE0#(@`2JMd!b
zr$FHV*3H{^lI$5OQiUs+^{RshAI!|LP?gGcc!<}PS53QVK&&yzI>%QR!1uB~=j$EF
z58`;yU7eQ}4*jlirdCr(+&ZzGbch}v1s0QWnGwDUK3>ZC2QLl}n;+&k!p|40Dy=D`
z3M5J7|7^b%l_;F_chftIyd0c)*Zd9_eo>!VA71bRv3w$2QpFC!A4>7h48i&fF-Lz^
zEde=4I@l7i7n$~I5&~Eh8ktgO;w&B3!-gMtyV!O#)LrFPEs2_&mpP>V2O<Uqi)Fbc
zZISkC=%|E-$N9u?&X*6LuNs<?_*|k#mWRLj$l~i~fAop;ERHjo)|r~1Pa2xtLw|-0
z39U^@c$Qs*2<RdV!zTS<-QCTDQ!y!ZkkvKX06qEP%sYcZV*Nd^);EfQEC0O2nNr+D
zj<D1f=%J0IRb+-SFgn0ft|`efzykL`chosJ7Ub|$xl>|;1G?BCHwKV9$gXk}T`pE=
z^oo%IK2)c3EeT8_g_d~eaQ*IG;vF2t_Z;l+6%(iV%`3?>KPnsm`36DRLVhIgXAO!7
zX%6Y{mgMFy#)Yc=hWYzh-|&s2-%WIb!2?OOo{9Sphq>#y4GHdoEM2%J3QqG0=xz-2
zb7hK_#u&;#Hhj9_1CgJxk5budXTk;>97CK~rf<JU27cExq{`dVr&aJ&hj*Mw4iGZw
z3vV^n_Vw`anE~Z<7$2V`Ci(ic=ZvoWSGtdx)<ALW=^re-+_&%zlTRe6VS$Tt+79y+
z#=x_OXj|<P4u_jc9V|psN)1Z?1hXQh5jK}Q9MvGlEn!Sx$)fV{ZtFHJuP98;Z&|Zt
zRX5MdtYF_1KR^G%n%-_+zVsVyO5@e0$aRB<4)JY-P4oQ+d^NQE(MhA$&Y!(=+S1l>
z7SBmzU+vd#L`gkyi6<-dam#7;wyJk4dk-RqAXRWq-@+V+8{!X8-Qi<od8C46FpRDk
zW${TM@X90GP`4-p6B66}jU-@f+lsPoxqAY4>G@mU0qWgL7cH+WYF*oBP#?3Hn6UZE
z^hj>Pyq1TXmQES5zTb~r%Xp6n7hQk{=kF^9TUV@|JSypONkOIa+2;mcB`-e!?h5`2
z81k0^Lzpvg``imDKLL<Y$c;m=2Ojy$anI29T_c7*dHl;!r2|63(#m5ZGUB%m9k#AG
zGC5<+hiw6YF&h2P-bpV{sC)REm)?j^uT77NDNPFr7+unE%W2J^aXrd61P8HmOC()x
z0(_F4U=j*i6w{BC_T@~}MYRfUnGtu==_VC@%cF33DJU<{U`X$8({I7dHCtBZuTVd%
z=Lzu+pwD*FtoW|8e|w&#8>-PKpn6<Vg{0<%Ee}my+RAwaYa%s12x-T)+jWdsz6Mx^
zvXe7G$M|$LBi)->BCE`dDrv3<R%T`fsyfZUzm|A{c062Lb!u;8V{P|d-?va}_>2GC
zRLl8}NJ%JKH(_Ah6msxquha`Ijr*P^ri!%0v_U8HLLaE49b1NTLeD7EtT7Kdky}x;
zgdZk$;Cv<a6d#OAq5%VbdYEPe8sw!}byx*U^`hhh7<qGv%qTxBKdHPasi=?1&Chbd
zocx+5KPY#`7bWSr1xdZa!xCeP`lWh@J-s(FWnXI8fTLv@`Qp^%vXT)V(c?{X=|BBq
zE%aO~9LFS>qI)LwDv1w+F^Y95kMO$!qKUEU3u83;Ln!ci9k7a%xMlT*(ZI@cV9Zwv
zhv3AwxigN?n`HOJkrV#9`i4jB8t4uE0&EZIHLk9zZ%l}<xA(l2D=LbT^JlJZTUDT`
z$~xqcGUfBhk?Sg7(v8#bBh|qj8J3(g^OK5-`}zB2TZZ=-Rb9QhVZ_?`Gq+8i-#YGP
zFY{{JXUl+h_f(Kapi724&x2>3hs14gq7*#%lMx0WeRbGvVwDmL;gaV{$qas#;*Y&1
z=e8Hcl=h4Xjnf5<+*2_!Fej%vrzSTv*4-;0Xw>fBV|;US2IUOO4U6&g_7nTWbT5nP
z9@qY+cggQ#E6inEw|w5cY*gw3v)-rpKXv611v_?plV3J6Wo|so<CsEAxG#V|XX!}+
z@Wk-sA*irg4vkS#yo4`$kOQ;cz%2JgVN7{ZOt1dVZ<?B#*O#Vs@19sbA|Y*T?{2~G
zcox@`#ihr%`-LukwtBM6o3-8?(Q$R{h*3eN?umuP1AP2OR!-$pb1h^0rPTM+yLTge
z6U3Q~5UXpzzkAt`lWkL_7Fb~~1!n|{L5Zml?3JM?*Je_Lgn@iOS#l|%rXaa&YH(`R
z(Bzt_6(ldPbXspWoo~p1WkV);wHu4W^0U<>+j)ncr`|!%SF7uHXzRx1#U}Fk$)&}k
z-2%&^#>`EOc`2+VY$E!5aG!7H)c92T91LDff1Q!-8!TLn&_W3H(?SU4BRUp`HSTjC
z6pm95olb%+ECqQ?C{LGYCE0?)HRF|A3h~IZa72llP9IRVpn8%E@o;;{S3Pf5V4xIp
za<f^?3G4G^(}2imAuCykaP|pw7hGLgoCe!dSAf5aVDw~j^H%gHD_E}8C7mkW3j_-*
z3v?REC?)Xxz!caEEYy|_;X8Fjz=*vSqe7QAzqmNaO&d1Q%h@k6+izxI^S)I*Vnaeb
zOaUobQ68a&u!y3eB_6tf;P9}FzEzoN;+ogLciZ^x)b2f3N8}97K?8=lT>75>9a|Au
zO(rke{$9K(e?C1{=oO!-8cwcEv}`{<=<#)H%cdn}2DIhQnlyRo(6RJZhCXmWePV?r
zv-<q|@8@)zGL5dTOO;F<a0eWO4#1)8&N#@u769U}r0ycI&=Cj{j}Begynkh)hsG3?
zrU{f}3^PO&)s}jC2LzkK(q$Q^b}w8VnKLNQX!h{(CmFgTkT0r=G|k_Byj!&Irp6DG
zsuD8;H|5TnJbA@nCQne+xP;2AjOz0s%}lz!KBa7AMhh%9!<d3Kj1lDVbTTLsv8n)-
zV;jA|LtNqbBweOpeDc^=500og^z;|oM%1(=rVoF1QCwL<`fwu5i{S=-d*NckxE)`=
z{6^!r-eY=Jd|5&NGk8qTO7hqSq;=~zI#|GYmKG-*JyB{9)I9(KM(bFDOR>SxV&KeT
zr82?pA!7*&Dxox~d-Lk8YjXw$?a4_zo#>J45s+Hwtatz2t7v$Uht5CP6q4Sre4^XZ
z2bWhAZCKauyskmznlR&&W-~WoVe>;xOE=SJCU^!q`$dVOK1xujwHf?JMTxQ{Oo*!(
z-s>?eUH0^$1O45CjH}7Z+hy!P9u>%w;?$GLgEfOBiLI^%mYF4VsU4V4I%X2M2t-j4
zdRe{O4CV3{Uhs$_)H!KLU}&(fA2)v`mWJJ%*KAqSU7uj_)nAaShC#z>^o`E^Qykx(
z8SEaY*2jVnMh#ckXYROh{2C|_S>^C>L`IKaYz0HbKr9NGE%RRk|LnQ0<eQ)a^jqnV
z;;pxPudECH>+VUtCPd{en-b+ASOVhJ{sEcjnrOC&J(z81dcTVCt}Xj|rseW^NhQTK
zK7kKqM!9}j`)piwE^|AZnFdz@*rO^A8zO->tYwY@Z+VJUqDx72AZlJ3+)yeU_yx)d
zmGm@28k}L5g9-CT{Q~0ijiF}4p~v%lDnge|h$@YkM8BRnU}A7+M(@7q376mP6WG@<
z@57Lxzl|v!z>5jS$lNG@ziEr(LW&|iO~DaGBYX7vEHSIm5*1sVo+~bVFfDd)jAuy7
zUQ5BNaX2163wRa9zS4YGX}}D#iNuu}DjqDab%<sz4E#z}HdJ6@!No__McZeqJT=b#
zVJnUeoaDFRqo{(nYrG4yod<qs;+I8R#|B4_Co1;<XPsL&+A(!t_%JTTH<nE7o#|ns
zC**kaBH$!hpp<4ol|Zpeb_Kd%n`&@n*(B|?Ep~#X^e4RNZwyQCza?t!nz^eQa-c3S
zL@RYcWXq~Kqg}m;$NHe|xt<|;{(gZyYbxEneMm-V#rUMkEn8O2T|k0%C6$dzpC{J`
z31jH%%T6r!G;ldw&Xg=o)~sI!4j5aGnMUS45_pGD1kr$lbxVK6v|Mk4971IHX8Jb$
zVFEH35{C?qez^CTxXHV}U2YtgA320isNQIOh&V4K-aAstMkOsa>vhGy*OkXkqhBq%
zKu%6cFMFJi#4;7*xylK6V0D3%vK)O?NpO-YbcIk+v6Q~-462+Gy7g!}@=o^P)vNjr
zjE|0v%Biv#B7?O70i*VokByvmq_kVM#xu%4Gc-RZbZE%Fi}Ru<bdMawCyaXf`m9U4
zcJ(Y>K5XTbDHD^*`Xx^2r`PrP6PO=M-<|VD&-`BNb~U^=DN8+vZl0NYf$Ut7)9+yw
z2t%CGAeIjSSy*(n`?F2uQq3)mX?Cr}I+tPqvJ`EFA%%&hBa`zt6waDiR}z~P;jIsy
zdEr>fpmpV$Mcos7jZDek+#?{>-15)>_b@jP|Ik@49?I;$x!h93=Oh*v*LVkiLmOsp
z?w2&apHEQ!e-0fAF%>12lnn9-xmkB{N6MxXk)?k6!2I729}b0XD(Zul2-P5i)C=oU
zH-b#y;|3jS=&vmt!zma_wfe*O)on*=^NYHr_v#tz;%Zz9i?;cZ^JMFmj0daU$d(lY
zHtF~23Uc}B&cPi=pIW#&DSb$0-@@3QFxl}_u5S6<WyBw?DS44>+|gs{E6Y#JuI84&
zz$NmY2XWvH;2q~8!s*W{HTs<7Z3^^J4)tzkB<o(VuWa_khS~TxUVH!B+Q69Pr;`Vj
z<;Qxs`-QbUU$8AHJ2liC>g+#k8gbh{P^(Kmkvu!!)5SlaW@EQ4NjWPyKmKUgjTbM~
zJC~%!4GGl;=l`-lHZUXBE2L@dFPrMQ;&B0beag`T2O#gmIGMOsY=SkUFn3-W^9M!%
zS5~^fENCMStlyTFNhXZ{_~{_9;#{h=&MqGD$KsP;N)GULjW-m8)6%whi#ZHNxB?pj
zgTfONvvk}}A49(|arYdpp6W~KdwE_uf0fD{=c<M|3ZAsxD<%&<X2CF@Izl)FYvY4O
zHCfI@S+4-5(mX0$3l$C{1gzHsu(Bt{xFTF(R>%6e5O480gqV)AOxPR~9^Uf4CLA0R
z4^JMwWp-)5)Rpwb4jSa^k{MC@>s;R;kbt|oZFm#?b{_rJ-DT{xCH>1QSJ4Yo^@KRD
z=vyQtZ5lT`)U$h8^N8Vpm=j$EA_|jWGYG9dAh&ekE<!ca$I<Z9)_2LmNoWHf+`6hN
z6h|SdFq_4c#t_BMM3l*(6fIJ1D47IyH>84#&HAvw&~LX1LZr$~m&kW7UrvkH#f}<&
zXvwT;S>C?xB|bg-Kiu{l-LbdVM6!i=yfw9OSX7W$NZox%v}=s(+R;<3m!4es<j|Ud
z{pMyDcn0;Hx4mEQ)f?N-9Ql)Yt?v#`KCtEk-K(^KX#k8|;ZrPmz7+V3!ixl?79QTH
zc^nW%j#b*%KBCWBGlIf<jQF)%zB&e>yYl(mnQ#>QC$GA@{^%u~e}B%1ymWpjJ$#e?
zW=?iTtccnKSglyHfh3al^<>l3?_Nio(Eb(!4}&F~7zPX`d@vzT5VD}LN!?ckCb$F=
ztiqCf0SCXb8Fk=q79E%|n;7LQE;8}yks7VK*s}3pm{&u5O<cCG3XshY_6Z1Z3DCqu
zX>^_sW;FZwZa*_-ScON3i)Vh&qwX%A?LP+T-BNl*{Te+X$jJZc>LvQo2}VI<gvaQs
zlcEHw_YLVE5*%Yvjh-_jXS_eJ4t1&2S6Q!eB|V>t>;(gvG(XJWoZzZLV=?E$LOw<2
zdXTyQy=C^qS)6J~9kR?0Aw+gll$HSp>hcxq!ugDFji;)}vSwF+*VNb{u^GN9wVN(4
z&?mtySQW}8ioTv(lcq#1$Z&S`$o@V%`CPIr<}!B>^9vVAOb`Yh_bf|_gkzXM%;1pd
zaMkFKdbGfJmD&K~*45TO`53JaI<YLEb0|tE*?ub6emQ)=K0l~Zev0U5`vq(^x-|Jk
zdZvJB7yqERX4xNLEC`$#rbVZ!QptEhTjj%N7A~cwYh%WYJUXbbw^xjDRd|3Q>&vX@
z-O&Nj5hXq`8l9*O%E|PZ@f+Q~XUno5$bdJe^&B3e7kj}D<L)|xTcYc_;nS^eKeqVD
z(3;q!zHbU<DfAGo=3>GiuSiqi^3@wUPLle0SJoF)+H|J+0(4f(WCG^YyfmcJslNh>
zF!B(4<lzIyKq_kp69Jf~bOAiG?)<gt3m=z^?n(ciod&8&zm%SMDlyR4B`vaiI#th@
z;|Ed7Gv#7x@(W22xY8nf{kp_6C^_j|GA#KF(BX{}$ju3hJ%fx%r<2m&N(&JE5?w@9
z`xa-Dq9>7vT&VR+L3I2EY*Q1KuTn+h)zpvtBz;tDl}EW@cochTOm4sXk&ypF?_w!U
z`X#1HuMX0<dICQwucZX|xn!6te@z=7n4EGUIrY`lK!rz+QyXDjEm)HhT=@v#3GHdd
zt*dNK46JoxJn)<}poxVwgIXS^>x`vvAuT!S?H+X2^!}rx;))V;LkwwYeFk<*(qBC5
z8feVEmJ_|(3=rjtq$7)7PRVI3vlJ93S(4K|%>#Rm=8p?t&%l86ENLHL08hn%K6Z@4
zVJRwVxs&pF7!mp#s)wba7@%Z>Q0+5njio&`G@GP3_sTYycbQ>NnSi+D<gcHoP97y|
zKIui&Jf<x8O3}QJi=`l8G55JCEyx(NF9w_zq{<SB5KGrt^I-0J6f<v?AadF@bOr?D
z2+15e0Ue#>EUK)Ja)VsW40cIwcs4HU9+H?8TVXzJXQ08BqaZ!V-3c`qhj3=Q#;aps
zXCt+Io)usyUUS1|&Qs$uhG>F>puiwv4Wt<uAi*xd3e^U*!aPFM?VGuk#aHwKA^12?
z;zj)_@B;3r*db87lb^9CnXbySJ~UYX8vbSl4dgZnb_go+1fx%NuIW7zZkVP7fzQPs
zjgNgIR`R*))=Yh@L3Qy*Lrk6v{%BfbGAuC!g(oBy3qMCs3^bCKaMf{cqOXyR1IQCx
zRN!kuw1ck+P3^s4-SzJFXWgMrQgFAZI8O8t20})NX#Y|0#XdOZ;x|D)soupf$l|6M
zlAO}V?J9^8@?jQ{{W+!d#QV*##Dr2<Bkxn~p|QUBWoT@^^KAkw^$0SO)$tng-qDbl
z2vcCJajDU;)ChtAf4rz`AL{QZEN=h7jk}HW!JJ^q*LIBIv)nk2$bQN>y?5)Xcn#vd
zw5AH?UmI~6tIpe)>co~eDTNPCw!Ze+zvzLV>3=`{fsFi_xYB=Tc3(pOu`)ZgU@=MD
zl*f;zJ7FmOU&QTaGLE>AK>F`xs|Spw<dY+72T$VMKb7kjaX(-dFF$vK`h`!mz%$L;
zy%21c>D^WvI+PdU{<K#5IK4T})!)x8-7OM=Z0hT&m=%MZXGQ($GddG1oEP`i&7j|(
zeb&RJ>GXzztnfg=vvC-`MU8~lgiEz-GVF9DOyXjo&MEF!vxZn-&CS?21?`u2dJp!u
zKx~Xq5f*?AvpGYZ`vg$_fthwfOnKUc!{vUN4zq>CYpd4(UqbhaD9<2WaN3xL=`9BL
z{sREdPktbyejzUOx9pxv9$Qvhm^-d%KvT~Z1Ip;8x|F`vMf?bQ{kvb98e+Y=#ill|
zYFnE5geP(Tg-igDL+H=*S5=SN*+8w|962_2;KHXHN$_vhnzrI(=p#eD2>SgQ@Giks
zwa{09Nu>Cs1RfhgEp`XcF;Y09j^4^vlPhBnP}UKs<5-~wm8JMI=i54(?oaJocwp*W
zeW1qGBjuHpq%%oDK5j`-6~Fpa7ojHRK0W<`#$lUQ8TwYo3NE0mAo{@jJ6xP6JhX0&
z(f1|ZdDQHGro5O^RAaqv%X4vVDvU5pH{JT|TRU-Rd|_Mii^;QRc?A3M<64RJmvPGm
zfsEZC*SrjRa$?ns&If8rbxOFJ&9aA6;5$tVVwDR1g@Y_GU~Q5IBc(a+=0sRPYysnE
z)r(NFpoVwWi>|IB)QugJc24c{P`xE>-KICbo6?|)^BwM5?9UO`u>;pm@6&r~--pLe
zid{e~=Z9Ikn|=62<V{yvtMZ2Vi*5;S#Q(ubv%-DiLPiXp{MN(!rcD<7{mCPqAqg4F
zdRl4+H!nB&#D_jPVeBXp+LV(C^H1QERaFS+4ad+RjI+2Q@hGKp7Dziq7gQT7#aQWv
zRX>)Ns^C;1!2qSDbMKh7F<v)93-Sy(Vfi=n^KRq?8pf@>?i2Y)YpRQjw|81lw#7~3
zCG>UC$|ZBKD!DA7#po@xZ{fIDOh~Dcx76>5h{!N$&OaaS9}2uqhJMp$GOui8Sbn6y
z`bM|q9Tk`k8?*uzF$g;3)6Wcv2_@pA@w;|kes%r^=f@X%2O6QAf}$$G&$%W3px+nA
zXE#Od^O+rF3}0<BEW^N;spfdWr{j-H%U2E^_d>T=-dj)^F(oBC3#yK5lk)#RzTN|_
z>8tx6=YBHSBMCc!EJ6q?kU$a$5cb}C@4cshAc_l6+}2&Ib#Lox)z(^DJMFHuyL~!s
zpSHF>T~_(<Klk%Vz&_9S|9kOjl@Q4p@AE$Ao_p^7yxG}uhM0lzV3{#TqH&P-9>|N&
zTtPViJ1}4}IfLfre-?W%Me~o0e=lfQFq7^i%n`A#mI>Yc75jXkCUSSM@sAX3B%I`l
ze6e)3#J%1PYNSZz{UR?f=6g&aUXaJv+QR%nIb)Z-DOY1TEcGA<JWt#x2Zc_U>!JTN
zI^9%m80$|SoTS4Yl>d48ACg+?Rc&rFD;#9(C{JcRDRGdo44#b1ED_Eriv2!8SA+OG
zn_#`T4)r=YM(M<g{R-+eYgM?Y2E7xQ@9rm^mb#R>7&Y-^Auq=A2c!5;N+*t^8))Tk
zWp4gpg1B_ef>M(HmeIwbm85fIKIllz^svF$|67GcAuZ$oO#O8G9l=x!n_gx=tTM#-
ze>*3iFWl-+?nKtALU*zMDgWT>!EO$grTnwxDxn~lg*ErttMD8Vx(V$)dqSaCaqN5F
zV0%ye1N!ZJ2Wvl>*9H{m9}jieULWCzCqPW$s3xmt>TnT;gTU9?oXtX4$>fK#EYxlc
zAH+s~5{WE?AivV)f%g&wo7{}*jTQk{qj8wQwga0)oBaNNv}=HdVStO$`(dpmSm}pj
z#@tT5STS?IOx(#AW8%H6ghD7pmRdGz=Bu>#;0O2~^;NyBa(A#U65l}QnQ00!xYfPE
zjSm1-&-9SlOdqTiEF%yLog|*7rN@9(SX;7Z-X?qr3l{b*&@0qD&}(JsKz8Ho4wNnw
z(-@cfbh!yB2D}5#1}=rk6tRk><2>lUdg7%>TcKqvKRVJ1D$QCKE@RC(^5bS3zGa-7
zI>?^OSn9%(dO6=;HnBIb)KzNp(-$IFfx?A3c1ND!Dz(0TSp{5=_q?8jKAns@Z3>-d
zphoy46Fyvk)A90Rj$z<?9Ku*0Duab+nNJd#Ck{n-PwXnpo!WZ4J4K!%k7W*8dl!lb
z3oGAXa-pocJzgf2)pwOMQ3%t5yxQGeU%C6&OE(IG!{k=HnU_L+lizX@^3bu?ZP^D;
z)~;RV09RKMW^aRR!K@ddUND~8z;elf<zTQ_P1mwA4V6$qD&w5ayr9hB4ZFYFT2_RZ
zwii$!GvCtM0U2aczNWNkXF<-Nb)BUV;`a7<iI+D~`Sa5^YOA(|)-o!X7AT14?2a4=
zZ|7YLe~)gc60ciCzP~?i_twnAXK9~do0)^ny#F6_I$)zYQ9NPZlQl{{db+Lq$cew2
z(n=M6hO!c6{AVTNqaTd81aid}tSv5A*PZ<P+*5(t>gW({L$6pu4sR%Uc7d}$1D1S7
zKY=a$jWZhm<0m>VXtb0?=!qQ~N&j#c+&uRrk#!uqYiAL5S6zz4V6Y8#azK$@Xx7Zq
zyV!%UwDk?7yq4fac@4_;hun7Y^_1;MMOb=qgRzwe=6!>oBKcKU3FW_>1E*@%F6Y3d
z612<=u#@NfZ8E^KW~SP7{;(uq44>|lFhop-`Ev5$6E{)DgXXltw}yY`%l-2{?9O1=
zdp!}Seme!NzhG%~`OPP0P^mh+?n=BIEl4j2jp#^I68`FVIB5tmHG7dvV!X$?iSJOO
z*GcfH)P#d^_6FLkbVk6h8v*W2)uGhJ6z-(qY!8rPyeF0GeblKU53zgf9f9~>dLS=s
zVRm+*AxSEaP=utq^R*%i=jE??0J`3nDND{58&X(4QNfxBMP-ncKUwM@Lt2t=B!1kQ
z=og#|uj>^x0oF@BH!*sAc~1O4+phZpw!v0>GKq=6R@6O2AT`zPhsyGw@;x+zgNtFX
z8|&d<gx~P0=Obf#$fvwOI+aRQQj`$R=W)wwcNXVOZTYS*QBfifB4?$w?eS8ntg)?v
z5pHkyAaQL*%yvrVG^J%icw=dqp|<kTpD(;v7_6&q+LXEfWcl<W;3|kmRx)64ZhdCr
z33^i$j7puU!d8X+PZ^hnBRxm=&(Q`}GU1t0yr4Kf)lT8#pSPt~#I3i?3k(W}m2Z??
zFpkzJ38#H%&5FF5VHcO7V3w_&3`%9fd`U^GT2~-YE?TsyYvFlyKIt0}8y#%PVt&N1
z@G{0OCz~Y3bTNxN$nlf_pKAhd9@uyY_9V<%FTmRDVPsH_#$!WNk$|P1-z}s`mwLy4
zks$H9%txyT&eZz2yMz;x<l?^K_!PUxT-+jp<Xo1$wU_2bTS;7s?H*Ttr-p5B?H|A@
z(<xO^zF{?D&-<qc^ToyOpoQ2MeUzZ|iBTsA0-S^$|5ED;#d1=Xr1ZJu5dbpJc9BWM
zCm^%Uf6MIrk5Qt3!em~7`PvoGOnf4f>lCUCtwI&UdctGb$cA)%oXkhBP=#|CX^~3a
zaT|F~q+Bkt)VmOV<t?LiDLJgNut1PnS8JGQb$5AiZK|};Cm=a8C?rCW7r-b>Dq;AC
zNmG&oijzIe+2f^+p-^DsyoR~^UBC);_t3m;aa(&HBoLMVgbB@9R6mQV$zU#-$~Dx&
z%2ecnJDBeh((vqthSV&}C$p?_12Ae>kjRx3Y`oC9kfu&uZBcBsrz~C(l@w;<QL>Bs
z{KEQSj!(UuX=M}Ohk-Ow&=+o~gX4t@CFB-=8bfbD0wBy~Mi{|^nvP35`ux(m<5NRp
zBNh4@g1^$?iYBHTM$j`~c9TM$qI4x*1zlm+4kGtq?gh|bqNYG)QdXuRUd2o+D-;tJ
zmYyL*+Ci{0`!@3S4w52+7i*7^Qr~nG^F%mZhUlwY1k7|=vRJ}_fX@Uhn=b&qpl6Uw
z9|E*x+NGV3MI##QkU8`;@S(?lVw~;@VYUN85#j&-8K~w9h>CwfnA$>^#-@gg!yNft
zmiYnxkwgbKFC)S&-;Pj6*<}X#M=}=M$itl6820W-DcQvZ@fn<@3z40C<yPc6?CLrY
z#J00l1!KdL&j9p21D1?$f%{K|g`P1pfBDDi{cSA?vx3lt;jW9tO!5x-o6?~7x3D9s
z0AM|9m`=jVzD07sjK`jM;;%k(BF)d|ve1{ZKiGnWXK9RmvAH<@hc(!Ess8^`ox&JK
zs%d2oS7;_7QDRXi#IcPJaMXCevn>*8EgWsLjM_$da=A9H8l$$$)~?K}_4ARtxb&%6
zb~c{CRxIX7Ntaq%C{Zk0w7GNPc?qAfk-QgB{E%v0DXDX+0b|u|8D5wi=yMrn5=}X@
z4|KDmZXBVy&lpZr5;YAbn*?U|9X@vdTx%C9cyPA0<KDK(Y_&|ZeKJcW6BEe~PM@o;
zKQn{sYw8outtvYHNWuB3qT}1)GiL9SrOYz;47F);0wBv!L74qlbN7E}h0Z~96Vj&s
zC$ntwk?)$5)6K<}8D8>Ta?zNG?`4_zp_N=MuyL{HDP6!|N27YCb`<9PQQun%7g2cC
zv_XjomDn#AUr#2t5y}`A%QwV^0ml@TUMa~Q&B-3%{hl6NjxDp`&wSmwEoc83Tw{Rj
zsUW+8+GT|3`(L?X(1dNuR3I^)?f$Q{nTp8!(9h2FlJAzwHpx5!?31~vWp#8x+n4CF
z%EQ*1{LWOyc9$@AAm)8FEo7)I6IB?D^{jKW>tT=#*Fd8*4+1usc&36{8)IbR-~&>7
zC|Ay#buJXa_RdT*nZlq5?{Er?nYLYGSqKq_11w)eSXsGa$Q?H{t<3Hs9>j*~BNdB;
z9vx9L+i(~eL*_L{DTS+r3;TdCG9dRgf*hukg}8jCxRstD!d3J?Hx!(4K}5|DQ9T@x
z2+E;Gfl!;B7*vw0iOMiUe<H6ZKUrMZEAcicR27E)wxpus^t8hI*7`kdX%!4cxL<H-
zvBXE_ml-Lrx7WOsmwiK_>4E8|NZ&q*(obEVCgyUThYEL>6!@rM9mfJ0&%&MaYPxQl
zi{rVfj7RwnXJWeTZJIBl(+1-#;al3Wpccq<<OvTeYlo}xmPLW`SXSI=fu)W8l||O_
z$t-i8ofOEQ$sR3l4GjlgB@%ow*=P92g?qDI$!mUGXZM*4A$}=W-EjnBe#iVG1l!?R
zk`QAqn?uw*<5IbnvJ<xE-1=x<=!cm_$lwPjRvw9}pIDz)E|+<`xGYey>?~}QE-y8d
z#HHGK%Y9m#i&$fp1%bW>#;A>Vj)Y-jE%iqs$aXMqL2qwN@^sUR-ri(?pR3OPJddXD
zpmg8|3=Xbtdt}PinJDy+Gx%EA&72SOPQK>uW8z7smhl{IUzk3J86#{tQ^vsP`!De^
zG%;YQmzmn(^_R#aaxa;S%V03m-r7xLlvU=lY*(lEdbyuIM#3k^kI4JvE6Af^S$B7e
zpU<<deojJ4Jomu<{>i4tQQm-BHKL9T(IvpN9c^E>FUXZi`5lULh*o@W@IR#cKdnn;
zvN=#t_Wg&*Y+q&0;@tdiQnMG6TPVQ?R4n^>E6cp)n~L>p+iI)4K;I~$lDB+yjeMQl
zS05wg6A#)hlFxS}_V**Ny78_~u=HhD<(#E^`&Kj^Ug|GVN1|&1u?AmTOERS-`f(Jq
zR7We9h{qnxf+7Ah0XuVhrXaGZs+n6LQmYLbG+6aH;DgzzTFA7wH|HvIdOw-+3w{$b
zQzDP@Rp|mHI*qT$E}vJIm=NP?&b5*H6N;Sb@yqd|u!yj-m_(^O%16!j2o#2E;e9zy
zbxCmscXO_VZIH|2g+s3-W_A`26Mx01!}Wfu5<5{$a11$6qOJ|sCVDF2Xt4QYVZ(@8
zDhmxOhWAAJsQi_7!dP_-T3R1i8y1@6uI70x=xiMw?WX(+YnsELJAIZB2Adgd<~$K&
z&77%K*Z&bq*aZKBMlBsm@H@-+dIkB`6HPe{QhB5zGCL@Ku*e`zZC;mOF82m_>O%Y+
z7?!p|6F|Kctqp|}bSx#X9T1s2LH_5|AHE?K(Ris=8{oR8ag#nKWi<{dz-*i@nj=w|
zP&+s{-TKH<VhMy4g;zcB6bX7!_Y>eqHwOpeFM31+iZO4hYNhEMet_RXd6f<&&>Eb^
zAbF?nXYcCyYL&00rJZdUpQxFMIT9SHS1Nf?jNGrDyios&w~c`3VUb{&av}PtN?9vN
zVC=PUzx#diW(!-Ep2u|;vdzh-rh@_l1-9%hpC3L9cYY8|J13zP|C8xykd--mZT1el
z_c54jjf46K4sYXTD4s9Uy0BT4<lb`nd^?VP8f_3qE-+e#Op$M<^};GJ@J}f{>6QY#
zO9Ojacm_#hVOy=O*}rcYLXWziBX7I4?Dw|2x&R(`@W)_YX;Y>$RTmPX%Z!YLRvxb{
zD71WS9kMxuY!Bc0YWZxk-N0x_`^uRWx{QK|Fii!ri>iFO`*Hy5u_a}Xk;}-5FWqi)
zW*q$)7SS@p2J(7*N`GdDAuyWHad7kxlkkyt`(%|qdL>e>`O3QS#sc!Iz7q*W=Uy*8
z{W{qcnVMJ>U(lYkyT0xHm5J-YCIpht-Z8gi9e}xYxQGsS2<R_dMuB?Nd=hSONsanb
zMls^nxL$z`4RgxJPL3?fB49dtgc&*qaH8GZ^4F^$CvM0QguJ}u-%<V&S!8x*iL0k$
zap6FI_u8Fr9vN9uwy~<Ma5subEMw`D_btDSm>X_<^l49WYIU;EL;fq7))9{UUhZQ4
zapuU%2%hVnw8{QUYkP9iqXL5SDqqP9?a#|@&3km!*3RBT(<j~YtEYz=pSBTNcJ6xS
znc!RJu9Yhr9K79}XHpzFMTmj*W+407yX?<ckHAVYi@Jx&G(Cn#35+p_D>^NYi`QlJ
zoQkmuP(Ne@nMMrD1TCDJG8zttv6ohZQ9&U`#r~{CUnud-KSEA+Z+K>?D!cF6&i50O
z#-9DHzOr_L9KF%{{7WkbSz^}s`gb>!l_H0~VH3>eVs?{cU6e8?NRwT2Y;|!jGRsbR
zkaw@Axi%rQpB3U8-=0}L{My@OSww`JS87vU#ztsNO}$$w_aPs@u;axyFT5iO4-<ZN
z?W5YN4Y!{^doIp@=D=T<a*muhd9-c3Hs<N8Pmm7Hi8_HJ#(?GQcWeo36Rb~hC*7zB
z?d1Q811N(G;8koOqmdw@UEp8Px>8r>;`tn7>=-$X>Ss~70?V)^nIg7AethHG-?gSU
zq=%%1s#Kv(SsC5gp-BnBO_#<ehYhZKhDMLAzQKOHaZ6d=n8ZVS<2z)Y6{<V%!UtJ}
z{;QYlUp6F&@?U*sGG7I|lpnuDe39G0d;aOFoVJXL^u`Evl$*Uh*Wcjnks3U_AiuF?
z8LOpp_r(?MfdcP^XRj<wie{Gge1G~Szrf7(r{69VId+w&b`nm0+7Aw#ZLik+{u!(T
zj**G%BGwjI1z^Uedc4qvGENwpL*tc-4eWK=P%yKJ8)cXq%;wDDLjTY~rjcQ@!YKe4
zTPj-DmtW3ZP!m%X9<!=-3z|ya8KujcIQQ>gbCte`asCeSooL%~;myA1$%$fxkC#rZ
zb%+Y94^t86zd)Jyf4Kha&6uE#tfAG7Zz{+S|FhCktu0?#lIZ5?=2x*OJIJ3od*X}O
z@cb*QY6A$y598-+Y^8eg;!}lDTA`<qFUd@7Mn_+XVcidrt>3dJC<b(W4tSBz+5u<Y
zTIc;w-;IoUfaii)9L@^@8-PN1cL*S_(Q;)h$YP-H{~uI%Tpnc~oaS+1h2*eQ187jS
z3H$;Jeq&sIW{<4<WT$}Xl6lSj&i>Sjbv&KSKgA_HL+zn@9W9xOS)CuBP)jcTd41JD
zU9KuAEHpH%J~exNW8UK9A6{4*r;_WIxQ~#x-I4b$zlcFQ?VDe&WsRE4gQs6nu1hJ}
zufHpGP#_M6e5x%q73mXPg|1#fTw$WT6`d5P?IQ1f_UW(WAG(B<dEGI=2EM%mFCZE=
z*>aH!Jh#SrXR3FocjRe?Be};BwP}5m_cN__AKwEM0=?BMv)^0vvUZ!n_$1zA^Tvse
zU;xlzNR9de?cx3`BSQW+l;9`;ypt~9;hhY)R2p7Ut1NnxZB#buaLw0O?G~<cvUlY9
zM5!BZZVy;>c<`;y`?8A{<g3zj7QI>7QHdKy+TUKg?!qSl_D+@_4tAU%3+^fZ%Bw4)
znCtb-uu$?5^56?$(TM-}dtE<GbuWMX&*Z!0$183}#C7Kn#jC=FEL+R)NYJ+!>A(0F
z@_1Clv*qd&BHy2R)Lx9d(>Eb^N>{U|;W-HJ!d=YN8BV~zDKlUI07yh={>&F-3oZ}T
zz$`F#Ukn%ozruRg6YfIQr9S!6`qg6*UK6MQ`R=Z(U)j-6FEqCmxm^7Cm28FdZ+H~P
zkGo4Uklo|2{_;v;Y&!GTz+~%4|0F-}tE<UhfB$S{@-iYCsgAa-A9(Y%$0ZHO3&o+u
zG1~n5<asi4Y3~8J7E^I{;l@B%J`rZavp>R~*lyrA<0&=TE%X|X63etmfm9C^2dISr
z=gKID8p9U+`7rNe_fla1<cG5z_B2)cnA@%F-m9)EoBp1B^-N`9Q+AMC5f-WmD@sV%
z*i(CE$wJ=X{(qzFrk8Ghb$4M=LGq5{i<#~YgCkel6Edrp{r>I0E<Ki3#4c2yI2AG!
zFO0HvURyfJ6m9OURM^^)Urc?KpV6ArEtDu@1r8iufZj{cQ;SyG6gXGdqWc$<s+)HA
zv?P~&y6=Uu<ZCNe1?!p@3?FQ&Nt3(q-8`0Pv(j^RCVU>4?%8n=+ocP9dK)+{hCb!M
zV6(9LINImg9V^K*`W6lhQ1+p?PYd2PMm_~%nEVENVZLD9zV|fw;J3W)<L-a_)%M2I
zo6|H2wOM5=f4sAE{Mfl?&)lrZs?04<&b0IhCjWD>Ehgccr><W;(Y@e7?+2YLj;vye
zz9sLxaVY2C9P&hc4PP3c6C_Xj6eS?L)2|J5kylq{)#q2P-#y?N!QM1@iM*}Tx2{K7
z-GlYb_qTR8RD)ho;BODs9;(WtY8tpx%s3(lPBZ2vW5&XP>P0tRK~=htnd5INj;V46
z?_inZV#edvS#ma^<~wrtRKs9%mMTLR5~?eVkDsVZPYBhJ-wdno-ufY{l-Uq*Wy{7$
zkDSa!&i*6yTaGViOmE7o{?~S)2376%XMVTs;|qPS4U%w3c09X3F*wHE!JZosF69@+
zP4xFM-YzbE`|<Toe9l16Q$<-L$q5YP_}H)g*&Ws;q;t)SkD~?kpl9*yzs>7e+o9is
zCx<DTG3`cDeu5aqUNZ8J77vo+*TEXbuQ}p2CG2^lK;2_rpZ`MX@fRj`9#~P)TbejF
z+->h}_-0RYbbK?iMBfe{-IdcCLY5>3^ZX16Yk%6ccU5h7eMYd{7vsGuJ#kBSN@2{p
zlkc%cpGhyO&FY+3lGJ+s@JfE1<&wU~KGuXaE}B5aUgGcv;Y&jg{5CpU8y%CnJQIUE
zM!@0l6neREIP26j90zb7!+dMDZ}vwEEo%c^rNAw~6!Sp5QWXfT3(mjBzflxS(Ui!{
z2wbB<=HCKG^i8UpPC)T632Q90`*(fplj83bSg@#FP*62d6XWCMHypLBy)4u}OSo`U
zQ&13HN&Z1Pm!?dwU1}u^+`8gGePqnWF_d-saQ9G_WrDcnBduJ&<%aOig5_<@2S1bl
zCWqsv%A~xgvb~(al11Sm@iC3NBbOGZ){Lyv9XnOIr6f-wB)vaQsr%`}tuC?5>4CS_
zE(+Dw9l8AYjgp%EgKHfcgSU|{45&RbP(%<~^TI`Inwt;Jer&;IO;J%i=Uc2KUSb))
z=Imn3#PIq*axpIA0OGJ1LJ;rpk1V)P9j`e$6jERG_E&|Dyue_oBb@uq|GDHsYn-1@
zvc!3i{MfCod3#krL_a6`-r==QqKL#8xm*7XRH71>+y6S$_6Vyz<W${H2NRZ6e6ci`
z%gD(4Xgr`U`MU=RE0W##zF}v~ZOO;D<27r;10qim*3T_l%=IhnCI5OfgM4&m3RUod
z#g!`x{Au6cwp78|tsK5#(lzRwpSfByb2ApLubHWXXo9jS2(Ue<MGPno&kBT1UKXfI
zZ*Btp6Y#}_bZn_2e<HuFuXNXNU4%ZN3CVk&4kr)aB(IXkFZqZ9&`;x{*MGcwKQK6Z
zV$-yxAn4eJq}a|CyH;L&Y#*|y_n!GT`6{}Bo}EIDzWzQA?g^Lu#-pFv@%7)#+{eh=
z?H9wkq=x)QcCFp~6|$};vp*xxemd-C7l3Y~=emksdH2KHIl72%KHMfUuvZQ3_*3n+
zsN=$g-4)r-r{=-@W5&$i=;wndO{G&iTOK9Vz2vETsP6+5y@|#__3Y0UBB<lq!A3ah
zO?4N;4BsD4m2rRw%2Jr|i~yht7us3?3KQ4QaUi_*P}rC(NQVstA{S>1QEZSrBFX!e
zf0G|&FSyO085u|fE1n;3X-zL|&QN7VD}%BvJagkK%61oC-g@%piKAN^TLXeq)QXC(
z1vZ}Qr7NCk81HV~edf$dz2&@#n$>IK)q3XZL9r@t|0oz3>mhB(e=S8}T=MdTou|p&
z!^)6|hK!bo;J~m<ZBdX<cIgXn6L$0$H~L%l99og44R;E<aP3h=IQ#LgXIHOX+%SFW
zK>NZqz0(o-@3!rb$T6O7!Jd&VaA!SyL&pq(5j1ZX%#kJxQ6<4VeoRe5ob0IZGF1k2
zyv=h8RXu}|;LF@LNfW2`^KByU9lf!kd9)=fG#&G#Hly!QS44gMcvt+QuH@P@?!vV5
zUtUYs#I)vD#fPda1+0dy#~vH&TtBvYX?df9wYpug@qVwoG{ca{ipVbSx$@|4^0}S$
zktvhe9nm4tP!%}BeZ|4!32!Vz78?wG-6>7e;%5g`HCNLsx{8OpbJ`laqZ|*eeRTVV
z-K(<`6EemMvMs+l<>P@ewyL@_3}Nt`Tqc=l?$6q6mIw7xvso`jlPP1spE!TQSQRD=
z{DoOYh9P3Kp0O^{P-li<<qS13n9-a94h}rLwT9ng+^~U!L@kzSF30Ny+N$RMHO2X=
zjNC$Dd}7l{%ZjEj_wX2fOa9qwcV8qL(jA{)<>eu+$trGc8cdM9ZlAZLuW!0%TTKa9
z#65EGCuIAaA0gm31oWk<WG*2cIVuO6l=mO3($pk`rX*I6?%a86tZ`)tt0B9q!Pm{M
zq1!JvJ*W4ux56VOgOl$k_xyGH!HchK*}6=r809)iGnL*!73nhMkQ5u6G``@`$O>jz
z?2o&5{u0U%+HciN>s(jX7ZG1Rct6ZZ5EemRRpj<Gj$eXZ55mlB_AXOPyae|#sKAaU
zlVNKZ@njAyCzXo<L5`x(B*ViWrevhmFtzp}A@M;O*%4X1qx<suq<#YAiaZaShdv;8
zxny>U2FOEdS<cp{bs4SM;meSo7aN-^)2HhLQpwT$jA9)JtsE+p&KytX4NJEF?G^kL
z`E8|7S8mNmm@_E(82@3l!5KQ3I7bA77K8Q{9=rno0D7^rAvla8Yk0ICP$g4qUfln{
zLSsj382`EQIeA&pcRXQ1Ok~P+u47n;i;k}sg~xh&UfYyjHSBtX>8}e?CQkC>Q9*FI
zldq<WC34g&eN|gnZR8i^vYGdK1t%gZR&UO&IrkGQ&@q{l?jCIYY-M`iC;rHu>7NoA
zS#W|=hW3Q@N#jdSJy`81%1DTg^*;*=V0$yHi5IC8Y_!l=7uv{lEkx-?hp^G)4D0c%
zCA(XaQa!u`@N6>IoUnMEpI5j}sA^lgB4&C~)&itI7}XFH*Blui1oo6D(*46#UXiZ0
z=7PU}7zwP6dc<T)Ryy-pIFpEdZE`3bD0K2M8ju#p^5GkwaM8g^pDA}t?UwZMRdoj6
z=(LDz=MyJ#JA4J$<(8Y>&<e8Bh3}Vl@`&HAS9%!)^V$2qOxnZq47mEiG+|(dUK#mY
zcW!F2jDsdO6H8|5mGVIH@0l_=@;l14q5M6|fpfI&tSXq-!cSCyya%`MXn4k8mTGul
z9SBYcQF;xe#VdBx-YVVjWVVN_BmL6$9QuIYo<1<vIQq@dPJf*@moJXr9_p@tZu3!O
zeqNbWsHmxmY0xyj+rBp5o%wrI1<b~uJ3^inA}8*2Oat%B8?PdzB1j%>5kHZV#w{vA
z(r;0to-LWIc&Gitt<x8d;?bJf8xTLktU78(bKaj|EbKuB3~_5<FcP<8;ESgv;IQ*t
zMQ8Lbb2xlaQ%k&$Jkh%>(Xr;9C#0s?EvR%I`7__+&@+?P+}D2nmeis{Ya*q>SnvE;
zI9(;_N0FJET9y6@wL>xeCC>KbrxNmUt6zxRBjiDj{Kj`jY+O;d71{sbJHl2S5M4c-
z&|AWF9rc1s7^#>dNahqg4+*ClQziyO;@-fV5(daSAh?Xe35ZVSg!zXTYW#J3AmZbK
zGqR%P-itfBj|xuhLgwUJ*QWRFnBuTpy}zbV|KMi`^BnJpK);x>kDhM&hV$Jf+nLi@
z93<hHF~~Hy!-xf+Zv`s@jKp~f@M?Wt0&Fy+5CnC34bFsAsmx&I>wKdMbWLL&X@jHH
zD<(I=e9zgwtyU;(|1^L7JIL&(iOx1d)6DYD#tnXMi<uH#p21g}`{4ANm}dLey8B!O
z>WYq}Fh`<t_!{TU4Ibnm`L$zh_;PYAB(){cO@!lR_7m`}7jTa~Rk;EZVP1stC9n!_
zjw`9=k(@FconK9r>wJL&D&g2Rh4ar(&+Ho?LSL*Uf8xuB?U2S@{vPrJtH!D_>Q1&;
zS;;*e-9}wShUh{=U~Z_lI7DfqtVq|4#<?W-3Wk7%UcZ0C!h#Wflsv=<-NHp99%|Hm
z|0`^BdBlkRs=&^Uu(#pLED3&6QblZlw>D5L&?1Yz3W>T!ea6ahRJg;)MSp{ScoqhV
zYh$ZKWk5LGXhMKqg9*LBqJQVS5q=<LO68b7I4M};He3~z9;W|j4f%_pa_iVwOu?8f
zt8J3JSWbR1a=*@lyZ!*@jQd!QA$wpU>N-pw;VeGCWo!22YmW41vmXZ@#B(4fpVQ`}
zsgHqs_4u!d1<!oLy*c=vS`omzaWG*Pz^Q&Npp4dKKTap4q-mXXWwujT$BQ45zm?QY
zaQn$*@;|7}DvkV6usn2qNqDTEeM-GFD{i1ZLgLYgl6OUWi`P})yO5v{N2jTM4c*Qw
zy7>+*SID(?Q&0V!;yg3xK=`-WkQ+HC!*^%vb1OwlRtDB5jRyM~x~`$uG|ITex2El#
z$I4(K0IC7s|H`}$dg8v+|LXa$a#$nKhtlqUN#Z)zN|}+jHBM3z=kz$KCx1k}c4>g1
zDtTdax?xDgOTE}XQ5r3iNF17~#Rc7-3n?w~y!0okdc*q)+#F{5JqdX)m)yiz6x5=Q
zT$bJGJ8^e#O6eDqR;<{%#=&V&^caXqz5*Ov%sfS%TYm`Gv}14#n&Vrs!6Q_5RpbBv
zufWBJT0$c>#Y-yVxnYe7<Xw+o^QMo!Cw>OBxObswMFykq>dc+STRj;OGI5-=Bu<#q
z<I|18e>8}8w-1C36o_mqqsfo?;nwHK#mw7>$-~?&XsNP>`TT?0zE4_0l~H9wQKRK9
zj>G<&;k=R=aLQj`XA#_5isvTSAQiwEBLtvKmorowh0bkSb83dw6q4}361nlZ3C3UL
z<ku^&3!d37jEGw>xqNX|o?7V@z=wXT!v?#^Du3^)?Hi>rW%=<doP_5DWh!6d>UPrH
zgXH|7&MRD)RW!ZnkItCLg5>H54w_og(k$1JGk*<8Gm?A%H8Yf-L!L6Ym!ul8ahIWB
z6i{bXO%qR46B{f{r3^aR;VK6nT}xqu5|YPI*st536I1YEckB{%oglPNzraPsm-$5*
z@^yT7w+-By?@)x}vxBv<ZK%%CE-Zd^#BxsRlwpyZKoH{P8Y}Sd4pjt%E0yFAPF#eq
z(U~P@?-H*vnyBe*%IDZvrWH8dc7z(*n@YR*@DP^9$&m|xXtczu3lm2+HYDd(%EDV+
z9Uaq()6C7$n-hZmSze}l5!xdS=t2<(B3fWXwOQpAtheIXS|8hRKoAu!{Ok;82XgIq
za;UIJKIFGeX<3SmAP<fk#&awt#ZA(OOBK_qnj$6&fUxDmP&1zUkaQL$_IWJeZ?_$+
zj`35}B<#Z}G!112Rd6Ipx-TzXWt@NTR-wz7XdCCM-B?gSZ1EFg$nz*<%m%bo*T)a(
zOy`pCnd0^?9KU**%Il`Mr7ANm)i8&@(p^|ckU*R?_wZymHcXg;hjvnxaZXfrSa9%_
zHQhz}j4#?x3UmvC+Y!6!bfHV=nr&YryPVugt=uuWN8D#(ot&u5g;iDLH>*1HA{L{e
znjbi6>orXdJIUvdJ3DRLhZ^msrw@!2IdDh4ps=HB<hKC(T58&t_MVBqjU-CJiE<ka
zb4nE>-#Akxv>Zs*SRua!gM+a`&u7+@)rX7I!yO8MF>AdFV$uwQ@2h*yC-o=j(_>`S
zj-0R%H*KLb)({zb9O+Z}LDtW<mlgIzbrtZ;fn>)0n?fVE^^j|vB_{)$cdX2=Y8i-I
z#0qduI4#Lai;wkwotB-|PTVq!rgkajWT!%vvL=;>=4?&Swnkv-|5Ah+Xq#68s?~O#
zhbB@aKEEL|B)Fv@zoj%f!I1KC`$@iTAfyE@p&0jeU5Ab$hqTdk0VAh1RT&AXH=Uf5
znv%t;uvm#&6NmK4u7Nf$>2+DHulDz^N>mj_kD}Jv@4+4VT6-9s`7Mj<NNlrj{f7KA
zmVYUrW@@6NVjqmBjXx(&$ga?e!wcGQY~6;M|04K@nq<cKrI(%NbPUl87z`XJ80noX
zh&$?4Issze0l&h3&Wwx2;V#IWY2g;D68Kq45_`S6-R&mxQ_^<?u3r$4P#vbS^ck{{
zS~x?Nb6*j<u41Khaxfr@s4Wa)NZea8!yRMJd-Hu3$v1F#7vsX=AnWgu0ToqW)}Qd<
zI)Tqlhwu9BH!b!H<bdTMa|FHa0`ZI;YFx+CZlc4%DC1ljrtuGf2`-|GHn^t{)L|}v
z`H*wKC*+q<sU6c_|7<#RXHATkC@G*Q$*F|=L4bVv!=$1_d3mC97fJ{yLT2%cPr526
z&d&^yhoFQ*I&wDL+@7q0(yhEol#O1z7I`KlFs^kpv$??9o?HiP8|)uZx+r0+#?b-2
z8oia*`yF|}f}{I^Y}(ULm2|XTjJ=>2Jzqih4e*M8K37oC1C!&HfiZVb<~LobIqwwg
z7E@UV`$-5C#cpHl4NBQiQ&;Ui`~?5v7<b*W!!mc*b$z4e(hRq-$cR)J`w6Vh%h$&G
ztK-<I<PYwZ^1_&m*yfT@ZQhgVGBSvKMwVKiO6>KCuE}^T#YgY;4fkicHsta4I*HJ`
zX+fom?-;<>*$RXF+<6x1lP;c8L%;}=O|IuI3Th6GY6)G*=JJqYMs<E`%)W(~&j>Tg
z>~6L_YZ~UsU=jx3n}byYB*G?>ahC+Nf!>EFOkDEJc&4Y@dOJB_@&`o`!GR)N&9;vW
z^wBAjUH!OZ_n0~P?Qo1v@9gTvVlk~NRHeTm@f+5WI*|ht)$n{Q;~cqUgU6NGpnya-
zZ-Ikz%-~A|SsbK_7KX(jhJ!K=&hZ{amux(wVp~S}1I3*{5voF+Xc^f{4&$;E?k0MV
z#fKU-5593^8TYp-$&FRVd~Sk4&H0uxPF64#K~Q;>DlB2Mm;SMl_V7tpXBMAaG*M9g
z>&+iC^6OoR2%XT@-rA;U>EY%DU5y*yIWgP>p5Q0h-bh^@dF;c)B3^}r%jocJi!KoJ
z#z*BmTPx?=D7Gdpjd}3%V=g(x%Rk>aCH9FFcu6?6wmGQ<kFPDvwzB0btgZ4L3zy|6
z{U1C_{x;>QwYFe?eh{5NF9+EO6XWdI`3X}<6AX{F#yZ!{zQwF(wa?#pOu^6*1J86M
z9XCDjEFGp0+LNFo7vDX?tXFtTocxs%F5CdwwZSv9^w@N*oxrJF!eN%~Ie6g7+CpK$
zJKv*-EzDnn8!Ll7-37Mj>(IKHmj=4e^o$QX$~`nT7VHhRjT3`c1{a{X*T2H}firKc
zFX8N)*mNsA%Q)6X?V(dvmgA}%4^}}J4PVpi2kjdC00lTb|K*eW$=_#x|Cl@cuYg~Z
z%sHG|DHjp8-nq{l+J6x-_q}@f%8uWC!+vT<&L8|3>%<tIdH=bAZX0DFoWP4__B;6q
zqu?BJ@?c7I)c|?%>+Z6d*Jo}_Y(~_P1+%i*o6I4w7w!;&J+POlAf?h7pcfknPw_%#
zrqP1M{4d*K(Tz!wIn=1~<cco*p*HWYSj2-OW#{)^=Cye}jY-->XFruEk6pR<$i5|&
zU6#_Jjx|r-y7t^B%-c;79=42Fx3<>>{NBi5TfUd%>NXF4TSSP`tJ1?&V8gOpThpM6
z9rBQ_Ufi1)v-8Py<Ji{@v(K{Az^=6H)MJjE!Ovm>9;8RhtrbJXVa}F=3i1%SalVu4
zQkr2Ro(DMfFoZOQRjbH>K)vMJhzj(*qh70UWs@r#Ya^$XuwFVJf+E9(_SWVWnm#K#
z<kR(I65(#!DB;QTuN*pse%{Ue-QGeFZDsBmME*wJvyv;k9m&5h4aB*yZMGwZz)S4J
z;S@5g1w<wh%<5u9dBXF_B9>*uV_jCvIx}y8A7Jv1?#P-v@i1!Va66Yz@Y(@L2kVDD
zK%@AE+SflmkvH}Z*)ighl)JgDx=?K|u>ncLUL-TGEMi6IMCRt}H|?K%<I^K$xvrU?
zeuKR4F>ePIrYKYFm`^C%NKt9Y&c+3q39W&p!YGc@8#5t=40B)_W)6Dt+)(?ex)LOQ
z>RFImF}t6g!iqNDH&2%s5(qCECNA?41~Q5tGC52Uz{o8wn`rz~@W;3Uo)mMb_++Or
zKFjwhCTye(Yb$Mth)WQ%&X(pvcl&<1VCKijGOoWvt%OT#sEZBqI;J+~*td9c2wO?Y
z+KERNW_o)Nf<?KQb69FNo79p|?0J3{Vh}=sSZKqlh>1#&H-C%joj-pN*5(;*#bg0>
zu0fU?yi{GTfe<pX<b}!co$JXLoKW7FhYtG)Dr=S_;0=ERVL@GP4f0d>&|^ZOwWV)P
zfe}fbhD$vHomLR@r~;{2jtPO1e<ut?dd7C31}_^62ipcOh-cs7-UTzm9Qfg>+*0nI
z$*X@ya2x?#wyeMn=vVYTXdzJWBT41mtTT;P7BW$!HLE2t#>T^kj|5@F()D2u!EmpS
zm3PbyiU-YRo!KrRE6^ex*L07<h!aZMheMjH6`Nc^5k3_UE)iPM%4y-S{^GR{rYq`f
z?HeTy$hI(Vba`W;H&?d#2lAI+n{3@}>!pq;;?0+Dp(9*Y2!Mp_Eh6LJ-*Ye{Zz`HE
zjI?%+9?3}SuU(tIm56`wsyJ2@X@eLqPfucQ)I*Ni3%C!Mzg^eJKrALE9XxFEPs(8s
zSVGv{WjQhcZ}TzyP?BQp4HiIxife*<MgH_)Ja&BaaDoNbGYTHOyKd>)Z5IxmeH87l
z=zXv@E4jqOVAlwbCh-jW*r}1rTQ(}=G5-wn<T$gP**V8gR#<U1kuQ=bJ9zR)2PR`l
zei|x8Q76l{Ec?XvBl0>-e%>#A%p<~vO=LYvbfNu0HsXX>Kni2_J?0yrm+>3|%maH#
zAxdfEf<jaV1(Kpz3m6xdwUmp1T$!M96ajy}fn?<Dl4f$Csj`H}wABwqyN17wp3e05
zv9ey`#X;6WsbSS%NP1|Sm#7)7Z}#9?yNto>j)*aGwY$ff#pcDXc+m73u~4hZ)_90g
zECs=_fuZo6Uh>1&cUpGKh0$psD|2?YMIF=$*>rVd;u0RUdxpOQJLAC-x@ZNy!Sds#
zHWjASwh#W+3_o?1N~#nMV48(_r@Gow{|pC9bH0JRGi!EkwKdzCeSAaw;LYVh;R()e
z?ipE;x%}A1a5%?pWl<z@v|uneyx!662T(q83bV4a;Yxzt*_PJ6YAH8Sru0ix^e5)Q
z#7IB+6#1`L7F${Thv5W|=X`GFMK@1{SYsgKPK7^#xQLh3DG2op_4W`nR?R$5-rsN;
zjibCop^Yl_eezB6gLuPo9~BbexVD|$ZT>RrKPF!RDM3X`FyxePyyc+$y!vWTA7<aE
zXQ<=-E-pOH&J1Tn^Ov37-Crt0qNw3^!XiiPsA`LtUaoIHxH(9l40={1W;AZ|H_sP2
zn7i7AcK4;$Ae+VYpWCx;inNAo)cPKoNs8E>n*4JcQ4u;#9wqn8eC6t)5QW9Wp=k6O
zIzo7catebFkO#<bFKlHV8>zvv56<3XJ($B80gs)-esXv?WMHvpO5G-$%?Axg4uSGO
zm<^Hg3;E7xiw6$w`dh>2CI$rTd9roj_0P`i(R(K3?cF(I>B6m&@=)f^(=VPa&tjY(
z86a<d{_W27Um?5SzFR7=b`0|L93r>A^zQ0yXZC(G(0i<FIXUB|6o%Wfh#TwnP4rW|
zq?p~!dVHQkjXV1w1(q0#hby1Cpq|gta|IF>_i^h8@{hk}d637htb5eY>d=y7jjBiG
zIh-1(Fp)#}4@p)|c8wCMOv-!u;DO&RPo8C3c=`RXe;bs`qSCt43eT;XdNP9a8NCkV
z4+8@Gh{en{7p14cSSuNzXvX%Pp0#2<1@?tAG4w4s5XV#$L#bvG*|_)zWSB}LDp-t<
z19Nh~!&gQRVB%#x#n*n_x_RdP%^Y|{wL6lm{9yHDUHj#)Paew3TT@x1cjd)CaejA2
z337)WtI!(*9sj;bKC@_SLtm65m+MgF<tXC>lr4SMj_)N_roZ{x?W>Ddzxw=l>nj_A
zJ#C$RyPNADLqX8QBi1f|n|zKWzi;vN^>g!<i6THB#q3RX7uY}jA1fIkAIwZ9FNmf8
zZy$)LD97-pbjJS>ere|Die>e=G12L{+$g=r&aQ=0Yf@J3w_Tb;rD??0+>N*3+BeXC
z$-jK?!1sjNo{5X9kifvSj1pCvAV|dh58J#iJ$K9W^cEX;nKUtTU7+WuWDcqCz<z>T
z&3cH1tX?Mt?WdvS=s%8aT^z0JZ*E>4Ug992eHH*U?H}MXs%J1))6$It91HYVkcrS}
z&Z1%jJc=Pm6CDl=<{x<~A=fUXWa=|N^PeA0Sa9#7FK4<$I|7AH!4g61XDB7yvN!gT
znb)6ua#vjh^JHU?2M6gL61*Z$3Ea1~Cuyq|zVpbk(`x;rrF<J_akM_v|G*D0*H;=6
z-@os~@&$4DIt-kn*&^05Q?7;+YWU;=E-a`j)^yD!HM#?78Xs^4;pg%+Wqy&SAUA{j
z%0D(PICmj(<)kDC$rMg%f_P*+gAo--<`+k>+~Omo)=YWo(27mO3pIXa{v6hjhkpW>
z(@Fk^ytCxpPHVoO!rH^v2mOfxtv-p}&yDkuvaDRw)|A$<!I)T9|Jheq+o0Zqc!0Ws
zCVFr`B`BTUpva?5i!%i7d&9Rhxaiz4&ql@s!rB(s-s|V1lyWPJ<Rx<JxRYmQ-l|dg
z4@E}i=+xaJUce*UYqBFEmq--Zi@w;gcuMP}wXc)#SRu@($PdWyV+(w(JZz*&zvR&a
z${&B<^How*!%`$zv*zWjgm_y=ac6nf)yYZn=8A%_ga;?Czc-b(-V<*rm?h1gV>v-A
z&`-x95XJYfOrR}`FMy)t7IAQ+mW!2{ixVIrCx^u|gXRT7J2tX1w{s<*a#AY=s9W^@
znLA2GeX1RBezjK3EZ0Pk(wTb#jU~Zi5tcrJWuG4>p0acI<j<&Y{dVFx#5ifqO{w%0
zX`|zeHcpy7XpZk0!gmTgP_uuqcaQfDC_{2N4++LF!@If|0aPvmF|ox>ubAJP`EnD-
z9=Yrz{~|Ys58K;W*;kTpQGzB0px#+)Re-?B&cfm#|MAJ|i*21;-C;tP*+XudDZJ=O
z>>_wG_eh_#jT}!GC6c2GBAb%?<mcoM=zVlg%yRSO%RM}1Zq1M{yomyqKH?$LMaSZj
z(@Y4p@*SFIaQ%sR&T1?q4URx0$4ddK+dGdOd_j%Wq$Oa7(upcFC>YU7vF@<NGuNfg
z?aO^^nT~B$bro_~XXjsZU)r<vJZPTOn0pahtesq1eH0<kmXlW%=2XaCY&_4$T(V(C
zaw5ZoHOzNJ&Lfat*Zf#*UL3A24*BVqwO$)E&aQ>lutsb5a9@s=x4iR{&{N8>lSKK*
zO4JL;x7+<jLO3o(HUg=bii0TfPu5b<4+DwXX*Z#smK!rE00<)r%MCAzc+NDA{)wWc
zb_+?*j=|$uZ}}pwv#TXj`c&b&Hsqi~iifk6Z%kq|BAR0?j_!J;BE^C0=vt{&F)Ko~
zB%f5al#ai{G8gy;I~_Z*_Ho95o3E{ftwts%_kBbj9U3|GITGzosSpW#gQ(+N;1jrt
zhqWJK7wSC9C-lrjh}?_?w#G##$Vr!Uu)c&eXAE3Q2kNd6cmZAp&ry+r-wtIsQ|$u(
zoVDNPRr2!#aUM<+(A>T4=hKBQbeY?D^Bf#(mw4Hu>*W0|GPO(D<?bN*8NKtCYrOmC
z&!6<*XOQn^6nTopwu@vA1YsjeMxNstC?K7guI8{p*!F*uUos*E%1}gpea9lyQlJhD
z6s1{_JzA}`o!~8Wg5&1*;%gRKo^zf!)ruw5H?P$YVX&@v1~_$?(Fi#71#R&;1~_JE
zI?jL_t`r*a>>Q|pFBhR(;u`kwT5|KUgRENei<XKYZzOrPf2HF(3#Z1cmNUc6GqJln
z`i?ZDA8aNjN%Az}g*3fNep!~>^b2ZFPC~oM!-uY~+{0}qzkhz`7ceh?%$@_AA7tfF
z90TT)8#mQ((Bf6Q))@rAeR(>Q&Sf7uv$77Z+@G3cy=>*>rAH-8q{0J8-Cnc%95*1i
zU`1|<TSi2#(;Mv#9o+-OXrrUI{F${Ica0aHAXb?l3krU)pe(6aA2ZsyIwRR#5gy^`
z?XWK>fx_-9FdHre+jwHjm~d-qLQ}Cumy9CB5^g>D>w7!ka-oP@N!sM~7AtzL>Y_WL
zFj+{fm^t}NYs0Shk=|7tStRFjMrX~o_GT6lDR^Cn?cWc2%c&^^Y<ST4A0I|HE#xKx
zs8weF@I(I;*|Km4x3YEDSf$b%iJt9Skrx}7Eaf}sdNzz75~QZ1-2R!wM>~2BH>4g4
zB$nSN2k&)u99j58X>!xA;10CQP9e^asUKWgQ@0!yT(xN?Z(rN_1&}J1?+W-u12%A{
zckoSCprhBxktsE9iOZ<19pHZrOSAG8`JeUKsjJrAERTpKpZws;wa<>OoFR*bOHz2N
zdZ&n~dry5(U9#zeM-TX`N+#c9ee%lATQ)TlU6bYsxCLw0NWROM0h{>IcBh`2j*k&x
zEI?RcmcS8+k%?gfpoF<yv5GMx3GyP-m-2XNz6Q4mhrWDAt!PZ{q|BW>u2Y8B@oSf5
zxT%ou7UFh>v%^eRbwZHTEjfG<u}{~*x4#~@xnSDWL#@;;_$YN2bZ3~IAQM?6<0$1D
z=x8H0Jv9z%RO1qFev^WV6p)F{@Os!g_zhqn5sSP;F0^D=IR}&XcQqvx{CVL?_t?do
zmK27lP|TIOZY!zV!l)<|_WaC&x}lzz^BQ&zFqSVrza4oItG@kYu}5*trc3gms^yz2
ztC0Of-^z%vqIXe~E=J&FHBLJ2eb2g;{CZE%*_C8gTH1p0R<Pkdz?BAU7=-1fy6+6I
z6KrxC4T%l-P+*zUXH^`iFlTGV$QzC0Vy2x%LKnH$&O0QY<6uv4cdJ9U5Gl2jV~a##
zU)@>a<&c!VyP*u+NuE6Af|RFbwnRB`93wSp27^@z!<lzVtDTt`xknI>#y(5V-dMU7
z@bmx<p%yXs!2LD2q%&nP{IT;PhLf`#yo*zw5njYsqLQ&-5sw+sP==07tiN@lI8^PR
zaW9sIg*ayqzp%2Kxu-s(!&?=o2_jv7-2b~?S0YYFM6REQb9TnBjoww??79eeo@K*x
zxW1-7--s>>R`~Pr{W(xg8l4Ltj3W+=1c8o)A-={E2suoBQ~5_OSs^78$8~B$10ybI
zB$lTP^L8thgwryF_-lemfAs*_N#5%`=;EQ$BycQ)(=Ta$MB?WR{sL!E-0U5Qs~sl)
z(4UH@157Zd(T*j+`&)EDfPI8vuVw9MU3Pg**M^}uEiY4UaJ!tSDs|9iH%}cc9Xp!g
z?O!x8nEu?l==kKWsz_q$g&m)*?jI%ZW(Iiilf%atPq^oJ#Ast5?Ct2@+GLfNoJPJG
zq+UDRh~piZy#W3ZfL#CJyoZrubO>A=CKwujX-BOl$aR~*?Fpj1ufOmK*UFOWto-C8
zV)-}w9%Lmph7A+5tOFro51JMQE@{di@9TxnKwh)679qeXiTDHQ#E+{n#=QQZC4OZd
zu5*a6$J1?2j`s9Gh?66gj*vwNdG4>>YG+CQ&F2^qHp#AVJ-;lMe8$#Snr-3dUE&oF
zkGtaDtWX5hFF3oRKRb343MQsz2Hz~c)8r|J4#}+mwxvU&V{^{lWAf0MCv*-DydsN4
zG+a{ZFV68i`!SKQQu*%fclQ51SxBBMtRV2d5%rwmb)W}E(p-p9Ns4x#5jj{|Dr-P(
z2M*-1*O3?A8HZ<=vSX{iU25ek&U6&Ws-=2+CuINOsEBE69v5Aha}^TDx{G3@y-2oy
z6UgK6iWFz>XJrLTi$b=)PefmIC9hs=sY9_4Q>Ot-ml&JP1k{uVM(}+0#Bq(2s4-De
ztG4-dIG1&4WUQo_So_GkyRQCu($kIS_Vmd3RB`jnJ3KfmDOp`#p^Io(dWje*lsMSG
zf8fMRyH3NZO30Uq?N1d)9*fcO{LB~iuWL$7L$IF<ved(#t{u|>=0BBS6>3vNj-&V?
zV8g<Z1~%qz`joWss%)m+hRyGGrUmjG)BFtX??tJSCGMQ??&%f!rK^|Zq;K^Pt?n2t
zPVd=RQAl{bw`)((Pqpy@GPmU5<;+l9g($;2l>A_<uKf9?l%gRrsdN<3M&($Lsffy9
z`0;RT>heO9Je1$)`*SonlTdhqk>etNr(={DZp+BOKB)+jA<31VmCnlD?T|;)4%x!W
zrTM{uswDjJ+A(4i>06%MbO+LD;tO>C<l@gpX0Wlv^o7s%rmO)Ufb02r4xT4EBcfp~
z?b|QV)NRR(D~IP#W_h@}xVdL)G<LQ&eq96SH_JUG3`cEo#2alRM^oJryjOL0E~)Yp
z^5X(ywAwFjJ@So{E2Z<X+4an5#spx3(wSvM1WsIV$pwW7pjW&r4HLK&%W9a>`^ewj
zn`+16HPI-(*x7KTWkq4aw`WNq_sjBxJYwTVTf(%X1vz5x=$;*G6hj#si@l?YG9Ozs
z^~TH%zkuPmDC0a@8R(qNJV-se2s6CcXjCl-fzgRSU4vWx5ay<<_3$d5naz`la>%^a
z@ubWYkrUb69H#V^$(Ck>$latV13p6SAdjPuMw?q1SF_!m$peSZglpry1nC#*^126h
ztytlj>gYM`mx?lA3>s{I2XbID*d8Mh?li!Kt%=_$R@csD7`(~yaK=IGW@u(VIK|3q
z+qSqkBq-O}zBM7hkU93^UdyO}IIp0b^N2@G&g?_Msfou{JRPksU5p|M++E#Jh<Mk>
zt-UA;F*@w+xC)EuOB)ZPdz3uKW@j1q85_*NLpU;wUzjD}7E85?3wz?ujQbmVON1Ox
zeqaqJHLEX1Q*c~{yxseV8*yKs>GI|Z?cLZhAy0n#!y*ZpK)#Fykcgt6E3<#G+TnLo
z&m>@gm5tiY{dOL>TJx}uMwMCZo0e`r$*wAG*y^YVDNR%!3q&m`RV;%%PQa}#ol1$1
zEF)gMN#4DKY;CUI>R+0a|J3t$8$>f<P7|A+9(7e&>}lHaJ_>z(y(iqOZ1&CU0@iv)
zA;iBiyUW?;*xxkfFcBDqK)?ZrwSJ=G!V{;K@ANMJB}l2=#u|LbTIiTZe$=z<Tf`<N
ze_j0ETQ^_P=m%$W7p_f=adog;^UW_4%z!TPvoq)u_=wqW$Qq_A_}GK8sp$k1{BG+0
zcd#mMW4VA~nXW_R59B+K_BC+>BEGocnOe}UiwN-XPmK^D!g(dbCjHBq|J)rb^6}#%
zpJ$%_XhD!t{ne8rXd4RQ!2JL)tHSDJWI&Y;%?Ct098Z8{9M=@8@jx^F0$Y1wxZ}Tq
z3|>4OWu|I|)p?9O={~sVsj`UV6Qk>+<9mmR1pl5Fa?%&M=Lb22`k}!He(dq~Ag{p^
zBzbe@ws5F<bN66zKCzno<!*G~<yGrt{)J5|s^UB#QPsIePyXa$<-m3fo>KWBwNIdb
z-UqAAQ=UhH8Gg7nGP^&wtiBqAHj@KJ#H<l~uMP~(fJd-M@MkDU%fTo#B?eqp<MBWW
znV=VCMh^<Jm@zo`OeIx|II-OjUK+B*)5Ug0YV%`~zR2x2K2Fm6YFZMbVj^|A$fhLQ
zDnod<;l1TY%M0`UUM$|aWyOSRYN4ugP<yLY8g@Lf)2%GDt;QuS=N&I@<uqLL@N9ox
zt40?e7a1Cwke{}~RVa*%3=dH!l`ng(z2W%o7dpdt6n0gm5HCI1=pLqxuu!^@8)x=i
zgE(NA4b0wUon#F|zaf!&eh!_1aK}Uf3V|y?SAb(kr~|Dm_R&8T)!<wSuQKTa9nQD_
z;~9+u=Asg*hIR7#h0m7^`YkUC$ukJX&&Y&jVmI_ztReB!YZl#Mb?mVB9(g1G$L8YV
z{8y2~r^AI+OXarPTQ;YTEO;!?i&I=(-PyUOdHf=}`{DMrajp&V1Kc+)O1q0T+57mo
zqT_+8=)4;xSE5CV_`r~I^Z2~Yw@wz;hNxq@R<CYEqT;EnmE>(+XzI*YyV@EoCd=~j
z3JMy4^a!&F@bPh0EpTrPxEyZO$9(&c_Qw00=I;8UVT%tX;c*HXE_*4|()9v78fwd)
z*_P&<oTBKGERQA6g#^c~NaHTi6-^KA;kYQyY<Lny+?@$Mb9mNlVvQj@tg^DF`iYh*
zVwk-D<aMn&MBBsplviTV|5Q{{?Yhh+FlxZV-By`>s4D%vPsybZPVSfXRz!STl2w$L
zq}Ru;SxoU{^Xy;DS6G8)(Vzj`5G0a&<Ex**cNFSy^28Yn!WzGZlQuPii@iwDOatr(
zBSqAHGxHT4`PU`#`%`<<>(8%K>|R@wqjg{QNO?!H0oAVWY?W{KN(nWHo^naNmS-XL
z3BOsr2ys^TO({{&*%!Zl8;Nc`{m0=~s*||qVv_ax0mh*#n>rTPX2+~O&Nt*|qoj(O
zF+)HIsU~k;_&Fp37aYiJ9r-59iq&NXc@SaoC^%7$pf8Z{mcpZZ@Qb+Mg+Q8%GwPZZ
zs1WG22c;;*Dpc1=BUe+|6RS>{gJl&EtX{}!+_3KAkyY#V`+Egg*p#MbZ>cODnmCt{
zoRqOaw!5>wBtES=HZGc(2we`{VAm8(7aF3H8PdmkLwr)-cJ>)gB!1f{zqw)ag^6Xu
zV~47cD8SFn*)uGvsFJ*!HjtBkaH4mlp<%G)nKx~6!-7H!;#-xn;KbOHiOQmjS%%(y
zc0*<B?`@AW&VU^U{Otjbk(l9e4IF**?t{nzu9)*5_MWN!Gfq)cp-4G#-i53^=a2nO
z-n@LSZOL;}5%tk4nsW_q+r}%0>sLe_pDfCJmMd+H4fL^6<fjeUtaxgfY~&jQT!!#>
zbt=LCW9P>AUPD3ez546wnyleWmviN*)iodN8SfjMiXIFLN~nt*t}hMYr#F_N&gRzX
zWixM+M|S?XZ3x^5Yeka0&Kv+7dQoS~sa_rxN)P$R=pLM8z>iw`Y177llLB#I74eTS
z>0rI^3m6jcE6kY9_B&cyn)7li(lZ-7Q^SLu<6<jETI<GJ8#6Nt42Ckc;^5<NZm*K%
z>cZ3PWp;W)QA2)QTyE7!deQ@ZOjSjsgD%Z47KvF7&1)jV!Xx{#QagkmUdyY-igFEl
zy&)(1{?XUAKT_s3QQlJ$9#vmaSzlE=HjMTT)#a4tdSpiV=aV|%3?}%DVD&(q6fu_>
zU>}=`Do6w7a;*!94@V@ZRScz$6W*z#{sy<l)BJ*Q$s$Ih2b3-W5tG6-)e{2)6Y+Mh
zO*E2!Ajj8VZ`JAi)Xo9q>Y@k*42FBEZViX~D)h^T)04(mBqWz~g<eP2ek0S1dJ7Au
zLZy4xX{++kl?AUMizRVKme@$zf)B1<y-G?v#b4Cg+E!LLy7>i&wPfImE#M;^<_gSq
zxbZ5dNFMA>2~3SoQl~GeK%;q|3oK{!jF!1Y-7`GgOJ0xbj&dJ=L3ayT9o#atZd*L>
z@JK~LYe!Ml3sVVuRySnF83af=P+a*!x5L-$jN}{?+<pLA4h(N9`PoPB$FJQM_hn3T
zVsva$O9%O7cHdhL^+meSEQ%8xXa9ox7&=V1%Rrw5hl2V4$J%?qH(73f;C<dCO?R7S
zHBHktyGcjdq#13xlO~<%-g{8G7llF@rL0nsy+j0MTm=+G#f5+(4pa~o_eRC*xUQ>Q
z2hGd>Ja5uc@6Y@B{QsZN|JDm6P5Ykb%<nnRdCmi@!&(7`9|z@Q7C2vU*$fxUeUU3h
zv2ML3z;9tj1L>5T{!8d`IYg>w1xp7yDw(2{8g*;5p8Ms9h^t9^dsi$=R(sa7+zRfx
zfcNp_JVfj%O;GhDlYcDF6MV3G_<hIHtd!Ku=;&NledeHV)`gwDCxi)?eva^3(f^n(
zFvzEb?n}@f46~-LC%^tMLGXBQRr<-_YL{3=^Q(@N^R&By$q%Lmo|?=MJveEH>Qy=l
zF1A*YdF1aK9p@*_VMiuxaE|X`badEZPfOHiSC`rIB%yJIdSjDcLC3CFC+1)Kv45f?
z{7|nK&L?4i<mRu8A<#`I47xB2pb_jQsgUN$#k`r(P=F;a%W`q&{{R>q`d#*D<YFv_
zi(QN%I8Q2x7<p-<O2%V%!8z*RjBQiJf-g5zhiG?~j%TH%S{m{_>$B4{tZ!}VsjZ3$
zO3P|{)<jcqd-o(pPR8n=?5G{CE;;(y=~iK!YRkHETO*u*|JM_e^3CaCCpITNgEoKN
z|M6gPT8hz_-&VFsEY(_)Q%t79)=ihwQ#<CRSq2#wdKqHh<wYmSwXnkm_E-w`c#6^N
z5sCX~aSX@33e<wJV$Zk|@G8_PejK-{JqY*=sKy+{W}G_mFnMj+h-gc#d47gaX)kHc
z{P3FGn)qrW3VP^}Zsp{+hAaAf6+fc+)9v-o9+|wba2|1x{Os9RQUhC4m$RBJ1>S|W
z0))Cge=#=pql@I*KWx22Wr(P&8L1?%w{5(Ov!eguJAq`NIfp#Y7y!R-p{5f^C>Vir
zYZ!z>xJd`zv)rib@AVhnr38fa+sLF$gZfbrGhVD4x-bUbf04X$m$izk)IbBi!{HFD
zKEvaGoM$h{&djhSCKNJTECc?Qm$r7*SF2TT3>B0I3M%Fe#2Ur&^wxOU!-GYAmrL!m
zbITL2Hr`2osD1Kf<afHDmUoIq*wHgdDLH9bDP~74SbL;gRH!vJ1QxVzyONdB{&lLQ
zzab)?@M0@8U74}kp5npjU-k|ZRsE}>B`@8@hvJ*RdvX|!P~D_ZHs-(_1onTW2MP>p
z!^6}5UWo9n3%3GqJULbK%c_n(vveeE8%Q)WRFOkTRGH<L=+<huKw-o9y6^Q@^aW8I
z35d1fnWO7!@|$ww6rt;KOi95xODETM4yOdRrYvVcOED#1qWd$Ke7_~Xd$8S%-u`jx
z9;IH`=o0g`-JInEstvKciMW9L{n#d72K_t-Ycyb=>)z_(2H`7;f!dksI3IKoRt6hi
zl&87{1MmhK<J`nY7V_!7r@Ly1dl9*;qK5pUs3or?fg6#kvY>$8y>C2o^lS3Xvya_z
z__ui|GjGJoNd125*w&YvS5b7u$doCqDLXnOB3h-}{`THa)+~7cGSc0A=F;juOdqx%
zGuTfSynr}16A?iF+&VPlJ*X0|3nIH>Gp5Zo`^SZYv1l0PC#QSJsfw|ph~(O?&aP!S
zt4|CKPxh2&+A6Yxg1mwS&~m+G__jT0Y2}*Muu~@!Y}FecdB6M4A*3YVczIJ`XC6#%
zG8^76Uw+nLG;56|c?~p?XR4`uvZe0%ox$YKY)88B6UX*@mpqPj2zfLE{Rxo6;7k)c
zDp#zaGB!QV*kD^2r)=0BuswlOpu)inaGy=k3_3=_PD5meCdKb)VK+^2KsVxu{keEa
zoRmJPHnE2`3@ajO64lC+6OCskLh?&8zer;gv!CpLnaumQMp@ms!ZWR_LsnXpb0i=j
zbEsk)+=Pa@qNQ1jdiv^)$rtjMS<6}u*sbHl&evi82xE7`qY-GYhd7tz(E!u~u~-do
zsG4I1SP)PsaohGxFuN7XC^v0zxoU6&Gm(*M%?E+ZI)Zx7Y@_|9)5lMb_Jyr0H&qmh
z4?n=;FI6Wk%S_A4G^b?T<I`vz^0)SMZuzh@>A6QzLqb@-+oOYI%_n@x@AL;&ceWN)
zoUgLcUX>DIlGLQD6_0IPl@-*TH4u1(mJ9QJ{5LhP(&;mDOz{bsO%LRT#b(8r8UpgF
zHqUE4d%jDxuP;bEuj~-{lHv{}d5O1SAk)@d`)PGcF2E?9izax`nZb;1I0w?}F#+6g
zA$u1yz*2xE@TbeV4PZN1n73m4Eq1s#;R;@^KSA7-f1KeUFxV5<89-fUnKR>RsqeuL
zV8$_n?U_YyEF0g|cr``#)llOP=2E?I^_EcKV%jIRPMobDVRdDg%^8;`YfB1MK{iX%
zGnszbnKdW1tYCIe=QcIe#hdbCRsJwx&`|P4s<rVehsF8Qy^dIg-^$y=*9|15*q77J
zMk+H>uXgQTyZ)Xd4_32Z^eINd$OSy~pFVq*IWaM({cveSVpbANvCD0qyks(zH|Vt|
zE46W5%`F{_0CqEEvnj^H<nPT7ezj3_@4W1aUm6=7mT73!n#fKmP5m|XA6Fav8w#z9
zz*dsnxgzwB0zSA^)lgEX)o4gXV!e3AOz0Q_82Ny^l%66a=8AEo0mjf@?v)j3dwYsZ
z{Lc6-JCe9B-PNd6kw2rrud8Y}&y*l9WoVOj{c0)uvDJH^*Yv~8!ZpRMKUG9p)9pEy
z{au~$1AAjd$MzTH7mwasD??A^Mf7#{|Es$(p=Db{#Lk`b&%9APZ&UAhCDse%At%q$
zKLyNM4lgi%q3E8~1bmnQ3lG~3{w~lA?I4P|RhnB`^4}l_lmIHopUU)inp!urr+VgP
z2(}+t+SVIg#P@w-x2G!pwNEqjf|ZL8JoX_>n=tkjj-?II(>2;$--h%-diup3ALYv)
z`?x5Mc%S@w&nI^pZ5@GqdF)5#XQ%d~)D6f=u&zsng30UkU3VOeixlRryg!`VG17qO
z?~hdt4HOvkEev~0QBFZnc!Vv{*y@?nxb4ClSAN|L>n1!_-~5%fmG(C5B}-js4!ju^
z<v}RehjHDmPR;@(!vc6l+nPNv_)OzyTvT+za$W7A$8#)F4f%=jvG&bb3l(+s)s5w)
zT@82L)6!cOQLs?V^IJ$(u2t#@&(t&xxs^N*&y2nK1Fe{m;O=k0eZ&+i^%yM9RI&J=
z3={=4>`vK~PSA?eWUt43v?qxxs`4vMNpI<kr$3jMS8n?DuCrN#L~n<52|<6o(a@K@
zP{HDq5@#3ab7Mr(s92^v<lAqgQnhNB97L<l&ToWT4aof7o4*q$X_u%vCH94$aIY&?
zJxa8$9Ke+x6DMum39Tkb%rkp}cK037$B2bFWu?Vtm6+B&T%Jh&es9qZeRy(j)nMa`
z+Z<_Wc6*Ny>lNVvbrV_#BM<nCYyP<Qh_yz~q5v}lI2@7zV^NhJr6&`EDq2U~)cUti
zmLFO&JiK!$+eH3cKJV@j<+6YiujRC%AHJ@rZ`kR}Vbv0$5eWuES$#*2Kq`0icg|l1
z<CY7SW_Tt!UmC^FzT@V9h(BppJUFo9FpJbFxw73&o$g^}eB#gZ_2<$pYDGij*=NZD
zZ)-tc&ho?i>qG+2{q+T1ZQbweFVEM(g)R4-AE|1!p`A!9NsMl7Z=!5RPrg7Tf$b<=
zE2LZ~WyM@+5KT(3q_AK-q8tnXvlogcJR%8(VatX?qI()PJz@*D-ZK?clB{093itE%
z64M!uOl^`SX)-U<LEb<88m$Z^7I>}=Um!BqrwjREftau4d0HdwUD(6H$C$B_x*{6B
zjtBD;KZh!n0>hzF1&2C#3>xS#RbO?v7+Pa><!y`hlV^l?2OsOrE>o&JPpthUUG`4=
z?FfA#s?D|*g>iyqgVD60;C6B><G6l%h5eXJC6mayV)Pxc<@Kt9#&IOQ+-w@ln^HQ@
zqOX*yaFMJusr!+Nhd{p)$g{L^kbMmHDR9k~D;WYA^Jl!rUsRq;sXW$&a&kc$(nn}V
z?IViRR=;^Q&Fk|x!r}nCDW$C|@tONJuTG3Xhe_X`UqqiB9evj3yc8E_k*3uQa)bRl
zh^xK&yqE~3Dw?j8e)?}yXZJ?X2CNUMH-AU}VN}CDKfXtu(nWV28G0f>KCt@$wgxZ;
zXaK{<Fag+zR;wk_?leV=IBLOgQ<r~+L_J=v57B7bJ$=$63mKluw7A$sS&Bq9??!cc
zaow6yWGihJN{gy8_%VUOeiLuMycEj7`1$1H=q#fio<C~~v(E<s^0_zwL+k|{GDF9l
zhnw4T6yfO)O1-9Z^5nISrXq$9e)6DAsb}*@kH9_7yh*v(r<RbaPz14gLM|;U8x6(J
z%>o;I1mr-?62ciPC<Ko3-2W*EE(_}_W&tipK$RW%fQu^dLtvu@+9O5X<Mg}u>|S|V
zt6xWT(-b8hTavjQ#PctOZa*V9Z+l8gT{b6;4A2^5c@9fZ#6Vnb67q@6tuFjBCf*`V
zuLg1X%_pw*81kcM#6@0zV7JcGU)vELp$$E~S4PCe>ywP}Eb@0YmLbN`{~_qG7MDfO
zcoSFg9|t9<{Zl@Spce$`#0`tfCj#<R>5nB4cZP&UhQ=?~`O0O(1lt$7XfNp^xJ`sS
zki6_<%hmB%M#w`0Sn(?DReTqQi&J1luxgf+HRmr1-C{L?{gl}V!MK{bblj)b|L2XR
zvd=bV$g|m-vpU(o4laS4cULxa&dUj~4#-QB5G(O@-Lu2aBx3Z!V)*m)YMr<-&2VUO
zOU0U@?vY3yZ4ueL7w_dmo#A)dPe6-1GO^sJ``olpL;wL1l=Wi){Z!aH?%&|^pN;8J
znVhwbW*(wVG|VSDvf1eav3bCI<2(A(BTh5*%nG~y@L!%s)#>5>jW;}4Gxxa6dTSmw
z30FRd%@+a_t-~BKzg6?@<Hb*Wy4$4Q9;)45no;st9>*V@*q*0MHf610^O?CsIqkNZ
zEd%6_m)lNjoG)9_R2kqUK_}OeFVS8A{}oR4+_>U`CrzrL0kdIc6t^i$1U6G4(EZpK
zsuqt9Rt3b0qP>DklDw)4%N23M6&1oq7k{$lSkaoM`^rN62+e!*2L=kGc9HKqio)e#
zRpIE$givWp%4;oYSVwL_^NUFzVTZmGx?M3X6XcV$g}~=f%7cT|2Ls3fQm}T-hCy%%
z;6JeeP(>O8ZDF-nQbeNPa|>6*D~*x!x{P^?7R>wVy00xf_&`ExA}t`GHHW-vCpVmb
z7)5257mv0ay|+BxYICF~XndXfh=`s|RRiRN0CrwM)?$do=KzO*tPxX*{rOBNp4D-9
zw%a$s=!tWyItO&|A;M;MLr6ySqhq7(Y)f;VJ)9S6+exzyEge2UZsCQ8*@PLa_}HbK
zz@Vk5^}Jk_Vb>a!?OW$l&+G&2BZBx36&{y2q<HU2N!_;Yx>v=B!`5t#9KQ%hG*Ne3
zYxR<<^w2HKnmgvl>x!b}zR^7s%{8^zqlJcu+xpw<%Je3?!QQ_OwU0Iz7W8I^?C(ii
zP@J5m^2-R=+}quln>#Nj<c?ZRcW!3(Fntr|gZ$>N5KA#$a7Ap46{LCyW=0)L$CYAy
z0RJYEvR4m}l|HgJSw_pea;2CX1jD#CXgU}20=Nz$-*&kD9BHp~F3%3*xcx=~*wQuH
zW!zDU?Hcd8yO9XCYivs__n;!^Ndq?Ps05dGEpxn`eq69tZChPmE=Xi8s2=q$$b6kZ
zMf2lr=J3RYvXYz)l>s@LmY9Hu3AFsK2(c+wM}DY#Rd;?VI^84H7dXTEL8w^Ij6g#H
z?FCqytMg)(0*cwQPKC#$as#XZd;_hZZTX5P&ejKT6oMrBVE%mOvO}xX;yd=mPu7UW
z+R>kHwROx}?=2AJqX#uggIJoDSyquSS~XPpb03OukVd<f6$9Z8=YF-|+ggDK_#RDM
zhrm|n;sX_U6rf%ZkZ05k`!{TS?wpwE(nz_>4|2lcFbwonw#s7$qLeWLO;eXP@m|rD
zQAdGDW9VJzGw}YH;NqfJcCy5+F;=~ytv+d#B!+Y+!gjLlQDTC>v$o3-CXAG*wZ?YM
zVb2iuAR0d?R!MVWwx{2g*O}MZPHw*4x<(u(Bq7^1zl+*;^pUaRNJjxwAV5#dz{>!@
zcHp(Ky@(JfhdXnk;48#YBOfv?sa`jeY2oG20+u%xY}pd2$~EVCWv!gb%NQT+>&)A*
zVP}#y$hu~0e9|^rZEve-WYn>+IK4Pan!Gq;!@|nZ{$_jMgAOmml83~17cA+m!8F(a
zgH3@C!(Ga70X5!Rp)y>`Rn6u{|HV=sZR(NB*{3au=abh+W%B62`IQB0lQ{wQh}5By
zy5QGqwj?Uiu0P4gHm!VcJtENMa_74-OktQftGPLX?V}WBqRn?kNRu<u7IzfSzXRW!
zR6w33_5&SY$9Td4u4>F8Yn|4;i4N+8QRs|xDYS@#JF!2vVneSjV>CEDLS1!0o4qxu
zlGtyaYPLCcpXu+8D>6s7F3Pu8?_9jGp?q*+Z9vuCE!Mi}Ba073%Pq3<8e46ts-YrQ
zno?4i8WWeWatYQoI!2|85tt9B2Go)2k&P*%E{erk0~Cqfupe&k!Y4K0U3>tM@46Bg
zKq_MLd2l)pQ;Dwv_NDIm0A*#2h@H<!rNU@k4p}YK^7sNNIUyETMWTydLV-8>JvPCY
z8+n2sM#g5#2fKXOS)9EseQABId?fYbDwRrE5Qm%e{L-uzHk?rv!0R&l2`=}>lKFuI
z-P>D~N!LAEPLkIJx?`mgp=jmx-wu+GlPjZ2{QPUfLp?n4y69iQ*@1Ad;Y6s0<#|8?
zjV)<r9oU4hJ;S1)`bcf)&=Tc%Au>3|j`<JH9diK}o2aHZnH>HVja>GHq&)EbOq~LL
z4gITgd){#FlUnTjFcr66Dka*`r*BOZmhL8<rClg=TAkRcjF1s`SPM{2L)M1wGQ=jY
zYt37_<>5*v*?y7By~soTXWAS}8H<}sd$ok)qmYwF@9&k@H>2M_leHZ<RlaV0cWzBE
zS4Jk9(#g;XxOlPR{bMb*7j|Y9k~A5YML(*tP3vtcv5L+CMW2yvE$|==;$<SWBMvnI
z6>`N&P&kSK_!V%#1sjw+s3{wQ@j{`9K&>=#?n)W8Po5$#Iu8oGytuXuVQ_`OOF}dt
z)zi=A&ucsW;GtvBl0W1&pIIV{h(aUIA3qFce;7iXB40iCyg&TUFQAw9N^!6s{8MrK
z5%Pl<H%%o!OztLoj%Og<<#+bJQgq`t1vi*}UsTSt!5S@%p?d?oV_@IGV8A-EVa}by
zJ%t|Hl-vqQ`9d{yfI=t6LIJyiDkne!xaNt=g32;9ed2fZiDDK9&WuA`!e{3JIMeh}
zIQ$3L8A_!(F&3rKB~}K_NDsepzgk_!7dJ2ko?10sBbEok5nHdgk+!kr1|)>$G6i|f
zuyxh=!Yp654=W&0aDS_rys0!Nqb(&pN1U}B&dVGwdY{adC}jcM0@|CMa)lqCJSX*M
z<*`~5qr1s6#F5FI4~xY=kn--@vN3KACm@tKQzUU7-mDP`$dZnX*i_ovsj*QR({VOv
zdZz4^z8QF7fc>3x*KJ66Wq-d|3{7S&cdo)~xlC9(javF#Mcyn`PV{eDVgxh>ce;|F
z>q6U9Qs<N;$srfA9q|%+NMwG!;k&5hWb)k$!K@e9v`^*owT`R-vijCi1hybA8Ca|$
zmv%WXI6x_v4(CNW4{wMI6A<M}>vV!WN|sFfD8r?rH$P+?0smuy)#Tl}L&w!H1PuTl
ztRVN?br6_KxUQ-$#&=?EDsr6{gNv*|kRW*;Ta5D{ropIBgf1|^h<pVrh;by0&#z_|
z9ow-4dh=GH6)3r7@nEVVG)yWD@%IyHfA4;}!HU{G>&TEuh$<<0lNaviA3LA?HPy4n
z=uEi(++zo~5_}<(;i;|rA}AnPAx5_$GkmSr#MFsl7K~70X+HS<@z0!-RiC9-%H>2%
zqc>7J8`3I23*m%GFBQ{LE#$>3m&iBl52LMU9mW~pqll{@ODXO$oa=XQc_u7A$`esA
zlQu_I#8s*DPHDQ08ydld&R(K}`ga(oRQugK9M0Qp>_b_+91sE9UkSPz%*~nBJJ|m8
zBUl7BRg|6fstrT{ctd})k9Ha8z~@Ntz5zTE1KXJhg)N2J2geoSIixXN)Zq6hDd13n
zGmgukEh~qf9j)!HOiHRW7HV>2f}AV~F(m!!ZNA_|GF~MVs><l0d`753kvm;=s<}d!
z+MiTXk|eLAv8-|Q=4@V&LY}Y6x^a(IZGMY(H0Q>O5T!E2u4bv_?wIur&|3&QyA2*)
zv%E99Vis~kp#P!yuGJw|kj1_ac<cgLfe6PnEjT===|S5To}AC+aR1^MzLAhVl2ACh
zX(Tr#3OL!x66aBAl0y;6sRX}Yg)IdgQpd|8BhjbQNTIN(Q9Aq<x*?GyWRsV72`#7X
zBpN_>E1h=-vtAEofs{hLnTYO}g-+|p4R%h@jO93jeX)yC<dR~vEy^S_!7Gs$oxyjA
z`Yt-}Rz)S!kE*rEbYmGRCpx-GR=kQqS6XS8bCfO{bITSxP~epsGG)9YJnJ|AB1)`f
zSmZA62tovr15f_q6X_)OiH}H<3Ki74iEOE=TyC6PwRAk)&o@{Y5Ym@bbDMJ>H}C?R
zg?5sYVJ;T{Yr+c=JErvmR$ISJnh<i;9<Rxuy_%~~WlbmKK%xmc=;6Us1D#oLYMPpn
zK)H9yRqI)Jr%(xj_m(?@Z@>Z|NKpdhdjl$Q%P|1KI<Vt|E4Q#e2R)V}DPpQ+&POF;
z|Inx;Qsl$u`;cKtwK5sGNg9*IiqSbF67(R?8!bUgy}9VLG?dSeN=i^0W$#BRo>!23
za^Y6=HV8|^L^Q7yCGCS7tNDET@@ZR*0R$!?Xg(p;^w401oHxCUwuUDU^`_C8smf`6
zVx%xG6D&=2<3(%qAG8xU?!$5cKMsEH82CLu4<29?T<5}j^)7c8=|M{*W<oLE8-@SN
z!HXFwf5td=_8bhwc!6ArR#Gl#Jpb`STelp19Om*KCJ&-URPWrlZOg&O9w+W0pMU-Z
zG=);IqaqiRFI+-#_D9G8a_FQTX)Y0C&PnGw<4Lp`-Ts)JeDflBCl_sB(*uCEbm+sX
zruO0}UjW<&IRI02TJW&IVG1GQQYDpqgUaBpg1<Ov7kZ>qfd=<MQlFfKluQFdq2wCq
z0T1oC68~7d)ZwX6NdGlHo@yV-y5mUsij|8l#Xl7<DQ3#$p)4OC@mq}zi+2bwqrPK+
z$Cp3%=*j0I7e96X{Z9#ZIR(*?a<t^7z6O&?j`k$VSu1~zNgP{Ht<B1{^=!P**=#U~
z$=&iev7}~iZ+%NyVAY-IdOM4zm_BoQab;D<*8G&xN4L(etQ>i;ETy(DD!!NM!FR>m
zH$g9B;51Ys?s3B2kt*1_w9M^fu*HBvy7DwPmp~zLl$A@lFrgi?W6(tUn+o|z_Zm5`
zC{gB|6pNTK8L^%9Eov{eH&-sDS4;AHv!>V2Qxn<T<9ymBnQXk$LELygkK?OQD#Msa
zlR-Bjov~JH36!BCsdQPnR9daSF&1T^r`>olo5FqApMS`h0Gi>n->v-dmP4nu+Gic#
zt?&{_bqG=40N2h3qM^V^0iqzrgeX){Ke6`u_mf*>1ql+ONFrj!rE^%y<hxM+dYKIM
zh#$-51_U^lbaP(~VuXfyGd$&QIRE%<!<I$Mz9FvIW#9wCJqaN%&1pDMHG$3$bmRd}
zK1?dR(b5kM@vmg771_>M@{-$c!5W@~HK-t4!hQ?54%3aX8*nQeW$$>W3&FJ$lt3sT
ztHn`?!vxq4J!e2XA2FVkR>{af@6Zq*=P#OgU!FutSR|4$l($ILAo7V3NzgLsvvph~
z^C!E=4gS-75&9NFQ`L=f9*@4RGk{?D3c-OH$D9d>GmOwC8=vXJ2$$zaS%NuL5!11>
z@I4VBVOcjWxa^ww4A5<Z=v3{|HkWemS^C{>3wvFdzQg0Q!7^|K$Gs+iHt;SUMF8t^
zzYoh|a&N5))+HyDgnNn1XCzt?S>+Qd^dX-h*HC|V@V&U<u~PJfM3OhpQTS(`IF759
z5JCVvQdJvoqDhcp;%Q{4TC%S^42AoVkCGn-{ic!#LQt;LzER!f{eiy#EdxfB-Y6Fe
zY4fIc@r3lrtUv|!=Fy|%J6GN!Eaxj(i~s?=5y0Z~kYA;c4<pZtcQ*EN7%*BQKf2bt
zB67Nl`0OEJh^{FocY5z}G%}8o*6=xk>>D6ySN^#e_>~V{ztaO+FlKR(K9Q!xoZ!ts
zSnTtSY=x_7(3Q4O@CcZNIpq?+E0)8dDJaVDAd>T8B)d|9mBz&@c-Nh;it!c;W3j|}
zQX*OVO4NJNaW)CrBMIg4Q_lXHaxK(g7KMjLNni&^GXJeDiXItyMG_SmIey16^mwvB
z5J7(3$08DT(UL@Dzr)eY_+18<!d8A<RW;0T?hK)6qm*zJZ@2|TCjFL>C`*Pg!T0fG
z1iy>8&8Q%%xPtBL6A%iV3)herpV1nv(h#r^A38ns<<FcoaxZUR`eTvtx*H?35+zYL
zGO{NzC_rpBnO2Y|S4}*g5)`0})k@s90x^CFcxVFjR){r@f-~+!buJ3}i|xRNK#Qm=
zZr%EbtsYbid=+LgwjFR;jG@RhBfW(DfhXvYNSr&x%BDE-FiXYNNTujkaa3dkL|5@N
z$F2o0&@Vnv$@8W2$qoGR57_kgJT<6;#|Y&I2=f`MV7~Qj%{&1HII%TIOAJUd1l~*$
zz#4BlgOlcTqB|m^botmRNEnef2IE>#{fFpwxz?+~xsp6p6N{lt?9J=+H)+p6PM8Gw
zU<tl^QqF-y4`hkG14vnJfZ>o-0*@Vm`%OGc5j-FdJ^%=oO5L%3P{)@rSb$|iGK95_
z`Zo?y@T=%=%04+69#vV8e`wJmBzX20qq$Yr8Lf*mn>AW={}UTdp8U7}6>CtiO6dG7
zqg5n;;l|-;^Ul$|{kDc22if<-t0@Xahdwe)lQH#FrMa-(k{c3ZNm59qiljF)%MUo6
zdM_drhUsldtyw}&Ca7&}KjNSwLt+&K1q1|<#;eF+pUCbqnvth<-NLBs>cwC)m<K1I
zuTcaQ!nm1<Ca`!WB}bgs&o~&oJ>&t$<S-`;O1wi2h1p0s%biEiPwd+C;fW<J?@1(P
zGaw+Xbj1U2p@95Xib^iN`1?I=<vS4Dd1^18Z$}s2n;07#kSj)L|6Zt+Nt{2|-SoKf
zN88XpuZ?v4g4T>Ve_Yo`AJbZ<11wP9qG1|o&w`v}5IL!v5<n2x1QobBo9eCy(ts*g
zXEb~R`VoOpU_2b{!5@V5j`nO(QgVqb%k~>mG-WE4;Q?w|^z*B~+;z|0yRM-n`PQV2
zROfWJ<748t<kHgQWQB;FM|LF3a+AZoy_T$AzV6ejlPfQzM(CB9&W9&{{(h_nDn|c@
zf6$4BeGZj9!h><!?;HjKIT%P{hAA=L#Kg;8^l|7Xq~rtrcYnBP7Ycam{_$im2(2Vp
zx|P3|pWk-icf{U7HWnAXESFcdj7_|E1$oq=A<VoRgChwR`uqgzjXTE())={rT#&f%
z%P&USfBS*LhFHE$z&jCi!biJq*p|+;o4B|(=YDl)gU975sY~TO`D|burMpdXrywf%
z;HPU#y(FUT<jX(pxci=6S3lW(ZvpGws(gLcvhfTZLLa?lL%+u`o+w|wx<nvQzA(1t
zyN}nc7+&$@yLC&Sm~39OuxSdZdVV8sb`F2_A1qf8?tP4tkg?)ZGT>|G$d!vFN)^cP
zG;nu)26zW}$qdnLM#OG2Gr)ln@Gn#ajdowT(NvY_AAD|`RJu*fR!Ybri6nWURJw4e
z|2dSI@1XO-)S)3!<ZbWpPq69#Hda=c(lkEgmPVP<IZ(x82J*p`ju2awvNh*=x}LL$
zc%0C%5VdM$3ORj`B|+h!CI8~#;pGtv=Q-b}JrCZ)0x_q~W1h!SkJ~(U%vp*1I04ub
z_5$D!s7~2iuEa>GF|{1%MZ<|wqLKscC!i^_mgW|QyU-0Vmr`i>Z3yPd0LPTze6UHH
z5gzkoP$r5g7)Ct~s`b>zF`MY`Cn=+nJxz%vhu55Vu9sytrH2iMA==t^uWrBe>Xr{5
z>9lnHW9>t44bNMZ=*W*oeD1qvHOj|7h*0(PtHNA=k}EXICz5ou64G0>mOokIrPH9;
zs!J%(@ZyK$ug|83uv-fI`U+c|C-q^P_$-<=Dk&){nB@~vzTlq9?8LChG;IQ*DSTs(
zH73ToXSuF!Lw9NU)ZJCtS%n3OQNG@+U?%UxKlFJUCv&qlEzoD@=@(LecII!G%E{VL
zl45Y~Ks4H@q`XkTpvOF4o02eZNknKyyH2IjC8X38X*isSgl?B^(NBS2O8}e=x^)W)
zV0*;Mg7s@wt!_Cv=voKt>b6w3cgIP)%gfPENy#Cp)Z8<6$}E+VgR{QQaIy{cCQG;R
zj>`GY-+AEX<XDH$+o#Wtk@t;Ym^0(;c9yr1ACvZxcq@A9nAF-wMrUcU31fekrNuY~
z?1CT|6L4n<uI4~T*^Fgi4PpNs)j%(GN({t|l?-MKxd}#3wpuLB%@#{*-du9c(wzpG
zEKx6&83;@){bNfje6XeE1_LPVCE~lVU$%|Vw@D3pnOtwUu`R(uY}F(?Ur&Ka4iGy%
z$WG!qMI&4!>*DcTDrsQL(3XM;2Bid=sQv~QDxFIy%}u9)x@rj<iGjF|$;D)|KYNaR
zmNMpG{!_qjh$*H-nap62N%ic#{Jhsl6Sm_F>n!<yesu22bJ(6!;(bvz@%bWH25Oh-
z_3%^r8&+Dm*6Iv@r7K+l)+|U1qk5$&e$xv;SCRnp*zp+~x3&O8RA>;4F8?38G8ZXI
zCEnCYQWr{uZDg=Y{v5?Akdmb`SuB%?KP&vJ>Re4MkRVX1Ch`*`@8?U&8~IEad%60W
zRJ}i0#2^<!2*BDTA?RMb)F1gT49?M}>75rf=4f7+Os0ej5I5gOV{pU5oIxv)St5P5
zOl6ACp!c{H3wqEfy&Ccm;2r0=7U4>!amIk{VkSnxm?XlbG$B6H5FF9X((SxEd6a4o
z(*CrB`uh6_W<!wLKJA$f@tWc%bC|XlD(vNuwe<b<S$}VR|I;ExaDo|51%luFJFBG5
z^SU6|EnYK+T}IkHb_&Ai|F+jS-Q*jnXU1s%;Q0w7qRJK6eD4Zzo9}DqZ<#Ne`+^W+
z)dEw#aAB@7kC56dEf{u9Y;1>0&$3akvE_i?T?6B$Vjlez@aF%UUvhEb?>O-PgI}6m
z%iNWKTe2j~P>x}k8|w@JmI(CVLwy&YW}n5x5RYAl=y0#7VP^mMR?LFx84f`Mhj;(;
zpSup-z3aR0cHfi#a&qSDA4p9H4;rNr#(VEIMmnc6k}sgwuC7`%I&t-%Qxg+Y|GYjl
z?<>;T*NMEIE*T#$dHUtDO`FP(^dZ{S?!o_jk8>8#H*zWcA>gSC!vY3F)NQ!1PvhFw
znFX=jTU1gQ7KZcT<^nY1-5(-<dFz1{Qt~yoU$5xHfGq#jV#mubl0R&(Xg%<o^J%a~
zbm7WPk2<nIER9-7yL*vL+1w1E?8lCgFTY&aejRO?bpA9(PSS7FTBlnq;L_*N7y(rX
zt-A^V)UhCd<KhA)3=U&bSv)QV!4{g7$!EC$4PZs6+X0=}KSDgGKO`Y9Nmd+xi~JQZ
z_k&AXG3LfLy47AqyOVdhVh8!dZwJV}S1vfn{ZcVHS%*BXV9Y(Jlr5U>u?v0uz3H3U
z=r{fuok!bgb^e10nj{yJW5mZDKm6VXi*RGJHNaCfP)k*++}I2f8>%(zZ-OTjy4^|u
zbW+IM%~#r*e1oANeB5S$#9&U)EPAjiGe19HVl<Ej9EFG<4Fv^;6gh4G((RwSVx~(s
z551s{FHI80DU8nTf1{J7pp!<Rve=`-t&@>TAeX8x&Zyu_Rfpm<&<TscSd!YC<nZah
zZ@hu^zw3&n=e9me-W;k4S4T-7T)(X;z4)c4PQCQfmeb!gTcg8Nl6^}@zkLanh+mrY
z@$<92^wd)?u@B-;gg-F7i^F1}xO>afGcv-E8VYSWCP{Qvi#{ec`}V#0hN!5pAEnZI
zQ_LzyLYaRNS`)@#dO1HCNsWz7AB&e8`{wCmW2{q_gpACfpd??|>%sYuf>8(a>2a4O
zg_7}>KUN>eQNdACDVvrJ%f#ExkOEP~L}+h;K9^rBE9455VTye7ZmIMa4J*g`tCYML
z$L9+Rd}*Uf=QHQtQ%Semp_Q7bQp!;7Xgzt?^nJET+P@kb+OnLDN3hM!^<xxvr=m$J
zp2!G~pG8x^Vk)BG{Q-(5TvvC$N9{jR`i<#x)do2jU%e&)Fh%abIpmgEsD(C5rOA*E
zJp#ed*((oulrNQH_Y0SeKMwW>dQHYWeRd30xn4N0jnEhg+0G%*7NON?vi734tXkMM
z$vcK=hn(ma(CsLQh-S<|447|K1ZOFwsv1IScV})T(_PQt;q0FNizKT&KZ5*EaCsS<
zd_G95;sM<orP5d?3cvXlZ-EpINiLhb>0ENtz%zlwU5YSd4&(&!Jb~9mcAN8Pl!`ba
zjm0G$F+q59GMt~Ij}nw-zDSnO=JTCtU!whzg!p7<6T{Qr<%5|fpdHuK%RO5DN<FkT
zLq32jGylB?IDX^;U$~yb<Nu#U!Pz)mq~Y<|)Uu!+=qlRaS4@*@jn{+AOWEh1{M(go
zzRd{u>~@TBVBK$Xhb3rOayiMH&LcN|ToORrt4WNA_$ZJK3wK`pxHN!9F(L?F-{J$>
zN4EYAH?q)QnWIs;m=hA>OhXq=NfJ^9a_poA*ds@;!b=yg+&F~39(a`nsICg12b_cJ
zT;;%7F9uK#Uzt9aM|f9gwh-vj5a0&xV8CTSs{Dn^T5g=@$)v9bh$jh;VtPK@l2|Au
zH%lb8JLC4>^cdg(YmQ5$F<$hoSzd|)F&dJ|tW(h&QDmn=N|J?M^5y(^@>O$khW``7
zSfofxv$08ums|pyL=kklm+-CH_@o#L<c%w~qpS^}EO6b2x8!)bS6o~yR|x2DK(-p@
zAkrAT@Ng$9Bn7RvWtZnklF3c^c{RDba1o!1K^+V);0Nx`vAL#7x-}oWjk#!@V#oj0
zqFILE>Yf43C<z1an^V}G;RULa8%gentE%fI$qJ*XLhBzel%1GJu46?|wsE^m66Xav
z@(#9*LCI^BZLE8zB#?fmJPg&7>(wD4stgOLMRB%$`u&ddtfx$sm8KL8Eh}M^7A=dx
z+7Jm?n41n~@IIbnD!J&Xvtq5r?BsncP^$&$!Zf^Qa8@tCnj--7Dyhyf4if++EYJWs
zHVp#=BRDOv3NRfbTdZYBnFhHO>Ey6wNqfQDd2SyvgfkE`Oiu8pACmhLDQn4B!x@B^
zP)Xy{k`+!r1rbc#x5asSE0Gb*mDAb-{G8}3C5<B^A2a&}5`TWBpmSs>KVQlYn!X_p
z4g~*+Ja{*+c`6x|P}he}e%QK#u<kZoAVq1A<NCC#vkWs9l#I(^K#L--;=Ah4fQX^u
zfhSc{=j^mb{11bU>L&-MiwzgL)XA?LshQs7L{dq8gUP59hA2=>n0KIm<ZtQm#^PoC
zV)Fa=cuT=NRl)euC(wm5EBWm=+j47a1N}0iVvemj;N@%TR12V|4yAk+k>e<emXXJ+
zld=@DMCOLq*xvpjNeH29VtI-+B7u{+`_s~hK%pWcOr=*BE`DrefQ)~-wPclSN2-H3
zHFl48(``%B;zg+5IK5Gz08|0KSOk2y4fv1`)z@y!3+$g@tso7&P|!~)K9~Mqtbh->
zm@&f(Jl+5<gn>UPW>K4mO!%fNzT+H}YQ3U<JLV>Qz;kk0Sg+&{^1bh0oLD0`(VaQM
zkS!ayFZw5abi8eVW9#c$W{6L{KRoit&W9JY^hL=L<FF$;fa%9&MKi;h{9m3<WeZs)
zi(y>aXU7j5G|x9~>s!^^v$&#Ul(q=^N`pI||K`NT;-GcKyARZtFgj5ndO#%BMr-oe
z)~2!6CL|(4!ZpIh`lR+F1Fc$9>&5D#qkK5P=1q&D4N8yo?~qJM+WSfCU2B#S)hUt5
zM15sN-8|5pSm0R}qk+0b4EuB7l|n}uAf+eRm}xrKB5$dSOLg$21^AjHu~uf(5n?<O
zgX)QqQ~Ht>ogHneEV;%IB-C#RukUVKPF_!!_?m6yvgG2t{9<cNxi#ISKai<xT7)>S
zqv%9whw~(P^e5bh;Qe7P;+5ZSPoY2M7oE)$O&UWrZFi_w42+c(qORuV1<_J#d0u{F
zqpd8_mc&d@LTAif|0F-W<IG1dk&zePLM6xtjoo|vIG8L!>4g>aLPy<43N%v3XW;-1
zzPAHpJ-aZhB9w`M!gFEe03{62f(BD_<nXOo<H2f$g>EHRke_ZP^_k0qf`g?$AGY*%
zW~9u2fII(QcIfjvJ}$6S%0?GLGuE#c5d$^;2L+^(SO55pFYnt4htvW`FOS@IKd~5Y
zM&9_rr1#yYgo21jO`JO0FSViJb$YC2N2xZJClsLQf8W07^kq`@<>5{7A>m5B#NJcb
z${z1IMA?2K$Zr((#M|8Z4)Oy{g=PavclidYXhOXS&dI$#tirChbnqz*_o%eNRRhQJ
z1S8==|0!?)%M^G3Y|?45Ts=pbzG1_?xlLAOohUJ1r;F0c@2g)`WldGZl(8bMQjwy+
zef?xznIg?rn?wFoBi@y~$?51oUJq<PSnR_nJa^xD^2ql$jz5h2?;ea|fFY!9uVw^A
z2~y2QHNTQjhe_sTWf_}(T2yB(m&#MpizQk5Jju9Zb#cyU|Ayv{ks=dn=p3qw?3m{)
zB)^<|*qT4(?Yp-k=Y=;>DGEIG%sknyeZU&fZ4u13`Woa8qfe-M(k%|a5Joo#D2G5D
z(ZJo*z%J|^p*;&P7}Oj#nyHg!a};Cl2pgCAQ~INKa}{_DKaDG;)GuRvU7oc&)rTD)
zAw(YUKl9UDPrj4HFHI`Q%+y5&`1f61TwZy#wQOLju9H0Dkc}?>`ToIXOG#UK`(vY$
z$=7#Q)gRsd;)5sA4@a%@iz9l-6&+iGbAnT+yfe*>ImwyCZJCbcmN?(IC|xaiVC>5+
zEBaQvSlb%alOLIE(dQE0)A^3kR`Sit&J=BW&KhD}$2`rTw$-9asBJLCPjR;87HvB{
z&|HGnHf3hUuw<gNoolQ{@0|AS4o00WP7Q62U_S*nuQ8dxM+1csgBZ{c0zF)mts9Kk
z81T#wmvy+JI*uJ~_lOyd>sQp=k6Fc2>R^WBtl0sFF@I;~8!?&Wm;WN)CAZ&zD%N@w
ze0WMc<f~1IN|r_&9A)XoXNK=tyD~jA(YrG!t-_Y0E`OVBna64<>uz6rurA6^X4;oy
zT}D_3Gxp4@Ih`fTY(u`^w>J|a@`roY9X*fg5F71o<0nUj$Yu53_IPzx>{OS%BHe4D
zdAKk`=Hty#8vHbtlr$~Jo10EPi|m@7Wvi;n?zUHwzhx%Z9H4d28y~fGo4%g7=|R47
z$3J`KyL8QSKkx|09m<cwvSC$jZ-P%2QI~U2S^+M{)vksab4wFJU*Hw|1f_Yiu^Ag9
zyfgbjiqkkegQ|M&U(xc+-n+!ssujlK-kP?KFYLmjB)O`#r+eOQEk~js8d&&peND2T
z^uC>k7ge{^r>8Ux_E-}P#ald!56b>{<o^7Zw$udVKl<U)iX7X)y{D3HTXkv69q9c1
z>*hD-<gg+(*$lNNO?y7`tjRLAzOHIPZ3SXnTzz|TLx?TquKu>HoCWE%#pdiK$RJl`
zWp<zO9v|7*!tKbdyRwo978RXN(Jip{^<C-<O<U|bOE0?lBqJa0XOPYGRL;y=z^lGx
zlhkx5P!Iz&PGUZ~W`Ix*$rXnAQU&x_QcQ5iU}_i<yuk=>sqSkfZKFlz?4K4oh>n&8
zITc%0A6kkYOl<7(LHlBb1q-r2I<f66`QtKkN_0w<e<HDO*;Bb*+>peKA#>gPM^@ZN
zKiZX(`Gq_>|A<<q&=~vn&2M}xAtlx)(CU0Zc&|xGE~tE{tz=2kktO$}X}IdR<wth}
znXPMg*piD-XXo;Ju-)9mvzDttCzKwIF0GisA#Sa}P8Pp4<14VwQL?3Opn;b~DF-;=
znKip7@=;+6K8)kAyW+!$E~`1ZVrp=3qPwQQwqp5)UYh^N?wxf_`?j6hy4$jUFrgV0
ztKlqNdO>cRH20gAe<pufm6@(F)QafAzLKVjMHd`KqvK$4Mjm;lyKUWN`ql?pyK2hH
zYZlflb>x=?`c;%w?09VXNTX^^<6-AmmceWi_3z5w&~bIs*cSV_O$%cyyerd&t!W2#
z?z~qSo1cvS7+zgn>W;sRH-Hbd9vzT3xi<T$6(!;ox>-Ppl2U)nhS``b#{rnfn%zgl
zzLg7dhmrcOc}=c3hnWE_)3^4w7;libU4#vMx+H$3AvyiEEz9ODs!xaW+p%&<cyh`3
zyPR<p@HS$hz%#Fj9zOENp@HR@^rs&|VQmuf<idag7K7=_WO8yd@_n73C#MwmsYHz5
z$RG07C=aYOm2gl^^W^3;X*mni>(#MVVY5)g<CY{h3_i=>@#rtBJGbm7{}5fjW3!`r
z-_*)_^yo|EbWM&{<|#==@v5@SEIZtS^_iwLGrQb88W(|MmG{kS^rwMGa5oE1yg?@@
z7P#UL6|V3w1U$<_=MG(%gVdQ3=o-J}N?idAoR7<o@aRvEEgOFDN>gF?praG<8ikLB
zt6R}j*}VeMn(;%+#{>sj(#lyf&!Er>`$k7cjN^$tue@^bg(PlSlBKoMkJx<wp&`c&
zV@sl19^VEt#Ovz{d5f9<K7L@hFE4N`Z;d#!Fg><b4Yyb%&#yb(S69{jWOHR?U7B1o
z830SU`P0p7UMpc;>)n#a*AwAkt*$TE@+dV2k|9lkWEc)4CMt0=&8*c20+Lt4e`p4(
z%^JjviQofXf8_y2K76;A#99W7<AOKF^O1O7E6LSI!h92Lh-=R&(uC6)p23!)&_Eym
z@I!4c-1JCk^9w|dz^o(QJesdyzFjX=J#{uR{f`8j44HlcLJ^%FkdV1{L-|h6^6yF#
zGc#)P<|*=4tvo;2-epYq_WfRALrF)4t(Nc8?d!j>b`_`E=NoeR_6B(u;uXxdczgLJ
zife|s8MdhA__OhC=E+n2A6-mc5<o{A1NG};_Ml}YhrV5CA)S`mw8l5ymF8ZIs}rJm
z=XtT3g67bv_0RWi?oW#?Vq^|}k<1aXLleT~39{^g=awwe8R}nnyfz_P5>u(%u!<&Z
z*+f>stWN~@LVx0k<p3wnDGS6tXRaJzvk$kY!|mjl(F|75|0^C-SyDJM;!JTCIeV@o
zCmx9Br5aK6P-L-!2Q5Rqw5FgdTJr24L4(222ud&UWah5jQ@O*ha;kWLURq7Td}YDZ
zs*6)yD`R<xc;2RFFf8U!;i6a=*j5!=^%Hr$Xk+HxZ|7u{vV8=m$m)*pw7VtiC4cO^
zm_UB;fp1eV%DIBlQPWq!zN7u-IERmAXlrYdC|IBq$+c2j&&x{|#2N>#^k!^dsYIbf
zv3cdA+5@<K5BPG;vlIA&C;Q<}*V#;w(j92J0L2Od^zV+|uud?n;Mt%(1E5_#96Xh0
z=j99Jr8S2%udg+Ct7Y<4D|T;3zivO&QcGSdQ;@6ka|%tKUgnNhmUWLWE~^yjj0JhS
ze}3T`)bi;s#BJp3XP$KM#~hosG}e>fF6g}vh1G;6r{xxB5cSDs^4p5hy!1TBB8SCp
z4!EBC=JJk5&H+C2Aagv2U=5WXL$C^Jzk-INh)aZ?Ob|66cL%^qX2j$QE$+k@e{MDg
zVY|Uz8AD)5f<W8B$lRxJs88{6;H8`oY_x$xGI$P=6HnO|9gbGRVFrG>Vc3-C-_-gj
zgW>%}TzpEw1PoSbSQ)EHE@)R5?3#Rd+t7v>%O4A>x?@v>1>^oz>VWvDs8z??AMtGO
zZfg5EAlQ(n5Tc<JRWXt9JUOl)4Xt;Kuk4DFEJi2WJDCh&MEsd}^ejgZ6_wT<;3!;H
zSI!m^e33#ZPl$FbKi1QfU>^NKliV#?E;0HuX(9qKBgLG6024VHm(<C~DQ!wm@(lVh
zN6!iEDXe!+zFq9n1Lk_*A+GuZmoPhwFsBpL0kaGr@N~Ife6tI5N<f7RgVwpa08<%o
z<f7_)5Ve4dz(-f{1W#;Wu77I}!xOcUPrUf$^$V#m=|43%Ykc*6tI?aQo_LN_!FVh3
zy;M&h)yOvsy2qB46>?>SDK)3;67s%`(Dk!d=2^3h4q-4ML#Tq>eKyjN&O3g7YA`-9
z&v#!<-A5OnL@RvH)|-gNoLKV9hDDXd6-DC(j!Ij|uMMA%H8*x%oGK*;O$8=pxyqdr
zABXjJc`O2t;94n^&Rweosk?B=t!RQXUOZ11ioY&HcWDqcnqpReU~kohOJ~mfQ&Yk5
z?}Wx1>OibJwoy3}+w*uRdAGMXeST)NfMD<q>+ZO=vbOnDfz~7oPBVru)?H9$9!S<C
z7Ek&Wk9BQ-#oi*e-#PU(%53zB$T%*y*5s8Ig@<|*yhwIF+Y}X=l&Wqar+s}2AE_87
zcvm<dBoud`!_ldMnH#^~us^S8`EjK>FFVxV&ri^g`hWcSUc`x%nGA{5zPa-^6j?+8
znG#KgqG<5Z-j;7tObdMjthp7}O#T6EI929f8Ah5_sYEfltKf&n{laiZI`$us8+nEU
zAMNnMb#so3J<uIL!^}Al?=ODR%_}?*XSR5P1H5N=E%{_0+24O+(UM;uK!L=|<=KTx
z9;a=2_^$p%rMbPeUCZp1>G_cot$g@E=C;9SCl7x5B6*Fx|IH84CKP%Hx*}>2)BhwN
z-`6|%;6K~#$kWzbH%XM#w%pN`Vu+H(D&tCYQ8AfyVVNZ@C&{1pZ#eTj6iftY-4#6O
z0(mfRUW0kVy&lc*0y_Xo8L%N>r+`ankf{76eZ$kNu)n}T)~z`+df@(?9`5+YzXuQF
zbpu<<T8xYb#TI)($9>z6<vu=<kdRN4^>rU@``Sz9SP<^W4exb)UGq~;R=GW|A#td<
zY~R#t$IdmKy<MGMp6x&Z^D4%6kberx$He8|ShnmaU6O-ptE=i`Q*Ghx_FAp4-;vIa
zGLa<K8fvX7%8w|Hw;n1nBuK@P_Pl`?dK>Fwm)ECSjj{f+s%;B04D0=Q;qlqR?BX@I
z8%;^aDf!;K0=!rO@`Vbcw;Q>_UwWPt2L_jj0kU9A$2C)TT8Hb2Mjkbf!|efhj1}ZR
zMuW?}2nIQJ{#q_8OdOS@jxs>ts>yChsns^B712K4#hopRyC3)V8#l@$p>u;nzEKuv
zPf-?<_gzkwF#}m4#4eRSmV-=j=@q%te=4G*3W-65FoX~>YD$Z*#EOVw=cqg>)*Fa-
z)x9Qx_7aZ;SdxG$T_VKf&IOSQrt8k$R4PfoB_U6#o;L?o&04oRI^dmo95`lR1pei?
zjLbA(3FFA=IVnh!PDxpk;sue#e_VQX{dUIHrH=0KpkV)p>IEC3uNhRjJZpB|rukc6
zvG;TA_isOm@=91~=C#|a>X@4NgB^{H9VoCSO6rTe0<Dp0+imBD_AFn%-j=3IqP21&
z!dX$u<S=XRm-|;W(vCIm^ClXfW-<H=Egz$Y_(E-_N}(`!ZLG}{q81s{O0!CicGrEe
zN~>{{Yzxi}&hYhgZb`SAQwqv=l_;~4JB5j9)=2X4)tw2IL_0iM0Y@8Mb!D%Oz{fg|
zRUUg>ocxOqoWTr~rNCr9Pp*>6O#iFU4D9@GnCfx?R3o2@XMe}j8G`|{n_(<;IJp84
z)VG6X$JQFWHYzv8D0Bt=;RP3;dbFk^X21~<WT`SXl@61K3$(ei@0P_x=Up@;7#umd
zj(@L6O3yFqmloZ*@%gK3;)RK+BQ+boLvn|ooXz!8agMb=?A?xnB2qi$Ty9u(`nt>!
zTIMHgR*EKl%S5S6u5#+XJ>OkfT5KarN;~Yfy0p@!Hrk!R0c^P{I!$EnfAPRJJ+DBo
zw}$J#DAzHU{}NP+>d|>P$80icwbrWT?};L0TB%YWncaVOr0ed&FvHz<zh1Ubz#yDi
z#*`jraoeFDMxdmltgNIrEhc{*quOz53GxqKHV`5t^*5_-e={d%Y6H2lOOO&1qbn|l
zeB)cN*G(WRYBzJn7lGd6Rs+B)RQ3dyH@m$R6OZ$RL%CA-rP>sWv29QTEb;Mw7^s8K
z<-?T@*b?CP;0y)CfbSsTF*bD-SxqUm%!oE~+^@2H6t31e-k>L>4%gpLBemYK8}qFq
zW(w(SE-0H{QmoZSbL=$zRBqBWX%0;!4Tvi}#jxd%^{ynCXydL`+afKW^yC!M7Z(pj
z$7Pw82Tyh{c%?vARXN`~cv*Gdn1no7pU_xMo=Hw`EbWVqD@uyyYE)Yn>^V{(yInlr
zSFpUQVS#S|8WhyeUx!*vso=|T4fJ>5M-S*NAQx<}?!A3#P#<NclqbWsjJ>!k84E|S
zMyOh0mj{c+ESN1?&2bPEE}G*auz~^)**wPY)6ef-cH+usMs1!a*VCJ3+4Wvyjer}-
z;we;(5jk08KrC<3m?1ZqTohf?*f3<2saCETP84akq-YE|3t2fOg=@VN4B2^IlDtjp
zo>|=3D_1`K=Ymo~J`J98(ZOvw(NUhBv2|7NKPe<?O1C^DG4IyCs6A0v*3W{QS60Lt
zIOK(@3`^%gLkn{asy<b_FG7~2Pb_B@^uvrwRWK_mL9SMs#Q7^vFCNwy=AS3uy#o5P
z1p08lW>nxi&E@XEj5**Ad)RSODS;aRGo|1;u_@kC9N-S@rU9!#iCnP~ekh0mT_N<Z
zUw;^?{hv?R<K@a+Bva_`+ESA9*gZO7l;zBto<UYLduP)Zx_Em=T%yV^UG*gLCC}{b
z>hqBu-*M&3W0%QrL|<{Ng8X4>WQk?p*gubDw{$n}JiD*r(%1b@lvJ#2e>5~_pDhMX
zoTVm3`atqyL3*^Ywqegp15HgMZ<1%!3AIacT&TZ!nf4v+eve3ezK=?}apE0^0M|p@
z!jTIKQ;-efrD%<KavjEQwC|2r-sivgSfVzCBj697Jh<nwFEQkqC03HvgBeE29YfX4
z{W<ISYF%a7eZQ)e%C!F7F-*VU^h^92{yoA#^tn;*d?F2=FN5drrvD86KswM$Y;E`p
zM^#+-fuIUQ>_GY8OY8<rEIH7`h0#Y?8Cg8q?qpT>ls-M;%#&W;VaD1Bfl<X~^Fw=3
z0h?Wvl!nrpf>q=P(L%l6gcePu$B5M;iRy_c0TB~MtW~`rWaX8C;q#l|jrc<H!XusG
za9y|`p%%u*lIi%+Bg{IvOw$67!hl0`ppA-j6isqAlcvOxj*4+KE$Q62F|m{D6DA1H
zSd09&{J57%4@o^#UH#_zrP+$Y=D6zjHj9<P(WT_|2^2-Ady*-^iEHsag&FXSN&2r;
zU({SaV0#2sxSmO=7G{GBIDu$*zz6squwjxfs4OXIj(y}adY&<5GYV4tSd!Zl6UK@h
zuZYatUc5&WL4K5#qHRV0emlhy5gHm*z9*ICqe0hscJF}lJ@ZqI-a^kLgV=`?C%27P
zK)=X;;-X~8c>@~q2#*G!uNZg`;sL|><h&U%fxZJH<Zx{|HN(Xhv1ks0owL`*j(In?
zI;)?DjGvN)VcYAYlJagm^IZTtrYW5xa+J5f`}CB~X9fBEO^=$PFgX$-4LJ|<I-JZU
z76TtJ<KgyU_z#O2YXfisDmIuGIxr#%z_{38Bo>dWS4qahLPg;sAFq5C{aE^5nwYMj
z-D6qDimoll8)_mRCF`BZ#3^*l(^HIU_)AgB!eL$*d7~{p(-iORPp8&M+TlFN{m{Du
zGe#J0RP+~vc9B709VHdvu`1x5LCQ|3eKHL4TxNoGg7)mebtl#|-L8pFNsTv3gVTar
zdh(m%GQ2{4{MRpI`mgZ`-~D#qt_wae>q-(C)lCkk_W1?ySwjcw@*^~z$<j!XBv}_0
z0MkVhT6DJN;FMCY_PVyfSOs!wlS}J2B*1O5K`4+da$ZDhzd-LZi=FQa_@Jr4OD?Qu
z5^M{uI>fVF@K+!>aS)grtx{<i<n>skT^ROntPRpN+N6KDO5YmT^*PgLvbrKF3?_g{
z!k^2GDzI85;j#s6i_qUU5aptO1P0V5Wug42?$ZIu>kC`6d<-K&zOtpGn}~bD)ahhk
z3|r7sY}7@mg4p52<%YvBh22LKO>7b%MNB1m_?_VUp!E#PBJk#A!VY@i@0xGtc`I?^
zu^DjQ&<(f27f^?(K|Ofr*b;TPIWj)RU?|^5ey$k~^AD4<5NqQgZGO5W8qt@kS5;}E
z5~Y#W8^68hzayGZ`3q(2*QZoWPAKW65&1x!{(f>jp{1S+`(4yd;Y>Y*hX?y%sWUyJ
zky{~g`x#RSL|`8P1dM1f0kL{R`Fd}bF`n)nx_qF1cZeV}Avv0(0$MUpch}IDYL){X
zI$5Ok&or-)%=$o4L6SC%9wASq9f}NNzn;BFA#ti=U{jay;NHAU*MSVPJaRyaxS_-K
z1<$2CGTxd6vam!c*@>x64S=LD71Q7Xi7pI-odvj5+>ONK(qXKWK&B1!_V(8+xI~3s
z5a!*_&($P9*N%l*glxlXc7Z9Ws%ooGU{<<62U&X?V!|YT(S9-H%Km6o>WQmNX@bpS
z$*W3_|4HG`vIQmTG8b|a+(P|aKxp;(<nd&4OR|X_9?tMmTZ`K>?ldsai8Z=!u#6EU
z;~rR>0#@cyLf7^d<<h{S@GY2Tg#8_6FNoNa=;?S*oo~q^yaG7<V6|K=un6hue-#KC
z{d`h83Su(Redc|}<b-%{FMl@ixvtoz39V1RHzq(pbfiunv&x`J2G{v6Grj;j$CHF^
z=@K|`YIrJT9l)fS*ObA`ys4A}8UlG!dWV5O1p*jfkl$zrWqwilN!s;+i-w3YU1&|R
zc9IoiE3kV<D7?e+qPcA3pSlzw_CYqX)@&k*S^l0GK_{*Tuh$Y%KS?_2O*5gzy1gux
zzZTt;7)eCE&WKO+3i4z!x$UT~TNe6W;BBez6s>)0VX7BLDl9X9Z-z|*ye3c36E&;}
z#?ZOf<XQrckHH648ek@@!Ua~a%DNUoKy0Ui7u?H6ev>ei6kZw<MuYoLf|U6s84QWq
zQ|KF%fT<5^7DlmAAtqfE02dFc(0%W*HpCOsIG~lu3#F%<wPt-1Es*I$55E3OSQJpJ
z3scnttxT4^{>)tp30N4`X&mb&fL3aj>YSJlIWs15Zd98H4X-IJX^=hgK~&@`b$9l!
zQHPTsLKIts{`E>`UStSgR<X|v4kW^lBdN<DE_U8TKWWrTh+5EqiJv7Sb7`N`8=yBW
z6WcSkUg}Gsgdtm$Em6^w!fi&@|3lb!07P*$kMnl-=>6#ZXh%`n!O`2%d#@Hynt&7m
z6+xwF?4qbB3M%&Ad)HVJjYgB$jVYFBG%+SIHrU61-tK|=efj>s7=*)pW#&zvd9%Fv
zrVl8SYgmFOIAp<~wei4Q806sr$w+Od4DV=@AZ;xxE4Oqcw0FsF&555n#L;&|nTd`i
z${ua1p^mRgEUe?3P>Rgk##|^guyOM=_rurr?HpBn*)&Z}UEMWLmc*d^=)(E{iK&K;
zwYkX7*0BDInD&U11~~`NOAE<RTmlz$K>q?9UjWYd-nRe)a0CEi!*v$qRgfHW#6sir
z6#a#r$a#p^!MNJ?c>aN=jEs_)jz84#*pe7Ob5)Tu^&NOmR_wj8n`h5@j!MVpj4nW|
zlb^M<n{1A+GJ6-@vv<du7V)}<a$e=mj3lTCJ<0o*@LmB_&+uIq30-;9E&j`#D*PSo
z?ED&Z@brKd@3A&f`jIxSI>=(B;ah4~=<KMqUU-C!naKzte(IHF=&ELDg*FG;3SY&p
z{+^s04evcUP48v4LzTF^gAf1<#|1=9D49PlURn&$H1C}8QA#baN5n*D5Dq1#11Z3U
zv5HEN2%`6n9(i0=T^k!?r=(h*zBfg)t<oni4=nAXw9;{D!?mnc%0{#-EU9TzN-er2
z@$Q^uRhJMR6>cMuW+%o(SbzSDAzD7JD07E{wY9GjHFwUi#^H&Yr75X}BD<hb-b1B<
zWewr}v8i*%%{I}kTVOEDdPqWxRD###1crEe#I}&)YGU_N>zQ?&HN^#yICGcyR<K#V
zJt2{J)OvidZH^t%8q%a_ZDP88lGW8K$!>9X@jv@DOcjka&{KU)HMP+Y1#WM_CHdq&
z1t(WO$O1y+pf*TUN6!2lP4hIuNm{ZdNHvZxh#G@s^*|W>9p)WC;bXw>N!n_v>du-`
z$VlSlYpbJ|Yow#?7A4cQ>k3n}wAV0kHMg_bblWf>RCcp2L|Mny`0aILOX1JLkT3~*
zSI5*Fu_^|dnkXp1J+MrmEl^U`^TH`0A4u<EcaR0!m~g0|<Zj?{yvfTeh&Rdk(F2O_
z;PeKKUJif{4!|~5VM_jSU)$KCnvBAhf~00W3q=E)83h$8+R94Mk0RgJ9Dna>XdCH+
z@*-`*?QIiGJfef5b&OFI+8I?e!PkW{R8#ae6+5ZvJBUO_!?I&qu^;7aIAjQxI=~*C
zKwpe!qJR=X2a|R?gS#YAK2FYBLWw$|Pcawn8{D_zhkfhAuF1v+_bsRvD5@uvmrwDz
zw7|kC+&Vs%3Rq-m6crmF)-=<el$TavWsX#hM9srW)NN3pY#8#jwTZ+}h8S8W1X4Hb
zE?qU1iX6mVsVglE>`;H88~a|QtEpAz;~yeZ*P)@16}<?q7!%?n(ANOyM0Of>#V2I-
zhwbd**+$CEz-|auF(&lV|2Le$75XSS0XqS-#{-CXFBTXLKq8;{YAC*nTLP3qSPQN-
z06ah~^c7sv)s~m!DRq^`C8t<hE2gLGTMcn{74{kBBuXSRrVokIHr96VPWK*RC`Rpi
z9@e%>)pL#^KYSr1BsG1MyLg1r+SL{=PQq6cMvX!~kr}0NW8B0kG=AWg;Rwbo>Hi!9
zbdpDIxDZ=b@Sj#Jp<aUh4>a>3zD`UZ4)^->wxLB(7u}kXDmJ!D@D;l_6cmfcPs(UX
zO)SvXQdP7Sy9YQpL|MQaZ6lqBNY2(5{BXwDe)7b*RF8=y2-^%blSIY3EOvlbD5BR<
zMWZ5RlqneBmIg+enihWI;Wr(^lAz2GXhs1?QI9}gyAN33oB>O+hmbMiZkYqyeXNb;
zR+_h>AxW|c;F`JItCUiYCQd#!Cp#S#nrj3%s%ct=k1-4v*#<br>Y(BRji6-58t2q&
zNNsPCw+Fr!@!H&J_!yCv@yVI<OGeE{F^h~dO*BQirs{TyLC$UxlfKbfak7j6OLrw<
zlD2B3PgSwrVf#G1vL<ExLvX=h@9I$Geh_*!C@Fxx7TM4u8tRsXYKS?wb2__c`Udpy
zQPb-;s1biA2=4oWI>JK2gUIX+Fm5i4(}o*U#D9agr;Bt*@(Y5*O8ORvE0rbP2?r&z
zi2IS5i+^LWGn)CnY<6Dyyyf_zj@{(I-0xqkj!LPii#m>fdi5-$5Un_UR}kzIwRPlY
zPP*m?&>e|wg1RCub@9Y{s{-xVxBihpCprC3ne~D!sLLicC117Z>8;Cq&NhUUx!N+Q
z)Rr*ogPL1g@QtkpT!z1{UwrFV=EmRGnm(I5<!gj4(D~*bj$00*EJ(`HBVFn)?VGy@
z|AGJNn7NO`5x~mz`%{NIYjV575$SLRqL3~pFhVW3KoFfUZyUURc|VFq$y<=+_8;3`
z?b?Nu+rFY!ZC~7-T`mYNJAhkINONlMong~q{{)9>fI~F}1u~yLAdq}9YJDr{Vm65S
zoO}s_+wtUf_AUQB{SuysC_mz#wb2pLFWDR_nmxRpj$?M>aqVmkJV9{t3-bnW11&l1
zNIKJ&hIew1&UN~Hoe>xnoGl1a4PGk2yup9n>TbpF3p`LAig@;3u^_8`?;q1Ax6J9y
z+8K#EDb>-FowE@$Z4U}ZH4`tzJIGcodDXvkm5n*dT_A^L1rLh|b_LyqB=EO{S+Sl?
zTfd&#v7TDamI#8`=afF+6p<U9RP_MtUJ~flD}pY)5~`YIckQC+-Mbr^n8wE5L*!ZG
z{@<x-@GP`IB32zh<0auVy%*U#HEnFkzUn$OKC?$6#*ffxl)EQ?xN(<5g8xd|ss+Yx
z1w5Z0*c)_XBYQ&<#GJp*K5JXIj#_q(-A(0pVjtL_8+DDH&BH@Kg)su|YycMeY2S(U
z)M`O+FVr@1XD5)szXSgOywGxl%&LMU0@*q|brf#te2U6Z-g9Pq-zD0+Hw|W{D9n#z
zmcckULlHMf1mwdk`-Yv^iBzbRPUdDWv>oeR!i*(+M!`8g5;zKm0qk&+h}1BPp&1IP
zrXkEG9DL^>f0{ssj?g&g(Y%@`S<ai*Aj<_cPcogi71lj|JiefC{G-Qph16<%055bM
zi3F{iP|S&guA?xXw&~@PZQB<A`EoJ*&96&nlk~XMgqyw`)&WX5R}$#u)|7KLBdD8=
zdylS1MfGWilN`4dr>;4?>YLPLdi&l9bFiWySZ`>1{G>%;Quf=76b>G|N)Qh4h(KEM
zxhW`GCi3!Qpr8^LGRGh}B>!~_G<;O$ilfRF4#H1C{9-#ZvN1hT>jD9_u8;>6A28gq
zSwI7<ObdbafNMTxTQ|MNyCbS6TGD9%?$*VB{vijN;`s3~z^qLyH8>qY#XQ7Bs1dVr
z0P4rraWH<j9*vunvOCFP;jFR4qC4&$KbV+GnX!)q!P?fdBFYzjE=7$~0^Qk{F$n~x
zNTCemRWa}+WS2hBF{!%dBk53E%d28wQ4&VxY#@dyp0)I!-WSwOB%Ghu;OaQC^c%cs
z?Yy(^u2cK*)5*D27waA)F`B%ss-f)0KKG#JVeU@GLPv-*A1=!sesQ^bK+R@Xp?f0e
z{y*VN(*ZsuSf7Ip7(X3bt;1GK0kg9=mD$<O?Q>E8BW5-{2b@Z3W60?kBe?m;833Sl
zCCuy@)BpOXdB!?f+SzkyvUQXRzCLr>v^mI;w(I-$+~~%}(WhvL@dC^P`bClCQ9-q+
zfM&twkFfbJv=wa=1iwE6)E>zkCC^5}JFa)Zx-bTwl|K$66nEiGC-9H>$r0SM8CfB-
zEnxCnlCexvFEkeGZDLw_>zH|D4ljUlA<O|XRfQsR08hf23$YYkJdWG&XM5099B>R(
zq6xs0V?cI#v0qWEsUG%Q$^~%L2jin)yfWDXoIf`@3J+a}o%f?!G!X`Av3n_hnqgN^
z#r(NK4L&m##sE({Lg*c2l0FhKV|(Aw!F@l{xB3p#!&fod?aO<gljkXg%>G}XU;ZAh
z4=&J|7iVK}ZjPPYN`UeT&bgua4sIm+Ll>`bNY5MBv~5QNN{aTK*t9`;#p3g$%T`Rb
zFYsUb`OMMg9z!=ZolWr4F)DJj3SQ+DmADm;Lr95M)plxLP1aow>z)@V0)5MQ8ctS;
z2t#f$B~m0r+VRlmC)I6go}${`)zNiycwEnuX)`B`f#T^Kk7rJca26<H&&IB)mr+V7
z`v+hfaGurwoDQRRgCziZm{5y6jtX>4bnt*^0&WglKkeGYspBWzTDVMk@#4j?AtAAg
z^Rq%-l>L$>PWk=Lv{~^xYD<T$Se{!lRAk5D3iKE~gWEI5lU^UsuOs=Wvpzkedw%!P
zyrjvs+on$H?yjm>7!~+i)2PN3%@-cbYY9dRd+$@a?q$Q4;oSrm*|6u8^Z|%*TL1_m
zIc<AG{W=sT55|E>*^8nQy^_t&&uUK`S>&aBc*!rgzoy~(nWDU9=${EI)X<6b*-4fn
zx2*|pAK#v_ptj<yHA3^o6TJAqLbC;$93K%>KyHO7co3wdxj0A`YPNDxKzSN6!oPKu
zmZG5aOs2{(uflR#-&5LXnk7ot;c<Z1(lcPMrd;%lWb@?uFOVen2hk1q{qUjzdInCI
zH(z<_tffKHxvP$hOqo)%rFEj}qVC$Vwy2=zvr4hA!)pKNzzG@E^Cx|NZ`Nd)16zRJ
zcot?a!RKM`%fZN733!JcfaK>rYS=lU6)PQjWw*7{#QH^D@E?*;njO9o)oc<_hHEok
z3tI;Kf+Rs9%q_4KiL?QLX&8(`cI{H_>SCm8dL7|D9X!{61v*3?=AJW<KldLR9t;C?
zc-JnK_@t%7Gn7+(Yi!L=qv2!<VQ0oLqa`Al*L>>9G=gs+a{5QuGw?o0??F9J|9Azr
z6?J!`GiRa0@sfOeS)kbW1^OCi!Wh^ElEN68gHwW}U0v{rgJ1AH;N0pX_@UV2V^ru9
zwjt;ceBW(mKe1}5Vi$a?Bv@H^GJJ0ja-=kudPUa_@nH8*n#;VR07rCJar4rp9FpWX
zhBf{Z$1w5#!Z8^SqY3@~LT`t$q>sXYHW}bM10`*~NhiI%wC3uynlWQ)u3fDuU4!4i
z+iO+fU2s>fPhYTL+Kn627c8899gW7TFfSkQcDUzw;1l^k&YS}jCLNRyjkQ~+P3Y=c
zw2Fv_r%iKe#)5db^I&#!2%gIPF{*L-<gZYCDf<sNnS>T{U|vGMoL)sXq+h}RBHHe@
z6-V-ufmU1UfmZ8E7eoa<Yr)&m@rKUk^FPmN0xC_WR6WP!EG2BrpA&TlXo(aZbK+)j
z!_*yRSyJ=7uCA?fJc6mev})LKbl0p|BrFNzhV?(Ahky(g4`PqwDY+&dz~n~~3`!w~
zG?#Vn?o#gAeb3b*E~w$hyrMljW-7OBO_WA137q^hQeBh~ny_oq>|jeh9W^um6BCls
zBQ}mPv5p*Vqi(|C0x3xPUqH@lJ#<+mvXb1h2jdsaOOOk^43bdwg<1H=($a1ef=`>+
zRLf$Nl}%6xdNvKI;5XCo@HV#)kXZo3BA|h#06RxNAQ@q{0WA%pacS4OMfh^Jwey6@
zZ9p|>B$dVfwZu2Fn%V<np`!$S2*!TU%k&{UcO{-rbgL=d)mKD!u_Ee6vJSX>0&92{
z^fIEMB*%u9m?HRJVEyNU7ta^`y>`o!=HJ$kG1M2VFO2h|z9L^_ELrC;jOBQ8KpjgE
zefS)HkKY|YV{q3w#2~>z+(8HtT?X~M4voNmWGv7P*&|307%3#Gm_Ecl-nbnv+=5Jz
z1>M!FgIefHHl5l|)&et&mcsL&=wVvQ8d4_gpJ3NNqMT}}jjdH|7NG$O@=XeYWYF83
z@9T)b_Z1<L8YM`^$40PkN8ob^y1FSIJBAGKGw^=*Q7-Jau!KT4===9Dj=b;285RbK
z#ruQ*;`|07A>_581(1$}g!`EH^A_TF?0NJasf}AOssJ3#LZQtx-(t7O<3*x$?@;HM
zmyX|byBVO4<6|oX!G5vZN45{OH0wco?d_v!3ZHO|#|n|jLJfrQY(x)p0=N^w*E=l8
z;X3jR_`z}q!BB^D_uy{w2QADT4rutS9besd^x!@u?QBRY6V9F#7>-}(S+|z=Y+P?+
zq?KvvBHncf?$w2zJZf#=i7!ud*6+<}dR0Gqx*1R|;0|ygAfD!b`@~4@6N6nVsEJFO
zw;ej1OVMp4*^F%Pk#9zvEGfA>>J+tVTSs>m@re)NX-G8It#7(_CBQ;(8w2wKy?o*m
z$MmJqJJ|VDBzu&q6$C%Se?P<X<j;q|^Kj;JpO|>iA?#8rkUfhp(Ce8D{L?e`06YT!
z5nMeIhyYhsoL?;OZ_Hzfj~a79WZo+li13?!ybI5O{_NRsnM~JsXk}G&%Be|B|NO4+
zW{v-$;$w@!Uyeb(sHqO$7K)Os_3I`-c-BkNXvjluJ%T6q5Ac9b%>5C#<MZqTps)bS
z0{K%T*|h@53ZXaLn0z2I@ECa<eDICwG*;vL@2S7P|Nc6??E3Y-QUZ@5*fGBFtS)>Y
zSppEPA34XgZ~cr{`=)449C^sy4D?=bU&N8J2}bXSmir%}B=>pz2?o~!ok@0wL`aZ^
zn{de}vO)9)m=sZNlQ5hMTSv`fm&oxR3G4FyF~NCcUnW3P3Fi1V`MfOrJID+;N3i_K
z%qmDEVDT6D_q)&=`ZhGT_JKe3^i8&cTHFV2FY8TRl#dOAu^b<B1K}@07{0{r#6P1M
z6ooA5+kFlI%>~*IXpx-hGQlvw7ublzN0uL}!eG6++`JPk!^`pK_$*$IN}%c`5CA(|
zI%4VKys|OFJC_eH0pIu}o(cPsp$Ie)&&J1pn^HM;(%;XgRE=wbqv7eEA^n$0pKOlv
z!8!uSz%Pa{9`7GYnQzCh#Qjh3Im-Fzv>tq<I(&az&EeVf$_w?YF%WBZ`I9CWGaNC2
z>>amodpF{vXajyPF+(97Ys<ZE!0KNB`R+TWur@tGtG??}d7di%3LpL-Ag%oaZ;r0a
zvb||qkh5DC{2nh9h9=-S_~i4+m1FDw`W0ZCItZJf5n$tden$kFnum;dzr+!jd%uE4
z+>93;!WSs%%kir|Yx64dS~$O9UvM0Hi<Jez(fOY*J`#yaCOR47O7{Rb&ouCRcZ1(M
zl*bs{F4mF2ZDaD<3r^n-_`M*j2K)s}D7J&Lr`;Df{)J!vrSkwPw#!9M{;SKs#g{Lv
z`?>#?_UG@5WAa>`>)ImYmd-;xKTjA{h+Ge-Y3lg;l-lci7bD>}HF;V1hi-FmYOuAX
zk)@Wg2Lys(3*_XOPJokGrT`%q0PDmc@9_wxmC5Mc#$-Gr&&>w9(ue0jzryVbk(C0(
zo4A|__`o88KE4M&>5upx3Ys!^b~8}ZgE#mcQhH5~>^s!4ti6klfjNkdfw&T{XF<KF
zAb}6I#*3hfejG|dpnix4+-FQb;rHeaedkF$7Wf9ZMGaU{Bt#-pq;wFk#+~eIAmCLf
z<}RpA*;|M-ygx&4?*pH{&y;>lzBu^6Z~q{3U>5#=1Tv=suGe0}o6$Ge7nLF_h-~M8
zZ2ktjQX8lhI0_wM>tN5o(*iBn1MdS9c>ufC!sdV=eN=>o02c@MU1Z;)w{#SHj{-*x
zLCpdm59WAw&<CE|dx+Y})-nv6Mt$=eUHa_LJ`jk6kD~gY&_97q$oVwjHFG{NScTfq
zwSv2rJ>UY%`{0t;1N{@e=a`XRF)eEtn$*zxx^$cAt`oN^JMq2DrNb@kb4HG~@)Ref
zwjfP+EoEkA=npQ^_)~bwX?P1#nvby+x9+_D7fce<|A~#OM2LX%fdz6K*MmtKJO139
zu^RX>a#+6f)W{@!^;CA6ckHj|?!~#CAudcm4w$s0@f(EPv6~*i9}Vzqr1$@u4=mR!
z<O&+pq0$?dt?ga7V*P@ro4XtXoDy>yLj8M-V;tNaU85&VdHJrTI);@PI3>qU!GAg#
zL17A|5ZnKR(HPh>!PQ6hvkt@$fon)>FGd63Ub5s^K}OSrJ>#2^1HSDS_3QcU{7Idy
z7k-@I5`<>=DWLO4_yxxN8Ni+yWBRay5WHXoBm$P?{9m|t$~nMRIwXUk#2B-=n#k_J
zJgbvuF<!EH(fk+a9KI{qb5b2G`>E{rgo?>;f1BQnBO{L;Bl99+hfog$N+0{Z<P~h-
z`40HK4-BH*vI8I8#kZT9P+8+J#$GQZTj?U}LVbJD7^P|R`-{cv84bXxDcl<7GC?1d
z8}WR(HVxo{dGjbBK@vt|UeoL2>ueV`clo;2EyiOTY7fjWS4EciHk{r0tg_zne1|8#
zejatYdFb}_)=4r)b{1M|h+mL>&jT8E20R15gU*usygY4K=`hatrm<yN(r{2*4(pae
zOTkO+Zhqcu4UmGg32%UNnhuj3hw;463t=D{2BYKnOXQ<WMllvY_ad-Q0X_ZK@OsLW
zdltBrgpA-dav#8h)|(L6HpS<W|A`gd*@giDBSZ$f&@GtZ{hurL8eG>4b19>yT;%ah
z_MHcFaW>Nj9nR$8&6rIlE5jYR3`k5Y8jY_p{VanzaSabI+RyEQzzaRzxJ~wRX9#mD
zjsx6-r|~f^J|Jb#`-N*@H}%YlL-Oz~1GA#AVPulEb513nT#Ve&l@4bgz|p{Wa9^8x
zdH`7iYcS5R#((0Q^MC&*zR4V91`2rYA>$A9tI5U2x%+PejvJ?q2MjtsZVAS>KmPOi
z^Ur3_p7HFr&t~H*n&$C#&bjXX-X8fLc420k=*qKxg{IbDe{F4UYW*$4v&>x6H+)TJ
zc%Y7Dz8kDJ5AR@-V80*7&xrcq{o{{hM^pXIDU%2umM=Y#m&}O{moyL^4`#K7;3nop
z{-h;S;BuEcb_KHy_#5UWbk5H!`qV%El)o1&KVFay{5@eRN7NjH;~i*6EzjdX&V>Uk
z&e1dNNU!?HHy+q5?PzK@qNbQTs`(BUREvf!3!dbxxex{+Hu4jCC+x=&J`9?a1d0FV
z9dl7?ND9z9H?$o2X^p8Yyry=WlXgHz)7uR#d%j$3+_8Pj5MglmjK|1sb4F;)D_2vO
zc(G7fUDY)7yPovW&}YSQ&Uz{uYUbR%OdIfz??SBvNF;eIkw^^=%O5=CyTz?LlCv8c
zfUx!Pb4`=NAP-|@ldzaAXxBxgjNe|wN9shuW(1b$AmeO+=QtYUedK|8z-G0<cQ!A=
zpCcz@%hJp&Bra}3!zfURgtMtOG9DtO%upE5`N^P+O%XE`cjG;HHS)c2UG67;Mm3UW
zK@lp(!?WribhjxPp%{-J;0wo(fa&=Nd9S>H6pwXt-f|_o2)yO#)MWC-^8`o(CI#l;
zcp20`=x&$;ZqDM3=P$uYkHsrc&gW-QI_`vPLcgIa5XXXdyJKInSD+(T7|Z#~yxG9G
zvi<n<A~1NR_rC*wSr_HfOW18x2H9@}_!*nw`A>8<y}55CdV+`2kzk@cJxK{}A7lH-
z-l+b)us8Dlwoh`!Y6vm88;7ua?{A}x9!RtB7&H~Pf`M?3I>Cm)IGW_~nRPHu2O{1)
zP3g-ED{KIxU^+veYA`Noq9D114+u`8E2Yf3w?B+4-<UTCn;}m$|3qfTz9Q-L@AG@#
zM_cGshPC4#8j*T;c8iZalkuWd*W;T_t&KyB1;G}QuZpd7@W}Q+_I16ZG5d#^Q&l{V
z-<tlXf*`O(L9QXLD9pxMVIZ^NE#Z?LkX_S-CSE~eCNjBxImY|*3Xk<H8kK__Up;;|
zfAOs!P}N=L(V0jnavg)eJXu;1=@NOqaq9HfsIeCz4p*cnpdbQZ*5G38kVO%|3*tCn
zb(Kg!fPiZylnNpa9>qURUJ2yng*@8p&)wXyc5!M;*SmA*$@&C32;X`9tHc1(Xx6yz
z*3t_WI=xp=Mh~1F%+Fkh`GHQ565xyfLd<nbHZYg^+=>lqfWP~?kf$JcF0Prw{xKJx
zM%-B(g`eQe2gcbT=BOo`n@2@iu}3>MATKhaWDZ*ekHLRPp{D;A!CXF<OmIeWQ=|hF
zvEYRwZxKyOWInVE63i7Vox+co);vfSqpic&#3kVsmXzwWG1W6=arkxTx*r~+)|brB
zXZHux<5#WIaGtdpDxJ-K;p}3h-ZUEtP{UtuxpfH+3wRhw{D&(|phZGK0lvI$Ih(d(
z9r9e)K<xmR<^36|n=J$f@(BeDOZE)MK>PD!Vb8QgN#rdN+IZ9cru*<76SmiMH{NL?
z2p-?NZTxs9V>}ttzrX)?IuXWztUxrEmGtKG%mhq2@sUIC!Kz9dx+-mTxWwi#zGn_p
zZno=`afd@{;0oG-lL0}nXV?fi7sx+B_62fYG!hiD4(Nw7c+{EV4M@6S6SUq8W~Z`Y
z)aVTuJY5z_Y5B8(m^<fF+bM}4Lrt%=>N|nFHsI%T;q-dr`DYY0;2BQFko*=+vT8!4
zsDZ!QfOOf5`Jdw_%aPZ!gOnbZAzRgVn~v!Xg+&lWR69S1U^L7DG{8mVAkzs3{%HKw
zMLZ8bgu&2{EgeDj7ZPkYdYxhA4yGLRR4w>J6@p<v)0Qxewh~;PQt;9i0<XXeqIhKs
zbTQy-S6sP=*T2N?zqyTaUm~R)*(3H$E4!ZJkTqf-+tWoC<F<bM2U2_q0Tddk;$Hmv
zKuKj_1AacE?O;ju{TpPj6i2U9VXqnkac&?ssSRLNWJN=ldLlD|;CjrM!k*k|!dK&g
zdf}?szTNo7j_F&gqH5+a3L9oLljeJvh6u~r+w7NmRtI6;8puOe0xZ^CEt<9h^qSzy
z2Z;=@62eUfLI40Bkwfs(ihlvH694vwq4Kknb2ZJ2s_;W-DsSd!^ap-hJ?Vb?j+aPz
zR~CR=dLu=gHDWJb-9?w+huChISXZ?$+Oo|EG1``95GZ0^BE>t;Dq;WwZw?d_4E#1@
z{=qR--vb7C_-6wAS_3&d=<AILClI;$5e8;fmTX5&r*RK{J$VBN%Q1~{&-dX!uT8!%
zBDi`sW3i*TUIL*rOZI0-PkZ3E=h$Dg%?=VABLzqB&u;>MJHrRLOq6GzIWZ0SCg20!
zh~oWqK0n6Xv}fX*>uMJiHEt-o*1vW)e$L)=WHOo?8ha{cb&NiX@1I!v;4kLQ!3YQ2
zfan?X9QEBJzdk*!t>RpY>k$9A#nYYiox>j8oLmNb0Jl(J0dNwZ9B3cl^A=cGfv5az
z1B72iknNq@8_(>YOZNL2&>{G|P*V(iN-1!TfKWn6k5d~$LHdy>eCjV;XnJ(RF(ah+
zc}3>X6TqwY@l|lp3v(yX;=b!+WB+a#eV+D&`Od@IMA-4Ma2mKtP}TSJ;jV3qsndiB
zfB~YIBOI;}1^zjyTjBW+n2$UT|0`9q&1db|Uypijw4qG5*id|adP?s!7~RY?_l{@C
z-uu6TwTKQ?<KzR3hx|0Gm&<k_uYGT^U>{Y3uk8B=y#j_UWJgfW><wxywUT$UVXvoP
zyc&$>d~=!v#bLA>``N4w)9{^L&nTdBRtL&id}&2?8C6Qox1WVEAgg$pk3dy;6YQFc
zdhgOnR=sbn8S}nJR#0cudw*^hV+`8_y0e1Z!X?O$kWSMIcAQ@1#JoInV>eLGW&_+o
z-Wfr#54;F(nUnu;$t=@qwNNugR#-DOJnHmDRH7c}UNUo=vc;xFC`-MNmO2DOe~*UQ
zn`W+Wo1s5R)x&&fP;mM6QE6&Y{TNG=@NVay9Hlr(L(S6|<*0f1&S<ECeYwECZbODn
zi@fO@VtwE<DG?FNx$jD(K$8YT73_%H_^a>cRqHK6j$LKD=FX1}UAMn>eM5ECrh?(r
zL<m2&Mh)ds*~3zIUan+c26TeC2l$PKc<KVkWfKYa5igJ_2h9WSwj6{b7Kl{ShdFv}
zFV1-~war>vMYLzmu2IEl*=x%h7SctV;!M>$KRfVOw!Yey<jmY{$2xjq-8kGvLcBg4
zVBqV!<(T7bj{yUOy!Ay$6Ze}(CllUB5T<ONVYOOMYk$l9*l^@=XJPq>hOxC9N`@V-
zS}#!SJw|XfL%&|NaYRNtQbQ!`&HmxDV%8T|E6JJ00BlDg=3++tX|U`?FgM56u(o_*
zz5oRbGLrWeN$H~&Y_>{#^yK|pRIDZCW$8!DCUmZOwKP3<`Q?fGttc&JYHs+<Auf%f
zL3NvjBIDHI``+z45tGn!Z1H$!4xc`thl3yoPNJoNPXdq@AweKr8*d4*v*;j^a#(n=
z)YVuS8Cl@p_pjVvYEh~LLG?_Aon`3bR%SW5?`PU_GUUTyN`ONL^5HK44!(CayeENp
z&T>^9Ogb09N6r!CDgnKfKA@3)aolra^Mi%cZI!3bUlJc=E*$0^J$!y#RB}c~e&wPu
zLbvLQp5pxD6IX(L{?)^=;~l#EA=8%<Xkeb5wqW=2wTYfGhmC%7TTfn=*M7JFd|$y?
z3OS4dRKOU72<0?Mf2BFMYm)w|%H6BGffCCPwe?e9dIqvvD9s$tx#Q(YbAYK7{2os(
z4^E_-l8v{JfB}M*7i>U(=x@7Sb}!A!GXKzA(AA{BATpM@wPsE4p&2IEB!N@~duN2(
zM6hbXPKW!#RK+KA(d3@<pfO|PO;y<Ku^(|a9^W6CVx=4zRPA9c+HuC5Oo-3*CE>$H
z^DU#?+o|8Dz-EYsWNZOOUS<v0G>k3#7aDUM-<c7<5;?6rO_|eOI363Lr4{%VWZ2K6
zYcQ6B3&ui7hm#^7LqvIU&^+wEPM~Sy0D-`MB@YOKcS$KIs=+yv$~TZO1GrWE@FV<A
zLi%Gt8s0-uO$$(M*jciVQJvk@VAz?zcXjuTZllA~PdI$N<`s3-CxoCqU)nlJ;!HB~
zC9bV-03@TnbSX!x+*!hU|8<u9A|Ib6%==$QNoL~cGZthN;WI5hA3+XskQ_PIk~1~1
z*P`XWZa9>XzPxb4hC^$=>na$2edVZOR0i(bbM*LzgG<*YNRI7&zHsK3zb%{vQ^VQ*
z1Ub>$Ft-L5v*Y9+p*27P*h8O4zw3)ibGndCx8bh&NRJ4=NoBPgibjC&dx2-m@MMyx
z#~VQQ{o}i24!7?}nEU0x+{EH0F*a=?iaz0?m-zdxk{z?bmn9NN=vGlfB+$6^Tsro6
z1H9Xlh#tF*zFo7v__7LUfZ)|1{7g-bvI#d1oEz<LqY@N8ZEMHM?^ar#o#RQjuh6dN
z^Yk!I6LR!foDTX#7LyW0QbEl#{fD>&Z<WwlB4xLL%=}@&iA}!a&P<s4)%Fe>Wv}2-
z1#hSMR-dSzaA6N!x=L&+wsB5RwNx{4T`_A!Vai4qbJwkL7V0KmovkAaVeK;D$A^%o
zCy`N*R=gDEWHg~*5M98R)I&3Ts=#1jWUR7zDX?X2saa`IR}kGb6=w~1pJ>4mH2PyI
z$=ee?DgwDr;(t&l1@FD(^d&F#|AW(o4BA3V#UaXO8KU)C$Ct61b3lfyuG_i_q6PN6
zke@Q=xipYu^mE+X#zRJ*%nzlTi~-F5!H!`J*aIt8t*%4RzWPH(pFF!7Y=Rbe_CM_y
zK?_c6AAzSW^jmF&Cbi~*Y9)F7i>x=SEu}7zFBsqd1*}ElDxcah5KwVM)UH!_<0*6(
z<6S3FHV6e*$T5)I{&(n0+=KGDy*lCTj2?{VVih*v3=0vX*LP+c(%7_m8al$!(j2;o
zO`&#?=lg#F8d?C)bABsPAjF2D7nra~l%qLoU<zr5mmq+u*yPEz)OHd~q55GY^EcQ%
zpXT==Uhy|RYr*!e!bfQn)Of}pvYf{F2^fgGDL3{S42775JK#qQV@b>c;yQ5UgWNNM
z`?HYh=WK6*^pltc=g$l5QFEK}#8T?^7W{_&8cEUp(+ykjF68ZzwK;Cj#IPvGVE-v+
zvOY)gj8T1;v!!j#n7?Xr1i{kSpQ0=+@Ci3}EJ+vJ;@Jddg+lPV%OF>63Lj`*cM`7~
zatK7nL6{zT^y-SN1Z8pho3B2aF%da_|4=QqCv@y|+&91D@$ZoAQ)B+XmkyoT_B%d&
z5Pv7rwU{y;eB+uv#DLBrFdhLI`5NDkV-%3h)aIQl@O}hGj-J3z8n<B=0BGZbIVV%x
z@qRp`_1kro@!LyA(o+2Mljm-bD02(lShy1<_SNgTZ0Lmjllj33B{V{Kh-iKILIOQc
zc77-oDP@mkQ?;IbX;6R_{1`v~1<xSWxBNI&_=!7f`8Xs{m9opir~oha+$?;740-k;
zu}^UINN@>o#qpLLSG;k<g(w&vU68~RT#C^<^UKT5d1WI`xp+n5S6)>7GJNL|ezjsN
z`W0SbY|T8uH;<j#^ZH0ilmOEB?1Yj@Ga%pAg8r26jpbp2&>X}hAgDuP5-h%i&(3Eb
z%mZSQ!i96nd;%Ai$Ya-l->Hb+0}cNJ^hkUh4j&(45{!lWz3cbfSq<)+AQ&?H*GYz-
z&_Mr={^wjBHt0`~84Rd#A&E(FkrzhrjTGO;?DhtKopCws3tgw-D-s~%hTk3-fz)mL
zlJdR}!?<(km+zSpf&M0YMuL8}9JS$%_}c2xuxT$8u$WZYvx^}MBb|@4;KvrKNj{#@
zf$;*O!^v1i$Gb0!fZ6{H3S+o@Kb*DVMR<mjClGstG9h>p;u04DG3S58qwY5S0^w#U
z8ova6PcTDYV5d-P`%GaOlJ%Fbqo@gUz_|l%5!ogZDr&+6FY(w%kouRR3N-u_H~L<m
z9YA`94hA|dg0ufwFbsGVGEbypd5}A#a7lx_Rg>r(_$|jhgra|*GVO8a7r1xn%BL@2
zPHI^X-WwXzwxq7e(*YST9bfEWM<?OF+YiP>OrMJ=RQ(oDn~Q&0oH?p0fBA$3cyDcC
zR}Ji$=b<<bx5RFPEHPZ6;pKy;JfbOx!;N^=!V-=!ZoZtf0q=OZym(>9@JjmI=lBjO
z2nf#T-H9XoA_*)|4?tkCPyk<nhh<Pvkc5|<?f)lWGZ(y8JCd2E?$I~}uT(X{y&bE5
z<v?88gZF(5Vv)p-PQ@?pKN)FnKLe@*kg7%K^f?guse04bIvYP;lsT$0zjHzx-d9uD
zHEs~r>_J$y1waWLv{q;k)@(cnx;w0Sf2WS{D5Ze@#9O~VH1cFi$|(9D{ACmSIbS4z
z8#m)h2?Wc?xg&_liXi^r2p>SsiL8`>bNN5y)I?T<=0#TCaE{~;7m=|Nh=O#tz%89S
zNZqJDIQ>NWX9%4<jK9XWe-70<519cMq+wD!_WE;#e%RTMYy}klzI%hMv8$7Tp{HMN
z*Mquo1<38dPLYwDqh;)<Z=crYlD+HznMLAvpqDtAMLgv~DIU>}&msjp5@Msz2I~W+
zf_#1e&q5Lh;t&jJ{RWXjUb91W+=H{B_)Gi~`&REP3Ob|p>}ALoK(a^hlXs{-Jd=*<
zJ00qJ8X3^sy0?ITD42`W-9(}wMXK*PUc3c`l~JyI6rxXwen<8Q;dtn+I>2i*90Ra3
zj8JZ7!J_lQ9(b7-ilxy56l#YKaqM!uFC5l}Dg(aK0QGMNIRAn<IQ>nA6KRG7e?c4~
z1aG;FhvV(gqy9X~yofr0MT^;C=q7fe_EPh47&^h9+f|t34$Q&FB49X~;SM``5<XXp
zZ=%#)2xMR1Wfr0tbR2t~8UiPM6UMl~7*4hi=y8FYw6B8tUD|uti|$~vJq5wP_AUJ7
zF<l2*A9z9=ayU6)m)a9a#>XOnEI0#@FBsr`t`DII@RrDhumRsW$7NjF*XBA=aTyL#
zRWS)@&-CSrx5w`>bv|$otyjxavJdjZ<L5e0bTpZjRe0lq*;EY|H+|KB(6PuPNT_0?
zSQ>iQ<*Bm^F0wNFQC-<UB9dlBlYNPxmY@*wr-S+vEK*KBf-z2BU?dMkFonxkKIj@@
z01-klavZaJ7SzFASQ<H|JS3tcIfAOg?~k98R}|pctGuzBabp?B7l8n`BIMy9q&?s}
z56S}K;c_*8jAF1;Ugv_$<Xa1;I|Z-baH+oO++n1;hc0JpOGYiaT-_Hvs`xlk+1SP5
z(ii5u40|@?Dqm?uKoxI;5_Aoq^uMAHm;X@~2l*Mh)TCZDH!^jLinaA<Pl!eV-%qO@
z{#kI?+>H3{r~;<H_pX&0pif7~%2h`>Kc|Dl@}ca2J#R6-blvJeg0mo4UkW)}J<h6u
z7z7uz<F^1#5-4a6b0R4tbzsww&c-bw?_J;CXjuvucy&+@zSq4!94!z~m7~WCuR!rZ
zcJWueC;^|Dag6xBi1b9DS3&K;V7vjs4H8HIh`4YAdGiCk%FVz(AU#eWJsNUvGrqZ{
z3GQ1vo<BF8dGn24c)HSA)`7Zx)@aK%g0FrIH3*a747fTK(7+suKExWh*duX3KlYHA
zNk@G*EO~uwm5Xi1xK-hS=FHq__~5LLKUWUZ^OJ?PB}cE08wF<d)%Rob9Ul7mcr-#a
zg5SHnpUWI?T2vM+TIvf+11uu27jogO<o>8=AhrMs2I5^-Os>XUe7(%LDQa9NzC~!O
z^z=Ls8<)HS*iGnCnd_K9d36HdJq!Gqb}rY?#TUSQCQ6d{GID|CO*MMr3!W(1rF=Sm
zsMU@f8w|$<`7!-J|J-}^g2|UdL#TT8Wr0Pu8HX1Ws9(7C@qEIMa0Au}#29Xo`JUad
zuc+R%EX&Q%Ct!(V_byj5A-oN2%=+PZP{x4vQR_kZBjV#Tq!xk5BLsVr8!60wobei8
zJUA_!hj2H7$PBJz-=NO%_&#6Dz~O2DK6#wsQ^?wRm>waA%LJycIdJIj`{oszbKvl}
zR$K$;Yz3QvSi=Wg4<cPC8jLio(VBy=mz&l5)Gos}%1tNw*1!SWM2<$MTTXf0U-+K-
z+A9Q(;L0S&;cx`#%6O+d_)ZEJdU^)V71sK%bLEzRbJc|D%Z#Q*!t}Rpz_g#wK}ysm
z2phq%mb;e7=OX8z5C}C8F~CncoaGC)4_JtU!3I*4NGu;tYDk%wja%`H)71^bMsBHT
zJ5}9?FRz#oAHA|BCZ3AH|7_cxJ?hwrC7sc3nR(}S)m87@Rapy501tc%dF2AwFJHe8
zYk-_1Rt|>`ehEJ4$`o|1zTZ}s4Z`0RIU4MlxiBsYe?df@G-**%42Zfn$Ir+sAac{b
z=<>#{M&rkFaQMO+4X}nTfrIFxL1FY?K|H1be~)h#x{Z#_XitpVu=3_-ReJux;d9dy
zRz?<bIqn^nUY11sXr9<FbG&6SVeG0N(i0E(iSCfsL-76-oHGXn-61m(XV+FP;EvJq
z#3BcvvR?*@B7h|N|ACr_A7FoC_`t<6`MQUHi$loEr#$E%yp5;tJG;LlqVmw(i+xLc
zO+8|(YQBh7&s!8(wQu&t2XyVT;^97GkwfUjeOa=YSI(9$ISwX_fwfau-GOY9J4Xt6
z{V(VUz8-?uBOjs$9EFoOgovgiT=4S*LfJ+xWrTSP8(by@BF8|w>nz?!XdDP0`sExr
zONt}NnIeS@ki%WzPeYtru2Dad23$}WCf4H!hv@?SdDGw<C|uW^i-wdN*_ehzkLyH^
z>n(%)KwY-X|HU_eR85q*1sUoFQf+Jy%@`9g0qfKQU$?<JAM6^Yjr{`enupxO5S$hl
zm5|p@ECd^f)cf;31ZUT9HihCLs6D(82*%XsS;)l{?pG`Mkm`SkOZ-O#1?mT>&5$`h
zwQHC|*a0cwGaV57+J=6_eJFS_Qh_se$DYUxB3U=k1^fhoq9uEF16o`GbASy<D3KUr
z%!<By_}Fiq$R!!&aWqy$&t}(ABjEXdu-zCXc>WWchEZ~2x1h)FeJh=*k=V_R?%K;f
zzkZO?zXoei+&#r0@K^1)UVQNWMXvR<L@a`?B@o>j_>8#hqk$oU-$Gc83Cj8-!$~(p
zg1bFJbR9GP$R4T_iB#21_5A~eY9Q5cT^BsRy<H}gd1xp;e5k15A(MG(FiewFTf@S;
zcbcLGnnLYm6A7F&>5{{MzX%-XK(aif0~Yr#GpQjdLE_$H$4A;omjb>pLw=p#p1bT1
z1sakcSFw+Bq=vCWRr7PupPdzTk)b7xNog0NWTWwK567kCx-6)`SCLV5QYNZg`Hf7f
zu1GWPC{i|}pra%`!Nxo{5B2B!NpVDgjD1_V6l({{$Qh(UPSP5D0#JqW8YHm%NraCR
z2i)IWR~!&U(B4Px-f?aNm#QJP#ZV4tJ%7g5Ewd*1ySVt*&)U3pvZ<1>txQAP%~4BL
zE%N5X!t^0x`ym;HlQN>?&6TuN&Fm6T^~So&sZ~2>bau|zUNyDUPt`6LUv(22>#7Y!
zhDDi8wbN&eYtAf!j{G8-7;;c>mVSUoKft2_kucnD{~L{bi3{HX!LM%CW9*;nt{(xU
zk&Dj%GOM;TqvX(c-yIl}NiF^7^v`f+iWFceJpB2Ew_mJ0*?aZCQoxBTtV3!_z{ar~
zJS&Ng^@qda-bflqikbme@)wkX!vvrC;HW+mVJ+?JNb^z4Q5CC>N~8Uw)CCFg>=R^(
z664~0HI)$lnTk`_agEFMvXl9!!7ivMnUjv?mekxj9A>SOntDIgUMCU@m%8a1B@;SA
z@WyKe2I4V%S4SIbZhi38KH344H*zngC3qoy{XX8aJ|j(tg%(842qneF`f4iT8#UR<
zcvV`Vnv<%kqgqiKodCOJ0>}=W6}2^#Q`7FHkv%v^$YfDuhY{hhLw+wZpc@aM8!$GJ
zo)})=Ywb<c)hEP5UTF&dz<ZPbMLKfIXFN*clj)+Ko~dJ{&Q8*?O+9V34jy5N0a}W>
zX1*aw<A%rDT3Oh{4zC#>F3}vGos9&;D6J?OFUTEU*IKptvlU&fTdG<M3V?iuhl*q=
z65pzvsTECA%9@5%PZ~Bm9LOAS=M1<b_gz5R558HFl)HIIz^atLS`tWJ$J%D#lsT0H
zPyFX^xDiZD3jRIWLo*S(C<%2`hQX&4ca3BvU2WwNDM*+i(M&|&Dhah!h9&c#xTj>Y
za8Gp_y~NtUn82chL&L+#?{EY<2EQXe_Fe@~U11{#j;~?AhJ*X{hilTjupnX!&YAu?
zoo&e&_WSR{(y8Wj@*U<6W85R)?_N^p(%Ao$eg|`a%}2NePD$=~5ZVCnAif26;s<7>
z-}z{zk1t;~v$$!rgRgFA!{~sJ{W&?PEtg?^)M(UKwJ0~uOV(K8<6x)n>+Y3LPmkbn
zD+SyJ!a7h#WXDTXD5)91?0|$Fz@tCnUwx}XB=Nup6(V<;!1TRo+4%BhC2cLG5$R9U
z-L+$sv^AASWIQ21qN};-SJRz!L-8Io&R5Tt08828ete%GPNL3m;*R{l9;Twh!ii|c
zx$Jl)k`5s?cnrArL~@W`H=F<lj1KZNhtomsbye5)?>m{2oucZhUYLSv(sL(MLUnDo
z*jyK(u`GgP1%l+IZbHLUj=q2`m<*UdW)KI2nrt{{kH<PqiEVT~Q93%D2?;oW7!0)i
zf!2J&Ajs;-@k20@k$oV`Ug%G0xryUcMHVg&Ci<gu4d?)&IQu}3SkE7R$Z1S6V~iK+
zm{VFq7V8f2ZOn!N0lM~}o7^>^Q)<|<+Q-f*?jjT9flRY{pDJm%^Z(*be)3X@#i5>K
zVrHP@Qfo4x_o@<HrQrNKCIH|W&<g{!BZk{5a-R8@lLZAj$U*=J699Z*rR(HnXsV0H
zQosYs!&6_U!Y`F{b(BY>c6++(q9v5F4tz*?lfv{8@?RUSsjR8(&cyZpF6RjDU@hHx
z_cPElF`URBN?|<6A2pCa#sfD4c_fR;%QNK4i=?k;d3iZ$?Z#PKQbtYFtS<k`l~J{3
zn%qxc=hd2Pc8UY8T?-KNe^cJuN1l!j42(WKa{IU227cTIH7))RBg@MpAL8@ece0Nt
zIQOA|Crjuu3tR?-r2|a$kw`K8Kx6XyOI|q*{d)&~p{%c~3WDoVuCG?QvKW3uziofj
zIWoK9*|Uc1k@Sx3PjCf7Q8LgFP{2e~#FK6H@lov4=mdfTe44|7&0rtCfrOnal<jkJ
z_y54gfC+6$>>t34)#54xv7WB8&2;zR|A`@eVF>?FW}KlW!POnvMX{N^zFP1L!T*6X
zRBLZe9$eutI+#C4JvhgFz+bRJtei8+zCB6(69~Car8A&%P&#vvatTVg*F}&{BG3b^
zL-Hlw88rdcO75YBN0fE7RYv6C_t_FHpge8W5!q<Q=E*aUCz%>hAx7{LE0xehynb|M
z&Fa-PnecAUu$UtMe3cc&E`iWNiIda}U>|62blLh#V}c^3BedfTHi<3FWz>lZnICrc
z2epC}#sVzLK$AeCa$Ab%5*?7Xe2|qBxANdBZzmWMO8HbrLUr6gP?k}iT)*YfOe5d0
zL}yJkMeVG@l@*C;|72{M8lTo&zvftjp`R?lPD?{YNjL0fQDR16oaTlpu4%GTG<H*U
zMNv^Mvd$H1xU>d@heej3^3`z`XO5h*dd%pOl3e^luBMu;D0Gi+$f&p~J=)ex*Gfj}
z!$=JRM9TRNvAm5jNX#HFA&f*AjUy`wDUH)-LK0%}4>j2-ctT2c4Zf$Y?HXq!bft5n
zK_U}dqW3CMNQ`@(tFCeCmOyQdK^uYwe2s&(z~1^)KYd^svK;6wo^`!G{GJ)-qm@xL
z@xcE2YGtw7s9a>0>!Y2%0<0ddE@cPR(Zi6bTy3$+N9J^N%sE261@4h~gZgEKzhqll
z<~*i;hu@HMBk@IYH<ROF0B@kQMT`anGzT>&qD=>X$D}z4L-2h~GXo!g15-`>L#WVc
z*iX5R!r&Wb>a=dy))1j1d}dhCL%p*+bu=`!rOX7*Re<00ZLP|vMygZ~`33Aj7xqAE
zMF}D4iD{mFX?wAaB296kjaD2~mtuG~8|mXJ<c)NmUWoRPvj>s9qtjQaC5IR>rr{bo
zl#;K%x=BEi+N$*2o!JuY_*xxGV6GfYYZ`^fjF67GnMjqQtVa=hWkmMQTn5VUdZ#6L
zD>oo-?`j|X3jZb?lE6&iZ50Ofbxn2gX&-_NjfS{MsFW#FJIeg}sC#nRjNm<%ygk6#
z&zzQ!s1dC;pfFU>hmC^i1t=W^4a#hJ`zkQ)uhfFuUyVusE7esi7TMu<O4{1Wd1-&A
zjNIB)obq>?n|AD5<OQaJavrF<2(%Svf|=^2&QRfqC=OW!K8-?v^uQp%`s`6e<PG$Q
zguRiw=ne$WU<!Y*mw~#W67|DQK04{-Y!`gYb9fSdnl#)KA9Kl0dYxpUCwcNjqGtg=
zGHe8!kE>w$2-HsX!1tkAD(rhoQAKMgIopx2rU9&JMI@Zu_k#{4U>Xnb5zrUhO#(ro
z&luQv_5Gb@KwW3QOo%nsb)_Ds8L&gB5edXoh_ka|9O`n@HUk^M&%L)-4ol<ZXk!20
zj4!<t_*OC~M>!(meL23*5g{ZmPmXPM3_R?}Wk7jl8r1gsTI+fraG!i)R!Pn4wZ9_#
zmAR&yz|=nvNw<xk>9id$UE6#)J|v|!*3DMtqM;O?5}P({Uy78uhiI{)dhqD(#N2h*
zO}l$PBa)1X8wyQVy+KDs!oETU<`CBf3tTQ03FN%l36u)WK0pZacN1(#>y`mM9Xh4;
zSX)_4Y<^}|x2JW@>irG19kHoX3wmVHV_LIP(bbdl7FDQbW-+qRFgpou9MduHaBFeZ
z!ci;7X602D1KwBl|4l#TaKhVs)(U_OT@jQ~^6X_#-X$)-ht9DQ{nVo9<$3(VwjO1m
zU~i{Ds6)_>!@s4OoST;doUNoTiu={leIqhFKP(qHbvyaEnVIR`2#c71*(XXQfL_;w
z@LG|)B4-VQUpROW04Qf}^KgU0g11@mfkU}*5}LizUt0~;tvJwF+t_lfZS1IY0)2ia
zKDaoqH9Ivnb@JGxIGM~uH@LoI{*jY&+w)K|fxq`8GF_gxu%h_0mf~@Fkm`cHv;q9@
z0DcQ1%{i-=V1OhY!1@O|<XV3L;6!!GeS7+ysPfN?@LpK8GiS$@+q<!?Mqjp02~jcD
zQP#AIUvBWSCM(V0SCRXAq<`^qWIAo~1y@ni`e@ammWpbxkT5l|7VzE;zRNR#1J7ds
zJ2-{rkgFwL)+g-7a~rP->1R@VTOaBwVltpA>sEF)dptY)?%mAn+a-CkzGgPt`}o+R
z&4pnhY`H8{7D{!5gjG*Z25TGQD>8VeL^!<{C_h*M*nwDKTq{lfoH-H)gb&z8oXtZ*
z9PmXbkE1?B&OuHKd|z9!^(O}t?q(;`3HSB6)?SvWk?$Pt@nT%ZuBPJ$XC7GP;T-<$
zg4z*9Qv#hmar2~%%!&0Gnf3SQ#Vj`%GQ=P+B(1Y@TvhpEI>b&ABd{8t*Z!rqrA3h<
z9g;C~ZLHKcp?gtYSaw=)=J>XYA+aWKg)*~sT2^LLGh0~>b;s6DnHetD*3dJH-0OyW
zLFPPV4R|nMPjDOk7t9inNgp9-SK`6sX5u4RS?NYr*%RZVMrNktZ5dg4qcXC(qt%#k
zn~?s<?9k9q8G16@!6zrZ0Z*5~C&nN&Y^b&=t{I0fV=a!Rb^*d~2}~jG$9a|HbU8E{
zAUItRE)uwX%6;P&mv~UCf`$$W4jwWz2>GV44Jp}(ewmYsq~Yp<pR<|WLxZ?~?k$4V
zs18}Ey^a+NmLUaqtRkrk+&Xf*dSD$PoG!#<;nY5IVfmHGk{{M{xU~b{@^!TLWn^Bp
z{yz9wW;Qg92A61H(f6-*++XMD7htchu96a8K}UpyLCYw>Gx)JgJm48>Y6oKlhP0CY
z$A%D3yF_}Sk9<hLhK&Guz~-3v6#OPptQ*K~FHKLxTaz+NN-~q$J*`o$s*Bp_B$S;(
z;x70t3RV%T<^%5C)fEwn@7Yesn=uFrwUe-#D1wrOL2LHccoaqCJW^-_{J(>}=@0G=
zFfIolHUnk8?~+;1q%63w_iIK9%JH;9hMDAK$ypLH0dqjkju}U9CU?o@{yOMB&kt0@
z>FIy}l^kr2X#h%&vc_c`NzXJ%&ULrf&P?yh$kI-PA5AjTk7Q)o+Gk`%qzEz!$GIm@
zKV_RmHbQAEElVxI&4j={`59O`G_k4*KVaYSuyXVc`vm(?ehy?)|9^V_Kgr!sNBw`1
zI}s{Ix_)wErxfOc{Cp4cQ;Vxo9}J!laXFx`1{J83e&5)9?09oyWApLj%?(QuGn$$*
zk`ppoTQcI&*C*$-x6eCyYW|WX^LI}hT~=1mI-`8TgfgNpKz4-!j3SbAm+QxWV`T$A
z2}Hu1|Dq-Hva|4x%&a`3E4{4I|4^2=G%O?}j7bU!vy=X(wj?~~27Aeby_oYIBnBi5
z@Hml~L~p=1;;?XvOMVWVx|TAT8MrGWqjda^qfHG+_0;ML6c;-t1MiB6ubwq>SV~sQ
zxXpM*h%6LsZC*6*#A#$Q-dH0kr?-K+kx@6Su(W8-^y12cK%2vXHl1M)ps_ePZZ9Tz
zwSU71NOy7}m~r+LizU?diqb!_ve;`G8M}66Wc-%HEW3G`wh?>zh$q(W#Q*R*Ll&B)
z;jRXyC(u_E&h`PE?Ld436b5IGk)tJlBp_o3qM5vs;9|byS8}}oZycf@%&u6o39@3L
zarPQYIzxQ@Ymm-?O`8ua7~4HPU)d)#)<;9A?J{R%bm;+P?Q#IAFNyU}Ny)yNt*PW#
z?%=$%z|qDgaOrHB$B-e}i?cl9bUX~KBI0fRbfNA6DNF_1NrhR<<AQSn;Ke8dN|QvL
z<vLZ555)s6R7&z@%t=l^o{@DlHWuZlr{kUtoqCEYnnU7|W@~axblfaTH6(0TcJ?mN
zr0=^|xT}L8A!`kVwQ?c10#+I)6ToHxy)nS<AXx@|u#bL6)Jk@DCMsWyuMt%eqNVI2
z$|;jY=4WJgN2)UUnKD^;3R0l#Lc%PCcI@#i3w>|DG3a7Qn3J|S2zuy6+5ZOUze|2o
zLQ%}$2c$oeso(&DDGsMYl#2%w>aCvsTEpEV*Z8%Hz3T8pq@3iXk^KCrimhsH5>iU0
zvpv-)#ER{$W2sw2dP*R4!X`pRO?W7*=LPGLd%uuN;CxPgJvdeHwD`gddolgN?Q=##
zi7wCZKoxMa5q3e`s}vidce9F}o4=)&gS~)Kks7I*Mo1h~T77h_bN|WBEvck}?ack0
zg<9GnMs(Sj+}zhWbgqkrGGg7`tnGByE_VsJn5#Y1%7cP{n@cF1Mk^8rxM*uSZ(B)C
zm4%WsNdR8(gS~=3HK>Qclln*vK^Yg17S2I6^yW4WSR%d_O|-sW8h)2(EtH-*qCYGN
zze~-^LMm)#Rx(megv)p9R(lDplaO*sb|x5a895-H!Lo-0-a8_kp%+sih~%Lf%6IN4
zX%2-wLPwv?u&-#46Tu(hkoT84*+6tM-){z4D}e>Yof+92_^e!j^TThMU?24~e9kF$
zSar;pkq(|}6+!A!{H3y<P&F?FDJQyXBwip<O@}UJp|0w1INKCBTU7`|k8DUSERG)G
zDK^ztoM5m_M~&7%p<$sUw9fWBWrU4KU!pL;Ai-f7;1KGSiM29-Lj+wYA>;b5-j}(1
z-<2dcs*C*%B}5y5_w`e<D_cN?#>OTm$B1311{I->YF1LYpSDJf!%%icO13;V1F?2$
z8+~f9_YN^vh-J;)QsHv!yq!xB#JODqJWFje&08IxXX59V=9lAd;iREsY?{9+ZnS~F
zU#4HCzony=t|9W$jr^w|UL4)A<ol55e2*z&eZ7cRg|W85%a=b4iq3Oy7y_{NSAxyd
z27BN=EqR>?>;t4EtZKlmC@-@Z*b%&D&wy%ExnxsaH!n&O65<j&a;T&rF3{|%Rzyy;
zv!|nmp+)n7v<j+MY}@z4oRRsaHX$xy5$Sq{c?ngthrf40vU^dozD6LTtKl6m{oH-*
zdWeB38n+C5=6bj(8n<%iL2N4$SBAU>^bzF4b^1WIM5vMm1kjIz2`D!3h}<{*sekk2
zVDE}?k|Rgxb9CN?*z(>vg*5zE$V@0A`ijg|A;^ZDH)MpNT%71-(o(&m_iOZ>hD4^3
z{pPhmVrSR;Idz&1f#v!AG3Q`?MdQx~KO1tNR}6d>?BPDof&sLGfB!Rqi69+p0K<W*
zR}o(kF6C-owdEZkVc(>$w!X+qA~5OM0zHfFZCkT?E7V6iY*~q~;PX(|7>NAi3h{%&
zLS#`$b>f@Hzx?7jq~lypfBp4o{GJM853=oOO;{M3B$LVaO8vm?W%l6S)^nfd4&V~*
zC}xpL4iOlhAS1mX@nT@8FaKcR&7lOEWvjUyarOSeXB}qywdaf1I9N@#T&#%Zs0Vwh
zqXml<6$@$Wz87kOLih;@nG?3Qz3x1&6yI{|%^zH!#|>Da1UG>HUGVSZ?mem3;9B63
zNP`l0iTndbAhl1!%~tR?$z674Lm{oNHG@6gq@^b)&}9PF6|mO|3MjXNliIyIbqgt4
z$-IH8sIe2!`)0s<rFCbad40Pf6SXWi7n|Zdw8qyq!c+uaCfTF>d=!lr4B~|B5%Mvl
zLT7-i!0{Zw%3u$4!5+`*vEJTetGo_j@57$=yuH8oI&wrX;m{#DkpZ~@LV(zcdglz#
z&gUFH7XAlq=yA1!q$=nm+7M78D_S6efWyC0gc>x6x~5J|WM{+8ROJ4j^l+EbWnUDs
zCx{Fqcz(#kglJ;xd&8@8iDVV>9K^jo1B?NXH_XGp-UC)@=rvYUvSQ)_3(RZsU;lyT
zD5+o?4Szpsf*B=Xdu>$JDKRxiWr!8FdX^Z56;;$URN3nxNxu)AGt<YxxnvNhse))e
z?+nfXF@oS582=w|stvy&f{pVX<O-7uEI@5ks<*y@0N&78E&S_AKyPr+`+&#)Xw@1r
zj6l!HHa210s<LzkyUfy+;}YW-v5m5(h98!&*9h(@H+02MLqo-;HY4Y=@}1i&KFi63
zEdlL8-WmGt2ZOBh<a5xlxIXM>@W{Pjlbi_lg4e?G(G_Tpqz|SYX&@&iZ$%Q2uFoU@
z#=PliI`&lBR38{Lsmc54(Wai&t%sjVTk3;?CN_ILJ<`&H@0dGORyx4jJ}Vr|&BfH}
zO@&FiS9xi4RX3?{)5f9{?W;wEaEh*Krxb0R<d>|^eq)g6w~BJrPxhNM$q$M_<nnPb
zhuhANa2rf~O|W;#b|?;x0m|jUAfSNRp`#7qqmQ7`fj8j7uLY@=TK3Prd*c6hU|@Zt
z-{Wf)<zg4Bi*-GZ{Tl1xSCjpo?619KMfbt$u?$vU$Nk3N6e@xk{l;{9^Yz8%w3`)V
zQBSAPq5S^)jwL|p4<dNxXiuOE@(+A4p7wOTh{)5^CD9yO0xV5zCl1rZbmq025~pee
zx>0zYRRg?|^M?j2ydk#8aL6|6oY7W+C)U0CXWj8Y(db<3gpnrjj<*GPoVcCxZbvim
zq;~dVyBIB4W}iN1xvXjYuT2#dO~2MPMJ$__s;31q8sz@y{-cUPf{9QMtV6J-#3j3U
zj_`oGV8tMYO%mGM3)v*bO3-a}zpnya6pU0=e%~P$3(A#Mji2-tl6i(g{^47Q8(9#o
z&Bw>YoMIe=#~b>*5?I6%cw5z=<qw*a`PL_J<kesevoS4~>Z>PCx!PS;HZn6zTR@G$
zv`%zgwWpnx>*z%<N5!VJ=va(wpY`=OGv;-+v5A|<+qX2M9(B7Fon`Z;m#-rG@Wg5K
zuY&#HmxHAz_W`xxov>c;no}O97Kk{0V#WVQ*?WLBb-fS3oI4UWfe^xm5JK21Bw_E3
z3>g9{qJV&?Ac~3#;=qA>Z*lK!-K$ouqg7kAt+Tbu-PYQzlH>QDdlS_D`v1P?t51;|
z;hy)rd!6_2kr*dl`h(#P$d)tg^pkOI=N2ah{~Cmr9UeVp*@*rxTs^`=L;S*`LVSI-
z(UCr?+Rkak71}^_;X=pUGQ4lY=TjID^t9K2z1v2`Z+z6hx+&Vm8Pu1vRNQOku+(CF
zt?QrS85KQwJ_y6<^bPPWWITj4P?~smpmKovpk?LcB1uw^Ai&W#rg-j=k00ym79dXQ
zUEXM!v*pM6HO|(S9vP$PjIsYD;_p7&bnJ3vTYLW8o!>9BMrFFeKOSxJf<!ro59nJs
z4EXTnqcb>r&Py`SXQbhXFd86(e9Q?72r&uA$iNqv(WVboV9@SA*H1qgQnRUV-_p#O
zRk`DehG&OI<S6}uGxPfIL1qzqUL<Kk71x4eng)k>qI1{rUynZAGGS~`T3T^)dXgsG
zD|ARic6LOJ+{7y|p>Ord&}I0S!V@v!c>aU|W1ETq6-HqIYXRUTn&%*JVn7A)cXku(
zkTd)IC!8lp`uqSt<TE|o1~-r{pnL{ZO<K~t6y*%d8!)GKA&PA9c2ij79bah`ZIzK>
z6=BuW-)sA#R4XeR|A1cvg3(Fw5gAj@XsyDN2DU}}Zx~=BQJ8v}dT-ey3JtVMjx0Jl
z(#_q8gArHJ9qd5@Bg^GR_2LSQ15g1V5bKdE5eO*(Xt;P0YLFb5pj0Uyo$zQ!cbxA`
z2#)iV`8yAF4o!*)avSG{OVc9fqy&bYHtQAT`*3>Znn`26jY@9!nC4NxJf`y_Da1gI
z4o+#Ife{wy+?A~z$4ry~i8H*FzJ-2C=#R*O*|9<x+H|a=XCL!TJgf!GIk-28#Q$<~
z4=5LH!?0=i2B<9OkP7rC@R9VUEpzUV;FRXvjK6yKrG`euR}9ZCGaqzgMM?rL*zkZl
z_E~kmaWK?j=ib}y!4s;p3;or#m$EZf>D<BnBX$Jn$2hZ}gMTOCCmq1F6?a;H;t%dw
zhCzka5>`gW{yEo8!#ezWN?jc}rp8Vkgdg9#iw@(AyZ5Nu`1{YG+mX3~+>!g|B!as7
zm@3!pG#jd03+uosu{VEEhaj&Z)@vGf*qTtSFsK*m5a<(pdk(7an<QdTEm0g@6dQ$V
zt%=U?oXougY@V9lLS`y~w@c=(bFa_~9WN1pE@Y=-)NnxO%h+$`pi%aLEkTV_W=8vj
z_EhBeM}-!x=tL%-L;V(o28(coQ^fAT`Z^zV<a#V1^A*D&4^YhBFmi_lVeg=H$l#lI
zWE@Zrp&YOdT=rAErLrK}vp<|mMBC)z(9GeM*_$g1W8^3O%|bFk>QPU;eq8Ssl&c#`
z-<sw>oJcx6>xQnhAHEdOLe|3t42<{U<1<crhy?N4k5|6H1l?Mg`2x^%BWmE5{8$AJ
z_;by|Li1li>k4QNVKZks;7gOwPo=wbtA3swPp+Kkvvs6j3%3r)>9-)KL?HAQgAPPO
zxLOPbY!fNqQ_A$WBk?1bs0h&=`<R?%CFPG7DAk#&fHXRx?ILy$4W+hc1*0S?Qs;}<
zRF%&PpU`L$0Fr(1G6w4M|B^9YT@jV_A7V!Q5T2#^Jfq$-;nc-{3f_fpKT9iqD|i`e
zCN<|p%{=6z4C&t^wO{oh-{?W5gWeTGCwpEDub=;Am8PV&>VE~XPhO&LvW=Z*q{7uI
zBRpr&fLJvMCD<px-BZ9FKVyr`|09Jo4qAR(53eHVr&xFM7Va89>E7K*tuKO;7k{cs
zTX+FoxCvQq;jM3G%$qk8|FO4u8$PtFZ5QB74YCJEt-0KfOd{gF2TogB%V}T(Si}Z0
zF8p^Im5k}c|I|1tWI-ii%C%YIq4nnd685VajRRA%hSN3F>!Eo2UVqyFC;N{Vw4oT?
z?6rL@J&-vXmme6GlBKt^81`YqTQS&&p3&ah3`sX~7KFz5^_NR~1l|v58uQid$>U#y
zrp~Vn^DoZta}izm3jaL_uUUP5DiwaaedhdG_^%x;+k2%C!XKBWlA15!hbCAH{JL&_
z0E~g$7*sB2CwMIW+nAA`BKo%J!s^7}*i=8~dgsu@*g&Uxr}GWN=PteV){w1fsGBm%
zb*$^q6)~&Mg0l4u<B425_~U!K4!yNsEu+_snrjYCg~Yyw0^TzK@BDcx`CD5GIEEG)
z{#HOxcp1-XUVirZ>#^f+P(ARX@@or2lINVJUbmn54C_AsYRXLA&##+bY#FnK@ITO!
zz6|elh6fn@$2(2L8-!vF<Se^sNMFX+iNsQa!eh(vrz`d3qZU)IbuYG!@@X4ak<}AZ
z5}sy6A3bIc(nq=2o0AOQCUlzucL^EE3V9Y0xvJNWIXG_8mnW|4Z2|JUu{<a4srja=
zzUa~Ixl1n{M{#>^TgSCkXBWM~AK~*0nzkbEtW=whHr@{_Wm<q{F690X&JP0>%a=?+
z90^mv)r367h+U9a+d<P*%k1gjHQvLo5pzGlx<leS)y{kDM=itggO%}%0v*tWZzhe$
z!_Yh=xc4oT$Rhpl;p4e$C`!CKwQco+V`$zCT|Md`bxguD>5Mb154kGxelpGe-@4Zg
z@{vdiSsT#4&YK4oBs%-zpP!@Sa)~CNxLE@WlN{~tKgVO;6NiB|?t?ds?LYdUu8WRY
z9X^|=-?0NmRiO1c&$;+61R!M1Qsy<_7d&9Yjv?>+uCWCS!_KATN)nRJ;=O&~j@P~F
zZ`R|=ZdBWOx7Cm6kz^+liK@m?eV%W>&Fy;{irRZy6wjml<))MgLV9@D9LtHrTk~?m
z)KQ^;c@7RZo0<lD57EQH<>Nt5!r41GHvuxqQJK_i`D7NcK*S{vLg4tZX=OEgKJMA`
z<2|)yE9WB<@%AXsv2n4XF7bow;#@*w;-+}T>=PrC`76=BLlYNFnKFOUA;e5?qkA!{
z%CF#U31O-2vz|YnGbuGJ0Y%-c-pux*+erS0GRk}NHS-y}7x+)bK}H6==-nqNFdbw&
zU|NB}7lo8i_Xu$k$`Qt7KC`OS{d9KB$<6Ct-03C8ox4i>Bhy2JGo1$_5pqO1__Ns5
zu?KS8BsRYu>YYl5mkiWZ<h6eH%d&+xW|gAtlZ=!7L(@}(1LD5N8+2c`6_(GASk&70
zw~Z43K2AR98GyIIxBh3ha(>VC6ifJO0pT6qNuR-aoV>ywQ`E|Nn;qZN$W5!okA1%G
zc-Pb9^|y;pnZe7%hb%)v@KWBz<ZT4ZdHWpB7ISz4?xl$ATa)~!-fMHW2B{@vQ^O!~
z&~I?9TBw5eEC5$*y|ZhGVCeMUa9r>Hf}s)dRmf8jHu)|#UDxt*O08KP9*^AB<MUL(
z)I~1~{Kv<Cq4v>xw>uT4_r#w>%}cMKdZ$f7nJw%7I*p%1oSpeNE-L?TK#?9tF9An{
z$B943xfz6rYIu@@m#G(Oi9s6+3AZU#cJ#~r$9}V49H(%<Gjsq-pj`bc`>6tcbC{d#
z<$ikz`2-GOA4S^_{;3I0+_GGO(7`~{F@<9W_Wt?UZ|cCb%}ZtY<pCe!X9nO>R>`ae
zFVmIFm60qkOlRR;0gYCv0ulR<%mk}EzV0U&A^!8a<44y03g0|mcLe{OlfQUzK{l>f
zlAn`ZfIhiDxzUoynq}kU`wu#rEx!HMqPgSZ`szAS*Eiy^!*sNVsIGebhGAoYPSLoK
zegU{p@RDW(=iCWZq%f44*k3L#As!e2X3%x-+4vV=<MBUb<_@J{D1TaHevrf`-MiEK
zOipWXK<nhYVEBIx;SE0+N%+Zg4pRdAyI8yVwS;ReT!NO*MPL5g5da!dU_bs4%;fBc
z8mL5U5=SKt6rj&L76k6SkimVE92>u<4g@oQ8&*=e`9ya1@y(Sb^^5hUg)PJ_g}PgX
zt<jM|&M`GLG0s7e(XEuO?dGm=GslmgId0dNZJf2yJw>(^aGC~RiU~<-8T#p`LtBzU
zVjyP&J$dX9b{yo44{|vi^1On};T+=li#(IwJ(9x-g9&YXV9d9$!gw!4;wc`rGQA;$
z<G>n7&ccrb>uV%z1>?g?B&>0&c9Jg0#T@@(d^5y4!5Uw(jI?z1W>Uj_ERm^kNQx?i
zZVO<2Xc^w-Z)fTr7B?<H?h^R=s=H80OXLh=ClesoaK^`7=)y{&+YN9F@X>z){8nU=
zUw0LRNTAr(4*YxI#6Nwy=GvQ4zuUSvGXtnC*}AW-tQ;Jyt;DQC9`Nc*N>IZvU1<(*
zdP$Fu54imw?S4+@p06671#R5(30R*t`tr?J0#kMntS=+EOeCVY+^kvzt(U-cd`+8E
z@<czli*1w~@qz3zgWo_37&3rZV2a^Bo5SBsp9F^_j8V$B(<XN2_uc&BVr^`6PVddg
z_3FX;P*ZEMsjkt|Rvcn#Eit8LTS~-q8C=)+2;W~a|2ve4oRMPL{FOU~wf;Wg#G#$L
zo2J4Y0gBb8XM7|kiX@5foR6)k0+6QPE4_u=3#4NCy$jZI&mVTvo&nr~-2%*dki6(y
z`U7gaNpJX=&&iVz3gn&f6eWlTdd~NB^Z^)j_gotTork$d`${EFGqR~g5*KH>HzPHU
z3RNf=Ml7dI6NMJ^&s}L@PAW%BAhy_pkxpYK$^%}9sVo_W?uJ=-fP?X)ZkTy`oZ;vJ
zCl=Ui@b8Y0J1qoy=&=p#2qk|m0j3U%gVKR46v3sv{B{T>$Y%yZh=~Hz_cC(kgb1v}
z4t|HXF6=cwV;iwmwT>=#c94q1f;e*@`mO?hCkQvQvK8ruNX1e%($vPz2DT}-Q};AB
zW1PAi{H)BRrj~XBOKmdsdyS=uo0FA<4K%;&>u8&8>*UxY+16bAi9+{UD81<;F^%af
z`NPN7IH64UrSummONp7B@CH9y<eZo+6q)wQ0eTsDPvCIYKraEAbDGNUn{47g1e8-Q
zFcsx3`3#Z^dxbwlbh%77>{l?}$}~OC*3<<5!EEso#f$KBQH+&y;AE-L6uIhl;%}HO
z3LrCnZWRk3`}(Ry#-_+zP;8YH$ZYUt{hWj>LNY6_*VjaF{i&Ex+RM|-muY%Ey88nq
zLWp%T_hAC;%{(OFo*LwE2}kF199<22B{LgI{^b9XGnwY?NJ7p3DN)UF^e(BQtH1^1
z>f1w||Ca<UykEa%{78_YFF_d~(#6mI2{3W_Vvcn<pHVKefs@93jY7{Z;2#(m2+A3N
zNcOh?fvwoME`2v<W;IdPFjq6^SxuV8GR4xucDgwuVjW-W!o(CDd!{03otjm`{i^oj
z9^zGMIY{?I6Or!Y7~c}<OlL8J=enAUX|b^l<wJew`v&Hcz?oNarcdB-k?;Wmk6X}(
zEh0To;Fd$E$%E-mx~+MG_@2h*7(xuWZ?2%kB|hQqI8y8892r5M00|T1pNK!}EDU6X
zmIKQ|?Mfv0fuv9(3!LL3vnk5Ev7$gEws#$N0@(<2hb`RGCp3s@Z4?Pzh4J2=x&!$9
z=QhS7V-ZCWB`)@|6s4nV6y1)zx4Mh$VjkitlF|#Uo8qHDpMD28hB?JXJ)qkWIz5T}
zl0V(5=6zl@r1dz?)f*+^!jfPV%5j`Tld=uG0#uSPOhJ2!HHaZcpjmciOYM^SnaZz1
zY;$e#50WB@yM(EXwfB;kTWlINyRCM`@Cjb5dAXa9g~(e{Xop<wiX<+!CJN~UCo|6t
zqi1ixzaK@BwVt>VAFpyjmeix!<7%S(%vTtDGu%cUp`edUL`iCmRc`;K^T<D%&J|e;
zZ5YN1B*E5INGq-9oA)dq`lGYX*#lYjMJ00lV`1I{h&1*3cp^vF%N$*M09{Fcclleq
z@VFuR_C1nn$xIH7miVFsD+D3rCkXXPk=zjHyhTzdp}mk`2Y$^?YbVHa$qke!Gsn#O
zRv|E}E)TZtX^VdZ9La)BdzCm^`rtExX%7BFJVV3Id@E$l29|rlKO%Qv3RfkSGStDs
z>^^dD3D8EDO8mT-AakLlr()cb)&=&9EZ=g1f<=y&>-|xL<_k@kt<c;~;#M8~H2PT(
zJ<eGyGPb5DTY@LKz|GpXt0NU1?2L><h$3eQp=!*23w9UIDCv2G+c8ISim%j>z3@HA
z3|G_9OQf1dhZnF^6w!4QKLZ6U*0+s8Czq)@Yg`0Mnb@vf;`}P~n<n3!-E)W3;oSlD
zmU8@;0y)}IlylYx)TSr5kolR8W%SoeHYR<sz0pmWpDMP&*jQYF$`1G1Fm=uj^)}q6
z03R*bZD-*j4GfUBd%6~8I+~g{qP4>j`@xoq1|X{ug{HqbCan6uYd*rN_iH{KuXj+s
z@6~*kzFtFop=FRyxC#ER4_|R3yun9mdO-l!7qnJ)h-c@5;FtyUy8%KV+~bnb5Y{m_
zO&sIWa#3=4p|R95X5fP0qo1zmmAic7{na_~QxlABq;Nqaz2k$%KKl>TI~+sitl3xY
zCqFaZ#>%1L%$d3YoexfZI%VkAV;`cLK%HBVug44zH0Pg7S6{$hX(KOO#2jNWXmL4z
z9t2?2JH%#sbF4qFj=TUOAQ5-+N$x?DdGTC~#YO6z`US2A8Z*aI5~}CUTzcc{%o)y6
zkph$$IjQq{%SOD=D?C~$_g45Isc%5)tz}{Lim<p5rw8RHXAEpzn;(~_3S^!R8(bM(
zbMekGxb#7Hdsw)IJxe`ab9NavwX!osAEm3pG2Ho{wkT#?am~|1_r@nWh9x;fj)8^{
zID?8)Sr@=J=?}0a$`v?_uN(2vv*8)SQn8)bhNx54W&0ti#8#OVD079;)SK$dvLZxQ
zcFF}0FP6ufG*1kR_NCjEFi>rF{@i)DV@k%>)QlZO`KE-A@{o9BBX|6A55_3=O|^mE
zV+AHaZ?5BuTO2eZPe@)T5Qw@7uGa&GS!R?0oy^$8fK0U_y(U2&UA978wteq+OZ%1X
zIB-+q((<YxvmC!J^z=V8-Y-2MtZdtu!R)Aj)D%UGAizTzlRM#>$J(_&esr;}dinjc
zSC|*$zmfTNjas|Q=Gz|lkK&5N>@zzEj}zX6dAlFNx$}5}Eda{^C&!$GHF@Ji#F*FH
z2FOWbgf~UqEJ6Pg;^f*H*iySNv#`0NvneGpII=ct$Qkg*g1km`wU^gNsPgi+%~_J#
ze+)hm6q>H}@=I0H=}xL}dGG+Omm)mgSr!@_)5p&>M+&kzCoZG4FgGnAs$_a`hN}Y4
zvk;pC*aU9q2Mc7Mfkf%8sZwAhu_afF>A9ARa=Ds;Ua<nYMMj2X4q;i?j*$4y95XY4
z$9wx;#NT~#abQ4fO4<N<s-ITcm;?s|I(uaIQFo%epPW2xO(ap(^HjmXA-*yPFGUtB
zO7I$q%^$x=O_BR(`&Q)UOPoAlm_tFZfB3*C2S+!>kOy$yN;yuI(9g~y)FLRrKHS_&
zq~}qlAK;zu1=YuIZyTlF<yj(EM9vI6Ol$@L9x{*pZ2l0(MG5{EH*J`j8szS7>}Vev
z?q%uf=I)tXmTW0@aQ1Lh=jLlvY{!L$_$2C1WLlRtQ)6jQU(JeNwy*EW<;#Qe12y&w
zqDBuLI;FT0zfnsZ3kL@F&}s@!N5+6&I0d>ZknMsR5<e@G*nO&-13-end~+&_mf6rU
zicgs_fk|oY`wq{F4@^vL-+K)HZf_nju`myPno@{^Q^pJ(SIs1Rc>mc2{P(&Mn~!|^
z`~osxKf)7P{<IulfQhOH@sEq~?_cc)S^f}u+`a%jksPlrS(z{$(T?Ez^Al5uIf0)4
zFWjc@DjEWgSX`9Z24V8@(E=-D6MLk#jKW<FMe;tBvR-ZBuN&&@T>}>?IGDh@=fK`d
z4K(1<D=-o=oINImWdpl&dN_<bAotGV#3I9wFr|rp>E`|LjRF+ym^Q43x!BI7aB|5I
z>z57UqzK_f@+G6B`IJdhMIPPk7nkB_tH9s5d7pI~<u(YJ`rA6^{4k~zB8|;1I4L{A
z&Y5;2U-8#2gSQEaf!E2svJaRX_D7N-W=XuK^r8iP|093{TG<QE>~ViMe}aerlM~Q0
z%sIAw8vY}sucK{@AEgyqgs+sEIXZzYSAL;Edu{E_g*M8J^=SH9d@{MxCc?#!iV<3F
zMmrMhA}j<#Q!D$GuU#T!z^w!Z50JMFfGd)303IMvz!w8f^g$X=5WtH8cZ7}klq83$
z4GwAJGpa2|ZJE}i+%+azh{D8)Q7)Cv>pL2p&6bJdqZO7e?r!qrgdkgYa~nIPcFFy&
zBz<ivo?5Rlb!I-#)|igK%?$}3tyKC`{j$OZi=#%@)wT8=SnD?$x)BMS%i#*FX#l63
zgA;T=+|5FCKM^g$I;4_MSjUqbWd!O?vnjiE9pBH-lA_as&Y+NU#txxdkn^7Q@y^-^
zy2DwEf4qLV(%G7#Y06%#prkTW2F{UR(hcbM{Wg>Xp$Ba=8E|6_x~Qj7A0ue;Ailj`
zYjP|^q(ud8T(^26h~w3h1bSIWamGMCKpm%4|4%hVd+CiYV|}nzIV3G3t7z1cBNZtg
zv^e0#@rScTJ*SuY2YCcV*?CR~2#oi#oc}O#ZFTR73&zwgvy$5xo5$A83k?pA^mTO(
z4vwfvi;0T%3Q36uMHUcRRXd_7-bouPGM2C3J1MJgxM^rf=`2fAN12_JLat#MK>=>&
z+7fxig7&GS)ALr&8&MVD5#7(uGThSF*)-hT#7=k0ifA|DBNLxT26PZO+~epn8lL}#
zTpMW`g+^h{W#Dqy)?s2eZ`y5=q4xGx_d%?{{9XNrZ=^`=)~D<r-wvU@tADih$9a>A
z)BHod%^b9|7E!l)(u30u?>x8ESKt<eO!lLRTd|QWRvlsGg-#)n$~|6XW0U&{*bFJq
zDF9&7-^a<>;I~Wjdc=?#(mOS9jSmyBecyNUW8`T<u}e_2@zuad3wJN;SGo|4?xXRs
zR+^EB9qUaMfvsKHfxl5iglPmYuKUQ`^>x)fDiV9(q`MyWUenR$85|y#y|JOM0t{Tu
zf$+gwuYmUqIOgCZCBhj&qz(>z3!DVaCRY`#b7{_|1?xgQO7hpnNnP7}y9Y!#h|(qg
z+M>%NLJ}_=zL^x?j~=hE@EJ5>O;Na)%CC=?t1`a#d~=ahB25iQ3?3dInLX_D#U19>
z24Ceq&_zrtK!h@S^Qm7H(lMl2<E;z8+^;;Dvwio?g?)>+?!1exX5uyV<%gRp{Z)Op
zOddrKNvWK9``D@4s>NR)If;*#4?nx*T>rTAFHXVBjhcZ6dcj(boQ%N0D_%1HP4Qk;
z_|SZtq-eAId!ZdT#M{hXJ8M3boC;*tx%JT+ds4T%iOS&=`k)yF;FRMn(n|q6#o5ev
zIEg#C1)der>xRlZqwrV&JqwR&BcTi0#gBAB4_KX5;WxDN$97qDtfGVtD43&Lg-pgH
zo8=+t{evbbCE}Dnt1^8X@pqFyLWk?a(zntINH6mK$O(W!@lHRLfvLHG&!7?|B37g2
zd`@nrJNyi<B0(WBCk`Ha<tcOVk_Cnb%VhZb1(7nT!#-r<6IJ9pbjfS&t){}b5LY*G
z*h*xZ96?ReeR`eUe_E~aTwGZhi+t}QrdG_z9zDffs#$yCuD4I|(mz_ucel1?iOn{2
zj36}V3o_6FaB>wBFcmh$MdH*HCl17n@a{eWTgwxOV?8LG5GBua-~j*l@_3PTWDlXe
zb;OWCF&ViUXPhpyl%N|Y8^Vf(_O`KAqti6$rnzXFjYvvw6X>QMJb|Bin~t&-JNFCF
z{Jp)mZl|fODK&~ZI?~qCt$$45HCNn4rP>30#CI=XAHk_g$R!CWmcx(U^MSD0=D&K|
ziNmb7KnT2419{nk56<KJGHX9`ftf?7NQO78iY(N+c{+<6><6sPtW?(gh-%Gj9E5oJ
zr$-Ld#4C#F0DJ@E$JC;<4=jXYlhcXQ9AGXKYAR083#`qPSi`K;ET3BZbNOvYc71>?
z>-=iK#dBAZcO$|Bi0C}F5^ziMP+We5*a32Xr=Io(#~!>UFhPL#cVMmbj;@?>beCw_
z&TDI8r4s8CilDNU<K42o3e0AAP8?ko>jm6cwd{w**S`1y`nN5RW4+Ya34is)z=ZsZ
zNE48I_QPH4HYV@oKmmU2{pJQUmpukGx_Ay6u!Lm1utAf+xd>u)K=dFb^R||#S2O&-
z2moFVNZ`!5+PrxOf5o~!PDf7tI3z9EnhH<OS$M93_0nj(yfn1e;MytI$JYO&jv8^a
zC9rgK-O{GsYEOFW{3Fn$aPwhu;xETON=_JhYwF6Xrgh{uG+tuU)*hJ~7wMjjO6z$j
z8GlkdsBOlOZRCzx5|gY2Jo*yI!PDRr1Yb$y>;@oCt|7T!o@Lcxyg03Ox1QoTqq-mf
zHT$OF#jXLG>Vi{9Qk>xxq+VTKa$sX^{T+I|Of#b25*PWz!Xc^o<&ZV-mKmFl8oKr%
za?Vo$-iR)F0{(6&>0HxWatithNW$hFf#9?xuT8|B2BZ?A@<I)1EF0#D*eN4n(w?*U
zVN7yTBJH3FN-V7Nwq4UQsWcOBC>=0iN|d+%kRwe)dZwd@c<LLeSobCV_K)nYq{@0p
zoI*CNP`;&S@ot#8kK!7;rnYvh8M0yi5h;4q)!H!PPAwuXu~7}+>bXIl4Y~vb6<`4Y
z2FO_cFYs00Zh&V%1^h)nHw(FA*Ds=vjV+zOwmbx{&m9#gRDWYPKwV)irc(A)grGi!
zbz$^8C*__6!>TTxu|;P1%cHYD`3c_(w{*HPe^CGP7wv^6$mhV!Gf$8`@rNq$0H%W-
z50w{RUe6d2zzDGjrubGQBhE*Z3e<3RfUCwRX#kOUwIuqLf}WZBn`NAdg^9U+fR)>U
z!PRKoi;-p^=YqzwgG$@8)0?k-HM13;`l_R~Bz-U?zKXXCHUB7mjqTW7@olDc0~ddW
ziiGG3ABhXXVU{B+`%TPB5q5oO{lR*4SG;fS$1}5{1wd~F=tJVCDBtsJIT#3y<-mM$
z0GyK?U^8Ao4AmoEpoxzlgV?-vk3-<3=H^KPkANlSQmOgmh@z;RsGQarOP2I2ogWxh
zrVrH-GtP(e7nZba@3|>dBC)S^a7#eGF}r47N49lyN-GCfXAMZ|@ohH#lSJxh^DHoP
z#KwSrdBujod_hj8!Hc4Sxc^@&2Jp>usJmDdDi4J7bp*$(9s8<E#Y|oM?SJc>tHTO~
zkAK7mC)Tv0qp78-KRaCQtjHRKTz7*R?!qte1x^o{BPUJ|-M*>ULwRRD>^k{79a*?)
z7)&y(S$)LWyJuqvbPw`*Q+5VB41B`J-OoF@Jn9qJAL44BJ>VJU!RV*)>Qm$-NC!Rv
z4~R%Trx6Uy6bcha2ywtwl(0QKD0e2rNf4=O>6F;MaHzL;buuxtjCc?kd@9Jv-c&13
zc`?b-Nk*S{Vx_p&5v~BRE3z9C;LW^VKtXq-Ok`^>5GaF8q1BQZ!Wg^7f>T71x(%ZM
zxVhf%f7LP-Fe6E!>KdaEQ5(eZ*~~QjaW)?1<Kt-K%2J-5uO2ZUQoriJDc0|wuZjJ{
zJwrW!zdzg&8U9^xpToy<zz1z~{mnP*W41r^z`2k)d{A3?=T<&)qCoEc)=h=_CArlO
zBuw^J)HK=<q9|n~>R}(>eTp~zg#Wtz81?%Jr1%$2{6zfe)QHfy2`F%0befBcRk9<C
z4;mYr26(wRnFt(HSd?Kb3Gku^;1y5;eS*w?Le<CwIpLotO)sp(==RPT#X~5IJNBZE
zDJpMP8e(iFx0yE4-IiekSZNTHe)apN`F;IrcowYZ_W4^k-8})nKzFX5*{x@_aOoHc
zXI1}8cTx|79HdkXOu>4(`)=_KIUC|+WA5jX&=+g$W#NcW-lIb<Ew^{_@bL*1QLSRP
z91muKO_C})8mR1R4yO*GFKC%5O=_YX<s)gDF>z;(z+oh3iqgX_By-RO4u5pR{t5T|
zCr6_^py6?NmI3!xa(v4x3ys=KuHZr${rME|0c6C~(zX=OyYG>SXKfj$U&OZH8N=Z!
zUPHpK@J5fXa+0GL$JMN#hl#bNtW?)m?P+6f1H}xjV<FTpTuf|qNg|EErS77LHIH}l
zkQobH{DgL9l-7zdk8|o-BD8t^nYlF;A@K8n5onZG26Z^r)7IQxq9r16M#czTZ1W{7
zGPd_krtIZP<Z16{%HSL;d|u_tsxpOEa;r5f9c>v(;Le6Y22A%n2!C$xWR42S@7k5v
z2^pb@OXxu0cLV<l9R4!Und5Kb+i`L%q&5F7(l7)2zyCp?mvzB?iK#X&;FsY3gv_BA
zLW4dGc9fcEJky_J;}_&pQ>&1Rp+xM-r)lIP8Qa^Dl?Ix^ZEA}^zV##zG$X=3?Dd?t
zAL->Ev9xEbL2fs2G$+kH@5-f=i<<sRE}?V4Q1Ar%0J8T4ZzQt!2$grs-i1lV)Fz1^
zI90p|n!Yb*rpOWhGMSSz_tAG|G;^XR13d{z2lf`gqkWIxh(3_nfV96;@zjPAPXHM1
z?FlZhV8Dm$O%FJNV`9Y&&pC?ky)@N*iW*LrP3U3iVPVUfny|jpBv!8vI+;>o_%aI^
zX0ptziOM82HV-i05#^)%$Jo+T_ob(5iBFCLQW)btD!Gj*<ws30wXn8zaDn=#8`Q;|
zIlR3l^hfFNJd{o2>kFXMm7Gfgo&o6g|D|^*NI%4CTypV0&v*%j26#viS}?mVTQS_B
z(OTwYY-SnxAX0l*>*Rr=gZnp04or17Ha54F+sg)hx;{6W%Br2w*(Y4Z3>a)HaE{qO
zd5`V~(EAiCw-yt{9|l*YQht?%$VFvqYwsva{9<ME2M0&3OikeE{w?60=&d-Iwg$SJ
z<6)>@{wL^h<j5Lvcj8ELoP0xSpZZA4%L+6X>Aa#n5$W+{*Pq*U*4Mt?*3;3%)H3{j
zxca8XQAQ;Mmif&e*?w}{Nx#q;j>e{z+WX;}uQU$s$sK-6n`hu>%j==*zx?kR)SV-3
z!!MDY2t4?msErYODYtaS2W`WtPZ^kI<{%JwM}vvG(4(a9d>7rP0Tivp`)9f8`CCxP
z(di9Gr!1fo=|6#<4L*+1yKn!wSF%B}Q=lb$1@*-1D>1k0clQj!E+#5lu*Jnh9PX{2
z88LcTfuE#NEC;$-!AVirw3A1{7{4`rs~nS^Kknx_;e+7O!7_pl*tA>9jJ<br!^fO;
zVi<SWo!#c|TS5c<xLq6Qr!s|I+m)2B^j+^0p|DdfR9#f<38FI@Wh`tzibBG!qbaEW
zOOT;Sutx;86=X@jM-q-{34jt3D{%tD1?qgnDdA6_c>qh2B7+z45D7W;*%|H^rFH_;
zE39LNs^<`~m4~}X<<x9tY=LJxQEmgK*=D_YG_t=W5Vt!cAyV7h(G(k$W}R$hQJR}r
zx^wmUoEwu@(6<-NFI~O1(9*0|t|vb0XeFmjrd&b}Atx5Uy1Mmc7QU7BK#7v%K<Xgb
z0B>h=s`T>VkyFR4FUl^i0owilu37${=hTR=>CXAZq&E(N39dg8m{{+D5wDZuZ<3di
z0A&e-11Eq(O1OoDMyxy1e4vr$+WBS1CuFy~o^RW8W!c)FcGva`s4x?lxp`p^GgH@+
ze!b#drK@Y{X*7$!>axNwdb`H>dzEEuKD+zZL#G!`KA4GA9>x~B_yY%!!|JBC%Iu#&
z2iM|4=12BRt}2nlL8$i;3@K@i*v632LwuD7Qa=#F@x08FkHkb|BV68G!~8gP_`=n{
z{5)(7tBSTYjfkBZHh%H7X=MZPOjj>uuCZ;7=H&b(L$duM{mc{6o7Y$7I^<O!|1KpW
zpE-PGLB+A(_n*9~J7ec*SsH+BQ5aQof8LJFp4isZ)dFqXy=&ajmyZ+NTY8n>+I_TV
zym#3ctAoIYw;|tw0MDdP6!1n8q2v#YHU^yPLv-$$3!MPR5F9}q0@y`Pn)oWI2Q4&l
z4~h?^nLI^M>L(jQO>J$w!YSWALl$qVN_ASVv686idC|>t@XwK>lsUyKzX2y+HZ|wR
z%Ei5%loEGV*jY9D{EX}9a5{KvT#UiA3CtiK;xa^fDtqz$`Fw_wK*#GglBOozbWphj
z$oWJ+)0Ptzo$C`E_+eXic27mns9E<v8Z~9X>^rT<v!%ER9~p72(Bqq$L=~G5m75bC
zr8F%IY0J#WPcLhFasBU-isSdTZwkFP^|`mYtMBTQsrb{@^3RUWC%kR60%CL0udU^>
zL!1WzHV-HY)Z{pm1VaYO5*!g;)%Q+wyvo5!e!~tjS!uR*9`5o1`$qPj<S?{z+ZPLq
zYTC>DU#v2gSvdp*HRC(0Y9>wf_n(GJiUv=|V_m~5vcgAY&>?bXH<7=qf0?(ts<1I2
zt0GP5oF?!Pg*Znp(x%Rt)1ZR+f7d+x@f=epI{+Kto{rPt-0?RMx4{WwKBoYYqZ_$%
zPQM9t7||viJCY0>01LbeU&$7@i8De2)Xd!sucenyeVtU0oY6m_N2T|~V0*F6qH3Q~
z--T<I-eVJ0PLck5CffM9DMgAb=3-0yXk2mXVL}h-_{^%_74~i+fmE!EqeE_(r?sa?
z({Eicn`55bZ&##ag`=d((#8RJvKeCH<s6=g<a5(X2>J*=>gDG@J~J3O;1M{1$SgNK
zZ_+DJnLwYjNu1bZZ^pXjnLt@IhHf)g#<^PCSV%P)c_l^3+1BlAkR5d)GN`LKATdHI
zvZU7)B@R8Pus2<ZTLR;w{EaQC@(6jxu#60eTfY&lO26ziApa+U7aBqSt>6T!3t*M=
z!2ogGmE|O(02NcdB1u{&8ke2G-)-rYy!<3`+ftPDtoL3xAf_$C`y=}tV9fD8d;&Kt
zA9o14pJ1Be^0A_;x+O5osukZIa|Q76400?z=+lPtAl>{AlasmZnZ6K7%m?8*x(DS~
zI%rfyMo+;6lY)T2DAZ=AOpOb36@pdpLt%`dwNITovfR#vs_{=w3^ZYN>%;sq;?-GB
zzGB#l(KXoHPFN4(PGXyQMN8Cz9dU~Fa;E2Rk^lhW5LNM(DBW=BA+lq3dMYD*L)jix
z?Xt%Fa<Na97j16t6iOBEsm{zZS(IZ^6c8AR*6`qJ5{8af)t33F=(MPy&{#h+JKyqF
zM^>9q=QPwQ=b}_0cBh2+WMo_=bRJH0#*6(E<AY3C>KVTq+$FCWt;hskhrP^$z5L03
zX5<dBogMgmUZnR|uRjo9x8$@hOmVhj{y+}r?Nr7WaGGDR($OJ^vc2wZ=8)o^@*+_p
zMu*HTojq(RsqP!KhnshtKl+<e6<f*0CQd#ncB<EPummz10Q%Gmc$drGag-vf{Re8g
z(MSeh|C@}UUcEB%O7}%JP8*hzX3{GF82KL_ITg0;(J6^ejI_q2D9|^SYBBTbp`=Ys
z6+qeY#+Gs8T=5?NB*MtdOg%odWzp-yf+LL^(9Z#halRHNx`SbU>E|51fZ7D+AK(1L
zyrDnh`X_<j<PTs<trdqszZmfy6&g?!`X(@7FgxZ=-Gu#{{)x98q(GZcAXA_~u?n;u
zS#9+bS-N{wd&kp#$M3n(J|<tH5YXmu9xXV5vZj=X>AK&D(h5V=gN8xIn#3|KIE{V=
zx+%>l*9fZ3ymtDRK4lH2mD5N>QvtV;Qxu#{;=hKG`N_P-B~!x;`ij=;E&AErbmd%&
z{N&?zhZZcEjfM|QPVW=nXSkBK7@g<si8u6*j7^EF=sj}K5)|(%G)4izM<?0%xhqBT
z9wQ{a0UEckOrp$Ye-*EE>D}TxX>L`-5}$Ep`9+Sh0DnPvl)KezWlnxo)7Zw`!s!d!
zhN}gZ7QzFOj{c!yQ=-;%x8aMvE;$1DL*PgXmB{Ea-1AloH7VZ90laetgp)I#OQ8dr
zv%mZ{HE=3`x6iP58!nQnb#V{;%*4(*)TXZ{L+PS9Tjgx-)!Qc}#>YEB-hZ0b)YaHr
zBUrSL7Rr3+lwdEP{-LE6nWKFrnzFH_<vS3KU1m6xM0&d}=+|%ch;*?d?QU#_904F=
zJNknzZU%Vm4BF>CZszn2r|bYIa!(JWBAe%|{HZCuz_gHP->tqKi_Wb1_|>qnnZBM;
zUiJG6JgMHlAGwf&+ju6WozG8OaNcKmXYoG#T@9MG18}nJjXh0jSzP~=KK~9Z@je?E
zxPb5g=)4me!8ql-5pA`|ts*tEe{fKuw>VYo?}K0MI<)iFQ@T1it*C59eax1KF%?C<
zEyQwPX;P5=vZ~8pEMGwOxfJ}(aX<$N(G*1My;q4e;xG+59qcBtlk7M^`hM4=A3WPT
zWH{>aiYk=(V6<=9y5*gfd2~vU(x;&4@wQF<2kv@_($#o3p1I}J=i3OqKL>sE7}kN<
zl+&%Ux2oaalw}^fxCP>UJ%xoT??mCw<<qn#VsnXFxNsjeSx-vcdR2C~(!rj}Nw>5&
zb%!fhc)IbmPA$kZ=S4x9mOt#?Z9$2(1hnx<4&GfR=9ObI@-d?wGw&GQru0-urK3X_
zD>Dbpg@L6>nU-D(@5!s`z2+(Xq7pouD0~OM#+Q)Gz{$ggW%zl2XzwR+t9hgf@8uZS
z)HJ<jJt`Qf3LU442@6jl3<Y<Q<4krDy%=Vg=sP*UKYEA117SKWZ^ejfLI7hqZ<AP5
zBFgZQ&>ir<=$qScX4%%#Q8L;`EB99(`pQq!Tjm+$QV^y@gGQIFxzXMuy{5U(&WUkO
z);37g`5D!#>+lCu#i4m2-nRXk$0$CTl{aDIAf=0mTiLP^ktdWWXThuTk~8^LTMPR}
z%*`ir!GFbR?0VoszDEk#a1j?5Ve%#z`d|#Li4^Y$lFxaDB(5q~v1Heauzx~!|3JSK
zDoENRHK{G3A~ZP)7g<T+bjyv{?0#V}Qi?V6^v_I9oRC<lij7A*ttGznIEh&IHNMt)
zew1r`gxc1vcr@H3Y-Xdf6H%VXZ~ez<W;SB?_;9tYYw;j_2mMZxoy2!4WmmJy--#<B
zna4LR85CwW6A&f;J{NFhOrmW`2k1NOz^?X;ShD3tx@D-17n`!CX^NMJTq+%=7Kn_^
zgQPrXc*qqekUjSk`01ZJ)boKwlD*uhe=29(UA~>g`{JFg&7>%i&h4|LS8H`my1(}k
zhY+y~$1Y9*)z!_t54f?m+)usw-56z5C-a<>8o}v=$80(9b1)}2RJUaXjwRJiU<+O}
z;fxf356XcDpW|`1JfPrYQ^lC%1yjaF`t43ts1W0^V^QzAwMF@=UQHivtWM~mbf<oA
zScIQ1?>BdDOW91wkquVSk@)Vgt3@cKs%%lp)sgYD0}^YJfo%yNH^2FsP2kQ*hVl^U
z{d^7h_<WZqah3EjDj%cp?8_;TSi~lTp3*%zH+24?vq*F&JQ`oyUDr1~G&J3#6*>Je
zZz0}v^H6`kpnw~P8vS$VofG%M0m-@@FLximai;}EwA=R!O-~P1#66rgQ+K*+cHFM5
zg?l%~|3hFyBu=4M0N=_9WI$xPyLQRt7~Zj_T-tzM5!&=11C{!y@CxzQL75Q|%85gx
zFOF;9x$Wg_1wAhw|DcMlQ$O;Sc`&K|-ty|9=l<EW0dOz_bfy}7;Aq}c1j|5r^FY(U
zp&7lat}hAbRSg`h;lm@bMhwMtqPRH?1OXgD4hXx3Rm*LCBPVRRjyGEQnJWVvtwdJ#
zoUdM$(NpMaCw5F5-`73`@99_7v8-o;3tU1|(LYX$1fkR&jpdv3a44BhOZ_C=GeaZG
z$@C^3yE>}BmB;155$SH;$Sn&c)gyM+h%w8?Zf;(S(1DAUy{bQ~gajcn`T%tES->0D
z8^Z!PhI|=c!sI)-6x`N$IoH=Qxot3K@oBeyQB4*ubnin`J@AdZ$&Dyl-X~_bi4#?}
zwZjAXrOyd-ccwK*R?m!VT<6S~;`3+gW*+Mrdu7=?zmaR4;H*f@wUpHdu|F6-;v208
zSzZCMEQ6`i`kFrbZ)sK#?k5!G>X@RpRZNkTUGe={{8uU`k;xZZ=6!t%nfB$LN<W#f
z@b7<iUv3zT7hD)x`wPXsUOB}KALAu7N<5(PqpszXEzl0`16*lc(YOGaId<I?&+R~6
z(z(-bVjUPTA_qR;9}s`W*DzfYxPVYnN;<T8^TJthKo}QR^2(hLkcc+t?I~3FM{M2k
z8do^j<|%eB8XlBtV&N}{Q7e`zE~rOk`G+rAcjtq;p)Z$B&r>Pfmru_PRmiCHuDu67
zsOsrk;%;T*l<f>fMsulZcL(y>bFX9JfU1-OGm3XEE;`szymL7ZE98^}Myw;~^At{I
ziMIs|%T+Kr-~g49u=n+dJ2|e(dzyq<NxK4h=GhezZbo3EBdlj`yk^iYDPE!145|fr
zsOGe<Xk0gOc=Op&ljv%h&)<UD$~C!(JzuToT(Kt)@e5AhJVWM#RhD>Cg+bk*pJ-=U
zZ13h_xygO2PpZ|ciu2`u>AgeTz=yPeJTN)$A#j2i2cB0!eef0c3{^VdWAdB|&n!H^
zpk!+qld4;Q&(YhNqSrg%b3!*MyrUJqr^)Sk<l1>L<epn!tw4XFG1YK$G}N44Z==;+
zpX%RF?vWBWK^_{O6XE^jERMjbmtlQ2gnLegchg2WaA)>Xwhzq9cH;aTk&(>Z$eR0V
z=rQNj01TOusb%a^yd0l_Ih)H-4a^ISLAChEpt2<k%j;_UE?eHWW(gjFW>ahMDLf60
zL5UC|kH#JN#80jDL&p66thJ%BZIF(GqdzQ8?z9j%0eyM6p_hj|rvY3D>Zf|VksX`B
zQ8yWzhmYX(@aGJI6UPkwnq0r${k!Br-~^d={kxL5XUN#X9)|)BNG+9yoBYfOp4BoM
z{ujglOxx>U7@L5uboxjD`Ho4{b-{m^bmTn-+z6Z?%gxh@!<~@8L}+C#V?*%Ay6^Eh
zX0d@@{QAswZv7tI`iA$I!TDA$|L_*ate!uGEHqBqaqjB>VtB7@HbHR@J8Flnr%gUV
zbkBd|`0CQW^+Sp~zuH{c&^Qoa&4oP^o-rq|s!b3KJCq>_k}<8XucIGu0Ar*ZjXuQw
z)QR8G1+?^+r?@Qw!!MD2Ln?|{#=#F2OL!M~eh7CI!r#zFAaDRi6)7pD8X&fjYQX2y
zG7o<q-yfgvKmO;|n#Ko#K|eOuv@*j?@DI1~pLhk-fz56s7n3J+SOorZ#R}vX5k><w
zQr`S7C}VSg^E~+e9jHnRVM3)rier%$z=l;w{R2kgfhD%Kggh9Ca@ppdcRKO;6^%di
z@>`SjWEF~BH|&R=zWC_;rMt%II#<pvNu;*_Ju4;0Y{?QcW!{<ot-sGm$Tgoi)5NRC
zhXa~t?6uY9xb3=3ePF+3-oc`He%}({IbJpjxqa6|-k;q41D_+25exM8G~zbTeGA_S
z`r~8xG2Bc47#~AgxOrCt|7+<l;f(fNKYSNKoZkrP-8#GkFUg}lyYA(oI#kEKTLx<#
z1-S#e54;4inIV5mwkL&q`ebAZ0bvwq0+h(uqq^negTwMl)~qebQwNXNEk`@>JXDK(
zV1j2Ye76(T^~x(*u(7tWv3BEvlDuAc$y58asP!dE!Y5zi$!nq8hUgN*Y&uSt5V>N>
zKsq=DdRe!V$<sxn3U>6XB=+RvuBF`1r@uMN+S3<-b4e5g=h~%0=;oG@sUzSLxJ#k7
zPMm%IygO_E^;e}!OQvG{4F5KL>N6NZRk{L?Zfrk)zCBV)3&Wr>;Lo_znu$x1(bK1s
z+E$JY!R+E`FktHucMTrEHw$Kre9ZO&oO{E1Tt-U?h=1#UxFYT@TcsUA8LSLbP9SOb
z@wx>!=CtBlOJ-c$Gk(GF=2`gjBRTy78&k51V@_1edyeK^9@mhF{n@&+BZuVo-#l%Q
z-}TmO?jNJ@=!Tez&vkMY@Od=kgKpCMxSmrZKD$mr1n48=jEEBU3xxvqCJsIYhbAOx
zBRh6i4r^8vYiqMn%hDY>xJQ)2%OmT@1h1J^h(hybTz>3#+e3F3^cN^@$|xP~=#69x
zpbo)B%Y0y>7Ae3l25Tmj$jNpH`ANBtXLQ(F<bsZSccw2#(Jx*<T=c8sz1asg{+PWH
zUs>DG8mz85i#FaGGpushbrf2WePGJIwkI2UB<2iBnECycQkxAUs-wXG03wZ`qC{_k
zyVGH1g@Cv3T5^hx^Xs}-jzSXNT7o80(VNa+IWS`FM;kVd+P3Df`?U6BMfMFfGY5L)
z+}SkMJuodaW#!fwK~U$sq!9JJ#F7LNbHYTNIuPs(Sr6yauh}_-iY!k>HPDH8nqZ(s
zQ2f!~ovl?#jJWwNuxt8t=cLOrRcYXXB@f3PK+DD~i}D<^s&_?0gqLp1v>6?nRn{>d
z4(KWP#;RgKSk8Gg4z059d9T6QE$jwX;$_nu&CQ(J{rUZ-0UynV{W<_Jz&;!S2_M1s
zfR5a)8gMt%Z2XmtOLaLgPN=0-SdYl98S9Sjx(K5L503DPE!0h*w!r*rvmwJS>?C$X
z4fMl6KQf7p`0H{AZOA}X8s^$^*%ct2N(N2}OjU*L5N*!jT+5MjaTnIj9ch_c?A|o{
zr=MpxxfkP6!8>*Zpp!Vt#4mPuW3(SN0OK9kuI)h7r6=?E?3w=r^~Reot#9b;9LC|Z
z;mz;V9^g&TMSA+da5ZixWXK#WMeWI&GA66UO`WHyOUjTbGJQ0`;Umyr&VtKk+UOcg
zIg#{&Q3L4m)$krjCz?<)7}5qf(Z9z9A!apRkBaeDtjoi<^shn%z}NjTixv#TH>h*^
z_gzJhih=iq!aTNHAg|D;O?+<fw`fo*fCK$YAyo^&F}Jc(21dkt?!@Qt7wGB0p8e{>
z=S<i#xF8k98jH;ol$pC6X36L-&?Ar_`|Iqwyxm>D*s}2cSs;^kd=7@&H(7&|5eZyv
z3c!=M!(RjgtX+@xg*}GMsV?wv$-w(7katGom?Q+DP_~aIrAjlPCMT)bcIjpMH(gm$
z8ns3jOHcx9qybLq04LyQ5sd@aD}x2%;fEvDVM?{kj;WiK`3e5ziMhE&P*`@@jg$p<
zf{<wv?Rw$i*uSX*5D*D2nO()X$oXWs)KP2T!7}<b;07MwlL6jI)o9gx2E`!y23K4n
z<Kinw?0`tz?wtIoBB&_zz_b@bw|2Ibji1qSa_u1y#=Ow*g7g9V@XOMa%rq5>iLVLO
z%SNfOr8@uW<cn@5lI7)xYs*166}~xr!$ZCdk18(ragizDs3EcQL?1=Lo#6tffgB#x
zZ+>T|1FlKWy_`d-lvfpiU>OX_f+3pF5W-G>1l$$IaT{E{b*oolhD-T0W+-(X3!PLK
z3D;4KE|9ujex(n=1FzHDU>z$sO#v7tUOc={uhRJmhCoK9?ag;^7x}G@sZXCx?Z8(q
zT&tYE3tjmhzf8b#ddibY6WS*Igk16WKN4M?j?3uX{5{<NgWK*9fYWPSfJ2ljy&Kev
zXK-=wfoT&`W@aQTo%_?~#a?3;G&Z;Tb+oGU4EXCKfX<)s!&g3TAD{Mj!<6A?;_Mvk
z6p&al=<t`Y7dtZL5Xs()&q>e$VlU%{_&{=ld5NEtf*FMEbWD31sxc1s6{3e&bm79K
zkE!c(Mn9c2zHQ>uCzIQZk(mh&CVRt=U~fPN#u(^8{4Jif4RkQjfHB4gyNR%wBLLhM
z_bvf=<b%Aw`GL&_-UfdI3E`R}UKf*FD7&Q|AcZkV#1OFAYPVVQ-n^MNOE3Gs|DKUl
zr=d4r7C2w{bKc^`^ZvY`m;WnxD=N8C6HV^Wf_eMwac&J?ScOOskQYQqZ(W3505%NB
zlIo`_aovbuw>9kX%?p3UcOEX>F{<T!U}%_`DA(KV#Rrq0&Rc^&Q$-B$`v-mdsC|?b
z?uB+)*H5^8Y32g6OH^TeDSqLDKAF6|vGv}-tfF%41Ehe3jZ_fdE&(_|H=9sIG4N;u
zaRZeE@EEK(A(Ingmf#^sXyIli4a-Vt$d8Q*3WD*OH&AEvSeJNX5u*&t3Q11Pb~*Wy
zUZtzR8Y%smS%$W;e>u*l_6)rhR%s^u%*@e6g%6`ne*H-}UEs?oIXxocd_-&TUwMCy
zxOg$(G5YFG<6FAZ$R{Xa3-aEQ5QKcFL%MOPxD0JbrKUXi{>rfBzI1)p0^jAsu6)nG
zH|xy<_7w1gj~=^3DCN9linKBbbOpg)VHz*+3b8scY7R6OdnziqC9dS~5Yr)tKN>vn
zCW?7H&rj(GHw`QO=RHO-H_@uu4Xr+s_V(6M=aAK};tTk@=PqtOC<7n%b#s1>TrP<p
zlJ$ANC5t7o3-7nQJ7X+N&1cYvYH)|@K2K`^h{+1-!1brbPHb%caQ!5N|7qMS+ItS!
zjvb0WEb2Q%8?xaf_2s%{IBn3d<7Xz%XfU&tn8JOKKV>bSfupmslN-*%+92oPx9kKt
z2NHMtEx@V7S>nhEVGW_Q2HcgMOSZmTuyWI!XM2};2gMc+_*{Y3;S%Z7hFq1uw_oz8
z@z4LBJS^pzw~P1TlQ+B_0h_Ql%Qugh6)>aTlk2LGlk~RxTlLSsT7MdXyO@kO@LVp0
zS+UP-#ME2(N~X}#EHErfc`8{susXm6h4|qg2TVkgeV0d-xE;d&rh9TV!6zy0!!2i#
zixehTd}elS^oq(^D64AEK4f!l{!eIhQC8t(vfl(azqt+O%fdVmNO*7=7YP9g0ArPJ
z!vunD(z2ppw&m=d;h8p|0Do>4-XjqIv^{wrBX`TUOC1%B0)@$$k;sOw{;X~3cHs>f
z>hKIdF)I6ui3&w$u%E?!M?A()_RRp|+oS{U1_AF9--dYlA~;R+R*Lm;7#pUr_GGQe
zsn;O<OUGI0!Rh??<IXPR+qL>*I34u`^4D#Lua_|HND<=-wAQ(1;@4kKtaWZ_f$#3$
zQ|rD{t0_12z1zH9$YF?Gu;;WBXBQ+eQ5sxA*f9+G<8zMxG7yMqoA0^)r0&gs*a-{#
zcf<`Px{Wr!XD!HD@;46z?I1%^sAhn5<McM?fa?VbMtG^oa7mdy%LTGZBo`(+wVz6R
zPm(fD3kKk_Jl&MMxAFwqeCu0j+B)YF7H*t1djpZD2M<7+fYsi-d9w%njNiGqdJ|`V
zA$Q4oanGAMUMJ5YcqX|Zm=g}MnMkW!^u`FELvXG7Q$s%J%|7@!a$jS2KFAD)@7TRs
zN&BNQ^9N&lNC$18W4g`~8&BS8%dG(=Er8)Gcn;>CPj$n<=T5-Ig*Og_e9(7nADCP&
z=cFC(3?L!_)7D_pA$Ow$?@N<(AfXlTppuq}+3#B0e_VC}zgoQd@z1CpQA^k2{R!!F
z7c~tG^F|I!MplO^W<}x=k#sKB-TuBdrF|yM02%fVo;(vjT-a+sL;vNY=HmS$s#Xpk
z`v$~-gY{3qmn#SBu5MW0aL<5ABlKpk0iPs>CT^#U`5m8W)a}E^p;@w)5xj;>8;=9Q
zCGPhCbNXjX?s-4AX9{paa%P77kWi)t{B!@a84<6ahtoqMx-!D)ipbZ`BiOi?FLi&x
z|L0!5gm)S6C2;zHz{KI3;8O@Th(JWBsDli_S%h>yz!-aul&?NwN?$|Qq@F%m94rSo
zSPbv8hO7wD0so7CL!tmuMtTwe@+Ut4<iB3B`tdJlD3AQ4%$W;D3=E@|>EbBlu(Ej&
zV7}|t`<VaSbxyB-L;5Yb?&gg5j~ha8`UBv?8{jdA2jD?y5C%+`AT8^y)(uC4Ep;cT
z3t_LXYp5dJu4UsM;Ff5d_23!0f>u2vxCKhFRos4#aQGn4`yqEkd~4FOW(L_yuowz0
zcuMd`V*~}l{hH?=E{H9}7xHEJlBTt9Wp1unKJsg8WJ{k2@dJ`WT7oJTEJa^gJ)zX$
zi<Yi}6jCJAa)4qrkV9GxIV5ZFmYjHeu>i3rVOND#CS*XSff-<Wj8w4t*(H2LjxWk}
z_}N92?v5g46par*SdXSb4sYxOT7)m{m@i(sEEr8h+U@ggXUz`AHFtw_>A}?WU_9wQ
zxHm+GKvLM>xILcW_V}5Rk<b^O$@*l32nzziyFX$$xC&|n{_=D}Lf^uK&oATe;QU(B
z&6bIF1xQ<9bNv|797W-U&{GRpq9;cW`I5Ym$AoEL!Z2(|9OcG6k9nIpLT?Vj+IK)c
zy<jcqw1mA10ii?;xoij*L(noUhXDmAu<RY{Vmw%Yc4~Di3g#qb%dFbRogP18S)p!)
z2JH~wSIFx&xdvuV4ZS%!i)4zPqPoJIJ`0mH<2p7iy)bVqNhP%*7M0#zw{9fp(noN=
z!C9Df^G*&)EI8Y>6)s`i%P4ix7vD`G!Ow?74ygiiNcJ4mM042cvq-#;Xr#|0k--&)
z8UtG~rzm&n)R~dn@S7ub%{FS3{xf1LMs312=gucuFPV{*AQRC-x0a@*dxA(tDX;gw
zgq%l+AvvX%P5Apv&GM|oIgnhY-kgA3z(){=+3K^5#C4)&{D>O9rp2X{)OK&tNctl*
z%txObe=)m$2)>2l{daA+ys&os{zLfl`MCo}<QF?I@v0NS+l%K-*@k|5wrW0?Tsl3n
zAtrPB{%NU?r$BBgB4((yO;|d~E`h>AMql7m!Eo?TNe-A;ccNLj5_EU=k54fn!En%F
z|M*75$%c$<m^9nk#5Zz?SAVu42esHgLQ(We-7CB<ykTtcnzDZD_vQK|%$a`bolFzi
za~H&R;~-ZdCzDqZcQ%dlMBf@d&OO(U5YRwZ2A^^wz7#V~?RaqRg$YMA6D&h^Z1{F>
z!?bb3kDd?&>juwXbiKCy;OcQ1@yr)bHk5^@R0K7w35)r1%!s7?O~+<U)+EfgbGVQr
z>)P0!B)L6xS#4j~su+B@hmeaQIg@TkqTpM|cENfoVqnNbKYhSJKUBFlPrjBf8dT%I
z|NOa4E8JCIUBQhyH1_zM6Km)R_Ywz(nNug43VMB$cI(SbfnxN=f>?r53C?FWL(Yjr
zAwo#t{cFQopeZDvU@5K5I|(RebBHdkL^yBiw0XvUdzM_22dN5zuTI7RrbXyg)0BG8
z@>Tr?jYwwa+`xW#k&Cp#+QLGyz*&A`Kp|wJ#%BEO833h@PKUgE4KD7az-%-Z`0WAg
z7tB7$C@2H245|Ny54!;25Z^zrc!s~aD;ZNhZxOz=no4DIBDV$~KRP|P7qv?j-X)+9
z_HirY(oiO*UM3_F6_)~1=M6EP8_?Fl$eoJ`gd`CKJWcQ?*BVk$P-j#?x{KByE+K?v
z-2!uaY&fO6Tw5l}4J<BR`N88WHT@WTectXCbddGKQP%TER3y>9m++rEE>0PJy;tu`
z&*yJzZ@wPl+y52b9Qt}duYWc+kUdU-d=!Z*LFW;_99AZ~)W?*h#K}uCm0djbS78%!
z669-(w6VgG$jP(VN3+qv75xQc<k-t*UVi!ZZkS>zTP{BZ*+Z6v_d@Jzf<SKq)*uDb
z{a!2ZbXc7DJ>I&xHU;0>=)~r0dTHW>!D#QhS*nZttNrusUAaURdb0##>Zt#>Je3%@
zL(4?vCRK(+iZXEm{(?H>o!@T)yLQ5+{6x178X7VwGgo<^chXeV`FpuE72v}UV$WZ}
zzjO!W(1feG*ppC&({_-o0u0HBTG5J`UpG3*dJ9UXER3E!r#e-U!Q%Z2$y4OLDstGE
z!j&N2;SxxsK+0;Zs%ngFNo95)L(Yn`H{i7}M*&A9w@IRH0Sg%`L&i-EnR%raGFC^K
zkh2vS<6kmZS8FMor@CPmh;p0+$kdmPv9$j5@yNfZ1O7Chw#xY^Smfvn`*4MM+f{%k
zs8;f_%4usT5DN`iDPp&Qz?|}endaR|U2xaq(A%CMrb^{Ly1j2gT3S^8z7YJfuDEZp
z->fk{rN+Jo)?SbYh2?0j^uAKDy>VzKmDyY9vu4rhHLUDjqAI+1wx8n5^d2>N_U1I4
zgl=+?9~@jR_|CGW&^>(Zn)ZpFCe}^a&Ta<=4FKDs0X>%uF@!Z2wE$RTYCfk(xNwbA
z>;NiJG|=ysZKKAAe?B~z*prN(jtp+bmzVl`^ot5vem22|Doe<H1ewp?`{HvSA~v`8
z$7{@7XEcpijT~|~yq7_K><^$Z$&U%;-Bji&D<jiL<Pfs3e*``n<t#5@OWJ=Gj>dm%
z!MC>bDlB&iYMMr`yo3=UE%5*QIkGp;Kxdrh_Q7in9=$|&bnk;EtunBQ(>AJAYkn9u
zq#ob;9JcW@m`8kh$+bjv$+X?^)>K(y&bO1Nayc{DMPBc-og`(3q?z0vs&E<O0r51a
zBT2!5r|<uelw?bIJd!Ak@rdv$Uog8cXLNnTXcNCZOF#DvBwDg5#YydR+FHAJ=dYXS
zp?^2jRs28PeFtD$#re4IZS5_2Xjqmdc@N2wym#UeCw8Wt#EG3{XF1auWROV`5=ejq
z0%0Vq5R$M1VMC!MDU?}Cfwn(dR!S+WrO*=V<^SE&lP#~r0op&UW$E4BySsPq?pycW
z-S=I+3H+(Jme@T{%*5nzZ3P4KUG<1hs;WQUx-mRn^lV|yhoxIKtU&8KW-#l*C*#8u
z1kS_F&f-6DOMUz!pTU6X0w4$kvZbkZ{haGgRcH_Vyj%<2+BP9M<zv1Z#;#&C2mu@+
z=lJ{K#p}E<dUXKTFm_ZIj2+ggfr2-Jp?K`Xaih92`G<Q4?(kqkhP7%)@+8n-tnU)~
z5V{by%0%dIG_ArYBETIMD?qvS#B7=}(V6-8JsA4M(sdO;5(5*1r7WE3e&p+hEc3*%
z3xc3&L*`Teyy}{k+0RrX#wrj<OvNTmT3Gc<P`I@hih9TepmRG1ZEy+vT|h_7V4}th
zL@aT1g-y$NQ3>LBXE1$Eo%`JV-^}FSo%O`(tCbno9eg1xYnEI+yF74mzU}SHo?N+$
zfANMiQzw#?NQvfP`G;FC5tMMMu`}<<$v?eoFR0-*&R={y0lm2C_~<FWIf->}NS_Sz
zhrQ6Q9B3ET!6AXBo<|9%M|4i;jhi{U!bCMxE-v>vVq#%`!LNy8XN@|IRm&2oG1=us
zwYsIKIa&#~tW{LP1!iC+T#PMORKg+26QIX933?2SMIatSmk67egoDl?4*&@kgk?Q*
z(tmB}{x<$?*feXgSWrs5#rE8bDEY;kXVm9V737T{h1QI~O1S_!*uHbc%H_+hZ26N9
zE9P7qX5FVi2>=IKpqD#EKGHh^Kze%A2|AZq9RC0&{Fn;>`U;X>&_th_IPI1(i%yP~
z?R@mwaTB$b$n$XL$k83?t<riVsfUeO?ghnJHD7HbDjvS+Xhp)-t)m<Emeir7Z#K1W
zzGnNT;$*C*ld`T@^Pa`)_O93j(*i=03be2V^mK9J%rRO|7ZyP<eey;t=~`}kl7H%+
z&Q+J~dg=C+^3S?XYGNOI{>*#);reOID+{lBnr!Beb@RWU+;;aX*WJ9hDd{6n(7hG<
zV${^Jt8N$QNf7jBim-l8<QFg@5x`!M>qJ^C&=5r+dETMd8qlrjd^7Ruqq~v=hwu8u
ziYqmNhwu6Jesb}rohP5t817r}m#R@y9xoaB*Ujs&9Qz^E|1jw1QiPNKte~L7t4uxo
z4r|=88iI+?eZlT6mV7Ywfpt*oVc!E~2OfI+Uw$b?#HwxdsMHQ`no2!mPNP3DC+(%l
z`yPMzMO47@|6C0Yv2TCCM4I0F_{ejQ+DnqCSLMO%`K$KNxe__^kDfkugs&{Fe&Wg5
zZA~o;0M_4!@n=C-hqa>OSO-Os9-^YU4%&g=9ylfdo{MHLeL17kS(`m?{Fj>Q@ss)2
zuV3*>`ch+^Z++osy7~#7C>d+(?kJcA>biecG$iMOzV0_0H?__JZQU1@6H^o4YlD6#
zCDQ@UrvaQ}88EDsg-7<G0C@Hbor6z~!jr=dG&9qd%)Ir+U$ydYwY|LMxWfCvNkmvs
zs^#U)$NAG=uirm&b?E*5vsV9uNV{$O%2Cw@tiv-mbUc*q|NW+Upv5zf>G=KK8KFPL
z)=fn-;zmu~byo&72VidmKStnRiGm(AA|8YR0bbu{5~O@s^cj?)`43=*rv7!?(upL+
zaa7K+r}$>W%mAte?sf_P(sgf?=QeM@2XnWodd%GlvyMAr5$O6#t0tktK=J$XIRfJ*
zW2RX+{Z)-AfoPyqAk#f48h{=e3P(jkDlF*)TmWqte;IR*B1zj9b^VW^d@9-VAjaKl
zSW6Uf*Yf7!Pisr3zk1EOOIrDzM>YhDR{)zLsLJYSg#PnWU?=RYw=q8Z`Io}@ylDO8
zM(gNBw@>z_&7SZS;$HDNoR!eWVLzKsgPtJ)B7*uGmgPhjo7jD*fD=7VYM&OI)WYn3
zXR#1Uh;mm;jTGF~^5gjg@LC(XDavateh&8c*A2W9>oXki;@HTn4;1Z*j1}}z*zX@!
z%{su1)$4b~mo=hvet)Jb?1l)vO`IKXSe<maWp_qNdDsDw0UQtsFj9N&6Y!fiQLwWw
zXto@E^op<@p~s1#mVg=Q$(jx@9`bERP3=6yAg-gD{~W0tU5ir{#9eoQL((^I`RL3+
zl!el7`{b{;h8|agQ3`b8Sn-wHJ+Fkm=ARS#Y&#&!CGbpG?{*}@Fbe$xKM6s=Nv)5(
zr0|>KqAv?RT)qc6uk<E@-@5sfEph&331|I6`8Ftj2+HH#D6nY^Y$)OtVN88M2nL!X
z&RN6qlNt^O0VyI6m50Fif9dNfx$~OJ*G{geXkNc$|D%^~+q!nmsXsodiZ`O)@+spO
z8Fst#%JPQU1@Y@ECQq)odP?K`B@gerqI1#H3iDm?co>TY=(7jl`B)wYtO^r3OvHhp
z2!zj%J)1(i0LO*h4fvp7|8`+IKt8Z%3+$KLFk?j3^bKQ|v?XZvwa0@Q&^?#TsmiOH
zR8rP7clNeBmR!+T)3tk28(R15;@RU`_Klb}y=sfSWOeCwl$38`z%LN8zEH(Y$S;{R
zp=|5qi6!;>SIlV2vQL~2Gyo>Q<STR|$XGBl>FI6Q$s`!u0uXf?eMpPQSF(PVo%ep;
zOT3)etQ_q=aNq#Hm~V%ke`f)?NAK?5y5JpDMT`hN0q@@i?~nUGFY^A-;o;Y3oZ|aq
zN-vy(!tfIm5(RpTJIjdkl81J0f8&}{<BN+XG!%`zbajep)#%dXWC!b#n-l*yrhQEV
zZLL50n?OqQx@XUzJ6^qH`LC}j9yh+IsA<W%5eHC<D<;EbmJ^38R7G-J&{=nwJ6G`)
zyl-S|9FZNru%8-h$$PD2!NE*{4?!!!@|WlgDmR!*KCrawC4S7NeMqx%@0h%T(UrcG
z+FOf~3Kl%SXfFSUE!SN!%LaP=dw;d|QsOaWed?WSSLKbVFUTFmWInj)rKuY(u{_J)
z#P4rTxHV<$*f6Y=Lti~ZZx;0qm><B>pa2UR6h4dO)cZ`JDt~6{Ual!tS)X4x8rfHV
z{5y5LaemE00yU!5)Hm#dr{x>ISi^sj-!Qrm9YR|Us^V@Z;xGvUz7u(8BdpnA%@VF(
zm?wnCC9F;ZN0-8D!@1Rf9*%$Y2tVWlU;ON`m0SLB=W9m~wlBZ$%pbaDHsw{0`liD%
zi~nv@S>^JM$~tt_&pvLR`Oq7iI)8ceSEDA}aCE^{=+2qzovGvMvJXxUZD=pMd(Qn`
zb)$1Z67C&?1YunVdpH)FgNMBbL&PS+l9{kFA67Av53IO?|JTN`6C3jLMlZ;kxHs2Y
zu<*G>b3cCt9p-<(`TEW64lQvT|L3Pa7+H5|{+Ncm<=W)O=ANFuarFzY{GG2st^5<e
zdhTl2a7syTJ@-4<?>P(Tng!?t&<(7$kEU(dLyZUT)4?(Ttpzg`v0!WxD`W(a6?hP+
zgWhQ0#J|eFvZ;N}MwE+u8|RG5tGKDC@?aI5Z8&o5SPQsAzO%CU#)`cBDq=tX#NpRp
zJB&u6x}$HubCf^%-R`>rv!4sCJvz^K`>rv>WvGIGG;|&R?4pJ{=08QuKQ$+K*OlM>
zbJuNf?jPnrASW&XEQOUm(MC}r(n2?d=}4F~dSS~4tN~Ijflyg)`8~6j1k(1EEgZ8X
z@v#d2@wB2Ux7+QamfPG3luB!>b$r)Nz3YoV+Xemc8PvZF`Xd!&w$jM{ZGc8$xyTo$
zq9Bh7RJ1?2Vl^&2a9CCXdzJt=fX^VjI6<nUmTjK&#Hm!Yc)8o68CBB#v<yx9wKa3?
z#Hr<zrdL!<-`I8iZ#G^vivQQBtNa;%3BB4-ZOBPV$|2+h^ZCY^#BJn@i?43I?oe8`
zb1k1-M=Q|&vwygzZdo%qt-NB|w2HmcCbTVh1(8Lwet-InjO15-HJ&6>vz$3O-5)!<
z0QPA(d-*%ClQ#=!QH5l*WRhfNgeGAG2typm8L*ooOp?RWJ|IH>cZ9POln4?A7Mw_d
zld$lMqFmwSOAw?1s{)Y&Y|v7Bwy*!yeLL=$IdVkn^vYSA4%{-`wPaF?^|FqplIBUJ
zWs@&oap%D$+xZjdvaPk1OTerK8Tv=2BTt**s3WTQk27ob+!?wx*X0SsRk(A}%2SKl
zN44BKa>mRNm9110nutKWxwL7~JL9RzC8bSGr8iBisc78y-TY?sWOIH%J!aeSCGEG`
zvk20iVNVb3e`sp!(Z96o?=JHA18!eBMPNQjN`4MwelPS*9PH(FMMG5&^#>6+4Qb){
zj~3odjkKf|QTGNz$AcBu@D#DyRyk*WMaBI272h%j3%6(#-;4na=_itxrPaf%%guj=
zs23^u&1c_5twc-c4or^#)?iGw!E=j1&KnOlbq8`uaY({k0zh1wi-|EF9G_R%4<m3@
zEyRFHVp3rgZUWr`oDHKao=w1D1gLEXu6gbL<!gX7jL*p!QGe}|>&BKOWjNIZc9MQ=
z$t^E4WPJO$yz8zlXxVZ9Q`;{8VEgKohnw>nmaqO~!q|-k^*bj_4qaAN#cf2l|7!D^
z>2vNWnlPcLD#cA)g{GsuDdyai1mc*DsHh-P6p3R>t)sR4qZ=>XL|mKT+pkGY@BVDd
z>>0Ls{D*&@>u8&kGh&1%iNtXE1oXk9&<9CCk@LV}4(!?%WQB-y1uqtn3HmT3fI)%u
zfK~~x4l-%jq%egPh?6*F00SoA=$U%->Kz~P@2s7+<vOIlaoL_R`T32N{-)g<gGnP7
z{BhmJje5V@SyJTZ|B=TL<w(Z=_1YWuEO2W1uMagf1}kqVL3jUY&GJ9ojmlBNbMF<_
zU76p|knbPO6~DCg;c3fPqF=fl9IHt#4qc0KizeNXG=l$X;V6`iI{8no;g8?kKz^2g
z{NOuhcOUaEd;=Xo<1oy<2Jd|by%p9|lEt%Ta70ApcyQ88k2RJoW_d8&KtB>Zn5_65
z0R)-wHW})Ut@~w%8wv^<54QiAKO9m!w4-WA(|3&Bgr08&=KA`S7}xCDYII{3fBfmv
z5}HumcUsM#3w>8GZd?J6^!FpJ%61zOo1x)G`A#TEqB!&>|2F?!c{u`Q8zb2T?K=bG
zVg@>!CMgG+F)<oG@xEUSgaXgR1VJEto(S(W)0lU<g<Jvy6&0@mPne?$PznqL4t^UA
z)R~8Ge)o+VpGO&I4()p8;T^}mMtOU#EXv<`)3u9QYn!K_^!0!Is+PZUlYH9I#yjUP
zxFz-a$5!#r-gI=+vPo^B$D7ALhjzWXdfwRfr%zwC?c^g1rd2iFe(T!X(9>%x#x9&W
zcFN?=Z7JU7x}4iuLT7HfJoWU*Ri4Cgt1ej{m=p|7+Bd#(ws&sXJsl5iy1RJ9nD(nK
zpSN_AfS=K@nFBalB>_#Uz#XHww1A+X7{Ry~?h@EY6k(YfJZ4DrYyn^i-JuCmU?x>W
zNm#9Vbjx-8XBZ^&^2b)?PT92~m{isI$8{U7-u@9vUIV7TD{m=Yc&KSC|L&f}4%OZR
z{OPhX{@eRX3$;O25^)p%$1prLHs<?Baisu{Q<trHPXJc_84Pgqf6dR~kMGYreh|UY
zs`1C_9_Jra&iOscS}=<L1MGU)SyJLk;21T~BSO-7?nCk%J!SAY4yg&x(Lgf+-efTe
zBF~NK<p0Kh)j4`hCsHA0XT#mWio2Q$7MbP#(tD1T28cua%XfVA;qAzWymx&3(H;D&
z$i4O&SM|G{oB2Pj-@k7o$jE;MWH>=r;<H9@)&nMm;58UFM1ixW6QMk0=0CZ%vY7+B
z#B0f0I*}{8<17f%FbvqP5hbCgVkrR1;Tc5FLZm+emx2@tyjRk_`H87b*L&L=s#iaD
z;_hEQwS04Z@%GuXI_44Yow&7O;<Y1oZeLy!T=~$rrWudyy=2C=nN3rsz%zD0e|!ed
zzzbsrs0_x~56S>|bu0j+A%7$Y^f~-cfmpHOV;|&a*KL`y@Rdi&6E9smcEaSk8|v~l
zk8K-Qwd%2lkDZ=TcSm``fyFt&CEj?nYv-@iZQ~zYIeP5&D@(jPe8p?qeQ7Hn9Is1W
zT|9Qtou)X>oH-xwdxbFyz<b+a9xcN?20LAy&|}D_^*Mke*-zaPT1RZZ@f3e!=sk2P
zzZqS6n)p}ubHt|52Ha-{;C;S<vUm+QJRj?M9bjv)Wy<IfS;;q-Zhil?BjiKRTsLXl
z$%mHTOvZ&Sn^g18>TA)FU##Ce`oyvcW3S%66$t)S{B~|aM;LY}1KkXA8P+UgKgQy=
z8`$m!l`||hK7o(p2~Y$F1VkXB41DO+^J@<tJd8$6E3RGm!l#Djt6T40a?_E{5tm(c
zB|$8i(6wjONb~^g&$;9#Gy%<d<!$|~p6}idWHl`M?9MScV`AJEo?p;7HGJ*`6mMXI
z2F_Dq9j+4}m!hc9?e`PgyLoa493a|4-FFqHzpdx~M9JvsAoZq-=dL3t+`F?Ga~>8<
z*JFIfEEua%%mQHp_6jip6e!u%+n#=5)1H4Wp0jK1@q1VATD)Y_<`*W`FYc_Jc>SU!
zcgAOX+BCm?;@-_$8YiLUk1d@$YvD7WEL9h7Z@+V9Q)A2FDfjv`c{dZb1w{dGe#hqe
zpkpylwdQ4JvW*?5H{Dh-GCb~0=ROv2GhWnD5n*tICIo``@GGW1!fHzdPjO@M%@RbO
zOCI~THFvfajau;H8GYL|la4IC36ZB>SaZvfMdMdpSzo<q#MYW?st`eZ^}tp9?-%7k
z|9<mvL0UuSnNx^aeIx%mqUSZVOuXvw=p2v7>=xi~(zy?*-9RgJf@MH#H%r`UrNf7i
z!MS@>pJ6nicH0V1wO_~oansrmvhQy{RcPg(i_6)&Hz&^Gz3OUjJaOpwcK*Aj^!tyX
zS!gDjoH3dIZu9ZeZ6_XXeevhB9)4sN?gxbZb5Ruo=mpRXs-pWK80`G$>X9u<FdJ=n
zjrjIi!kIDu?3F^f>!I9!*vk_m&<ij^9^P`|!~l<Z7o6U5Q2V<P(%tgP#uaxxBK_H!
zZ_kAqj?@wBUi#HdFCUn*cpWk~zV^)LUyj-mgmx^3_wNGQ0QiV;2^h4tmo)SchcKlO
zphtL8G<~4DuDPE7mjB{sn&+OqvAWR~*iqsyES{XZAjKS;IV;Ec_;ae)KmBs+uC138
zc<1?I(AB4xtQd<7D|7M|R=CPZ^cJHma+GA*@)UFzQjZ%u;r7mB@g7c}JS!XUvG`m!
zbu@}jV9E*`vIRPE^d$dgXeF@_)t%(6d>tz0pF!nckoxX-h|JI%;eNgh-fs<*PZ;=q
z7#D!-M2H1U{?_chng824$w}RF_aCmQy6bS)aWi>yXy>H*&WX>~r=#cI*|2R4GImuI
z&z?0el{j;TKSvw0cY&x!Nan+Ht_8Ybk4QlnlmVCpT?C+8cpJP(J;YO;qM=X>RoCvi
z=JS;^UTa9b`(d=Ad`xk?X6lBAei_@kf6~qKZsDIhl$kwt1~Dl(c|x!p{rs)XI~*fF
zTzd@7d*MwfOMR94@N<Q}QA_x<&pTx<Lt4VSEk#AOFt(QhtgMaD5ZDC=G-Pe)F8(%R
zRj85-Q59#Orkc+H4XFbfasX(E6?7=&;eHC+9uGtvkBAVF=o6`C8#0$5J)8@~pU7z`
zc%1_$_y3;%^r}ru_phDz;8j0Ab@_>98?V{SA1%vo8eLfBOsI~XT;p|HM$U8j^1$@S
z=;}oi3LDVUmlrfIZ$CP7e`#F7q4_6fG*mP_IPL1Z`270`Vti(DVsdS<(_xo8%!Ly|
zCu-|5wK{_?ePPvtl00`V9)pH+AH!HrfiZv`mk|j^WOZ<kF+yI#@?P|NVEU39pw=9F
zoZnM1x;S3jvi{CldDYr^TV~um@8$#7eE4^8y7Iz=;N%^C-RP3#X)|3U@fpAO=WlT=
z{Z;Ci^i6AvvqvrY`yaPny7eah<F{Li_IO8bF3K@!3_xTE$y_)muYmOvb3{ia&^%GQ
z9d1pSqx487m_Q3u8TwL@?wh@O|ADm~+3qyo90;xH$o5=sOQ;w(ciy;)1Y4}FY~td@
z6UuC{#4R^maa-r+9n0?Avj3*b!=Y_!*LAKOKX=~vm7Qx>E!sL`!-g4K7XfUX2Ig@b
z+63$9gJ~atnt*23OCE0soo;MCy?8~fS(U!0EiR?vbW=q|MHP9lt-_;{GKS~<Q_fxv
z^(_EclR|ya^DYe6@QQ*-M!|utz;y;w*3u3)et$|z#OgCbF;f%K$K9PX_e>gD7iY^$
zPS4x9@vdK9aov~K@b3|FBv<E--Y0X*inPiqn-$&g=F>aJjY`jIh)Yi{D9X5P!OSJA
zfAPEDU-EUp02|c-0KlgHpQ$)#Q-uiA0&@}Rq|m!z@h75j>6N@NtoKzb!*Eb>`>%NH
zp&fSzGm`V;YyP&rwPRk}rrFJL>P%_Lju9<WM@>Ig19mdg^7bvc`Nq{dA6-;ggEpL4
z*;&(kdqx4gOw7jGhD+8pRF6njNhw50^Xr#4c~h!ll9CIH(sx$*>YMhyywW?R4Y!@Z
zyd3t*Oo82c!ij@4*s=hVccD)ULB14T1^W_$*TF_(L9yinWf7tZCm-9<JdU3`uKDuN
zTLoH`0sX_EQzy$!CV7tQ*kpbaAA=q)|GWyu@N<){$YCe-c8*2KzV7cxNeDk1NftuC
zaX>e+&ev~PkPv3_Fq;!vhB=Uq;%>P5`CB*a31*}OE!EHNm_2Xw*h}tSn2<Qq=_eYR
znnGW$yynEe&~49dTr;WdKt^#vN=EFiiBm3H+uX9qF@>o0yQ(Vq*3xrAA1s1)Ffe{j
zVck)b#RM&Tc)})*Q5d@L(<64?vCP1Nv55f1@c($~UzbcDKjp5~n^!eX3uL6^nNr6*
zw60UX>#0Z2UO#T)hGmmyP$W_P)~5T=ktg}?j~+z2mySF-r98KIX+~jwN{Y#O=*p)y
z@Mj;}IHjemW|7<xujT*mQK6s0@HJD^^}=R1p+~@?9c=x<K{((84F#V#abEuBnVdmU
zGJ4JG--MpTkX&CMR1?3MOr5o4@h3vxPJgPo1Ev@0DER{b->EHAoIsZ&@M{HGsn6O2
zOcF%u5$*^Yz%yF7!-5K)w?>3LL2!vXu=~-Idk(ZtTEDb*@^zOTK784={O9W@ww;{Q
zyl`RDoH<PkJDcX%=CxhAzHL7IUfMPfZFp!^=b}{)u9?x~bXAU<cT30AsU5eRo|@D&
z1BKd4gTd1F_A>Yl{e8`tnwo}7)-=}EHUjKM#w|(k<P4+$cLo;hq7=eWYsG>%4R?jv
z2yV0>pbBkf>L=c^Y~!Yh^Jk{y8G=*p>6)#Eal3T=&K=MGW98K2Qo<G=H)_R}N5)Oq
zuyo2S;@(qtJ>F80UASs)eu~@dy5q{nHf-JW*fX0qoO!5So-QX<q_e8TG5zG0jZ>yo
z)W8_h5--1+No5RRlfW$5D7jX07!n0E0~Hm(H3{oEu>1zP3WrxvOo6}*3M(vW3De{t
z*50IHJPeA&8@u}go&zrhZ{QEVdeCq1n80@e=n~-q{ejh60I*moiF*e&WD2EoSrZ;g
zU`;S`MpH20^g?#XoDFJfzmvtq;bgwhn;s^0=UL0noz#ar6X%|_%$-YpIQPh&qD*<)
zUuo7=s8Eu`tXVhZ1y-)wUP@BxY`cs#viYvG0J0)u^8M=EY|7?;F}127Mztd$#ebbz
zK`5vfXmvYhbJB5{iE@sLQFSo?hs-fv1;1IbP8GCi;)qhtzDVj`lf-`)|5(`)wSl06
zG6${Je7$cU)3tBkzph}qmM#0&70ZZR7w!I%Cf}f%>8g>QT+&|@`_Pz%Rb$7_oJGQu
z;*>ik=Ok)SZUZa~$9o#l<=Uk63MFSHVl5t0UqX6v6iQ{LUtTfKO2dK`^GY5qB?-bM
z)fY-h#;UazDC9d6MkoDDOUWjHdo_ZB?d?>b@w`U@cskT*;+b#{XnJ5g@Se?Jt_OaF
zu`rogpD<LA0HX;EK^Q5Vghx0$1|T5e0G^!`BR5Nfsxkt|IRFDDU!qH>Eu0BI00TMP
zFtdQ7LdCd3{4tra`i~asEye~82N~aU5;vui#e*AUrYa{X)q>JBNI}4#BBpL+8*Ayf
zMqk>XHRWbe0bs%><P-}&dO0gnlJsnY$`p&rw)o>ciRCM#qc}Cc+nS?uC|zVG6Nl7Z
z#91h?Q=godU(eDqS{sm;kVP7g7WA9)662KFhFG0i16Cg|G3Ato9+fNgF~;=R`2NFA
z{*9PoB%j|ip`B>0kj7Oo?X6^TN^V?kjM8|iNv34$VS;6&V=28QgRt5>nklU$V^ONq
zGE0NXz{Zn{xD1-e;ipQo)m7Bv)a6xiNtUGS=?rC;$}|b)Y^y!s&tmVV2^ptz>I@n~
zPD(0`iU^bSe!0UcPiW|e(~~7LB>RSj0y2z$;vj@&c4wmC#R!kG*%ZVwg7CoumgK~n
zNW#Mfs|+r{a+jZlwRzZD2Kj(XhY>rx-wLY*h0ItNR19V{1hLMHOPMjW4Kl)i&>E;1
zqbycxmRgh4dPbRG9A)Mgka9N8CXKD$9DhKrl%bj|8@FQo2sBbL(VL|6&9x<Z2o=(q
zDyn(n@gl1Roiu32J?2tTSyaBtS=``AW<3-1O2=4LLec{agA^3{V_Lk-ZHtdJ_a8xu
zrDCnJ>;=WEk}`Eknd*$mIZk9Yx|Y|yyii8i_Dbze5-Fq!N|~wxyj!bD)|e33M0ngO
zaUWTeb%*BHX%u@+vh?^k`&f69jJw1+)v1WDpP=?xb(GVs*fJ?6R_1rET?XX0AHEi0
zZ+t`HYnZ!w@M0aDoHdzAqZ#yTfJt<?Td@ppg0u8^ctjjz-GG^XHy|#?YH<z=xNJj%
z^!zJ{qehk-Pcg(!v3Z!I(ganJjDI!GpbTcVOz{w*6Iz9e%GEJn8ERkO&2SIIr<7i1
zvdfGbO_JPhk@xRK!tVs9Rhbm=JY7ratsefxmBivnx!R*Vz$~e5T0enEToF1*TOA7R
z2rw+9wjL!$`6vI0@uTEem|du}*^|o3;!RrUkUli63A|R!AG(*q>jfq=erK?h$l^oB
zc&`Wx(i#gqSomPVB#<8<bzuPlcv={m!D^ry!Sag_>{-(Q*=9JhGmy{lACA-dNpkUZ
zF&a{8f`cRp$yb?JmNRoQ&Xgu6TWCKRm8Lnia7?^jtE03?W-iLR)s%fdqwuo@hxp^)
zYFWB}pHcTtFqUU?TB96XiatMTZ%#(+DzM9hOgdWO!MfN+i+8q6C6|-*;(OyvvCKrO
zlT1iVD9$jEYB?{B&G<5@cBBO>7@0nORt&3zS4!R+y4OfSmKA#kQ~PkgnBn~~;DmX$
z3D^Zp6)*u0W3@=i1x{{OAwX*Q=z#-x!V-Z%IfNRp$&E0>fV!~kfXO`oYq(;D#j=2y
zj;n?>FDHzTU=l7YWd!_~t`sA9GHfr!nW16saHY7ca8w4)Ne&#U9Yj-+BTb!lG#D6>
zu2W~k)yUMAY(}{|Da)0X$rU@yWdZ+g`K(q-o@>@|w$ZgZ7a2!W(<!b(lSrwhE>}<{
z&)?dyDJFlu)9>*F7N~R@8$E@R8snI^brw%TvMe*Ri0^Ec#ReA0<&<7Kl29imOJ#)2
z9hc)6vsjj7)@Hg}^%lE~DYV4}7H-@B&$ObT#-!C`XEHK+45iI_jO3c0kaF~5+SVT|
z$frzdh4W-_NxegnmON9<s@G*^>Ak^JyV;#&w?A;BSvOYUS2|4!eW$U(-rDI)*QO@9
zM<=S_m;%T9P>OAFYiyOBR(mWKWh&!JRL5APa(OYMi#5=><$8z1M+7>V3`Rv5nF>y=
z(^9b(Y03IRL(-g>+F+J%Bx4|b`4;u~#GII1%MGx&o7!kG8q=?*RpyFp{+CkEKw9R+
zv!|hGnP&(IbCB`tTG4G=v4VVmMdJ8w+xYS1`{Vof&sXc$(<|4n|86I}a_ZFYcEa*2
z9EIxx|5=g_$%~RdNWK`lMWWv}$`_H-fk0qBg=JoVGXP3az{TJ#0v^mke2HcTqX=+1
z4A|Lt<sIPBWY&vt?DK+LBnY!mArK=h@d{iP>cvD^fN{`3!-N~ic$ohJ9-7Rh2ncr~
zepr}x1CR?<igm$5U<uCI!){ra9tQ)g-wh=IGcezU%FKhYSpLZ%HHW&MpDxoRrn;zc
z)M_}%XioE1Dm2=W+UnTEL`qBQbh<HWq){m2JK~*=_cb;jk%%<9O(xQ4awITnu$3#%
zWmFoys>EDZDD!FE+oyr$8;?A0M2y@J!~U9Z$kHbfmX&FYj55n%Gdw}Til^r#f=zU2
z4DmM2+VQ$Ff4t4FkJIMF>g~ylJnexr{Sj`BQc9_*Sb1z-na!ZN$E9RtL^*+EmKZgs
zkIC&n`t;%$Rkg-o)RJHu)D(JA&Ki=OGVqJUTJlheJvK4cR;V`kNqtPMTCPwSq&~(N
zFXd+?ZfXnI$I6<f$HeC;^sG`z=EgY8aa6H~)v-34rbXdZNE4+TrM4GT#HtG5m>-$J
zsCDC}#xP1!tA_bd+GwLTowPinjLBu0IISupGpRY7B*CbzAr}O4Ms^DvqLxUwKClQz
ztH2iAYmyHn|2Q8s0>I$`bOrPVuv{(1z}d(DC`^XFQID!y7sw5uF7M}N{<F5{%yp#<
z_=~lyBed~pg=7CKVUsCT5lW>Yy@2G$*a#hCBIVL-MV{KgultFCsk9G_;`5p%l9iHo
zU{#kt50qkpBtR)hqe2*{r^^J(C|C#JOvJ?01v?)h3&j4XNT}MBq@I0AR!J(_U`TZu
zRF0BowJ{)`j6j5o9ILL(e~Q0P>U9$D`)XVMJ3+TYE2p(aTLUHM{|-*8XtS+=;eTT!
z)NouTy&(fEef-o2ZC^TDC|NFf3&nuzS<oB~C5IpbOc5~Tx;>f5Ny9lwI1daQ7d}R;
ztb+;ePZ@j#l_wUW@eD95h6@NO2<ccjjtJY33KJRw7B}2}kPY-ctZRX#E2!c7$q@IZ
zv#j0_U#=v~F(v$~YKxRsC<$2%t*|Soa*C)|&G7#e0AFcRr{AWxX~7^pl})*HQYtrT
z8I?m+YH6Lq5~Hxf2@Z~=rc#vgDrY?kXk$|debJ2<D}^vVvLeCJ+PXMjCY>5@Vbx}J
z%SorTo;9k<ibJyhJg!jjX-cVDZXRc{aSZE{lIl6CpuCWi=@q(|62I1?Q<9WsZYS-e
zX{6*I%OFf{r2ne>-SZ1GefdO_WR>JTq(h0wkE+juWeiKRj3~!Orh>vU2F$-fR}8Rd
z#7Jl|=Jsd>!;{4D%n+~3V~0aVjH(zv{h-^&1@PPyD?NU?3<l#D?3rO$tWUsOIKD5w
z{Y7QwA9zikP3ClPR6s`MQkGaMd9+-qCH3P`YJ9vWuUQwH#<<lk2PI2NHk#;IwRtic
z6Y9>Y&=3?O=VCN+X&RH0Q<C|%i)4_h9vsyC1SI}?dJNcjF}h7;S1f}xEf<S=)G`8;
zqg1Sc;uzHtyGpK>5tN2XE6itNm6fyxTsIkL7h*Osgj{Act4MpIs-}!16pD&zlrmqc
zySZWSoWwX2TCIu6%E~7{*(%SKG0yJQ|9PY(*C=T<HEy@Muu4-NDmgzY!p^biwVMQC
z-)*&IgXDe5Kfv<Dd3YX(V^{?bCJVvBBt|G<QUORN@II3Zt7pVD9jvAK>0;OSodJiI
zIAZ6>YT~L<ZP|mD-+8Yr*+m?;Cwn(46ofp{-SsE_ut}|Xz+ql39f35~RCM5{fG8I|
zHD+p(XWNRNHWMsuvAHL!wEQ8plg`RL+-6tl6pB4dW%b3h#>|iY&qMl!=FENdH?@*Y
zk`E={BI)^{8UrnB1U4aV9Kq_6h%n~_6XyZEk|AhO;LsYZHT^G6OCHuYH?J7Yuo<?I
zT~<29!K&wtH|I{bD;40i>C0UE2b<h!vI?*(NiisYMA3gGRMT&$Va3Dhn4r$DiczPq
z9oHL~G)^^V+&H3@vjuYhq+gfmoO>fhp`~%5&Yu`)_no5zU}w%6&`W-ai1R>p4-|(d
zCLsRg!nzNJbNs==5vJBj0NekAq?-RcJ2s=(qmIesT(P<N9%~XuXL>VZVitH8PT@iy
zF1I^pTjCJIS@r0z|CR7et<-R!M<1ms%bePl>yG1Sj+x-~?$5u(NFb^FmQ+i_M+ZYo
zeqw+;K*v5qa)YEBsgdJ6kQ^2<^nzj=Q)|ZT!~#5CpcH2Zc!mmxPw@IC+{TM?!qSic
z<KaoJAoBk&((Y3={@j<OnY7MdY$$K+@-uNuCXTX_<ina|s&-CXmW<QV(h<p0a}3D4
zS5e6hBHNjeXc{xYo~cEulK)QFuS_zi?nd$yGId4AhBQ4YT{W+h%qN^0sfpCGj=EH3
zfK*csqf1*-sdN&hSzy(EUTed6v&v|1r&WC0PYf**`^e<WCF>;HVCD5%@UU}O@~q^K
zlD|m41|y+zq(||vH+})?LhI00bOky{q!IyQ3^9l3B)W)8iOY#=h#QB-B)n?_{5JuL
z2unvSBUt|tBp_IP#moOeH*B@Wo8<6LDsib)Oc2yt*lK?mxx!1l;i)uE6jrzJh7L36
zio!<@!JrJRF9pIV>4Q0Y5KuD^G~jfY+6K(<&~QWW)1gAFX2L6Cct4RE!CW5pcL_OI
z;R+eDvDL2JfKUS<HtYt$Yh5bXn*||Hz%T5j78(VWV}T8yIKu=%c$goK&Iv1QSaZj~
zo_`SZpo#E8p4=du+5vS!qHvN8lMmb)=me}$$V6~p6y7WV`_XV47#2>wf|eRw76;96
z!B2<Rb7F-WZaX};1VL3oT-ehR?p)z5;b~?M2$n8Ew~ZBS0x|OmE8V!6c!GuL8FaXi
z#bg#FQh{v?bd433!STW!<icGEtR6NA;tWFnfj&eGi83u%n1QW1Aj;y8D=2K1!a+C&
z0bKx336spAFfLG;2g3+{VHgd_hjkHQT|DgP!s$>w+(3eQ9%Nz`z{cZ)W<y?RkqJ7!
z1mS=Wul<LE*w7vZp24<7s5t#o30gYcBX!19lJOnWv`UI1<*|CF)U2*#K>L;e`!gyk
zRc3}!dQ}BKOSoa~*s8p|v|`oLKpL0Gxvp>(?(mGhv4P4k>oOM3GNt6#jaG1+Uau{q
zNTW<QTNA6$#+2w`(NNt)Q5hE49<G<MoF;u4r<XEd!al~y>CHNYR7U$)FH(`T%%mnz
zj3K5`CuKQi9;Zpn0i^&fV<5ZE%*Dt_c?J#p7Br}ZidV2o^$JCb%Cl0ci_@!S=6Yo+
zd!YhJwS-qm>uH%rW<ffso&<#orB79QVMSieN@Hm*m5GaU+Z4`Jg*lf7Tf{OZ!H0^Z
zs`OZma=KP!rGpMBESzhz#!FQxL~N~#N+LiRN3#?mjkW5TU+ejKG6PzvPF~QSGK%8}
zPeH)ngj8OYoKo&fmh+Dl(rHqC{fG>EMhzj=F!5T2)NgUQ3gQ?8!yz^4esbsfSvAuX
z)mJXmj;Q#Bnq}o0RwE^yu|}y>>ok{7A6=i(O!I$EpF*={o!&DB48@+4bi{HbqoQXb
zuZ!b<D_0k*<()oR%o(L6kdmC2D0NF=Po_mBS1^i>1#hdRQ_M^ZqsUjuSvQkSG3K;{
z&@QP{D$~dL$a7i}wny=YTr#PGl;-ED?Ic3-vOKkoRPitC^f68+qje8h!aY4QsfquL
zWo0F>$1zD-k!nqrTPup<4KBM)m#9h8sP%brIBCYJI3-h<kU`2atTECo*F><05XU6g
z$jo4hIzdCI5@P3mSE_0PziynuOG*i&TxDFKR@rSDxm>FR179g7zs$rU!X%3`nXO7v
zuT(K6SgU3A$>2c__PuFfT(vakR#9^}6~KrF<S{dBSC27pCRL}=3NYj-ip?&8E$m4X
z2&saKrER*gETfT+RdN)YU_tENNJW_$B>=q13yzJlu2#l+f#9#qn6I-GbTJ&kpmL*3
zTEZoIq;6VjK=63hs8cjjYNx_X$tiFIEH|Vn<S4y_ab#9Ye@(I@<xYJCm#*+BZ7>vm
zvz$&c%C);0g=}_!tCKN|ycTv&F?K>KlTx<0gk%kU2SMFzvl!h{k5R8P$138GFRNx=
zGCf&iS0`BFR3^k}8J6@U1_I;c8ij16+v?10=F+XjIc#jF#%Q!6nZiJG3RRYhN|wr5
zQ#R{Kbm}~)O&3R~Sen+@X0g-VjGQHHt#+2bft|>ywO1$|iOzJH!Odh^^d_6!R6R-x
ztM9Z-E(3db7JCdj17@jIpy#5b+9%^vbXucU%5jFY5=+pj<dDJ$p}a&Tr>M}m6!<)A
zUp*JzR}ui<f#s4KNj;plA6n1lW_5z8OCa9*s4&R@XYl13{Z6AE7#t8g^MI5=_MwEX
zXm95@AN)~NPsmkVOm=mxBD=_9_=^Pl!#DXI$AO81i4=A8*s*R+RD_Nv$#q>_&m|}G
zf7#Nx>{9X{{o;84fU1v7f#1In=8YraB=-bKv!qqh4*TJj4zC|zi*8S!&{1JDpa<vy
zDFgGIzn9Ryo^I;?uqTKX^!5{axi=iL_J)Vwe@8E-FNv`OJ6AVI-&Vu<@NtsKk~Y{i
zv;ce+t(2^nY?bVg>>0X`$*8{U)2~CN57oP3CnEq(;Tr}}BwhxT8e{}|yE>}Z$)uhE
zh)N~S_V#(W|4AoK>HcFExvwkKgu$AehJS}WI?)5t2hyW&41juZWI_R9fQYTh$=#19
zCllEMN_3wTE(1r;H0aokmrRjNm&}nYg!SJwZ~}0%Ac60b+$gyXWbk`_*cc8Ue<A}J
z9<oR*GOYO8cW8g;2uERCRPelmjrQWf4*$ZC6BPark2-o8k9zp`dyReQp(xDk6B!O5
z@b3tKAYL#$@YBLy5hnO40!)aPfuI4W`l8oH!ZZ`xW{FVC)i5*LBH1aq8s=s<NDfKv
zlH4nKQ1Tee(S9y@>EdBzI5^)Y&j3swNL?c^BSKIFbozqLFzPukjo`a_2t!mbid;mc
zMg^lO2Y*j56$yujq9OxxhFRx%>3uZ3M2Cl@F438WqBOk>_j{3^fdFUg18;V)hM5H(
z*Rb8k2C&gI1<qj1?V(7QNv@DwCD|{z1t`+plKUkmBu_}5le{2#d1$x`)14r3(N};E
zb6D2F-~_=4*#U5ZIVP5V#2Z*18klD|DFf>fQwD)NEJZO4e9?7cfM3}^rTgRlDZP0*
zi;EG_)kUzvm0vE9sTadwgu!dDo1rElopcJEEbjb;1zD~?K+*(IGlWQv<N5Bxy<wj3
z4M(S=NrR_H=cl)mWbQmw3(&Q_LI~yWFv_nX`MJr-&kG@RZ0H<hrEstNav>)fGn`t&
zwMxK?RWxlZ6lvlj$qIpA_Cn{K0G;<lLFb#2w_&Z~L&=|ESK!}=hE<S-{DM}-W9*fF
z@EHR9#kvG=6R8JP1q;S@gnXdiG2=K$ra_~S&kSBLh$uN7d04O)EI=#i_ORxlhqZ(A
z1khdtA<nSo01K&N0SvMr-$NN}`OhQLO%FEY#+oDGFIEPnSSSx|gX%z06|Naq9H|VB
zKq06?oGA<f(I9VWc3*MDZcPs%UAH>kZjWERj>3}#amvsyEvk$|pq~8SV^lhHJ%-S?
za}(>zuQ0cok0?B?6(hKR=4OwmXswyvYHk(e<uG*(9ccBD+=$g!QcH$FMQi9mTskbT
z9fQoK)|x6P%6|@ZkO~j3@saY@+{CX0uJ6+sV))+;O@B4Yx1N9gEoIMS<$;IqJ7F@L
zO(*Vq;uuBo$Ii~7sJ>}<hQo2a<@jUNl8C^K*d)0k^wy=zrtKxs>QUY~Q%OgqBS{;q
zZ0%ss`wmxoTV=<#N=GGX5sF|*5I8(hTUq1T$8_8j76|9#aBC%@66HdeIjtj+35wY(
zJ6fO;L_l><XoI-&;MB@dUi43rgopCe6v`w-0+ReiC?kPW<<U6MmtHpwkP>za8r=R;
z!W)veM11%{@{Qy>gwBf-7`iW>ehU~BRSsZVq~`;v?r>=JkCkWO(}$+{fFT0O@1^1q
z+CPxe_ppV5w|a^bp)j2nNcHz6`u#b`kIN*Y3H@*w!*KFM*V)TFejHXYkOln!1|#o-
zTM^lNt>l>Gq~!VYO4r!J0eB7p^G6ak7l(}o9QO1{2UdZX5<r3OF~GVvJ~<<7^ANP>
zSZxj(ZrA`@2&6t2>!~s0fh$)3!!MhghOlxQYEdI$sly0t0xxrbcad<trEroBYWD-j
zfb|4id$=Yj8~toSRX^B?vwQi+KmHhev5)-tV>B|Ef8(vU_%~4ITW=vaB=(P|p5p(3
z<WD_?<jG$jKmIlT#+3US@<wLoIHjqnvP552bwPu-Vz9L2`h9iEENiN{t}e!9&yv^e
zs~?#1=aF9TNc>ICayYW^HyQu+7iq}5dYTB$g|_vyv!{X3*l+{CzS~>emXKAIF0ZRo
zq?BbQ%&PPbNXe?(Xfjz+JR3Krq}z@9jdlIw;Z}|Gh8vaTfJRBc8&)(Oj=&0@r!9cJ
zrAH+1AQtwPmZQ<YU8bQqsB>r<D_8**M=D}}5s$lI2Uvs{I6B({J!I6#4ln;;z=n5Y
z3;}9dFf}?5I?q#p><^m}(6sjj%`jwYFDm!YZ;N3c%*6_(48h<HoKC}bDzxHt5Q&FB
z_4PgXd>#F@eQ@Z|2hrb*)4O+{j{e$CZrXG*`m1XyO!X%v#WM+ZF3#-?q!%^~NO9*3
zNE$4YEq`&IG|6b!<^^?@LTPYue*WU1EXkOl4d&_M3%NX;aG@Oc`du!6^w(A-{@Egb
z{ZWXXC-%bGSH%GFTd^BL7BN62iT!Z)b1^`CBX&f0NDNTq_?nm`pM%Q_O6}Q+=1~Yu
znowhoPVsh6x^Nz{Ew4?jHQKFhZT38srY$dkP^(rWCTLY{-49(L1Nns52i;9#fNX_c
z=zbJ_$Y-G+x~Ibr)=68>i?>@qS9&ApR9=#N0Sh0cu+F_79YlAb`_M`B3_68gMZZPo
zIgK2R$wP*tFc}RMj>7OCR*!(lc#Rn&2QU~B=YhKbg%KDF3M2au&m&@Wggr$_K$tuE
zykX`PrU2;Ql~=@ld?pstf}U$`m{y?v*Z%p$_#m_+q`7_h^4swjr4I~+_U&J=U_bt%
z^nsz!&TZ4DZ^K`dJ}?y8w`S6$HTa9t2Zlm76?iN~Hdj(Yk=0WW9Y*QVvFPy7cS8Hz
zbuQLpP`F$QT{7dUbN7#<^!_RR;}^~m%Ec52rT6}Z_F-0z(tCeH`wZ}h(tCdgP^oj_
z{=Plr?;oIw!=1gK*Y^+5@!_7{7OLwXpvHx}c}<A#AE2pVwx*!GG@#8X><NWBdx958
zq*l4g6f&owtjy?^$;w=PVxgD&L@(kd^&9BH(89<M)dk%bdM)xpy$yXQbffSCw5{*l
zu)j<ap=}RIo&oyyTgh2uN0q1p?FGvADPbn;gonr?f<!4%O*9ZqL@UujEGAYBEw@B-
zW_k#U)h9iQ+C@yXV|g{23ie5ls<Tf$L#1DI{THT=^p8XxhgHu-P({~8<h>Ybdr|d@
z)Dq4p_Mx^t@!T-g4cmVQYTQ45f%1b;;p-!$H*_QtBAO$isI;mG5e^-Rgox%yC@QTW
zLXJa6A|awV5{gQziV)_|kw}PWj)bDp>Z8eUbU1V*Iu;!!nxkXU;q#QK>Q9vW$3sW@
zr}U2#&HYpQ$1hw5`Vf=&&=LGgG)IN2Frg0}!M{W^{uRSjnB0es;9sJ-H{74}Q)fhq
zFS6X*L&|;$gi<8@BHP^``m|pH@u^7vMb^75l-MtUNEF$C$bQ#^-s+b?yg3L5=;Z~y
zq0oq7W+bZ5!wmYehQ6`To!_${aVH)Z_zP8quSJ9~Iz5Ae$4D3vJTwdOpuiuj0-bMu
z+n<+w02WHl!i+Z!HK64nGe3dO5PIMw3yA&1LE<jrKH?<t3~`EhmG~|39&v{Fg7}s=
zN3taBk{RlR^KiIJv~1jmLkxox{1C45?|JTjjvEa}=KpWuSpRA67MW9Ah|3L^+x4$+
zcwBGLNk}hG9EAT3Ix*?xj)QQ*K_@G{d~y(;IOqhXmt%ep?l|;RX6QTrUcPzZ>Cc68
zTpVZZGm#4O+9>|oXHs<ph<P#*#bu)>SYf`~pV!inX;u%f9WdRB-07KiMVRiu=~v`V
z&or!u`wp0nMeg)W%X--GfazJ}&Y;t@UM}1l8vfL+w@h#7ywkb9Y`Jgj`%m@y*3&m8
zOalcD-ZK@%F=0B0$Gdk*h-1RE5VP>!siDBoVSbqRy?DAF=83TMfTp4i=yuS7eM+c_
zLYN!w1&;nHX(sKYhs+{_WGPuqHjqtZE7?IVCRdRg$nE4FazA;Hyz7T?`97Te$C~>M
zB_Rw||HY;cRsY4N4`cp0EKdDXtLGx-uNO5Z{co%H0(0R0(!l_!qW_$_fBYirAD;9v
z=$!k9%)@`k-28{k*Z+Uc;s1;0{r^_o!Ep2l!_X<5Prop<%o7oHdUVc_grQ}hh{)3;
z3`G)#mVqLoPmhi|k}$L^6cK@Xbk~uDA0`v^3O&7{L4~K@+r6QGkDSz3_~{!vuYlDz
zYu{L38LCH^8YoBg2vh@QsUD#!B2Sh7AbF}1bR|<k|Go=W7k`buCE`I}GK<(lJVBfx
z^&m|x2+L07edI~<8S)hQD*0RTJ@O3s1^F#`4s3m^DKl6P@_?oAAXPd%3Ck5F#YBgr
z^%>DS3WiJ{LW=35y^qQhy?Y^A@6soIh_?Oo+Ie9;jcXXv)^PF+M^7Ve*7(8ex5KLE
z-y~iAyCl5GPLm&dP5Pqh6(ulNziULYi|kh!5br0+^<PDa?0bnwggx<o&xt&DK>cFA
z$nyu0{4zF7nX&<Y`SgJyQW8mvTti19p~#i^a^?8(EAf|49~dGfk+jG)bR-grT!~NS
z*453$Up{?ch?GRqBG=H7NGNh8zHF_mY{g$beP9UOFp760*U*tjC~_sf&9Iv?V=b20
zEVDf$I?Sg>$D+eS-ytQ@`Gyk?9T`rp=sd)i)&eVS(@3pWsoF+Cq<@@G@1N2?e&HOX
zq<@)<jfak0Y>EE)iNjg&$EWxHk`f%of1xAcYgQKVr5*nG^xj`mg2VVPbR>MW+lj9<
z@W-e3{*n?L#($wB;j3nVyByja#*qz0{jS~H#Dvg;VgMcJpF-{qqsPim`dvdlF@bLt
z14MQI6sj<c8FTCVUAwOn6GG340d%x~3VBNyDO%s@cMUnk1inEG5U|-@z=fU^DmBfm
z$nfT*Dm@uJp?N)_^QUz`G)TtKdxIpRQ-dT9nv;Ce>XmZwYOhyg<5;h?Pwb&SvEkqA
z4xOhUpK_j?g!Vi)&s&nB0cJbIZ}$TjivIvV=ogU?`51uf!{WF590d3@_#yO>5XAzd
zZWF)VuR$Qx4L|6^NJt{7`%&c9<)9DTC9L(mN06|0WEAWc*$eA@ACPLY5OjchL2CUp
zT1KU+sRpWvYNa};#ndWl1GSynL+z&yQg>1JQ75Tqs8iId)Nh9;$qpr@MoX;23HPaI
z7!qr=^g5jIP!evR=SE4s!)bGLo<8;b+uMI($#+;%<S?Y;;Yhy!$vne)uZxh5FG_;E
zh<Yz(HT0*D_oDitpTruGXfJe)NVo$eWl_S8qz`rNFIo50C$?v}&mTm>{(OCN^SX7-
z&FdrA(Cd*Hku|)up8N@2<HjvtK5krB<QjTC5+kyPm)4U%rlY2&y}hQUBXSMB9*GfI
z!%OSQZ=Y6CF)jKVdLt4eG9#h$r$urRu5_C*BgPURn_;qLWI)&qQaOav2d2lz;q=fO
z;auTZIF}^`mnJf!W6`+=D-(WVq|CtQN6MVPHPKHb?ACmc(bZC`MXIt<mOQI9&q7-@
zQi~PG;pT<zhhD!>2_oyKQOAYaiQdW-|3Yuz03pN%hJ|}}yUiwiL$Bj2k%i*}!@|7;
zjase2-_Yy$N@NWl#`pTKi!%|-4E>*oo@kkftKIrY%5pK#trKsdNJ{7rVhYU(Sh;*T
zze7Y%!Xl=0KP3hTt9YyX$-XI2YP*<1KPX~k=yMS*(PlBF+bIOv+tC*BR(E1=3dZC1
z_Rwcy3LPV2BfnY*OrK7GJ#hiUy6+JKgi^fKeY|hVv}yb*F@?T0HA$JClbxz?r>8*(
zW&;X0&-El`^n}nYJ;C0b-6cJR#GENgcT~>a;@u_T;&8vWIJ#w!;=FW_oOG@=o0G<?
zb8^7d1DkEN<Vd+Vh-s`Go5PQ@<Zv)=5Th1rj+E_*p)=NOJgMj{$w_-kc5jE0y-^FU
zHj*_5oq=d?MNn<jL&7C{@(Lw;sufE1whwOhwmpX*+vh35&7P9<I=~K|%goF`H$$kq
z7=CalqbHQfvyeu60crRNfHUY52z6hMLw|vv?#m&HK7kNF0YdbpfHu4vFatdSq3)?_
zwHiGMQ85Hj-VHynuVDO-I-j^5^x;p4`wV=r4}C4{AbcKl;&RwyFbj4RJVBnJ^i(Oe
zVBp+=dXG9oeL;OoougS=O`B;u?V+>iAYDpV(+zYJ-AZ@Ri-$ME7;4u+wDf(k;XZXn
zN$W%D&4)9?7%ESnI-_P7ecBL}ezETooxe|=|Izol@Qmcg+8yzqoNfGA&l=XdU&QR<
z-=(MjDa=IvU2V9iJ`-mYJ$p-sIm3v|KzhoFGn@Wv21Cto`lt7l`;po+$joPuwFUHM
zWZj^<ITGqk>kSQdw|9ktygssa(7Wb<-i)MmH%CIfX}zJr?)KI~UL9Fe=v|9IZ${F(
zn<Js#wBFEQcYA9guaB%X^sZ5$HzR4?&5=-VT5o8uyS=rL2cy>oqQgV4P@p%X^F@cd
zo1<gV;i1b6edqhsHgv1W>-(<_^p9V7MFYLrzfAvlcXR)g{_zXfap4?4##1i*w&WO4
zDvN6;=uI5%ZpOdi@W7PtDhqi%Xqv^f6!azzcQ@nTaCl%!c-4ix0o2dp+6sCThr65c
zZ#X<KCA<pLe@;ffCoZ6f>yjHniy})a{})+WiKLw8R-`m#5|>oOMaq?Yd}Og@S7fmz
zl5(C~k<!%j;v$Q<VmUW-X=M53^T_f`B;`D}BBd#}xa<;HpycI|1(~&x1(`_7d2U5Y
zQx6WZn9{pa(;EuiI7mi9K1kxAIR{M~e(~OR^oFRa^DL+IUC-$o3w?B+g2cr0+&pi|
z^WOaa)%I<B-xzfz#!UDN-2gv?G!p6;#W|>QjE?XZIs-pMQzX<cigQqVFb=|B=u!9~
zk|UvhQJe#&dHwA9dL@g%(#cI=|L=9lyT}B)#68G|&a)E<?9qb}6EGGZHqs6@2qIpm
z!Hx~K{|**!7^fG^nql*5a56Xue$$}<7%Bl9@P2IW9-D$UK?IB!fct8Ec-ZHqVe5<F
zYXhvZ!N;ftN7tob6%9WpY|%dG$8N*GpuFI9223Gf3;S?!`-Pv}Krj=G#p62h54N|1
zFJU*<xK1#MAIueM7baWKxUd}_u+0LMg8$91T^}5cSoi^JaH8cFutE>^<M1(OXjjmW
zE%|^C1nejzdIlA3p=S_jsr%z+z__={kU>~134~c|C?yosAxauEdA-(RNup>u+pJJ%
z-Ac1gt5M2sMrE{9sq`SF)*oZkSk=ayG|G~wBf&#;CS~MzIY=`TN2#QQS+A$`33M!?
z>n2@l(>4%Ni*GuoiDjH%vfPwN-o2&8nV7bvrDaRyvX(6qM~s-brDa(qj;AF$TegI%
zH7d%Js$)6dG=lK8DfQ&IrHv&%sj6{lW8+e(#-Q&gX<WLr5h46r(xEqKr1(ywO6o0b
zTp9{;cBEkSMwT<X(Oz6H{@QRB{O!*GnCm^HK9%tKN?dZ8b0Lw*y){vxl5z^L^q!QI
zp^M36EGC87M9b++U5tX$a%`OwkzknIm1t9_ViRfo3Z<Nr8X5i%wA*AoVamF~bHix0
zO6lp+d*U)%ScK00t7VJ4u(oB()|QsdEww96rj<1<;g;1D%D0fNdJQKf3KQ6+bb>j9
zRondCXB(HgRN8`>xY2eC#TC}!#)F}7^|HpsC3S@yWl6yIW)^5wNlVGU={U}0(ys&C
z{3h1Hc0U?^>n$zemj;vA5{b5tPGzy=4#`o;DU<^z_D7?3v>2TL4avI%ODGA$(E1Dj
zIdG_efe&EYZAIWa!R-OG5}YJpTogQN0QiD88@JO7$YTOjaf43|fLZYRF1SkoyKPVa
zK4BEXxJR<MaKLQBxCuy#aaM5E!Mcrp$PEt>+%TAP!F_9_0q`(zxIqfo4W+SX99&vx
zi|Ek<yMzMl6x>dL3B({qA;3n4#m?s;f=NP9NCD)<&BiV@1qb#%ui&`@KN?qxT|bzE
z0eB2NPRxb-Ao2y|&c*M`G9F{V38cYkWZe+On2+7~_`y^P+{BN^MZkC+ykEc!Gynql
zB)jMs1KgJ+`VH_nOa!p!50l^E#O)8?2ZCS{+KekP<@mA%!Ua?aC(__KLwG-20KXLY
zClTrsnh&?kK6n*9G+%fjOmuL217J-O8iZ|63J(MqB|y)hLimEANEkO3e3tl3zQM@I
zz1+1rgUSFa@pdDjN{Pvp`Wb?zC|inEMS!nlmgW#6m)fXu4k@Laa+WzZ&0)<_n8Dh=
zg<$jvWipZ=<cyQisT0x}>%1(Z(xgQMQW~X*^_5wwky@>F%to}zDos?`)GU=Hb%1Ar
zEGm|8=G&Ax*DJvOzSb6RU`SoOn&7}wGXl4}3>BzpTvp{sNXSlhB0`zUxQ(D|w3iti
z4sc`;mr$Uup{N>tK|&nO#W@^?GCL^kjc&%6NFZl&c0z)qYFT5=q?R2mrT$s7{G||>
z)cvYcVd11QCXG}w$$CA*#Ke=y`hye|M<+2H<>X?>)C3OY(~8mYsU(@GQj#A`XkJ~P
z6PJ<Vq`1yt&}0e*J0WLEMqEz)>gEX*b?v3eHk&J$qB40+s+6G1W=k$@udCoQlBG!`
z8E4V5+3II3aU_`}O;%^KAI8R|RutJ(EF)K{a#cz>IDN4dRiwtn!uaRqd2;y-g_)63
zwHol!A*Tiqyr(G67Aw`7NzJoYI`iUu1Z^y}Di%t0(j<$;#l%`jaA#maq}f2}$ascQ
z>s_=?XQyQfo5>ufOyXE6|LIJXR5`_K)|kNEg`N$nP1S_F8L2rnqtr@O7LKJ-5f!UY
zJ;!As2TG0eI1)%Dv20YH+Cg}=&6%y)q^jGzYW_-ZRn_clTBnp#)`=!1_%~s^8ubE7
zQ=6Y<G?xcQxZNXy<z{16eyxUDpw@U9j#DU26Rnh-jiIw=S5<je&R=!K;?>PBzudff
zF-e!35kZh#rd+QwOi>UdYl%VV0Oep97T}KpAJ+;UWl?e@x3!eya!4|yS=-)OkkHzc
zh@|NG1m|j(Yqc}sd59!7wI&pFwy#~-zO1%tM6Gwi1TVfWYwzM_>ZIxbCu4lFxCE_K
zSuOK1GA^K&>SjXgq}l}jg9IzHim~~TE6HfGBa6plL3Wcd$%XtjxM58IQ*^W!IIAVs
zppr?HQM6env4hRzO37I8UV0X-Mw`$b=rnq>FHNRNCkvzi;ni+%T>+8{MBHh}3`7Me
zkw7m5sv*!Ed^h}Iff|EXA0Q?q&Z&hMxV-@~fJ=mFhagg65+=%4AgKfcIf*QZWhPRf
zJ7!D{!J~G#a!m9ciAF8H1t}~z5P~2OkAN=`yB`ul*!ZB=2Q(CafY@OP43n@vA1`hh
z{uGDlAy6zESRgbT1FSy_1TgqGvB-r#K;DD|NCcuR5LI{<&^E{j?alQ7wP)RaXbb+p
zqd<NWXgsFT!YANz3*<cPB1otK9)+2MQQ!#pDOO|y5fnEYTqFr{7Cc`IQFu7K7w!h2
zkZ^$qz>5Y=;FAd6SZE&ZRA7Rle2ST!*cAx(J$xWzu$QKSiTCmHtXO25do@9lQft$E
zeq<%HwML$kg#J~-xT@UcmRMJLtR4K07`FLUmLz{*3qukpeiEf%jVTG>yc+@GG{$HO
zva(bf%1R~Yv?6nYB8zlcxis*#rBbjAVrB39>f@C<JxN{`<IT*>N2F$iJG5r*(FGjx
zPOKlb=Gr76wIuhLL!RY!q^hVKDi)+Vg=tH{#2MU-v50co(~CG6K@c26g3lhn74zI3
ztdxMT)IkNS)mpinrkfXOfiBvzH&)&3E3&6rtv-}lTUKUv&`QU+*D14>MoBdID|C{o
z44VH|eb+Ij=CQcc>NT6|D~pqhWE82RSe2HZc&*8O!?+?eAz2gqe`fy;hU|*Qn~T}R
zpeDA<>W=~Zrdb7Bq$J+#O3WjamWMRnx#~n{oismHX>_=p=Dg*EN$zT)*_#afHyT$i
z_!Xq3QiXvu(r%8-^VQpONs}sOJ}|EJlm=-|Dr8h#QUxhj+C=jCI;y-)H!_K@BIYjR
zLoqQKhVrF5iJ4=rvltZJi$5Z~(vd3yGqc>@7GyBTIn?&}M<!XkISn->ip=H|B6kzZ
zw<xu2_w(q4G7ju#6YtW}>N$;#<@90-0NEJF8JTpFRO!GY&%RWtRD;r%Dr3yanHk9m
zd0Jg;2FsE+1(tQ+Fc!IuI$is`N)215bQ|UItU@lIZ)%uQM%zuaR_(RL+mcGXIrH1x
zWx;uxT^bdqFlJ9m8dZ(18TqNTl5C#U{E4sdI)+(z^$VkSOEu}VK_~TlJS8z|qBPT$
zB#kkqb&QN9_l~>X%zT?*DB}?S_a*msGE7c~CMLmVm(Grp$z%$`;^mb2fh||rR%)Gh
zrv*|ctT9lCQ`$|eY$jn;s9mH?KU00RI*D1@B+VkYI9;`xVs%pEIf+W8R%olq%In<O
zu3t54RIUeTSVh#yRg_$>bh`>i$fPMZ=A#Dn{JiNksmBOscMgBaq-QI0tHFCy95{4N
zjiQ%kuq;1T(gHpVc7y+d+rYN!?<8lyDmM>cX+Rd3LwZp$ss*c=ZD4(GCG0WWfv!e3
zqC3&OV1w^jpslZ?chLvvGdM9LA*6(^FQp}6vks<i2A{)=Oj!C21U(qZ-J*B1phqNQ
zVYv+O98(Vyra6#Hz;uwK3@o@u(?c4bq*;5!(l8AH``uxx8^kmf$VfnNW(o$qg%Wz9
zuuCWmGz@5s$?OqiRbRl4CGu=GObzk$HXCRleyAJMLJx$1I0@3aA;*ZXkRQyFlR$uR
z`2TVD9)NKa*Z=s=mfP#SOFCWA-Kk5KbSKGbmW$-xjg5^drq~ACfPp|DfaxU=N=P7-
zK!5~7O&~z%B_t$2N+3Xh6bLC_2npm%I+AYlf3thrZg)?oV#xPz(B0hZ?(EE)H=p-r
z=Djy?OF9q#!=%^5XF@8(Pa`3-n+c{(Y#OV-e6ARj2^S0y#=v>limSz3Ul1{n#Kngg
zlaF8T@Ad`Ze+uVg;D<x*sbbO>%!<i$P?!r-P$9hI$5K9!O*p}%A)*(K{1mD}e2R78
z(=gK%T*O)}2#YiW8F?h<h~fFNX&-+DV}0>nO3vXY0PwgC!8MqLFz^Mpcf+CZLc%BJ
z$T*$cF<!l62mSjU6SpAdOVu$GOU`M5<E|+BFxne#Ke*20iLeZ^n=A()nlc61s)(&N
zYl&W3+Yg7DS!s)v{7s5`l40KtrxN+X6V71750>@ra4-iaetnnCQsyO1DJL8(MhBj^
z$Lr7?&es^*T1RiPXS|;~hoaDEFpy}Tc-?FYjMkZZOphTeQx%T6g0I+*_WRrv$*^l$
zTeJ0TE@yqK$)DJCn8kz4j5}x_rlROHa@1@dCD*J$uP!#(xU&F^&a{~p7oM{*uQ_{?
zy$*6`b0QGr9)=g4-e34B%WzMo@`+R!t(p)2&{mv&8yYyA;$jrVozstRC$GSduEk|=
zcXMY!flxRMwXd&PBfRe_?qOW(esnrDhi?ls%EeP4g@zgQbW=3seFQn9*R)0&EDP_m
zjVB^-NcV?mUNg69V1VrFBhjl}q>XzVEwGVYg+~@z>LcxT^5@OmQwU^JI9a&&5jfhb
zIf`xslY~~ZHOl>!&nWzj`w(AmCLgrl$3MmG;~s}Hpfu8s3mzDFl6$H-8Mgb-A@|wa
zBXF)L_t$81B;?iT&OfwTYf{c;3UtX(JP>Bw{fPEEJ**wkRed3rZG=(usypVYK|V|2
zN|8=^@@Npo6V7aN)*moEuqfC{M{HgBxwOscBIBgPS$IVvcr*7#k&ZneURNgAW9eR0
zo3hxf*Reh@#12<egQE?x+PVbAvVPjfy4?M=Yq819ouTZ_Ulqx27TKl0aA~qfV5EDC
zte4`>g%0IDm&oHT0Cq%6i+tuRtQES7f?h+{U~Yk4<m!r@ilBqhcLi=)YilU702-xi
zMOJy6MPG<E@jY-JP#$-YXDr%c1Nx%_G2!`c<T8A}J_&t{iC=i45jx)9iW-0oF!j0L
zK}T}$17G0oKwlC1rtmZ9Cm-%G^aAcXk~@U7p#^-GqF)GXaa6I((IEm)sPyX)oI?5t
z@dEKW@dx7Ha7u3)wS#<EQ3mx*fOmrOiFLW)5Pu?X9)mcak7YqF3nC#4z>8r<z+KR)
zG5kUfUa!M2oWVLEhz4Qx1hiFr#%Bnw^#PE=e|W(XBmkU^84US_EFQ#hfv^mLuVAGS
z!<dj3iiO<b0id`P{7U$bfzncVCBp|=DE!wA=SaYe9^{INg{2JqI*fRrXu~uBpYAy)
z50%4j;??&gEL;K{LjllWC;>zo|605_D!nD0gyTU&flhuk0fbcs3ne^>fY<0P78FkF
z>1|<cE9>fdtD1blAmh6<(!tPVjl<z}whlVXVUxe{uxj6naX1ohGaa+#kN1-H<%u4<
zWu(rW9Wk32+T}{afr0c++7a$KhVhvknK(1-><srN5&0*(!)yNG)7PMHq*9Hn#Twdq
zq$RofM01v2lS;Kk8&<pAk)+qlvOZrtQRkRjJNUCusMb+4?Ag}7!QyOr!d}(My_i~4
zAC1oUcow+R$Yk+1dTcQiOg4l}ZOKGt?aqX`a8>K^XrVhn^+l`9HT89*Z7z-0t#Nq$
zi1N0Evw^DCt>_yLTkV4_=eAbWB)O*nXJRN4h%Bo1nQ0ed>^n@RQfy)ReY6Rp@C?K=
z8Na#ORUJvV2et;9YcmdH^`|U>pZn{UkQW~giyUOYR2wy!DUZ2@rOhU{(`&7bI;+t<
zOEpYC<79$$nkc8u=c3(qcLbqUnl=Zk@AT3fmrOL*?mFhe)7E_R<*i3~JkivW=5%H#
zUcIHIrMj;zk<Se`XBYG=ZREOK05$W^jStrhr{<5XfYUysM-5zbiS;2{;kRvp_!+Ao
z+ude0(Z8De4Qit|)>YTPHs3wmu>PJskwF*g-GY2eJT5=Agfy9)o{_>Y=KMHS+Y)WD
z_~QAIdT`6=gsBN*ANkK{u6Fq*AANMgNnf<DbDKEFi5G9ZgPO~<ntp$;nIK#$J?|tq
z!wjFv@)bBQ=nmq$#P^A(iFZNM`%n3?i-#m0M-W;YmgV{Rm=oc#nuFOS){d~m=YR1-
z7f!JS&4pLQ@Ib<&0!9lIf{zxKHW=_24MHq(P~2dSnFTdx03zBjp!f74AB+T0nSvoA
zm1)ECSHIGn37gQsD-cYmAz*SQ0HwlvIw)KlQwYBgkfa@-{(|STaM*AM)B=umfzik}
z0*>z$miv@;S~}`UVaulO?AIx}ia9MxX04}eLYrK4U4tWfAnW>GzX?@)={Oy7+H5e*
z`W$WchbZ*JUOV>(lf?@vNO0a<x+?91(<oCGs-rt>3WSl3K99ELw=Djp4cV5N{h;YN
zE&-=@GQt%y8K&xN(8_#%Gq)K&mcb8n)>&J&@PAxahT%XtLvT1xef^8baW;ND6tI1Z
zF&$JBu$Wd4?=!pNUFmd$Ze=$+y(xMq4I<O+_Vu(d4zCB@ux(^y8~!UDHuR10FGR?>
zmgo|8Fja5ywW7WIEGFtJ_8bK;WF@^eyFH((rPxrKA}O0SR=0jxFaT%DGJ!f&TeD|r
zisXKGmQeF1Xa!ez530!BQfwbO5IN3T3YC3KXvtYy@YTn0V=`Nc?WFgdz((SZh}#sP
zx~gGxyJ1$`Vn<fg`VGc`0+ica9ZbX~J``H84c6i<D!z^r^N3}{mFQ5?NmiBPWnfw?
z1@H<k#`G-Dn3zfN0z@7bCEy@z_z!ila22nx1OeDXrW`E%g6f~-85x#}a&QknVc;hs
z{EbimE({KlkVIH_J8)zNFHf-006Bom4rM?dz+v?!VN_&;rcjnYHX1+8X8E-cSTTY^
zd5OnY5>}zb)pfqa0K5!mK;d|3;!&4@;RWsJ&fwP<6TH|2xd&Nrlr`)C2;(%LgVB)f
znB&jF(hQ!_gkS|f1&MZ8S1PVM;al+)6K*Pu77&r$@QvqXc;3LT>_dsg|B9>Oc)bSy
z2i3^}eLItQcGLw_l`EeC9N}dr#sgTh1{T9hZ^9p@5GH~^8hCxN62%l$KuAF|`TD@N
z2JD1DaUhOyli}QL;fnABZie4o-C3+BfQEr{gL>n<cDu#3gsd|8H^pKLtKH$Mbg+N8
zn?{kAlLLuhz=RqDBg+?>xgXj5emCQ3S$ecN?1Tm4T80dpBQ+K~9OpGB?MNpq(JF__
zWUF;__t|{k3Lppg)dgZt!UE6Q#-?^h74?ITMLR6PP|WP{xfl-#lO~3CGZY=pktyU|
zgqRS9NLR#q8Gwex=46o5>Gd^`WYkQXX}X$*6MgN6I34~F9iVMJh@o3;aHc)&pvk4_
zK6f>p@>%K~Zqi3(DcX~8R>$VUreO~~-0qxDvc2vE>xfb80-LoFo?%Q?j0M)IElh%K
zqMK=&q^T-~27SVZLRpd_-7K7@>k7N$CfG@~TwWbuefAv`<Dflpm)UKH<E~wl)n+zV
zo2^v{3T!gb))1Md=_Z=-lV+EfGSTb~iVZlKD%$3^kd_*|3&pxOk^_EEjXzFXku_My
zy6qM?xti{xVXYa_9@_0=BjJDpD#Ez^G|M_`tl)%U4M!|AjVx?)nz7hJR!@+1MY<4T
z84F?@kvfx&`E%z;{oPIGty_;<YA%I2(*c9%P>+jobLZKs-Gd9;7c5)?=iYlV`^FCo
zlW@c`_pia_YyAvzqXZp~T4@HwU+*=$4)B>xUH~MM)d4CroH|_Put%!B(QAAwZEfa}
zHMz!cWR9z?^PI!U+E`)-8Lp|RtFuj9;BT4FSglT9{Zd3%r<**!m?iA<`C{IYfaf5W
z)r)9X%(i_~grovK1Zr8FMh-+edz^8P*~NO;Kr`(1SXpPlj4X5@wZv8BnQwR01Syxx
zZ-Q-~l+~Xcq-<;&(FqUfM#yS~$ui5#L2&dn>2p%Hz`Ot*qyuEs6KCwmmo|Gm$(opZ
zo9RYwK^47-w%bFEfhv=QqU;_}2Q6)sg9$d!4x7uCBt4XeZjU(wu-r+Kc9S(|f<u~F
z#^f}!Zm)|@43AVLvu3xi-sWY!-lQvNf-lw<rBZcH3iK9}*9@nd+u}pfnz(h1uP%g;
zyT%sun5}igtkpt>y{2k=IN1E^l9azOWVXcPnYEy<5UdK<hXB<NAg&>9DTnDilmlpB
zg#?2ikGKF^{K7c^1YYI`3@WN7o%vvZ*V6f|Pf$Rzp*AuQg0ECJo9)iINc@%U#;3RO
z-`QF+2S2l&Y<Gwa43YQ?Zf8UA4NI?Zjst9khVpv2a@@hG+>*I{?b~+r#4qw3&^ug3
zuIlU@Xo|K6N$Z*6>Mu~sj@a}bvN6HtnwkOcpx5e+3}w>8wS!gUOPQ-pZLXi+?Eezg
zPhA?g`E^&D>6*IhzZ$#yx4*qR_SNg_u7S(1-yFCUE`P~?^UvY()tT$Birw?>yZ6Md
zDm;^SRRyDwc(PVpfc@kW(}{ccesalP=A5crbIY909yDZW8(h>fFt9rB^aNTU*gWdE
zz(jT@!iUnCXcfxY@3Dht0@>)BxVLBXZSIHnP3&sj`rw0GTX#+Dd)R&3=AHu=H*MH=
z`nsl(E!~@McRjYRu)A&R0}pI%+g;fAnCte<-CIVQ)}6j@L(^jV8IvuN1XG9<^s)L3
z?v<dC-T>!&`~cQbLMU0Tr&&-c`Ncgfhj>8&pCEAfZDW{X@tYokF-oq>#cy|{JNVsg
zn6d$9;K?Vxoo59s4nS6ckl=+{5`JNM2U{1s<SVKO!dvjh4Je_QkFxM)=yWVw_&UH;
z65qoMKD=ayw=hDm>KE{Ifk}xZatEL`z@nfe<0+nCH3QFp$w?>xH^Qld{L5jxJ2Z&+
zy&D!Qu!1}c;4<?**eZd2n$BRi9<y;znF8DnXU);H?Wg|DuterZB<1MyxLtY6!ydYh
zCY?_95FhJpPW&kxikiu%hCQBqpPkNI+4_byv(06J-Mt#x>8XL8#USalbyHL*ctx$V
z*_?1jKq2d(<5y&c7cCqbYHuH2=m?|lwEC)<!|sUxzBA+Y#n)$&C;Gw`+Oh1LW}C-J
z+O0OK)%LhI-o_ofwa(EM1&DK+Y&HubZ;b`EpFp`rNmup41&ARjOH0;ba+3j<D~00K
z)oid8xhYHblka)GA#>BfqLI1hc1NPE=FdmcTjwM+@g7VkI80V&^~L5mYIQ;j=sEND
zc}IKN+v2Wl($x|<?Cb7ESfR8~joa;UCeE5|q0xyWJ+Rb7E=41hxq7a<!^+x$_|~d=
zn(PDt>Pl@%1e&ZSCwEq8bYyhlqV=@^nDkjsuwIk><RM!aHe7wp57LpilQp}17O&Yg
zu)rFtqW!Kq${qS>xt;r`Wjz|HqiAzivv(bdP9$^j19zFsj!>*-eO1m0lXjoomIy3e
z1@&<`?8zZV6*)1-T3xfd8df0PRWwDPSZ%M`FmbHY?K%!6Juq|#y8<6QM1Y9E={X4^
zO*9ZK#2g|Ar@5C#@6LMitS2?;e_0PU(^8<=$jBE*7HR%dh}CV5f8Xl~u$%sU`(%F<
zyT-HilS{DPPQ#3}p8c3Ug0Ml#M}!ChqTwWxIZqdC4+JPr!jn#T5(xg-k30T-c1H($
zMhASe%O@^@!^Ah^&&?ej)SDe06ZO=a6ZIXC3wf9}R7u&Il2cH+qST4a9TS^Xh2a9V
zb*$Ca5tpR06_e}Amuj;2*4OvqKTY}Q&%%XXf+?wQEzvajo65bF{*Cxna+8?Syq}s=
ze1Bo3SP`I|NvAH|Q>#s7HABr}&E%AE9l0+T>nJ6luB>id7ffDT<syQzw#xic{$P8=
z`W9{%Q!;hsJmWSL8KGCAx0r!>)@;z0Rnu?HOj;)QiJY2B8>McN5{kxJ4BNV8^46-N
zYWP8f;t4W{TV-pNY32RKeJb{-+(x~=74I_cW2w2QrgU^kInq72-%D|D8W=-%8P;ot
z7*lRM$jCNPKl%Hm-v89_Mee_`3B&qnF;MCy=$mQdi<1A0(xtp8W41iv<WwbXkoZbU
zC>paL@I}cT%2t-PtWxAGte?D}L_X4BsG_N`CaBgeusrPsJFrzm1^8mrDrF0e?y02Z
za-Yg68Fi*Y1F4&(gh(9)F|1{1v3>udt&(EKlo9(}rhz<i<vi)G3V1{!heQU6TcjNA
zJuu#9T@OQMvEFi<jAe&ZODq@mGfv9rEh9^rI!baxBA~LepAk;V_5I}KY0;V7Rw|=s
zq=zZ_y^?h4m?$p+rq)J@zompuWA_VA8eyZ7BBd>_R6@v_hTQkY<4HtAiB-i69a6wr
zl(EdH04FPHbtU&yLK#_Z$SD~qr$-}+O{7E_V&NIPa_+8_uiJ?eK0T>Y8BdAWAk#?Z
z9yw3EYijh9$fX5FDMz|TkMH&~&dU-=<`p?*Ja(iyONmcgAJ&sla?RzGrVUzICAC3H
z{FmUo%!e|%%Po^rnl@_ZEfQ}@ZIlu-(}$H~Y^v!}G^<p?$t{;t#x#%`DkaJh1NeA9
zVSOd|uB2cob*3%_W$MT&V>*e5ZY&Qa0!j&fb#_KrUkOzzxo4`BlPMynWVDx2UcM@)
zCa0l9ASoeIcM{&SPa-?d{A{FWWz-dAq)bN{!Q?#guIbWPBB>-nC61MHq<hMdd)o67
zBYsromyTZQP_f-ICG@B>Id4g=6<G?;2WPN;qwHH{3ykthTP90ld39onZPdzSv2A*d
zozc8R*(zmvIxUywmE4muS5J`!Wn^|4V$4uhDJfu-o*89i)Ra>*r;#+irGzxljfpkm
zd5IAvj3{T6uPmo@G?ka~GUd=d5l`einG0p!n*yFlB$Ni7Hb<l`#++G@RZ2=2QERIC
z$}%gVuFRKmN~Y=T(OF_uDWN5=Hb+5l$E3Q!7iV8P*gw=4c~|CBJ>KOc9-nzHNJN)(
z1c}R~94R4PD%&43khw}8HKMTco>D&6(<Wr@l~Xc(C&vMaLQ+D(d$T5Um93gi%gbvU
za?9mZ85$Vt9TE+sgiMV6By(p<nM$=0nKE*!42>$#OC%ae35i%UmbpeeqRgK?%E=Uw
zQ?e|OsU%;OQ}R{gu_h5nN=OJJl1#cHCB!TLKa#mJ+RN0{!+4pxa;g$KizF)p<PzZ}
zI!g)hX(0Hl$lOZ!Q_0U$O)JYUl@xmVq)baWwSW6TBCV8=$gk}p=^iN|cZjnB9q8)M
zUJFw8U}e2C8yb<^n{uj>(IU}Vs{lzkQetZTH6y)2X`7{_s8L#Zf9W`oHKxiaE#6fD
zmTO5P<w%sp*gcDSgR-SY)KKOt?=Pi{o<=3MUgjPdvE@ARE)9*edX+>7i8K-)NjcIz
zK&$<xHz+Bgq>xcsd4DP8%4=LAb!2)?iH2qLE{RYQ>B<sw7Ut<j)KTUuDW%LeN-OU-
zrmT!)a!Qs}vqfWxqEbSVPf|`r#Qr~_FO;Lap1vUStxS1YTa#z$Gv#zq%uC!Xb%K;5
zb%K=8UXpqYaAcPB1*Hr(;^*1QpK9;O<3dh-I{hROT1w2g!(0{Vci`t&>J3urX`!Uz
zZ1qef<tX1<ifZ!MstmW}k+nZYo78D#hSKydNhS04>)Zx<nW<a$<AGRMDnB0V!-M~$
zmw~H}<g)WE-j4@7cDM^9-<~u6eKz$bb>hGONAlxQl}%_$hGNyFg5Qo<-o$3=Ti_>D
zk3Y5b1Uq}Z(v%#aDVba$cB|ey(5s>w4cL*Y>dpJ}O!l_2Z>Fvk-(2{dn9{2Q`5)1u
zai3Tjz(}w$($oihdZtpN3TwwbD%DO-75i7&A5uNJyNdOc5>Q{*x7DdH`1MRyW98UX
z)>xUZ=~bDwV%=pLi#e6inrzonAJ&j{+X8+)({0TRTBg@OQ)?rli*1w=1&P&QE@;qJ
zu)Cj1YnA<F)LP{|74)gtN^ReYSIYLW#GX<@>TD@TN&pLEzn&6WOiBSwE6U>ybEi1O
zr-e6V=_kLr9Cf4`Ob}vK_B+<dHA9QUy2*X2*N0Lq3(eZ$Ien~A@}*I_OpnU7*Bg_S
zwL@Y!DZ$%`l<=MC`!Xs2DO;iB4x{{vTBq$JF{iRNO6VeuHz^0(H5#<F0=zM5l`>zM
zR#Ie2E!XScY0^N#Tqz+F126~HpA6{%Htdrjuu*H3EwALBDN#qHggl1D9Pzs{K9Poi
zl#m!k%8?R4t7&1Tvh|u)%6f#{7QMQg-q3-e{f?V@wNqe_j*h0Srv#utzyBLLn$!kK
zLZMAX>PtB@!c3#Fq2v^0x(wHd{4R5kqJPS2(`8yIb(xa)XM~$mZL#wHDYc%wSW6Kx
zr|h_rdRE)l5+=+hZYo=-?CVO>%4erZovF%~GTb6lu8fw?uiclCGvNO-nWRy++K5U<
z_bBs~>1k3=<S2R6i8<o;6nRZM;v}Y%#-Nn=Z=9P;{2|p+O3VcJjrv)cU#1WBxLkpc
z<>Z%CeJLUJ(TuQPS#zUwg&ZokPHvNyBg=B4wsBhcgZ`Tl_8YablKhJLR<HGPo=m0b
zQbOu@iCRFC+0>gWp@j0DS>caqOG=3f5?!=BBcYcpGGXs_X85n9z)aG!Og#mEN%~er
zQlJt#N>er|ArlmM5cY7((iHrHCX=dDrKFO2%4e1N%Jj5Hu*{z#HMQ6#UYWg-Eitat
zJ5mDZ{eNu!BJqmUDk*11GECXOMm(U*FT(?34{G~Xf#BujwA3PP8zp?2nfx+pt+Iv6
zwDSHbwOr<SEj7w=xRwU8POdX^ow4jvwouvfsitR49R-g_*gIoNNo*sJ{29xx*`k=T
zoEcN^)8RMmxSSQarKH4E`OfHmWtp=`-DztGQySNjh9D)R$FaTgBzgk)2u-FbD5+ya
zL8E-5XO;QN^ej@}Si*=`_5)%_OfO-Gl)!U`|J(b!(p+C+Fp1@)gmh{D%U&hlDEY4f
z9x6976|$uw{X=THl#pm3Nfg}oGu&@6YOS*6Mrq}<)1=PKWrjo^DN$Zo`LB_^N~+Ex
z^%Q(IMIA;Wpp?*3Qer(7{>;L>QOQe6%FHCKEOQnq{3-LSg#FU^|Lo;&CB3rWsb3Cl
zE0e(zqe}@b$ICfow<E9(@T58s_zdk&tw`A`O6nWsEAQDa<3rSlwDV8#%Ix)%7MY}h
zBVm=40J%A%HE1Q}l<8Tbv`C$4(oJfnlqgS%+0-GXN)08&D&WD%DWi~o<@79xG*Y4r
zjU?UzzL{11p%Q8-DWps*pPdoqrY+AT(n$#|4JFcP7xia--mavG5v7#*m855#vI_pJ
zOh1!|D<vwSvP5_3Dd62%pSSN1iYv>Ub?Sdsye@T_ti(Zo><67eNj)Wh8|5qSsU)o|
zXFvANv~@d)-KB&?dMQU58(K_~6hSGW>@e^fszApBzoDsUc}j{Zd%!4Pd5<z}biXoR
znck1RH@TE9tM^GAB_%59L#bEGJSANs;H07s?i5p_$qy1eL{t&AM2g5ljQ%#F6XNvu
z5knBGe-uu9TScrRHbTt)Lx{tP?Zh#}u@GDMWa2d9OyV5P=|<pk1jiP^(Lq`8G{UC`
z!GUhwE|l%Y-)Z>6-?Q;2mW9h!oRTCSWq;}TQS`Op@vqWH?ApD1H~gVR@WI`SQ>(?F
zh3BQ8Qr^USyLatEYbv`?cuI9McdPjG6i6tJX5!CzyTe3}`I*<onwi1Ng@4=#d|wNH
ze1iW#&#Hd%dE`ghJi`km1xTes5ts8izp~Gph^54##OH{Mi7ydX8uulfyWN>hv7G_<
z?uNfWD%8o3yKKtMgc99#o|JF^3>?db4`ze^kRLh*j)Z|z)ZidEIF1<3@$T#ZP)KIs
z#8v)mRCpxUH3X*#qhit7V$t{&aGWuV;59m3JKno0>|W{)uZrZuM~Cwf>hhyjUcQ7x
zeN15!gZil@m#;kP;H?MmsjfN}z7XS|+vl%?L&lsIkJ|$0B_>kiE7ZU79rVk^;);cj
z6V-6M=STh3bZI}DmPT4zBa!Puq3a4GE04W}yTOu3SkU3O9J}(c?FVf=<%}~<IcV$l
z!cF$j{P{sgIyyH>QTXE>DVgRkjnBnJL~voubsIK}nKnTGm{nu44MyK#FxI|I+*zh~
z@aa2Bssh<DS<`F^pOZI;a$Tup2#!wYPu9bS<8^jVseACbdQOB7SI>3^pa=0eyzpO&
zO?9V>-HcDmQ}na$sjj!B!ku<gjjO846?E7;!>Pofhb9U~p|j2Q4zDATrK$$z*-gzU
zYB{3cs<6{;(>@zU+;&{D{I-A-zpb<znZJh9P3@Z*rhZ#fI_yvH-krW=vELs{JABqe
zk7cym<2I+Ng017>Njq|#&SQ%Y<csu&>zdlPz)KEqs)O!@Ik$5BwGk@-Q%@tVAnqle
zn??`gp3il{@PhMy*&KYrz)Im`nD7ybMt!W$Ek;8#lS&5s!R`Qj!YJ<K-w0<n@`pXm
zy!Vf3tRAgK&Dm(OGnPcvsmMTehJH-j`GvRS?o=?(i8|x>uF~@06@}kSlOxWE#TU1y
zT|pG7P1Gl2`GmtZj!O6ey&tY?6d0+oF6_(f*^@!PFCFWyl2X#K_y#=&QJyCl0!cgy
z=dJD{&IS(oHk=Lr>~y$<_o>&zhg5(^^js?2-5CHtp8{gDsT_bb{tG}USpyVc4DwM9
zusxsy?cA7dH*eO<<(^3R76cYLHiQy-9HWczcfrm4Q%~vfLt(RCE_Zg0vF0j355ERa
zPK|}bvCx@kjC)I1Mk@<UXPyzpcVDJq3IUpwIKo6$uO6#k4O*KTOGbHFaT)PV;z{BS
z;xALj6GKkHVq1V20GJGB7wCUMpzAZuG%yCx1x}O29M##4VGYF9RQYPA9QF9fJUYsx
z8!{2M#m4TA3^M-UApQ7^;OGubfg|&t)8jLJ?wc0hox5;hb8}PJ!W^Bi>UWR*s)YM0
z0xX}RgoO*WSfyo4n9G;);~~WH#07AgFqUrb5dR|ngV?EaB|l@+!7o7rRcMo<-UHk!
zXr3t$Ugfw{tu_^vQIXe0CWI4)1s*Teag5&YF}fd1XOPv17pa{c6?3Z|`W5ss@!^4Z
zX0(@#GO-2}sOq7g*7B|{Fy5wk2#WZzK7;C2MDI@Src^M%Ce!qN@R15uz{7>_YGf!`
zuffyvN4mO>9?C8cjlEOC(i%V=`wM^L&`8%s8bl>~G%qXMpt*~&W}`i0NAxshvEJs;
z;q8-&^NH(;`#>(gMSP4bv&Y$K1C8E@<KT2_UXp`O4!}G$NuJ8(1u+iO0+{6)@vcFQ
zjCg%Uyv^OM$7lw*-|q>nu4dXs!e`RYRLJbNo+&=_Lp|=*A6j~MPLHwwq~UASpvn4V
z!RByy!-A^(*jFZH^$UZ=n?KSpab>Iy{O#4{Z;ajd6F(q+N&F4jPzp7nPSl4W0tlmu
zEz>2f`WSJj5r$8h(*d1f`pLt4xjBwLva@hbz5KkW@M>{=_V6B0nnHm4_!||!+2Z%7
zH%6XVxTLOTaDGjyaz$CVf8i4SnG;&4HykP-INS}HbS6zVHZ(TS5AdJ(_kJ8sr}g!v
zot{`O7xOsB>B&aac(rtMx)0r_8CBdDHCdGnH0IDmqIRIJE<JW~I$hUOTbsbL#iKL!
zjwdc6ZX_NeUL^iN{0jj?q9HVjAX?3AjXa}~3h}-KU0>3FjK+ztC@a)UKSt#mtS=bI
z6@0f^hclK;`lHoIGKtz39*tNVo6#uL=Xmbn(H=6w)YhXwv=_7~>O;NJ@|sp!RldrB
zdi6vkwFj$z^1BVxIKA5F<#9KdlIdiSejynQK&pb_$sHF?H@4w5wZj^VYiekRMz-C-
zt7h{SbxjcbYKbqLY82MU8dKaoC4;k)$qM(V=C$MFi;BA9&6=@_j?}*P7|mVG5>Wj<
zc^#BMJVyOGWAtR$0lAv^20u#id|Mo+8_^*M;(W~3NHvm?#`(hR*=XG2)qGy%o2sH%
zT<s}0!pqItjaCbd@(o9DQGSZ@bVeiCK&#Z(K;Ir192}r@N7eY_>#D1Js+f>=RO?Q-
zUhJuY2PSsu4&&j$fq}v6bcf{KmFMc-`E)#yh|`BB;_<}v#`7K8;jGE|_RgI<$6wG4
zGHPY`+Q|Lmi%UkhcJ6lJ{o(MnbW}5_Cu*T!?NY>#G-LMy&AU0B0p7l5&6=@g@B!mH
zrW)T_Vt^QiJx{#b`8n7byPx<O@h0&$Q9w1Q7cE4~5FX>_qf60M=n?b`dI`Obeu>^K
zGv-rR^UQXGz!|{fPaK<S*-62kDWHaGGpD#J!NQ_J4HDLCVP%ZPJF6}%%h)#5o$$eY
z+s_8rR5k}v6YrnluTGo^Q##fJMZ&ggM)8qpLwFAdbl)JB`1m1Hz#mHGb6r_n7@x)O
z<slQB&3C8yPlUIEGQz$dE*sz7iJ!yo>+FD=;6Gk+W2L$~#0C`~!4Rwkz*8wj6?5I4
zp#Wb^#3r&s2<X!t@+Cs>crEJ6;-Ya$c~NJkx^R>6YibeRXN1ZqUxD8UCFFfM+~hzy
zmkPk+s0~4#f%vdRr6vO|3wAf)kwGNFNeEsG5A&}^e3C^Oyo%(**?K!$<ALhYR%_H6
zN;e!qKdc3SA5HXA&rbMs_9`9{9)ibTm{?D8HQt50cQ5qTSkYa#RoPwExmK6GDpTF*
z?yS!IsHbnE-|hCfk<;q8o6RO5B<qf$P>QxS?p$>Ow`^Xg&E%>bsdbrbo%6cqS*`QB
zQDNQr^cicot!J!pt~;O12)U{ox%b2pPS7i#%NE}+)d#(5<<?t^RlS<q6<&Pw(TnfS
zW@{MuSHmRX-$Oe_wqzKqy&=OOluD8DxXFS1l*s`#x0!2wwNB^Ce8=r(o6TIvWZ(-G
z%HGKr7vvV;vf&l@J=rY!CI99ynv+WhBC$sJb8439P2+o3w_9p+$3`{tXzpX?%@0bq
zX@q;DdseSvo*J9Soc<`YY8CUSy>P9|7jUn&TGzS*K9~Q{^#B@c)*Sw;O~VW62DTot
zd3wNPUP*3iUqHK@(QZf8meWt~?Xm@;@zC&aC>{;ix_aw|mqw#YhYOdk3;Ba9-w&>I
zt_u}Li@9|rcV8zIvTD<L+86vte7|2=tHQVJcD}mw$=8jH{AFa}!jZLyBXsyRKs3}f
zdi*M9w5Hu*wwf)ZpJXFpmQ0v!-Sj+`TE(uU2K%^I=2Fz$gXhkrxM$1Uwi=hzjq*_H
zkNNV~!kf6q;FZ@=zoY5;LVtZdO%O>Ho;DNni4o!;SPedj*ate(gT&ua2U>%6pcBw(
z=xlT`x&mE;ZbG-Ad(r*qA@nGE68!)@hn`12MX#ba%HS%78w@?60AB1B_9&+et{8HQ
z+o*sDsT_ty9$_gAyKI)i2+PA1EU#ho!s?T!JLCZzFN>W%43-!!!TbRdfL9p0f*}mO
zA)J8gCV+9c0cY_T#b0U1HWUm-Tk$Ro!tJ;)jAQU004dywA+7i*z7_5f$^azwmB(t7
z@~~MCv_oi6r_j7k48uMwrn*DOlVv?X2`b@(Pk>{AzN`vcrNs>jqoWOZ@RuiqEqq)k
z)eRD<6Xs{#V1Cd^!CwgSaUQlE!1+45+qlnNRddu)skA9xw_ss9W}+XR3Z%ZEcoG-%
zr-}7c&jQD)!NFCI1y=N}-7%MIrOOqIWwWuuc`7Ir(D7q?ZKBCmL%AF-N63W8VOzvv
z510>V@c2EoW{=NpuAOJ@G1;mtb19p%!RyGlSaZbIm_SaQ%<76t`=Smo7aX{X#oD4T
zTe;2FVl&VgKA+8O?&tOnEuJ^D<SQ5!T{4)4@NaYze{CoMH`;vUCYRsUNcpLxpYpf)
zUH*%YJMM$yj%$Tf8{~Atl^EPnsu7wFWbHe5dh4PqRz$~JOVl<!{2cqJcz24mj|d3L
z9cB&&&FDsZ;YQLO2)egyaR&o#(vMt=7jqw@TS{<GL`lx;4$oWbs;8}1y92qL9t*p|
z)41G2nderorB~G?+t}6`PbWpEEQz@dj)l$|d(dl-*`2YZYt7IpdYQorOXO?@n2e6*
zK3=>Sx%|q86z;U!(T#i?*C20Q9rqDU4sxgXe1C>sSSCU$hReb|=t7^5I|a2PFHLhF
z)lt8Gg?t6Q0{>nnUm+*_g*yKjBz^`N2(A#VDhzE01jW``pC`^D&Lb{`)uHbZufnRV
z2Zhiov<IDozJhKA{Cph!5WNWc=&#Wq(1++Bs6aBLgA9;0WD}Vu7m>@zwd5vp8@Y?z
zOMae&cqYd4R9=|^SV{6I2-w0~eHa*)lu=&sA`iwmTnwO92M;d*Y$Bu}&}Nw;yvSN@
z2y{dIKVD}_0kR2&02E>Pn@nlNkPdGU*L$%Z$BPNR5j=iFg?Kv|Y{7uh6i^v<oCP(P
z|IA8duy}h#EK7t;KyGE3g3S#sV=^U~U-IIm!Vu~NDFBZIDK-nRi2oOrU<8Ui{05N3
zWrloRfc&_co%t*zQ^}&<nim0B)R4vB*&;o~Z!uq_x%gYWE`E#o;x`gBZcxO7ogH}w
zcOySj2r`0h++B;HlZKF>9Yc*l2k+!B1w%j}e#+Bbl%u#IyebXN#FG@3|Dh)Xy4HF@
z(RENJXS>60wOOt6=eD-?(brBz61;>T(UddZxOjAQG4;oZ_4FyDix-b_S47?YOP2Jz
zqu#C-cXPA5rRyM%^{W=f+T6VH^wT%4Ts|7K7hcp66l5muvXYcN9=B7Z)fE?h1^W`-
zeBPVr3ktaxEL}#Aj&eU69knf8c8dNz>T<|)b)*4zbFnIN-P)uIdy7p#mJDtI{Gajl
zkB;_lv&VP0*6nkh*&VA|b^P(GS~@%jVBrw7!@mxlkHWJ$nf#4G{2ZFkm%*3DeSk~0
z$I&YORX*{}@9=tfQ?u3Wcg8#TA4j<o376OE_gin~KfUgFVkxh*FUB`DC;7BS_}sh6
zWuxN=g)AN`6It3iw{PslN@UQ7aA&LPS?2K-%U6yajRjKO$`vb2>|JbqJ$sjVaG<|`
zV32bRt}r_s3IFLEH=e#^!RjW?KqeJps-7<Pdx-V<-Qj#b?DqTE5YG{rc8A~Iimdil
zPrJh+Jfw4*nsEwA1F>_ZP^+9+OD<EaxS4MTeRB)yhkvN$)KrSQx3&4ic}E<*`N)ya
zAG_Or{Hj&QN9TP6UAGK6HiJ92_z$PiNAOXac^KTxy@Ved#06~R%j$(v3sC&2#aB@u
zfRcZReI-4A6(laKt22kgoEtvOb>D$GKpR}}9}WqE$f#sk2eFt~PHZDi2O0KN;%?#v
z;!niKux=VeIkX%d#?J<BK;J}nfgHOJJ&c}4ze9fl2?pbfbdwpfpPWxFA<ON80IFn#
z&2V8?JAiQ}kYcgHvanHrF(?aI1}Zt=Q5mU)fxc+-T(nFs7TK9qt-gqI3X3ZJSwhwi
zN<JvN@DafC0MLSk4?&(zCd+tfRM`SdQPSqY{+GocIXp!GNESZQMmoPJd=&D>SCmJ*
zR1!o`aXyg65&<udNaf;GXNUMsR+dS^R3V#!2D4dVF-DXtOqWasoJu7{5_JorEuR+W
z5=B8HXao3DkTswcKxcQ$vIbYHC~=@?aToJ)2lC(wn-%ilvnYdbt-8y|pv>CfywK`M
zWNl=Acy(}aUXZ?hD&prU>A7M#@4!r?U0mYv&S`Wv&T;dfrz@r;Us&EB_4+I(hucpv
zHjCeCas_>{BTwD1;ZzRk2q9G1{5ATr1G!T!JJ7ZHYouLIbliZS)-RVkPC3c=hO$=P
zVpad0ayK-%J38=ZDu5Szw)4}Eb$eE<*t5Xq3%VS3KP(t9eukp#0iV}yj(LMSc4L9T
z&r1GiBmYiX{)pFkgsI7m#!ulgxwZV91-;0>ETDM(<GeU&wGOnqeN}w=en*q9k*1n_
zO%9)>+L3j@|J9av6=|Pz2gQq-E_l{&9hj#tbCyQdtcgUfiAG09;cw0OXe9#Y!s6W#
z;o)QXiO<!qnO3bby~bi_#{UWzD`ySG>Cdm{A06yBH<PHHMr12OEp(nV^{^`jPTX+n
zsmB|Mp&O2@@<$GRCvvFc$g0Ayfz-GZO4wjj{7$`z%oS2yS-$S{=bQTa1_t{2nyw!i
z;SMZLZhpIB&z=<r^j5KXGc!no+r<)cIa<yvB&kK_j;?QFQG+Kv4<_zUB)$NPNqFY-
zPs969fYK7h=@9ofc+d64cT#@>!LrWoA7(6&*wvXzbux9SR9)eh{1*cmw}61j4l^t5
zf}|<6t;gprEFm@!JBi(}?qod6!62gXZ2`?5w13cbVY0)TSYBHPNC{xuddLyx4lsY1
zq3a5LZGBTy!}@iFKg?~0e{)BpbLK=x3p>`Y!};{{({M={XB*P#hS0?qkvFw$8(Fky
zWLwMPY$TFJ=R#f>u8qB|<91TwchW#CBGwRFVXg^Ltjf#}ODMyX^*B+{RHh)NuYq?7
zycy<=Sf=p{WH9a1nJW~&ucF-sU4N3d1v-zfC{p%jUB8i21o{i*Y4p+6Dtemqd_~6I
zEE1pIB~tredcGkhzDpJt3&i`&YQK;Mu=`&}90`1T8SF1lr3ZLo8GD4N`k<uu)O-yh
z)6nl@I{mU)&(q`Svh07Go+ro0Q|KeV)_Y^@>B)x2{aQ~AtGc_?J{k?+DY+E9G`2x+
zokM(uxQ4iHYCTqpFHEUlhN{!#fm7;(Q94$%y=3fn!SOubI~r}r_;aFiL~%FCeip_4
zl7`W3qCdrB&@1iH(Ow?K3MVT2h&w{hf5N05P2x}xu!{GD0KbW`pJ|5E9YsHhc2$=M
zkBNmahwJ%A;C|Ww9ug;j)yCJrpYHJ)_7YwlGVqB|b=c&i3>4K;&j(h6eA?dB!9uQF
zKi;V8-SAA=A^1%l?}Z;2_w^*0DRz+1T~4)^!u694%!gDS3F<MaW&prbwJ!qh`xW57
zd<^(fUIgRwZt#$Kj`-<RIKZQ)2bA=!&_{STO7=WZ@q#>fMedQT?C@%%TGnYb50Cbq
zE|}TCOh>e8o0KQYjPvVCd<TA1Dl^qS0?(@1KnWSD;eR%)oErNAl;A+&VwI3Z|D*b8
zm+b#<)BwYmMSK576*7<?s!Evny6P&k-q^-p<e5FhsbJ^-72-DHVdD9jaZFmnLpnL7
zw)_SRRBE?B9qySDw{VXrySU`nwW3A+ne=ldY;&VzZU1y-95V@sl(5KyQvcRRBK7Y}
zzp&1`T{5EIpy8Kh(P;iM6-Sikmr^@<kw=aNAKnXKU;Ep{qhPW74)Gqg1|<Ho|G5Pt
z4&GQP?q$Gi#eiL4e?#00!S@RGwMxxeFQ-&9(Z`>u+PJG^loF3hcuLK0H%T_^8YM)s
zRafbTXrwZB<Ib$a7QH-9m1Dw?!t{LXSq&dPr8G4kR`DWtq3UOO)@1I`n3k*U%0*s1
z9#&s3E6TuEh~E+a0IN1;W}K>(RB7NtUOSTHo0h+PYF;gorK;J81~-M$l#*6YewJdQ
z4*&Ag92gH>f*hR^B9`dM*C{NovDG)`MoA}ry_}kb)+(WuTCKL?E)ld!;i^n?XO^|r
zE@5D<uVvdJ__wWP3C2y-r2@{dXrVoR(_(yCRNT0SCsES4$5h3R?-Z@D7pPbntx^}e
zQFWF1vTS*+w!0R2css02oWpbRH^KV)NrLBN#KPWjXl9(OBabz_hk4roL-CdY{9$K$
z103f4=CRMbcFge40849ifBZ(ZZm7-C;ceh)rQgw%c)KhXKgHWYzo6vr@rMQb=jsya
z|6{?<`C=7=r?7qV)yl`YM^vn=`lY&Zi?RK3c@95Y#h5!)>>k4Q%DYr7NqvpCRW@tz
zx|z34K3P@T_@z*QdO~ues<d-dzqk^1KNV~VMLXoUYQHSYM`BvQ$6wk;oC}`)-zT1c
zC=jm`{{X9xBx*pdD31owk!Tm}oqY{`1AQCagB}3;xu?sF1C1@R%&RPKfvi~HoXqaH
z)G7`(dGOQSp+G0>J$WX#K9<J;-kIrykD%J(7*_wX#qdJ;?ihlL@E;xzcr7-hu`vdt
zIlR-PXWNE{T@F@swU)*?yq#6t-V!&cJ_S=_s<^||-IWdGr(tXSgfQ5i=k1Hb#ih;r
zjBSd=eI~QJcdp9})@73$6%P*4^w3}`JZPd#gW*)EL9uk<becYWGE?Hs!b=skKsV{w
z5-&)c%x^G7@eb1dG$nTN`%Fh966otwGbI*h6VEVj-XX5@zQ$V_Yb}S>R&Reez?_-C
zEM_?%h^^n=C}%&6h~@(hOePOJpgCN>Vnux+s4yFzc$Uu#H{Y8~-iw;b*b286UshtZ
z=EoJ`b}21}$FGfcwf?{2E)U+d**`|Z+}p+Np261GwNdVa62swAyWt+9A8ZD;!n)lq
zkoaFEUPE5+L!OHkp%rL7ItU$(jz)XY=h0c{JaiHGV_X4Na9=|=01|!^eY*?>VhF)P
zTx~a81_(g}PuoUVoJUCr_u1M7mm;c>Rlt9VC2%q$Spq+$2YAmNCEqc*#cv6qeJ0kv
zD%AWhv-2JMsHpNN!R^W^n)Q+yHFjNBq3P}H8}k+}R3hb=-oE$#GvI}F=u#WreqtV2
zKpn~NN#otso4~hBuz_kr^Uwyg9eob4>@svUx{>#WcnCZpo&zt4H_$uiJ@gl_g));N
zu;r~I8_6zmkX#7%yx_ma7{+5TwBap>b%K61oA$c8Y92r;Z==g=jJ!Q9Hqr@A#YPun
znNWtIjjp0h$<9~sVO6S?cr6U9vOukzU8`K|NCs`n2y-#f$`*g)o)MJIP+stLoBTde
zIsNpka{u>?q!?3m+`uaLMm<#i$!uERmVh?dS>slk-nwgwze|j7-6t!JZ;vs!Nqo3y
zj_D?^QsMLLTi*6K7`vTm!j_mFcE$m}coSQ}_}1X!e~10;r8=_VikX_*qO(-OV&XQz
zU{>nXV!yZo4$;om5pWsW+3MUTcC6UZ6E`YlLULBjYx!<0v89DP^q#?m9iU*(qM5D6
z&UO$y?pE@)PiI4P-zQ*&><!}A#7D4Z&<K%4*6^0LXMhLum(W+y*U`6N)!@5eZ~IH|
z82K9-BMH(3J|n&|as^vW8QIyEkt}$DY^pZ3pm}3W-Oz|Oi-TUlj9+km1`LHbR)Nkz
z1S<*ha-O7mmt9<-u$Ipk=S0F1gJ{&MHl!6^AviCK%XZ-MCY#L4UL1l~hh#+yZge0D
zDzcshvsoXsE8hpMl9?RuIxRYHNZ)v=1+Ji+sR<>s0biCCB@9Ru$;?>azSd`8SF7^j
zpepm%(Avu0ttS*7)w79RsAm%!&%?i3U8B{df#3VB*f%;KaNGUAv7NYb!>NT2OGHGe
zU91YyV~QuszoKvet_RwtXBdm(3e!}<GS*VwCbkx@XuNDA-_MxMjD=fEeoWKk_i<*S
z2Y-?$()8a*ZV$d{{(!Vxf-}*Y^5(L3jhXBpc+=RL0juBVZlA~hIDt2JU4%0R(v_LM
zigtv`c|dbTmafZzWS<zAp0=!u#SXVxk8}s};DfpRs8j#00{=orVcR<Kgc7H-#RrUx
zTBVYa8{S{2DQC_4bXg<T$AIc*C%8vftf0t%GmKY>3J>7!*#{qm@8aLiF#31}MXli8
zOC%13T<&jWO<cMEEj4Wg=Lu#QJ5Lm7-eH0n791u<RqMYg;ueUV`90zh;wj=MfZ;d>
z#qWs^h`$p5COFvd2%svIKpE5w5HSL%z7f_#cB12925~;R1YHR})n7+<pzoju(NpM0
z=mqpM^b7PG^k?)}^l!w0SA~a6lJ#UO*-7@2L*!y|CAp3~kUWGul01eyi9DUWfV`Z%
zhP;`)tBfSTinFj73%k!k8k~>;<Y3hU>)XYBJ$^C)zl(PigHMDYf`o9hbcvq<K(qxM
zTLK(4q{6X_o==z_z-RIH;(G$Tg95lb%XOjfnkt*i@Si3&5X|P1P*xTv;Ikd}S#p^s
zgztf?`4G+&F5yq8eK9W&*a~Ts%e0|D5Oxaj#W^_D-GP4z7x4=q9q<boAwHY&@bd}W
zkbvN^9SC;kGT;FTmpyqFE_*=phw|V-C{TD+P;jvJ<U<~e?zkjO#z0<JCFbj?t}WEH
z!v}>4_kjR}dpx*0@DQ7W51?_bOZg0+&cix6JPMK(m#M8tu{uIqvV7xU)`BUF=Q2Jo
zBY2ME_l5$vmK6U+;l1!F5(6j(#Y08#Jv;&73B`5(^+BO}!Y5)wS++ad2|noXx*UEe
z1s)>Z*-$rIj6MXdgiF|u2Yf?WaOLO@Wx>UU1yKhcB05`L<7W>vH4WfD+SQdz&B@Z?
z>iW42acjdNYmPsD%^?kqM=T9=<`c=zV1{Na%_n^BNOa;HSD-aYcR^-Xs>Zc)(F1Fo
z7Q4e5PIY%B<9Yi=YSq<?dMp8FAkl?yBAr#62Rc3IgzcYiUttm7H)t|N9UgZb6S2k+
zP1$VzdM^~x<gp`H%IS8z<#Kt_4v#ZwF_SjOTjrpTyW8n@p*{!gusYbn?KV4WqDhJ-
zP3X&Rr;}Uhv)RaF0^A?r;gj4>2loe)nX!lLW=oCd78X$y6u8mmvvG5CnM^*P$>hjm
z{Z{WL+T^Akw^=MMS0v(TvD>+r)9s$;a=8z{)pK~Pzk*sgN!JjB>EQmy9Q34P40WH|
z>8^vnTTNl-_f2*?<=klXd+1?YEH0iq!0z=HR(l+dlUy$6`3z+rjc$%aHb+NadyU)Z
z^EurXhPK+@_c)-=@GkBQ6FLIa_rga^#Fr(lUaOr%M|d1o?%WW0tkv(jz~wS8w)&m(
zt$r(aL}#F@%ilTA=Ocfd?VDc{>qgJOk0Cz0aBp3#FWb=_dnUDcb1JiOW8u*#xZ?ZG
z0l%4U;lBcqp|K~rq-mfJ_@Hm%<77uis--$!RXg0ZpmF)xw_dz^_r<rKy}a@Jn`_#k
zOOsh=gmFgCxCT+Vd##k)ZcF4b@7P<pfA*e~U3L&f!ieb1#mVeWZtSHv<+A1yiH<o*
z`|^3)5P8*2fr;N2-$nh)?&z@B9bu!+q^L7U*J0L<c7_RAToDtM0ME8I#*rtPA<N6*
zs4MA+WXw!G#WW(+O208=w;gXmJ4aaCIv;n{S*#^?Cr$1=lQ{<=?(9z3mT{m<PPX`l
zyoIX|2}Y_><Y0&Yl=!wKR@+fEkCS^Xc9vnQ*=XP#-?Ft`w>p1fu0Pdgb~&#P*MSRv
z5{=i_6}|%vOy}|$_$&CX53;9_mcLOo-2a$9Ldb2h)n4rMJQW`38`+Y2Di*tT4tiyi
z#WdnR_%yfu$k35}6xqr;>**x72Q`O6m!%_7a!>HN>Q3%oG`hZqv;--$&#}sGqusRU
z-&^hGMc#BDOLnj?pJuAQ&HPR)*)V?x&FrHldWv;GyVg|27uS$i?W3$m+IljKEonKd
z9j43Nssoyu4)``Vf#~dE{hhhUPhGCls-hl~^TQ;1E#VC(BZaFLhC@RE)Venmt>yL&
z1pGaAGTz6APO`XeW1`NJY3{-$wYBSgXy-xhs_MccIY*?;y=PuHJYqk%*HJy-Sw6=e
z$=R6gnf?s?-`6*B%Jwx(;qJaZK7;J2?bu#*<9X+G(MJV?u8`9i8tdi1T)|+e9lv;%
zj&O#K@hTmjO_lnffO8s5DTKe`wW1p$e+J7G4oIP|Sh{Q(m)W;(U*Y3rOP4aW({U@A
zf5Z_-pzqvu*PUn;q;#D~)MuAe70(dD=LQ+K99me`Yeb{~)*}qOMDR&KI)GpJ7H;r+
zy6zya13|{G23pYn)O7?o3LY(m4d%l;@4Qpj>toyp6rt|GWcin#x5rj^Q0wDSMfCDf
z#uo9XDwU@Y)@zK<`4DM@zlA6`M(1^uqtu`E95lYK;v9Nh&m-d<BVy^fUreakNXOaY
zK%QD^9}9do6|AHadGJeG0+!sX!6KqO#h|5Zi64bTCf)`|^5unW246Bflj6^qkNyrH
zFUgJ&m@WbXjf*Z2FNwEt|I~AM;MoV7cBkmvFz%4JMs#ZUGQJM~=(7a}24EWX84s8a
zBG(9~aZOGIyriM;ryvnT;u{@Lglv&MIwOpeDDzWY*Mf)D%=3wkFTv{~(R4=}rbUUD
zz#D4*QTqg7*1`WY_W#1!W;vdA;%R1wgEv4~>iLTF5$v(>Ua@4=FH%mVtz_khsfAG+
zKTCmbFqv&WrXc>u^Vh2-2KbLlO!iN;>HW{eC-9?xE^A-Uvt1#9ar+{mjBG*w3yJ$A
z%lS*;26PMDT3{hXpI~eoFP;^bC*~4^Fdo-{XU&0=Qxj8%|0}U^FA@#>xmB^~i`kf#
zM%;%9@T212YqAac6B6bACRv}q3b*lO#?R=o8&9USciwr|7oqvG?fB&qr6im2zp5yO
zv0WWMU8Ik2ik`@Ehd?~ZW5ENZT+AJ4D{ikyDa?B+`|cu5U^@*ah4M8?Qz$-<d2gzA
z*&;8B^n6LOxK^N@WNVF4AK_ain*OB{J8GF9MMA6WqyHn(T4fjgZJ;;DsEAJgWD<L4
z<(MDl<%W2IA?|}oM?TgnuuXA^6|+cx<u}{~^J@h@;NHW}^C-a2mSLI-J%Z7o948AX
zP+~^R6Z&8kl%lJE?$mG9X2L2^_)A$^V4)M<f|33T&{Q(^ouGjCIj;&~xy^8wY{vU7
zxF4RmtMDcy==+T9bVdHhCrRQ+s*CtDBt`lk13q}CP2L0I7{I-N$;<ON-avpqu%8us
zK(?sGImLU$XJOeu!s5wnVN3b{9^T6J5g_%%GQqgjC&CH?p?-1r-cxWtJb<lPzYQsI
z;6QTU^Tu|nGW8=sL<juw_NPAuvXT$+R;LT3Q6N~G25=u>8&fRcGVmw$z}FO}qePu*
z?NB_)6QAL^7IuR0KG5Z0LG^X8n0^UPEcp%bK0c2JfmRJsZM#rET7Z_I)#w1U86Av{
zK*yl6Uh^1z6!C0<&U`2pzE^<d%f+fKwHf6jDT>=WENtfR!BJY_+`>HG!@&!Pc`(~l
zhCwOj@gcDB;v>IJ(+zyV2Rex%!$>D3L1sg~qSdE5s0kD#6e;ev3u|&>Kv^+Yj9~&*
z76QBo%XlS$ON8jL#b_l$$SWxvBEN>k$47xkB>WE@d{D)geE@jy6yD&|h39f6rM0IV
zUIZe@o+R2?f}Q6V*3Gl~ZC)GyXP>uD2q&_lt7`@PkxSJfM2gwm2l%d%2TS6GD6BWf
zi;-Xz!9h+l!>W_h?}VUF=F{YOAVSF3Vki*RJ<8}GFAFA_WIMlGv6PSb5$DqzHgEp>
z=FOx0zD81r=CO$XQ7Y6G!C$cq=N@9-`~!TCRc5Lw1StIVqTT*sx`#rr3q<wM!~Wfi
zAh5>O3pQ_F0Dpx|itUO*RWbM5IP`|*xoZq;kK~xG>KGg6v^3IPH0tg~@YUFYqdcm@
z3I4O>hI5pmH2%(;RsIXM7LLI&G;EM~$j^27FM}P2AsjOUZ#`hWrPSWCo#-NZc#ZBL
z9;F}VPwfiAE<*#vE$o54;}NtH?3A`bw5B6ruVFXrHk<_Zm#1S3%yO6x%+1S4Wt>(e
zXka**W(-ylAOI)$1@~@13fMXLRD-RGb@<e6DRB@a9LNZEZKoDh^&vHoR81*vY7ryQ
zU`63gb>gDVBv@+k<%P}4*hMo8ka}84fYb|)JC6JLamO`HB|>V05@e=oGKqd7V#<r3
zow4K}igiHe8-Ue*igc>Alf)?053@>a`Mndg#mgbC#!tXw|8-;njU@%~;ub>G)2)C(
zy8(Yr2kY-k!SWl&j=LNDUml0Z(Laayr+>mbog_)xNiP{8Ys=sh%%@=SgVn}5Rbdo>
z7~Yf1fGR&raZEw05wsgVQhmS=JCZn(XetTE1PBwnJ_OrzJal5km!D|hFrZLX(24}5
zh{eVs{A3WT$2`(XPk|zaA6AqMc01x*g(F0G(40-HM^Qf#ZBfME;<uPDnz4w##p~jC
zX+FYxr8r{$e?u(Nud4C0W;X2|iwH*^)raGXQdArw=))gQxU9thqo*ou8_z2S9o4&?
zyh7CI{xXX(L><_CaRh&)q!0clXT`tuuJnQm^V!D`{jn0IXJ)*(a8(nk6Jfi*86v@o
zy@V6?=Aymg9A!ArJ;hj|+Pe#97K^$EEE1vUnFajZjC%q8g^GVTjb6r|@K2d}95!E>
zwSb>$|3$oFk5>o}1RUQ>Ttz$pQFng8Te5tNe5fA$c=%Jz&=(+j^~GSN@&s6^JP(np
ze~1292CD(&jBF2;XpOOOs<wuj_?_6W5JP^&{*2|OtJzubUDPo$)P(A+<*h5qIWz)-
zVhn{t2te(w=mZsPjDyiP3v=>NCFiK<IX4y~dgB<L6#r%)Z(gW3=ha#i-l_&%myRtV
zS<tg3{Ej#io`T<_h`>wL2dEUYUnqZOijJeBZfMObH3ozWjeH;3nxL)P;<Goiy{vum
zvs5OzU3s92>;-wf#*%Q5pH~l8W-y3%h^0ApWtM{Kn3z*=j=V)g-Ng#8$U>r+`_Ob9
zBG;BP8Z74^$yg|tJ<W7g)r88Qt5W7h#mOoqPLh9AS`WU9jRwOop)c7ROhKf;yJ2nb
zY0#42;8*vI*SHmSa<a`HR;@lui#<I<F03H}Pyp~?i!*GnjIF_7tq{YOYy+kTAf@(R
z!KI&ywb%I1hJ3zxo&K(_0KJ_5>VypLg)OyPd_MSi|NUygkm;Ec<0Z}NRjHZM=KXG@
z#N1Ofav5tEjbF&4j&5o?`a$jk6np~AU>MQ(1+N{cV^%i7s?iA$C+pk5h2Nb-dY9U|
z;Kd(t3WNI?Z>E6NB$iO78UzwYu=)eVA2@-{4`8!EekK&ctHgMAV`BNcpd8grd`aS*
z3Ewe8OPXsMD1RW6@%yRz`Wn_}cDv0!wz{G4yO!u2N750C!N;6v%P0hW56_<;w#O}_
zg`LVf<>%>_relV)ENhK3*(@8gW-~S3`WQvU>b*7Sjc7wx?V>!x<QLU;HAEM>oi+ZE
z5r2)-jUH9pmyw<xuhT|>Rom|jfYx>zod5hV#Iq`oBx;iD^h<h@xUiG;{iMBG&N>M5
zRtyRAWBw2kA#j9>y>#Qsey^lY*`&~?Np`ewpsrcbujJlU_WAg7<uCaj`kT7OM<<Rd
z-lVQWDMm2wsQZ19N9=dc9=-Uq<JA%aDA|Ylxjv5!=vgxz122jB7cKI~oSsFh*K09h
zfY<`jrfwmANc;|2X3Rz9t)M<d3;_@_jE##U^UOZK9js@Z^`y*7N(P%27~P>~+4bS9
zaN?obD7@p0E+0-E#>PI;M(f>PjzQISWdmS)hv%ga0*C$yPEzuhj~@k6XHu+Vc-=%L
zg!B-x#5S!0<}H1<Mzm?;0Z-0{;5S|Yw;J2VjbVIBIcj6@(E)N#K(3HIX@V%iYU~;{
zC2=tQupRJ|yHz%&GvH!F(7Z!5xO+-jVoS6Gst~J%50JkQfml%!bv?Kpy5@O2k}l|B
zn4Se#f+~<y4RXpW2gSnS7{n<a59+eB0j!SwZ!w1PH%b{*^?H4bWf;BK#+Z*!hZDhm
zNW6y-oE5)frdV4c7h~?xw=JxIp(`0p*q%c@<TPwASiI_4E>^_bm5l(M2?jS^-oHiH
zSn{b^1oPW<EG?g#-e}R+I8=;U)HF+!0p&P3N*(F>H@c%`8sJ}0MTFMizN(h`!>J@r
zG#*DdKJ??D^L`8w)&{_z?ih5!Oh=QaBAHOx90%(cf<Te1Q7ag0la3->1|G?>C2K{a
zr?NWZ*o2eIBGE#wTrBG{W3EIJ2{W*eJ#H>9iEb=0x_wrE92$zFZ>mjme_U>usRhxf
zIW7o9m?V}FSLc_v?=_ZNg$uBDE)N3br0{=Lio0^G?ilIn;-i0#{Z4n78VR+x#Q59S
z8A>%WtbVJaLWPS<pOPlC^goU5kcIJjFT^+a4I)8*>xLcSb3UEXDr}ujs^?WS^3x^u
z(6ce1)wa}pV1r3#!LvD<rzkOvM=$qC$*@t(jy2bmI_B49d+;AlaZukZS&jd2w#V}n
z1ZtT9{4k89m@q_Qg0>pN>pd_f|Eqe8DfHN1O3~22Hl>lhSB#X7h|)nSfy?xUHY^yZ
z?dHYt{3P)%qF{%x7aanY9e2W+;E%$2;ANxlSE5Z;CWmKrWW!Ka+3(NB&@Qq4=dIK$
z7~7S|;L6%wxjdh$55lzMy9Na+MTlD^4~HpFLPbA_7me`&Vj3$dq6RTdl`GQ)&Z)@7
zVp=M}bP#2$BDDRuc`BeXZc>E3H&)zH6OT9ovf+8SjCrrBajr65f?2L{8UYMa$H^Dx
z08isJOVk8WH4cZ!qW20XYJWPqMP+iBUujh7?EGwbQY64}_a|F%uLMmin44Fm{or!c
zGn&~%v<k5*Blt^+bC6lnUdpb5-B{x4^PzG|pkC2>LtlfL&RQ>8qsAiTOR4p0r=qgc
znc^-NKgTL5(s=dlobsMY#@NLTMH{<fg2oZ+YE<oU^{Bx>q4ZoLo@6lLQ9#5(RZ-lH
zy3jTC1qtp-T&}2=sj4{sws;c4_Y9RNw5_y?Qc>K|rB6xoBPJ(%VG)G-yaZ97dI(~_
zy~m?j4sDU}Y#bs0**+aat4yz`^e$nCxH7cE_VGoJu?lbxkWn?I)2=r1Wx?uwWf+a?
zh|8!9(Rf6k6u&FGt3urCl5r2~YO{uW8U;t83Tdt>XKl~&UUxrMf|42u#~&A*@uK>O
zXt+@Gyx_8TehE@36fY`^J^8Miu0}U4IJ~WlpWw8xaGy#`!Ye!C%I67&Ao)dn{>86L
z!AF8xs*m?dT&|0fM(aU)`ExQ@LqMD$;ibl!-(8A|s};ZNOY2z?NLDKxB}@GzaYTt@
z!7KY5;!AMC#uLPE!87tBh%?`W<`<*PV-JIK(HGH|;bi*n;nOwHkI_pIP3`CCSCiSQ
zV#5Q4pX8(%Bppa!9*3rSE{Eu2$%3yC#Nom|mS8I@`B)k$YP?<s?grR&M(Ka4X$IV&
zw%CE#o1jF(^Z9N#9UelSVc$$Rtz!nhnMFHQ?3{_q97Lj@fRT4*(M%OuYr^fu@nc|#
zyYygr!9P=sddVB4miT7^r9g^Q=AZePJ}mu&ci9Xm_vz&u=?A9Z#pwo5CAZBld2!Z<
zTWv9Gb+t8SYYo@WV`K6D{&<X?R~i9RzM_7D<Bx~u{XFHOr{w3kq}SrNcpzMt2fllk
z7<hV?+-2<R*((IDT%>XK?Bv5&Hcsa2slU3#{h4|5BYiWMXhlbN$o`-Mbid#a+D{J%
z{-BqJ>so_D?KIs!6l|>v54zjzgM;=qcVWBIKQt}n5326}e?@;$b-7dZ7aiQ@ZKvl@
z*kP2KL$`ak{X*k0s<~xQ-)Hn>9GtRG=`%VC8Gg0TsL$jF3)B$N3~`3n5+}mG*`?s4
zbuaNMti!K@_`(<S{#dsHV&0D)LC>I{pjTiH{T5jFzYCsOe}qWGAESSuPs-?@c);-r
zn9^rdgFL0cQz3xja;E8TS^-#owg-Ha&hNG0jQ%_PRDBnZcV2uk{o=(CW4?384*JC%
z<Bj+T4}~u(eVdGvO7y(1ETG=6C;=Dv+QfRQXMtnY;NU990xSB~ZqX$GoZ}1UsR2<2
z%FpC*5c&1$YR&37A+zD`+M%lt8sqHPn^QbR1U;#ONd>I_>a%l^{fhyJquV}hmsvpG
z4(=3FV-bhj0fi4BP9d&<)6H)HJ@z5u1>%3f$LdhfT)zf;D372YqE{ip`@8%(BL6_+
zBqCYTMFz+!GDXfI`|(L4<R<c9atFDWJcT@yEa%T}=r22K_$+9Tv+8SG0dRxYEd*RI
zddt>85P04Xw+XDwd5>DKJO>XbP-C&w0i96Pk2}Hb3zS4yJ?IRmopBY9c6RX2xQgPz
zfmcH>Em#Z7BD3$M%SVU;A6uCBi<-3X&HLSUph>Qa&-_<;<=&t#Ey}CkFU+Rzt{Syv
zG$$i{ws0sxQ3-#Gsl|^I^B2;iqc+MMwHJMQxfSZ)I!};xxk&Y^X7!*FXT<IpjW`77
z-a3c9)$WLJHl57>4yWE%rYeixnDMD4Q6u5Btl1&;aH!GL;;6U#?X4ctA^HP<p!((4
z-d<=k5HdfV4bR{e;JWRIU>D#z=ud||g5EC8Id)ckf-@>P)j_N$HW8<Sr_k4kdw7dg
z8_XC&s1Iy+PK2Gd>(DK*zVZ|FGRzi!0n+M^yp&3iS%^~)v5Lq;$)m{KWI3BWz-1%<
zU=7+%bM}B2m1pc*TwIe8mSpg{OcMejqVTOP2EeLBY)x}<Mp&D{3p9O5eUz$U1g%OO
zkhNj8l!XWIdJul6C_#$rH*E;SDhm!?A$)=>mV;fw>NLdJQW7SIm#{FsbeD4!KE^)K
zA+kYnWrzQP9iB71Pa(f32QLYN(IbVI(}XJ^-uXQIdVVbkzZ$Rp@IQ3c$H%pv%6Cpj
z2tA?W&nyS@QXW8Zx?=M3g)_q5h{bC6IV?_w@>8_i;<uWeQD4<|A;_0nM#!>bYRf~$
zZz)+RQr6R3bjJR-#?4s~By5Y{7hr96zr$o_{BFO6t@2jym6wp-_0W|06UuD${54~?
z*@{uabRSZ#D7~n0WqzDrHc}mma=)X=*GN-Mz9xsyQtik(;QwmNyNa|=x&z{)LjhAd
zKt<nGugv^tZ$+o8sC}l3t5O%{d(6EMhn;CdEo3vII_WOTG@o7Ae=@8s&BE%GVfjbt
z&3djV=SHoLa<&uV-sLHJ0lkof`3ItxkmR6wXwD7d+ST(z^Cr;H%X8;a_(<A+8r*)G
zavke$N^j{ufw#1D*2=EVRH~DyOQq@xzvRCd$hZa8x!UmZ*5TNv+NF|JDdJ|3QIDXt
z5D{?)oHM%*&da(Q-Gpv0vuY(SdjpE_dxS7WfOYoI+__qL%m^RL0Y`HH$b;Gy0S`_I
z!8sl9$(n?<w=7=27xH;aF5X912n1o8!{ev`!TbRu0GRwKCp^I75){|)JK$=2fDhgS
z@GqQ6!oM1vcZEBB$~wwNfGCdsph&zP7=$%^5ELLBp#D%>(KS3XZQpRFyH0QpU%hwl
z>f%u#xn#04P)Ay<t;ZLS0%@r#9tBeE7LEe3IbkOSjsi*K?3+k@6o@J8_7#r;aYc2G
z0vZ2hu6QB`ZBAtAW^>)(=$9F{d+-~bbq$gF`iQ;JP9Bszam4Jg*aGVqdqX5zzdCKV
zB;n8@?}|$j$C_)+RrT3uq@LOmb@t2~a8X}bvNdN*R6$;2C#pW+$TkyOf8dg1j#+YG
zgSBl({qk%k8m;$;$90UqEuE-AZ<0>Z;GTT{{VlOAen0-;&+ph0f%7}e*}hmEoVhV&
zSM|C)@2h^!Ef?+CbI~p52nTAwAu7q3ua<ID=^m&t_r%PygJ}Lhjjn__QF5Thig|~r
z57c13EFM@fKj{s!n`~`YN1Ywd9FmDd8mi+L`O@wKZa<A>%u#c=Asd~4+{U*1J>j+o
zT5Rd6XnkV@&Z0<B_Jg+!R9}B?G~x#m)knfD7DVm5)D!pQ2Tr?g-!aGRyY95qdeWA>
zenHmO7>;JMg`wh0ng56m@?%!<V2F9Vm;8g+UtT(;;=9{BYE@424i&!C5-FkyV&rxc
zL&P#3Yo3MEoyvGy7cCzWo&>hy!h=DKp@lpN4^z~aMBKpx+XueUlF9>X2w4*;{v1HQ
zc42_yAuWt_3<up9vO4)Am0}2wX+GQ*_OgfZFAU(IU?|1MkjeAowg&m}u<j1#urqc?
zcb*mCga?=$z9Ik#4-4Xu@6MYVuNrT^>MHu>tCD-i+xPCJU*0=z<xK$o3QM+kJ&kwd
z$J_Z$a%y51y)Y4vC%C$Nwyry$&gK^&vyFDr<{EPn&u6lkj#^XH#CVzNT*hnmxUGvI
zEQg&W-7I4TUZ6eZAmeeemPY?h^Wt#O=jMJ}YfG>uYrtVOZ>hG|duf_=l8gztT#i(e
znRd}_p0LSoig@PK*7!VqgZYFn8Y{KoHr)$**`M6bygBB91akx4Yu>{=H8w8=DP~i)
zBUhKs=f*FCDlp7}{r$aPIEnj!VS+3<cR|$C%$Qh<g-teHR0~{bgJXQ=dOdcN$?85i
zK-;P6aO-f>T}{bImF==~F4#-GobX2?$yk{Cz!q+Hrc9A&%GAc#JbrU^<PejWY_$Yq
z$Pu+WEUDVInn-Q1g>?_66CE}u_Rm)P_$P=ofnzie!HLAiT!$w+@CP<8nD3-`%UR$!
zHK&2LO{K8mNzNmFQNVmTf46TC=64;zkPkfVH61?oH{POyw%{KB4sWLM*u*Zfskgqq
zr>DNY_lxN`)8K4vt8Q;`HZbut*+O^3Uy66oEu^L=mSR(dv4fd6Ke-bdARLE#fqtug
zaG;@KV6bpyJcHIxJd$ljZ*$4!EH%R2m5DQMbX>fpCC**$E{$n{N9H<WBXI^;27J8?
zh04V@;KwQq34_y1Se}Y51mg;haLjeJ!C8+mtZN}`A0Co0g7M*Bomf&*ShWy`DO_NI
z(!xE$c+w&5xI;Hk0gEa9BfaPYtAX%uT6VYOcI8@jTT;%z!K1m(bh;})dT_v*+PXHJ
zY>9P*JAa-Guk8$X#9A~RaHU?{fw5K?8=upQCNLj&5EXD)cC|DP4mP&zvbfUzEw0Ew
zy0<qy5OHnsbBiL|Y8-7gQ@yKe_~e>xk;rhDtKMX5D~UgXPj}b|@dma-oa@WV^c7D;
z!D%(a<~nkKnb3VeUZ69?xy2mL>l6lOs0jUqAyw!dywk@9J$@H*XYnMQSB3EGR=AGA
z6Wn|JA-&G=>Ui~2AK<=uUdJ8(4d|LJ;+VM9er#9f7;@8w?3Jr7jG)UhbL`hQZp>Cy
zXSlZp>omP`uGR;CEChYhp>>}h;fKuci$jL%Z?_G6={fGLnv@0AuD$u!^}jkIaIBAI
z8qRShQ!W2*`RM41<7($NQ~|bFRkAHZG(wNy^UfDQ^!H=S^hk*>JnjOuFFW=>$Kov&
zP~i<w9@E~(l36P21A2EukZn($pofO^kY?N~`JET(EIN~qSLf(eAYfMIxbyoP>T~$-
z=IZ6k)>bXLWYy7&kA8afcY?!*R4+vCrV%(t+7WKl(0E_b8+@!D2-{Hf@n)U^f9)<z
zQu}IVe&fL0`o^LD!o;wvqkH&@d$<!D(YzD56<z3Gb<KyJ-uMsHa6wyi#p3G!kGC%Y
zh_c!qpZk5YunaK6Fbq2kGsCcN!!Up#`zk6TA|fIxA}Fhhh-8Z9f{MFlW@cvQGc&WY
z()Kdjd*$=r>sh^Di@kd7W&TX(yZz7oX8UFV_5JE)FvBeOo_o%@=brth5?O7J&lH}X
z?V{hrI|Me#<D=jc#KH(w**5NWQ7>)cY*t&aur>`lK?Ln((#^ujkOpm2h$u6k;xG}U
z5c!d#-K;_o<Xe>l*ij^u0IGq%E)^mq@Y~fkkh&^}roSQk;B^<3%<sWIct{Z#q0UUw
zL>e;Hd71=I@7hp#<`|UYAryEg#_|Jwyy*l@w1-d~_F9BG$j>7_CMI4%MFa-AEAad2
z?r!2hC-QBuD^mXLXCPv_U45}>W4x~n2~SaJ(o?VR;#0GfLVRiK0TdLR=@TC2b8@UK
zrzko<OD<Fh{k`d#w6MMRSZzYkw6gf{=V}U5q$Sc=5uY#43in8f33YS#FF;`m9#3Mo
zZ=xZtm&4vyF`L)Q>*OtgE<Eda8zHWD_vkcdQzeM(VzadfsV$6PDeARkw<8gp#IT{D
z$GuihWEJt5DMSjnNC66^mV948Dg;E9Qd|T?_qW)AAkxy2R*}y3MHE4+K~<z0CY8G)
ztyfM7r#_bcfjxIPujG_mPc_xI(uQ@q@N35Qg)P*XGvk7uo1~ufT+p~PXHo@I@tMrb
z(2x)`WsOLLc8Vf3Du28oDo~r<S5wm$Qusy(esY~Ye2hr6h8|Nsu^vBK-#z3+-c2Q~
zY%2I~zXD->&BdyMKBz5aChEg=_$>dv>*X`W{A%;OEC|)Nqj%P<5&Z(whlb)BNVG<g
zGh;$!f3NB5t1%=C%d*fo{W{$@q40htR(}<7+wyac^&}=aSO__WbD@)Q7q6Gs54{?O
z;EW<3@R7AHhni4!>)PFqLlX+>Qu(mutTcd|GexX}7A`O0QWnId0^F-M!UFvWQ4JiE
zTSFwMNC4#2Du`fpMNhG{rjq`V(DG$#q2#;9_SH-3(Zu@7%8Cio@kyWo-Fs$S;PXJp
z=L3O|Hkuv=O5bTCDc%j#L#NWiQz{8T$qz0EVxpr!^w7)|DdFi()coC2%lO+vMAfra
zC@v&a?6~b3O9}e%>Su$-J@d@Cpl7*M{RPO~X{9Ri00QEQwW;BMW#?YHG>E0<cL2e`
z@YJ;+hwXdDkb5=8z?n7;I#Zi&G8r{aPBb=RP;vANhx$FP1qTFD5MgRyJt;(BTHl3s
zXhcH+x`9X~-WcKlA&*)s^<7cS*HYtVKJYAsYu95*EgAhgA=~r^@6p9hOiq|86;&E1
z#m2<O&@IV=J9P=O(M0kWpM3O`g{)4*803_JT?>NkmCGsa61)v1SJ&fMx{O_Trl~=j
zHnU;&rf$T4R;|_;=Qd3VkACqEU-veAw??DR2oF~-Hg6+`{)REU1h7*|;jXD^(50al
zvUNw^JC1_Sq}Rc#EFo<7c!97a7$nMtX(w4Eqz$L6#$k#TnCT*7DFIeA=}+g<fc0{y
z>oJKv`^uW@Nv1*=KkL3h{78Q}y!ey_(e#+>552KMJ7e0;i!6DvlLh$Uu%HRGJ3ert
z!3j&9%WogShWO4>Y$BvVW?j!Q?F#%XNIMgD`PzrB9*$4@WS5y9gbK&;@BG*c!0$4<
z^C+B0Fi$)brQoBO%xeTG*3RpOjK4mRVkdd8j!p-{`Jm0YwjhBb<b4ZA6FOLY7&Ngo
z;RayHr;yR`3-15b>u5Nf5UrvGN|_EW{gwG?iL?Tuvik;1A{wGXdOw9om1IiPV8ddd
zl^fvD5&^-&kq?T3hPVE#&jPNA03RYK=Y){1b(2)$ix@E3r^Q6#eaqUXlUcvSO5&HG
zFM`?_Li`d8Q~Ox^s!bbLw?AfiM2|H#qRxF^?V}=?|JnDI|1*tu6(uJtlMRytVnThq
zeJji8BIHR2(3C8h3e)(j=}=WF9T_4N=qL}hTRfupJ`r@VIxSD+5yX!O_9;$@_Y2PV
z&^j>yaY4LeZ~TsTc1F;B$PoR@FVT24ew{o*$Aky&zaPJjeDF`Z@lVnBQ=iB10~Em_
ziku`-0*)30hw;Pw`E-@oTOdmk$prpMAp%VjrPd0hK_PH^y~xvB9)iyDBfU^svX?~e
z8^Ck$p({aNCV?eD?jfpxQ;^)<co*+5@5Cs4W965TI0s&b&&a`YV7(AZcUt3)1WF`>
zy8+VmKvfY$7=^G?Nqc=E^ebk6Oo}PXGQa~w&YFIM%msmK{sAFNx+Q?rPB-X)Q(zGI
zx*o)YEAg7dvc^&;23g9o$x3589nRFkeJNA$L--+TF8&e!NLT?$S|s7AYD5X$`0kXO
zh;ru(1fI0OollEADM7TzEllp^?V&($Su=9?@TYy<yusBa6#4K40kQF(aJPxj-&5h{
zNl9fgCthHkAmIJrdO`xN?hu-$s+m^iI91(={(+-*<0v{%nJb06w&C7q+D+l%=H~6`
z;lX!zSGkF3AKH@+6jL#gO4vG-EEvG!%R(iJxUd|g3=5&)1&M??m6+hI?=a-G=)8S{
zBR$$>ejrEe_1bv07kClG{u@BAy$v$d9_F3ly#n28e;S1oh-pqtbcG7!1dv83(!o_H
zBZ(8(%Wxj*Sn{PCR3eqZ(Oef1^PlW`GlgN>`y&-C6v>nz5<rj`Kv<YOp#BO|DHiY$
z%nLyVfA&U4n1KyFfK>x7E%-2)IH}~MPN!MM191WpjZT*nzG3~I1~wLAb)v!={1vn-
zX39jJlN6zJunv5i{0ubTiK|-7Z&$**0Z0voP<yg6G9^VFnQ$>B)H54=ioy`BFjS^d
zr=WjteNilXn3;7gD?se!^Ot9Wg{9JP_tdD+SYK!o)-YySpr>c3?{p7YLvpY<6!EV}
z1hw9wa%F^v4?l$OFGiI=%Dlzm#Pz}6A=HY4GemBlZb~;<u%8@J-#GEy?P;l#CCbDS
zLs+CHASlhA`A%BiD}}dMmk<9dWvVVxos!lXmKiRI^b8XuhNoPAnTi!<V;|}-P(1?8
zOQ*_mOMFBkFMt0e$vK%igP-E9j|qy#m;XX9jPi)D@=ue5&x`YlIv%7CRpHArz_XVZ
z6HPrc#XTS*I5={Q*iGUcQxGMRMa1w^eZjNpt6^4yG~(t>>fvM~+W7*|&DZgcK`+4P
zp-25W-kZGh&`0@W-lx1T!6*Mc?`OCP={nq)M#G(Hp0F2Wkh2nu!r?9wEmR66Asxul
zG0@Mx5S5}zxJPZuC|pgLaK!t3M`Z6C`=xBW4K_J(8N#s_1)Qsj(yB}xFJsS3@GY88
zO`=j7*nK4<!V=inkWQQYD)4QPujCe8l8&L(M}dD*B!{#|cn$*ApFAT!=C@6MxO~C%
zecJ~{_#4{Rn?8eRAGnZQMgC@AgS)Q%74U~b2JL%Yis2#`p0r`7?K9bhSM34VL^C3D
zJTx9~NxI6{$Hy<tH#(k1gX1!To=F13q$)K=9(kW4K(#^faJVSIS5C`?(c`7z;R;Yn
z;v<y&8i`mNAcvSiL}(k$7x3MVgdU0#2^0rH=Y$4lg@(gJacIyi^OI8NM_;NIK7qzI
zJ(5_apu>U$IicueW=wEAt`Q2Bq=pJYoOYWFf8I>{E!R1cXYcGJFOiyxkBN@*@)6Sp
z-|LUetbIaE3D8r5MHNM2xF;_7g|*e)5=tDQ&k3M5y9q<bNW(*LjXcm-8exE7n{TwQ
zZ`SRU+mdEq-&0DV<St*|3Nd*R{;%@&4Hl5!rsp^L8-IyJZoi}X?APEsIOU#+6VSWx
z<ehtX4n5kUc;t>Ua_ejrWRgt<TVN18zMDtcZNQ>X0tOnW)&N0_5x18~r?BW1u6>RI
zastuB=ScPl@jAi-F)EZYP!-5aDv<sL&`(_&26<NZ<B$_`PPDorm+JXS&?%LA<`s*(
z7wwDky7R@LzZ7(;1Cxtht9?eA?4CD9j-o$1?iE$!wejDty1k+lqlx&Tzb$rR7K>wY
zf<1@Kb>*Uzn*F{%Mxrn7Mk#0B$7^EuR}2;6N&~uDxx>G_$U6!(AHRUm^E>etX;KM(
z6wF^ooi7C}<XpI^dk%Qx7x5nBJp<?b8&DY}7==o3XuI}Wjz}<*JRH%JNra)vk*Oe5
zgCpJ_UePK+MT|7CsbMVXK)tZWT*#5nngSp<(+$KXfJbm$f&$2<D9At)Au5K3_*3BE
zXG;pnY0r)XB3DaNC*Ti|kHinEiUd1^4V#)?gr{uC)aB`4;K~iU(TPuLT)0FJfDlua
zD<iVff)dJqj#6r~qKi>LV3;4i926QHK+Tl;#CyBTe1lLD-;2-J`viLhMT){iVG5bA
zG)%1X5=4o{CYIsnv?_0nf6!EkLZZNz{5(YNf_Pt1pj3%ERp}CCa#WPqTcwB%O7wPD
zc*oOX0YBc~+no;bcMA^^dPoHoW1N`J-mQ9vJqs>$;b46$B2^y|Jh|v%OlC@W63tYL
zBktNA>P2l6hsXw(E4||QG@Z;Bi23Pm{(f44CM+zdfc8Vmu~D&+w0{)-LLMUjADNfX
zM^x-37DT%RGTYG{Ul0FSb*fq|pmce`rE*~+4Fe<w1bgYcK&u{CpqAa|?VgV3@%-&{
zgJ|~7`8?L=Fa!K|UEqx!f;&`?Kv(ovfusKl8p7ASA4cbDV&Pg{4kI$Nh5em;wZtX{
zej;o~M*<s>NGiDuHHtWipzl3<uA2^f!fFa|&I8+%;~(B9Y!4qGB8t2MtO}oDo8}Yi
zhv)~iA7M=qyicrRtyHHFN<|U_c<WWkddmdh<tJ&8uq)srWMWs^Yp$KIcfAwi*4g`g
zcbombZ-A%^V4b=zduaGVK?L88#>aepWL`l&+wznW#e_-Op%TRRQ0_J?m%8ghL;Sp>
z9*qo$^wL&n)iJ&i<;8j7xUSqYG$zPfDvr^l3B4<d^+^HAv*v|{E}IxK8CO#L_|PBX
z{Q^`G{_2MKq>3m_VoFwdq^BXE(urX$j^aUkR-M3g8JnW}9^hM{ALfe{$QuGrzEW?u
zIFElsR=M#flx$E-QBXk0`~zr)K2TN}E%)<H(k^n#u9c-L0ySQtI#mRUDDP5)dsRmI
z=KHF{{r#|?yH9d-6fIGeXUXH3`6}weAN%p9NOXMpHgRCG+gZO<cTbV$AxVh4rz#eQ
z#C$v3Z;3<yG~3xY32t0!125T1-X^HZJOtMEGrZSE;Zu8W^GI9@uiM?w4!jARXy!q%
zgn)@zMgu+}uam!69y1AA6T88yX0gmRvS7V2U}Y2jXYD26Q6jF{uaL$W@SN~65yKp3
zwJQcJvpT1@IWgZ{tD|}c*yPn3bz-zw678veM5FPM(X`A5?eQ9$NG_C292=FN-xA`b
zs7$<l&9rH2$PZo~Efs5*W@Z#<#P#GOUhIdF+VowG<_)p>aWbZtBpTH&C@Gy!ew<j#
z>a~8;p0@%m{_DwX?6sB5;~5QVr9TS~nG8PzFcMgCZ$jcYf3MKF`KZhU+?vI(4%6%(
znHPhfu)>%s@iGJcK*<6YG6(;RmPaCsxe!~N%9{x%Hu$uW1Z_k2j>0V_Is+L^UhR?C
z1&GHUg1{5(XDxm{OI|ne_i55hvd!Yn2Gt*2bwoCR&qf5-D#O|91EC6F4-iRO@Z}M~
z1%@@e4w>2Hbz;m%fep^S#l8S<m|i6JRRQxv!9y+@i{MMSFd#^<RN~T&G!Rd_ik$O`
zT;y*$`C)u`A5MPu{8tdMNZte+$)KQ3(S5dU0)PPk02D0a0vnU#KFXYvm?|=F3wS{U
zUPph3t--RuzzT<rVR~i=CpVkGti(A9&)`quaDrb7@`^wFVmTjP$|av94=|-rl!Odm
zrNPHsZGs|;zu$%VWA*)Sw)T;uUnky6tCRm;`p6W>Qt}YGQ8exD?k0(Fm$-|f-90?~
z)gr+hw*UbWxFc^ruOK(t3xchDA0h2V3-g5Tki{qzQxPKMuJNEfXt7$LQt3tRegcUf
zElZL3#UeNFV6Pl%0|KQ2Wr&3Fe9D~?`_OJ;8io*gfmto^^T~39at{G5a?9j<2;5_(
zZ;QI+-t-EEkGluoTPYMF$~Q(Fz?X>v1foC@U&=@R{D>%lhXB&Re7r<nl$XpcBn$;l
z_4J{n;X)euD*e<Vp{I!NK><I>Jf-f4FK`DRpU~Y$C<=8Gi9Eao9(2%HH$OM`6n`WT
zi6dzb!QrGyrDc3K3Jq1o@g+_>nH%zGu;0uBj=_%{h;x_@40m&cgP+N-lXeP{Vg!_r
zM92q4%0D2La?5p-s0F3M3>iQr_oPz*d2S-mQ+z~nN+1xqc?mtdD6xBxp$af4@{8fS
z=eR54+=T8j&p;1<A>W-25Q_Ma=H|&4P_&0iBnU?o%@@Xt70}2|EzfM{<5$J*(H@?n
z_{1O|y^q-61JQv=aHFc67Rtn-;A^3SDJ1d|fQ`fVR0!N7v?AZx0EIkWC=y7ckeKq|
zyU9?npC{tG`vTfMgrSt59K1)_`arF_H*zaapn$&<_!|siK|z!+KQ%N}4EBMion95g
z<~-(uCwMx@oOy6(&@IGrMwT}0$pRaN7zS(*93F|@WQi*f_Xb1=6tIKj5GMtr5CnxD
zq>BL_wFZSjYkJhe*3`q_;9-WaxSU)rPr~COtq69e%eZK+eZ<Fw^5YQw*}+DC=+9vH
z1)0J=&jxl2QiabA1UIEN1rIzYOcitocF$D|KKI<9VlF%#`AsM8v<8Fr+OuYiU0CQ^
z7&&dqAtpqvkIP?3ZR@-^AueZdFeh%p#m;Ti!u+`Ww1mQrj>3dAcslC)j`xU%^R!?A
zwm_BFDzMGB!_5Sbfluu`?{nTa;6V#QQQ$4hMdQ$H)CD&`-U+w%o`Cw~H_$uKQRg4%
zi&3~irB}*DdL>aE$ms)mmz{r@xQ9V~poJimHBn&KX-PVr!6ZJ3{y_vS{Dz-UNNtso
zbXG@?v3Y2bQmT+D^$N?O1tq{LWu#mxBO^dXl7=uDP1I=tu$4iU4pt(0NkCqbNz-)f
z2iU*BJ_I1xzghj;-2{~R<U_!8BsdTJMOY9x4C3$LuNa|*4UAd#Fl8Cs{2UGnR&8S6
zkON*wS+U8IFhCUo>((Rc7=cgAdbeQ>=I=t=9{4=rZ4(@1{%{0vu%*dxN<xYpKu6#L
z#96+SriE{rls58xf3k_l?tu*gIA!4=8E~K<XtXLe3y9r_T7`}+7iO(#7snSiijD1J
z`k1kT#NAd9e|Q)l{NcpmEl|>1Jkvdd%$_JOeuzJw<E^H`71D^LITEEzAZzl7kqAAS
zh3V6>)SPbxAOVThtufY!>78O@f+>|ali8EG(Niz<q_)K~dmv-pZ7UT|wVIybx8Puk
z5P359B~zO!(1g%1Pbu?kv=GTQQDA+=D8w@6vk*_T9e*#<@#EOg-!D*~DCVohVp>a!
zqs36E=;^g7#xue*+RH0OtQ1FkhDUg=$_Vxg;?ur<D1273$|sN#M5u5>Y%Jte%c&mI
zTN%L&FG9o@327lM@DsQTAYmvrT_+6A@bjhNV+=)x*HdCIv1LlixHJOl1w`%=TIR<G
z3tz^M_b&32z}YB27%20V1p2C?)k3jWEDT5xS5Xt?Vgco^pgcsB+^A8hG}NUq5oMHy
ziap?eM`<E>^x{jR3krxO?oCUnF}e6l0)udgP-=XCEb0&iQv4|DtpHi19A$b{tCeng
zsoE<GiE|QtJdFOFucXa|L8_@rIdfqG66}WDXnZOzGt>AnEzhNnYTP<dvhjUSclHUL
z==qLb7)~v4)4F*YzosKArdA2x_X!hA7%y7x>8bbJTIz|<Nuc0@DWiUt`NYbu=fjBn
zL9s|o1&I79@>oWBx_eTS<X+K0hDt9lwHkh+r+MZTd-*GT@Ol5P0l%m~?;s@eEH3tx
z%VbOfybisUifO3|^b!dz6uE(hlbE{At2ob7?nC<-f3Xfrd9hQ;X)zt3^l@{S2;I{}
zUQ#c9nrDfqB;5xNN!lNB!vg$*beZ5xDFjtxyr{%2To@;nxzPgugyDE?aI`wc_>dr;
zF7-<G@=heav;e!aQpv{6CYa-9OL=#|UFZkQ_T1m0Q`u$21ARRL#iQ&|<)%3T57|L>
z5)<@E5SdDnE#^WN+J{+5*a9{+$Qpl{N~?nNlZ4oybTn0AimRF4<0fgsrH*!=(>VNX
z_gT*Pf7bW7a5}ERg*>{R$y$=F_JKKmA;|>z-YyvD&jx&#fFtf{O>nS={FEoVyKi=P
zPZkSx>vh5$%ggwn<r#X=?i2X9-JeKl`P`rP4J%OgusX^BAsbN+u?z8CD}YR&CEUQ?
zo7NCBT!b1O9UL4JgYh`{Z<bE?j`;<YX@0^SHNW$V`H}hLkNAjX9_z%gpJ-|aZ@JK$
z@5K{=?F$K)7VUwSC?lls13s5XsRSZR-i`J3jTpa(Ujkz>cgu<6$4`7RYi2$2#RjNI
zKa0np3HStt%mp&$@9zr5Fs2aV6aG9N0_zlPGN&QMnn^R`0*5Z!4T?f{J$>{E6y!84
zkD~Vd{;ps-jUl@o$`POnJIw%QrbcHTpRe2E7WF_e;_pBen(9Uvc{`<Vs*UPzeufDr
zg92<6br8ld@_hida4TfQtKx%{a-|+@M=)|(Re&f%0wWnHU<1B1UekL74Kr{4Yrdjj
z-Q3QS)q9qePc*~&L(4o}_rZbAFXxBW)~v2;>=}~>Q^8#OVXiAMR|M#MJTeKWUV2t*
zfYv8Od9Y4IVvP`^C1?`x+Us}k>D;*d^^X=Ve0g~8K<Vm(%f?OHar}x27PM)&Br9vM
zWZ!VlmgN%~=cZ;a+LIZFzhPHMQ-Lt&VZf0PdUxA!&q^Al9_gfjEn24+95xO1^S~C|
zht_Qyz{ZR>jHdO(ojcb;<udP~y>syEaIpYI4a1n{_z0vg!I?y9Sp@-K252KH7HEtn
z`1$AY$-~uMYtFu2(2x_3zQ!AUE8^DH&b-XdID{U?7j#2qM-K%=qlbGw6&IG{?@h#^
zsRo$mEbxt-7s87s7$XRa(o2-73VD<&g4VI()ie!pj*!#?5;Wkyd*9~!YsaCJMS9%?
z{G;40Z{Ka3P3RiJ8xEBi#wO_|A4QLCKHS%K6w-#4`r>mfyYP2p-oXddv4vB{<dStB
zg83_1+<8H{3xuzgdZlGmm+{e^s1_GdRdpuR(R+<osh^iwS&PS~R>1c^1bP$r)sPux
zqIrbL$3xt7B=8~fhoUAzXp{D=fEqD25(3NkaC-Ia_`SU=ri@?MQ!#nVF~lQN1rFin
zp`qb5fro?F96W>umKEn**;!q)tTQ(=J-cH?)r2c#9SAR6IBkp$ADx%uk>3FsfUplY
z0z9vq@kuz)Ot}b|%6eK^$wr`IPdP(6ALE(|eL_9*mU)zHT(#ry(EU>?-!!cnpL}}a
z)PuztdDMF5e|-kzD0}XXRqG#E+{%2*LUGUAv#XA(V+jBA$yqIW$J~R7_|gCZo-%?b
zWq;G0=jOcu2dD{4w4R6^ImjK+JIrf%KAz9KMrEMgXg8J7j48Ym{!s{{cKC;x>zOrw
z|NG>uteOu#sLA@<w(Z-uQ6=1OkP*lSxnI0``%_P?_}?olpL%*F{;V3!!v|{doq#hA
z%)w9rW(P5pu|yH3lS<e~Rl1e{sRtmX&QLN(bEbXvd0kHSw9mh&%l@A|cipwe1yIzw
zmtS6s8Ejnh@=I%8#e31Lt*9PDT$j%~fUk&}1e-zDNqND%NCF8`0qT&B2T3_fS_O8Z
z`EPhJ38|pWM%09V>_b9)tq)0X)~5OR@zzaf&SK`<KKvt+^x<oCLqn)ra08Wv-SFek
zi10l6AG8o3F*YI(e1-11_6wwETt!Ayhd1L0oPZ8p8%Qm`2DB7#;PGeW8K`3%h=^<h
zMJa-?HwUb=I3xwGH$B)vr)Zusgr7#<sOi8N;|VK#N8ent>rBvF`wze32qRO!svv{z
z`ea*@-uS9LnAC~o7+>3h|4!&<!&?|DL#$X6h*;vuL7EukLREy6C~G!YxzI6Jbd8I4
zR2HFx<@I%|alzN`?O^gOFggNO+m_JMum>MiE{Z^Jy#L#^f7%0QPfI^un2D<_6SJHT
zm;=#Zc?rlVQL3c62rfvtV#Tu0@KqFXp|{_-+yV=I6+gFnKAP?b6ITAuqHeltLD%)S
z?V*9@l10n{dpyZaQr$8=QF!I-KZtEwIgASnbDX(Kx#2aiYwkh=OrQlCM<|SqbXSkD
z1AoN)WDkY?{4!oBmzM<W{7@x1((GU2Zq$bF9Hv5zpN=&3A^c4{UhT}$L@sf8M8!&J
zE035j&t`=XVHY9GEs*yx0xVd%fA43%u3h=b-K$epcOE#3is$CPhH8zcMuN*Yko4WB
zAN4QR_ZXhO4<C?TUu0Z28g3kE16Tpf=-@YJ_j753dBeDVco-cXHl7<1h$gfHchDX9
z9yG^s%RAu5aemN{q*~%<f}BX#yitpHx3{DDot;e2$n)1Is9nL;)xpdH1%_lguFSEg
zkK_D)77c2o^)uS<vJwhZvxk`jBTj$m2fr>^ANAu6)~?_wxqJ!gfQZFCbf(jRa$u6h
zQi&b*<L<?8joZ9AArpBV!h5lJL>QXTo)UZ<XwZ@~7KP(A#!g2x*zu_kFVGGap#O;b
z<1^;h&1kvt(#Uhu9gG|EjpKyeeG$TovYU_S+JFFmIl+KTVUUf)eseZ^;LF|kYsK2<
zf0p=OdDhrGG8mM{{vyVY`gZ0Za~VL|HemwgbObr@qccqu1R@Zg5S|}_Ce$umEnK%N
zd^U>XuQQ$<1)d{EFpus?y$>hcM+uy`gL@_iLU#h49fnNWy;Xy;!Ga*!)uyUK@jv&F
zE@|t2`@PP2tsUpz>S{9%T41Ap8dI`mYe_cz-cp+FC|7a7djqQn`!D>zr7KnqT>ra0
z9nqyd)7#sp@42&~qhq?A9^ngGDXY;~U}KLNa?n^_fRo2`R69V)$J?uie?@i1m#qLE
zf4i}`Q&;Q++DrH={J68+r8e%z&xAzT!9#c~-42HmkpjY)Le`UFQUtk>jfTc6Cyp#B
zkV=nyG$JNTH@n0nJ~{jNP67J$;;6{nJ%b<<{^Rlh;l)@x_*GEi4-(p>=G%kLDnfRo
zPr3j6o?#?BFmdiFX4s0?yR#E!_VmBth*!|iTJT=FD=B-&!6M@a_9UnFOjQPAQl7%&
z?qO0{;HaZnEH?<wvRMSyla3ft<ev>{F0jm-ZFR#tde^OaqBMB!LS6C9N&V{wW9D}6
z9}_UEPhVv;THtqto0+htFe7Df>|kD!G&WgR+_q?Jy1pZ6adE6PIyJtS@v>iu9sES^
z<-iYm0pNC|lbE@Nzu$_#rye)HJrXQO84v18pVPLso6}LgfCnTHjAlPD)<={tJbVD}
zAHHyYloOZPhR>jKDua3Dz4xeWXAtaQAUYy<-5_^$kV2Vmkhvxf*5DU6;OF<9)Cs9E
zN13rBtzT!{0aEsdI}^N~q@*{1f%LxM!T^OuB&h%lSK0&%*sm;1a2UEi2_OG>@eywy
z$ymL<_tKg*9^M}LX=#i1D}_F~*f`_vQDCGp6We!w_}F6r>o?lvga17CF!Mua-q44~
zAGra{j=F-%6G36VE_meAI&j~`k9Q(1{`Rid-`s(}XD*Bcmaz#n;RDbm_y~Rh<>7kc
zU8C?Vk+WRfA*o76z!(8h9{7{Z6#mDK4=*wmBh9a4zQIROH5H5-z$SCB(j51_qdv_#
zwumdkH2}<;xD1_Q4xp#-1gc@=t-OY*@2#N@^*T*YWX@KwRsRh>#01Ef;Rzt^A1<7A
zxAS<7EODTL0n`gfLEdO;(Q#Z|i!QSAX7@snH|;U0J!!?K(sS-uL*z}gs%?F00du$(
zYtY47TpfW=w4elj97=BiGxle*uo<tH$rJU(ZAYLe0)$O&L}+|wQa&SVK~?;dsICRS
zaUG;3&3hbQ6IBYfgXc4xJ&F7%J``+I`ZQnYl)(2DrBP75&8Hwk4JwJ%zK}g=I>;fW
z2^J*r_Y?Uks{9-;{q!@u?2FIQ`cFSYYrp7u5kGwHEPmwdi)iw>vuM&;+!j+i{qDN5
zmmB)$Ex+ej&&rScsS?{a)_qP!ARi=Od<7pr`w|elqd(^09e+8W-mgD)&%Yjg4$dAf
zym63!3I3%UK<p=y!J$N}WMECg(N5nSwEgF|>{>opvGMeWC~$ahO<}`@8$yfrznhEK
zq1kvp-SO=Td>)umU<YqBM7;}c46&9qec=Sv5M&e2GsjqGm6M2@z;_E?{lPbXX`Icp
zq}0@0{Cv*DaSQOC=O65)`hKo2L;M@A<^tYLy-+)C$LuJ4?RQ@Iq9D|L<W0QgXY32>
z;`4%k-zvJqH$pWiu^)@csz5Xfl@S`XRH9KUBNTi{P?Bh(ln}0zN(BDO2!mP#?pN4^
za-<|>novXzzb!J9eUynVZCw7*7x;6$4F7~rpem@OS&R4=5VdhdJFa^jU&Rl8hu=eg
zc>^wVp8g$5`570X82mLlgg-<HSa+hi&zB##sQE;H4YayU(nc@nRJaM}QY9bXzoTmM
z?x)c_H1Fx%#WfGza{(>hQQW^5pTomDN|x@8EJ4fWO~4ze1||=^Tb$O9Q>Yj40?#Gw
z2k*E8cjZ)OqEFd%U-~^>6fBqpJBLIIz`IOrb(&<VnLSc6vmYw>w>O08J=c!$%dAeQ
z0@m~NH=+L87(vaoV^>WcC+uPJFbR0vvHeUQFU#l_9|`MS(wa0>i%-cqQ=HYIbnoe7
zZ?4&WI{5AVhtFE)Lzk`Yqpz*rA|eC0^Mc&A&S~E3cHSb9Wj6YAtAl9zG;k1o_5M!l
zO#C9QL+Jcf;1}*3zQmHV&SLhP0l$mPJ|D{z{CbnaNBOtj{%zppS%B)TQ&4Bj?wt=z
z-W<nu$ZRucINlr^_)l>iIM!jWn%y-(YkRy%ZR44|Lqrp^jrLF6gIe*PVJgHr6n(|)
zfN>fNY-;Q3Z8B6r&~5X!SjXnO-2)DmH7h^a2M(4laIlm#7rc&Yt@9u`_){+S_uBj^
zj<9oa0Z<cbk$6vRGk91WCe}f(+1w)lz5_0}<8izp*74{jivz?q9>?7=+IVbM2^$~c
zz(<FEpP7)an!VXN99m)aUpS2=x8YX9^;RG&bbP&?gTgxIH3xTu^SU7-Vxb%G6yVT0
zCjBkzaIlR<+zU>y1#!Ob>`kx^#_w=&AlQa=<t}iB(;f#L?|^LzG1no$8Q;$QCvu*<
zZxtklXTgA3v$0zHq!8N9#<%X`39Vi4S`GZ2R;zw<S+;dz>g4%lt1RaHUv1WV11!!S
z28o^QAOeF}@3hrsx6bNqHrRK8mENT*vQ9-en9Oth6EVlZ8DKwt5V2>iYjn28M_DEq
z;C=Zv1KhIG(#`fOwKuoTizU`IEY=<tIkAE)u)z7kv8*9A844~TuwWypugRFccVf$_
zNRtI^UGr6r<@}k&P_~zE5UI1wbaOhZbz=JK*1F-Hz3bOJUK-TWtuF$@c->%3bI<-U
z{>@8uRaPL-S7y~TKT#T+lxDMoV<fS<_#y`x<HLc+Z1q}a<nzsju61nsN7k@)7=yD9
zz|X_6Vr?UNSPWO|P*fb(PIcPDp#50zM53c6?L}rAFv(<yekS09A!;3zKaVv$>lFdS
z@N|@?5w<ajUPPKxSQR6g(+n?vw)l`#>><CW_tQ0-Xb&oU_u{8SkX5_FZZ;~jx@_Wj
z=5-K6kNVZ>x+n#+G9rB9bPAB-I6qgO+bl+o#8lcFiPnj(*_(up<3fgl4OeCh(1s~r
z*690i=Z6=q<MHQljXWnfIcKoD)uOWwNdJ>-#M#D_n~gTIZu|Y^%iUiD^JZK_n>gn~
zQV{-q{|~G074hll0p^z__^(TrpyVaCX-pLEi;4<4O8FRfpnbR*T-$e{d9LOKv17rE
z{k&-g0E6RVwysW~eX;xH<-I~aKd=#(4Y(bveq7Rfc)M7<`;a3H8<SGTY$PyH9s|`(
z4)t<<59?e$J$p7)0u$TGbO}_;j^RLKu{}(Q2c}F7i``11_e4ptILb5<2NCopKKS0}
zkJOejD+c>IYCCF&;sVDtM#cBfZ)^-JtL;@QN}8ke2%n!*^`#YP>I}}MJMQSjJxkZ8
z4CD>v#s$Rc)5kW?U#@RUS(dL2iq483+YL%yhZFtcpen_NN0ay22C+Gi&IOp%=USpC
zr2m5D@Zx^PigEtG>L%VXIDbXYec2)P?@cUQ)W1kGyJ2%m(A4h4Lgt9+&F+IP-n6a_
zeYLVMCuMowy8J}{n5Kuj$7bpmqz#nB$fI@f`OTxeM|ehLM<*#S2rR8wl0jg{Ilin@
zj1U6O!Bpr!XntZk5H+R;>zV|*$9uLdFLM+5)Z(W<(siDA8`rWA$k3D>*Mn;sv*Ws~
z;DglKMK56P>YU#|`QTsizrn5DVSW7RAb#pF{5bP>D6z|}P!i-?j97E2AvBN!HV1DS
zyXU~GM>d|pCPf7)s?w@AKd!IHpL=>*dC`=I7vqBc-93EDV?ob71ND@DeNUrU>R~%u
z_(gM*K$0I)bwzAm^6E4FyZwOsSE~ZXGh09aHbmV<QJ9~#xQVJDGRo#dP_TYR2M>Zt
zt}A6UBroc93TImzSL6E@<9jx>qRRQ(t~La_g*sW&Ob6X%+(ryM)PJo!b%5nv+q@wx
zEuDN95GR4us~80SbLg|+$L=nf>A?jQ`qTHqntw*6LsOcMo!-6X&ET_#_rL7~3T``~
zPulj0aa%?K<+%m{BJM(vS;V6_cu+fgB}hKH*&1Op1x#*oCqEDKUFXjCze3Ngo;H0s
zK3`P1V^O0M1Wy~Tp2z7Ci<GE#PeTi68g?`YVq=UBG=L2HD3VP9crdv`T(~@NbARvO
z@IR5;XUkS>!-p5FMg>k&|MmT@1;%aNi!S0vs9pAJCZ2VNS&<&5)U*Gf*O{YBi+RZ!
z@4xCa5!2Cw)E&ki<2JG%xVR-zONV(hFb|jy@Y}^KUo&3}6I;@0iUlw@THcP}1m}(q
ziAIj&0|P-*151L3g1sdT5}W*8xxTP3KKgn=Gd_LvKo=O8`#xE@=GV{mI!(@OK+i3@
zE=5iEJ#FaG_x4}>^gD-jy22+hlFjC(^GdOw+3a+ltPA7}MCRcbg(&?^%%j&z4d7Q&
zNJVnzc^HVq6NA*nG#sn6#*uC#tcQf(<t{PFXgAMR<tJo*?>y0E>MKUlC+i}8kGQlW
zSsxC(;ZCVQ|6`G6K+cQ7xp*sTIfSodCT!k34y8HI)rEdW1NhUiIcP87uet=c+Rq8>
z<2Wbbd${t`nd7hE)tg<+&`Vu4?r_8x$<K0F3!FtzPz832PMW5LWG$iG#U!}z*(<)1
zpPyf=K#Fc8_HZ#D$Z$3?4nkc#IFrQ7i}o{D9B@e@4$kw-qM$tt%&&EYOaFEJb@*EN
zu606m-1W5eZ=(lOVOri1rVi%go*m(Ae8^!&R&H67GC_EmG!BcR;qQ!NT-Vn1*7=Us
zd7baQ+ts==yKM88k}=sOTj948NFV-nVAYDH|L;Qo;HqWkNp!p6PS#eogDb$LJZ1Gd
zVkrYaCaukh+Bg6o`E|G&b?z$Cbrm-{pCn1h6C_Y2@|&v(K}CfATzo{j^2Xcn0b2$t
z<)Ac|K)~j-niCyIM#)D<q|*GpBPXs9tZXj50ah;liUd24&qfmnVrJ|%A;tm5P&TK-
zfo9N+3#xU=aRaHrGV`$u-biNz760$4mWlV`Yr}iar@qkNGczIEi9}2X+E{dOM|Kim
z3c}S?$6gc{2o68{J*aoVtE@swR8r8gEfU)lkY+E5Co%_e5}bfyeyP$eZT26tzo$87
za9#hTnML~UmY~wd*R1c|Ib7H31R$O<w<um0D~TyyoYVn|_M*1pw4_*RVm?HuQ!)ze
z;e>2>$2|pSmz-eA84~QxR3hK4PBYH!>m$~=BMw~1KBBvVd?oh-NFZ+Dv{pDV&R-aY
zy1*u<N$>$G+Z0-cRM#gR=W-#-!Jopm5zvAW?_#FReMdu-0af`0`%wM{r`bMYeyCo!
z{o}_T12M>z=Oh=xfxB$;Smpz5Hyuhyp+}|j0^eS}!e1n+G#D1|4yU9k@o{TD?Y&3t
zA(kFm>;i~yrcdm;eEc}`b(e0(TMs`Ba>_7%Vp%nF?k3g`=Zqyd>;jHBh^P4Oc=PqU
zkRSeV=f@YFCTF_PIdqr}1=m601B8Yh=L~R#3z!ljaITmqWccET5QwIn&zp}(#Fx2*
zk0T<2?eOhdw~{Ln)G;WXm&JU|96~2?8P$X<oL01<x|eCF>4ou+PzAz0f@J8Pp@KDV
z?H5bNtkl4U6j|3Q1lNUoVrnN`zFc2j*?~8`bbJNVvs&o(ZpSNb!hsiFJa?LZwN-~N
z<Ev2%m8kEL*O&-&aEQ4;#jU_K)O+L!$k8KI70juG8#n?@na(8r6=EXbi?E*y3M5(i
zoi5yi```Zb_^f8e*KRgyM(4`vu|xgzi+Bt5UR?w8x#M(r-(W8mF9BTIe1M)1$s_)0
zKd55WLwTw)Rqkj91)sfMbM`F%*jZ=~>R|s!UU>yxKYJa*Cw5kk&EMk5R!%@h9e0M&
z>>b-|EiUaG^OVNRuB;o%YCC)KBJAfBxU_3*vxPa?Gv=9|aj;^zxbr9ZyACUJv|nsf
z>~gYO%u_ID?9CP6MT`I4lT;?z%>X(ZYpD<`!a6qdi_J!{62)ejaK{5Z&~ZGoO=2Al
z2bpaV^HBJT%>=Q7jrg-ToHL63VH>;9mEB>U$S8NVHn^}m;sOo~tDRw+q1bF+SP*f|
z&Z-z~Jgz-q9gn%&WJg$sv$q~b8_#sEnd}DJcy(rb!LsNTRx5!!7KxQ|aBFWLSO>%1
z_I804NEg-sk)bxeB3@O__-0$cHn0|K0PARG&7b>y5~JXL--XU^8|;X^u5TT81Pz}%
z51c0s^Kf)~+YF@~ot`_qohHxSyTQ<b*nVW9434J5+a?<tQFk{_&72%bWw(>Peopek
zSzou!T5hkWo2P<P(oQ|+t}%=UwJLVlv#xPuz1%jTd6};Dafg+<RKvNju;-f{EF<XO
zw)vMh>D?B}UUjW)bNPmNOu77db9%OIa`mYCwHXlOS2xhA?e`psxNu>z=+w4Zb6H*5
zLfRkADl~Up4syXkceagGY|)u5go?A*l(}O%$W;MXN4AYPpQ{_2N4<-q5!<iT;mo&<
z>8uairobcX!PW^!(SAo+6IbuG&DY?d@0usMe$83S<&F*h94;LNM5Si+TieLvEqbj5
zZmu@V9n0Z777(5=>9MxKf^7P$dAM)PTC07$z#Vkg0FWt>tZV~C0s7^V##t7rg7i@4
z<Bp_I6APJ#aCMv2E5OFjD^KD7T`SBmiy5>4SG2!Ir5RuN`4nV-)}5lhGC2q!P=N6%
z{Byy+6qD#-?tBtGp2u9E3()+ZPZ>Q>JD&C=z1-w3;L3mqxW&c}b41B@@-{=49h+Ov
ziiEvgJ6MNvUA@KOZ2a8rV0KW{m~i`Z+7|yJIxq3WJHSG-ab2YhV#dUCq>Ip)0s$m?
zWOAKYVVQsr_Tv2;ArP<tyu(MXYzFTMI>v?saIgtU7EZFN##FNjSqUUAAZv~yt`x4G
zEQ6f&JbUa|Aky5F>_X<ag%!#oe6k-O-`tFJ^O)Mo)Fll;8GAaLAhCGq_-Xm6oeklI
z$5*WG8QxIaOoe@39qbn51oMwAg$b!zS!|KnXV3~A6t(iCT;emxDn#PTRk6#!oPdgJ
zn_dwBnzt6t9q@H<_Xy3#H~_Q6w=b}u+Ah{1a9ltcu>dZiFbH%o?fA)ld~$d$iff^I
zPj@sx)MI(?+r~>5Cj_|#n*rw-1<NcJ3AM%&`v|!_DF&eB@}rWMWe+9cM@wn7K`%5#
zuoPg+i%8V~h($R(kepJP0owUMDwV}H8e2Q?Wb@SOrk56!RnPeP)0$f5;);5IpTwBh
zC5u8SzIVgm$;AV~irW{NL4C%s<+c~z>K%$$q(u#=Nw*1mpTF~+6DP26<+y}N6A?IC
zDetp$nwTF6er>!<@(*PYz2Ziaxs_qW$p-u0RaV^zC=bii%pS%co73wqEOtt-vnE*K
z8pk|48?O==yoil#iS=pNu!bc^*p@fQrU+Xya|FIvxfxAjzSPw&*ie#%{CcZv`*1^R
z=W83Skw?(f88_-eTSEKv9p<vqw+8MY_fy^t`ImFe`In?hJ``$@^5NzYD-2*TlL~)x
z&j!mQTlwk~g|yZsksRA}jrlv^Wt;n3y6}zeYyN^=AJnYIR~|WW;t||^^2Es#_>f<`
zVRmbJTwGRHa(F~?dkOWbcR*^Y!mC!N@Wws$b+x)ciFF;wKw)M&ioy%fF0>Q3n;uiD
z<M2!PoT@Q&U(1$F^AF(mX;U|Cs%gM44^NqnvhgeU<xSH7x7@YLAU`_}_EI)yr9fXf
z+r3(<BNVVcH)RU3%@>jBeb{XR2nEX_0AyX-R{RwTc;)nIm<|661)e=~<}7}uzOT4?
z_{}bS<-Id!YLEsgIt*jlxXUrt{i_aNo<^A;Q4Kyu886(YM7hQ~e1bB5IB0a@Q<7(4
z$ERjF3f>J)`XC#-<|Z_KFsbp`FRwm2eFBq*cXf221zlZKl0)vmtBcps9jkhnwHz4_
zcX5+!0RitZ;Fa-aUI_#U(mA+;$g|dzWs^q2&k7lv)oH<|B?p7l14TjEi)j3BEyBG$
z*UAK4b+x&k-eYR(8k0Oy>c;Yua2boe)2GkkyBoe1*EA^0@^U?EtT^NA7(RM)?>=mx
zjLeDD2J{kRtfFcdz6FI;Nf!i@DdVz-wrpuxff~s^x8Gyo><L9qaj<gX;07<0DH;nx
zisfl3Tb*kzO(bQ2wt&BQ;Q&55Va5}Ejhe=aOBZr8wjw^br|^f~i&vu{s@Do9q>-X`
zUg+Pd@5#dV<NY#3wPP){H){yTz-C-Mks{59?B$Ofa0)dt*4+=%5e!|OlmzslTcd-U
zpS3s$xHjMl27lD`^<{g#H;BK$uawt4e6+5#eA>~6>dIEDQy0Ge>YG;RuAwct_ypMR
z-OW-Ij8~+cUcUG4+n;)J`CWJ2_SCximH1w~58$(%KSVagz)3nCdX`!tbjoaFo$W-{
zTT@ybpuUN3n5BkoRmv3o?E12%g6^WcyrMIu)d6|=vlM;>Q{ifg6>ww@<|ZbNU3JIU
z1m+riaC)ivgQv@?19J<S;Dfcn(dfvwty{NQS5HxM#^lDd8U{*qiHU_BugBFTEE*FU
z7?+_;ZQR+uZQFufch29owGBUJ{#dat$@a0JSVN?4CM#B0zp%(|UwHETKnF^-%K@T6
zjU~Dd&@#euk+jBw7@#lPa0GHAK+J+r0XHQ`OzQ@j5<DSDhhI%u@(j{ER|)?yUh!Ew
zw~vYIlY~sE4VCnvQ^&_@=OpN@tAnhsA*v7ZO1>u)HeRTyne@c{6I<J>4pK_y;)3MK
z)kz(c21CBd=?E|;?Dqz_dun9*y3Fvg<n3`2PQ=qDu36KvuKiG9cteLSx2kOM^3KRP
zv$tdf)h|h@VBW(&58$siKP#XDZApFT^TERG)WM>4xk++ulD?>|XKaSPL$|ar)=!%j
zUjViFq}Z$>Frb}kbJ{z;0QXpX$XQf^Ok`WW7{D$ky=K`iIphiGBieN05r+N}VaPG{
zO5ko4mQ8mpdw$xC;=atOb2DenO0Ta<?-)~C{#0kh_>ILil#jgted28II=X#TH)LN8
zoz7odpP5lNSgAKu_oqLVTiCuoS+Q&#2-9`|AG&Z@bUU)Q0^l^tgc}y-^M>K3LK_8C
zL|L+;T@MAx(lk)*L&>o$H^I;92i6zJ4ikZ?L(;VzS`U#{1lFNUyA*iMELfm_IcXmR
zYM3RsYTL(_ri|7-$^UA)Drr(uY;=5eg1QOcJ|inUab~?XBP}KY&4`Hg)Hl=xs-v0O
zc|&r9@L)<<l}Z&?Ixcut%D#%Ubo88Jdu?(;V(OF?ss^u&nn}e1d@(D1{HjW?qKxA5
z!X?5&ed@TS<x`W!6c)A1im2vE<EtiE`J4K}Hz+r2@)X0^fIFFA5Xy)N{|T*AgoQ_@
zGOyLjYCc4F_y$pfQ;TPW&ad;&jmipuPUP9mu?ON3jU^9^G1N`X$lfd&w{*!=k8uex
ztzJ2m`q<zUer#n$d`w5-IK3)3UK~%&TfTIe!`|?NyD+SjA-bzcI)iW~yV;C(GtzDR
zWkcF;tA0pZvc&NDDv-|mO9Ge8jD)TzK5-M&1JlMPEzourztWbMV_oKDlZbA|-P4gC
zuh`o&ExfaK{Ki!+(_;H-CnT2~9`ob45~qFO2YL-;4mh77GSXlGddQhNHmRhvYq(Cd
z-3DcWlUBD~dS@g^@ZX+)ekGN_{DWMx<#<N;v3y)M5(E~h$F``pY(Kc^3D9M3ykvmp
zMOuPA^WW*N;k<uh`J%;T6SfR&Zfh$pzvIqb1-jHijW#wmN-fRQg$E^M#Y7nl6GvRb
z_uct9S$RGC#usmCU7MRfZ+k%{@=vR%(8Z^urKRB8#wEt66Q`s{gh2!s7Gt+p{b09p
zq$G3=gPvh5-N!&hCbSYYt&(gg()x>C4X3G<Z9y$7#>`U$>D@~6gf;l{RjW=GmEZP2
zV_Wu&vC*msbzW)Vyf}yno>PpS)SjPdTMBhHAaI$xFC7_X+<DK66;ozBFtIBmCBHB+
zy)gj&wC<y{8IxVW9ByY>aAAh#Q53E6l|lG}+yZEWuW`ka1b=|9EKg8_)k5u^g<B__
z#P_1Bn^&#kf|G>$S#aifPsHy+z@#6|+XSFF@`i@Jm2R$$H&|JvbC6Xeip+8b5lo^H
z-zAWa{(b8@1j(}p6#vGL@|8J>3Hl;!u$-o<;?_+}jAlM!-#JN#<yqcAlh}6-tXjo<
zVEJ0M-J40#*0s|+H*S8ceB&B{cUN;kL3MtAu|5^${ZyG>V|v}qb3v=!>x}pwine@b
z;VirNfM#wEe5Qu_#__x<aQCToN0T+f$p+$|L^EysiA9;|Z?ifJ$~K&Brme)jOWYl1
z{X$^YvbZhJZ1@V&rc9eO{gG)&QFvBlYEPFgQl;zc)<xpVsMP7NYYctqaS}y9r6N01
zsfaI}mZ+kB3J8fUNKXq5#4~2joHYYaoDv@-_YaP<>FxCNIpb#H!*u)fGW^dyy(b>+
z+kMx{=byhFzuQ{Vj!qn0^^(S0rImV>G%cA@UC}b(`^1=J{C$FUJ<0(C?$tww#-`|W
z>98A}aa7Ekz;@HWIUIqkCO2x^IE(F>#~ymD6+lA7?0yDq%#1G!wrm(m(k4%foW62e
zk_PVxiEU_z4Ke-3cdO<7K~lj#@L&CXnrp`9OUJnd$)gJ@V<PbI^yoD2@rHc*bHBjY
zK=0Z3o{DkfDr~&OLC~cgOP_jb>5kpYUwC18VO>??qZ#UeO)Gqh5+2!6*!P!Qky}W;
zx~QR)iKJc$RP@KB<LgP<6#Tsp(&1<D6OKAv0CbMC;znbyQAl;{HG5`ZYh55ccUgJ)
zU}<i4(csklWy^-gYa>*#<JVb%y{s>sUAuPe)H!33jQQfTaoIJKb08PkUYAsHtr<Jz
z16-#Z5fAnL)^MXu`Ut3s(+^bV6;Ihcv$P<rJ8nT^TC^&)eO@B-+7f&jss+ThY60}z
zKMyQFb!c#ZUe-**#w88yE2b{phJQz^@p8J|Tr^;x{~ZFpG#zM+<y_2w?ql6rr0p2o
zPh{S1=F|aJhbR6Jl80s4O17s~^a(Vx0|FA_RSgeJNYJ#zhson{t~$MM*FD{OHO`uT
z|8)4D_V86i6=X*T`r$e9i1M`LVs)Smzs+;+#{1~@sin0?(~@UR+K=|%z33?2erySI
z3T?nkU{$2kQmiHc|C%1RdBLRHn5`@7q3=6ar}Tu1TH@y@gwF5Ha6d`6ZLQ>(B0mC<
zBQ!LYl@oPRXOgI(BswdDAeAjv9l5g_whM?9xym1oIFSlaK?X==TM@!l3WT<#sFwIg
zEN&|5dUZAOe)38DV^!6IGd49g3^!8QaZ!fbWeF-Ty)L=fKRHIN>+uiPyCo&16a}Q<
z*VKzECQmBg^ND+YLco^`^Yjso$CK(Os3JqIc^EQ1{+*GZT53fYe_S1Yx%#iD96#~w
zv*_8QM~%Juu;AMT!n|-_PpLRapBxg{DR56yNIWH8!P@1G<0|I7R-8L{>==5kC~;;)
zM1J}{y?$=$0=R#gi$hWqF`c)9w+6cAKh1lVcNXp;vhF3b_#GWvCJ{aAXEemqXhNw)
zq>uV}@U0M^+)a$^NGn2bi#AUaGFj;((8OyE%Vm*?Ug@dHMHXVDyCs^4@k)G@>0Q^P
z+Fu@{oiwhznv%1ls1xi+Y8l0N5Pv!6Nh)&Gv7T4=R#aD+$&NptGzqOOt0*t;A~d&>
zo6aZHrQHd2B|zPjkiag1yFP%WZu%(ic^uazRaDNL$&4o-;=8#V0PR7~;(M6Ck1~#p
zgU}fyn>A}TZqe%<^h9sS0LtfZ3#rZ^Jv-p=1~PC+XtKFrFO6V-*@)zGU-^C0=P$qu
z>kl?G9IVIVRPj^OV*ElQa&<Z7IT;x_5iyfn@(L3&@^jieY_<fy$v8|eVxFSPj5}@O
zgIU{DGA-OEKFQCs@%FCD)Wn41{uzaJch4DEke50|3{GHs{}1syrt)$)D>CUKj>6H*
zn8eX%@@=r54XePkttJX&;sXy8nHV$u;B@#Om&T<|s7Z~fmnsq_)zcaN%Ce%oVs(&}
z?$j|CVvy;pDXXb1n@+7{?oE%&dXSoeE9O_5B%*yBPXuwiNbqB&u@NDQ2hg?(vn_0~
zfc@EGG9Z~v#1p4Bm?o@)+qMvm+Q15T4IZOOZ|~G=H2SV~y#^N^C_mURe*wK31iU^4
z1U$}a&kdEf=Y>d}mo&U%#Zyn-zH3MSiAM)exP@T2!YtfdQ105vE%>obQ+dEwpZ^{s
z3I$)R0Q?AE(9cs2d2XSQsjOk|57&eLDIdB>l!Nv-3G~Nla6i>7-ds2X$en6Dko-i?
zhaaLvgGRuf1(q`byq|V|+j@h-t&Z>x7?BR|+y1tE*D@xVL$0&*5)EyO*?x6s=xSRV
z4j39jU$wO{F&j2eA3&q}He=?{5Phz#?Rq&pW^HbTE-ahS+;-}V?J;fF>SEfq^G^&7
zUDvj?(O(Y@8KFTwb#222Mo7L&c?=CPSK8W8(9qDYo7*(B1R6sGHuB$0fH!gfw&6Br
z2r50=jCXIxgWKr3wrkIA=a;r!*O?kdT#sr?5M(Co{_V9ke%ZEb&$ZEY+pZsPqvn%O
zGed2|+ws!2w%rNTz_o$Qf@{Pc488&Wvw*)!;Qs9iylP%8uO4o3pAGkO%;$B&J?;Z=
zOUJEJfJl1aR&y`Z|CkIW@1mv8#Z6Nqn9~OX?fVbt(QIv=aU+@-ldL^8jKAF+S?G1P
z<{N=Gpo<QCY!g8nn#$gUGY9U%A@>k3;`Q;C-!e^rv#q<qtj*d-=q&rm@zM1j5#1~~
z_)l6WK)+(&GGtNTUw5MVo82WhA_Z&*c3a>T+~y<i58Qs;cl3P%`{PFPDFZa`B3>D<
zlD$=y+)>^H8fq)AowtzJf6J6G?+!M*mqU~h#FT6Fo01bEZkh_Txp^+>rGh#v6uAW%
zb==f|<wjI6UNOgujl7%N4%7?g1}-<+3z={WovRa~1NOtM$|sOba`qqTAo`z@;HGg;
zJ;?1fLrHEO`!~Y+b)C6y4OZVA)`915gl_|APKCTuh^;$Hpq~E>-=IYPSFruAwHFWi
z>W@b?PBFLjx!GfwoWD21HIehKr2GKfUVW>)&E;p4<!cQV+qw&}-bfb$$F;DzX-?<J
z`mbGfEjsr{OZ)3pj@^%pr*A0kZ%B_nQr2*MMgI+1bIsDr2|fGAGyiqHtuNFc$^U;O
zzPTwS+`Zs}+X+4Xj~q``S$bVj^ZpEcbMjhn?jI)GiM;uv&QdOpxfy7G4!&&?hQj8q
zVCdu@E>upN+lv8@k7{DwjBF>Ct*cYC3+`XOW!Y}ufBjF_TxgA5uQZzaGg#cA@0#(x
zn`ZMH%5lQyxh}OB=qdoaA9(bpy$Yt>MlQGiIUG)X#P*Uy7yk@gle|hCcGC#Hk={bQ
z2F^B7H+T&o!S)vM>)a9Vzi?dAGaP#Dq53}q?XLRv{gLPAA1h-x9RvRhB%qAkUWDk(
zpMrn8zJ@oC`5XBKh=t_rv+UsYfQM$?E$;y07qBHfL0tDgmG9QPW^<<AP3!OUSng#E
zsQ=b!LEmd_@CcU;+{kV<e#g1S!RUE&a*2Az)*y2FjeR%ikTYH2(!1IHANX!8d6EAY
z;+O-mH%%1^n|oQJr~d<jG@7odxDhFsJ57BtZ+3IgvrX4o+|YMM&ft;Ghz+;AN4R^!
zxjW~rnYI7%HnAz8{3M62pMy86i&{4ddn?C{sAF+%8o#q|9}0VBR0Y+tSIoC}+(@2{
zc8=VB>$Ku_Ed9T17;`A@rZ)^t*)A5Lj{OIF#@s;lMpS`_jO|Ji#^dJ17u{v*z<MLy
zYBEH@W<vJ5&F4P=asAbBt_<HYB}^xa-WsuWkuwX)S=_z#C+W5ya(cz~q}h7KW-Dg*
zrB$I%Zk<*)qLEQ$xqc;48fSO?iX<i_v53jLIjY^*hc{Xb^Hz0X(#!y|8~+;=xoqyG
zi(dZYagXEJw!Alcq}&+C<ShBaY-x^m1>J^hcii0CA#&3~$#!Va-&nd1pS{`B;znF<
zJs(=Q-HQS7qn-{ow4X<dd)*>WTdFRgIOxB?)^s@cLLe&bPvGr?+`EKsp2cs7^Kyu{
za5Er?HPH*2>T;0%w}^9+4l?qcMI8SBbEG}}7__SP_L1hMr$evmK@V^DBE5d`UZv10
zJw5@g`*UbQWhT$J+?^D=Y~a$v$Cw`$X0N;W$nigrMt`Kg+S-PT6g>R-G?Ci(@}}PY
z<H-O~0{g3?-uk1?*wJjcTihGa{lIc3)t`@a%G&FkD){5^jSq6$rr!da-%u9)fiYlP
z$M*jMms9U@d%^!HVc;rrTlt$tw}2<Xw~2lfN+1U=4Kl1cc}sabxZ+7`AQwGpy%ERv
zLyG8<5J^_HJc}?Wgd%ymK_QZ}DYvYv$W*Zdy;UJ0Q$;~d58TvlD(oSjjsTS&ZmWxu
zN@NNO5*u~t2GabD6e>ZU^N;I2?j5|}cxT178u7l4){=^*n(pj`uEtHNqQN=yO0(xr
zY4<2ugCxhjW)_Xz<n_VB)c+`y#o0}nbN!~KCq$Ha`c{NZd-Ab?rw=UZ@P2%r#v@QP
z7!`>E1Nqn5#wPSntlm&Bq5VS9FR2NJ)Ug8_uOxo<PTD7z`saooU7VBOvLHWG^p1!g
z_7)x#2sVk8D`nJ!bkOR6%bCne`!~F*PYhTW9$t(VmWL*J39!$*Wk=BKo{EhMdXcuS
zSb4DP%?M;%{mGk1jZ#r@9KM9l4Noh}o9Y%2n$k@2`kU|}(E-61(B(nI-X6{)_1!e7
zpC%<`@SN4I&Cf&!uD&43YyNG$P&vrFOyw}|QYVd<txsX7yx-KqrN6C5hocA4uPcq8
zu@5{LojZ>T&S%RkO324I5hDj)W3_q6E@fi~*4YHx@V}PzJYK!Gr5kS;BxU4-XvrW7
zw9Q9<`R$W;ZYW);o!@)s_xKHzJ_r>PZ<8O#xk(pj>)cYmIHV=Uo~1*aUMSG=H434?
zl=WhRU^DY$%d63A!ity=DJ`x-Cl=s`^Qm66G3N~aH`<F^D2WXkY6U*Js8_5*32pyq
zJ?HJdz;j)7rRHy~|8T&!jC7l_LIe1QWP2s#RVrmlsh^MwTDk!!AP2@)+CZAyVO-yV
z{?&&r$1(q|NZ%JfE@L9|1r>6vmU))?=h}mmzYQY#o43xRyuEvw9DK=8-6x7g9-ZT>
zYg%XSsD}$gAo16ZK7ml*k;Z{c6a_7aV81{y89+hNzGNSgS7c;ULSuaZ4ldR}N@%ig
zgYTWntp~ULz3i)v%M0~XM8e<@R?W@MS$wthi!GBMo;H7ebO0`*;(e+Xq37_wCsa<g
zL5s#rtV8Or_SQbYAPLHCYsOFDAMuwh8ILZ+7p9y<y5*1Qn>H*t*M^^b`8jG9er4NR
zum+*s8oZ!FLP5GISn<nB5FbQ9hWpi&Na-(^2()UD3h<W=>__GV#<xbVn-dh*7X2Zk
zquxffm_~U0TvSgnf8#%F1C#$kZ11?Zs)u5F$Hh*RuEJsBL|pU4qGf1KmK4%a?DrO_
z*|5O^Gm@%2+pJN>MEd=i*E{*!IpbF>GG1Ebuy@9AMj<-~7*=htkb(V!Z}*A_-Ub;*
zn1?*rW*o|0^7?l;ungUEDRyydYuu%3ylowRX)-$cG=3d#EJlX)(My}BmEC(gUb6P_
znW*KJ=Fo9yM}7B{@C2y8v2JzRO<r^F;te&ki{}=M&nllhuxHu2hCRPMIj*T>OnO0{
zu71+8=|$7#|D=x|2Nht6dbsj{)JSvXK_ukT+A;-gSR(24fF-?(@R}CDhr~>|j<oLp
zekA9BN%W^1$OlY2M&}P=gnV2tCHzUgLn^}HBYF{hN|!DpH8JobFhAN5^88O7_!<&+
z%Ti{~6D&aPlRFL{{%I`VKR8pLP!KsIC_?7uc0m32<Xl~`x-t@<4_jKjJhJXYMvI(g
z!sB+I^4Wj&Uf-DeG)tR08c`hlvf&8*j9*1r^Y#=L<Slzdk(sb%%e+0bx~yk?p?9Bh
zQd-)zhFqpJtz@1s;n?S072EDYFUFT1K{8dXaK+q$+Qai6FcjzFw};`s>pS5;N0|n7
z!8R^e18x8TYQkS8u>tsi96n#$N}sI4MK#e!?tW(mdaD+M*~>lxhT->On(u}_#a$H~
z!1L=~Lnq%ld1z|mNi^6x?ThyIYlW?N6QQB~e)EA$^<cKsw^h0V<v^Cvq9~1luVGme
ziPTyy!vcByZD4g?--4J9O5`?UKK`}^c`#4U!rzWZ?(^w!<@n5(PvG^XXxZV8$+N2(
z7G=+=>Ur4)Cx6GhGiPvd=~F99*AyMzT)X_B@l;#Qi^sa#YmWE69rx7y&4<(8Sp5Lh
z7;^b847yy$!%ZQ2@RrzNkb*4)_#<sTf#INnO6e~!6;mle8y5P2y(rbCYk)mv@MBxS
zkt+Pfgckf-Im*qze=A3_9^*9pWg_!p$Gsh>pPIFq68P2Jw@!*P?!EV38}vw4|0asV
zr~cCLAQH5pcVB%Kr?mar*x5;c2F2JdJ;`T@`?NhBg+PJ%Qn&*CQ-XglyR|5J(SUv8
zTjR#@ZL1<3TVORLlCLNG!z2{oRZxY9_<+Vgq&mzbA6emUK;|t%9xXov3%2z>{KApz
z3l6{ic5U&vj~C634W~<1y%4A@s#{Yxguic3ojuKaI<p|5Y0k{6(I=Yj&!fIs+r9za
zwie%W2O8MWafb~9bmzxyZ6CMYQyVjR`}ZkTNo{{;WU`2-oAu3)YVPTZpjr=WA81j{
zEbM<cZ~F#x?(gs)KK=2>sKoU6@yCD<ksUsW{0|5D50&(`y+IagUK^?L7icx0YryRR
z<aP2}u9Cxf22bEk7D+^Iur*oa(6A^!{N42xJEz?KO+;H`uP^o0z7DJgC97kF(Z5+b
zr)f5Ic53m~pQ4s@L+_jRF(+$h%<1sMh}Zt5`}8%o74!QF4pbBu1br|wapyiJJsww}
z-FM8}NYhMk6v{|DwK!!fo>+RYVRn9C(x&{|RLo20i`%zX<Sk#{)P_F6k%HVxShGDp
zD|nH>(P_L4(*4M~YLEl$`2cDyIRR)tAEZqck**|!i)p_kN|A2Xy+m-llYV;Er3&_4
z&qIxw^$V(-KCRKWCX7Wr%XTh^?DMTyc)6qFr#qX}+e7eg9q7{z{2LPC-#F`AKX0xf
zC-uQ8n=)pX8pm`aG#?4H6vK2;I;O6VLals(;xPV#&bhdF@jq{epozUaA+gBuP-S6T
z2az3waZRd+L8OH)7_cx<KVVs=-x_wIKtHH_Cnp}!>){)~;%0(E_ae|&Y|DGS0AIiN
z^vAjHJW;F9Ur@ed$z#Dgls#{x7ZxoU+p@H5;jEQ&-gyO0of=m2WJ#@GEMDZTK#!(A
zxQE#@_uZ*)%<XJRTF@9Y<*)Zsi}By0>pE=9N8$5QmMltc4r`rs$GE%+6JPR}Lrdq~
zE}IhB+nKW`zohCfSw9a;CVFM{@2u3N`^RWn7q6bnpZW7}*&Uza+IwS}nN(4Q=cIb%
ziL+-{6H+_ycNE-lln7N@(5uNxX_efp&zi^yTivAB%0c`?c_0v${Ltn{8y22A*!hyO
zaG8pUYd>@d9b|ssZ)d(m_aDUH;df9fey4+I)c6hC>L{<rmUQqncjKo}SsN8Q*w!}4
z{6D0;?>_v`r=PYw5}57v%3$bJ0L5oEc!4S^xdccQh*&Dhl^WnyB6DTrViw2UNMskh
z%i(67Z4svrckDkt^T4Ioiw}H>9%T+QYmsLU7UQ44`6jcsVp48vNBz+MC+<Dqn>e<{
zQO#CKtFo)ME^?7&TkcJk<zB!TFwKAs*e3L1gAJyHmQVwPkOm3d5CSPAAtZs2N`N#%
zE-9pw-V<_@+)HxPE0!kj%&t~8&i(%Pd++z&@3~03vomK-n=@z5%+54j-+uUK{KYdF
z<x__Hrsky1P0rliM-_cI?4-WlhYx*Q_bMEK`$t@N>qVI_-Pd{b)p*SMj?(NAD;t-N
z##_+ht7na$d|Su*&iO-pBd%(`EMvwfLhFV8UM9Q+(MKtHHNDSWfwt!r;V8O@iGet}
z2NZRH;Q>O)n}oz~D+%_Id5<WM9b3OR{t-v1#IV+Hj4@M2-8LQ<$~6BJb!GUTy1~9-
z_02uqWh;lTS+Xe?U;S$L{kdx^s;m0ZS-$0#&ql>wnmKpqu%|oFM*R4E{Qcz%r?y^s
zwqp-!T!4eqN@GV&npzS5gvu^#oi(^~)xu7s`%`z(W!Ja^3kj_k+8wj9x@nwl5{%aS
zXjZIhWTXJs%G;4XFhbEbOGXaRbX9q3?V7l3;IO#t#BES|B^dTAj6z;uQNOn9E!*=z
z`75Zf=H)vc+-GlQEi>mm0vpt1OrBEio?1R@Ok2G^qiNdmJ06aSof62pe_?56$>{c@
zGbadkG&E`d<))FV@V{%qxMQv>e_9#7RT?^Dh(sUxN=hF+vyWF)=7eqKtqtBO^#^Wm
zbtgD-a02>#@rs(p@;2MwZYz9fOTMAvmg4VUYRK|7uj%R;GNGlW?r*5llh*j&k?rAg
zt%nx0Ox_uDVzKM;%bvO|d;6nQXKee-o&i2RY}TZ;38Md`(MrGr;=ek0q6MV=D*t_Y
za9{5X^e4U=Ey4fFx}p1fS9j76-RK>hNp{bpiuwrnvI7-%BGZc7D&9fWp5j%cJ$K-r
zJMpVTju-mj#GaJF8$9YNkSI=|n-QCvPJ`Ym!cd$AkY9;J17c2($h%-uLl5|##EU>)
zkQ8wlWcVi@cOTwoVuIH!pZh?==?N1(<&Ly#=H{Tng$Y#`WoFtXIK4Xj6?$uLL-=7l
z3O)4C)Cb!3XJ*l39`V5Z<Hq;NPak0@Gcho3@3O_MtJXaLhjqO;_pt}+a;Q0j<I-vx
zYC5OFhMCWIevM!K`O?49Q$t<*t{gJ&J_#Lrb-@*A{pQW*w{OQk-FfGLK1YWA6f(#j
za+);A;fdfislUXR1*s?$LJNkiVqv@v|9!MQ6n+n#AX~DB-=?y<Dc{D>H~f&{OGeKe
zG=yH)jlb%~pZ4L;oNDgqXztj)J)C{nf{Xp*3MS9!M6>bFx5Li>yO{+06ZIdDD<}{J
zfi>CW4S$aWn&RTYgQ3B5B|?$Gk#p$4SMBGVHW-78^33?=>Sg1*?(Ie!pES;=WXd+`
z-1>?5(Q$vyn$k_{4M+@qd~ZJ_-*{}Fck#57i!1Pg=2`Rv-2Mz&Cv>k24WH73hT(4>
zn7ZzfyHSR9+_0v__*OK5iV6Rd=+%Y3sp^SkgQrd6q}uzdeOxA7gnzL6z+upS<=*M(
z^UGB43_cag(?|p_m=;klU*x+_3|DrC+q==_3((fF;cPhioNE3B1w#*w4c;{LGNz*b
z&VLMjJ@mxz$ye0xr_68PQ}^@<d`s}*F$YTNjMJx2cmMtGfA2^C@GaZ^xaz9VKJ<0V
zoH;EhX4s4|BZu}L9dlJ#QzrUl=;Fa6M};rFJ9Sdl?$7ZLA2huGYxd;Hr?kI;J`IuM
z7}yJ}k8%j|kW*ZgolAU*7v`uyMX=$T*5G`=3*yJX=@!rvz!=xds{t#86J$+3=_Cet
zHTTA~&tCYZ!O&JeX%9M_km1#DYPjQ_yWbpse(i#)M(QHlLpO$x@4wA<?a;u+)R=Y2
zGlmS_H2bl~y7r@Q@t4&jy86*S_h1*&T~}Fian|U`o4&vgCawxyHaqw3tLmqX=~;Vk
z$L9~PqrSwS1v(4`u-9NMn$LOAs8rjOBrmG(L<amDp0=-g-oXAMr{7w@K3+ge1E-tI
zM{-eB<Xw7o_)iog(&@vpZU^M?`eavtc<4cm15WT2$dH~GoWE+s3wSvyur;Q1rmadl
zx!`0M%EQ;7#ofDehj+|QSr&S2PjP0_{LHnf#dC(9ee}`p>#x6wn)l2z&vc(Wd9oib
z4z3H+Lv4CAA4#`h3^wOgdg;2(Lx+ky74?nbUrO<;>|s3HL!lHj!|9ti4yARV82rzU
zP=$ZZnxC({@@M69fbAFhX#?1qJ}sWxdk-_AuXdUz=a5|JPpSKW^y6Rv+RwnqQhvxm
zf72W~PB+}uyOg=A4<hsM;_#2%;n!h>_W-yP;jMB=jaotQD<jSe2nKwx5(xN#9>U-V
zA~9+_-d99|@ElQPMKeqC)!7U1;v(Y?C+M*f!t`tH+LPiVKok+W`ceM+dq<tNlt5zL
zOE0yi;IHY#Nw$o4-m_69>FoyACKQ>9c&5vlGP`x6JCUL<eyZyxrZR3i??A11qaz({
zscU&J<e5BfQS%nYl@-o;d)~EU=M3NR=Qt$y5l=n*MK?8<i+{6oTxG`a%vx9F0UVpx
zNM%<TA76+@K00+*%b-!S7d#y9ICZLV<Be&9YCB7+=T5G5qfL#wo9d>AG8ZhkZo<e>
z==RR=xk&?L3cK<|c?a@P`f{Bbk0IWT$_YsB6ZXBmXVAa#M_q@eqtem%IGW;N=5aC9
ztKpd3MCx69IeN1Xb)@S=TVK0lC=$`u&ZC(L!!PN4Y<MRo>M=l$GDKvO`r!h$1bPGy
zPkIbLtwj0BWgi+t7vtL&;oIoN=*=ZGI-}g(+*dPIJA=4CbE!)ZhtJ~{GzdRQ{s;QL
zWVeET8~~C*#w556su77x5kAlt)V(J>H+ML-vpf7<cgM{wXm|&{32lmV_9U9AOTG$!
z*M|kudfkffys1;En9Jvn{TPktY}=oFcQEu6iIET<To?yP09^j+&%j&vV0Zma5*uY@
z7o6e~Bwje_OIcom0FP#1BI-#TaWCxGN(RRl4v-&}-FcJoyjvEb`0whz!TTtx2yG8K
zT-~^(o7xl}dq7w}%iB7-y=w68x+6!r_Uzd!P=kPV_u`g*ByC-k*SH(4|A+6I3D*^s
z79I+*<0nzqP920VUx-i-O&6ey4A(_@@o1uIQt%st=pQe+<lK6QGhaBj0;f1cb&rP@
zrnbfaL_uA$IvP|vTBqXLD4(u=!;2RS!@ZwApL=M|o2lYF%6ZMa@V_V-&q2Gp(G9qh
z62sq<@2YuyxT8xK-GBX(VT<3LwtL^=^>OH@jx(Km_jaD?c(C(Z0|oN9a9ku`Fk*#y
z4xVs3G6e(Xoj6#^q#jA)AwU!9;(-1A(0mAg?MWSUSMvTKzJ>ZKJpX-tLQ<9^JG;(z
zQ}L5c$nxQbi=KO~pR>q(7}{K)Q;4Yf`Sixl@S!pIx||drg;1v#6%Lv*j`UWk_`^>8
z<%j`en<VgA$ZAir)}$Y2NvtTK@Rk@va9rS5ouBMWSNbi|F_G<?J)}<$x`Hs@1rs|m
z2~!6=ECfUQ5AI$Vv#+zO;qavMBVKsDi^Nkr`>}pR#YGFs@0f75{&&PJIC8|f6#Wo7
zMh|_h=Dnxuo;Vo(WyXCOw`Pa`#atV9T?w;0Ki}3T8~Vi&trwp=F=6J271wm^+0&8j
zxt<wTpY-wRakIvEZ|V5k-#W7GX?WV)@bBZdyIW#M|FL)}i_+hjd-AfvnQ5e7xG*N;
zgndZJ?pl3(Anm9M`JKdTsUb6lqy-Un5Xw@6ghrxt(6je5cGr5R;NLsDGM~z^*3A!f
zcOl%3{tQ>o!e?s{nnmaJE~4ys6}<|tri6a9?A^TJ^ONbVF?ZjMY`5HU>bpzYIzA1-
z<{&263*_g&;7WE)A$z9u;R^gGzZ~-E>@u_lWfn+l^)w*aX9r&%-neL9?a&)f;kBdD
zvA5>sbl&~Mv2ZhWaQve1EsN=T`0R(+?r8}lhgA-K_(vR?0K<;5VY%xszhPN-=$qE*
zlmj38<dcCmNqrlL>>$#I9pRBOpQHLV5SatlPGu+wL3<!p2aE(=i|8Bii9omfWPlwc
zqh<1`Ol_kJNO=S=K%H`Yep*}Vx|r~I;MLc2=Z**WWj<PfJKlf%@%hNw^~x*ng%*q$
zvtrN&*T@m8>Mvb8ec$*a_0&W7hkj&!*AjlBC@q_&I$7jKXYn5=@eNg_Xx2%j4_`yQ
z-_p6YqZ@uYw(e-?s%sdGmyGHeRo{U3;r(|FK7;IN($=j5`X@5hf}K~R_KJ82+LWvs
z!h#m2BeRQ2puj^YyU_YR77BT6)D=6I7S)Ze34gIT^<_Bkpbfu)S{$hh#3br{{6+W+
zDjp8Si_TXuH_!5fQ)etR#9f15r|z$QV-V8!b{5<e+t7srOP8M80K2#hz%vGReopR(
zr`m#H2uPGX7AYe^z>SY85cBG)LpjG&aY70HZ6ci2_uR!e8GVXVs6I5%#O@^=N=7l^
zw_4vsCh7)!<g?H4BWKSJ=)crH+zailk58Z$q#xJX8qr<C8tprZ2J7#}_jKb&mY~PG
z(W!3O|8){R0QYDVeyATNzc#~00N2i?ov*xt|8e**e&@sql&O9LD+bs@vPWtv#Fxn~
zAAJ~s<`NH)c;!k|8D16y^t2%ze3M^QbBWd}eUCDk3}ld?b05mL4Req6dJ3+~>i&0k
zH+Tcbx>0L4YS)KOpmq3tFi!7uzxgIg!5^dX!@BXrE@}gO_9JH8+&ClE1y&3WWlyDp
zhZisYVAZPd(wReM)_1nHcGk}v65ik1itaeO680k*VBfr8+laOAqe~$}Qsd{5Ko!g(
zs&Vwlvmn?uAObvZn76-xlnvdXM%cTkvTNMR=Dc@P=d?_#8@hdBURT~Ql)Qd^xV{H<
z+wf^Bgb#@5_*3DJDNjpyP#-DuQ3%GGyGK?xU6DAgqjdN--=(Xw=FRTyZEHjKk4HoB
zW8+cL3fyuP%*I_9$4SuT!dScHFMbb|jbQIC#Ug`gfg?o8SQGYriW(Xa5i~Lg*+5v<
z1w*Mk1P(tK6{j7XAEIJ?a(Xze`^*v;;k}1;bnhxzUg*ZHZ#}jMkM278EA<gRQTFX<
zerQW(uvEXka>B$GGz0gWRiyOzW5---GaA<!zPB*^t@m@<ydzWqTR^?GqZ9wRYZn~R
zrvFKPVk%#o^&397%Ug+_!w;^&^)qIG%!t3U4c4su4lTu}>_mxtNJ2pa8CSs64Y8z(
zv6LvJx|?eMY(qR`lM(p4_;3SR8`6Nr;_pVkzUbny$cex1#{WjPm3T!fn!f@srnqiO
zhu2RJeb|5xqp=P6<qUju7|LQcqO4)~XlV81-8bz0Dcsu$VGo#*IgjVz_a=OUdOAM)
ztOM^1JvR&uW8Ou>hT*q+FIDY{hO;_qi-$xNZ^T05(8g{55y$Zt4&izq_>U<492w4G
z^M!R2|Equ9<m@VqV^A|0m;A?C8>34Sdhh#>72?~;`h@WD3#(IXr&gaGEPSzYW{g&2
zq}33S*u5Ojz-(JuWW@p*R(gUmA4Law)QE3Caa}tvv}Hc}b|Lyc<EJsRk#JSR4165I
z47W6(NoO9rZ)*zPk9I7dF@?IS_f`#QCL7<q;<h!LFAyM}w`UJxVHP&!%bBz0OljHt
zY|`wwD=WRvjOqBi@WD`if1;?Gm$R}!imEN_qb*jMVa!#mhQ?EnCh>OQmr$s5%j%q}
z`l)d`63K#W7ieQgxEE~=ok78Fid{W-`nHz4!krD>lUMwsC$saSxj3MaL|N+}n0e<!
z>Tr1f1ysF%HTIxS(7NrtpHw||art$3WgJ?PbIIYP+t&Iv;N1Q+A>s6<u`^$|4pvcp
zrTXX^UBpALj_L@|^MA`n*9g3Ttatu*?z&SW?*f`$`d_>5p~d|vB=R!$(|s5CgV`Xf
zvc3ppv;``jJh&g=jYG&ivP^;O{0-w&WoB6M;lT}qSexQx(GgohqL4}u7QQbaxyR&R
z5+8%RbEnL?$2;3awGGCf?_UAt=A$VKTpjv^o5FkAYxlKWO@H5OzL`F@C$w(mzR3^F
z->0#FIdEV1y<PWRz=^AF-xyooHFa*~-tWBnh2dA`R6TmIWUgmS`|EO3+r8+@x{Y({
zM)Y3NjT-S0aDCoe)VL7E^sed8lp!A}KZG}=&roH~=`3)%#WdKbYk{(U9tM@Fe!2{r
ziBc4q7}&_@4BTh333|{=mP)`RIj~M$fKx)oZC)3Q;>a2th)lyn=rN($D=T=wD{#r+
z0svE0V+`xDzznFLPBM~G`XAsX=dEvV>-6WtNI7b)LpQes=Z@>5wlsPMTMcPT64yJO
zLn;$(PAh-MVEjfE63QQT`s*7q=H{?t2XCZYu_MOLMoo7VAOFr2_dQ~5%mT`a>OQm>
zLa#N1ilV$Ou=BBY6Jk4ZcD78rXKwiH`t|FXg{uZt4qp=AJFLImf3$K&b!B7tqE>tA
zdujXKi)p7czG4}EamtL^ADV0_6?m_&YC3c>!JDRZuBy9l7hNB&UewT;RNXoBobmJe
z&f0{|RiRJ%ON4sAHlabrA5NGJ+Ph%`+WO|3#1-r>A0B2U@}N~#M)xAotc}v=DQX)~
z_z1lp;kn(V#F@Ml9hpJXxUJ2kDceGmDH_$GR-NiTKI1PY?q0HW-N=`lrX*1@{!v&!
zzwAkEjN@a_qKW#go3Ly0$oZ3&;vpIbDSh)j;~%M_-LDH-*(q(|Z-}d={$HTMy;GYz
z_8)0(x^4?~;^>HBiTFG{Dt!JF+RbvCHg@87F@D}rx@vHB6OQZ8qjwHm(z^6|sv^Nu
zc;&Uj-$8De!MX0bFj)yj_>_$2@Sk$&uuC%WmOaqIYa)9z>X4}OB<m#QlkRs-#vB?m
zoZ4DTWlT<7RVVmFYLt@hTRM;yVHW>s_z3j&^TJ0cShIotMm5d~|A4Q@*N1-q<?2S=
zloekVUQS&R&RTn7!ix*&BhL)W-IiP1mK{D!jSc@v{kr8DoHu;c)%Dx{NNnq#lr;%2
zqz>S*=rA5jHS~u|>LK9zfj^BtHUD#a<Ce3b&YucK_Za-|bWZB*oP@s}vpRif3RP5p
zX}E!^8SSpU7f~adnx2|40s7<q{2?9_8Nv7C#RYr;uaGP}twE&qf@cuvuW3-L{|(_!
zADR9^R(9GI389V5J{-3Qztcr=@cG{eqYa^%w=QQ94Wp?$yF(rG=206UN>+_ef(?hQ
zgZTT|Ux5-Mtm=tT)@+r4S5XbS3h0nGJuScxdAi`h28Q;Q=z@sSu@bz|1AZWJ2#K~k
zDcC*V0}Di8tOPxD3Ga25&|qfB0<IG7hR06euhFGcN@xbntnB^w3Vdq+hAHTZpP3pe
z{4QSqx0<s3wWat6X5H^DTA*)=%LM5khEv_`$!+g%3jOxmZ|j)Pt`V2hq0i9z2M{{6
z06+Z&sz`^kzShGrkMyC?6r)6c5b8|Hphsn7{`=IkNJJfTXH+!~-HzAZHTH#HXCuR1
zcj2L^4tF`pxMUpAd>_!Po@X{(Ju3iFh^R9SQ2-lUAe|keOX)uFk{~hwlmZtNQ%lwi
z&@f1J$-#6_GFd>Nc*P{ACpic<T=GGn4IGpba)W?%kP$cocKg0K{2l%VZ^zriAH;qB
zc^s977Q(LsNpYXgDcsstlZkiiTXG9%_wrko>_c6dHEmn(41aX?q1NwU+2{-3wLWw<
z{1N3P_b7;h<o;90h<A{Tg`}7Q1a<9OLRs*2IE2qrMzo*@Euf4LQx4(ldVV{-w{>_+
z&#D5v3~#{83Rd;B3~$|w#`aL#>^HWZIn#EdJ>1h1?$K_jZNH(dkzA)kzoV^@@?aYn
z(4Ae1?zq8v4uhRqL0_me7~FUx5j<~6FhG<hazucG_mGo46qWIi?SjejQE*J5(@OXG
zl|Y_iAV7s!P%@Ybfrm~HMXn%|GnF{<<TNyAs*dKZ8_waKKOQ}}Y)j9UWe1P`h<Bdb
zaM?>|zWw&hODL7WhxxI+ACKknVP@L04sH#<mf5nFU&D1Qn}&-+rRX4Trk}^n=pZ^$
zkKOp$?@yg<59d+TDg4Z;uJEa@mH3%c6cx^EKY8kV{493YGfl`FyT)<PFmp?bdDuOU
zHL>`krxz_<x+omT%gW2T`KqgKhOfMLPd@VU>kmBe`pb`;#IN;?>FF8sDSi!KWbcr!
zyY|B#d_JzzR8e8-jDxkXA6|Q%)L}=rBM8%&qV15JuScR++TORTbZc}s>Fy*}h2~fo
zJNhLE2f*=aFvd*vQSe>`td%4;;2gl7De#z)Z74wAu^>ksk?jSbl@ftS3~02UV!?R^
zeu6SX7o{vdgijcyf`bsbSKI`c=p$gAkgiPpfsukyt6xf08VCs;lYkO<EacQOmb@XN
zo-BU<vnTPJ$0s+99^EwgIDYfwv(KJHIodtSIr(g8dz#yw=1ESbGqzp*IVwyTJ{cuD
zKKjUkKb<^00l)hB)!V`k9YfO(9BXeshMzfxDmS3YV;kY-z=31OM&VbX0REH|K*>-5
z6+(e+S5sX8(F2gd7(Vl-uD1m(TYx{eSWv<OytSnl>0q>7g&-YoU4RlS7X0}Fw5+A~
zPaQfqnWiVxVMpk#S7(N=S<$f_t$YjLIS$|X7FxNzV@3FynXkS@O>S+)%bQ-DhCiJ4
z0=h!EX~I3Nt<OzEsncF;df_=pIzlam()jYXQ2RL4{uaI*N>huWbO=D-sni0a>L$D!
z+RTga*3<CFPRH%=hP@7fxd81h36dE=rzZeP?gz^Qi(~E3Y$CH-Bz_M<f#q9ZdcmfU
z#fRhrni34lp%e_wUEoK0U|on}iir~fHV9e`KlG2qo=mg||2DX3Sw$6<QB|?5X)yi`
zEy~==h0juq7>Co*uBFGH`sjH0-QyoUb$lt>h126iiV2_Pa_P+DRK{^SGj|0N!}ksf
zze|_lLr;cp4&N&xY7RcMlm2&2*{VS$^=`+~r4Dy}$)HtbIL;r~R9U&{vE{2==;WqN
zxZ1U9`C}v{;J<z=z68!f-L&<x5sf=3>#9|~YmXOGzwc}u5qk6ZX4ST+{nGfz{sTJL
zAl)Ou43`tEhU6ig5X^azmH_QQ2TL2kgakY`7Ia-<2Lr|eERW=|>BvG<rFB5tfT=>T
z+`ua;4S0p1F!?1D{Up{z!!>_D6@CI0Eytnmk;~ARg?I}--!!_pd2|z)&@F}N%Vi_G
zacDUzf;T}ZYA}9fIbt9ujw?hf5U1uu99mI`;~*zumg85b!BlwA@t)(yd*<QCQT@Cg
zszLUIhunawnl7D+?!Z6e&Y>`Y`VOdTCjQq@bOSQs$x|<F!q415J?4>R5B1m$_!-Cx
z$2ObL4MXw2P$sDGJ4haiAwG}pfV`;chVT$i_&53=<T%Wb8y`f?P2eHdP}Sj+5Z8Gg
z?_&Mz`w+Ds25ZT{n!wu)gnhs*e^F{sxr7@rXd~yfl1XV$wh}*dh+sj~gQf^$BMn{|
zpOBL)N@yiKNx-O9p7r0c2jg8`soBBc4ai(GW<>p{*XB$*^C2p0SbUB5(*v*7w2ns%
z8a8Ud;xpSHr`Atu5Bk?^dg*W7J^H#SPkxh=KV(=zUZKBccz!l|1OIyF`KhI%Ga>2b
z&2e(|led43s((dPf;TU=vF#Wv>&CCYxpMXKt8KPR_iebXVtLP!*RJ1v(exeFS8sT2
zADZ1zR#{y>yso0Ax>TpTRI#z=px@`=eUVu3Wl8*mL|e&eK^MUu7Ykv>q_w)Oy6bg&
zz~Ua#J)(P3_pI&}-P^j4bzkYe*ZqzVf>$;Xgr!j?@}mkg7>z*9aAxi-)P<I!OVLJj
z721LJpgYhZ^ay$aokB08x6#MwOY|-J75z!^loi$mB~h7FAyr1zQNyXRR4X-;noljE
zmQ$BdYpKhq%c(1=>#04|9n>M}2=yfOEOnYXL%mO(rM{+qqQW#wn`tMV0CUXQbTM5?
z*V4o3adaC!gPu<>p_kKZ>C5Tu^o{gw^gZ;0^l|zm{WAR){So~INFBsV<jqIEeeeyE
zgT_Iw)F+?`YLeV96M3W+CI@ejd)HqxsAc^{S{5xw-}eCMP_vfTrJ_I@YNP_~JA!3j
zRt;G#gZ3TGs3rg?4QDL}ytb$!uO$rp?*Ck6L;n;)wpQXV=xV1_4lJNyJ1|`X#79ul
zo=2(B68=x$fMXw(T1E}BcCVb~_*dNf3PuZn4OD;G2vVAKv>X~S8nN2Fj~p1OAfu6^
z<seZU@=u%#ZS@d|>d3|9Y#iVxd@FB*Y6)q@>DrU%g__`t6jA(?$hDTHl}1`=?E$ML
zlxQh^S+#m1;0cy0HZBz}rz3g+%!0>kq}CEygQ@}54v2}?AFU+<mC&kXQc5dCYXCJc
zYAL8y%c_0%WdNoqMN7yzWEuy_x0Z!JR}l<WFoBYiKzq>TNpS`z7gv;(w0m62&BUTW
zpy<J1MMV%<3Il#W-W9AUbEZx#4hD;l1j>RzBqlgqN$>!`1j^b2Wo3a0g@Hif)MTeU
zJ>BUC0A5=Wt_fC_J5#3y%Dk??BmQ8}|6pEWVcx_-S8_=q-d$c+Q3}t>0*?gX=Mg{r
zv;|;L1ee8LdtrDpf!zil&QxUb=NA^X7Zw#2w&myN7Ea8}%gYSCM~G+(%Bg9tATp8q
z+l%uHiyp|$%gb%g&rg<e52hp}q^yt~4mo5BmX?$~qEZ|L3g#9S78bST78d4C%*xHp
z>L8iIKL(150_}d6C+J5D0)>SET&8fLv#_M35Sj9FbMx?xg^o0MY$COw)1=twWUn_l
z{2{r-Ba$5c!obAByu8APN&>-RWX|^oa@%u@inG~gexHMKsWYgV8hRd#1my0`_xtnP
zN#;ih%O53)Q?ub`Qj*=CSXh)o@V}U(a&sE+j}2&d!%Ynj56WqHpD=QY-;o4750n%K
z@%L$tLVxfPkIU~5P9=PKf&dKtJe!UKYJ*cs0)diarNOci9P~Iq>{AJKC?-`7!n%o>
zgm+I6N<)t(#Kk2{CDlGPn;I0bdp*v;v0yOO830L?1wwOXqcz3;Lc8}EJP4FbB~n9+
z%L0KiT%7DGEG(H41Pt&Mvmtar_~$3$I+o;eBtX8HvOq9+ELdC|oKgWGp-2goK#LW8
z3G1g21q?b<@V^y&D~e0Xju5oir$J4=1ue-0RdOb$!`*c*54pS^5;s?r1@NPgwh{i5
z7X<@wQQ^nOoat#U|0j^P4gN{SZO+tmJCrFZk&@4X8YefDl{u3M+;5AD{h4Kuoq$M(
z(j@Vl;$nYx1*r44g@yJ+v?l^78NUs9Z!0V;yt1e$cWZWLF4d|$N|9Yj_y`ob#$Q-?
zE;Bp3sK_tH|D2SRjE~tIc18!eR3ZT1)=2rQAm63%lrlj3@CBizD38$1gs64^hL1rF
zXh>O_BY=-Wh2bwC_Z*KW1ucXNbkLDj;on|d6xa-O<6}@W!Rq|0)IPKd=TrM{f=oZ;
z`|}lC3AheOs00-&vL_|ka~16FgrvfiD_>Z>8qZs~@@3_3<;r8glk5tpHa!sZZ*!yp
ze_h^SkZ|W4z?B-ZV@LQpAc=66uni4YQ7QJHl~c+BNlPQ?)JO5Laf6eSlWy9v0}roA
zwL4QFyDCKr@7NInP9z?1rV}y%zo&t4G}Hyvr2_!eymKe4aD|KEh5r1lt~3zGXOQDt
zz$ueJL5-x)GZB$xy1X7&FnLL&YGPd=4uK$^bBsI3o>ty8WLO<bRy~p60a7FBWQYp4
zaDFlIWXU`Pcm{Axo$_`(nA)IXPPub<H~hBZe+bpLCk(1<N~cHI4epUi8BS?z)0%9f
z<W4LJ*mDZKm0m~QCGBl-uKY%MpGdRsyz{5-alZ1Fg!=lHDt7z=XPr=$kdiQF%sP*u
zm^ZhixeIe7<CNGDt6ST+l-d+HD#9J{MSp_`t6i4@o~RmgQ&-dd^#q*7Z~_sD1Z>c4
z2LJRL-E}}V5XlF9a!^LRtX}bHuz;7)2~+}!5K)PC=g};r7aQ0eYYThHGtxDaZd&PM
zBiH0PN!Olh&saz!|0F;8=BWu(;pB>nNdXG)nMc)k3?154ONYN-*gWjO3VuZM@?{6v
zgg!I*$D|;YT9%p`$e_7-{S4qEU<Q$|A$QO%4S2|GdMJD!YshT~{W^QdY--AE+%+3n
zVR~}TIr7bxdYXqOHZ~@~S$02oyD#!hn(Uj}(=+MD#P+!>?hz*3^T%+lvCOfT7uxdt
zc7GMVYe0K=ef|2^SFXetuZExF>(`@&p#8?xt6x_BR<EXhC9ejD^LFe&pY7cF!_J-G
z@7VFZ@(KE91pV8=|DD|r5itSwd58shs&ip&um`bDiFL!20a-+(#=T+wM|s5q?qG>J
z4{txhECc9ai61VMCnN#X*Fz2^CBOcnL_}2BQ=|i>h478~%NFaDVH#0za_%C05Os!!
z+@-6GiK`zjnPau=G2+K6QtTBXda8UOYb{^Mg>NvKIgvAoG0)k&$(+E&aF=sFexfxo
zVLG3<Mjy-G`1>`bxwBnEMw!IM*lb7k4y1b%6%MVf9b4-Owo!N({^`kAudt@1*9PO#
ztE#isZZk=h#f}BciB){!s^>H7ObK&&l=viPdXfqMoK!3(Bo*7J{O4)<d31o$AEKyp
zluNkL;K)B~Ox$jY`QtHqH#27VmYC`x9@j8W?I{@6U2+vOaY9#Kj2MU3K8dV*q(HgJ
zGONYwugG$bo>-72uLItjf%kj)v+S)9)iuF6WiHqWG+BA`xI$T>F%nKKQY26kEb{de
zL3DdHmC?#4Oh>3pClLglUtu+QcZ^7c<X0!0(+JN&3bLn!JG#XbJ7^I4YFM&uq>P?=
zh_gP#l|S`V=!N29+O4<VO-rF=w&Y>5e62YKvT||1_fWQWRQBN~sB8*l{NsDQSh|9?
zU3%g~^8LK=Aj7oaubw}Jzv`m?IiI<7g(ZGa$(~y!=2k0CYmz)o5`M9q8hxVonPgjo
z$xDljbSr1YA6OG1=O4dQS6;sx2HE(9Pj0)4f{<TK(2|CqEW%&aiz$OGk3R>?<-a_2
z*OqJHydV<uC*xof%uFUIx>^CzsIjou<4ic)X$hRRb(wCv?nd2hy8CrUbtiPs>t5G=
zr2AU;ldcyg5lqMdEAg_G@ozmEh1$>zc>i=UT7@>CD`E6|JGvJ=1PA;*gI+{$pbyaJ
z=zH`#rK9weNX1aeR0dT*RZ&BzQB(^xg_=VxpjJ@ps4dhsY8Q1Yb%6Sm`X}{0^*gPj
z^|VOG&=4r3bLavX>y|2`-FkW$J(6yso9RgqxSK}LqC4m=x`$p$ub?lb*U=k6;+!%V
zftCP4G;Khl3{l7^h>Tf4#OhO5-(z)T7|9lSstut?8B$gq4-w<4r3}oWjg(0Gf2pPK
z@jxIN@Mv`;LCLPv4CF=e|6dhV$?ngU=tx+rO2b<l@kNIBK&qPKe_)7K{r~h0d{VF_
zVE$wMTD=+o?SA05_FTjFKVmhokan*X((W~2+P#9C4??e?FMr{TmYHakGK$s`w9@1r
z3ik_%Xio-y{{;`Nht@y`A{Suh{UC2RF7`iOXhPE9X&7nuTD=4FY3Y1Kok>sr|Cu*%
zPRfYQwlYkco}tRhD}$3#<EpBvC)UPi7>(>0-lS*Bt12qntE#K3CS=Ce84S#LR&Pd=
za<j5>+Y0gv^YHn~iqu%yt7Jh_GvVjq{DOjfB?rE}GA`3#FpS~_mMN{MDw$X|Xi(Y2
z^muogLC=q44My}ZDbY^Awdd#L<>KD*s&u)0VwF2R#^H)hZTGrs%nUb{W-aJQG;3=v
zc-Z*7lC`b8uC5$F#-|$%>^Po}fILD*hiwEdZmh1Vib<bPR-GvaAE>D{7`QRKk?#i%
z89nfW_vZKu^N>Cje!@Ril$OZp6TI=jjrP>|m>d(&HM5+c;(J)he^X9=Zk|%b{iMwO
zi3tgb;rgob%8E9qvAVscRxfZ(j8TuMoc#P8C1)F<K`GuIEfe~huy<lbWo5<T%-Af6
z<y#p>L=Q&Ejo`Q2<;*X%yO0nq86H%bCz$hO?>NHpiHcDELj`Q2=Fl0$gapxGv;YM9
zV)}xQ*gt#&D(u4$|4az(yML6B%Dw#m*dIKcnI7-7F^t~uPFY1|Qmn7GCTVa+yxq#N
zJZE{aqO968Xi!yBO!i=s#Ihn@l$n|32O1#^5}W2522XJVByEGFtKb_o56O%Zt*k-M
znqDO!YoT~tW@ent3J{^Zla!CbsEA4R49bdgOP18Zu~~HvI|OVQ3EKu{>H{OPoSqS}
z3vz5LD9R;u{t8H>E~}`BOIba5FsVn+TB7yflfW?41nA+%f!SzcMMY)mkeDomDqoyk
zWb`c5=m0pMX*mhdvyl12#KZ*30aSPf5xxwzTR4v4Ecm5J#g|74RcLva04BSEX{%$h
zeL;a|XdAXe9zw5*M~SN---%z>^1CXs67zkRM0ht4T<;#$8Asn(5);f<8=w>qKLbBI
z``4hMQUkPT*9kxd{>T4&PJDCJCo(8IwWYx--vF$EXaKM1BD4+8Hr@wQ#ScS7|5@}3
zMD)*s_cB58UKUcTs14Ls>N;vKbtgpZAEizx@%j&`e^B30KS$#A33M)9MUSE{qPywU
z^wsoU`VjpD#N|JtKcl~(e_>e0z?d0{@i2u<9W#U(&a^U}%t~f8b2YP<xsAD#xtlq}
zJit7{9Alnfo@P$!6dy+k-A5f9S?yn8Y#VhOqA_~S@WTi((uqZS0McXlz{Q2mi*yRG
zu&kKeC@0U82_DGqQ>KH+<j-HP74KN_k)c}RphWWU=`b?se-AK~L6A$fz__O`qvFZ@
z2f$Dj=~1IF2i!nM4ajL3{(riWof@?S5ycB2FX$`F_(<Qa_R8QmMa7_|kles)rGFpT
zb0adC1F%YYSQ1I{`XN|S93&s)MoEFylO88rk%>AVyapP5pg9oo1s5=cfkiAA_!ESG
zeMuJ}rqly~wQsdz1u0Td)Im}mBA_^uSM#F&2S*6NK=A<@2q{tS@S1W)Q#7^J{1u|D
z1gmHU?EwPdQQZTW%7kP;>GW5*sM_><9@VpmTBQwuH}Ls?gFo>3!14p(55zC(nEe+#
zNIq>=<-hS@AP!pDf#n9~8+cF3{kJkv*d%Y{UzzoRYZ59V*EE05nl(5xF3UQ(66R?q
z+kCO<H5n5AskSyFCMIKIMRj$>gp%^|68wuVro6OnLMi+_P%Vjq!%`HJ&XiL|iscOD
z=(IgO&TbLy@v_ZOQEirDVjbq1L1uD}y4hE^5V0m}MU7w<t-RhWNfOT`CMGAaoJF#U
z9A|NujFlA@Gff4iB>0SW*)H<cgN>ps)@7}(Fxz8dC1Z`x=15BrExhE+ki=}K#mJd$
zX)fL{N#?DRXyROx;`LVe;pIsQyv1s<a?Z9`-fR&iz3U<;Cs{2fK5<+OFNzkCb554Y
zg^7!u7^4>@i<wWDBy&*8%*M3Fa8|QK;23yky3N81qAODjU!3EyWTlzH0f!(;)zyA#
zRc?VX)|J|pm7kv#T2on@8C%|79-CfQN~fm7&*UthFDpEk1rC*$8`!IVpR>wjvzeBg
zOkzQdrOOl_W9dK?gJv0%va*tlOZ5hWekb|hO=h3ZA{eZB1!nN&oMKA+LVa<Ssm)mG
z@>$x2iV~ywkMc?oP-S~{MMbqDpY{?twW6d|$SCzVttJDNNl?Iki|lvD;)O(NlYBA2
zxXc*eL**3}<r9j^ON-l!9NsiX0p6A7Dk-j-Tw0m}>s`hd`Ta!?rPzy$Y-y7U3JVJ+
z=H=(-wddsK=1k7dE0Ej|5yFm=5AJ!h9=3=RdERQ1#~L}KRkCshvqQSe$eDoQyxwGU
zbnu)gLb~4KaCDpWW(W9ulH_*b-3HDK9A}|`?R9u5*=83FlEazU$}?t2;tdXmb-$i7
zOE!tqTV1v>1`v?d%o!~<`wODcA~{8aAj&Sh3s?ry<qQ_9c(<Mt01Mt=c8YX}c(9>g
z0ESgG17ebWKD>@=lb}vfaxfE>xt`v~44f#5B4?EB_Hlrd)oKAy4)H|`<N`gjSYl=7
zKFHhaAdqYpmN(m_1yD+~Svb9Dvn>z=(H<iTW?PJdozw8gM+VkxlO%xRbS|<REOv)k
zFN(2o?0z+#O3hItsk2G+bja*_CXiMam!7t)wz~Sh%=FlD?~vNsSg-funws((N=wSq
zVtnMHv~+!~!IPGo`g$pHI=vo*7A1=|InF7IR=KVwPO>{Ccg<i)1m?vR2@5OqFbaw{
zGQ7n`nw`aFH8YF}l$|$NZJ^eS!Hsxca8E82{4t`<WO3Bh*{vp*6c4~`4oQ^jlIlEG
zXN<!lB#wyZMR>?1jy7;oid_U}SWK1dDIyWRM6M(YY+7kcm26(PGKdbZ2up=5Bww-<
z(nP)9Vo#MID=BO9*pxId04a7U#bMz&6Fjwf0WT#VXBY#m*kZRC+@YKN@v*5EDlIj|
zP+c9a%*(StyWlp0LQ+R-tK(94)d0^z8`Hssf`4k4$Ln;W($ZcJdf#f@2>N4MWQi*R
ztAl9fg@l}3&%a^J!LHG#`}iI<FQ1>ziD?C$R$E1d&1!X&rOKcV_Oc2|ME**U!>))J
zc9y5fW%s0&IMR7f`0r2?x=bobwB{fuhz4Yok>~ZiQC?ngV@XN*&XQz@GkLQsRk?Mh
zr7kKd@%!ywSk1FA5Gc4hFQ@QIz`p>#6HfyuAN(`46yvZ8MyuU!H8ca(FfcZYpqS8H
zEG8Bji)3Y{TSbT2U?6srpJ#Ic`}Gzn&SiVZYPXm<&SV9(JMD~<EP6e(NvAl$Vz&#N
z0E#G?4OTk{-)MH)tojzw2GV3r7MsMMayX#H7)86&ZhF`%S}ZJUHcKMQS_uw3sJzJa
zzNC2i^c-R=Id~3fGXb{6z?*G=Z*QA6uf^;Zoeql;^vxj(6Ck^SI%NO5gAisAZ4QU&
z{8vh}pE<866%Sp4m78mIDd0q>)i76b*hQltL04copSyZB2d`g<W?lg6A?g=6Wx!XZ
zk37_73*LcQf=n_?0J8(|w{s_&5AkUh;?ukMqwJqB%aZ{s=f^{QRfkephNd9g>;<2t
zBxpl=i1fqjT1ZE82{5xt601=#71s2n!%P6D<2g!><kh8>z~VoMK=WKA36^A+R3Nev
z6ZSzP*-5$$K)`PW;*a7Cc!%?@FaDKdL6>=wl6S(qk%@X0U4CK@z8X&3`esH}_o(sL
zjQOJntwGytQ#U16K84p!nvuseS2{{IQ%;mKBw!W)ja%o>)Q=6sq)$UD&b0F*+RNjL
zSK@S&J%JihbmbK{#T3o*jA1WfLoefd@a=fT+S%hL9y%}y-GY+gjphLM(CKaXOMDJr
zd24gmup^&-f3oYd+IR69Dqb%I@N@V79e*=o%>3sDcOeU!7sufT5&rS*XI~#bW#{0=
z$B^K);_rE|kM1unPOMzg5^F=1yKg8mh_O0&D`6bo%74kl!TgH^E7;wUcaWN3H=s7y
zHEq65n?2j4%$@Dh?b9999f7#^Y2BN!vP%cskGf<Q7Uu)YAp8fb-#`fD0ygtVg12YX
zUoXdlx1o%OAc2PMx(Lh3uLLXkVW&%2iJ9hw5F%_k;0=&}mrOnhWFk=ocAyWktQL@h
zbhHqe@`2X^d;#7k^FcXa&qwN25cz`Yl`k!N)t5&9AJh0R6O9gh-vpPS*BdFb3F#-;
z?XI|u&CRdmjxnW7%1w^TWUa&Sm$Ac}Y~q+<u^&ybr{=OITiM_d{0e>t_BA)7_h93c
zhVY#&(Aw?m+uF81Z*Q6Qb6Xo;FwS5?0(4C-q;E00U9lU+kEfsRJ<c@rmbA32Z;@k?
z_|1uIEXp7N*gJEQbCcqIDF<>WPfmP%HoUdn(Mp$1EH9r}M&b2S>GBCMeON}LRe2~i
zHz_GQojx^%s%R$9>F^tQbV`0wQh|r|x6{RBqOp|9S;iPTsY`@0=~G7e_|#;5c;nCU
z?j*}L^zJPyyiMYudtcrb8g^~?ndfb3nVIR*P3Xq)sAce`U5~vpO}~V_;*aB~?3U2S
zA1vH%Ns5pExiM#%-;kc~UzXEIUB<^HvU!ce^T%4kYkoB3r092|4{r&t{9qxfx&^21
z<h%vk&$C$*uKj?cqyn!sCrwB##v`QypEWbXnx2PZlP8Z!8aXm)RNF@h?IXz5h>772
zbFt5wn_<l;MQQHIklK_ox*h#MO68<keFeDIt&~a`*{awN&~5f8%o7*uYGIb9jg0(Z
z)J<lkT(Fom)o!y#mTVH;1mgkL0aj&$Zz8*3;V>E8yI>0zSP1S)fRZw3qP-YKYGhKJ
z3{{n1qMpR)@b`M1NmU$QM^CQ&y$dB=v2ekCXwxV2)?{Yqv<yzWbVFm+^oh@Rp}F|A
zhJ}|EZb#M3v-s4gbaRm{Gsgaz%j5EdvrFdPb5T`AO?Jkx%s^rBpg*YnC5d`TPG7Zf
zUGGXNF^F1V^<*Y08rk-C9xTu-bv0eJ<XU`U+j_69#GA>lrJ0L{F71q8WG$4Kf((4X
zoaGuTSd7WkK~4_bJm=#dCgsm+IJj@*w2iQia~!^kKgot*g{uK(1E=a{!R|^I>o)54
z>ORo@OZO{ckpR23=@3ocr=#H&ZFqIXA8FJi)&VQ1puwm63P>~0N6PpX#@O(L@KL=j
z35fmfNP0CQ<6!b)hmy<g0f>H=orr}zutO?YFb|ufs=vghLp;C(FOQMmh&52IT`*&d
z2o$**7L;lQs$tLsuSZ6TlT^v3ROyl-FWeLHfxt+b09Hd4pr3ZhAZQ14BM||U<^P<s
zSg8pX{42#E+^v)@VN-6*DGe^S7$=t01el_%z#uuHluENw^aG8}`LSYhL6T+Wj1d_|
zZo<@E4%@c%uTHLrp$1R>`r)fOUW&~waEzX^V7c$<OV^C9ETT|c>l;5^Jm_!K(%!d*
z-LSAJ^=i}P2|4D9c6QIwFFr&k_x_lycL@f`KH4&**~k?3e%zQ=BDjnrVtAG-Y&DgR
z_t(r`lEw|~eS02re>oL<Z6G*5lanl&Ly)74UTj2qzNjMC*BX;iOTGF>%c{(v!8CsO
zswdq>iZ^?nTeKpRPl*fLzue#}7)jSHb;h!F>3WB)0RIr1m?xyjCcVMMoPXyO7mG@3
zvki7jEE~eNo!$xiK0n!72)jUC^V8bjzpxcmiK53TPw`ruX_?Y}3wvrS{d1k%HQlQP
z+ukLs=}E_y|6y|@YR#dw*l40^W?j5>T=nHlb;a}F{0aTsjdwq}49^ZZZtQ4Wg3mYO
zbJV6M!i@&nVDS{^cT!UB$GyLxT0?wdzF1q@+Sn-O8>-sU3o`TLn2f~ZeEy_qr@e!H
zzB;twVdLGK<s3L5E;n~HIN6ASSMJN~>E^tYt1ixzY$<YX*Y+AAbRXW@K5j;0X*-SI
zxAJJmV%}VA=@5Yml!`Kjw#<ux^}>U5rVJa-BvV~u&)TI^tqqH(HO#qb#9DMGw4ZJK
zhnyQ`d^hW^)$P#Tth-BhSof&zY26Dj>-!$`kDu#))cv9hLrb#2%x@yRwOWA6Q9Wve
zmCx;HCTw=ngO;F6l(o;-q8nlUcR#uh9YrUV)z9z1E7PB&f1-b*pV4^=Q3gt)VyQ$b
z4d#LKsUoVJs-+sKW{9QErMjtQFcZ9$+5xfD1JwQ0G3puWCF*VJJ?e8MmWpW(W`yl@
z9Gyz%(E+*!W`f7k?euJz|6Kxeznkf8^lthN`ab$7{TTfW{Q`Z4{*e9${Vn|)qhpMW
zok?JPOdeCp)IfxF95b1j!}Kt#Aj-Oq*~(lGk=DDI`<dg+N#->3I`cmB59V9uca~yJ
zti;B%iEIX2$X2k`>=1SoJArLwXR;k^54(chz+S~(%kF0PvUjl$vX8URvaho5u%EDB
zu-~!2a};ObY@C}*<#M<Zu9h3YHFFnnbGUA9Ik%p>lH1Ac;r4U)aYwn6-1FRP+`HUI
z+!x$;+^@V2rji`In@{Hp_)@-(AI^{E+xc017r%&K#c$-d@;msw{2ly3{wV)6|1AF^
z{}%rV|1bVWzE{ucje4g(NuR0r>#Oub^<(s{`kDG}{c`<U{pI@Y`d#{c`h)r-`V;!o
z`Zx8T=>MtzUjK(aWPov_A;yqm$TAcgstiL7V-1rHvkdbLOAX5n>kV5CI}A4)4j3LZ
zJZ?B;c){?7;UmLWhVKpMjjYjPl#MCIY@^>;W~?+e7@Lf3#+k<X#vbDm<7(p;<8{V8
z#{I_ojmM3DH@<3o&-j_~Yva$xFbohxAx=mYG6la-B@7Y92;+oyVWu!&xL8;%Y!<c&
zHww21cM6AvM}?<_7lkvzd%~x}IpHVa4-;*&m~5taQ<^E?RAQ<&4K<B5wVP&}7MfO>
zHkz(B?J(VJI$*lj^q}c+(=(=*OmCS!G5yQ*gQ?fdnk{CRImzrZ7nsY;gUut&E#@ia
zIpziCi_MpqFEd|h-f7-r-fzCo{HXba`Ly|r`7QJN=FiRFn13;cEu2NP#96!+pC!*y
zYzbOwEJH0#mR8Gj3mp7{JVC{A^99Ja7u-l6@A1KB&_|p&Z=i;_ZtACc<K+XeI*<>5
z&*xLhNFJF_LS)IHazP6CiAU&{gFg88%RX`oiEyoE^h-Wo=KVn@)Bq)s7koxi8(jOm
zaxe+0r~r(76tE)VU-C)@nZSWd*_lrfWZ_l@50qTwBlSVwJ@4!X4c3&^D1e|KtU!ax
z6yT(2lH!~KOrVCqU{wzlkb%m89e@#_p;V`41=M9gnqU@$csF?{2Nc8<5=be6VFaPR
zZ^#zpWd*$QoL~Wvl=2D%G9eri6|w-8$YUtt1SDi1^7>S60M+o=sW8vyRPZM^8ry(I
zC<`TE<vOGR)?S4glA5H{K$3xt08`_h_N{Ue9s@t1Hjn}AQWgPB!1R-Ytk$exsbv9y
z0LxSwAg>~$d@2aCQ23x=<%`HPkPq)kE7U3!D9lrGL25+6eyCre70@Bz2pIs*3&;~0
zC^ac8)VKx6_5mZK69PZrgHu1qMgK>HP}pT4Dr_hjp)IOg!0(8b0S5u~ez^&is!X5`
zg~|vdU|T;qz&b-B;GiNY4Vuaq!h98qBJX?{>-LvCP}(0ijXuB;#>_-=0hQ&N_V|?C
z5tUGc*sr`w8Ih${O@G)CMY}-nBif~*9_1210&4yJi${1I1+8MDHid}d5Sb~p0CRj^
z;ANCWswS&yp=1HNHBBLz2LcZ$HG|-yS^;A8Leo$&1iolhYLEdStx>II8^Bxu(4Qba
zik+%^AeeqK1!osjg$R_WFKLxgCGo0_UTF}lV#uOOLa6VD9H>6wBf&P%SDg=zpnw#O
z4=PSpM6iuEsy_On%mIoO=n5hPA%z9~DN-QzS6?NoUu6er=?XU$qM|^es7DH4kVi$4
zg0zV809va4Mymxu^G>-Ya<8;jD5WT9q&6*0;TP1av{0>)fS?J7B9iUXYnAh)tAdUN
z04l9g(Gp^t6wOjOMjonHz>Wx4fK8e~xllievOrsns8xg!Dv^Zwsun7wI6;icMZ_YJ
zW*pU*2t)lua|v#KMIoZPs-~*YA#MWANE54Kp`40BP{hzE5(Mp_RV{(8E5b+8@xVLI
zgj@a9TFI|asq%#A8sP?!tW0_jxPYB_`&nim-=}E(n{zZze??O`(I+mY`2chRJX*6N
z4Parvwn7*av1)*D#AHW!3FQ=NC=C`kG=PVFA{YR&UxixL#Hy)$f(AtB*P5EDK7AOF
z7NfK}(q@%heI=t;5ep+b*(g*+v4Fb(Jqkd3s8+5jme!{#_JL9{QF#?XOSvJ60T+Gj
zS9qgnW+Y$+Pr*v6{DCN(CN)jp0gZ^6P@6@R$q^A~wGcKCvQ*^221hv&;SrG2ztKh-
zSu|I)RmsFs@Bm7E6fx#nHIZVfTmx!-pq$Xwlb}Gf6k(nhcH1D%U^KD6*fsD_SA@%b
z6-CXZ(vK+3I>JBDH;pgR-c<E}06$nRsCrCVa}4$gHL6Iez@tXUN3tj^Q(JRH6IFfb
zD-M=gQ;Vp^Ky!e$>+kC<6jGE{tr~UkH~N5U^g<8dlLJB0)v2UJPzgr7J`k2dutKJS
z4WO>bR%ugCqIG>epduAj%Rv_4i1t@BO$7jBVm=`ou?rC+)2}V7?vCPN$chU|vI25_
zYOF!(mqZj*?b8_bn*fX`lj=5T5P)^jCxjtNDWW-wGZS&h`|~~8s%gR{V&|gL(-4SQ
zCm>(7W&>HK>H#4k0zu&#ffTXS;0j07o5;!ug6wmMBDw}Fh?LSaOmz_Y40Z$>yygO`
z0EnnsqmT$yfghrAM!`a{|0?l>4TQs*4nt?A$Q{I|c?v}J)tY40w}_yr`S65+D*s`K
z6YUFtkUk@zF$=h)_S|p*rHJnNoJy~wFa(&Z)}>~Os3qZOBzg}iq-~NRl$ZZ7Tqe3X
z!7YAmb?A+5E0@DdxPg;rxP4Sxn=m{H(u^J$aC3H}F%fp=iIF8E%yctWD`z&MNnG^=
zDW#>9MU|X89;R7c=0aL>E;Pet4JMgRWmdT11SIn<riAWvR4HY+uP~Sdi0@cg!Adcq
z7$Zl&$it#UqmiLfogB;5q==HoVe}*hjJ&}>@mvhU=@D<C;vllcbHWS}nVd#e7TLu{
zD|vpUkukC?jMR+`W8^FK9Cw`y_ATC;BE;n7rf?`l7ThW95>8mmu>xzb?h~v=xY!6E
z9K4ZI2k``sMaV5>q_F83*4T80ftTkEEHlBx8Vt0aJ1CiDnUmvr6Mj<`WSf!W0s<?%
z0<nZx*6rc#vy3c|lWb%SJR^)32s|MXawH^}5G_!8NWB3TUQ)1Rmr4>Oc*4C3JjjaU
zO-?H-x!Ae!Mz5QVOEODa;|$0yK@A25|2928p}k2M(Vo)f65O&R3nu&n9HePrfN6#&
zynt%Fl$*f3&T>$-1+6i0E63Q%OsAa;5}x2#Bcr$MPD^D4A&=z%B@{1+MxZCpC>bd|
z7Xy5Q)V)?tki^PlUjmAC8gCLfpWBqO+beey9E?_Ui;<S}D9dUPW!7TnxiJpPWHmBY
ziJ9Q$Oz{pQ@CNT^V>~XS$HZnPn2KXIi=0hhC7GWC5f>wE<c@iG$t9WGGE0fM@x#ka
z!8&us9>OTZ2;)3L41`R<<6doK3^2Eg4p|Ve2k?K`#mcN88%;6zK@Nz7#oXvCk##|g
zEFSW`=H~DZlHie9mz#4T3y=pSohI@H$ZtbNIFi@NnQ^ZoYZF@P65<nCYaDOJ?>WT<
zxp}O|Q+PN-NKB5G^4u)-aRO_MkvO}P!9Q>U8}Grdx`d1rE+y6KN&%3BUo5qOC?-%9
zTJ1DCC8*m(J?AsoJT4){%@#vB0gaQGY!}Dj8j;gGffW*!QxpS?<q}fZd*e-<TN2`J
zXoL%yL_q)rXtEk*i5Fn?NO+{1sH@v!vY{vEi<fO3vSjCwK)P(K76g#u3edv%LN`zf
zm@wh(R%3juRW_IymywYqqs)a`Bwm8X2~ukInB!cm)lQGF=sBkV$>BxGmSiuTmaR`f
zi4l!N(44GpHz&JIrgjNXb;a|R4FZ=du^iqef#Sg<&K81Cc#3yQ#<&E^EE?_jQKC);
zj&VBlrg+idklD~d0VeTTtCK}@<9S=0RdBlv>mq4p^dl>d0txPGk&B1><@#D~rzD6r
zWRkg)Rz`Btv2lVaUo?tVT8!avl|m$kN<2KY8O|o*X$DFUi`VB6+F60xLxURIP-wO!
zSY<}<<X%b_AXZJJ@JWU#Et^g8nUjA@Fi0|RJBFp&1Xcubxj0j3I$W9%pvs}oS>A2J
zze*hFu>{Yka+8GWpsl%Gf}Bt<aI%2FKw??qIF|@ZO1KgkEze<`pn=;=0uU#l@N@CJ
z3qZ;&x<q;nWa(s_ae5O%#1NgcA|qhUqD~HM02s1iG7E(OfxnxKaA9<ssB1)gXNJ|D
z6K~9jXTa$ajceRON&@Tg0WzE2(8^&e<V>p^em&02#fuyu^Jpw@kC%jGJBya8iVy3|
zK>tM)I!|ikjVv|YXOi9Z_*$UEN;_nMqbCz(ga#j4AqtWV7;_xD37Q)xvS>SzCfKIw
zz$Ex{g1s|Xzz~8RpjHTw2f&A#0C5{9x`d;ka8}ytq)e1S5Znoz%Rvb?H)*DVfk$QV
z)*m6#h6fuMs~wb&Lo)>?Rp!bj2ot8~j_JzF!bP$G#~HXxrU$IF%gM&L^#c7{E}!Zb
z+_?$n^Q(=b5!M+n%ZZ_Z)@%#OF2d&&j?%g1;*5+Eb0RtcDw@E_aTe2B0mv3=1n3hu
z0WSrmp?UpIK#xQDdWI380V6X(i88|)Is8B_2RvrOd+mCVwb3PQBr8x@vJhpCPl$0#
zT!NQdY+xnce76Id0hj}@ImPjU+smaud&f5kq8>N~8)E@#t`rl#lm@fP3gLw!kvMc{
zQocz}kGH0$aC8Y_E@$GxAE_6&(}>Sj^_jyjJB_f_BWRx)ZH7k9p-D0etDL|_Y=q7d
zM3M={&}h8D3ew>9bcKhsEkm50lQ?Ryk(F#57+c&`T^61qg2_JGm?+m5o675DP)Cl3
z-V*u_YO!c^!}>uv!*oW`NF)1+2qr~f*Sa~gQvwhimKb37?a&rPmUQMcm6QVABA1bC
zlEbHn=>bw@_GqR6*3Rfj;3#i`l#;@F(t#a|l^!%DO@vjL7GMB0(&wRpxdhH-LOa1!
z+GICxLRU7)nJqO5jU%M<ui03m%>*20&|T0_7+9S`^F|=p$b}0f&TO{|E)(~qpOf-9
zJR!zt1G5RTrq_cI!4|<QB%ut#dnZ^_s%uSd<z>^$RxFhcg1V5#D{}{BRw*O*o-7t^
zWhqi_v4GH9U}8YdF776oi7~Qn7PZP8VUon+_gE)7>N0_Og}czFEDsI<jDjY6I07g|
z=BV35j*l0Cn%>ula{wxVz-kc2NG#oBftJBa0u`F001;%Cp6N0{0mf+yFY}pYD$OnW
zQs@9f%(;=lYswf$ocRfb{W7c%!(D<2t#=DPFYAGhDg1#5JOIt$o)iSA0Tv;0)U_G<
zWFB-k35Nuu+f8~uDN|+v3BfH<Gu*Jy6iV5s8$_eaWE4%|Z-oTe1XW02$xUDmI8GEm
z=EiB@SJ)&MEYvtHKt};4UXS(>KrX23E|Fr1vjV)r<&rU8V&XG6DhS=10CeL80t;=z
z9cz`sC!qHQs$DF;i`Z-fKi>kySgM7U(G*~gRfP46>`K`fpTc-Dpy#NU06iD9d$dWg
zf=|Ykb1b+=R_bg<O4;M_0$yR!n?YA$DH}Q^aEN80@nG3uHn~JbbhC^o!8^rJrO1YE
z1CBVsm`NO6>4rqohP|ZQV%-UXX?#3uA`YOFIgldd<-$(E`OcV;V}!}m^G3|g&#F*7
z4&j9a))wb9#>?CafJ;<dkAH!tKx{g!-=x6?npng+%+PTIBiQNCAtuL*9*Me(STJJv
z1$=9+0IHOgZUVQ=n(Hx!hpKu8ZGgHaLLV}_I35reWP}e|4Ct`O<Q73VIGs3VoKWMS
ziIW(9SYpkDJ~&ISOdwt^{~93-#keUk*<??TH>Sih;bd4aYB3sJ0+q`OM#+;W#7<Qe
zDS_38ImP60A)vv8tWIQV6OHjU@M9_SFJSJ$PT(4z0m`U#jDYlZ2E{2Hb-4r{m%5M(
z6wZWVhT8lwBNZ3g;}dMuJ$4EVl?WCEOKz5!5(5J^B(WtXuhH)sQp29iFu5|^&YTnh
ze+iSBM)8Xrn~C!=@6krZDzf;q|BJo%fRn7M_C{-;9IH+~m1B2Rbq>{Coo2cxhn~pf
zz%a}VFhdyf$RKfGNRm+yML<La2^T>H17=LX1yls@6%a)cB@2i!(}(ZBPxUZ}UcC4B
z-u>?T-h0$g)hF$<!`f^8*V=2X-KZl-@n{N<VluD`yDMu}3tX|PCW4uetd05fC5KgL
z2c<Lol4O+5QQzPmZ?mcywU8+iAXvZ;CAg<(YO1X#T!6l$WaeG9U|r>zBt%SG(`u=}
zr6`AbHiWbWc|vBr6z3L=-&BTpwNm7-1P}|kBtP*WNZ%qppgB3y;|Dp-VuNFWK2#<K
zS$Rn~9l+tVrD@T__(I~Z0UQR$T7ymux&9I`c(B!-s-VDKK>SQYA0Ua0SpoSMJ!><9
zF4BCe!_V(~<f~M)!q@XS3M+XPnygBZ=Dne6q6WJm{!{bG9q?o1r6}p1WZx&8-Z@M;
z-U;STv=rFv`XmM9GFrZCNJ|TRO`R135mS(L3FS{r41%L(`L&|a(J36=!2g|=+Tnux
z)*6TF8>s89q6j>TN%T_MRRs+i#knSc3I#$>10Oo3>LdixmZ8$2)a;r|LA;2A1X=^*
zpA8Y#Rh|QV$~Sp%SSn@027%^wgZNDX=KHM5Iauv>rL7fFmGiaf7|6>^c>IECP&ap=
zwsg8uDIG~_v$ywUOkx5Y;oA^yK>B}!-EQV(NNfW4PT<`~)fRK<c)zDw*awPu8qcYi
zv0N2f2#;5WRtdG5Nd~LM-~~d!(k`HK#gyJ&EQmV*qj{dl=xUxHmYP6UreCTNStbH5
z#8sYUQTq~_$D4#(3Lk2)8s6AW6u>E#`y{3r0Kf7WK_B9tE?ZXloAAdpv0UlQKo>Tv
zrr$bfnp@#%N+JBMlXsp>Z#M|X%?XS6NwMmuD`~Z*+KIlx%-M!Y(JMD#o`K2uCRyYe
zB#lCbh@z<MGf0MM<iV2C+wo?Gt-;lk)?`zos(dHmctbYQPYVpo$&7q!*c3&n;{5<=
zJVaeE!Bfo^bnGpSH@m5_UoBpiNW3NpF`k#n=f;=%okz{Ath&uin|@JKvL#{zTHVjf
zEGV8oI@VNeD!Zw+2hlX>tilNze=C@7?e{4En_+YLjj?o_qHIG`RaK3{GZ{#RA4Jnc
zh69je!z$l}5rC^hs>w`OgI{sVqk`&J&AZa8F*x8Z>Zb)pB7E?BJE{Q5xUo(QxdqpF
zd(ii(+yOg1tx)xm4R;=s?HC^HxB)@{V%Uo<B`g~bB=dxrP7@QFQz6LJW)_E5lw&i;
z?gX|44`J9(iiLEhsCpfrZ}b)yZ09L9;??gbQi9M~&XW~5g2-0>?57lnf6oY}yHzq1
zMS3|Kg$Hi}2y-A8=5awpE4g3@4pW9>i>^nYWYaMXJ`IEnSSO~^WPnre_lxzUS$IsV
zREr%5{hgTQ85Wx35}{qOky~bAw%tp2_*%8<BbFAmnK%WbN~wa~Wu*)QWbAnpC-KFi
zUo_K|eidL>SZb<>6*0)~;J6PyA9%H536;#ZoR@~wRZX`SF8u`lP>Qi0v@DpIh9>hU
zCH!(i%ol<eR)6&11=k#Y!R2+|Ph;31em7z&`+W>c;U_CI+pV-}rff80&mI)17NKc>
z7iFm~(tQ}68K3uE#Ype{2?1sS@=%#?7Rq|EE2$Q-6<|23vizo%!aXJkcpUl+osyn+
zf&~_X+MQ+K1$j$!-RGJraf4i(LB(-b5r~4$JdWeoy|!p*yybFAid_sH4`4-%%AF_=
z1;@M#=zGzfUZ5Fk)Zlr4e8KRF%FxP7(J89xd&X^XSD_X5{bA|_u2@1WMt+LfA<8%k
zo&YC-pupT9UkGO?w?@JRFoB6v8BLKn_9mTD88E@+Qgc30G5zZE0|~3tmzI)wQWX;p
z15%0QC+@VsT?`c(GJCBCk*ImZHG?r=7Se-`qyon^CVpnBL4Y+kbh%lYqZv@;0C(UB
z?16)Gia8<&*LH-RbOX3!74aX;8juSb;|FKU&w~z;ZqzqlL!F)mW1&sBNC7$Wn$|Bm
zt{&qR=W)(5A?Z}}BT&b#cZ=m*Ppa6%1iw&)8*+IgRq+Kd$<LHJ(uEc-ZDxwhI_R?C
zyk`1iU=>yYgA!bU0l>WE*<8pw0S9dWN*LcJz8h<*RLRvwIu=Xl=)S#Q(m)*G<_7z<
z#*CC=X0Qr$%m*J1`xJ~|DP{>B1`n7B<)GdZmr76s5zKst8IxnU6f-}sVFn>6CKd~H
zGaZr*lS~!SR>~}W!GQ6X8eSeZ(QoJ^BY4<XMb8|XcGRreQ42P0Ay31)VCHO+azF3;
z8UU&9@12$%sAg)V&KiF)xHsOo=gTIVsv0TwbvFj1gBcV%JN;r`L92BHtNn~-f(yp|
z%XnVvZ166b+{{R@$Fahd7>VFvi3&kQ3Enbc5;PUbG08=mx0Ek*00ept>w2>6ouSf-
zYl7nriOq#LD5nS>4&`n)9mS%?XEMPHnSzmSw}oPc?3m;yDhAukz{E-}7APYn3iEkL
z0<fi^PpcG56|dO4_kplqVL8pvNuuz#VW>dbjr$cc8uKx8X_p44X`tTVX^0U_EHix$
zxEod5Y8s4agu7K$almh-(}~ik$xnPf<QBRcBX@%VGrJL0qXIO}9#e;BbyQ{s=L)VL
zj?=`Q7$a)rD0<%#!s(<w60%cP{x}3Y<=AQR94fBfZ-Pa-nvhIPJdgUPD;cq)${dV3
zfvp(s*<j1rik~h|yy;gAui|%B$rp-MGt-)aT`qVUX{tdl_XvpW&^SpsJq94|IG9{}
zttI2bOA57>fN+Mx$iA$)!CKsme-n@;0uRQ|{E?(Qs<)};Hvw&|(QfjnobWMe!Me`D
zgrOY8aoFFRDOF9u2pp`=p1SkEv&UAQ{YkJ)+rf;xoJr9KVrg!t)!o*Dlz;tPP^GL8
ztj9cAa9x-}jo^MaO6XiLNivlR&JYl&<se3cZB-$(VP*~<7BZOm2ArBtq7VbzF3qJS
z$Vf<T?3Camumo0{3!!d-V_WQ(ag*jkQtbUU<C^FzFU{N}wpaL4N1@WO_kN<nRtnK~
zeTB}f%c0w=u>>@2@(Cjq+=cmF?(w7LD$_yvN0GR(hbfOykkr_i_<ROqmS_e$d)0zb
zFl}LK4tXAi4HIMH8=k{~C#dnuX?vh~8ca(OS&idR^e7#{UWJfDG!}h5ZWa_HXG<>f
z8RA9gPu~o7gQ4+eGU_C+5g5lM7EGW9`8P0l6($06;_-dhi+su{m~M_W(TU7vU>_4e
z#U&fV(PO#8Q66Zrpax%+9M}TT<+1C0z>%^qm8;~3s4nHOt`VF=;RXxAJOdC2ppGZD
zpRrP(!Y;?(hJ=9;7Lzd;r??0ljd7^}3h8psUhreE0o7nXgi63*2x+<ZHzE4qRbv`u
z2uVju`X}>r^i;F(_0o`^?q)M)XXp1vjvVdSK6}&VzDbmG1?~Z*B+o3;o<J}Bxd40&
zDMe0c%vtGG&|}EJhQI+#$m8O~I?C;m4lw;E(wSLpzXlZGt8}6;_cb^wDm!r&sECEt
z>rGfUHCKfNVKXNNCsfmzN0@0(p#mIirEMxF0)a8x5XwfIqD}mWNHThcdtQW*Ar|+8
zB3~*ArGnw)m=`5G2Fokv%QGs+IfBy!<-IVQk`lnV&pZn-i|O<{@H8Zq;Ckbfk%RZT
z?(-@@6}tHcbc#z87Z6RA*x;|0t0;&zLtCCPK?+!O>daUj#o6F=Ud0qE#feh{24IPT
zlnnW!U%ii~W=vkW(VRbj%JTBSs*h`xO18tK>wt*r68JCa?Yyux)%6;T|5PTCB<f(M
zHNc<UvW-y$R9E)iSnTl9ooS(?gFFKmLqXY3IVPWqr!_S_hjr*^^NM|4HJeGw$tl5e
z6r;i@wNpm$TRfvA+5+GoACtk$U*>ld0fW#js}g0+Y)T5nBFV$_g9ZnqaawZ~ZY*sA
zpW)k+$?^s07)oCzQ?r02VhP~JPo@2Krd%f1hxDW&vTZjyQ8j7Tb(u)}?8z}F_%cO$
zX#HX6JuoY7c1R@riI6S?AeH|ly+}Fr3z>?MYDp<A)zdSej3&1u4Wl}^H_LvDvT$H)
zcmOxll$9X|)V@h|4-np$&1}0J!0b=qJKslV6vvZ+!WlacI)8NKd6%FHc>E&Yv>`mx
z!B@5RmU(=&R`n_UXeXdW5VmP=sW4Ql_GL=7IT&?FVXkJTv4q19(JI0i%q>JgA*#AR
zZ9<wD$v?WL7UNViIKzqoj!>C47qQDBXYqo+W-wswakW}mO1TCUIljwr_;E^3L_S}b
zWjIYsOqjjGx5-)5pTdCcl*drrk<j%;5M|n1pb5lHSFzZI5IN)^iv)9|h%g7)^K4|#
z%OMxy%E%59W3FTVh50h`P3Au4$IQdbFPSHpKQb?~JUndQv%?BOe2b6ddH6-31HK&}
zsd{N7Mtz`ML0kpmxCA7}!!6;t@Qi@$3t<{vKiq->u^9-%U@HiqgVC`OU?Jj6<NQF~
z?W-Vw17S0W3&CTJhr<jNVYCgc0Zvxv{~q?Tz$dH#jkXXgr~u+Ma49UUIEE^QpM3?1
z2;5`BBKN-%x8fns6+{}j;rfUk>2B1=AMi?(^`hnZ{fPV^eee>1v#?0Jz(EFs#y1Y>
z2XThzicZpliX$%qtud|50G>f`5SFSD$AXujwe$yXqr1S<53RP?Ny0+PxW7aTtRbxj
zn%nr$l!JI257JB_;fFTa@5XoI6s^tV6<jYBF(ly!sUVQ2l13}h<M60aEgbFZ7~CFS
zt(4JcG=c`r*#AKfPacGWM<aG<hrByz<x;O$AHY4d2k3|1K6wN6pl(FPIANcM#d?U1
zLLma($T1Aq3vV94h!zI~1nJPapfnn(6BdWD5i4MgG!Q53HgpW#IVOSx*8SlKU~>}?
zPMr<=o6wHKo&7`*QC0YyA#ny?hFXWoR_NQ{;xK^Af>`c%P^Z3u7%5_avGoDn2_C&P
z&`rPU*g<H(lOhv02Wx^g6E`z!$jv~!YbH+1_(%!GJ4}(W_z5+d;&ign$&(6;m46@c
z?LFX3uuF3K4>C0bw<`|v7-(XF7uv9PnBxmsE!rDRzT)v!Rzu)}9OI0FCW|Q%x%kAW
zFR|u#v09834$(!RJf{rvQD2F|T&d}Z%@Bz$>UvB_vnuCSg=lmUZ*vSAwPapSA$(F|
z2$p57XjHZ&QOt{A*ov5HB7CdJYOEeJU9neGs*2XBaWO0yNw8QaJdTCE)pD4U+{Cm<
zEYG3e<tEq|S%izT%^WNVgkj~rC~NDcmXTvB!pl{k5zTffD{+fi77QrLJ1POrP)t?R
zqJEPiFud-^BrwEmB8t5J(Re3smvdvfZRt$jWQth&U>Tu`;EkwaSECSs2=W)YiU?`%
zU&K}6X|ZYyDJ&#LtN3#z&Tc}Sh}zqhUDPThTe&FH6fYT^>@%gfT|`4w9l4?^){ra|
zR1v8m`b0(~h><5&GhqZB03qX5c|F+!OPegHvL#DOiz375uQCF|A%&XA7*SZY4uIaK
zr=gZGvc(rACTZB{SVf`%+ma2H2YaoNSr)6P4q-G&Gow+iHmr0u#n+lLC&P^)#kwG|
zOhVxF1J`wQDAga2E@uv1MP&B+I|P<55~z9FM#e#e&vnfFz2|c|j%soILA=BB5+ZAO
z7GPbU5ZQ#tKo8eMcJJL*HU`*24&bn`;BqmJ%z-gr;yWw?%OT_>Wh+*RS+-V2I&VM2
zR2<1*R8PciE$^k@o5|~%B*vJDE4(5Dg6U>>i3_fXCh8=kB1%7-ZUxTakUb$*k<c5W
zlJ5s8;#Nhnv45x%(=>`VSWeUwQR#wJgqV787*&iDx~^0l87V**Cay?aGKpRl4I!bX
zWP?QAZs>@DuJf)7V~VOF%3n%pU=MPNH`8n^ngkLTML`h}t<JH)XQaE9ku5>dV-nmc
zh628$Lr%ES725>N8qS<<8e<0Esctm#nb}xQ7X`Kp{xq_t`yf|akMc3UPq49a93!@D
z>b8&u+=*sMPV=?6vBZseAd+Ssq-~}J#p@iktDq1oA(c~c$%GS+rfo4Y_5mYx7App7
z5n6fcR8#3fI#;;mK<LPFyDBxu5fZ}o71K7dcO@_}l09rCZR@otG8!9(>>KiYE}CWy
zO!H`>yXLg$3B|LEB37x5E|_ffI6!rd6Ed=+Xq?VQ86<De<fzCp2>)j#p2TBp3FcTK
z#w4)Gn91jfYI8EH3(y%1Sz<k8e2C?dkWC_3IOe0GXd>YiVk-IiI55;D!O6cE>DSeD
zLV3C+sCsZ;a3VARViw%O7n6dh107r3E0VO=5m{tuC^IlgXbk8-Xq6duiz`NhZ7{+I
zXM-@w8(hl5@Q7)+Krr2cOxQhNaOcfzX%m~Ic+!-_sG|AU1uTLrz58)T49LSrF4O{|
z^xLuf*)+NbGh1T^*b#OXdkVXYJ&(PRy^_6=y$PAS?m~Roz3fAXE_;D}gMEwL%O&53
zNs!&9nR=wcxeN#zGRDT43Zx6fB~H3L6>{P}S>;3Oh;=-G4O_8$BRztddY|B>(g>nw
z@&h+ADy7P}nF=<X?V1D>5KWEU_<9E#@(baiRK|t{VTV+lEW3R)Vg~}NOn2o9%Rx;L
z9|~C;!k31SqveM}3x}aJ#xcDcLYvC4ir6>M7d~8~at<57p&nGASL!`|<*C>LVX^{#
zZ+{t=@UF6m47{OyZA7iUM^5h-+mOk~eFffxs}QM>aa81^{s^gWoTBvxz=A9us6Zm)
zfC_m$;}?Om!v4f#=tkhDdQUGpAMgbI1fbIBF*FB2pds1uH=gwT5DEes)d#|N54a(?
zp$Nf2k+ciZG&HI44G>ZE0dK-8HgYb9;0bSZ8z^o7eb<IP{_sQF;y2(TdL6fv(ZT_I
zL_dUEp{&P?LtKFa+J2hX+d;44$?yyi6a{K%Egh2Zo8ITqzq|1Q9K;&ozNi!4L2E`!
z^xQsrb+TIk!%&cmn*k^3ZNNa`{ow(92HDK;O1!%U_?AQc!!}pE8Zanu6m9Qh`2&rY
z_+szAhjA4UyWeRvvVl;2Jn&xdM=Mit#Ks8IiZw-eOa(*&)Mx^+3awO#lW8ma_cvFh
zO-FZ3wjDScTWbS=(%Oa{CVI_|NC7QHnxM{p@LCrmfIG(sP%Ho)ExhR05$03lX;e3m
z7w{B{DEA{NH=Yp0{Z!E3jUes@6r<DvV#5cxmr|RL78OC86iWA1km7-sNL}P9TI)ns
z<VMUmC3aAsmt%16-vhNE8J)NSkf#Vl@*-?a9RHR(3K+r#|Bf}4M3#|z1P1}DzzxxH
zj*UsdQtXTf*~|!2I0nWES=X_g36lv7Y`m?QqNKWsKI~331JaNYVltm$EJi98lHH>*
za`9Ec=81c-qvo~Aq6Qxan~!tmG?|aG?CG{`v%pV+#)^y$WQJvYPhce(iH0oIVX^8#
zOowGOHrXsDJsrX&w=AJ^oeXF4L}Ia0#z~B)L+mpNP4lBtt|$u%Hh2;^cpXq%89W8d
zT=WDPP(VmvrV6mk>M#;RKg5C-YYAA+Wkea8rx0aTxNk(cET_6);t1V`$ytH7Rm?+W
zMaU9JV60KKNB#6v5lXPka1aD=;1XCY3n)Aw0nZ6qoFu6sLK3uG3aY2dPz=R5c{Ky$
zoZ_&^MWk|q2ced!uvooK@w!|PSPQr`XY&kkRBHioAgR0*BX=scsAJzIk%45yAfV9-
zMguM{vcttPitR%9h%F40j{<H0*1#i{HLy;ph<-DI))^oPB5~skYfP0OutW|>Sj`uz
znW$q69RBGXk6cbgfGVvS$TlwI4Lpa8ID!Y5%A|QIfej|$F94I7EM~+$z($W#+v&oV
z8x<U+hC;2-6-rX$WaRZ?ko7>663leOjMJsFA{@ySgkB3eFqnX}r?5;hVGf$CuT+$*
z&AJA!XIiQ8vI_4NQI-19Yj9v`U(9Opp5X-HV^}N77vQz9o&0vs3mE!iVIXamtTJ!&
zr6YKbVpFZo5Lyo&9)aj7!N!PkTrmnf#JjDfmgEw*4P7Biz-NizQGfw)CY<k3cr3vQ
zti}mU41Jgqq6{^Opb@O91~;2gQ)Zdh1Vy`o0ks5YFzRm^=oPG(6#40jDKzCLx?w40
zc1rN2VK^sM(hQ<Is@~^nEQ#k6pk|*$FNRJ2FaT#K4vpJBB-3GQ0I(Stj-u2YEodrn
zQ-23Z&lQAofWO;0^dqK6@EI6oOp{HD3@KygKI^8iys(7h8J+9_UCfrbi4$vW?o`8y
zBY{%6J<3)RaM2Z7mm4L|Px6@|9;B>Sv8Jf7u*up?%n-Q&%ZiIa+r&M==3ompKvfwn
znv#?HHeF2erjA#z<m{3f#ir2hz>k=9JckUlcAE%aE98RrMAc?EmE~01m4J{_zBp=U
z)M(2v7h{E{aI{6_7)nb(<L&`%AWGW=u41u^o+B*b9C=~M?VmzeU1C)+nS{e5a=o*n
zknhytN1!8rRm#S*utiB=7?J`lMI%wTRbcsz!8oz9jx|t1jh?Vw!ob9<oRx+9qsYp@
zek#!w366LykTZhQO}Gz<gidIUjmLBFl+hR^OgR<zIARlMjCe?vlNLCRs~~_Lvjh|j
z?O2yZBdI$)YNM%ciY>&j>c<P&G~?hhE61SNKo7ziCM@PW%jhyVrVc(PGEoLT5S%DU
zl3Y<3MgjZeoeH*2$QeUMz9;4+6zu0A$UH&nDMN1M1VwIAyi!GBp^`GxoSU+me2a&Z
zq65_g>y5~8#p{X?o5Ctwp4AwntU?L+p9MjqQ;b+r;$SKxJ_eihz@rdRAQ$8eyysOx
z)NEMjjq*a#h^D5tCdX7aU2FkA=EW#fkXTaT2N|sWK$j8)EY2jvgW-jegTEXKlPt^*
z6scBIuw;T1We5cZW_C1NS_m#f^9u7^GbRSZ#d27D5HwMjX7J;(#q9leP5Ugvh;XtW
z#iO6Y?QopL1YmBk7;9n+C`ojwebCN>Z!;veOcWug$j$QGti=7c8LLc^U6u*@)ziWF
z7=t94$iRCr^%8P8c*SvK2Que=5xH}}hU~cylSj!DOgq!Z3?hT>hnZc>dC2>J6Y@O#
z2s_+8!~B7Hk$IJQgLxa-{{@!zSc=Ud%l{U3EBkBqS+1KK;-+)UxgE&au#5XP_e1VM
z?h)?M_n~hJpb@P>v9};jZtnuw?d^jv6`D7tapVJG?n6x!BJ6{%urM~$?bLz8C=vl)
zqo@RMpnDQe?JJA|RR9r+*XWKi6xRTlgt(_v$NgoXL6Jgln4|VRLy-%`FR<&;q+M7g
zefKd6OK>yAjtxs5g@P1n0|C+3Q&<RG*D$|@-vC_{poq`|IvLyvxExj$WtKw3PQg6w
z5qxTB0vZwmCDgI;3Tn;*zNGk;7J}QtD?Z}OW5mKfyr^~vDC+}Fur)&Q2>(a60@_kP
zOf*At`r-oc6j~ehgNv7;p9kupqTwJ@Kv@0$dW8b6feQZj0jRw24>43W0Ng1Cq_4Bf
zz*eXVt<?Z&s3K@R?KCuH-&j!n1|3BQ1~2vjqQgF_)I+EZ1p*pCX!r$gLsjWG(_due
z0X{}OfZdQQCmb!j2v1KEMTL&ETW%vFz%oh>Rhv%0TbT23p9dozhF}0hhU)sXU4VNc
zRjGUjU=nx0R|F$cqGsTJXd(k)CjoH#edy|tmMUdfn`vg%u*LO$m~v@#1O)gx;c1+q
zkQ)bL1Mt$GLYDw(67)U7?`wElsSe{Hu)Ylgb*~?u#JFR#6QEw&q5%*Zy&C|V){`n9
zs11Ip1|zsI93x1Vk`=0oHao}>6&~R&_)Ow_yc9DgM*68GG9;vTu{g!WbpU2M@{|a1
zBc;~xgT4t%K}i@3jQP9M4pvO`Vi_<SZN#*L28S6#+e>ftdfr3c4Jr-wf_~WeQCDau
z=p#DCpsj=?jT-OMQt3ES&2h5&_=~m#6Pr>19_q%6&?O)wXa%AAC_wc<L(u|iV=W_j
z9<3EHeq*{oEezWMJWnS=9lOt>e0mDBOIwY<!O<}$w1a73{e4K%AyAE^(GC5W_;?|R
zqd_l1KUOFPkZwC{C2gOFgxw<aW)GSKC34sbXpY>!*BkbnDPFn@`xxtNPM9}Kbr~L9
z692&!8{a&WNjUH^0pH|A$nLZ;jO}|Fpll|}sd6pJZ4G7xH{~^lOLQaYQac5sGSrYx
zr<w4$69^r-f&kV8VwC`&C9MESpBJNPqu4>B36)r!$^e@6aEu^L^#lswEzW8Z3@Jq<
z#uQ=avKU_RWjj4=#;H3u<8`gb#&SZ`B3OQmLHc8(1IZ9!A$C+$*@7X}B8*|HOdPA~
z8Wq_{j>w9*KWef%!^x#23lz-71jdLV4L^gWEMzo|;u>_IteS$EiQ{Z0K~9aE#e=P;
zt_|@HlE3-Zx7R_i1$W|${T{OE$`wAz=u)qO@Dzw+3Fd8}SQp+z@q8yy8Dw+?T&BiN
zU2xbjC=hSJ*aaVbR@lfCNGl_xEhM>dL>@>4=2-H85>xlCMG=m~JSOEOzQXWE5~3UG
z03fhvi+q9TIdmxu+Jb07dt(u##ptjCs&-0s`C9X~m<Qp^C{a$z0vw>B68~2-!<ae|
z_dX1_V?cf4$gT=}jr-g_s3C}@z$&k#sOTfQ0feKfI{bL?sNicr|FB>F5{ddbc^f>#
zNboxj$&HacOHFG~24EBB>HyxH%u7DJ95fip9oR3S!+9smatoYO1P`V?-~lo_mls_N
zfqn~tKbYIP+ob%IV3{mFr)dbAA;H&L9gBMc=#1~Stj{89jFo=~2rn=)D{zOzqKh(U
zyWSkbz3Hfn!3BMBP*1T7u8Mj95F!Vx2Cx{z0>8+#Ce~Mdk!w*$6^U5^_a@Oz7claS
zCmTi*&W*ChCe%bM^QvzUxzK{waCE$)r9l=+ci}V0ut`CNA2hVD7@Lh6qUJz_!ao(M
zm*u6V1Kmznu*?8grXutsGs+4lB0sL+P22)It6~Dvaj-e!2@e^Cp;WOhv4M01gNZ>0
zg5CtBTSP<`N8%(eC<y;XPN@%P6bnlWZqkEp;~=^&1(yYfhZUUar`8xVZwnJ0jxuGe
z>kH^xPzd%uX@&I^o_jE{YT_>lXG2#ugWrHyNh>z0pxx-r!erwZ`jntqO}!Ep#p!vL
zF5jA%;$kd?`N35{u}Uy67R|6vVNYt2$q50xGv8-hM+>6%u#mwFbA+}Ln8abvZW0-W
zG-GEIP9hmt92jW0Cac!=E+Ctj@;EPhE_}TObTgoO7R`sZwhCYL7-#3H&L{Q34(pUs
zE=Vcb4c@`noFwrrFr>>(90TwRs|Bn2(o~G2j({+$=rKYb!C_d}X!q374lkjRb`>KQ
zP7WysCq8{X^29;`gqs=PBtp-JiY}-%!O+cV(WufZ!!jZPjY37#5Fnw!zsP3VSjlC*
zgyW`E06$D6Mb#y1{#Zuq)ikk=%wa9r#O8!72_`?v2D>Mo_F1BXXgyXx_4T(go-jDW
zX2LM10&cs8Bs$PAV-7Mi3o<LRo)m*^0uG-X>o?mV4S2{%X#+?cN_~ReTY{D07?>4G
zny?W1S3&52zQg9>@^K&Bp+)AUxCV!dEHiO2(@ZQDQAL^pcK~cGf&_Tj%}YnHD4lc~
zv<5_*X1Q9N%TgV;6RH>|1P5kwQa)itnP)*-G<__~`vB%qIB|f%U>6Sz2G;D*a)pcX
z2ms?fV)J}~iPl)c%e>M-IPDcE2<#5908kLak}^kN12S2~%0O*_hKXXji6ua#R~%?D
z1|~t8g)7DVJai!>Z%a^d0bM+{9&7p>*Nw5AxP4Zd&rT!D(Q8lfM@!fwXBpp_Yl;Pb
zWTEXi{Jlv0{8b1H28AnUfcWn%u+#{{MzPd|BpkAgcd>$qK8`|7l%VT*97sh=rwSIs
zCVpNtC8Yox2^YMa>rmrPxrF7+G)TZ93HWXaN5Ra54OB{PTr5>(S?n0cD2Wo4h_c1T
z@&*=fn&3mH&`{+JtV`9IZEd38#K>)$gPhB}Z>gB7toB?*#L~%4FdS$$L2rl>rlGEY
zT^ATzGjtVWlM@_*T)^OmLJt>%%>i4zd*HoFoV^drea(o@fdK}+%0NDGE~wB#%doNp
zy9PQO?OcuS&=KEhAy$nu*m1^zR*OgAalwjkGlZguIRhOM)6+(fiIRvBMopTUgy)4j
zl&BaRu%Ur+Y(bLXu7;eq%iuq;EcBnC`EPUK{&zL(hB+3Q9a#`rhW*|*Mh-(>Ol&;)
zcb*e<yqZE9mVy<tE{2JOJy=YUags04D>UCI;0rP7IlcgY);i$1AX1Nu2wT8~0#5Pt
z>47@@S8y|ZzF-l02M(oW?_a16F8apnJC>Y9Zd8N4$6vZyxOvTaBYihKQ5!jT?d{A}
z!m_(>XTK0E5>{V&JmL0id;J@SpS6Va-FEjff&F4I`}Vt+eH|xuyuSD3OOHpe75S1t
zUPf^Ivb&l7+i&O_IX8IZ)3>9*;F{G!un1t`c(M&IJNz5(XNV+!>(Jf*I&<PqsHpm(
z^ZxoIdF{FTWHRxF2pLP{`<`1Itbh201H|CkkthB-{}7__V?(zdIP<}YD%m0)@WR6*
z!FBivnsDl#A^y<$hXk(&A9-@(T(bG07Y?{!u{iMt3VDc8#l^JPpa1oV;G*EQLxM~1
zd2r@|w_+$F%icjWFaH(zz5LC%2tgnPp9!uDH1ZnRL=ML8c^hynkiTH3z0Kq=ffQjd
z=5LD${)Z6*JJn!ccjSZKxB5fjt!OltMX0a%04Gz(4(!?h#RGLQ5xn{PuiYDbG?2+V
zWb@lUeQ@XMsX^;`7m1_gk1wA!XT`OB?HNXCUcL7E%dbwl%!Y|z)6r|mThQjWFzng8
zp1$$d<heKI5IcVG8~6Y6sh_;EwFsdeEscKmmK%0OXx-k?gy;D$pl;bl%Zg3VFR0H>
zShr9=Xd@=AQABt?(1M#@430i_19_FKCEU*+Ibw9m-1YZ<@28m+qes6?a?G0Gra*t~
zr?)?a%WqtA;VTz??Mom3-mY`rdb+ZbT-kVEL@e{aj6|`1_nw}liv;M2NTEo3ppg-`
zmPh-`6MKSdg3AMVIFPMx{p_KW){F*~;O?*NK0IsOKhQIFB$@U6bIcLJH4}Tt1UZIm
zW%zT>dirxulLh3NM{a)j*pq^VFHO%?Uw<`hYg%}MzXfeg|HE;h4k2dft|UAWy!oe3
zel_@9;F0IZx<CKqz7tnY2?m1i;8Q0*CNuE)5wq!?;K(EAkQb0za~*l{^i%%r`p3w0
z@<7msyS^2SkROEaG%@y1BHwNPZ`vDyXJOd6Au0GY?JuUJn3#A6#B_DQk+;d#z2vr|
zmIVhJ*{!?o3BDGz{{D|-=CbOc2VTeQ2(Ft5NI<rct>m5HFVEceug4wx^UpmJWO3U!
zUV7E2p8uzi?p}qz$PYlX?_cvYp_?HCw`0+6uOUr+fKI+DV9<pql418=m2F)eJQG~`
z*T+g5Hs_i3w11fh_KrLp_e|_LURZ98KtXx(h2WH<tW<`s(Na2pUDWw6<9*flwlyCC
zZ@~xZ9#!@5>PGVO$x%iw0WP>6+xbeEG>4KcWMc33?ip7s92;MMQ@WC~G9P{G$m7z9
zpKSTal@~E9&^rwJ<}lp3Ct&uR#dd9b{=2{Y-Ggth#X?HriVH5?z2m^((PxjJzhtsb
z@5sVW`A?xngOhcl+>@FrXv>TH=2=4#4mEt*B`h5p&!zNOp;RIKbmGrQ!G8AMWY2It
zy5**wXYj*MAF*`vs%)nzjnB*5Qu<5F?(W~T<@WP~Sa9204<HivM&w+5jX68Gc;YSC
zW2elE>UE)aPD$^b)^oz4%TL>V#iHi(cZ*J^z4MsA22Ve7&%H-I{8n&lpq&$3MP5VY
z1<cKq@Mr!$^rwr==qE=$9{Kd&_AA|yo*ITQJ5gbDEDkKX1X(U&7D2zICZ0)mB<c;f
zkGIf0Y8xw#uCvdgHmUIU_d#)?)&%rUFW)y=C_SJO0*5FzJo&DL40<*-4Txa{@Q3i{
zKo4#RZVnVMiB04X@~2>6IMvaSnDU79^sWnh^^<Y7X(e%VCu!>XNCLhT{`nuf?E#jx
z6n(=d56`6XYdkHtL@6oGvV7HE#^bMrR~J$pYd*D5F6{kATQZkOr4!jiJ9#bBT`!3X
zMRAGfjf^s?Z_l^g5yhTsTXU@RI=*+~(cbX*EarGrNWy$siweCOSP#vtB;y_TsnP*k
zx*a_T=2|{!&!pnMK#ctCz2Z$PG~_8M>x)e3+DdL|c}aApG!i{v9+AaddvlAkCD~#+
z*^FbgP5dUC&UJM)HQNLZuJRRXp`#6BNBL@jKbXG}`Ry;FV<rlPJgghxBnPc^PiFrP
z=fplg#i{TVqaRA0?;2*P(IW42Y{(ixnLeyO=y2bQky2=<q%s3TLZ_90K&e`94;@Kr
zcfsFuo!F(ewT5W%C`;uJ{{0_=YlA<W&d6V0IA_-KY-VVVnNBccmVSut9kgh%WQ+X>
z!ZTKlZ=AnH)1UhuIr1$MnH~%Uw{QNzH@C-2mGkAn<~)`khWnrvTXxz*u3mTMye_vt
zX%5JPQ&MwXV|BODT4=xSyi<?AmCX9t1I*#UHLtvOl%^#7zG)*#d$hfa%Vjlbp%w31
z>t>oyilwn<iGn4qDZ?v<d!s;{vF*>k5PXs>BlouF*Erqv_%+ccvBIQ9y_`v;+q{Fe
zxh59%7Y+3|HeXQ&4S}ClJZAY^#``^X3JCep8_4;41^h#<!5D<bFgimT=BThQVbKZ6
zxnXDu#V@^Dq~<l+*CW(v64JU-HjQR%=?nv6UWCU!_%-Gno()+EOjg+Oi*89;r@!H#
zVoqS`n_4+5#WsRMCvP60RyY{x=*<|P22bRVH4Z;|&Cx{{``Q%M#GIAnz@&PFYB#G`
z-btHt+ex;~D;>3M{8Gf9ocC|RmCrv%xV_|<2Uq@JOK|hE&;9G8WI@jzGemyp`Pa1P
z&=a{MV*_o8sGo^hNn>tY9c5~BXTWBWBw0Ian}q?bsce*3Dc&-#YneB;c?n-~M6uel
zs{c?dRjOqr>9-%!$?~Z~yR29*ys`Xjmaw&!b_2O<rw;VPQGf1VUjxWE>g7MJ>3I5?
z;0wWBPe138MXQg=Plp1GEqAdnVtR_-l1s<aey6+jVAu|93>@~lhe|E8md`g?H_J_1
zYps!p2-)#_afJUF<YY3^6ge|;A#z*a+2D5Q<VmqiX8{$_=>9x_6oxM3*f81Bk)XV=
zZ<75r*d9GaXPO09mj-_f=Uq5|TnFx;A<)7&hre`I(Lccg>98~op?}k7a1{C>G)fG=
z!vVzY;f)lvpbq$39GUoQ@X=4-@@DX_usdxhJD5m!V1TjT9u!}El`Mx;cr{otmTvDz
zO#itjJ8LhS+jGEmOVlzF2esNQ&5PssbJ_J-({EdK*^x+^^o!dLEM+f>$JFAisBWgP
z^NWfIt|l3=GuMw57ten#RaEzWvLmx%u#jwHL_2NGx19NoK58WnO|a9Z`qCmPK8q_2
z^{vu|yPNu!#gAUc929(X;`KR)BJH<KwlgBI#QCV$(?LGCEx7f~x5=N$8`y|5**Qh_
zlC86Qq~O_kE27zgFgtp{Vz}4Om$gd9<dSRJnm3BU-Z@Ps%f%DvY}|*ho#~82Up}tI
z8-;J=$1>%a`D*9H$7MMl=bUnLcXvMX<+vGZ@4_6-V=u>R#4qxDupfvFOlU(V%D~&J
z0?)3g*cE&(cDddLZRoVf#gQ+79)1z|_sFj!FGOCA`~~}4GXzFVViJ#}A`uzliBurm
zWu{zd_Mzi66CBxWS+r|}uUC+NKxAS2ZLY)Q8_s&zmBXzH5jgkmCAI|9ILIKBqWy5e
z!dQ#cR1R{$UC4$hf=yGG6x<iut0~pk6u84wPrbltkrmJaU8|s^6BdD2QQi(J${{s7
z-izWUE77P59)Qido8GZcBIED<Z>$JCA$j5I0If(fD#D^7&Hc@=_>@?judo&D3d>jE
zwaHfq8ihl239@T^CisD$Bpbi-7-lgc+kz9LF8SPH!5CJBADTF3Q=xeIk4mM4!+t(!
z!T3GC=gnealg*vR2fdnbgQzAqCXt<dBs$VM+|v_~Z1ypvWKe?jZuIg*)EN|`LYI+)
zJqn%)SS()QWDcG9V$u(Opz{Mj0{H7Bon!mNN3dvo)f6R_lg~;bY>DFwgQk5+TDI+6
zM;mNs9MXHY2-RwDPVcZ~&XcT^@VKo-yQ6Sul$s^{Vc11w%;a2;Pw+@!4%Z=V;zc(a
zoT%`+8N8Ft{;VzzFj2S=Cvr|8X-FW&a~Il|7Yh>?1})@qmb{a25~gJxdAYr*5PT!(
z<;i!2S;2aRToipcc*lG!J09GilM$bLn%10*Tu7TqE&?P+>5si}MX|7%xs3J;`ED?W
zcGliG*nulSeoXt4-*c9|xlnvTDM^USjYf$?J6d`BZIlcC35z<c9i+QxAnzMVimKJ!
zK{9k?^tXRPUz#MpM*5UGGF)^iDii#>rAx3R@D|UzYy4|HR!esdTM9$Gm|@s0+z%PA
z{Syec^L;1bA=<;!$(wY9&9`5p?Qwh3X;=0g^1DLu3VY9qw5b}o79CK63WeSv61s;x
zq>=8;_7%lTA49T`?6=XE<a2HvqenJEZ3uB_uw6pZ7VzeDWGQwvIV5r-IJ46LmJPDz
zLF!n}40oZ#><QPNY$`e_2BnsTkUwHN(j$6by;i8(4H<~(1IZfhObLHPU>8!rHW>uY
zCHQB{lc=aZz_ZQ5?oIhbe`kwrq=xsl*Nv!h?2xB9g;D<C!9TqCErQMce9!vYrth8h
zK<)5!sdGB>y@e+qu<Z2KkrH!YVT0Y8S+XR@)lXqI7PG0nYlnx1hS|=E?LU8b;&3MO
z5H>rA|CH##C07OK1{cFRW_4~}x`b4ZC2iavqSuz{#===~=fS$je?{+8bG_?=dq!G5
z^W}-Vx%diIzF_VpYp<*<u%>k~i-uPX4Xv-2o0c3z5~ClUzg+!%a8XNn&zZ|ttX#1Q
zlJQiK;|UWVC1(YvFgr+l@J6tZ#DZ6g#TK`JW`F<B$eLeJ{2zQw{Fz{bFBY-G?V*ul
zAQ#c^VkDGE*h>n`f^|f21N1W$S(7|w|H>cbK4B;0HaZ4&V?ZW{qf(}ex1kIz;4WGo
zm4JQ$3tn^x(BV8gAlel%ygC4%P@3ERXDz`~PPb0VYRs^6?UzkV^*d#!`?5R9<~#f@
z$*N79-mct~8P&Yrmb)@jEo98Fl$Ep2J(gXji<f<B+nUT!A~{WE$g$2#L)8S?W|w1~
zR@ay<Wt<jrWTJX>aNf?7f-}kBhe$uEo&1$wt$XQpKARb>^?sI2|K2k0Ltabpn_kBz
zWl1fN)%Il*Q~Y+R*SqvCviV=)9b)iXuT8l*Kdf~7EqCUJVtbpjmNM3JNbvck-1cJ@
z&hT5!G0dV(#%(Q?WPSLA>BnUj=2nlMI?zOp2tM(L;JPQDB!_(Ev%w3u{!8=pVoSbo
z0>gZJH=PSC^SyUwVPA<)!ID>sbVnlL4yhFInIS}QO%IFSCRLjRWP}P;vpUwTL!>fb
z)(|E)^35~Pym!ZkmM=eH$2C(%T3e@1Ie5m5gWKnHchBj%v~&9zx7>2Z#cSE!%a1={
z`QFpko;|OVeW?}q?KL~*PhYiadiU5^cW;RqpSZh(`jE)&kqCD_|6@o_YFWZ&W0ONZ
zfPu`x^X&ZKsRthjp1QH=^l2j<og>pvYr2vA@qysCB>TWUU#VWSd*}DRzw?|6t6!mb
zc}4II@iwFe`&8s+l*Xg_IRe`hetn9bCVvFDO5;dm={Fo;!*9DD{y=Xj6?y8dTo%Kh
zN;5s^BF*79@6o?G3bEJ*(yD~N12#Q^yL0%>3XNa-VtTgmJJ1|fgl|-*k2ckHBDLO#
zcw6wNjPY3T4i+cB`$xs9ocvQ&g40*~wPLiuCe|r&M_TW|cS^sik4fs1`1omgA$aTS
zV$ld*{)1Nz-g&WDeS@UZ9t>Em{I_6<_fCD-(sRt<&4Pjw78yxjTVr#@m~l-XjNjP5
z@mHq^g{bkH&qb5)pLCyzmx-~boINu5(km|`>~PUbFO$XOw;q%C)sG^*tQ6z_bP}Hx
z-@a9DGT(es$p){zm2%(OQ?>scUZKA5)j-Xi{iLKB7CUrp%+0V4^v`5;g~Ozi(JO0W
zt0MercLA2`TVq+oZHO;RWn#Y2U3hb%*MBOQFf3R7);pS-k&gR`iS@{#YY}b8`m6M~
zt)^cgi-NmeehGWDEdsr8@cH=$;`f-ywXjfhkU1egq3po(DJZIhTNcrA|N9}fLJI=M
zadLzwf8IC37~22L2scJHMBwikU{Gx6k%C1b*sLix!fXOzHK0_eSb;*I8;7;n$Mr&O
z7iZ{=P?xFdO#j0Fg4_6^1}8XrK(TAk5{jnf&^Lsx4EO`gv)r_grl@9z=keXp&v0LZ
zJJwk$=jf%$f*aMu^HSss%`4{2P4rwjP0hA4Cp;nL$v>jNX6dO(@@r*-KfRCq$|aB=
zmQ?;@@<R$z{a3r*Lwk=GrRT2hoi23LI5w({PM<$suXau;n}-&fd#ok#&X(r+Q(6@{
zE_H9(Npd|+%itP1QYute%yau%x_S$qQ_8n-*b?p})}D98;cH9hl}1nQxJr&i)#kP7
zw$Bt+XRn<2^LX&`XBw1!*X8}z++({+=aepcnoOBB-!`<tse`TQ&aD}&bRoZWTH~>i
zq+oWnPveEua1WVLU(t)W)6DQfHOjs8<qk%8{}kYI-<r_E8IT|Td;0G~02s(0esuqs
z{NWs-ek*umKlxu-Xmk4HMKu$-t`N3fZSN^N(bhz4o)$}3d@7-5hTy%!TB0&?tfID*
znx<5VH&&~p6E|(@>Ydv@ea;3xnnYq<!L#G0UdkV^OxOEz`CRvMrti|vHm1{NaYcUB
z)ZEaNTgBnw(UzsbqaJBLi=?u?Kh*gL23tpBu0<v=*Rqk1VXpb4-k58YEca0t#YU54
z2CXFY7ou1RY6TPs`qN(l=%*Z%euu^c_)g(07IAP6F74E92%H}DTOObm3wm4Q82<F3
zKMn#L!xe?_#|Nd-d9eTIgQgg*-2O>Mbt3o=?VDyHlgIV&o_+I-a*_|4XcS_ghL~$q
zKq4BmF|+J_3OpX)KeOm2YPgrqtygE?b>vSxwf)BS_`&h*<NZo%pyxY150Pn1OSVsH
z>5??>5V@sW(S)P*t{Eb80XJjxBf^5&@Ky2r9CNO@wzx4ipl*pvuIPD1q`D)qtOrkG
z?Bh(cdlX$nl=_8nwog#34VKk3R9(4y!)0o@d-;x}ZLQg`?eN8eGgj5(mv#5gNgi98
zG2GvjE3cdqjTY5e7tW{+vK@14AL<-5yLErl&`Dc!<Aby3b>-8&ol^x1L5jC<>EnNJ
z)tSBD>0SSY8IS3%Yt&C~8GNS6JFWG@WZj-S)}4Ri9mlL)o$|H8z8kZcKAhZQDzbtE
zJ}E<z6Enuv!3{Z6Zk@x-TfB2a6E~=jwDQr853lN+*Nup<u9>#P)|u{^$QYd;#P-Lc
zgMEeDumtXSx~^G9Le~x<-HI69YzoVa)@5ow->r45CUXZ_xmIdQO&#pW=inA`fNK>7
z%wx?lws}4?^s!S9td!Ifm)8fm!D+MWX=kL#JIrvK5ZBgZwJd`dvN^~l)aZ(G%QQbe
zrKfM@5R>h5Dt&_sU%qhG+`~o>+;Xny*k&mz$=P(#^LjdWe8{rKJ37k3>{(=x`O>j>
z>^Ohj*Ojr^(}N$tM`~=OtFy>d+VX|v)5!w1uN_8v1fB=qZp<U>cy@E-uE@QSA4VP_
zvtUa({{NwKibC?n%&ENl7rd({&+Wgu|J?rj5K~6yRA@c;Taoww&&U1qaiS0IQ>@xH
z@`cG?0^gMIMDX4BpV@Z{|LFhcCvlMO=p0omgX;$;e_x;cC5OE4#J(F?_J3&JW2K$W
zdwyMHN@UKY-QnoS&d6Dji(vW7|FfANN{)v7_(xK2{~X*u^Y+ii{Z~Ku-2P|(yJqb_
z2CVPOQK11xDQ9U&V*LKC+&uQae<(LSy?680lpkBZdg(~Z%H0QD3R$<}#D=V!xO#F1
z?VC6sFt`5W*(Q8ya<;7=P9~2lHbmx%sZ?anJ^x*iIb`%`?-7}WR6}HHEJWrh_qMjq
zphEMY8)xqmnj=pm&3)_C(RF)04QZAHv1%!@T(FVUyCEkfiOR{j?~{`&yM~&*+Uv@)
z6>CTSMyk;XF{YNo2@(EcLWI9`LVWNE%#iSgcV|c;mY|Z+Y~3drHT`cSW4~SQf3IY;
zoqduKkuuhMWn-~4NLJ^WG3;UA5Qi(KQE}Kd1WZZi#hsJ$VjFe={Z8ZsIK<7u&Yqt_
z93gBH)cn%`ZWLuv0-=HffAseOW&X2yK^2@(_CWOspTT-0g=sKyG!(7yn<|W6X!QF}
z-fRCC$_+zI{|_qnztRu?ui_KG%f?#NbXLl{nJJ^LVwKfwTB_>Vgp2<WH28s+ulm5N
z!RQBG{_lMFgR9N|>;DOCZQ`O#Qz2T2JB32hcdSIBsX3Y}SgAZ#1mL5~iSd7OJ-GLu
z+(4Xva>M_I68>2u*qM{q<-eUXLs6l&HRQ$uUYQa3YUJCIC--w=*h)zWyC^o;@PCOP
z|HlTf|7+U7Kfx6hvBD0(XZfGPi}4K~mmgXh{HQ{f&z(A4eZPACK`>*VO8wu14<@)7
zo95p4;~C@s9418LB$#<{@Hyt|t53Ek73=>HFzi!<|8FI!-~sCgtAnGSTFSok_fj9U
z#lA~hTR~TQ_EQ$dhuTpfj6-7&q%`b42;iIiM_1dBpJD%ra6tbHaNvK4{Qf!JQCKUA
zo9CY;%)cP9itx>Owcc!Y=3-qv<gy=6yX3|jrE4#B?)XG{=K*H)Z!AXtb0qnngREr1
zjGlBa*S>n?$%%Nm*w3nZ%r@nuXgQKw$hIbj4^y0^l+=|>j4_yo9q4~Ax&9+;N=-Ep
zf!q?gR9MBG5{bdLy$hP#{KzU$E5;MXbyze*!+YpH@j=Iw@06(xgjzO3UyFZuz_X`+
zWpVK0{HB_H{Dv8Sp0VLfvh%ci7U4{#yK!dyS;2Qt56?8$tm6)v@!E{_yS8_C;@)h2
z%I=fL7m+JE=us{^vU}(Fg5cNP?YIX==j<F`$j!X-XrZ=v{dh3@i$@E+i`Op*4yR`p
zty{ocsIOPVzV6_o+B%v3-lK=V=z@rb|EEe3?pdss_rR<F#>lOaFGaqM1Q}&A6CQ}+
z+IdLeh&~LLxL{NbSJ#Bl&&YOYLK>W*6C3x1C+WJwzS|q?F!1-lxyfFl(?49SK)@nh
zAb|_WyJzT93tbbz2gOoDaxEVg5k^nKrW@L&LX$AP5j`D3{pPShoDoDkGD4_}ODQY>
zCS0tVg!~5IRM)7$VGhNFWz&_F&^C;EH`3Bfz8qDBCmq!)XpN{!flB&bvlw1L>!@Nu
z-$47KaRa?Xt4EuLt2m-pCRLdI7vZY=?%76TCZF)%y&unr&n)imY-$<S7L{r}g~Gz_
z<iVNgZaJ6jm~I%0=XWhJx6GZL$_x%p?H0Cf`RS>{zaMTLJ^J_yde2<gWV23T;y1g`
z{I@j+j^{gj&T9G0(q79bE-M^D_?G7M^it1)!K0QgUC_FI-oU>NENJ#LuDopTeM#R>
zVs}3)In@{{w@lyq>1<{9wKL3OS9e>dY+3Tqh`lJWo=mN2JzAmE+MCTTZ5{0GYU)}!
z^4v)9+;so7k!MEko~BhwrM93&8Ec#V%Jf$^ELmD=>iGWj*QWQh8;e(MoYh+!o^#Go
z-By0&fUf?f+2uQybP1)NL#K3gP2HL<W6@`EUq}12Bl6|(Ol!X4^&WJ@NXnU7TiB5(
z=2G2<vJ30WykuK1iDvo+OM}hPDw&t81mB$EWYcZgLYAM^H9NR^+te;%xT&eNDThC^
z+LTn&iB;yzE4eX+INA9lh1Pkyx2_&SxK;a<6@ylro2(Y{StMuP)!O0AsWq)`$ss_G
z!=`NQC0AA2mLw91Dp@hZ%?1z8?Czhk@guULl&hUZwPHv6lkNEoY0+n9SCVeVbTW32
zZFY;XQC;r0gmm*k>zrimV<Sy%<sH3O<_8nW;+-wR%8zfH(QcZ>o}-st-{emn8lHO2
zhZkj+tQtMgAKlR`ZCJf}Lt8p^(5lr3-7cicXWh_#$kOq6M|ExQ`KL5bXE0~Q$g1Ga
z;w}7v@IC8=m&?Z@pNxDj@<2n@f(kj2qiCq{*{4cVTBOF9{p1`@7wX#IAl=E?HA$9K
zR5wVqp^4M{VboQ-;SrBj%EmvOY1|o3AiM#=`S1OQSHeO?zyIbfcqXh)qf(RK;d5c0
z0Xj>>Th>qg(AI6iUv>t;14k~~T-}su%g0Hy_3As1UcU8={MJ?OI)AO-nTrd@Odp+i
zC0;0qDtW!9zOK-+=-6e;`p-XWAXaEuF?;sfc?YeUx#64-oqd0b#Lx0q^qm_VS93^o
zs62nF)7`dWhBuTsH8VciUS4>x>BM7vy|;JPl9BA`*|B=7yUy)aX5~f?nYh#_<`Bqd
zsZm>=^U=c&d+@E9=YEb6u0QERh;Zrf+InX%D&<G8wM1@u`M^CtRinP`7rF%YN7sD(
z(Bn29w0F(D^=Xo0r4E=fa_^VZC!D)^{Me6VH)TW@`E;3u^FHQO5pVgI4b$hvGP|~H
z89r>&Ot;eBTd58&K5WtQwnBIRP5xg`@D7;&O>#pmwmRo4$>cSzmd$(xA%I%$4oA;a
zXC$*l3%Pzq;f<AiB(8B<@`p%HC)u}TB&Q`<AIs1TcPA4ze&vxz{^Yxz8&14j*Ej4~
zu|k~JVM~U)^5A%^$?Y8}Rs0Ly{#ZtpQjylk@$h%O1TjHZz&H6bky|3aiu@+>Y~*#K
zAfZYHkweFklgZiSLUJql3b~IwL>?ngl0TAH7#4|Dl1!fIV1}8M%puHf=A+CF$h-S}
z<lB7_**GRxA*5J@;PK#sG`GNh0}vQ{=w1%~?BMT#x*O)u0BCHeCe#J7mqy{!g+%;>
ztd^!<z**{u9`g2g|G+V&xA1J^8{~?mN%}A%_`PseKtP0So|Jp2JV&u~g_8#MgxPHS
zL^w>-G#Hf0Q(|`9#vctgZPXu=!wtnuBO<>ZK3|8of><xn2BOSH4dDODG$tqY(Prrk
zYHDsG4G{?!?Q#sBm)H=P78dpbs^5t;0(7o5>e`UD1GJjBhU9L@tcG^?56~<bB60#W
zF3?ugE10>VFhY0ueT^tPT)?_*7jd)HTQtl9C)UvujZ7WyCPKi=U{gaMQzIJMgDN1|
z1d2o^JTc5Z5sr=BSEi!UbJ1657kV+g0VRWHzySfZ7!6b9A%&Yi`3l-wK4v@y4pJQD
z!(D}bX#2u^DRrNgC8CH%2g6CdQG<}3V9as7F#uG;(<j3L3@L(MLX#<rp+hR7dLr6D
zUD+vNg<`((K=?xXYRZu&c^HjDr1VJZg0@mXLQ8494EG@?8_iRQ(i{EaSHdWv@?`M?
z0<}tpMTT@0mI4NdoEV6NfE&^nVZ%gk186fyi2?@k5<Pf2$OQ)l&*h0!bP`-HihNeQ
z(xf<fi`d2J94iVlNum|matv;|!Nvy;R(-Px*)kcX>NHPH6=*zed<wGX=|Trm=aME5
zp`LJH$Iex0MnGDy>9K4zol4k_OssTNb?p{C#j0k96X#yM=$b`?69?%^SKbozg9Sa=
z<aCcPvQ7lWgy}b_+jc6Qo)MLim>)60eo<7TtYPNBq6B2bN;F-16iw?R>L$Y~t;qH1
zqmfbggUTkiSMFH*NZ*kk>a;V#E7zPpdr(GlnhVK~_goH_b&l?Y_tCaaDLS0ina;em
znV(0Rgo>)vcwa(}U|FhjUF^p-h;d|MD-h0T*Nq%wR;)9auOW%4;v#8*RcgAWWy>t=
zf}6LxS_Y8j$rl`ci#%LT*@K4D&y%XvAM5^IX%6;`V7)wpbhQQK6c<IY6G@ECyz>cF
z?$cE)cTb74#FMevjQ_w)5}PN_)Y49sT_fI@Q@OdE|6v|kR>w-5TQSQkhs)e*R$D-b
zVYDNIl8scwM#hqDL02_d+2D93Hi3PKb>u4RukgO($`4@snQkj7iaY9sPHaEP&#d}t
ze4}UQv3VtfNMAosO4#Bdnzmcnd4=^^3lYh>(%Gyc1)AoX2E4*#Ih{`>iGl4G*$h8?
zeOENzr#ID^FELD;ABAI54jVvZ7EkN!v;??UF$mqSBU4p$%3R*-N+V6)Zcdqp9gU5I
z+>{VIZM|$E145hXJ9buqFDWx4Yh}+NUGi9TSiRLUqt&wZMNZL^W|GnDq#Hc(r<4QK
zRMfSSBjx1$=uD)cl5Xo7*meMkc8RL%B?v<Ikt3?G#*CqJ%X%!+w{gU4MwX7UkaNq(
zr{H1hT_Kt@7jHe(MVdS!TD}UitS`5gx%7gQ&wb(s<`oGU#(1g5%h-=-REwoaJ5jhU
zINa*9^+K_2Rm?y<n<dqe3ybx0NFZB5mTE?G__kM8!^zteu|E=0{_%>7jcX>Nn|2f7
ztOB-xVZL~2@Zj5TU3~MS4?fR4roef6zCaSl5H=uaNhCzJav#>3qjBUF&@`uAGwmF*
z;9I)RA+NHCT`(jZB;#7Ao|e)@L9!12j8whYt1#ISgEh6_B_mIWn`ch#z;Z`hGx7+R
z<RLAA&APE=Co*Xiq%I_Wj&dazG4F~iB{!a=r#Kn;DrQ7gF^66D5Yw(3!Gp1(q$(M6
z3?$G-a^7e^`H@&;;_NgQx$pGUZ7q&AHHJ*KqRlkf*x`kUV*<;r$tPlQ2`L@yG!t#^
zD6^a^SRG$-Ej=pDLjFPEgIs6phPBgX_t#lJmNm5jA?k6>(U|6>NV_B@czNCCSUi1@
zJnbWSy;$g01tdp%Y1;v^*W@8Fw}?q6=hPHZC@gMCW?M8<(#g@5?zZ}Qw4vE_vr_O8
z<fcaQUsIB|=GwEF8D_7?uw#YUNRX`|KUrx|-pNg6g!bBjm|s@O(6vN6QidpPq>J%w
z<Wg&P&nr}`&HT?tq$wSC-$1l?H26(|u}y97qnxK>Z3%wIbKdC}zs?h&;1S^9BO<#a
zpP-ncAxb8{_d(%?gB(P{z7Je7!PdhM1UqC~oyHM@+v7t+pCVKsg<>gug5u!D8Y{gK
z&*7L2eT?Xf8fAroC=^hYJ{n&|)j+&}$`SezzkbNN9qFsDzGFwn_Knk?Jz=aPH`M3U
zByHE>PujN^#-eGpV{8|>;lRvLdt0iW%@j5k@2M5e>*ZFE&GzVZJ5F4Ky<QRsOXsBY
z?5?)rNxQyq|DtC}?cfy$@3~{j$@4$bcjO6c5AT|-X0ydzn^w2Xoq3kwE8{yZ$r|xA
za(=WeUULuk@l!_!FYhb1+kB2e?o>`_T{|@HY~Q}?h?bMK)$U1J3ud((j=00>s#Vu&
zhgxk~LQZ$Cp-Fg5DI4#qO>dre0CS=)VZ%Jo93MOtmCKg|f4pJ-(8Y7V_~^);zna}Q
z<*laK<#p}L4KKHT)wOp7%9?G8i1d1HvS_*Kp&4$=^74_`>z8CwNDsI-V-umibA2bq
zl!Y((=b_vD39(i45K|LIBmy56u*m@Zymu5Q$B&zgf-N_PJx)hWM54E_=XtNzh*ze<
znikX0i;$d;y72D1B;IoMrNK`ww}ab+E#n{i^U+(AEjM5I&G8GX)scihZLv7xEK<4V
z!;9iQPaYLK&Mco{>WjL%XPgzBJv(a^&LFvuxa6rfuU|SNU6!Ip1aCZkMsTmb;DtlJ
zcv93%UcKazhsa@x?e`yh%@`8z2M=C(aZ*FFl-egQojB%0_dambg`J1BcTAtNnr~nK
ztBD^4zrOZ}Up%_?m&}4Gvs>FbHU>Wr-Z|#_nWfYbt}>ABu$zssT|E_~5bZo+sCV%d
z$yut?H}9Hq*l)W;kGnRqB63{h@=0AV?6OA3?N{?$vt)*3PO;hk&wDyI?AS01aY(k5
zbQ^sw0{76&&lHQ|Q>V$t!cVPxpx)?ysv$Nky!1k-5Z0}b{E@SPZEf!uPP#p9w%?PS
zKQK_7)|b#zxw;;+3Wu4Cq=E|P$a+sQdeW4UX0!Ic=z0%0Nv`T#d@9GTst#4vIp;7l
z-96nsJvq-#p3T~vSG&???J5i9uo8%jkU(Gr0t6U=0TFD#0kDmE#(p;8J#2#wwt0Y`
z@gHOSkhb}Mw|Zs;{=KKt_Ec9_-BkCSd+teJyL{Wet%<qCVC9^O^fV>_QIi8tZrygM
z?^DxuQxDv}P`|Np>P$qA=GWepnutt~<}<yi=qooww~Swz|4>~!LhEW~hzV9bhxxcK
zu9q?y`s>>x@&P#DXiB>t=|9|mQra<H4{q72y)w%7#QK}=__}ZPeIHylN1CQOe*DDN
zXU>m*VS1oHqq<bz>#Axdx15?!O)ZxLuKHJI-?n3}vIt##u8?tUPt8>hP29EL=b>i)
zJUI}V>UUkUJd2(St<vBPoGYf?tglkrR<o%{#L3g(Vb5|mBa=oC8M$1ln@j*AVa}aP
zVF%xx>Z24K)FE1Wo1@O=17ajz$2e8T20cbJj(C(vuSCpsN{LY93w!o60}t%=vB>_F
zEhkc()VWv<d}#jG`*3!<_~REstg>zBcVhHiXKq)O;C+|xry*QDaCU%w>l1ef`o}KM
znapQDa@Q9pe9iH2rL$I7n*vLpW4{yh?akct*jS09J|Xz-r09Z#bg)B(J-lo7(YM^=
zx$oUiPN~AynSv-^dH(6Xps-S_AfM#<4?Uai#v1psSGiq1bwr44SpRc$1F61KfI)Hk
zvLT+M?+&S7XRDY@M7|fC^wEx>PQ-OG6P?HK$Dw!JLjo#s-f+}~IDrt3sA7DwS7+wW
ztY1~@A2gYF?7wGr{56663)bbEA33|@5M-2mu6NrDmu@fbHkWH?&#Xrg49~8+W4bRL
zZsuDn<*JZ5HNWHQ+82ihFH$d^TirI&`K)&(YEy5M>{HuU?yJ6$VGC31M;Gmt2X?Ji
z1`dscYZJ+2r8KcV_FU!7N$){VeqYJjW;Ji|Vl`);*zFmSU0l>9sq@9&v$R&J=_~2E
zV^1C>DOJD+KZ1l`Kc=3-mt+=^xnx5`vIp9D=h%m#>l>erPKSKKmIbdKyC#by1SH|Z
zz@5oqTSw*yKJnYeBiA3tH8QZ|cd{?ST_!e2hz-Pcsrw-2<p5a!#&Dv1GT@kkZUZ;q
z9IuM-0_R!O<5Wl{q*J9pqP?+|#=mB(iU-JFd?);a`1xXAPf8I;XHe+?GSzkOAs5J<
zjVwv^h)sW&19kUqWUq_eEI?~WOHi2Og-ovEE`pVVX+!P=|8YK@zhpjj)lMX#I5=8&
z@9bdVU_V1fj<m$Gv70lYMkYBvNk}?sC&~556TIL=S9XUPp8}ma5BNG)D&0WBYXESb
z&3JR=6XX7HUvhLg>DzA3?JX^R;YfC*)v9BU&)v@;7oAGSMkKhsYPuq3mqp{L#Ey0W
zuu{)i02xTEitZc@M<K;!kFp^yhFn!?TbS{(29%mIZ`~52ZI93G85`-psn@u75-E4n
zTSTCiCPa5ZM|LVB%y@Llow6mC%5z54IL+-TO^=T==|*bH4kWPU##SaL+2HspO$U<c
z0LuibC1Xg^+=4Q&139z#N_udhk@K}D$H%cdW9oYjmxQBBt#Gq6dw~rWJh#;&ND5Yb
zXPAjk&sPs?k>NRgOqVUKe1PJw>|xZ2fl5W>5+afa+pG`>q@v8y7y;5`3i-Zx^iE`I
zQ<YXW8xAG6m`F+Zh!r{%p=-7FPA^?4m&YRBz|l}3o3U2SNz)Z<Gyhq(vY~JeKEheX
zo%9M~T#s;(kWxiTJIynxy6Ag)1>P9b)n0jRR0+ohN+rAh=oWwV33_U4kh*QRmpQn|
z$GpwHP$uv5j^Ap97lznUgbUnRWCG9V?w`1e1C5C|k~z&Iq0Z0WaY>#Y)J>EgPTTh9
z5!xTW*X>bv1*5@swW{YwuJC3+_!pzkzdV{#l*tD&;XeK=;k9E-Y_O8cA&FTmn(zWd
zJCjWEmEvTA0rE;~SS#1dF>PTOd5J5fS!7u&11*CVBOFD0DLcSmZxHiywCuxvjngRP
z>ZN;4q~6Tad=z=*l6b=7UqiA(t++5VV;AiM_6(Adi_62Zk`XfLYJHyM`a=3JJuT5R
z0FZg)ITnowr{1e>yMf{+C&%?ZiesbEpxQ^pH7bfcYGI1aLiF0;Ig8w1Qus<73(2wq
z*_E(X@CZU3<RGL;xJ;L333(E7BmbbS1AiuznQi4-AU$%+bqx;hC_6w-BsdRAWbwOz
z?DpMTP%c@<oGL+w4mFasjVuIM@frqh+x(HNZ&2u@NZ1%@o`Chksg?MFAp-)b->G_&
zPe5f=uX(%oI)&gV!a*G1Bc}#On(uN9a1a}1qEsgk0gTUK3`B+2RS*$AO1g_&o6y`W
zCd<gYF7m_k3PG(bYMO%AmkryAOtzA9Kfw9gHuo7f-c29RrzQuHqtRtEbSPv5w^}JR
zKITi7Z^%p-7VTMBpwjhp``F>d+ou*8w~ypzq>}xmEYhQ4tF^tafb?bk)U5|oLCRm#
z8it(kL}-c)ON0O3eo$7$!PrD^K^q(E{BX>h^}3NH($;-tWUh`Rtwgl)=({!KdtR&d
zNx|3<CIHI}kI=j~W0e_?h86J9!xwLxI6_DKemmF~%^DGUI8;?D=X_gfRtw|{r;AA>
z;P*58mC)c=%wp9(Pw|D~+P=F3m}K#QKOGGYg+g)li4)IUb-OFfG++2p@k0f#i2eI2
z6Yw6$3>*E~#EJ3$Gk$XIrg}O*y32L!qha3LsD$qPnybB9TR1#aoZcR!2Ifm2DREhs
zCR3B+Mj|mgy1SUOI3QwE^l<rz)Ie%JX>7aZ=5_0VN7?)J)n}QPzo9C++Bhpbi7ce@
z)wl4pTb(^<`3&=^k$s&%r#=4YaC^MmRHk-NAvIb0Q0YY7ljdZ7sg?Fr8Fl9n5=CN@
z|9~jC18?j6?N?7xe%d<_iv9EO{~G>q+MCm3=ET5xs;7tR`Q)$uN!Y>sJ~BWI_DsO%
z7cv~^#UY3;tvKt`roMSI%5`J41OappGA9vDjK@G|O-KGALYy=A$c#l5^U_FR-w~yx
zuMM`{?%+Ppz?b`O?!5c(wyT#eedHrQylJg(V%sC^JzEYPyn6QReepz&y3?hFnAD%W
ztLR-E_;0m@@TXU=>c9H*K83k?R3GcDCX6v-C>nV8rD37IqoeF<^<`tR!S<HzLaey*
z8s_YQd++<L&d*0iR;kOLq9SrjE0N`3=G?a5d(Azbe|nz83T^8=h2(fI!fqac-TX%M
zoUjH$`H&pYG0RB=jR62*p?i)s*4cG+zrz`mbg+9Mg~6)_x%<__ix|}FBjt=2`@TUv
zB0Lcn<=uyVhzLY_thp2jhYp*!`R^Fq-5xk-=I%N54886fU|XTl_4}_}`B7r_TaQx1
zks3@_;Y_fu*xK?=uRM2ohQH@PZeR9nVl6m79ZJMQA-4KQ^U!*xhQBTP-m81>`$Eea
zne{Teme{d1zFE8WAGzMNZZFM#>PufR(vQ9Nzkg-_C*+fZ=U(&Xd+*I``Sv&HOVyM5
zWB&c$tsb{~?Z%K#Is2)1Xq~q+uYcvrYkqOV7e~&8%f&=)ZfFR6mgErmy6_q9hdq0G
zKHc-ju&DeTHg`nHb|(tNEr;E9%?!vKK;{j`Y4a~eY(whBh$4NqBQiVEvNKF@ss>-e
z^ugo;lX7_Kb-8(SxSax=`6}?$jkiI#{U!&-iy&#22-8DJ<gL_e>3R(Tu`TTMoEn@L
z?$p>M7Wf>8CNznX1db3J!Xk<TI3Ik8q2ea4vbe$FyUqpYRg==mCMH9==y>mLOo7-2
z(Ktnr=WS;)fG9q*Pu#uLi}bpqfHDgqacDIkU%2h&xw)HfTS(+<fYIV2_+>n1>n>O4
z=O^+@6N49?k=55dpQ!43CG+Nc_1t4myp%rCzSuauZF1?hdhO&6yBac^*7Sjuu*m7u
zg?+~!r3S7<if{BL0T!@DZ|EtwB5Fg6RGs0d%Ic6NA;`9&FP3#PKRvkA*`Ji{&ii8(
zswdblTDi`$2xQg(l=9(tJWc88q(DWs<a2F*EIi<^l#viM-TAoewL4!lRmIl5$m`0Q
zj}5lx<Nka!R@=qL(`jUG9L{7$ePQ~KkK82hT4$J@M|UjG>=)B5<W+DD^bX*ERky?8
zw0K~8y|p$q^_}-j77bxu=xg^Iam5v()+Z)9KhG}oPn^}7f?Ay_CyVa7)mur4taaq@
z=XUOV{L-EP0OKSv**7k*W4>4}m1wO$YNS;cf78N=m;AX@I`{O`x%r&`rTxDzdpz#c
z@RlPJY5!FSq>&*WIDj$e+mJVP=!Zk->R~mQeC3_-IFHO8TMNapV6<_xu-sy)9pY8L
zkwfB3myl9bcW4<V``F-V#mL3eth8@z>{yQnbn#C9C*1dO_CCamf41k#J>T#7v6DY#
z7j+|b23CW&QtyGK@w3#=3AH#BLS~LL>uf*+V=BKYtaJemohiS$uOKV9kBBL+5&~gG
z8>H6dN`wx`u}KR8VNtyl;ckxjzcCS=o4O(iZY7T*-xZ;Uu9N`XNDcByW&n>PIeOQ=
zMSe%gT~nWf9|VKg204=)S@=RqBv0TVk_e$qJhNdP+n{pLHrboC;Md-5a`%%A#756H
zsA!x5FL1`BOFqu88^WBku_9uVL*IC?i6~7R#3+RhJLeAd=SUA;t;zY7v<<w#X(s7Y
zrrR<+w9x_QJ6RJ^6k6KNtGA)P!)qe_aSC#NhZ~XeP8_uy-UXi67+7bJNmFotw?5Vi
zC^-cZ5wjrqnlmKz^*2)`x9aETb0W`H<vmp$nW)p@-bAuiD@<GNmE4r!_9&rDtggqa
zRVgER=0<~2Rkr+d1C7u?SsuujPu|`N4Xx}eNs;eF#R#jU-+6OF*gAMl8<R|~oG_!k
zNi~?u7jz&G`IW)fr(bz17Fr|8{@dv2Tp5CP)R)((IA`&c4YQWXvoBG-dB6ej`~Xi)
z(rj3>d<Dj36nh5>bCx@uOh)GUH%98=n9mn6*x1mlGHdq=nM{HDP9+-E;@)yo(+iQ+
zlI+bD+4?1aMGHmMzT{tU1wL~8B!BYcoh8W>{O*7eyJxCgZZ{@$df4p(GLe<djE?-p
z?y=7W{B=Fbk5&Boh@QGPW0jJ0*3D?kH(6uT-pNTpOH0_f<&uFwsA`rnrS`R*djzC1
zVT}G%NVClV%W8r)7<TX2A|_t>myp}gsorcTPDhxNnMLo~ZMXf+@#1RhvROz35+0A0
zoqH(sK{FgVf(%1)G38ICOTN%ZIGkjV;6SzZTz<m~>`#C^QWXITB!oME*}h?>&pv1`
z<>Zx8C|HquTkdQ$`pI-CJUu;qA`Lk2Mxij7lw)dZL`!*O-4M%J)9=wreRA{s+FE(f
z_JEv~Q|XA7m_Jed)W80_2y>8q#HaX%rYf3fG4Vuk_OSKZo0?0l%;Y$%aJ|jO=%jDW
z=Lx4}!BePESuKW4)oyAf5QyZt<5Lm9Dt10ht6Wq%M~x1sxj7Hz)2+<3CmEk;6v~Oe
zi2DrPIH6KKfM(n}JiNs>jJ)5yogXM3r8i^Pp3y=+J(sSIdgIMN)X&hBetzL^I75u3
zr4$1r$KC^`TRwdFjw3#AvaH+I4l7x3r^H%ywlun%tMv9NW3HMjIZvy>&W|NC+(Me)
zxJ~b_3A*^gv65h(o6`f~Dm+HGdZFO!3mjUFrfytFy3C-sL+bm)O4OR;J)uCNSNP>a
zMxy`5@%LQa@28Ha;Xsh87I?PU&mQS~=>ASe(Cw;k=gegwXfG}8AEv(?UGRQ)su^%c
zZOI+=%P!bmOIriTg~qrMtu(up>=PC6>0bgs=>0t+vU!A%U!(+$-f+(h6`+75NMzxz
z9~@c4Q$%A2mpI#5|GU0`&U*g;`o8h3O#}e22=cFsSBwX8U9Lg4XM}q=TemLf=|&B;
z`nxQ~VQF9^n+|$i7TD!j;3i#8Qtv0+#c??#Vu*7_c9{Z71Uqz2p`UX8I@NW{11|#N
z2@$<eOSVd6Ug8f3hP6>FAmIq-?jDXq1~2rJ7NHwX01g`FjKJnSPC_Aag}NfaKJ60X
zQj!Z=Y83x%30hWgJsu9n*Tdmp^msOz%pO*aa8UJdpHF0Gdh_;;l}R8BnEFk+!RuFV
zT({_j;@Y-GvEtvM4rJVO);{|?=~8B@wS4%#qsR1iB|P<b{YpUGJ1eV(Pc>A4#Y6^t
zs%jJ!-muor-Yoa3NKbj@v4P<Qi~dq6TntA_*=EigwT!Z%s@{72;?R(B`ybfBoETRp
z`^#G%Ips@7#CW!9>={0knl=ps8$pj6n53^%o3Rrd`}8aSbm?7he`q=7H@vEH>T0_-
zHFf&h*);y+9+lAPVQ7b3jNdyS35BER^RwuDIvfprIG#-U)NtH=ZFS4QNdJ5D0C=0K
zCSPLZKe#)2|BZ#EWV)VASbU&1(+tc>R~JK(!1#PVv2SGsm<S{L2i1LZdAI3zo7@cB
zw_{~>2b*76z4zQboH};Y@Wo}JexcFqPo>YY(fQQT`GuL;h1U4{{M=`6&nGgjE3MmY
z^YY+V+Jm2KlxptFp=>IJZ2r2k=$&ZMt7`6z9Dm#3BbT3B%%t;?@DEqxfG1a}Yw>s-
zJERYHZs2EOjd~+;!hNOZTZn%%r~*<2?M8mu2dFnglKFG$2ZUZQ>$<anOte?Gkd9!1
zEBL)Zq!Kda$h~$dmrXlMG!n;c><paE0A{>1Rh=(b+?}cBOjKNPsDdonq$+3WcCKLW
zNhUBUwtIrljo`1%Nli8b&LcL+fvDGs>kerN&fsQalE1{o2QFM71JVM=k>}M?x^xEj
zBos{yNJO1Yjt#-f>9Nyua`n~f9a~1dMOa8{;|J11+z!cP0~2OLG1ToVxyuIek_WoQ
zpe43Iv`lyic`iwqK$nhjqkzH$G@aB)PD%41BBB2_fj>`?p~l^%u2@M*h98d)o>QcU
zWB?n^dH2+57fHlfBZI`J2)?Hy#yGiq$0&Zb@3*zcnbw$(;q(1BEapXPpf84meCpeF
zKs%_io|k{u(g)vq_v6AT*Xhn%7S6rz9f#7>0C`T1FIM~QK#GwACj(RIoK${Yp_CY3
zd~m0}{;(^Z9UqLr`6fV5<h+2`aQhUyZ_4Mrurj3?G=Hf%b@$!s{?7YF)gvZu(q#h(
z&QdO6`rLom>$zf>deY0#L7UY)<(5#~_M9<1`rzGWCLLsR#qm?uJ{e9oLT*j>TELDp
zBPn`~JvJScDs})wDzTn}fYW0vKs=T*!O>>+mH*=n)d0-x_IZIDE%*#~g!<Y4c>0-d
zfAg7Vzjf`h80l-bk?Z7nx69);8L3Z?YVaBo=pV$A18gA9OOt&3BtrG>=EQQJ&w#W=
zm03H~8fuPQ8_n#z+={$8)jp=``I1Dv;MM@+3qK=w7QkmbR5Z}KcGegd*Xu%N{s3Gb
z0zyh=*@$Io`TMBcXm<W<hAZg`&+G%3a5d2DDKTICDnRIxjp5Voq`OR+r=v)rq)65c
z{!EJfMhpUj|JkLtewsSDZ>e}>IsVff+|<|>N^kAzKhkK7ZymqkSVn?7h+Fg?7zQ+e
z5K4FxCygB+ORW^s>4AZvBGng(ga$mBVzjtSzv;X043&{KuD^WjqK_JjWb5HQYoSCD
zDF*4)h%23nUC5P9B`oL(KoRBu3(k1_+5k4W?o;nmS|x~<p}o{Q#-_IB<FU-dT3zDJ
z;<f1fgC5}Ssj6;{!8;7ddjjqDX5wmufyeedmG3Rtg<jS(1H3z-UhX{j^mqQ|nRk5a
zThuo)qI<N|fLF^`>It{k>o*y8P)Dv?04xB0`zOOgle!igr@6Uk@z!aNCp0;0NxFw;
z`u)P-(mH)@bhlYcq*8#Xx%S2ZuO0*jUC}26Ep2APt_15v>S;C-2Bx+NtRS7%R7ngR
z$s$?n=e@(y2q(>qy)BZ9DM8naqgQ%fxEpr=3kX2#qlP!MAy&031_%RWLq?W;5Gp=5
zHV}lDfYiZ_a1k#1UD8KdxM8y6z%Q?|Ih;9*JfUu<sH$^D&N+Z3;pp;)F3%(nI&6ec
zF{%V7z~NZCy1zKBaDLciUJeJ^ypwPhau5y32E)PmCO;)L6NXC;hn+h25<W!gMKcNG
zBix9blZ(#A4gGN#_Qn-_1vf&Q$O-O)ZPejG__-<EZ3ua0tU2-U)0C%Nsx$#=DUK9=
zXJMwgey;5eiOI8)^}1a6O0@Ie!(nQ`J?%CIN9Q8;sH;CQy1qAY&`yor6X|88q%_c|
z#XKLoa%)ARraNC<-+DG0Ty9ir*{ze4H{SF7>^(DlJQ!VR<d>`c6McF-5NOvzLa*Q%
z6&ETg)*sLL1L^7QeVIVY<xNKxCJVj2bH372wte{@VzGa?dz9W<O<SINsn{3w&$$zB
z%^#QC@lbSaF+D$EE7<+adwsbud?DjrW0YxRt=!6;fkQiD;WRsQ?GN63;K-wo9X<Ty
z$myl!6DO9JPE%7wzmf}&=2OUqH*o)j!NFm+Or5=NU|X!06RbBReYLN|T_5rd(BioG
zalUrorlGNPD8|<l`xEzkaP9GuGBVsaa>v}G`#sIV(q|8_*=(zro*7IA0|DeY_Jw@O
zQgUo>y6DHe4;rqhJy@;``jdmj(ybp3Px}U5b7WuqHSxhcqa&j;yW(ZQSZWiQV|!BR
zOxr?!8}|ueR1nAbBW^0}QSy~oER_sh@YiAmj}F)-p_IPZeCNfO^0$2lPbBMVB9eUa
z5n<<8)Hi%kA9m?sF)9XzC~N;4o;Y&!@z)++I(=$+<<w1(%f}#>|FJO0eZFU)XC3$s
zG~CrgbcwFR1ACI5r&sCi^a1(^eS$tq-%8(0KLL;IXXxkY57D2be~<os`b+d*(BB4L
z;{T%mKl)_`u;@&f$uMPRkeOnZnVrlb<|K0~b1(BK^G4=b=Do}d%tx6|GhbwW!2Fo`
zcjjf7D}bj7x^-yOncFbVI;vq%1!gE&KrxZ)g!-T!A&O0bx19+O#^#7QU9>#R_c~^A
z!$+R3*MMWzRTLBA0%1W`LJ8!bX=gSB>@F=`|9rIxu;vnek<B&g8w7<KAu^#lTq6x4
zqJgu{gNz9I{nuj{NwM+FZyb24ALeQ_&Y^Lqv!>O8K$EjbZ6HKQ4#Zbor$`G)=b#Gh
zww%Z>sM6`M)8gxAfE)yjn_X*}==#Pj<VU9fM*;)9o@0w{T`$2==a2@Xa8SNu6nE+&
z&47&x!$ex&9e&6E84k=CLjZPT9Ii`Co8^*jf}J{F$;+zQjwc4;rFh2ii3X?~coMDv
zmXF-t9X7~Nq)!fyLW@%ktBZ9<Br&4DF$EjrgZ`pJc+9d*j63O=v-4><6#{VGBvS<K
zx0^OD!KXZjpPJxpjTGN7>rFW0+X8Uxa`;YkLd03zc{T@O47Ff~*}yy@T$S)aKsn+X
z3Q3VaxS0&5MNV<W@r@U7f&4-$MRD-E$IYhQAW}DxwoO!tPtu?Pi00%9ZYRH?)Xk^x
z*QqZ@F2Dzcj4L@e3H!!_M1*wC$uuCY^G(2L5`mk@ibB1G)c}p$VBn-v4kyQ>C<G1|
z=n7^l`b%EE4MijQ1D7H4a<i$Vqj=20Rf6;tsoF_%$rJeQJd1{7wdwYogfYO@N@^#t
zn`C@bD6reT6nTzx*IBXzVx&dtW?XB*2u-E{-Us#yxL`JTax)$#iyG!EjJc$Y&3Azj
z#1*qXAh`2_UkI*P<yck%DwgcJ;EGy_m5|qf=PMAThCTgF!4;>fwTY76?i@@}F{#8W
z*bIiTF=f2KqB7ikiu!ME7dV>Be<(7)q_a`M%lLV!SMlV^Oms}MjRIV<^QS+?J@k{^
zfbcRi1!Mdkby4L4g1SxdF#Wn76Jdl07?)QSRS|$r0e?u-V{DCJPtl4`N>ATJZwJWJ
z^v!>-r};SV1>&=0`EqI~H5Cu~!&6OFtub`e)s%eDlF@FSO6vgAQZf`An<-Wgvz|nQ
zi})wgv=U&36@L*GGG09meZ5D{Xcm-8Ng>VvQ(41)sp_$9zX$oGvw-;(q6`FdEkHce
zf^In^`Dlw5qbescoS$JT@XzqUlpYb?j0ulkP6@k#S{NQtqehOPn|u90?=wUWZp`Vq
z@Wea5?C%FiBh8qin})5-%V!Z(0<=UR<^jc<pmUjqkce9ACr|$JXJv1w5fKkc7BIUQ
zU?NMvtV4<x-irj_6g+uFL1QJW6pxpf$3s-`Brj>N2S75XKkVc5_iN$+JaTpaDB#I~
zKCA(VF)aQkm*f+_Ky%`5c@^>>Wq8F<3<zMF3H(uy;D*D4<N?GqE3Htl-0J?g><)YR
zs0)6YOZuXaqG=lmNpm+LhJaVufgmGkTAaZtFJ9I>wkj$QXoZmEUE@4aAhdJ-{1LQX
zVMHrs84{U5xe_0Q+nSo872PJN7hZrcsY%zOrAU!@Zqe2fwh<eHPlX+xrv+X2nnpS*
zd2a{uBSQn+kaEk<;T3wrTwDpM0$WPJbU~G4IT^^^!LXlzPYzqOoTS_lm;EguqD$)2
zz(HoLMcI=ELYG_dQcy7nO2IaBGNJ-RwIZ;718L?Ox+L@CApoMedPB5$T+d2wjdO`v
z$#ln)QxPdTnAjyplm6}Qb|M%_7%jf4mn%R8%f;gv-^&>>5EKAN$YeqW0F!CYVa3Bn
zOkhsr{lK0t`ZdGU6hN^vNAW)SnPp+&P2ODZ?qDM^@wzKa^DrRhfR{)&TwF!TxXc**
zmlPAg;bMbrGSQiM#ijvJPY(&+!9srO;cf5v)7LV~deEKU@pftIkYLd?FB!B7Cl{Z0
zs97w8f|4()2<~>no(G&EOGyCai?h9oze>?Mz~qB1-%{KaFvMPf?;tir?uRRsUqHY^
zSn#nqH&DJg<frA5EED%s?LnHy{tTWklBSD_&*I(g0PBv2^^lyC`eU--k_|88p-MhW
z)s3o4R}8-@Gr>?qvuUFuBe#oG;$&V60MyJ)(+H^1*#Mvv1+KKGcJNCVcx-NPRTec}
zB7Rv)#5TPBfDX-2G}7e)n-EBIF2vYqeQG%oR|>D(=xtOhYRqF~>5hxdFdpC}N*Y`+
z_(K%Mi!}~Frn<rIX!P~5yEQ&YasIm`xM8rb$E~vU63`@6#(JAB7-E4D;mRMdlduIw
zW!dimfarGt?MNkLKK_v)E5<$Uh$Q$~D>9>SX3#gR`807WpXFRWgvA7)jb`tIQ>>(@
zvbU-GTydFo(N#g%9aK4)<CLuT<{+yAA&yV^0IQCzUoaBEFJfK_$wt974pUsjpD1Xu
zWT+M!7b>RUwgRm02Gay6<8Folzy@^1uz%=_VbFsTFcl@3mI94n25wO~m&fBpq>Kg3
zbxrgl8i`X~thxg<A@D345`ltvG%EU{wWuH=NwMExxyhgi`z(_JBw=VPfWQ^+YYZtm
zQs}(Qxh&-ySzX8jK>e>pca8e6%wniCpOJ{WJ3kAULemvB{egZ(VncLZV>Kyk0nnY3
zx9e&GS*i9G3o?N4&I!VCS#rBM$iq3v!*3Omz$GGR4BzYdN8mC1wCCqNuTXWW4g9Ma
zKyR&6HzR`ajnq4+cLN9M1JsYHe+53;FQ}J+X$lZZq%H8%VLC(i(k*&|UW5!yd_6Yz
zZs;kF6uoKQ0@^NwTpV7Aum+aw>j#!%0x{fuVB^z~VTm%Yg)Jr)*MXc9NXDmd=XH_L
zsQ|x1EFzx}w>CsB0(b0u!HU0e`PH)xd2gdNUFS_yzHuKKw`l+cQaOV1oclnB5VRmX
zz{m~>q6sO6m^6vNl_TFBSqKWSuJbqvVXQlnHAEHCTHNFO#k0g^%2C*L3-*wDDMxk@
zs*cD6Il)KDbR>q9NtA8ZM+&0T^#j#I7_sWVc>}ri`YmLO4N0bv6uNFSXfAR>;~xY$
zr&vfQxcR@1y@27nUgxhBwo$heJLrrS%85~qK$tR}p&)W+9b#fVhkuZj9FYv-RD>ep
z4+K-ZM7)pzB6~V}dwBK`i4P(hb__U2cOV-PeWW=+q%TuIQ-!2Li<v`#cDS{mhYGRX
zonIt&i#~7W;pgA?(Y^7ygh-!z0NuD}`H6^^Ro4bBcPPn<UM;}uvX>2`nE)m1MP_50
zwF6O+mIrc(co!rC^Egj4QJ~#sASci&Zx<}DZb(+8B=c%77m~e670{FZ@RGkI*{zF%
zXTrmQ^1~IkKM_mDII)*)9AN66jOg-MTF~S1$2lrMCyObym5jXd9b1x*8Y&{ZB$pIr
zdD%6D1ssT&MiI+9BhddU$`oro@!Lxxn2&_$rg;s)*Zq<KxLM8g3NCAJMUj&JfkA7}
z%!BWwDOq^sn>Me)=;gBMs08(#=GS#5kkFg5zkch{V*my!C+CNTek-O}e(x(UN>KLE
z%o9i-Yu4mTv4oLMP496R$D1%F7MF~~uBnr++=pT{D)une1ISJ6B-+USvf%Q=qf9hK
z7cD9lyiwED>Vz6=6s8Z&-g^94bkxj=-at7%s|S_l<$jl_SKk~6jSNqi@-Ls|UHkyv
z+ypQ2WnC4uI}mq&4*xQ8lvk5-As9F%JTFUtzXiarK>0*p6#%!g(FUk5+8d`8nThjo
z$K~k}VbS0B;Jccq%H!L;$ph3a)T7mHF254GEywP;;nZ)nZVCRX=f!OtHTH}iQ5HuZ
zNlck}w^t+RM3TX3IvBk##jd)LGb;>9$X6-aCxQs8zCj#jjrJVtiwdp*7Ph5)$S{Tt
z-WIsG2(rZ$gIYYU!|P2^^k6|S>2y)__0mSv8)r4en~3NEZ}Rlp(u>b^ezEs6UmoI=
z>BiKP+|~9)S9Jc|TejML*=$9_GTG`YjNEaWQ2@ING+|d5(xPZ`QQ#D-v`m+HxPw$#
zKtn6uS3XF68nT{HUZVmH+fZlRV`9L^GI^P1gC$XnWWz<sn{syKa_7AtMZghrj{<|f
zq9`VoO{xxDXy8sm{g-1)>MI|5U|;d9U0&ZYHLW#94)zZB^}qgL;=l>>wf8Z%axPAM
z<*l__?@f*!_CA^kd1AINC}eVpgeR5U8XbM+`9JM^k9m{kLsY!FjIh=!URFt?JG-vj
z5~xQMuPsdO-@gjQa5C7Ko?foC2bcOAo-?00`1J1anRYu=cSTjpQ>-1<<DS$1_;BXV
z(|?q#o;`c-O?7x1GON0t3I^99N4G6^@V&vSR+~m2IK9eAy$sD}KJE3MWFkO<Mab_Z
zP2<ZvrFmO`P=;+>%Bzy58VOFE06H+_3f6<X6G+gEb&dFs{iP7+zDcpb6pA4#a+KOi
z?Yq7%Y0$tB-bS{6j<emSS`m9UvX{HQ3T&Qjn17sQ$$6C6OTf&X62Q;9oPEP9<<}Mu
zvS^_&1fy(lP;l7|b>?r>(a2WOoQ?IW-Zf?YI!`v8yRpClRb_MKau_yr59GOx!klJ0
z<wI}KZ5G+GqgUX!-M-<IB6@)c)#c#c2C+%uUYp!UEJi8tU1z(CP(PeQ%Nik0G8h%8
zk{!e|=gUTU6j2ypHLEv;_|nw2(14JbNFDd(2DdDmS3CcE+uH(l2EL@Mw+Tofy{)Ud
zYH9J&mH30f#*P<Mzcx9>2ixpqsisFBy!4u}S~W6~M+BxesMQ}Din_d%tb}|n*+<X$
zr?c5w-7c5P{UTRl5JqbxSS>T$GyrMe>ow_O4ye@Ng@_IHnL{a8z_R`BA&Y{@8!qz`
zice7V@ZB@>_XO5P5GU-3!KIgrFmKm1aX8bzlhP%)nPC%H32dX|w|$tEj0vOMTRXS%
zTJMS%ZMQnN>q4!h%RE59e>`Y-&mM<kn4i8Y*m*nw4kwtM2m7(6xELKQO{5Npk8|TQ
zRUfa)krY=PMiHfJ`5}l2Rs+b#zqK+q5&%N7D@yS?pL==wEye9#;9<K}O7xh8852R)
zq5%AJHkk+;Z&Z#?$9Z*FQ^IC}p<DiK>C@r90K7&Xf4;S&P-v&~S=k?M4p&0eC(iqF
z@d<ZrwZ3~_d1T+1%@1>2rU;)Oml5W)2qFXuQ>(hmmn#jOKHnSPJ}8yLQl<a6Z_Cjt
z<IW9EHQ6)O+~HtNS<zl#KJHF5o26}oCtTU!laa8m)pscto}?n~$XrGQ(4S>03)SEN
zm3izqt*WPTA=XFT>z!;R;<6Rt>COY1dxaOI8A^|7yE9O<zgeW}54Nwmc*Qkje1N9w
z*A4*YLmlAVKH4o(pGtqo5~-aZfT|QE3tD~=`89shb6b~wyHw}U6Xvx;CB#OsNrQlh
zbA*Tuq9nwzDaa7|>Jm7a^MnE53RHR5sfS2GG?7EPmx%6?cLE`WClBpCH}bb5JHD`2
zotQ0L@{HawF!jhW?^3Q27~ZpEeE6}Mmm+K=+FX8S>;e}{CZ~1v(EigS-y1pl+iyDg
zx88w;YTd1#EEd-D*#Ud#!2Wjqp_w-}eZffImN!h^qR<le0hMF+pIKkpd+L-rBEv<g
z)Vz4?D!{MDcG!bkmv+xn{;AVXzTvRzgD<XKxH673LuEj370c<`joVgt?f;r5I5xFp
zw)006Y>~%yT7#?ehgLiPzU9PQ&YZ}+>&0#NuaET|ux}m>Y>eqAg&O>8ffOuJ09H?V
zxfXoPx)3flV~3~~)3T6=!4hhn)p%!{?;#)gyPBSx{otG+P5j5gQ-AztPc8mpp8xqm
z3J}i^-Iwo7QJ+iSN8N3fsZ3J49~*^9D&P6`WXJvE2dMtecWej8@gD_?n}J{S-FTbi
z9nnNTM}$AHQ-{Aeukt!KB=4?aWYPpy3alE}kvxJtM_wNhavjyQ1ItKefTQTcv>;_V
z8g&F|k|IzxdC?n^Jb6^G&iMU-%G(Z}T{@q6>aU-E^gLtcQj);uS_$eF)hmZ<)KzMZ
z`t!YS`h4fRZ#vA-u3HDL$lKby($}1+r*rT0H(%>|@8E25aQyTgxAb2*Hm0{+Umm=?
zCwI(y_=bHRH9DW(L20#Kcc^WYxPzRPc>O>BQ|BMfKYqtj>F7|zKZ1#wIHU(fe&qF9
z#LD&_|DC<mi$DAWkN?lcr#a81$oBhp@=ZxtoLFSb(_6;8w=mCbJ1P$?*0;}Vx9mKc
z-|3=Wn>7w+-MeSTxOl=S1#OpIn#gdYc*g{v{P!`|uf=L;^aOy>TtXE1G_tsDg;(`q
zAn}p>+fVj<wC7))H$fIJD5M2v5vvP)iL5j&;xOv`;zceohh8jrR+3xE4`k&))Fm7O
zVARJ2Tz9rO_)7dQL0y~A0~Uh3;_fwgyr*iUj1(MuHmW2JoLJo)`h>@SE}ethc6V_D
z(PA5fmx?%MylpH`j5AlDdM7JU_k80F;dMU8B1+c1mNPl57U30S(?<FOr7);lup$;>
zzcMATZv$FSCG^ly7h-)z-Pc|(B@!9d9sN71MthA?_*;^ALFbd#{y~7<H!bHF2I)dF
z)YnAMc{lrkVMR?YXpw)gs)3q*?KQ!M&If0IAu&|HD^U79rooOg$s1hEwfp^H+LK9E
zgAFlR<7FWtQ0(#B|E2TOFLZu(#f)XBL^77~mew;=`W^pU4n2Fa?iy=*1ht~R$sRes
zd!(|wELqcr=cYd>TyEs^6LNI;{95!tt6a?&)P8SM^Q)6v(=*9rj(w5m^BFPK_tV^h
zVh8+@e^2;wGSCEnqWMD}E#c{W!^M}gf?<tyeuN}#(SVCi=`on*6+u<xPRNsK=8!R|
zWp>_~jP!AIpH3f#g3nfh*Zvuf<B<f_pD&J&6oJxYxY!o9AbYuZhGnIR{!HhCYH&-=
zWZCk|X(c;)@!j8g@X^@hB78j6N9SNoJn*{zm3ksoAE1Wgg^a=7Fc`6>O^d$oXfgSw
zn5n4z<ZL*+B2)XtLMpWuveJCDFTG2akcdz0c|+%%@E^RVrv=Qq2YWt+d|qGg`78Jg
zLEAtR+IOa&V+6Q<PNrZQuFXhl2a<OtFy4L!Y4bQt3I`h6xtxF_0iMScC3A&L9deo6
z=FB<5qH;vaA-`-a4w$24=3!$B`-@=V0cUcP`WyH{rg{=a1w?xR5FXET*D4}pk;#an
za@h<`gwJlJ@K|;Vwo{Edg%D;G+Y<ic{$1gg7HdtPxm4U5pB;HkG*=tQzwZ9Sx4x5d
z9T9D>`ur~<H7nq62Op+{zxxq2OQi=6|6$fE)vA35e)MAJmv?mj=u~Czm!ohVdFQ1g
zL*cy#ZnZ*nsvkg`Q;!-x_u#EJS<=e#k+D!DyD*bH*>rVEg?^V|1(_qlK|6BJ_uGH!
z5||*uLu5nYEWsNS^-o@S>H(ft0{i|_oET={O#%C@%gl^C_O8y)W;@@Tncep2O^+=b
zBTtpLl}ZEe4+O5QsZ}|zUXdB*T<70s+)2e39k9YnZ@%>R)xMEdZU6ZzM{jugtJHfu
zrNHV^I`c^MsdEQD8J+)h=WEG_#`f>&+kfNAuCdtI1JCx(Eci2vO}#j?YtnP!!5@ZY
zkK!-KGVw%OkV=K<{+G&~e`{7$6$;Y0<}28T-!oz=0(6x^Knd$2_7_$_js>FO@Y@rS
zaArT7iUXWb<Gr$nIWyk*{#T2|p{dJfcJ>9S*y2+sPu?MVsiIyqR`g>A<{<VJ{13U$
z^<3$>zvmI;mHW@0Uty1Nn9M;kfi{oL>DHZe-HGQ+9PBtY=8t1E9HWLE{Rrk2vFBov
zkh_rKij;&4&Nr-lM4E>t1y4KklW4y%B?b7&Z{%wvdZHB6Jg{*=M0bo(c$_0QIdiXB
zC#R&;6mmV~$jN_^jIK|9n=ohGP5x~drJYJ`9&tBL<GWKCFi2!pXJF@oHBTVMwqMgy
zU2iBHPDx45(BMWQjyWW^(H!SG(e!MP9>~whtKd{gV3$daWa;LA_?DsD8co$78Z7Uw
zCZ7AORoSvnIWyZIuhJ}~N^#%*P?HZ2*mdh*Y`9wUwS^_QP*QZC5sw>U(2s3o?v{1-
zK%lq0olly9l(^de%#i7p*h6w5V%mLur*4bzL1<>5yY_d2VThrb;ZQUx`C_80TBp4s
zF6@SWT%`{`x%=G{m5crnsDG!2wj*^&K=4{jsLrr_P)GDjZ^Q6Lc9qIySun8okP>3b
zrF?U7y;xAj+IF?DwNf64hhdRQ6;qR2XC^1o@9BI}a_zo-`?b#rE;Z!)I)yjME`%68
zXXNYty&v8Bv=)t}D_5>OyEStIhD=GQUViGep0$yjR?B;3TTpyDz`zhxnUG*!l5$_o
zZ+C^XzKp;B!m)P`3&!2YwFvdtN4~IlykapTX|XoP%HA?~@QKzfs$VEa&G)|j@VVfC
zd&-m)MEM{C$Jw27bMJbz*u-*97w^=xM0?57kyL4j_G$)08H`Nxa&0gYXQ&tGF{nc0
zlz$kTBq0-YNl7Hud(X|I2pQnDJ>F1BO005JCQ~xuJ{|?srQe^(_681|yk+}vC7Y2X
z2HAudIu|oMswrBA;q#wLxVFScCIYZk=FK^z+7haVf(#=TC4j{~wRSMvf~^ydzJ-zd
zJc+Op^|sp!v+2C#vmV7RBT-|c_S8V!EJ)t`i9N%|9{17Htw18~GAK^YZgpD}teR40
zWLPpzKHIq1#Yg>yFvI-|;uUYf8uLZ0Fu)&&dqp>FHVbD`GTSkM9V@;=4UXCwlaz#g
zky%R!X$<!NjfI5lKDu#RAmT0|;S-dC*XR`0RV8$P0X=O{Js~ARB7`moA0W$3*Fx<>
zj6H(oyOL1XJ%FfD$#&j(npEh(vTio4iS%=5GI3FLn97Dx->Ke0Q-zr?ed^CT-+Aft
z&)m74kwUyj3-$&*dWw#hTF6$!9JVww-OoyQvr3=piwFsLTzd_PRinxHWVSte=b^)Y
z@zsBL`KuP=kHkwce}GR)VpuTK*oRxTY7QaR8{Ur8_isA5tuI|Udw6>}Rk|j-!j(#&
zC@LIaacKckNNJY_-Dyr-Q?-CV2ca!h+{P}OcSkL^Y2-Mo_%mMh$%+<L+-lrA^O-Nb
z_3=Z;e)b12j!vrD#DOerrh-$^mK<|Wy7v!rmr9{<+N}-$A?u}-06z$*s;~u-Wo9h7
z)M$kwhN2|i^9lMrF2r@z`*L|oRBa%bXb~~z68g&5KDazS=&_5-qfNKP!q30mo|;7{
zMo=@#ChSK(jx)H4IK^j{C(^0>LccK-6DK%MgQl3TrR~0nYyYb4mwd$=Xl|z(Fr)J#
zqlSXPuq!_7c>{c(xBaT0e?RvK@Nf?FoOV`}*Y!Mw9K$d6{4Qc1{|e~XKkoSjf@!;s
zFwR`rR9uny2O-0G&GzR0)|mig*4a=vb!WpS7j~Rn@C&9OV!((O1(^zjn>$}H%P`4)
z<2*xd`oCPqJS0CrfzSQF?)bIqn+_ZQwRFtL|7+=XmP}<#dE_$W-+yv$=jha2Z>3>0
z*5*#!bX)sC!p$)H#kak1S@8^ps{Q`n;jCZ}G=}1ZRZd)3x%JZXRAl&uMwNPM(dW(8
z=R3c;JlluNWS6}CN4d`TF0ZZLe*5a;9n?o|oSZy(czpbH=Uo?<x12q<Fn^gky4YyW
z%rpm<UjB3c;FQm(bMJ~$S8iWhx#RNs`W@7t9i5rpdthqnC^g*7W!mjbX7K0h)!ORn
zK>u22{rvLs&9}@gp1<$J)YQQvlT*j8{p#+uwOg*NY`ycTp$B5^eGO||3(lWksCn&l
zCGsYho!(w7ng)`wJ#*of=cpro-kJ{Aqph)ZZ?Rab@-%<@>h||uVkGzO^~0L$=!3^r
zZL2leTxWJOd*|*6#A63{`RpPktX;Xhx_ZyOoy_Fn!;=#yZ~Uv}vlq84T)5OZ*w`}L
zY;M`Y9EuN4Pk5hd|L)qAyH?gNUFjT{Ie1`t>d2waALW~*AA|d=Yb(`(r4{PWm(QMA
znY-nD=dY%Y9GRLtbdc6pFI`+)x&87r>27bje{U<k8+%Km=f2Kg@$<Z|XJ^k7J#U6A
z{xfO<afhFVIs6{_UztVb&CD~*yO<9_E;2CF99Bo(xRZP!>o%NK9kUMyxD?|0a5fGR
ziU<MS%VbhJesDy$gBjtdc)CmypWu#|$QwFNqA+meA>PR@YC?7<^UYy~ga>XEh-74F
z0!(jB$}v2?%8VVFL8%QQ!x7KBCgJd}9(d|{&A8X$$s37Gf5T!(1Qj%!*tPiUPdlr{
zrZ@ku6=S+#XYU^9pwmW&YMntLve_s_9Eu#ru1(wKC<R|Il<e3Ood#m)x~{pKeb`(U
z2<dK&&-F?WiU9Yw>jx<c6+n}{(T<H@oPmQE|F4a}#yKexp*o~oQarxlf8z3me&Hep
zuv;zEFhq%#{q?%=LY?k(%O$TjnIoMf7xAUxj2&JUNw%6plSxe*2P$x!7&l9Is>KcD
zjX8g8rv-#-pv?{7H<Qo;QZSSX&T+l425D#aqVp(euPt0Juv<=d>4um}#=5(dLT>Fg
zwEGF`CHjUnwSn(WFS~!S2wxw~u1a!qo@@?Mx4oP501lTMqud<@ltPA@lxaHdWS|d6
zVL|F3qq2FRI3#V_eCha$##}!zsJ|fr<gUN+?hApYhD=p#e=TpfLd;jw;^+T5+#I^=
zp0<<%442e-;j^mw>^HRdfv4>L=%`hx!P|`H+z}7u_j;*>fBy|8Ty27vgH<KOiMlKc
zvWaBg_dYN^-?`mG37oetw;0U?kp-{L3Er`qigZoT6R>dc7%xSF@b?(osr6kACEYqx
zqYFPuY}p<ZC(1s-h(zKVEvvq8&P>667wgNd`ee8?_*5V7DegMF9tdXAnK+--y~P|d
z!TKVRQPwCt*lLcXB@Zu$fUumEv>UC0C?og*@`NVoid@Fls>SK55fN0{mta-OaHU0L
z8&QmOzqNIUw>=)+Ws4l6GqCTmis$tb!Y9J;+<~){V)z)3cid81NX*H|M#OS^=l}#E
zo)=Vx*9B8{Q7oMYc<+Q1Dtht)JeyLKqIY)nt84zgn@=Af3RXr8Z|Tu_wO<{iG==n$
zQFxJte+H|_I<j-RDOz*+;z^i-HLq%^yvGhwK=su)7-R()Y1QZ8-3AvC&cbdMaWNF!
zr(G(e`Z+_Ydf=YK>#hU^^kqS{cz8_d@WkUiNi`ky+)9Z&$MX7({d?UR-D0D>;>PV>
z1d+h6+TaAZ;&L*pU`R9<99ulS43cgdDpI$qx&oUUZVS*1rGzy%$1{^8S7q5;ZfKK*
z5hKDtF7m|K5Rx*f6zk^DAeNVq?+M-}^8qu@iK^~Gb5WZQIixg8>ys7PKo!BAseMOW
zq22bVMX^IuvMwUkD`Hat-8;&9Jf@U2;h_bFDbac#gD$u!cNljBwMgFqIvnq;7fmrB
z`^qlvHIhoRvLss6U7e48N)IRN@QC}c<b4sYEV(~5BGVB8)^=8?=wsLhdGhedcEcb{
zZyok|=LFdukJol&kwmqiB3EsJOY@OoM)dF5|KJnMnHpTA5->96JiO^T0i~HOlqZHT
zQyB*SiQD5Vk}~TH#Was#cOF1;0!6;Ije7VK!EBl0lXeh}@u6f?3(5Y256`ma-y3Ng
ziTs}PUo%=;q}UYa_V=yLu80CJ*=*C3cQ22Q&<d1s)a>cUpEa{1j|7A9qUxuieN@YG
z=sY~Kt{9mcsa>Z%(GkfqqNc7@jG~Z_asJ34+kZ4rV@xB^c|zH#szH}O7%%xX^9ET{
zN`e|t(qTSZh2v3x?N?-1^LMae0^Rd|UM|XKCcL*UEzzYKYsql~d3z(A=xglSvW1%}
zMTMY<*jwBy=j4#;lll)O%UTfL4To4-_KW^<Fyr(2++$UNl{K}@9M|E~xVn5a6D{bz
z<Tm!&_r!R7!mipC(QOuFG+YgPZA1zfaWN$+QcSCB+L~QWEpaZT7l!9K-F4V!ZL{RO
z;u>%@)AjPI5z`XU;W<n4vb$hc)Y_V2zl3x+xp>ToMO4PO?z03RM08bH5a8eneXEPg
zz;#OX$VuM{jD$vP+-zooB4)j8!H6Y<1;y_cBe1WF{b{&MMg?~ysamDhdCXYB@({D0
z%0!06m<VsDFX{UOy$asH(9faJcrWjh;DE|oHc3Io^HNOo-(VvPX<X#IoKW*ukj1sa
z2C9M*sJZ<4TZE8^Fa^eKjOcP+<^#M^QN<wd3WzSj#n)V7G-*t63JS=1jMPz^?~A5I
zuMo(3Qf*3euPN4$SW=MmwkfH-YBXVH;XP1VALk9TSlJ809Bu`~u*k5{kjv+n^pTOo
zKFa5AWb8f=xZsvOQsBXUe#&J}`dUrd{M7m<?`C3oMmEiy<crreIhmJ>g8;7&!~;7y
zg?Uto9+Ox%vXz;(KVT$f52qQC=&)*dJO6X(e~#V}YIpV>%vU<kAg!&7cPCj&DMMBy
zIV=8AIK{oUCk_mmOFd+d^IM4a{3LeQU+wuOyv}~wa}B84Uhtj*krx?gMZ0_K?uxdt
zz^18mhOBoGuCh7mRiOu)<8*gfYc*{H3%;|qI(EFx#ghCbC6e7ce(vg*hypl8)Jr`?
zXdnmEU89jnJ_iqOQdix{+TbkNB$tL`=5Xv(BvN!^`;I^i;{Ao^iPJx#6`i)X@N^F7
zFGTtyS^<GvMo$nZ0r>;xy>Ll@paswrr)l`94q=KsO-%gG)6QwV7Nv-8kwgJNq$RZ@
zKZhe3pZelgI&c5!pFA@f9*z$AMw|A^Ai&{MRF(QY>N0g%+Ep+8sOC<-yrjdL=&RlJ
z^)rpd*HfO|b4cioM9ZIk-9)h(W)*MP6I_l=&K7*RQ2W@}H+R2s7jm3TbCHZHr`DgM
zqS=)id-6R`?WERT{z2oIJ7rb=^0q`_(rj;=j0ydHGb7u!cP=dQ#kh+bjO)vK$tuAu
z+3sfx?zkd*{Dw;_dQ#tF19}LCj){kYAw?89#V-7niBRA;8+3a-k0R>Fo&7rH);tnC
zoV9U=?wl8WE)Ny3Tz?3ld%xTLQaFypusYJ|8k(I|V1Lnbd5?=RI*)XI(fQwdM@+c+
zc%;d8?Bqjx&tn=}ze`2`?Wgq7Z+<Ga?PK|^*CZE!<SX^VUuZ>!&Od$E8Fx~D*QptJ
zIi?cveQyrdruF&Gk7oVK?N=%jvtB_rqLt)PikmuXq_g$ORBX?l4~{b;zc8~*6|eos
zl~XL$zDR8gUcCREEl+UePmXgtc3vD_d+xXIn;3u0w>A}KJ`k;H-{2xi<L^1-d9pmg
z`{9fhO{%Ve&O_m_AIS!!=m%_SFrjJg`@`-~*{Alu%*t+AI4B2~-SSh=j|fW@ec0&y
zO|l(E;Gt_FkSv=;ahRg{1y@j8`#<h9e<hq72dR-9x4(L=@Fe?r<OUw>IoREOaWLg2
zb7`{aB1Y5=8wPerglg(>%s?{xiDXIUm$U!s1_qOD52WQR*|$O6T!WzlN(Um}ng)!S
z@m5-R@{y~ZU%v0uFYkHxwU^)bH07S@=d&SqG#87Xh<Q_aEip=Yo__w7pZnSkw=q7b
zn!zF2mUP|K+e`n+JKpevxp|4r`f8)PHa0*HG2+a^_uu#qiv2t4EOq9)kfpA6{^c{D
zTkNg9m(EhICmxU~RW!ZcVZ}vr_doG*k7auFfbC(RicO}1ow@Jce+L|b1YSIOlB8kt
z7<b(N-Ol?y_O_=!*0qOziXY;>)iczy)U&(iuAYZ`-hgb_@9p_Gj3F_q2!dRoc2Ebp
z+I$-0@oR@e)DD**oWk+K!SHo`2b@vExONYRKXqfK$WD<AB^g0%F|heUcn!wS`A5_!
z&c&8<S9k2mJ)63bdd*3m-F;9P*tnYnzHF35!daYW$%{mK*p230-+(yH-{5JRuN@Xp
z62a}XfUqO-#d*I-653@jm;hcU4y=1ucO&I=kvN%>$~XJbZMW?>5RpAPX}q&{{B_-t
z)8lUMyM4e-6ig69Pn=CnZ1)xRC1+xR95-~}o<Ss{WA%2qGF~59Uff+-KR$GE_t;yS
z_myEb;`I}^1d_IS39!boY}PY4*!fJ>GILqKmHukVlI@IyfD8s)C#o54A<08Zgx@&4
z`!lyEZ96&A{8ri9PW#Q=iN<KkYVR3sB>Z;r*`~)oSWyHe=wa4RXtK!13qyDA*}1d0
zvOh93IN%T6Xspf1oF{m+P^xR7OkX~t+wKG%^)}m(3lxUhSqX&^rLq19UG$l`l4<$b
zfyUI)#kQ?=KHhFO{pm9$(@wUn;-KGGjYNV~e^Rs%hHP}M<q)4&u>6TL8NWAQ^0iO2
zkx?{B^}x4!`3;@F*c*xE)xsE~$?+=Jm=BI@Rk8!Q{N(Z5{;BuW;}1<GOU?9wdAoUM
zXrOI3_uW`%-*jZ9q;R~Jjr%OWU85eeQfbqlD}2&QA~FXE1_cdqMS7N#%bZ>4{E3~<
z+ignsW{3Uh!p^}#E7d>J_UAG$+M%r7K!$vl{_C-wH-~*&+M(3^{FZPsZ^V~oXIDP{
zo#z5u#?pngRgW1D0W?MPXO9fJ6z}k;pi)~xdBiK6!K6qRO*0+z2Ya6l)OJp+*qwB<
zJ(${UW-|6j{<C(1g%@pciTl2p%K5ES{-8fo_Ii<d2?{p)M>KK?@{k|CC*05dF>*wF
zj@nBdf;ak|ziDsdx@-+|9PFyA4I;$g5W=QzgYRmH@QG<o2!<SF^Gl+=oZqk{lV|XS
zJPhKvep~mfo^*%^Q{4WwUtT4CLipXVYlm%a_$2+>t(yg6-|hHTgQLP_f~a&~t!!gE
z?zFz!5>PR;7bN9fmt$|1;xHf7j+iGD<Me%#UqN_*jKd><(V@uA<~p=VnoovlqtmDZ
zjqb`!o8?o)o(-7>tOKG8`Qvng!)0fU5boE!3A<RSaITA;Z+|*(#H?JMMvj6DULj(!
z*?Z5m_|@$i;%vTt<|Zv2H8IyAfLo^p%2q<tQ<FI1S?`=a3~L&oDg<_5Z%{=xO2y;O
zl~Qaj;NlB8L>5FU!m0XbDfh12-s;$7tEq=;XMCk?I}z20+;Q+6t|v44+CSEAtln)!
z{Q)tCc;2zw`}$?8x_@wu5w!3^fO9SVQlWDlDKmCAb!$TbfG!i?DY*)o=*Es49&r96
z{@YfATMhqF%@@=KA0vi(^_(9Gb&-bQkm5^vZc{HFma{6QEgMHa6`kQyI?Jl6Vsd`r
z4g>+;_F#VX@S$6FV`l)&)Lg10!+lGz1O)H|PX(#oaMP|<eBS;Fx-Gx*CZ>;%jGm?_
zS3q(l>j)m}TpX?UxhA*KT+h2^t0&gyW~LSMx$ldNp)5~u(p=uUi=%1Z>+Z}IvDet&
zA7o6AXe{^yKhL{z^8<}tKDcf-C_V?L;;K&FN7EizTPhc74L1!@U%2&bG|<-{cl)$~
z%GUXLEjoO`U)f5#-SoI+DS73Jzw_hSt7Dheo@uR5O$CyiC#4t6K9@he-ad^@a^`5;
zs{D_azktktB6nC|eO$2Q(G-o%enN|W+<I%6_b5I_K+bNyVq|{wl6Q+&9>W;;B2&4g
zP&?F8Ol3a@RYzIQxHELn^aXz4f7=VmHX{dRGoZQzL*wR+%7iOYsnl83W2F#(h#^*8
z!B%{%Ix^@ti)rd#b}_^BmdtArG~^1>l8iVjVDwBsY%fgD-H1%1+dAJCM!2tHXYu<z
zU+ejso`3H71@;v_U~r9LWj{b22j_UqiDY>{^2)qOeS-Rt6U*`+)GOd8u&+CGfGCL#
z=0V5^CM6iQ2|-`K+$A-WP^UwiAPRCgrkRaw3mZhgX@zmrl8*lw=m|`RhyZXd0Uz1a
zDxyY*Fp2o(Tx-Fjw(B=ch@Vhkov2p@qV((52NH*T&>)c%L<|A<A#K1a49m=h2tc&6
zM4L^#;hZ*Rni(P{;IhL|@KdfUHlR;9$i}E^-@)Bz4{k<zxEXQexR*4T17|8xHPmI<
zueKTbc+}wNXo;bcuuoVuoobwJ;R?cciB|z(d88tg)%8Fa#k55$Ngpl3fDrhBqR@%W
zb~=H*1b~Y?N~K`u6iBcMVqyS8)one|c6NKnIORB<X~2=j`ByjV*rTBi{4wie6g18$
zGu17F6op`(5x4v_`%rygf;PlTO|k(vk)802sX2Bl#kIn2=r(&#sG2A4Vgo9NOd7P`
zb_E`LuqAy|zPc1VZ|*Pd@85Nyw*3NfQ)lD3s0Y3fC4HR{^w4QQ;j~>oN@!I_49&~e
z%4N>wUYs{_g95as3Im;=Vh^(P#2p!q|Nkj_4>&olDqVak=Um;@Ip^+~p6Q;RoTbrd
zB#m-TmSkC$CE2oN%W}dw+Zfx}28^*;SPTYZz${*DU<tcRc(5cJSXfxzl9%w7g?&80
zQt$h2b&oLreed^sf0xx$U45(SR^5BgJ@=gNd?$5MQc9)1c}@O!{=y$~U*()id5fz2
zI6+HPAdgUweoI-L3q)F6K=wZV{<*DJ&6tMAP!YNP`8fESawT(|*WPKxo6)VgT!ROZ
zV1<{dkHy!nYH2qz*2a@Z+n+eZg-cu%RjsrraG>N;moZ?$lPa7LV5~f1KI&fk(lI?5
ztAYx9PcUPdK|UoZJj3P7nP;Q*fNnn-Y|2fA4fQbvRyyUBZ4;SG=yb1#Xyiw<5tA;L
z_%qEcFT|stbHH(~%M6f0l>5xV)Jvzo+h=~l$=Q4<qDGr+g?6tymHyOi5epE=jrq0r
z-go>&>vW5zuNnFqgc`g`T{U{euUCzniZjeR70L`|G6Q{vh0t9FGsddiLODS<$A*(Z
zZw0bBwLBrhOCzzkG#T8y6m7lbjTK=kE^iGT{UN{l$;nH{Be8<S=Yr14iIketBcg7P
zy3QU!;1?GJ3nU+~`?Tg7O}$()%X^TxCm|Xdr7)#itm~nu^ITy5L4MwvDunGdYZjXb
zqQ!FiqcC*-&JLEst!90pFr1te`Zy_0t+W7xg}Eg!xl4+3&u75TY=)Q$edT0PSQ!f?
zuS&>QQN3n*S7~Xg6sT9KQ(*(iJy^c|g<>KOgj9X{x{EdNj0Lxpi>qkFVy^ydq0kq#
zvx?2@9`sBaNQSB7rZO4NO<3)}n}$moGC&d~)?lbqbRk_H%l%*x3nCUg>kpVQTLv>^
zfv2P*EUZ~@6~&$nMGU>7hk}WmjZ9TPu$_o4!G6_NPZf)&PK^xP)GbnQ!w?5stmx43
zX5Bf_{`s)9X=;6~mE`p^ty>1KIQaw3G?WM45T9zVqOX75>s~iH72WkZtVh+J=i9dm
z>v^xIuV*EYr(1wLJ=k-+=W3vTZ|}Lc=M5cuPnzf;M4t9o(7GTRi1r1|gUBFXD8Ot2
zL53dyC+#RKgcSn?I=^CFQnV1AfWe<6{v^sO;JaWELFxa+r7aXiMlz!I6fF$-ZV}uV
zF`Y#e^*?c&^^d*K{-?p`YPEOPPT$gg<<<v&bNE5yv4hkWd;KZo09(_a%vlB7cwx^%
z`|!jffdCDU(Qmq|eDC|p<7?Ng3Mtf{`T28$!7W)WNk28TX5p?tKGe73wqnC^`wRAa
zRN1mqMY->q@{a0pjUQ_++_idS@^u^NlkE?-zt(<u?a(9CPU_h|y!(ZX<0J3<(#nH#
zTeh*oxou19uG~bw_#pM|GFKm%Gwvxp7%nZ$E#=PL{kdDt#lOdVBX-9Xb9<PD-8a5U
zGyh!YUQKO&h>P+GH~+^!1as`K4d&IV-OK(1QmPrRPAKfJg84swNVmBIl=jE}n7y6-
zaBBSQzKefMf93Ay0IB@*wrl#R;XUB8J_(${^+3kl2ke_~tNZ`ac1Q-15xRP(PiyjL
z4G5<cVj0i3A$%5Og3V?Is3F1U9wUEAnb&-xP4fsSC8%Mc6IhC!|Mv#m(EL`?vHmZO
zNVRXxt)~7(?lvW(pZjUZTNtuznf`L1a`q#q7h_3QPfWb}*_9*g@$!~eAM8u9TZgWC
z^(zs9c}qDx(*DKS-!l<<W>Yor&2~*zhK}8V91j0)tvpH1@!$C`4GrkVjmc&^v4Poo
zzOm09qr+^5JJ(qIAW}%Mul{!SMs_S%d-ai_BkbjknOC1pj<W-6ww^tzuVTbYPoDc^
zw4Zt<8ouH7ccYDU=uF>a|DAgl*{#QbdD`7`q~|i=!f)=m8(#e<dfo*r%14QAB%mS4
zP(eCOe{v-{keP;}bbjT6U|xc*_B9_g0>-lsxL$_XcBbb)P4gYHYZN5l7F-1_=-Wtr
zSQT`w&JmIpn;hw&oCtr)`NGRToj)r`_%l0KBF0v7T9Ezsb!$&th;_z_ovEpiQEPGI
z<Ezg7+pjLXZ(-F!;ez^IU&{48X%D*T@e96OTUTGY%ATAWD!Z%4#u}r=i*`5ogV%bS
zPtE_YZ(RIjd$v+2l{Q8VJr*?#um|8je1r`%_6*stl}a^gb6t<cO+E2p9MEG=RVpPT
z{tWh_M&&saKuV6cUwrfiZp&uDjGA{mrQCko`z~rfGqm*W+unT3E&HFF4RMsUv#<W*
z+nTGd8Q!)1lBKz^SFPP2xb@ciA56}PAO8Nphfe<YiCk@t3E>7W8_}3<M57-n7E50%
z7L7#wP5EN!<$S)<zP%FD%}DHR#e5~A;9&GqHNPm?C1aa#)c>Q9<(}x-3rYMCH0AU7
z)#ZkQ=)^`;xj)~Cgzjz~Cv$gInIcV3Bs4Ia7?%EStLwri*nTv#zamE`K^R5`d?>!o
z*;#WEt+M!<@BTGA2snaoMM_X&j|Zs0uM`>=E(@|jRbH+gBCTQO?D*UT#1SobQ~xiD
zc9JwhPtLAib5pq9jDy}oFp~G&g5Z9|GQx}&b}J*NtaRUnN0MIu`%<yBfXL@LHCWWs
zL)J<Q%z_mEo#tf+PBe4l%v<0c4z7UB$t=scmXY}Ul#?!RoEtnPJ$upk0XtihjUl%@
z*2iR{O1YY};%6`T+{s-ZMs#l^At}Qvxsk)6eIb>3@$fa@(ZXRZafjn>8Vtcono^}q
ze?sFdwKP0A9-m$efV)uUZj`UKY`4(cd~o&B9hrYgFBCVz`WuNwR#LLjoYe1JJws>T
z{q);Ud!eXCSh4`SqXQ-d&65!{FI=WYV`wB1X*^3kcI&~NS0M^72j_6sI_%{|@gtk6
z1z@D3$T+C&(dsrM{R{Oh<A5aLK!^oRfx_z{I^?9h;_Uo>q?pL9P(yG>(gEk(j$eN8
zn-qvP!du_8>XB8&9~5Jw!GL^dYN&Ndzkb&fyD!Y!0<73-OjbB6I`dcUue|3i@7x|d
zY$seen-!;G6yshXq8xqkUC0};x&1z2EBE=HJv|ro+=QIn%iN!S!;>CK3?ZG3tQrUw
zrTY`<U;ak;H~$Z29P~}U&!8*#=*$ASk^qIkzvfV9kK6%^4<g4JO}o>{e9J0v@C4AQ
zaZ_Is`rR3~BP8ZttKYvL1SIKyWF<qkWpfHdnNP%tk=2ESxB(REJ_SmV-Yjf|ZLT!4
zs6{V5uv9K`E1OR4l7IxBj@M`OXl7xP``kV)Iz2ka29>f^hg&hZG`V3*(3%y@{=xaj
z=bI<KZp61X9;7yyFIZfJXDA?aSI!?V*RL@6&wV{MdjBn<#>C*L*1MZ}X5g3}Rg?16
z1N0&|PE>_%GH@*lP;VlE81Es>wxDmk*EkMt3|gL4)yGDnGZX!ruKe;DPLpLZb#6y}
z-(%M%r>-+$U!YnAzPdJ;T^Ptao4AXR9+lVPk~Q}J`yPL|Uz#rRMq>B&+`4pe0{M47
zrX!77D3BNR=*Zj{zGR~N4xKtQT-vRM#v&Q+8}AXF+4TOq`5a3Lh!KuEDNPT@xIQn9
zjPZ|!`i?&myExJu9aT+g#|w5bK5V@D^^ctZ<2XRe<IGB)R@qc9r$jhzbX$r|+twQ&
zKD?n&DI1Xw=n>G%ILcP)B7U&8Lv|mW6%xoe>p0Tj4H+(20DR>xdf*kv$2$7qzw*E5
zzR>eHbdtxxd+{OaQ`A?e?@~Xb{uANa9$lo7aFt%7cl%s%XXsn$hv}#2=jcz<U!q^8
zzf1p;{v#tYF8JYU%pfz#EHT@ei<rxOZn!ryPc!dlo@f60wKFSO6#G58+nxQM*tII0
z7jo!u=eK~{!62bq0r5{}KEJyz|LzOmZYT7A`%?_Ezx?j>Z3tTbrrpkpzD#cKpGHz$
zw}uI?6*demGI;zwbn{N{Cq13axt%EkK?8s4_Wos-^>^Pu(fy57i&$F7NyJ*QJV=K9
z0Rw?fRKDUe2pWY+{W`w^Db?~P2BG8ZAO-!}FAvC0aPn*Fh?}4gKFK4TA90=0Nj`}S
z*nifJAE)z5Iwlz(ZB--=V)*TdHbGLHjZ?!UcMCy;!2?SsxnR-v{6g9Azb;3(5&Mce
zOjH!K7vv7!3>ou&ZE!Bqj`-0Z!9bpzJ`8h6|8Vy<zO4tB_3sG=I#Qh=yvjlWVxoy(
zhdUv4gaZ#(B~61X25^(skk26AkHwOQS(em{)RV}wP9YL(heP8OWDoh#9VX50?;`OV
z(zO%8)xZN5TevoUa)XHL0L2+`clndLN3=C!Kj(ou^qa0x6teys8%8dNPGBG|fV&K#
z?I4GNh6FI4G!tg<PK|<1v?z2rU(oVC#<AItZ=|;95Sir~!CK%SLv9Gt)3Dy_G(?cX
zJ44Z-VHEJ&!tWxD7I`t`hUfJ}a$@J@qagqTB~OR@5IDYn!G=c`8E8BNYN4N?(s<PX
z(vgz*fm8^unA{xIB*`RT0VhioVTk{I%A4sWs1micDAl0{Fou&?BB}A}+CVFS*WS9U
za`kU2%}P}Zz*G^htO6X!l^lTN!uxeg#T*I_kZK|xcPo|tgcC@xgdrrOSR*I<k(^sK
zXdw+f_9i2hotLsB;|JER?d_cfi+8`9XSlU<@rg^z$ZRrFuL~DVDAM}l-w>E*PFHso
zZrW-)e5j_+UUJD_W&l?LSHkF<o~j0_5g_m6dP}W@)C-ib>g|muWpFCcTzt1%(nA2i
z7+34^K+vW2nb9~Hlw_`dSHGI#M3K%6=2vYF0|+%JhmMa&_DdJIg{qjAnq@u~X2GI`
z<aXf!&SjmNjmZ5Er}tOmBZt9&qE~vM{$3O@R~wBtvEim3kB?61Ji3A>fK`qKmxC)Z
zleIlZTnao?JYttMiW^wXY1^rEur#x}k1E^wW60XwduSIom?-cXB|l{-^$ZJK+QTtm
z<4jPxT<hXVbx8tkl6VkgSgI<!ET__M5Vb&zHV;P$e+wl!RPb6bdU5FMh+L5wnr{C{
zG))j@=)C>oa5#wka@x~?k|_|~qVZ%npy{+pwZ9@FriO-5Mfi{i3a|(Zdr>_e)M;K9
z#P`uzDS%z!>mZ;DO6~svJcG+Upeb=J$mrBHk`W|<CJetW;=(eca4h!$_?toF0*-*c
z3@TxeM2ifJG(bl_2d*rnFaL~XX`CTH77K<&Ym7<DDlA7d%VuOF5avXM=EbwOAQnlY
zqLP$UnG&MsBLW!ubQp=Kv#09lbPm8y{1(p%Tl5bt0hl!H+(d*%Tp!KJGW`lbf|@1p
zXFma)lZO~ST7GZ91YI78ux^tbz$JN}MwAVO9Ohx0`&^ih@~SP+VUbE-B`TtaOA41G
zcfA-;>C07I=xZR-aoNYyN=g#)*BZ||0|h0NU6o!D8_I8(y{ms$tiKs@M?RmKY&O-1
zfMnPcH^_ltZ*(Y18H2&vj!RjJit`T70uZRE;OmN4xQLB3=@wY9y+Ep<OIjdQl1z{n
zB4i^UjT94nVA1V`E5MG2(}{2xcDNi;`6={j&EWtQ0Q<;g!^2w)wzof<5K^OQ5r#ui
zmko*o^if6(W3en6gv*S*##S7|&>5sOqoT6jRKt-J$0LiH8QCx$GVDT#bD3Zu?uFbW
zdK%X|&xsV%zN5V5?Xxt!h%jP={qMEF+h#>rVE;Ttq~EpAD@mnbPPY<*DcRG9jo9tq
zl0yv>^fqgg@sW*B+$^r2-4etD$r)kgXL)7bHiY*7N@O$0))Hg6{fbLZDUw)W!BcJs
zcG5PIg83En--HCGxW;HywrXl1rwIk#%Bw0bg+P|2hZRnN`$YaFubZIuv)J}``zsol
z$apwmPPr*b0z(C885ya4E~Kj(1%Mo}7y=EecvL|8Z<-zOdLdom$-OacmD!NM#EdIF
z$Ko@tYzw~%+M26Swkn_qCBI^Fx=I&3{ux)6bS{XFO7oy49~Uh*Ex}5uyd8s`=Mf&q
zi|lXIR6qjbg(4%~hFXBrUSWWB{Y*sBjD)yej*FTYzd}i1^yWiIZZ9hAP6Yj^rpNKf
zkp4ampjIS0mbBX03wYU5MN2W6(_pF-JX&I&9B@4`5QAvZL4?R_*MZ|smCpV*6ESfT
zIJ?nT4JODlo=B==%IDJH;nOT8lZE&*;IZQsQ~EhUB1oFNj|HWNMn)%PYwfoO<MxYA
zkq1gP0@^5xW-AZbNr^)Y2Skc`j|G$!2-y@YzDAISMTQ=kfgbrqu?RhKP0t2ooxZ;3
z<2^q`hJyf=LcIJKwE_O@!@#<nq3)m_pxz8U^Ev7z>TjtpQeTIz`9tcLU|Rb<)dtU+
zLOb0xdPiYniSgyNTWfH-v+5zU7NF_=Csw_LZQoaO$RxS^52_Dgef3v19j`Z}kH59Z
zLYqCG_nR4n@<gV3;?^M%N8Mt+V$=ENuk}d@qO1{Z$~OYx&p5OO65s0MjNsV8xu`(*
z0-d{cFM|ge22%lYGIRbC&G%*TLI)XF?4!HS>FX!{vyj_h6$i6m0A#kPBXLs^4qH;z
z|K?XEg9pUy4Z|;-{5VeLbn=Pt1YCe3@I3OKh)U|KHQ34fm_70=I8?;1Fj4tG65|F=
z>L_(kAn>rAA8>U)K&ypU-Brl^)BK}_tRMS#-XN8S^9)ykM~-;8{4f(j5f^L{cRQ{x
zpnd|m5BV8?$V<b1hqRWQ>yaPuq}V6r#p3?)@zh&F&$eG}|N5!VNE?PP*|x$IIJRD&
zp*|@qWhGMRA06d^`Q1rr&sKl(iKoB4OUY-wos#K}OiS(knDL$wW4luCDF4Gd&wYN0
z?~N_RZL?IM)E2dJ%gaN@zL!%zVFY8ktVgMmo|5JKQsHf1cAkI0eD6mNY&~2Y4<I$9
zyWX|8^#eQ{8J?FC*9#M}*MHfs0TW(}jOOAKxoUAhvgFOj7KgPMFWUo$H*JazM{d75
z^w^hUEhA%Ru8}@|FJ<S}P%^F8uN*irT{IT%EbnWNk3G0hHq-jZ2}c%#rF8m@lDqQe
zYj#G~Oc#DZjcz{j>Vv=%HcgYU6=c74;%>MSmh7Bm@ZSl9BkpF})i8N-pb-NsmznnR
zOe$kZC3e`EErpU*g(<XO1;JO|HCC^UNmd{-Cuic5ed(wRK(xYra}h2eXP`pmQ(kIU
z<X?w9%N_>d+jEqwIOV{?+ZGI5mmR1jU&)Uqof;EQE0&1Zfg(i*Kt=vriiV$7XB_@m
zuK-mn1!#R$h>OAtc}_NEsgYDX?{fv$6~C<VA=<uI*Yk$`e$CctWGDWqwW3_UJ^8VV
z&6$HOCTR~0-jf-w_o<qlleo_-<;d3FO1ZpZZ>zfJrH#$<&}I6jrG3i1^@gdgp**9|
zunz_i>9Br9^7vG6O33WXF`>lf8`e>8kJghr%R+elJ(ac)G{HGa1%qL=&N>IZ10`0G
z0!pcWb<Qegob~+pB9<<+9;#^#N6cmV8esE$$Hv8SA1|(l38@%Hth5IHgdu2TK~5Wb
z|Hq13jqv0H2kw|YUH(~VY|UFIPu=M%Fbv2mJhcxw7C8N_SBn5^Cpb8(?##ZCGDIiJ
zBBB^U7Is#oSx0l^EJGs!)_-@v-Wf@R09chZh8MXS`xPrGiQL^FZcVwz>|Xs?UX-=u
zv+0nfA=3Ztco^^60DP9!MzA2qbL=^R*OIogTB{1IJzz$P>DV3NIC}xC1ne!WB(n~2
zkuf*$0r6!;+{^OnMpyj@RpZ>Nl43OC2t5JF@iz%yM!ehpo|k&Q-19vk3$CVarXHl8
z1diZS)K{q=P`^elT9=N1O};_T(W@b?`<I0r2DOH@Nzd|kxT_&{y5^<M>WP@7h+tU$
zBogj5UpzlOQb&+?WGohD5M{)o1QFv){H~Pj10%6NH+1A(ch_J45(C!%=enJ*%NOnl
za9GIvrF0y)35X!XG(n(sK?D%ASfSxNWHd3eb=>l}uD|33?*NG?^=m?0@<fLEAOuK#
zB2EYVPgJ)nh?m#q<i#+M?3kbYl6YZc2O_<*Cig1<q`&}K>jHh*fjppY2x<0z^QE(I
z*T6*8LVO&N@XNl!&Jq){bos9S>J){Rzmp{+V6eXM?PlW&HgRcJC-0K5xPy@ao{w(r
z(0cut+3+qAnoAyxtQg59`q3PnSp(Jf-yN3R<Pd7z02n0O2s*y_CKDWalW1bU`G*8}
z%5e>VA38wFeuRCYmhhfH*b86gu+SJ8pHS<n)_$@5nMeKwXlE-;)k|DBC+5Oij+Zwc
zykdhwbNfTA%?7pv)CQypFRh**0HJ}H7Ln2qi$!@T?Iu+xKia26C|lnvy1O$@3o4Im
zvT-A3MAS&Q6|6ETW)m9-38hsy*<PL19dT||?Jy{YieNB9v;xR|<*Zx>Dq@x>;{%h2
z*zAC*jm5IAg<LM9=T7$1f#ESW#=_Q(q!7&qAkSn>skF&|41gaAdKMj#g9%gCSTi*Q
z1uC_wzJu|=`pwGwxwsk$W^K68Svt$Cd?Op+;I@XC4OEPb>W1s(hiS`TwL+x=Tb!%u
znS69|&(W&&**zcCg?OTckdlmPYcMOTr!!HbcTu}iVj#_D{`doywM)9p-N`Gs6>r;2
z)(B{?Kxyajzn(GNdmw|zOaV3m#R&v#rhS_jlsW7SA)KV1Qh`lRnmTJa<@Xda$==<K
zVxEg#b|}BSeWOYhO0Fdaf{|?Md!qTkibijLDxMBp8V<D@?SJc+-AxTDjK|Wm-wy(M
z#*GSTlLrGRr#!4UF1R++Y_t`&<Us47Qu9*m^>H&jIWn&P?$@VYZl7CH!c=eG<94cp
zOBD69rN=-1Kb~&b3qWGUu45bt;R_58ji1rLzoW&<dWdSMv7_5^cBDT<ORX_016M&5
zJ`IBk$ski@Y(b)RMYve0$S_Qps-<esjrwTOlry4c_LmdW*UHhjg}A?Q9UUT|{oWEQ
zn}s-QTH}vO4Q5Ib1CzXtkQs!=aN>Syj$^`kE=XB?6((vV0kdU0h1Id(%{nS$wT=b*
z>IZhWpSMc6WJIrlnLbsx@^#MO(KBW9=?!lMjlGBDU}0x3?;yK7ErqP;5pn$Bs^MhO
zUCIjJD?isSiqw*;3v3yr$uK5|-Cl4C>b}m8^u=0GFc6l=Bn6uJJy#Pmd|ee8{uilc
zzZ-W~dFGx&htFyV^G_iGTjba2*~<#Wf$TsvY*uoa_NUp+V!@c9Wiig24vC+Ug}$Je
zV^uE5iOKIcX^JzRf-XK2wF``r6S(>I&v|(qVJjr(_2%}w5V|9RIpPV-5<jHuj>g`R
zGRw+qN5n191Q2u(mcC*RIYQ*759%f&r2{he1vYVX5nZ$^43~vsN9YhI7*SK9kNN_o
zL5O=HdaD#TC5cH3r$UN#CIBMAJpVkD?Fwqt0Y~xOp9Rie9KVvK0nwW~we1S51|%Uo
zaUG*9sS#)*Nht!)^0!WT5&_()PiJ!RQRgru_8^l%Zx;HZ{1k}d88K{cbDP&k!qH;|
zGVYqICnoNT<kOkS8f&J59t4g##nREfVIXmOQ}0cTxBxc>5j7}AuBAl1x3Xs8ZTv;=
zi5xwYjnWj)tqvSrQ$S9hdnpzHHJ+LYQs4-B{>qV&r2!DTYVE(Pso~Vrg{k{iPt2TR
zd$&$i>zQ~fj67V1C%3<w^fs1_WZxCaaDN~8Thc0$XHF^cT^V!Zc)=RVOUd@@;oow~
zR8R>GF4`se0n?Bbn^KbckUkQ`THKCBG7+kW{ku8Kvz}M2(x8Cg&**IYUbpFO+Bns)
zIma}=U7t)vyfT}fk1*ndDF(w#V=E(k)ur6Rj-wM?$jJe^sV56=sl0BnRLs203B&Gn
zlYN&k;U_Y^0L}`+U@M$01~tnV=hH^?3u}jm*VyM?+5TiL=Jl=~?Y~RgHa)%Se%>__
zk*JXgw7+)E#_?TMHx_ctxyj*tT%UtU@XnN0P16>*9lediN?%n)V#(r~1Cc%{Y&#(u
zW{(uYLCdvZrXWrREQ?y<W3o>RKj3*F2JVB8?$=a|I@(>I`m4O<zVK&%F%tp;_@^$_
z?ePDHZas|@c%-{`)D_}U7W|Ir_pd5N6duwo{kakYs;ks2_cy-_;{=Q-l<ItTDne*Y
z1^*~IWoO6d{aUVOXOQ}aZQPq&@4pT?FxjEv<Q`4muf2RO?BK3nnhew_8kNV;^P!o(
zDggcO{P-Y#3{up;%8)lq1~3_?IOf~?$ro}Ja+5BJIeFp${`p6RAIxQDz@SX$hcxpY
zm#6_LkZ2)EE|)$ex$=D)lYuR|oC;_IBkI<T(-FJ*7em=+9)B|2Vm`b0$nc4*RaqTt
z(v;pB9!sZ1aXJVP+UjV`Xgd8O1yXmGaV*6PiBrhy;Bt`3BKj!yOh>9ON|i4mY}d$%
zE^<eJsTHJg2;d6ZSw>e13Y=plBuw{srTs!c4lLfj^#bkSk0uih-k7~`eqNf$6(-WB
zjiJK);tW8%b|zkxL%o+~rz5|e@DS4K@i~|MNomQ7>)=q;LRw4-Fqn*J3e3r}VCbsF
zN?e!`0)h6Op!iA-G=<F@hN3$RCZxeUta`Kz8?gYRU{1HyDK*3(2s)NvA+iz_c)z)a
z@2p5sp#Y#3Uw?f%@a31CLVRTOs^*q!%&Qk+zr&&gCM(eiFs{HQ4}InFTeiII4Lj@%
zy)!%K^x47vS0H@_Vo}FeETp`(xnNMNBI*D<d0Ygn`iBLzs#-CbO;L>02kxlsmvogM
z#RM5DCKEZZh1;5`BI$^9Hv&DQ6ZL6v{R{W3c+<>U#htXUW@Pnv>+Wlh1Z$;@Yj#Bj
zmL4l?8lz5l6Q~j2a@wz6dR&bd;H#HiJ0lAv1@Z#aNeUBkL2nyVG@DNY(2zg(;mpFo
zfvev^Uvg0#(b&kX%rMZE01N>0tP1r;h8Ya2Vq`!>_8EOpLiz<mt@LS3G)Uw9g*o0v
zxOR`v*?FJv9o|7!Td;*vW=}fRWBH#<XP>x@01HWb){rfH=iC?DSG2D<_eFXLCapKn
zt;6Tq?RT`FYE##o{>l*j<KBPxH+qBrdy9Gl^#DCY%2WGciKp66{o-?<zK;G+v)Oz0
z=cg%v18K~ukBedM+dUq#=lVQMer#wCv!U6cxbb=%;-f->fh^)?V1S2hYl<o|U}Ng|
z`E3XY3?wl;v8w&4-+uqwziWT-rVmnw-hI>8KlzUDQ>hnr9NzSi_W%6btN+-3wEe->
z;x*LH{)1eFex5q?_)8`dMUEZM_CI{v$=lY9rmKrbzDAAFJ-@l(i$7|AyY2n_lHK2=
z{+Tj9d+s;waQi3Q4pdhcBX?A(J7v2PD23bayLsY*`ZNerLU@k*g<o^m_Z)<zT%?u|
zXSNp^POqeHfaUM?)Fa5Q@R!v4sehopL46NC=HF0%gw4;O0oH-Fusf>~vExh6Vu9`o
z2O=Q;%Z63PYu1k4{Q)dBGMx#&Gaq|EPIUH)gCwxe*AsAAUw2qOfK>_PCm7s_7=<Ov
z|IwFz1p7k{qejG|c783@0NWvsb_=2a?t*ZQR@N8(?y^KCC*hhzf)BzM1p5NM3Mk8y
z62zKEG?f72SMV#m%>L@KTk&A}yi~?|sUuX`?z_R6%cVLvB)pzw=Pm<AMY22_4iZl#
z5xGssgzg(fFfKf%m|BKm#`Ca)XBfus@F?P?G(ie25Cb1^J>rjpMK|O>Sx^><`H)N{
z<O(oRquQ_C;B|cM=9@H$b5<aWQegVYyTVixY!c^eccDs=dZ5<DtgrNubulUD-yu-M
zf|698Opd~@+pkN`ta@MKHhYbI#prc!PtCpm+VTQeDQGN9)1lgW-ZB%xP09}F$vY>f
z>IklvlvFfwQN&K!p*olh<lqIgK(l4p2~TJlJvJ~f3@SWUiN#MPS!nmXEkt=LjI8GH
zk+CG>QWW4~B%|XPkSc<uzu_>RrO67in}i@*xS#|S2{%!o5=GV0syb|dmd3AV1JFT4
z@M$8qfGJWsFDop!pfNcql`1hRBGM7L%Lh0urh2T5%qA7e1L|w{djplvQ{1P2ke<E6
z-8#Hfr-p`RhKy6~7yjw-cmM5`Pn=q)#zv0ZebJXH%tg3U<1@+06@MtGF*`YP9j1@=
zLmCnXM60V}<Ki@r;9}%f!9*ge#m{eKO+moNM6YNV;!L!CvLfsKHmw;et-e^Ky>?RM
z>vZH-)3y-lwXUC0dXc(Mzn}(KRzNP$JxMt-6lvCK(@D^b_Y2o@gX7{rQk-tYtK<1g
z&)qg1#j0eh^vPyOSYbSR4Klfej7fuPpIIY|D`lPPzaa;o_#Nq=8fpSbVD(W&)f7Aa
zTu{;A2$3CnZF{Qyg=nKbhUqM}#p}K7s|%E|h0B%1NGmlzlPvGjLXrawE-KsEfUetG
z(T(@Ai%ghRa&<~my<)Lm3mS>6Hhk&M36Ex61Sqi%T%#gus}vokvX-n19FytSXw?9N
z1Y@Ka!9tjl4Oa-*1o((th%iPV<$#KflN~F;l#!v#7WkH*GQ+kkEK&tH7ZVJ8a;zQT
zRGXy}Ca<YN%&;YK++0x-<ah<?Durlms!!9)<=z0F+-<q}#&JFIn}y=~ht`a=6sM23
z<KLZ0PDX|vpk|R0ff`%Src(7JGU2ez_OnR58bGBiqzoGQNK?@IuFuL!in>l(A;<Z(
z=bq3Q%ScggOtEgfy|hs*G-raM9{F%pO$U38yAtcx#>dCTHX)-Dsv33WbU~<2TkpR=
zY6Ptv18d~KD5YMmi34+p&lbSk{-m@8Zq}vt7nekYM-Issr~*gjQr=%BqJ}xby-~S<
zybQZJ(#iGyxbO=5PT*&6CF?$VH84R}AU9-@X)$ZhYsJe_0a&qR2>~g?XMK<*4nmUp
z8yVVv+OmGgHmrZa&hm_iHyD(0v24B%(u`cn7pmlBh_ud`{#uTR$pOE3$I;WhJ}KC_
zTQ+^ZCd+dH5uWFjUcwMGKm<uwjqcPBl_q+(2Pt~KC=sN~&j&&83v<6>Me<mkWn|~M
ze2tz|(%<p_cJ4_&v5}|rVI*W7EWk^Gf4tCY!XAe2Ss+Jo07BLO28Lby<^B8N6Sgz>
zRSMaDvfnu>bTC0AlOvKm0?gDxCO*JX@C5h^84JoV+>ro2;8f|{9=E^&U|fjjXb6dH
zFfj$mH)09((IC+58^f4C@uoU2&Yy36q=@fgLqTZsWY<T@bf7h4y&wQk)O~V4e`mM3
zI_rC467=wNL!D;@#T4#5I9voKCFu2I67b=#WM=YPvhxBvpG6W2hSGkOVSyzDhCq8v
z<_YZMbC8$;{3@ZPNb~#6;eUDsm^1y?h&SC`y>&XspZ6$oCETNkzDn#3Xnd?vI;K<d
zW_*Jvs!ndx^3yr`J)-l1@C2l@ko(~;scWZwy6@Q6Sde!S4+q&o-Yc;pcW9f3Fw1s|
z;TFOxHqfZMkytynC9$p)F?oYtI$hm9!ClLFLV4>#WqY>q@b!~mi7mOMV)^c!3Q}Wl
zyYeVY-Jd%ZA1g(6^{qDJvErbbu*C3}rC3Ng_mZ`6)jnAXXI5lyPP;2InVd#Z)X<9L
zMHdfjEYM5L{x5|XWV*XW1Bybm)AfWFvMoL1h7;<i?rHz_z(e=#E+45+jcUWUIQi2z
zojif8SvOBy{;k`Bg%i79die-*?#Hmk!r+L6fGTJ>2fnR%`TXcr>TWZgjzmN=L@`&b
zq_x)W+&cMYX<h_*k{!><d#*XT&Ppw=EF9E1QUAKVc~*oy#850gF%Ei8x|cUchArM?
zs-~9^a;pf0w0|j3Wd*|d6k)JTW0FBjV;EJl6e^Pgxf4j3Tvmn4y(q&i1#TKl<?xfo
zXx^p7qLp_+4gxzZodGFlBt;=Wgi&Nw(~zFpgXKj7I)zthWDhqLh(y>R3`P?}p^zXF
z1}kJnWWm@YyI}Z0B^V0{!YqW9anKd8;((ha&!~=0aZcQUp_(!gBg#>*MaB(qD2ZVe
zAmOzvED&%50w4e%4081FCND|`Yb)TSRW(p~rM<JGQ6@artoBNvc}9l1c@b<=+_-J7
zqO^Q1lB_oD{zZi@iAI>_P)B4p48<wONGf}{@=P;T(F0&YT6t9=8FppBpd<h*)Zy^~
z@EP%T*o^ByYH1>jv#<`UPAFqW8z%2^PSP}llqgENU>iqFy`}0^!-6&$8BA>4n-5*n
zyv&Hl$0HNzM}pkZton{3F(qq!>_C`X!Jz{L7h6ie?n|qoU?JZAUn0$M3@FhkCo~_!
z4Wq;K-QoROwD(9No;47KEO8oD)i{|XB9!&eh1<r=B(iK?FuG@F?ZF}~s9ri2wj{ki
zDmY%>l$tD9*PgwcLS{Z13&eae88-@*43}kP7s=nWz?>SP0!8G<WcI}>NG{07`X<r;
zOjEWTcBoY75AG?i*mvbv?5a&tU~>XQEijGO7X^3I`_Ji1Nkc`>J2xhI;;1Uu7l8$a
zVTln{=5^iyBfh%e6<CiBnqb({5}X$`j)RJKcK#FB16B<98?B(5ap-^~ZzM9o%c8T1
zl|@dBf`H$ZD2zw|&xJq|DLx5-SODBKz^TC0rwa@~9U2o-sjR0UqoM%^1Xx`u#p7Bw
z9R-ZiLTWoj(Bbw2qb%q_%xs8&W*iaxVqoi{0MrtZI5WTtA{$^G_#j*nq_C`rE~_A{
z8I*4{1H*xu5Jj5@qZf$SBnK#)I$sd&{Uk|Z9n5iJe;nu@6OJDw6*U1~k!<K^vKo?H
zJyMLCXD34;HJ~$bGpEKiq#fjX*{l)(^M1eE&M6>pV<p7r1xarYLWPD|07(?RLZ9L+
zFzi4ILpGn$ytlDNek!l(Q6pg~gG-x0QOD`dnAzmPU1rKEfiNMPyeS7Aoe#)1vYhEH
zkFuGXW+VBG;Alfr7tXks9`CErJS-+cLgBHhH)E2tGa4L`tAA_AO@|6c19&kYe`AH&
zP;ZRWl0={RL;F7jf%|*#?C<M2(Q_SgL_F5>Bp91Mgjk@zCo58cPp66nKN18I9dn&O
zvykb_pU^PX_*iBi2-5w+dn_}UCsQJsAV^U%uXny<p6JXHMDF8gA?HtAm?%NfPs(G~
z0gDp80dM55-26jb<pD>?^zGtAK1-HXShE$de8LPxa!_C%93m&-uV2ES`cO;|e)O~U
zXWO6u`A_aTc^`E!L!Vg3?A$I-)cRH(*tE1&8tToDE*zq$|GuJqhZtPQA2=Eoj>+p+
zuuiaa&57GS`1*IAe60P!|2e2Qo7;c!cMN3lCqMkz^l;;`hn@gAqMQE6GcVpqg$v9D
zODBf6rR-|o<9m;saZ6lTqGqangX!{O_FuP7-Fm-vddJG!P7Gy><;+atNULUL<(*4L
zZ*y+drtO<XAE6WNzx$tm_~Y-Wu^V0oa(=#gOUm2ij&BHF8K*#_ojbE*)Aq^e-D_$e
z<BZDYl?dNg4^On-lewY&%8$-y$Rpf0<1lNdW6{f(1Pd4{Bji-~oV?_|D|W}6#lttJ
z;ve{mU<LvPeetRGk1DS}u%9j!4j%gh12M0RU)Zc@$qKt_{ok;{2E5t6cddIJd-|mG
zt?6U->l@n-oN2#$@@9%Tb|a&1y`5$+zR+6L7#o{jF?NYD;PZYxBD?~d$NPK!3f}TZ
zVd3}y^*7Yls2?F?<Px&1UrOIV-$TEZewrq|%GVZr-2}P<`U%l`pey))`~%$rXiU=5
z=}eyVBy7GWb6%5z;)bn@dV*dy+z)@Xe+=DpvTIicGbs{dql4iF_)Gw$MDF9O&G`UF
zbS3mT9|Vj}gF?{lh)zkmDLQE`&-v;o!rnVo@IU>YIShjVsZm$KY2dVO{a{NWiYw7r
zaT(Ip0d&SieG5VNA#h`2_$JjwF>(U_2xPaT<AO7mSWA`_-t#{Qq=5foIuRy*tSpjV
zkOH0e)fr&qm16mTw}YqlS<@&&)r!{*t&6<$Wz7)DC;cixuP6F^u{A~L$_Ts(<`7g5
zxNtHQu@9F{0lI9_75W8#u=&a?v1texh@@U!PZqJqAlJd*YumC@E8LgV5;r8GWVtz)
zcl{grZ@$$jhka7vDuvR2-u~pfe>yPxxMGrm)=b_OIpzb-dFZ;>AE$iR0l6blTQh)x
zqb33Ww`RsyvpXiJ&efU>u7SQoULL4vh%hP;E!b}=(r54hMAb(p5?*=q(GQ)8#i#0W
z3bSyS-x%uWtHBEo?1~SMy%AZi)x^r<@yR!TTTVsH_SvtuzwZ{!+jgdvL~uq4Sjh4l
z8wr*`myyn!Ym}ITqytQx$ucFU!O^L3VLd&*mq~D8J{^J&9guC_kczSy<&?x6qO*}m
z>%Fwrms;V4BETODiWFn0AV+yNS4yl~pmtEktN$Dl0PkeZO)ZMN-KtD%^ZMM1(wnkH
zDU*VZCg)^!Lmtb0JLUxj;$Th}5~3Di59DNzUUw#&5=@UZ^#B#MC_OI4qq@Y}FmD6s
z1Y-iUFl4#yjk#_vhduBd;ggDm0VhYE%u{g^n=ZS_RVviFP*5uX2CqPuoKpxjdZJJ+
z?O&f;eB*8AYUh_?M!bSLdLWwKboN)FzyS@af-GewY~VKOX-g>Sv=%HG=10TuBXX1x
zi*R-T)FEHXhM{W$T;=3-uJl~lHPYP5K%}>lbrYlQkB*3XT?&*ydp#gXtEOyoI5x;W
z_QcV_p)o!cHl0{il4+!7yezQ?`QaXHL~}cfjbO2t&yS{#7NL5?kyrgwhR|fFuuj=h
z5o9H5yKLw;@J6OEP!2{01*A5dfZ9hrQw#Q2MUFoAi!jZze9~jWhGuBdnrw&rE|qll
zQ8zERNpDu$P`48;ZZr^jyU1=}pq9sC!&-Q1I7QtKB|*VN(kidNEB1!dlT_G>H+oGZ
z8lqTcGtyRX9-a!!uBxW`fHO`f$EUJl*ekoKTm)?vrZpaD+?5-GTY?)y10b7e9+65^
zl!w;tR<wvn#Sctw<1}3^Nqi<KBK12Tl?%uNE$p?$bkT}Rul}%>DeGSKQ15I&P|`Cp
zAD9cz$#CNG+A10BxS}3I4r<8&zeY6#wtsgG+8B!ms~#&&v&SY*Z0GW<_mJ6OUGx!P
zs6iJrqqYBqx^H@BAF|ztXnq=qcA62^rlZk>E`}K@t!klYEKwTF#G*4X$u0_Dpgk~R
z1a`1z4-O5~KT&UflSM~W#Y9ALrY}F}eKa|6*zwNZlPQ}u#?V$p_V@p>51yn9kFZgt
zP!hSQRFTp3_26@x%O-^-k`gLc8j331oEY$2)1A*`(y49C=N@`UsIFZ<eK<O_dm<Xm
zW};?bXdpR`z&OC~1!s0#echVD6`4y;X=^9bx1=Yxp9o339pn~P>}%bp&;R52S~*s$
zFYT*FYLk*0&BO-gW}1AWFMs{xq8Qw`_~_}h$gzKH3p||}x4;gnOcZlf>c=wQc)eO5
zY>sU7`jP3I&*#cql5Niq%=d~RZhNc2QU8NZ3SJ&7H&vll5B70Z`)Bf4%r!w9(f(^7
z=Pg-V*^JgVd*xj^KNb>2q)j56fbDC9U&4RW0{bS2@H$bn%U%T{LCHo~v&ppMJ287Y
zt`mRmg>b`P5Q7k53oad$BK*?+)}3@n{JlT5_$PD)Jc$$!Sfn@>^HwKN*B8$I5r3vz
zz6fM>cP1DlGXZ8fT!>@+xtT2be_5+!vgdwS+ZpIfZ#w?a_1CX?*v`Ex3qa3yDR2$-
zChCFcC)4l!{M;6FT7<_;&!>~Eb5V}IY+#R*UD9I1+b<Y8eJ0Y#{{Gyr*9AlG*<V>4
zcT4g%BizeLYw4>Eh3@OWAdqLz{$oVQq$`BX$kH_Q;ZwzRw-sO5Er&K*!wJw{Q?ORY
z<r%7%YW3-pW`96RQC|;FX5z7Sq_`Bw2lCmhQx%Qr?bH{9)uNtz!#Z*3*7cO~O})0#
zn_V0UkKNd>Mg|YGU!wL}^_tg)Vd0hRrXc%pX{{Pa#gi_h>JPNPW&}X>7~&0XUJg$l
zO52Gu{A?|iZ`;(_>UOKZojXo_QQ5#dZYb>{tG%0d14<cLG4BZv1O;2lSR<R8o9I?a
zqu~Ea#M(`@&c%1_Wo&T@eZoYac!ywfe}GqQx@R>qP;5uU?ctuI(D$!^#(yI$nRg>D
z`~~zDCJ0@HOwlkp672$-SEt<=94|VEJ8P0@H|;l}uhyhVrV(Ps^NLK9DKg+^X$&*j
zP8;J~P-BrGDvyD^hg@WcLph2;3c><80g4hS+H?f}C{rB5DIU}!*b#A7o^%mX4IfJY
zUy)~b`d$aL-tqPb_8CkQqE+5)_6lo)7k{e#)%!nozzUUf8!-W$IrFUgA&#Y*kUAWT
zjK@@s=Pq~$%Rl%R8*jes(P4Ur6BVdWyxF1Z7kom}9;0dMy|b0UBPW8){#D`NMwhzy
z>MJg9i_!ao)USr8jVu5CPAd~ky8nLd;2rHxgl>}tDe>{~&r-26&-ZOzVl(fKMypP&
zaPFYkie0f{A_fCMMjSo;5>+W3yd>0H2pW2UtGD5|(Zsz!ZV&H%pEEAzOM%AfpS?=`
zj^04g`;#x_mev%kfNRn!D5+Ut*vnekoq=|Yu4LMOE$tIo>ep{aJXN&Wn(K4c)Y{*F
zF;V^%bpzY}fxPE0%I!1sT~wg`l~>^vxtm_S^8;5(+^4CDQ2V>UI6m6m`#zrEeDy8u
zuWQ2JgRfcr*6-9cizl6!F#K<VX*}Ql-p4jQ8OPcLe6DM6-Lv~MJv}n|&~w7CxLeVC
zPWSvx&lkYt`x`_xff?TC@$D*WB*8A?>$(C1e>>LT&VdeYiRjd5!asw!zE+%c_Tl7x
zt<3Q|K}TvdQ$)sKgWva0_xV5Vb=A+VwE44pbW}ZD1<B!18=`gkiX(B%LHk3`BP9yH
zw+<?_M;4c)8~W=>a(8$INkLy%hbD`)Mdw5x(dD1!A0RdCJT}rhKzW8P`m3#USxeN$
zFKhq)h<bWqY1-;nMi)!HE7z<!d90BIwL2BFE;RdEDpw99YC_G5WTgC><aBL&ansx#
zm*3^p60_okb1~j%G{&w_VydIeT|L{^7#kQU6zb*y$5n$XsO#@DYm&hmc1~RRU|}({
z=+(4Xax&0+>>u-MQgg}4=y0$WsII&V<^;vns-@?{eS@oaB=fU&y13o|%){)Pq^J$|
z&JGRzbb;lqnW)gdB@u=>AZGE=e$%ek)KP}|&|FYM?4Y5^X=paA_cv*|EW0hyUaZ>V
zXH!vWmZ9~sr3NbTL)3IygB3|L^+E`UR1bs&PyfR!+-#_CxVRXRv-y4X?b`7Cz|iq4
z4{X`Ex-neZ$Xqg8`<Cgzji*u)^ak+2ad`7qHn|n?my`U;zKRxJIlukHSWwafLRB{^
z`FzMr#Gn0OU~)zczTR4`MzZrGSNzlJdn3cy88t@mGpe1PhaMC}WSvR@5vyeOapJ^u
zL#?UQNM-%Nola%^(mP56tDNHeJwMh%@o>1gf5%(uq3F-O6_h?v)F@;%vT0oiBMo)J
zFe1Xd%CtY;nk^q=6A`;L+gBFbS9{9#V09_RtPevYL12>VEwy`7TsWMvk)OOh>sFk8
z$Y+vg?m_;$+}WNPc$H3okL5mCVBQa2yADqW<S>!Q*gAjE3%k7$eXHlsmqp9O7i0-U
zdOR6N=%k&Y16TlN=gtYRvy)5WhXjl#{&2!P?+;i1FwX4=>mC##!)*wf1nK|82jKq%
z4+jqU9tuKkjl&(k5Qc@n(!u~84)Wgx7P`2*=G4~qT`Tsl-+pN0rUOspw<QCOMe1QM
z%;@j&E@jy?W!pJgl6tGP6L+p(*bs4#4h$bz`z%sRkFMQVs<b~4kV=<(rm-Q?f0z=k
z9z43<N=I7l?^QRYP6AbYs@A`4AlCoVrdWG!sQqxnR_wQ3z*bg822G`=6C!yh>bg;;
z{iXd*!wDsi$UD?X`wO{DI3Lrdis4oWQ;W?$v}(u3T2$d~4;OY+qnT@XWAEscdiw8&
z_J^k%2KBPUR{F%k+!yw1DJ}WC79$kb56n&`*NslE89Q-oVbfD<o~^N>-Wr=~-&P&-
zWV82@gcP2C+7O$^lALL6YX2u2G>#{wR&8wh>eh|6e5&;QdV39%2-BkasjJy~c#7vT
zA|H0#RQqmgRz#}Bwe8bh8hH#tGQxKyJ1j|(k3aoShW`wArso)PyWR$7<G(;}8T5Ne
zw{xJW$Xb<rBeQT<QNvfi6}yFe`9xY5!mitFXh@Kv`wM^4gybtu?*5LFd6HNc-T+~+
z<H12E!ZN>0ua2xcMCKL!%adN`_;x|e^@58fGyfS!_aH8KSk#NQCA`62IXRhL;nmo5
zx|pc`Woa8y+U*=gmN9r7L;8{uV)><sGh<_0jQI2YOOuH^s8EEb<B{RqpkBy|*@(q%
zp3k`x4^#PvW@zt{b3dm3_D6rYAyx5aheplWx0je~X{2}RcY@LT-j~kAheMmTS#SPT
zV)DM^Mdx1e27cObSnjC$#)F?;JKEnr6$^>%8}8J{*R708j$qNH(qPFL-F#PZQrSK>
zK7C_2oSZN+L4}vsja@x5y1AH+4t}*bby6MYl-&xOPEHdCha^zk_64H>w}@M`#hp9b
zlj?@Iir&hF6?Exc6NVM)pKI^5Qrn+-u`f{fE;*_3+L`v*^z6~dmfg{TpF2Yx9{p#;
zmEcC%i}t+^Jo=BKh2I6K@F7GIo}fMo%i6c7?@>P@td<=)(J_?#sRxj~We6thw{8&>
z52R^)%NV|OTG*$`=``{34B5F*{5<!QPiYO?gTIIf3P>2+X=4Z$jUpV8r1KE-3`fKX
z=^?F75F4<<Frz>&^uUIc2d1RO;b-)zJX~(@9s1`H+gDF#Diw0DmH{C|9E?HFw<f`1
z>-(QcFAQYy4KSf0DCfSs!50#r67;{|v$K~WRp=ZVr@Dw7R04PFh`HgG@5Us3o@}U2
z!^dQjvwffC@^L&7Bpqlmb6q7Bog5n!SUfW^YZEXNZiY{y{|0bVF93c^Qpx3Nb!(5u
z!PQ9tJQ^8*Ex)eB@kvG<F6WD5oJs;C$>ZT=WBekhr2wV_Vn>Ix6>uKFL^v+4G{GUC
zA0OUk4sN}NUj4AJ?&bh{&(Mj{%jZ1K5d!y!rzTp85eSy7(Z8my*!YgjT&zB+C8z8{
zpt8@Sv^aOuP48Kg66kYJgf(RJWu}8=rwrg_gxlklhLk{MZ=c%!S88c5HSOdzc%8g(
z`!_Ue-*-X#Yn=Q2sK^#eXYWM@37&cj_2>%jK>Lxiw^8qTZ~JGKhfw@x`{wq)Q@3$%
zb&D3Fp+VDa3THnWBQC=L*Ir=EXn`_C9Ui{`4|(URQPB}uHew`Q)iRW@#r1;Nx}*s-
za=pT9sW_q<F>BbPT*r|s?6?UJ8z-0o!l4bFXW}ZnhH5AuM9v%#6gm_uCM4SnDgdoe
zmM9~d-EnBu?PXFP0Fi&ZO=;ghAefZQuiW$3kwKRlliNRea@E6gYRG_BDG0^ej3GOa
zs*0)}v%LV9M6g;S$RSz|zj6o~)>z<ZU_?`383Cj54*oE8Lg26X;UPg(Ogdzt_v>LM
zBn+N=GwvvWH2`if>D>LCU_>Z-6--*p6^aQ5>kkuS&B@4-NN+NbZY*i#!5!4#MO<y|
zfL+ky?tnsxOj_ODWWw5z=B#xdrIXc-^-5UIT>6dvtp?a5;PsLyK<N35*3@E`$M#~f
z38wX(QR=5gGm?O7G+?C)>z<uhp)xF-bAdN4RsTtHrGNw;Ur+zUN-4of>s#+}*!%6X
zW5&6!j$BTKsK7vV|7cs^L5q)k<S9X*uK3|a@7~mYohkr5kEjtlckY9NL)~ry1C#{_
z2#G))xSTcQ65=S^ksUaFRnbURrLZG-eR4ip5;VgQ1_h$cu|~{7G6POBm>iF`b43&O
z8XX?9lobSKm0~QB<qT6%9SneENbU33uSX9YcT_Dng@h)tmY^4uBcDw<#a>n73M83}
z5#>cVV1ZhvG?ub0DX40tG=k}6@E93_8j{m?R*-mFSYW5ySKF&>osW-%z%F#!;j~5Y
zA9>W0ph}i-?j?y(j_wCJ0j#Ibn7T?uRRqXGT?0<_!T-F6dzyW*ryo3*T@M)p4_U{c
zjX~~95OA^hdKbq1pL8_*NQg_whG9&kNvAmX^zDzd|E>M$zkVmZJvel4EJMh*l&W|9
z%p>D(S+{D{x=rg(fBw+AvxnowenW}%U&fbnRNp{fjtOUJr~Q-XK0~oTq1I_FZN(o}
z6km*v4LPYTFJE4J^4U+`Gq%)UtIk|`)#Ad(9;V)4POdT3@Z7b7*IhcND2tap>D!EM
z7hdM6o_7PS`W-TxpyI^pzRbaf+WN)-UuE>yJVgjG$Sm?X&@uZL&oB0Ty7QvHfFnkJ
zGSPHB43KlaQRvS=Prek!YajxWcyhYC<V|%qEWpSbY<cU{4WH0J$hC>5=TCPll8kc8
z+n;LLtu@JX-+BG`gb0T%pFF64Ndi0tYP|E6s7uQ??ELLaDFowlzJ??Wec7#q<DDl#
z4g}O{!2c|E^snw6eZ_0JYUEwGoimo-fRFp>>Tq3865cU-(O~!amv2E%=st6I=J4-8
zuK!=IdH%Ke*AQNg2@@$n4#q0F5pV}n(=o#^2DVE}m3VxpH*`TrAJdC<_!?^Y3CXJ%
zvJlKoI*pYoPt{6dreG*VWJuDz5XZ(NVODkX$l{vSR-}@phFN8~T{*82Uo&Tp8P>QJ
z3UP9Hz$sSj@Fl^B%DROiS)f))RM2c3X_!vB$f<0xh`eLlhLg!YainBb8q%N}+8MGN
zg0?$e&qSle*w!F%=L6~JPB9}~HAtnX9KD*QMy6o8whQqZr<kc-w$iIuSw=)gtLP=s
z#7MxZs(l%Vg}@FESV(~}!iC9+7Cphof2jzKtDlax6wgdvHZ&7e!`oLy^J%1j1M)^?
z9m(2!x$NliYTthwkLWfnna$Dun;YSQNa)bkRDe?YD(P@;EMG1w?%0K*W(=qosj>NW
zH{BPiO*dINGd66vFxd<0)ZWNoWcaH0uZZgj$!RPF5H&h`y(`fD)})0HqS#jIm<T#(
zb;WLvVa;`YhHcfV8H5Mb*m#|#G;t7OEi>-QMWnE()3s6_A({1Y7})87+*B<p#y!2H
z8wNZ{L5H<6(2VnCiJ>c%K4)D#8H~kchZ5M@fULWU+8>ewnSe2$n-L~Mvj_oK)x8yS
zSIrny)v~(Y3?)RT0+<leK-E|vV=`q(aL<h7Gwa-Ju5MS5tSfHiMksY?K|@x%bT0z7
zAh$K4Y8gXO#D^#=ZMG3AR7|I6#>9k?WW-f`6sh4tnUGoKFX1UYHI;giQR?dW7ED&o
z{0ARf)pz(;djYC|@CVvdDb}4<BNrc2yviUqR9sXe_f#;OtNIy8Ono6d&>ES(aWo+q
z#U1HY)J9_>mzF^28-$PGeOjfyVXV3{c)&_d@6u8e>m{?EsuYz;IiQB`o;8rCW)hZi
zq}ZE^_OfE%-)xNev3$2N{{fr%A=p5_*z<#)bC7`@yaEV%I)k?(|IP~*e-saQ9Jm;b
zM68j2&?Jih-;wdz4U#6Zg9IXBgLLVBlD&X0AyE+W3zsEud*GeBU!ke{7({ZO&pl6y
zK!iaD_b){-=r}^;7P)dW-Sv6{BA+F24g5fk6QvV?h=QNX0kY7qK2b6WT2$ytb8--t
zh2_$u?#zE!MGm02SOD1J2yZZHePPGWOnid{%@G_ec6C^!;1ATeNON8I5VetV=jINM
zH)3pMUR1n>shMMz=78X0XHK?wN%m5ibomlMfdq4EfCiH1pV`<Z&|fQ|{+ba|<=jqS
z@CMSdjd;~SXq}Pn8;wMVc1=(eo0~vtf^<XHhrpNoy@z$G{)pFi!FAudliJLrr?IZP
z>Ewa@Vq!#3+(pH9O+_nV2!Z;<>-S5^kQt1*n{Q8*2V^m1(XJKUjhH5N(F!Sd?0c!O
zs2Y4l2EBtzKe}(<iFL`vNM%fskQvYs#HsOx)!yj-nVcMOm38^+OJfP9kynM}I;|$r
zVyu{$;+v^zYOOe!tQxu&P7Z*%NR8Bj!PN%RMT`w>0&Rg~a^X-D!C6V?qF?0o3&%L1
zkE*3eExRip&MhG)g<0l?%w%OIw%t&Ih}(|yR-qP>@4Z-!OI#(*%lc{aCj%=$m;%fZ
zl28P0(t>LX;g!g6ry<{iL@DxvfA#u)-3qyP9`D4Z-XeU1m%-iq@t&VkEY%?MdAAdL
z=y>SP{yZ@_jJO(1B3<Rg?;2#{>Vhdebc6rf_L`~L?_`~>Mm{^;$T!{&{h95Tbk+i4
zS2@2e*Xd73_*S>m`ia^)cZWZSjJ)LyHOGqXd{6F_C%VD%%!u_==Sj%CxI73@Gm_1y
zV-D$DqBUqh)#wf_e_V7u7Tqfe--w0vrK5!<Cs*FMX3Yy9JmR*0I~<TV)Yi^SQ~Sm=
zDP>$}EX7-wUL$~@9g&-L!=)KMuH-Tzqo~{VJ8UYfMI$xF?G4yb*2$aElw1aOI$DeJ
zY^p&|u0LW1DNWg=%3wwlVkIsxoS$q=(saGK2C~zP4#ZV>?G3|j4#9s8>Z$;v1bR0=
zzVD-b+}irwE%zXPR<_u9-pQ+KCN{c{wsQShS$ZP+;_=@;Us^xCQ4x&6k6VkE>>WR~
zZsnyHH+x^*xfYoh`8{@J|DNdLUg{QZZPn_R1?G8&+Oe+Rkh2Ss_f%Fop^LJTo9O3}
zywDuVtk`q&bhfu|i294*j!lWD7lJi=ozXv>Nls=@8Kp13FmGOq7{K7}#`Iu|nk<$h
zS*f>V<PU$YwL=OT@yS6g$`v=&tz^uG>jXK~nS9)eBjTHn6p<HJ9bcgrSN3jCG_#&L
zP^iu`r?&6B-!5n8qw7HfSk=Svk}$Y4GD}r6c?UH332(5p=mCtW>F(O~_Sjy@vEz}(
zN;%j%&=*Ct3LA}isVT|frfyZkq2ze3I87Omh$3x2Qy)~~iM5FFH<K5?)o9wLt}Uz>
zYf>NNZj#N6a4b~YV4L-E>Lfcqm7np>^&#^NS1xA7fRWTSWNTG*M?#RFtj9w`mgK}#
zv(yJ1-RAaN`4;zcaB5!)kJ>#w@96n(&p-A2jvA%rDFlUe#$dNcl4vZVXf97KJPaAj
z_PLIf?#v+_O&0NAWH5ANLti^6y93c5D$qlrF~dXvgKcuz$V(<1=&O+Em^?6u$Z$Px
zZ2*)GU-2VRVe!W&h{CWz!GKF<2$()PihtK;*cn>q=a%JBXZwcZ^Y&!_mdmy5DCYRh
ze{#%PxW=;3!O>ugNF?aGz9tM$^YT?*bCHhgMerXIL7FICMBT8Y@}Hh>dBekdV`-{r
zhS=~*$!G>Qq~?n2ZwswDe))stt-EW-E_--exNlNBapInoJ{y94mR6nQc&uUN!t-wV
zz;yq_4L3y^d(uuNFcb*6OJ$jw8;rHT>i$Ahz~*;v$`0#=Z4C8=0rgJJ;--y2<$}N+
z*Il{y%By?Xz!jJFRpeCEG)A@9?EYP~;Z5sqJoFUk!H=~k`>3=9m<m#Z_I~omKR6od
zUp*YEh)L7&XeHnL(xY#E=q+Cu5_g{cCs-_Qx3+H%rvZDO1keQpJ7%c&LW@4WA$+Jp
zvu@b^-(-CUU}a^Qc24i@o_p@Oz4zoMxhXfjCzHt}Q!~AHW(FAAFhd6ssY*u#6-5wH
zTnplgf(7f^&~<lR-Bnq1_qVLBx{Z~Y9RKG#HyL!7%Ots{e7(HiTb{?E6UHo<hbh2W
zNBH(?NiK3K_=Kg6Yt7N1`mP^MZtJ?bSGS*1ie_7JLFf+T1NU2%4f2}H+UOpe9#UQI
z8?nNcEq6;ST)o>iSH+63RSbH6>*QMPoEZ@ederVabn)7aVL`CQHs5?=7@|F&N_MZ$
zQqdH@6^Lg*%^fR@WQ63{?ou}}d^LHso?5k-+S<1lp4viyU3x)Qq`?i5c*(HsZx8IV
zx0O_?y<bu_7Z`58I<aYCcx0_GNR33>;oB<3J372ze%r}f>xH`xMfc>QmngM0ncy5K
zTZiJJ6{%Vk^<Xa}_KfmtPVel<=4zW%nBz+US?yjG%w)RvC)`ae5J1LSH>^_6{-L|u
z=m;{4T03B>y5S|egZLxCmR(l%6tZcBA5$YCdK*(ID{bBFHR%RTT%C4e^!sKmjoOOq
z+zS}NrKbhAKe&Nqw-;S2PR{$_B>UryaNh0)Qt*tAn*S)gV^?-nNKq>`a-6=1i`fWu
z{#>`RnPQxWFq?pzfJJ=e#OY7WrqiFl0GwC0Lt-P_mq9^e-o^R8uIG2b^9Ff;n>#-j
zSv<Ki=ZIEuc@~o?3Md*<F3ca1UhS;ic9h!vn)fgFJpIX2qdWE&_F8m0kUf6%%&99L
zocz(qBj0=A*`84M(oZX(*h}htc|e6!xX?$ozP$aUo(SZ$#F|yn>qiU)NKw@NntYXX
zLAow87b;00bqbdUF28W@g9k0|-?iP_KDhOg>v9TW33S^@to!mTHGARS*`eBwPwlz-
zv>Bgy-AKk4IoYaAb8zi0$ds+nnNMDmn_d_w9L(egQWL8>PXBPBA&fCQ*wND$94Qsy
zx|-N=(Q^y(uEY0TI1bgE;;inB4l_z3CKapkRaMT7YtbNpp)w#7El`522$}a94|NV|
zaqU8FJy@9$QC^Cz-Z&l{=nk%$9NxI2dil=GMv2v1tBs4b<YD??@3!QKwK_H>2h7d!
zt_YoT$QbCy`u;KDDek{p_QB%v*I3zq1|0q0!UC>>b1Feqs6OB)%^=oyKXoA@eQ&1j
zM8NagfhPSvph>@gNZ+48Q~!GkY#p=?+$gBz=nlFYsM2%vW_lleoW7jCo_?5q7yVxP
zgY?Jg&(U9{zfFIi{^|K~c3uW*%0gtD=svIB|8p}t7Dq((zA+rgUsx>9>rj$3{wAKF
z<R29ASacytA>Q>3Rf@mx6W><oZ^%gVwLQ(8$<H?wL;kwX6WQ-iKSO@FwhyC33;=&#
z6n}JL7C^~Ol0|eC{7ilPCKS56sWPb}Ph?KKb)hhWsol4!gHD&|MNk)FcO*~Sz5$X1
z>vp*|wuT}xv-{s*aK{61_7n&Rvd=Hl*PZg+p_<J`T8L~R{;gj8Nid`^^SV$5)YnD9
zNE9_9x!i1>+y~nXupDp<LzxjMM*blSBtb%niTf?eNXp?Sh(|+x91(K;_Vbqp(hYD@
zB_9$R?7vGMMtbDMlwag#*fGf)DfwkU2F+;UK46>>-5jYUDG+XV`(DL<wtm4#m@;Wg
zVwNS3pfJRB)=#a3tX7KX10VXik~)(XLN3kfgwUv@Oz8S<fP;_?w}|BgKglkQR`U}J
zQK+up3Z<2LBj;v5BvjEQ+dRp?*9Ty9v9%M|>gH&J+KeOCL!x-YDkwZ92#8N&otcf7
zZ;1~KoVJVVa9eVqG+|z@&&)O2wua+{PzY!1a=55jX4`}ksTgrFF#M*|r>yKL^%G-i
zS5IbrX1uWwy2Z(;J9ug7M!2BL6l1cqrS{Jq>)dZg^ozIx9qEK#=Oj?FS})kwQ5Z`P
zM*HVNG}O*!l{grff|KBKx!7WIyt=u#rZ3fy<v^?4XJ!>C9jWh%583$}_O44IY)Tf-
z{W7Qq0R>C<g@8qD1)j>~s8u%Y$mwS+F%0zL!-o>UnTuMU>8Lm)Iu9rDUndBfbRqXm
z%~jc0Kr>A1Zv+KIR=^-uWn<~bIYCa-LjY;A&&3hQA^^<l8!;Bd>4V{F<YG;u**WTe
zY(V~lHBU!0ks73dU}2r6nE+ivR5oH+SSwRhRY1lFy5kXQ!ra5@bTuJcjQv5D2`~tN
zVZi_)sh+Fxf@X4D9|cS*E0+LcXj#r@fw@x&WSIixty0Bo41zCEu#mRO$%62?lxe2U
z6%e@v{4uzSeZ2x+bw>LdOfN!$SxO6_)dEy-l#T=fpA==Vfk6i#Jj!zcmQ8FA2ECw&
z2pd7sbb;y%s0i{iKpFM|EIG0c5LVv%EPRk9Aos@Uf{~D;kSt#4VAH_rdKu29fWnQk
z-qWeHMPMFX-kB8vuI%!A2huPO3z^PD;!qU+mKM!FUt<HDBHYYHVZERnRb`E6J1Z|e
z&hd2tda(jHU_-jTbRsF5Y#7d|LyfqZ?l~Ile__{6QC@e@%?!ZItSCAnBFD12n%lH$
zRdO=(o(KDjha>InNBK}!myt2kJ2$R@p&^tM!P*?>ExW2-oGmJ!(l^0k^_Oy){`M>g
z2b{!`{xgtBZIA6bGwrliaEfREtW)MK$+VelI-1DFh6}Ts%y}Wt$q1r9FqQ6_)_RYH
z;w5onymdTT<%3E*TC4R1K$5F0rgTuvRUf(O(ZrCNPcH3FR5WPs3?a%yb4#zut}1`2
znl)7iBVZ!257s?{S_B@ir2SPYnfwJ~N`mK^HVCe~UjVIFw81d;kAlJmnWYPP)wGzq
z1>j;{&8^|1p!Kve%H<3lUFw(RG&sXP2s4jttcSNU3lHG!NliFO(bjhu_qFI+8Tg;A
zP~IfKM)zG1=TaetzBM&5V~dfjD7mujKqto;pt*|+KUbr1bqV&RG%vhrNDgx&f(ijr
zeb&Q3TFq(-1~O~WpTk%O^r*IUq4g^`l?yj8(N=|eh80{{@UB(p8Y7()plsr)$%K}c
zmbNmy4xfqpSp{w%-w=RRz%kT|!HzD~7;vN<n+wA`SzUTn2+jv>AxhIXmlzq|!#n^f
zO_@Gx_KG-{Qyba!`qED<4UPtP0GkAuo<SlH*pLSv5Wc{9@Yz`nwBOB;3a)Cot>ylf
zceFg&@(frhzu59Us^GIsucvlk7YDKhPu4pOSfaK#znznfyo8;lSRyzl%eyxDzVbH~
zQF8XdC31diGzCVt1F>-p1g12POikN7F)ri54&;Ss5<E?IUZ@#`QjX;8fAtS!&10be
zuMpV9N!EUuy1S65zetw^-(v*tHWz+!QbW!}xrjUDtV&Ww_%7&r$m_mtlI*Ij&5)bs
zHUFp2l7bh=InN<xeUdk60T4!!R6=giZx39>r^F+zH^gb+@Dm>ai6;9fKsX4fiN8lT
zn)?#&hJ-I9x`9Fz7u<BMtpU(|r<zG+!kE>g<s(l#>HW6>%GuHGV~<fop_xWUWHz{e
zL&^?*;IH)#>TUo4@si3+-N1>`9WULi-pNpK()m2DsZQ&oeftm?s#F$-{(-vxN<Eki
zheuU<!Z4ZAy~^>m7PAXD7Kf=wHXK$0fw(M(?v<|!ieIJ2213F`F+upuTNU<<rcjrd
zSAi9^GF-nY$Zg>GIbPz8g)?7g!tL$pk&Xfi!5*SE%dl0i?o{kfL3CnAW3(ld3@N6X
zN{kybHI88nS^AP`4h`)Ch;}&Tn(3+lSChR;o;BVViBK{?!qnWj61+AQk`?a(1vo(g
zC)^2JxX39|U}=p0Fq4cX*l<da<-@|#dMsB%1)3ch2upI;mMFVBP*b|Wv6ARY3R28S
zWwUKXYj(|pSB=%$mu_Qs-E+^cKxAmEe1GS@yQoM=7Bg-(;PAC#_JJpP*25yn$`Z%4
zDW}=%KY98F=5cj_O3`8<e`9fn9#hI|d!F+ihRp`<O}(<bJ(d2h!p+W-FwJ>tyLUp5
znwH`?snw^%Gw)X#bsg5+-R`F@6VG_>QTDqvqt;nIXHB;&$*DtMW`vG>EFI{mQq&bo
z-=qSG@#_sC3plGWRRK7O%$D=Xp^gr13JAS|VMeN5R-)4xFhy{{4DMU48Lfp@HO#tE
z&Z&SLd*dR#wztO;=C0Wd>otxPyJ>Fe=B0PizZ2tWVY>y$r?(h`a4_(822*jp?Qqif
z+xt2=Xg>y>&m-{GJ4XQ}9kXxi|CQM>$^U%9H)jZOv%+61Gab?u(07{J9$#c9-Yq~D
z!=!Ft6(AF&DZ~4w*&fUxX!hZZ;=kWau~=f7kNR#Y{(^zGq3Fcy>v53|<SruJHibIO
zDsqFYNB&!HNa_HEBllK{RxELl9FbB}KXd*qUwwqj{`79DXrOCqS~Q@y^(QrEG%t)&
zZu20~40-bn;^)sJ5WJg_XOL_0G?80FZxn?XR+<reAz@f|rZ4(|sL_1*!Q6(%Bs-^7
zLC>beOHO0#&f<Iw_QDK<DA{~wmOk?i{mllani<thCf5#3!?GzaDt*JPW)Wa2e0Y8`
zqDG_4{g<<<FeT`+_pkD^*@?tp$No?~zx5u#lR62uvIzWrzMqS?j;}`yaQ2q`p~H`Q
z`wsRddcYrwB=-*+xnRcCMI3eCRhhQg@Rs>Lqo~!F{y=qXPfl>9oSC0hH1D@uW_-F<
zjgM~OR-cJ<wtsBZ?528hK#sD!1U~B=Py&O&=+B_hxf7;KF_amqTobSb)he8^SN8)D
zo6V-%%K_6COmGe;jm`+O=1TJ|u2PmYOOJ6PMAG28`9Nt7q0xk@i3h5w##}RJMG@pY
zIB6GezC2wI%IZDUt%-qM^(dTi_*5hkWvtdpX9oI^dIwb-;Jbq$l<%H*E&@AQeRHc2
zpr5#QXro3)J6iLRZj}xi704JnrF#5uDM+yc@RfNeUK2DXn4fMfdmpA0ou0m(%TDPh
z46C($0LD!#eMy*}7X<A@-?dQP@N1%7W~tn0?{QkGN5Y&n+-4LC_jzyT+Xt`iJ_sJ&
zO>1KPm#f@QIVm@{*q-mA(-p80I`*MLq1M)aS*%w;p!4X7&6~TYM@L6SHhFbbSjFq>
z^N@qVTpD>s=j|eIe3=J+LInz-9!8##r8ENAJ^=7&n05_~dEnZ+?OD<2C>sHRDdf%k
z^@3@pIfSagnv=sG&$R6KKEgfCJ>QaUIR&rW6^#!${gP7=f@m;W{ZFsi*T|$>h~Wc1
zY{X?2LmxvJDjiHCvc>y{S+eu_-^h0|r}4dcvxq54-oj~!%#HKku*>@BTI8hO-Nik9
z{Nyt|6IvlT`_`;8HWPa6z}^>Mq9RZ|oVvDe-uvx4e&s!}aqVqqK6YgL@gK&n-hbx3
zAHV#?|NPV=Cr>|d{nX^@m@_)KVgA^3il-68xw_Flws`s8&Bx#N)vHfE_~K(vc&iTf
z#u~XD^#6SB!_Q4y#o)kiXQH9YC<f#{c2HUS%#)v_VlV%VcjGs<AH3~J@7=$8=k0Ia
zG9OF-;Mg5~tG3<q&(C|?_C9pOvzdH<+m3aO?tN?a7scLC_oni2HhI<J;mN^oyzTzu
zNAJG>++(lglhyC%YE3`ZwZbdhftCznQ+D`L6g+A;Hj^&oEwj+D|8({9*AvpT(52Bt
zMSzw{lf`IdL29lV9O)N-Ny?-Vw~o7x$%QiMzP#UYh-SyxG}ByAm%9fzVYn~6;yvQM
z?tQ>}#`_=d?bPnbL?Au%^c`1RdHd6YDLWdrgKq7r^&7qS)z|Rx`r}vL;=Oe{P!f8=
z;po4;<EQt0;%C(e72mY(K-M|4^z)^ixr1vrQJa5HjZuBCQCq$7XWx3vTd1<sEBkJK
zJfgQ2U%2`Hhpzj03DBk+sl~TZ2fSC_dcl#mQZXuX`VLATN)Hu)Avls5+;GhWM|rLF
z*hSQi&ryl$nuS92uJE|=!~Od&UHs52Cd9U$(EhC(?KkZ#wY^Sl+ImxP!<GZy(zV-m
zUeCN|zPo(08dkrVsSIU)vAG<Nmp5O1=baedEds{(_qlH)_P-M{>{dhsUEFdn^jd!&
z^Y6F+pF1%59x}@tlHVmw-cO8Vf7JV<9719j@opp=#<J+?+ZUR<4aPFMsCk1UGs1t7
zObF7uzN`qv05q2*7qV%s>{&!1<$rlYA?j-<$Rump6`Fe+WL1B7Ko)LJ#$`%(@-2X#
zZgAiJ)EB+4c|Usj>jjYQgwl^oaBs*@j%}Ok8_s|I>J4u_dc8#nX3}`QmM`D+?2an5
zpQkqM!U2eJHZ9$-s?yOju%_Hy@7>>1Ppq$X;2b~u&2Vw;q*SJ#yz>j6y+6#x+VYpi
z;NH@zvK(W91cjchhguQ2166p)x-laqUQ%@(4kwEWCvlc-7u!|c68ZJ5%-Y<AL-`qm
zRrH75C@q#8X@0s~Xq3yPv5!)>Q0yn3p?=`K^pC%I<%d-1!abRp-lLmNfay0FbIK!I
z2m4z)W+PkdsGXVLbxmfXx}}{uoGoXpVIe!C6>8H2ESx$-eXuf8tklZmg_5_kc>2<U
zl}O!ut1N7oo*#@Whb|i#*{{r8Ch3uNiG7VkfXY_?c%(rUvfs<s#!drS?o;FN-^nHR
zrGn*<8=EqJ{=%v^!J*`ii`p|(=7QmHIF%6eHT`*Wa@b0>W^<bs-*$(0%eTJ_p6LC5
ztO!qVp8-$wj+Wzo?AeD}en5#}TB%aq)G%3T0cirgIu=u`vJfz!Pi!uje<Bx<;o=*#
z;rLF**@~e!;VU1T)4TbAKe~_#J~j<$#GmxU=Eik3Pg>*}QFD>u2eTMCa$%T}$9?T+
zh$ya_XCVUBm&<YlNETPw?kv|U;Kc%lIYFW4R{Y1BUS#;$>-6D4KWn5%W(t`S%~iiC
z*7<8b$vs2n3WEL%WaEGkg~49%cbevQ(R`Zd6#w+?WpDyeq>zL|P~-_uwAKvA`}E7_
zzV`AnX}z2NM6@V#Ay7VQpv6gCws&8x)~GfP*1_SF@&2YGk*F8ePHi*$gCNC;fcHtE
zwE5|gRY4s@7xM%08kbG}<@<7QE1B5vfFegmslQgd<XWIIYg(ul=yBwj8MlgA_ZS^C
z)nwmO@wFR5?16djcdOj3F4RT~yb|@k;C;ESz#HNy_4Xqob1w_T@Yl;nT}^A_{vy;h
z(KVJi$OIw>be>o9R6u!8K9zB9=o=a7ncFuxy|rUI8=ct=t=;Rd7ixg1F)THA?8x0q
zpV_mqr@Z%gG_^3(-Meas7g`*e9va@7I&?u}V3xW*HF<5Jv3k9CeQD3u&Y`XOdHNe0
zz019$mJ3bbZx5C%o8qK6taRc)F2AXgNH~sryfJvl%6Sja^+bnjX9BK(GnBk4nd}%|
zWJ-#h2CsU=K`2V)xN^hErRS&?Wn^SJ5Yi;TCQ@ufw&oq9t*zb}Dk`yHLA*K~4Q-6G
z($YKCh?}D>&tIC9%uS&a$6e4JG22Q2htW|ZQC8=}@$CXXQp&86_$fYrEe+BpM{YYv
zb&8j-@m@|kR>2H}J3AtlQyPg5v)m%<9XZk}GUAoFaEHo_+}B#lrm}G*l5!m<-qRDa
zEw?q`&V`dzDO`w!s^tXM{T%FBL&86C*8#O7+tLM_)^0={U5^-pN1(g-Xv@E~cyyjV
zLEl2(OMij>GX2-|tMo7F-vdA@0<wT2)5i=m)661s0rMd9P6lx&z{kPZB|*hxm?JXN
z4<IJv*^lnUg$8r}k>-7iFePMsP=)3jZU`v1WEPT(SjjO1@E-O8D2bO7Z@%eo;mzEd
z7YYbB{?n{%vKTbCmZk#3-+u6C^D<@|bRYzR52qR8kOG|s_Ns17`UDt)Foy{3H5~gf
zYjMp*jqqs(I1qINh=~4IhDZ(ye4-l1%cX|f+k=x(Q6M1czL<xXNxD3l;zW@`e770|
z_6_$z=80v9ypCH<HOk7fO=XL}-@zo0dw7t5gphCn{~6?kKnwpKS*=Kr0?DG`uZe_B
z14^GBvY!HHj%4icWXEmRitK|9-%OIEi?4WrEL8qKRKP!b_Vtpo_I5YhqIpUrT?_*Z
zQX*%}URX1`8_ib2<z}!(AB;X&C$aeYi(*$_7g~+a6$ufeuLC1@(Da0HgEUcZ2_+{2
z0e+G*v7ZCU<xg`Y6$!xsfV5k)t$Q1F92ChCk0%9khXCOtItgQhTx}*wsH})ZV)@$$
zg~rDx2YU-T!><jYdMv@e0tt``AY)u0$7_@+2WJh$HlqQtF+i*!36tL>GtzfBTKkv4
z=h5gxRygUBvva6U7ID%&*p37w2gE@#K1j9Ec37tILJ`nOq+}#Z!LK+^IF3=Q9;m|b
zWT@Al6nL2wnUKIV6F}FK3#1=}CU^|ez_7)Y5ZP?H-3HMDqND(Efh;Wi)3N#=p6ou#
z1&VFm{MPz~n+D^5_+nz9KgLhT`e(*-=ROsinT|7axp93U<Q;W}v}mG(x;;IDolcI#
zU0fQ3ZhkCFU28<A&VFSw<K35>nMzZaWGAREFDT5p=VN2jS*ANVLr-=D&i&YF%c{(r
zlGAGGbdCJ`)B^dPs(qpjU)H8-R6&XaB|-TaAE%ftN<d68EC=`sfYqfr&>x1`auFb}
za)_5BcS?v8k#w6v;6?oGQoHRv7ii1N)Fn!e`g^&ka`5i6>6qMQgE2${;3*e03{Y;m
zu&FQ{BAgAdZHRSB4y9$P<WiI^a}@-H=qX(=8K~B9QZ_X;OqC5)i-rU(3PQxN9FQD1
z(6LaSJ2}9m3akX_3<w_qn6y>!Y*RrK9D;yC6(Q8of&z#$ibjwLC_ebM9AZ6qUe*FB
zDAdKcS{*?QL4g4YHqT3Lw2S8uvL0ZOyDGEoA#gCtnr1SUh!#f3yly$1&VzT)W(`D(
z#%TfI-3F~ham?nU1N4lV=%O9EOD<TKoPsAshNiju$CQc?-rAMYtghIOOH!@7N8)x?
zNTs$kkc$q^4#sukkJ&(=%Tp<iDFLpJW~o%5OH2R)jScpT&bcQ7YI0r9h$a*}W3n-n
zT(rVADCyE$jLtov+!W!7%gDiUH}e?)2M<TtEWJfu2NX9-F)4~Jn;#b7`j+Ff*QWqX
zK9ew0u}wBSv1Hn``?}i|AP!QZt#=+z#!7+SN!MK%y<89!#u&)~#8q*+_Xe`%!epRJ
zE-ig70rO0t8^9~j)ETL*p!@<vp%J2E{Tq{w07D(G#1unfdqM$PVHiH(QVPr85|r9+
zjmm8z0OqBlG%m5A`8%n|K_&-XEBwRjCr)%h;x>9qZ71qyY4*4Ak>TXoKx}A;naQsn
zi&2lpC+2cXN3*r=o*Iw`YJ=&pcl9FN*`qzR;*Lxp+pokgrjKN1XOh%i>8ZKg+4t8g
z{OUOMqwLH~@-^x<D+~UGH>u@<_aA8}dD9&o$qnRJdn(h>o?hSXE!p54RYW-`yG#WR
z^$4kv!Qh?{g0jtlxKROGAK11yo)!#lkRGFM!>Pscu9WkIrK`A#tb}bvlap<fvYOE|
z0V-rmVEEKj$fdk&aKQ1Cb;FE<0UHo}Y&0b}Jl~emTo}5f0?PuJk<-9D17n8-fIOC|
z6F?uf2xu1wB|ISafDog}P@K}NT0=}a$AL1EXCpZQqd&k1ZLAbgLH{UV*mH7)B7-$<
z#6iVK(Hf*66rZzs6bf-)u2AO$J;9~n<p}2oN2Mt6-I|sr8c`HBLwI2|mIguT2IeOY
z)qN@O{^%5^@g{7lK}vz22fU5PqFlN|kQVJD9q(+L2O(qSAmk<t9EN7kbwQy6ZrdWL
zZZOJum8I8nHt2H!Y7M%*lWnIsxHD@A1T)p?zO+`=`H7kc1E4N)QG^~n3zx7|IXWHW
z#Z#x|O}NU3BrVA06DAA+u(vK`bT^)M3%^0!Q`rF*By`yEP+zqik5MLFG7UEPT_)GD
zSplBq%zT(F!pIenZnz_;+l*4)d}h`7)4CausJ*TzWjKV0#ze~m8lefiB%Wv8Dv+S6
z>`XO16JMXOYi?R#!g5UymRhYkW2!s!iM*bY9zqNTeUOvJfmOmujIjl#QUei5-LOTy
zEc~8(v}G8w+*)`jUC?qX(EGmH@~xJi0HGm`UA6%junG95Y@zm2mr&PIH&S;1iT+`D
zr+fghq@M$)+4m7k`g?kU-bTNV{t*2s`bGLn^vhs3|2h3T=33@{=3(Y(=IhM&nOBze
zVD$1%gl)>-yZz%f_Dlamws8LgDIo9f<Dh#a`!_aK!~*$S8#z&7*Mf%t`MRv;M(~Wk
zA7U4)lU<g^j<<5I6R>CFI`%j}B_foOPt*4W4i98E_wW7RpCo5oUGY4DAqpQH{czPk
z*dY&;r1?G(5B-!$lBI^zLyC*Lc;DApujG#J%O_2e7(DM$a;WLZ_S^h3MEsbM7^y*m
zf{@e;VGnygq%JDwG_&z53sDn#{$@L%e&^f3KSSa|(}#kD)<U=_<x)tKSQ8<46?$_H
z9!GQMLfGpeA3)fJPy#EVkD@|a)-O9m0*JDB4Ta($)RF7>gqkN)#IvFYaEeC3iNHbH
z2V$)6K^-I!PfZ068pKb|KOhsyrzz3m7rLk^IH6BSPAGxjJH35GrPI9P;|w$fV!!UF
zdd>&9^Gk?K$l;g>vHk}SmISmFK-^YJ+w24KAfzRf5VdYXCHs;ed5iR69d}5~LkWj@
zczydq-Ex(D6DkQjhBQXHsQCg!YEpRwT%bB72$w4b_C44kz9Ba>1@4j{=aoP3`tlY0
zMdW-Ug8Qcg{Jq?8K{7F#@E>RoGEe+*g>n;LUL0_mr;C;Pk>Ws<MC1LRk6&kh5F@@G
zN0#NHqxX<LsjqJaMhA{iqy>=(@KvDXLQnh6>30-lV^~{}DG}$%OXLCaKE?r&aS81_
zssP~X-<wA7&8N7&xi#yzxE&L>fB2|f96i&$+8A@nLkm_SY{m!1Per>@qXnw}tLoH~
z=_5O+NR5@v<OO@MUb11!3#%i5R65zt>otW7gi87DbR^hX17+M}>g0FS0<0F{Rs>t*
zb`p{jz+5e47RUO;q5Dd`T0B@ut=hOf`N+)g=w}XewC^4VP}169Ox2B2DFOj1V{KkN
z3DRIkZ%^w>@3pmA+KuHHjUH26tc^>V;bdAVz<l2;o1r8<RpE_vf1>9i_wtxpO6gHJ
z2=aXzOhZX018`NQRse``#5_s3V5GMgc51Ex6p?oZifgwAQ<}W=Y|xC!jZ?}5D_n*U
z4wL#1!&v$UNu{f-Wtav7BV-}o4h}kN;X6HgvW?~ja@|XZ3!pY|DPaQoznd&BWGg-1
z&$*ivIb|~Tj8z7unR}xJ0_#9-KS1i(a7Q)K7jfUuZtmn_)N4`Z9q-OoPx6$Tnd)tS
z`+L0Ka1tDBmL34U03<gN!2R2Y6I9xzlHe7O8{6A2g9nbJxT_Zw-i%)quXOba$|^++
z<QnUbb&LTzHy?}XQ7vI4=z`YAEf85$;}#h?#v@plr`Ne=j<Z;x`h_4hm(Aq#U5S{%
z35eFVN{nWNA~A{@=8Gw~*SD60q{LdRbCp?<3`nm^4Cd;PqN}<_Wd_n4S{JEfoTNbD
zWtO@#e4>!HnAJ7<B^n}w_bJgX_MDjQh5>1mVW_B6b?Bcagd7tWm~rMXrzT@<5d_sd
z7b-Kc3@?-sl*4dTjdysqM|NHCgQe1Dhr_vHa6(T}(e~AFAXTWNwwsjFlYyz(d<x+)
z++NyTtVd(hi!h@nH#3qr{FAOYyuHHF&gh69H&bpKuYq0I=o%x;7&_a%RhbKwW&4_P
zZ@-$YNkhUBr>szFHc*dxt4*c6rqiy(IvdoDx;!C*4a3%I3NVegQnWETlicbGfe4Te
z9NU{m9B~G;-k(x<xO3x#^2ikvLzj5}euTvw>~az8oRMv_JvO9mbUWt%u5HJG7ZVG&
z?z&(Y!@nqua4Kh%Z`z~Boa*~t*)NZ3Q5(iLu2t>`iJW(7vVq7#CfsV|D^JDh2zIQt
zF2RYbE{Lke2V@XBIgBJn&RlS~-u?899CBL|ZKbM^u_8mOM&;wD5wkZO4ZFhVz@k%~
zoe5E!TTdA1&X5^ow58p!!6g*>$Mw2}5Gf^qBavHQdVT)1QyK+Dcx<-`Z`|4z;ANPr
zz#G1nPEH)7nVCW3>t+NpZ9Mc3*+h1<Z+$v(ol>r9$rwG&mRN2~(t1DO2>Sh~mFZ;+
zfjVo3Qxfpc(>a^*yc5aE^7^gcv^Mvp2!y)H7CY(tO&+>+1vF6Z4YAloQa7WRLq_nw
zMe$ZdscKesKu+6nxggUb;utMQ@!q_7KY)&5K9cx)&FJ00^y}}{*KUyDtpN+4KDVv`
zCo@B)_wY8nhfJ2q)1knP);h!kifo?x`E<r~!qXMIEQ>&Sf&)g*3S@!t)0cq@R=bmn
z#lUeG7R&(MXG9^yalM(K0g`k*aqc&Pwj}s;WtwF|ven)*P2IYCpBhYZcBNytoVOLe
z7-Bkw2-vpVctH*r{N)3(EXC4hvL^AO9t%Y<V&t@__w0xdYhPnPx53c=3=+pgBoU+1
z!KD^KhtPL)CnFCv9;i|SWj&V)yg#7Dgr%XL2H)jQ1HT}ucZ(lq+C#lkZFiQSQRa9l
zPpb^vNSqESMI%zybQBvc+?vj#+5)ReCchuY&-}Cyvofs8Tc<|jQND9Rz9h&BmTXC}
zgD+h;0^hZ5e7zLw?^pnSQWQdIfJPetE*{gohkD5@$acQCP`4YF65Ur|b>3@jE7J}i
z=dVbN*KMvZ82(tYEHk}jOM}QTidg@eHrgLo6Np9T#H>|Iv-GM^h^j~d6S_*K<+%4z
z;bHD);Dj20blbGShMJ62{!i?zkOx95LK`+PvLQEx2wxz8bmi}M1t<~;G!c1Pc=&hQ
z|Kb5}ulJ(&S#J;ZI5kD_Upsx}a~nJME<Mzp-LxxN?(fMq){kVti4hn$5WeN$_3i6-
zuRmD%Tkr7xxrLp(7Z!GL+qQmr_TF#(vBi7A+ey8jnno&5J#g=Rf4leWch=R@`AR4;
zKHy}+g@aal_)M<z$d%j1+?g%<>SyN;A6!`2x8JYdUwIF+ukrB~3!Y?ao4QmYHCRn`
zDxyfC%mRoGA+|#Ki9BI9`fRdo+kmP?-5R}CH!u|O2k`WOm0&^qfCyj_O&|N(e6=ST
z?#k8HU9oh_Gb-f{SgGB+l7Rt5Q=g%tHK;>E;nsoHaHvGdHK0;Vb=EWSwc&w(sV)xJ
z2WjK_zohTozIOj-z4zWd>fIPT?fuiKE4sFC?Yi_TD$|bmvC+GElX|CjI@H@2rf&7F
z3HJf7<WBF1x%6x1D}6Hq{Y$-H>}Y9WaYi`-Ua?g^{@`6L9|FJEij|iLFsM%fJ?9HE
zE3!C5Wn4hG-?B{f##bV)u%tntq=QEoBt^fAdw>j2<W62-F)Bii>3fnjGQMc$4+=!h
z6Y<DIgW|Iy1;NbY3;E4agGSDy9K}+z9K={C{Db$T=XsCf^GENAvEDOXv}mjv?W(V?
zL}urO!<*EZ{@wGFYu0f`4rsIE`)0--WvI!prZJiE+q^yR|D{rW$4l?>Udyk`Fb6IP
zZ=*K85;ek0w|?bA|26hG>W3LR?yOnoUYLFS^hfWMoWSZYoO|G+!#CL3{MhtgJ{xV7
zV*R&Vd(FW$-~FQZhg7I-ao>ZlQNN(2U*GV!_pOIcUi=W%ebu^&#$9*+_hR>s^{sQm
z1HqovlYO)ElQNSzx;U`z8h7Wx#Vy-M6=!nGy1v=d*5*y?AKL5$4!*eQM5&9_GFzz~
zwfwKrm22O>X|6Oe9g;5^mrg~e?Xvgle9t9M&(3LZGd<b2Ymf~$)?elQhxcEBwA1yL
zVs@vNC_nyD@2(H8?l_blJ-l%~XijW@qBGULEBuyiPhI)tzrO-wob>(M`B&j9xfW5W
zkNG&0O||9<tc2gske|s(kBo7Anx{G#0&Egc;~#PSiSD0?mIdTx6TS~}woH5K%f5c+
zp6^~9K|yitCrZW_SsgHb7=ML$L)u;*3;q~u`tAE>2l5&M3W!Yuwg~>!0b?EbiX?F?
zk{Y}xb3HR@<r4#c@vFI%$tAN>X1Yv&s5&FH1$S;N{)A46wKZAbB@8QDIzYNIKO0gW
zzArm|=bB?~WlMfCCJEx2dsf#dIXFC3v8|;8sR3$JAQ3TYtM0hgdC7{>Jm5)F!RoMh
z*{i962}7x_3F)7qrzi>XlJ~rn5o_Cp#Y?E7bQrLfxBcBk@#EWS;dZxQl;z^IkPxQk
zQsaRfLKL~i(CL|l$DH=@`>4{~*9Z542Cz4VIOPrbyYp*SSz|{JW<ITOtY}vbRUIV~
zhSD#)<%Jt^3#IOkjzk54sq40`zwpps{rwT@`sl#yn=eWg<K4SI?|nHws3#sAslKgq
zZ|C#@kg6)Gv~K;;v3nkNuB3pbV9OLJ3j=x%9`Y9PIoRag!v26e+cMHJ59{x(Eibfu
zx#c@p*LzmhZ2YEi5F&m2#+pYCD>(55Ni3v~4T^qog1DCPAB3jBha@E(<u=2oU`)j=
z@*O?h98~1|v;0BI<WNqQfZkwp+3|BAJ_;Bh#EMG-G{&0lwf-={iqP9fUMJ^X1mEDW
zzr2FLhJj-l3=t%70-hv9xzGMUs+}o4l4=#8nKc5bc>iC2`qbMWy7JTOE0^w2<S-Nd
zQToj(g$r+E9;;M=0<>-H+*4z<_s&uuJNl;DJkD3G-sr`P`85}}Q9XNd@y5+_b7g&^
zo`&sXEUq$OT#@N)W>rVNU4YJ93r+XlcXU@()|jrRpN550uI@UTcEgIJ(~T{wXN_d<
z#GJ|>f6u9f+Tc3xN>!#rM}DF8nyY~@Iks!2&fdUwpSz+sA;*=0soT7N7LqBzl679P
zuM&+`_AQj12uwFIm3q0I5AlKc-t?P)xK3qS|K{fQy9#G&g-73X%fq)WI?me5M1(Rx
z27Q1Qlh74vPB31yy6^q=Cj!MdKSWndv&tMSXwRSeWrveXI_Ea0ffXh@cD-&o8hm`y
z0aL+$q6AoOEDwem5ZIh1hLSjU=+u|$d0^sxA{0_pwMD{Mx))l%-$LVcu;paSEpR@b
z1Qx*#>S$9=SefHw9H9#vzG4DB=<ghS4t_w*9S55Q1{MA%+YR(RxQq{mT65G9GrzBO
z;)$IJ2wh}^VBi4n%pYKoKbkrlviJ}q49sG<k3^wx@OP#h2{jjpR030&Uy7!Df|4``
zC&mp~n*1F7LN)q;<j9_n?}AID&*zBYj53iS3JAUPs1js@<b7L|zpOS7`ztG9b78~c
z`e!yUvL!Yv+^i!sKsn#o<m)KV3>d>Cwu(I0ROujs7)B@XfZ3#R$mAjl9iHBD`rl%M
zrs>3bs<OO!x6@GtL64ca`(L~ty-f-v&K$Tf%4^JEoHi0h>rFTPh}!bF{@T^tZtAk#
z;)EedIg7e@qDXt69N4N?&2>k<vGhrbeU749RojIbq&GFu+6z=!EkUb%M|7=Tq+ZoN
zJ*$il)@d`G{$MyOu9qSqbv<ZSl}KU3=tz65*4gfi4+OQ*P|DtX@mHVha_Om5zxP8*
zz5mn|@9zOqp%s|#zif+43*(Vw>Zg}cac|Q{4p7^AFUuBbs$92~xTWj88V5&5{WiN-
zNIY`#=)qI(iiy4QJ4hIdS;(?NYpSaft+Lvgo4nUKfJ4PuL29sC&5Q&?MZN+`Y_=Bc
zHr{iI8>jdU)50wj!)7cSPR*b<;?@O@Kji%&KQ4m+ke+lBldqoKO_iiv3X*<*yBeIn
znAhXA{r&B9J-z0OSj!V@^zItymw;r_c-OlrLxqyYLZbv%2Xn!&o)CYcRow!R_v17j
zcqrA;Galz1mC?X;ZO5!m>QOc}2fk`GE;7t6N>`$?2|9W<+n!rYXVmouzYxll>WMzs
zqgsK1$wbBg<i)^5r70lUk;NdM;&ndmZC&+dvnWSsDb(MHA-u=bU)o%5o3e}^C0PYT
zSt1xpb{Xkxk{>We`r&l&vlt-R(&dhhP}~T!`hAZUcz(tdGnCB-OtZuLv4g`igCnPW
z?(T?%z$YH|EHFoEQjp?X;4cI|Rqj7A;Jc}}BBt`g&{uz*dWHHGJwh+gyXYfiwl`P!
z5>#1aiuzJQbEdCokNq{AC~%vzpX@eG72f&P-yiD!+$VF<UjtU;5Udkqv++MGs|d*l
z8eTG=iAJu7a5e-~l5${qAhP2S)#u9&M06k^Fa#MHGuoGIdZD>1tq8V%QY62W{`3CQ
z(A4HOw;AFR)GXA>!qnU2uTg~W4L7j3VAlGZ6Bdc)&P6;1{PhI-TrT7<fae7$KNONQ
zLbJ+#{rn{m)eMoUl8S=ggh*CcyhyE<3rft@<bma<n>OcWo0FOnUk~Dk01g>{nImi4
z^0QEMkAcsSG!m%<itDR8eZ{O_>u$G~fe4SDDHV#)LzDFIA-+wdwa8n3BcL!OZL){2
zC`_T(#a)sm^wi`*2!2HNb6{pbhC~lb+7z`R8g0T|=hqS1-sMIhCGzXc1Ab@a3z`7^
z=G*4Gx&KV8+BQ3DW8r6`U3F@r7LKvnw$9>^J52T0YMD`iUX3$+s~U+Xs!vs)8p=gS
z_NG%6YRC3tX<pIxJIOV3MjSdS1C}~b1%>k#UdwIBt~uGZqZO2DvXhCjMj~#k19KRN
zx!FfRr55HkTcVlB%<*js)E6g$IXNwbu6u${*au=z)xlQX00bc|Mc_vmOz|Sj<YP=>
z%|(Iub(gYYc=bc~Zx_b`g&uQFH*j||BZB_q(P9t=G2kJ|1+KWU)vARuOvj16w%E&F
zrCRf=_E}K%9WZNQt&ffmPYA5{$gzpS#{LfdbFJkhs788Pp}#5y0qbfwi{UmZDT$hW
zh}A(qH<^g%>99FhkBBPEWO+4mFmh#sp+zSYK7b(n2wzQ#FQr3>|4-Uw0}LZV54&bv
zqEP8VWJLl2Wm)=dg-?ja)MBhC@w0E0G}$ooqW2JA+H>o>Po>>x;M^;rK(stf4W?Lm
z`~kb)NK0nx`uv)W(0jE4RuVwuGT?Mdthn7~CsILxKFe%nZA=TnVFLUTqKQ~TlK`{)
zG9bvi;pGtRN(*d3<=??W{cDs960clD#jz2*n{98@s#O(QDuGV6f!O4_MDV2pmn{|p
zLwBYlAvVd&?E*vdeQ7DYHi<}5i@^YyYYh*F2cp27Pcmw`)ITRX`JJDA9!$DGokYL_
z%(V$KTO86x-#yIm(XtY2?2;Wb$;cLExE&IrV!G`OG&^Pk7{=zL@~{+wQIT1r2p|oB
zMK&93)l4kzY-Y#0qRXqPw*X?ydN?!DNt@9Dv(Q(l7Bf6>gN(RFWf`%MbpU;s3)>4>
zDa=W`o?1&C?A|n%VPLhVg?yyTEZ8xP+4jX%BD0u?mWI|hGJvs+Q}g|tq*fL2wg+r=
zDKm9@I2aKYx;l=yA!)FFa`(E>pb8{O0sgHZjt$N_PSi|g6ZWq3Bhu=6_O{)@O03OU
zbne(d@x8$7L||0svEx@S?N=f!Gh)7$$^j)O#4K1+8Y()0VZF}>18!OcV5qKyp|a|4
ze~T9FZ&QH~8KkBHd8Z$Nb<p*$+r8PX)T~WPA-Vw~#^&u>zY^RA)Mc8F-PaY`*}ex<
z_7o5x<ai~iCK8pLq>1K&oa}``R0`8i25Z2*Q1uQ5+nZ?wt1LZkAJ-K-ETwB*kBO9F
zTTo-Rw+6MDd7+P&B0d%bWX_{J2XFPuTi)Gr7F^L;vj1Rp0s+SIu@-n-%iG5r8wj~T
z7L_+XzU`$^fdZeLU?HAmx_lY2xh;^T&)4DjZgpf`@`X^cbops8R&xz(ZhU~R_E$0J
zjY>YD23a=izO*<>+2<c6%P3wTK1pQNPGf<@@AKturiF6ClP}c0yxsU~I9A#ffzn@)
zvD%a0q%gii9_kBkZGZj5*@>}`5m}&pgO&hXMM#QAL;PT8SLsNZ@&04YSZ4CFo`j$#
z<VS|xu6BztI)j+QR!)ky6&i&#2eav20Q%TT<=e%H_3C>A-k@4kg7du-Y+yJwV%H*~
zTQ<UsQERWCFyMCF6)ym=Z|<;WrwZEL_q4^Na8T2gUbEa?NpPj<p}`Q<mg;P1LVTlw
z6Rz7;Ga81uuNzU`3<td?mAQiN#QJGE8Ft@9{_hX&)<)9pPGiv2XZrdSCo!xq^iG7g
zCxm!PX?x(-lJ=&HH_Sfz^UH(hb~S39Z*5P(ccRvN?R1z+uCYTvIEVZ~-6wLp19=?<
zeEp+sgY{@Ig@Ex?=S=C8?!cu2z(OvUKK`C7%MV`ZR5n{(xr7dq!E&wK+i~li;lg;9
z3xh8+Q=M|;nn+1}7nny%67@pV5viU<HIe~EVDRiO=<ka%9e`bf`S(;InKP-Hz%1!p
z7n{Lp3a;gjveSEz+o&l{(O%bI(yn7Um$JgrQo-q+2{P#rJT~oQo6V$^SXP;=w*fdc
zQr8@Y=UUs|{j(2W6rGyWx@c-XGCjU(NRh8`sL!`1+<W&`&)zgJl@r$ROP{B=#lq(H
z)$LF&tI4GGE5Zr)#}mT;<L(A~gwygS;354Gpt3{2#P|^PGWA31=hPn%vXr2UbSFLN
z&ml0O6Q92Gcn27yWOOZmdR8R2m0=3MHr&Iv<=OVX<)iK{-_rRfdpQ}iz5ql9E}2uy
zUz%f@xCfli%^$tQDbk-J=jWdPo<Hu%G%TDKM*R6ePDDr+x0io5r)tx%o+V-k5!0Gw
zCSUy7NPZH?CKPRDN;O|wSuKdg8g&2?$NA^UyNr*z(OeE}V(48-kjR3|P2^{Ge&Ry<
zT^5#B77?@<c?7<=NU*s;*+t~;mxQnvb3imCQ@oj86DJ}`!LiVPrMbuv$!fVpnt$MJ
z=%M{;`gQR6+58hOY0GAh`d^z1Mu>tn$v2tX5U7RbsU1?<pOuyBMI(`7+r(Xj{Mn!y
z5cJ3r*~eXYu^D1-5tUn}45m}mO!|*8C6l)*>q3l~oSz-rx^ZY|GHC~4n$)=B;^}9H
zslqf>w2isLLNV1D3Kx=nQJ!$aud?jEuG>?`W^M;VSs)Fsz^%{sT-vcgIy9S=omngH
zUG<bQ|F-PKePNO3Xxn5h!4x+!T&rnp4asE%0H-0t1ng*156X!|ap_x$!uxJppPbsz
z>6ExuhA;9~yIr1El&YdtMAZ!>DCW+jHoRH_VDW$*?@USgXtWq=PlAp@@9waZij+|t
zAa+~o+~8n&-R9V8)RC$in@7ydxmZCKiVO>?VBkI@T0eFumWF3w>xnN6TLsx#?aCub
zrKHfKg_L1gPAwL$(8`Q5eLx*fM>>NY)vDW#ptpTycKqREo8UVJM>+U(6_wqVTohiN
zjN=d{urU9H(>~oBWs4xQVBUT6h>iVmVq-of7yo@c@%x;<Uj~y`6zrsf`eW<#N!WFH
z2C6)fDp=>f2k{VmY5Dxl0mq2+v;1yl#1kaS)F<z@+<I`V5VE+t24!azhzIFy-<=9o
z;{z9$p0lKsmJ8QEc?Ae}&V8{r2wswPQeY}+c6u$;fHg6f0(ZSS$U2k4iQo+?m)>Wd
zGbVeTLK!w#8B2a8*3;RhSz(~=edMysR$pNiw?xCOR4f&qz-89$+4$A@eHV9@QU+Cs
z2FE*EB_<>Yl9eo}?W${}t>hj=9f0vTd1T8S)aOrtgDsdf+HyIun<(A@THRkBGN^>b
z1mMpvY2VJ-5!<qmk^x#{=v3OYECV0Xn6z|7{^`W+lv)p%TsmxbXahyymLB@-Rln~#
zP>VXcX;ep~Ak#A(76MulTJKE&-z=MJ9B4oIipQrM8c^VF{~mfuX*D_&#A*by2vO>m
zpf|g4%g&c~7672m7M*ZCKA}2^5g{Od<uh%qJ2pLWO-ade>gr@rx{YefOn^BoK!LCs
z+TOzS($k-<X5RbY0DLU|<+YxQJzkWv3m1O>J}Jou**JtXZBg`Iek<KsDfjf`Q=yRe
z0cS=Q#udppN@WTUPv0{5oxR(xw*-5w*G9#AB$sBr%a{r3e`o-OMuWjej(&aE)~1zU
zn2v^%sc^*cez8ai?W3tq>Ur1u?u{I51T^-F2k5VGx3?r(Ca@QP;x_|PhPc&}Pj9gg
z>eZE#9%E&kZm<FP|8QAY{?j@CN6w+Y5(+N8s>ctGAa2FLKns|f+?C7i7&_r?eeNTt
zPCdo*Pn|mT5&22{_z3eGQ9JtryGpVG7qtcLa6HgckJzL6kd<;m<A=_^%myzU8l4z|
zH={W*G}S9LhNp(#f^zdMkNoj>!cq30ppA4|DqvlkAXYrYFM*>5AFMwunRH9jUI`1N
zgKNGq12#MIf$<9D2M8E#>F#PN1<Bvwbiv=k8;)=d;b=IrMSt+e-ot-vfwl2r>NwSc
z&+)Up$F>|>sCBh3u<!Ps{mpN@XQ_3+`3<%18t?TNUhrP0_!nNF`1XH&`ssfq|Co=@
zdB0qG52#r02`@d4bly&#@Y6Zry}f;4ue&7Be{lB>JoA|M|EMVW_n24u4Yl6;I1>Ii
zwf;9Rcz>V-q$qfQc;V?^|N3eCYiZG1F7>|2KgIncH2X$Ns3p}>f`xA#q6zmQX7<{a
zx3oM!T7#_i*lw49mmo~y@a>Yl`%ka0NRp)@y|S}lA8l@nE##L^3D$t>6PMxcMmE!s
zi_ijMt0PPd<SWsllDEK?fbZ}$^S4*BUGy+Cx4chbOWUjAzmotLQSOx%f``Uey9n(A
zTk{YA%QSBH?Web2anI<fBhOsaHW@5(XKHpxHwLPg(#rA7H5a^oG@Su6JQb+tC?+D8
zwi(&3EmkqMk6QPaw+VZrO12s;Juw#1CtGt-Z;Z7ul>^i(BdLzzR44tbZ$9jO_UG};
zft}gp_$qE43i2WpbDs~4^INAnU*&00I;5(`+3goxe&~Ubo35j~ZfQ)~WnOMOoN(QZ
z^_#udt}cD>9`;<r&6J&Q$r&n~&W9^&^G=Cb@BQ%T%aQer%q7#tlg}xkXzO?wZlAW3
zl)amV+fzferT@sI6aV(WQoTJM-MptI-m=eoiT!8pUFbuz<q&w`{;}m>!0yG<pQitj
z{!jWG)52sC_futhna#|0<|uO!b2syT=0nW$%!|xdm~WwnbAV$+2N|$~5bY7X_OPYH
zZw|`+Ai__8Gy+<WVqZys`ljLb`MPI<u|>jQmT_9^h*qehw*)B2kk+zn;F7-V>vFj)
zVk;2LX;63wc|c!HQpWRecO>bPWdK?xUxI_72KnPDA`#+B4~#M{Q5@j`febu{Xzm13
zN`ibg#*}cC$S$2O))_xU1yTj13>cIl77>xuz#t<zL${BD<^<RG3?+FWWdUbDJW9Ox
z1ZdnCuE6-mAs6xrRQH`2qfM#MSMeiVw}Db&EaF|Xnv(-K7RpI7Bf2jG0D?S_Sa1hJ
z98dElT!wL^*;c4HtO0nPWL?65M|DvRco@QJhR0JdKMBD;;*p9;(np%4DD?UTaN!e)
z=gEs$U!c^3rV9<#hpLk#AnhVkH^-BTz_^ZRAd~_P)`v=yZseU#^dlx33Wc{zJf8KR
zK!+eIhRiNBB61)ZAYlQ)PRoUc-UR^HxIjh*l58eI6oVxw=8!9Sxf}U(_mSQu#cV1a
z`%pYQEdV(U<@42cE2D~Jf+8VjECwVcQf`tC=~W2$=uRvVBmrE+ZFD4gfMiBKBp`<e
ztV|Pk6m5rF{t|M2?74n+c$3d{A|-MYErrws6af%6jRLBO=wyiYBzv45NN*8SO!HAB
zga+vnh%+vE65u%)B&b>gFg{2SgA2_}1`ZF5H&SwRPy_uV^p+gAd165Kb)hFfsv{s|
ziR49ILl%BZqJtV_9CagqbfilHT7Aj8nCnDo$r$k`4CH5lgv~GC%L+`NU<pi#Arpyr
zZSqI34g~pNHV#k!H#<B+MU%R`lcP9O4S|0o2ERQW1~~xQ0484(YjA)P%!m$sFDr)&
zrmFG?UolNiwp~pH&0EK4R17+R#L_FQcLh{K)Vu^<4$z>=0hck2vV#TLvLz`VaScTP
zMT<aFF)cDDOTn<D>IorCaUm%PVslQDY03#pEFoW2$<YFQBZ+)MPEml}Q4GQR3*OYF
zY=lXG<Hcs`kqY}jm}bJJ320S80_CjC{0$G5Iyp!m^Txb=@8Bppkd+ZBU_?S9@=HoG
zVuZp%oJm04*c!6HQKE-~VVkE*@WBF_KNpTFR8})Z(^9Rd3w&fn=m09S8cM-cYLbbG
zm7owwh=?q);2Ea?-7L>kK!K2?x{@lWfHl4*$$UK^cN$?04wDkc$$CtPLJ=8;)=GmG
z1fGN@<)j$+yCniiTF?+tB<I2VWdhm40CNi~1~@UH1l0%+eIVfALHetiTCHEJ=+sb3
z;#Jq8Y1f7SS<ptDY*3Fx05eW?$t)`iJoH?=PRG?&hXOJx7vobhZ?ItnVOB9qP-8M5
z5CW<U!&?EpsUc9kJ!r{_>GH5yD*@;S7^#S$Au$5~U6l_>fHHCzLV{z!Zw*ePsfJl+
zXmB9t5t<6*UBQL~shS0ZnS?{3v>t<@iU!>a{8VW@0lc4(p5t63lS^f2Sq4Ow3yxv1
z1gPHMfkhdN06Kj15PcpAA{M~JEeqX^2$ckD)bN1!IK*Qr5d^^%qG><FS!UD@CuvKj
z6Qbo9L1@nn8$>~|?e?d6Sz+}AjW8SdSa`p%HBH)4G@wdUpmjl<m;$S~S`p!SXoM1=
zk&(S`SOE+@LkOVJ=&B}}xr9u)iX+oDLR#byXL44o^@1OtqHYM(cB+W1S~zulw)Fw7
zUXlboJk02@Ny}1hJ7C_6F;!CmFE5*%QgMX3UO>x88IUJ4hGN8B&g7x2kwjM#%#3Ix
zL01FlCLPj<BSw^HNb-Kb*h0W9;y9rv7$>X`#2tr@F_t98^L#3RFccuV#cV{-DJ32g
zHAVv8gcxVDaI@tCnrj3jn1unr@v#&I)DzLn6dX|pmo^tQfywtAW4al>-IF<8$skTE
zXjI{b8V64)k1!Pt0c&`2K-5?SJ4<3VdiLH={~LQOmsn6WVCa~(7_3?tkQxI2bu&)u
zI$VMQy+p;?K|sx6SP3A-0m`402qyTjqBE4<8icE=6;awOJ;g>u=nYsosw40XV^GxM
zIBF^|@rYr{vJ*L4;ng16m4i;$aZELWWk@k9APi!#+^~E`l<cHz$bcCH2A=}QZZ0C5
zWN533qS>run*i9?F)n!Cg<_izApi-?yIe32kC%j%VFGzW64Gr90AZC{$^_lCl*2(u
z1&$16hYA;CH7$bx0F>i2MY}*5qa+-vm3W-BoTMluL@khU)u7BPI7(<Dl+h+bTPZYH
z0h(<o&YJ--pjd7&6yP9l@;RW*1awXfWf>+dh~TA&u{syit&~aOfX5qFP;uEHu>KT|
z&d0!9A)Jg^3e5+ohzf&>ilYrs8Nr^Qn&Mf3<Ns&}bVCXtuuxZRI%J4gH)u?&V4QYf
zmB56e75a7F3`yV@5H0Tc4ingtfi}uzf=+-2dppLA>J&9u>r`0dRmu(r^sQLztQdmC
z@~UXNA;3)v;UL9jEC=-!ag5(#@mwxxae52`w_l2j-VH$*bk{O@E^LaWvyWDHvD>0&
zADCo!Ic3(6&%QXx?r(E)XP@!UP@DdEr<iA-1p3R{;TibVmj9x_Wqn@rM>cieio3kC
zL9RedFZoHfZ-jzlha`Km|M3-7=l{ktz6OfCvFy=7oW@9C4mnuV3A|QQ{qCoR4HGJS
zY{TU4vaOiB=t~PZNFNQm!4cG-<s5<4K%9LVZ!pnj-_Tn**m|+~LVMS1`Cey!sURQt
zsdabd`<4s5qUUQ$XuwN_@k;1{$U~$tpHIYYi20hKhYP8VRYca=;?UmpZAUAa0=5Gh
z(-*GZ_;~-!VCrMti3sRpMyzzN?yASl3iPq2QOIFL%IZP}F??2|d>b`&$;oMfotmGU
zU$u_wKYkb0byvBnyLVr)@SYC~Y6wsfDJgjU)m<Z%z=n5?zPY~Vy68UXLMuMkDlHX{
zY_8^~R!0oebjQz4<!Qma@~eSt4qRLmBRF}D7WnTb2j>R0bD@y^o^P8oC!C2MQAWV+
zP&hP5ok>SNl)ib2Hb)}8$xBb$$jYi2miZ>{Gp;^96`D?clv<;*;<Z1UpWj!>Dkt6?
zop&lK$G?LfI{~JJ53PTUzOb?ut5R>cbH}aym-RK)tsfl$HQSIKhy>>bir4j91+l;m
zZrDS$&94h@ti>(cvLhWE+>P0AIT2p1Dc)DvO@iFknyAJNRnILHhB~_@1LJ|pgVfqp
zKcIkbhY(9m40!)N5zP)QJ^DT8v=oZ9=E}0L>1_+?iOyHP%h~y@7t$HE-JvFeYqcOB
zC}kXK;WN{B9WH;hQ`l_{r=n&#kTyyc8MDm&?6&W*N494bt>f`fN6q~iCA4Dv>+o;*
zyzp1tJAlm4)=~!t?4Fh*I6J=ySd#B*d2h>8;BkKr{<46nAY%d_BJhz9#>evaCNNw^
z$oNjHnJydp7@T;|k5r5)U)9|l+n7-PdoG;h{HcI}ZQ*ZZ0P&GH3X#cFCr)_8m#w#l
zvY?Pbdd*ovgj|xjZ}I6P?sftNbqzyO=qmU!EpbVPn#L0T$}?WS_D%n;M6Q?(<|GXH
zpx84}>B)nuLCK^8+#<*6^q$M1IzlwSG3L>0^oy3hS#B!_HR#c78;}fHe*KLR_x3)!
zJrMn`rE}bkLoYtMCp1ua$$L!erVfUdcEE}-$@k_s&9SN0R3wn0Z=7no<lIZJCzVw3
zBeR_y6&aD39AoMq-!pcS9rVm^d%O9!QQy+24UcGMWZjp}dCJ{hoxSt$4@2b#5@KG8
zb?I#mW3=tI^SVgirAO+mLX{Kwb4QpjZ9JDd#C)xD*Ad04WYTsk9pmOqKJu1maazPu
zp1$J@O?76^UBtShXMYlAKf&^}p5jX5azawfBhuLhsH-Yxe|<67?Jh<r&Zm>%ax@Z0
zjH{W_vdO<F3~oD{g;nR*?DLoH*162?vtMHen6uwtymK^$3-nBzytfFy<|8fF!GH2?
zSTjEcFUo&t`6<xHw*!0pozyEdOILv|K1fdz{}}pavYKK}E-#UPVx1(b8$MWq&O5k}
zzsUu3KA7FfIfjG-=3owd<2w8(T%15wJ~(^y^)`VU{MX1C3nxW#n*fc6FcAF#h(JQD
zo)}8x0<b9%pVxzP4^I|t==XbY(8T}+6b2N31l9v*77K?h04g*eB5#qQhsRuUq-#Fu
zCk8VBFbhd#9OCEEOtV=ra<LsIUkCH%&+gzf>5p_W+DUDQ&!=AtVq)-*aw`?Y@22aW
zKW$+5`IEx=r_NlqF9$3PQZ^EI*wsg>K+Y-TgFVVG846O*H9cFK6Kgp&7e_~bZ)-l@
zbYN*(T$=ASO&)%Go-Yx~(_}Oyi9iSDSGn1hu-^JTh~hL2u%r_$yxGJKYChEH17Trb
zFBEWiANNSh2>w&e_C)6}7CH1bJBze$4^FSk`ztm_R220rHoJ;EM|#Td=;kvkJ+<5z
zSSNn{=n1Eo-jE!BaI?3;-Mu}L7^)25^pd)uo3jpFCDK}KII=%pndKvZZ4SwS&t2Uo
zUm7jVurViNq*;Nzd~ll@DQ}?TT09KG=73$11INd*tuF0c<?To*us>9yBCmVJaEUDi
z=?;q#3PxOTh6RZYCn-+mdzW4i_y8R627wEaGqHKH#Q-QFSw>^Q?xAvxrH{v2W361j
zD6U;KCm}|)QdYx^(^lT7MvNP+D_AZUiWE};-VFu}ecTAgWxM#XJ)#lVoJs*-quvm8
zP0Ge&fztFx-Hx03DE*@!>)xyEHO>D|*n0p-Qk84NQ@OfQhwAE_bDZhilk@D%PS~B<
zoHM&DY#=QlIfw!h774BhW>lgm7g10_LB)vI@S$7-*BtNtj3B$+{LiVLMZDkl|Nj>B
zRGo9`)TvWd@B5xNJg<Y1UV8-DHO$M?wGu6B{ul$0WICZ!R=&cCiS6q*_Uzd_-o9tm
z0(Vnp;ceYmp?ab}@7Z(5_Gk9odhtcKxHXIQ1{>X^f+5wNd*9>kp07+Vr0z%!TsFPu
ze7{@b1z+8wtV$V6*9ligC*3_tGOSa>jtR}(9i1v~zjmQ}YwKf%H<9$Ko@^vN6>#uG
zVs+ZF;86{4Cg_g=h{35_vVNyww>tpv7!aLy>T{t4n+8a&BDcr=`CyjT9Ysr=W;6*d
zEj)k>6c;>(TmMUjBa?$`$}9}mQUXi(K!o8{!5M<sNCg~J*IU}JOj<mCzavm`IwWgA
z_5qf`KDtHn-162Zuis7Q1I?+Xd-^y;Xj?dX*hu(FbP91#%B52t`6HrYsL_#mrJe}_
zJHYq^%}^o>pblG@Tj7C^j@1_JP9~#~RLtkKDA!NtQsrLud~WxR%mVa7hR<nh@27V0
zz@TV9MjwnsS6Y#BtaTsjO^Oa=?Xy5b!B9xRCr2Kmwga{T2<o3^Xen<Ec?`v)Nvy@t
zS;RZDXcDEe3GbYwx4x!LOs}1f?yKY@NoZjm-i&&?iq!z`o}mWP;g~L@r2?c0%M5Wz
zDfV87gm&p8`lLPVoC)`hRyR;v<A7Ol>9N`nQthrYkQPRReQo?DY8PZY#b|$u0ep!p
zl&d}tGB^XHt(UU|+n=1981fo1w}-B&iKUH#?fCKQcLU2X;-A~RdvN=^zv)=avinP)
zdDcjVFDzLUzpoq^n(0oj86EwEd#gXWW%gaO#+oTMVfSKbAX#)|w)I(J(+l0-fnGh5
zNV|f14*&}Um(?BW*^E$hC&G1+S{E9a_P1bf3XwamAz3aKVN_TGs&~~}j77tdL_|hT
z7zeTi(-L)8UK_V5g3(@}wi`YPmWuC0gR3E2ZB`xLlvVKvcGa))27q70gn`E+>uURx
zNCF$lv$_=`7J?cLtX^DR%%4pnIa%7D7CFQb#JdI%N3g%^d}PR8UNc1F5xcGFFvCMY
z9U(25#Le7=5n)-rF=eL?M-Yfm)v-bo5*&{KcaH2BHn%GZFB#M(LHSHl*#Jx9q8-B&
zSwk2}8$qfQphxQj27osa!iersZMGA+O!umHw?6y#Q_r3EPRhITtWBH4q1uFRT{_42
zeQ!<u<Rv>!eTC}Q^Wi=|5fMdul!NpXa&sQWz3b2mmC63TOD+d2_0m(<oR#!`?<wlo
z-|57SD+{UCmtP%e)NC1VU{|})eso3{2{;_yMwN-(`oZ?Ex<4!Fhk5bgE6=dK{hAxT
zJ+mZRqp^_ZYkNj7pl3h!)QcDVg8nWw_`j)|U9;}kam}#Tw(ShRFyQ{{Q}lo%Ja^+5
zLp7UgEP>%!oj%*X<J6N>{J}364n5v{^!T@Kx}|;B2XFn_+5i4;twL14;kp3j@&9ls
zd9!wbL%IH%^icbU-~Hdt)l1h3uYL8KADLLeZ5d?Q`$Jm?zhm0^+V2rQ$o(29>Yv3k
z!$gOn9R({P>U5JCQ6)0{%NyM6<3u1yK(g$F1>t~9amP{A<TiwZp#;vjqzAGtBq9a0
z%ggQ1wYf|1rA!&)O&24&TAXVxG0BcW*d^I9_4ys&2owxZF)07Zm`q0t^BfoZ5w9;x
zd(Jw`Bg3+pUK@7=of&4qlc>gLmG#{_+}ZZGDC$L;ZhwdW_?6bH6ei`7M*eermwW-u
zA>8)S1+n4ucmjaQiP)4~s(XV)DJ%KLFt>WDkhAq3atVoiaMxhC3T3TbUM!RBX|r)H
z>G7miC@ag0vYqCf;_TQycP4Y4tCA}$PI5icW>ssd(fPS<K#L;AxM!-d7SXgU``pq`
z7bNZ+w<jf@GdOsT5pcN}aVkBPW?x&M8T5NIP=eVR%EE$DD25>AI6yn~C0M4Xfs}I;
zGbwC1!*Ci@O0;fZ1K~9MrZNFQ&{&wzxU#6o1%sVsk+oTGxX##^?AK)bEN>K4PFPgN
zb4Yp@K;k7O5EuMxa<qHsjMzZRt}@gW4MYfb!S=MKeVOn&pX}P*buRP({{dg2E2-zG
z?@~XfUIB272N`pk$d|JXYat@6m>Y4mdsB25F&&sT6e2ivzE|?~5+cx9BH=+U%R1!r
z(?@vPXaOJXTBit9g1jK6wAra*ps!!vfZ5i$INli2f!RN<L1H{$aqL|0^luf`0i4&N
zC(GxNZt;4((UPbT2r23G)q&5(JJ!jRW>)-jQ3j%9=It@#N;+Mjg@Mw}I0=#nj80go
zncWlmw*0z6>Cw?JKt@|GGRYzaZC<Q;`lG?;Lk5a32qPlvKhuUmM%ejK&@sZK$ai%5
zQy}-<vDK3s1+@jN8@UMX9L>mwWeS7lY@1(}IX2?YPK;ii;^oyUxjoDcKHbweek3h3
z3}~iZ_q0yvG%YrtD-uETRTF_PUInDz8<P#o8!;T=*MQ(_=GfuP#cAio07ZaL0oJtU
z?IIC0E@X~Nc-<fHCsK#6Z7}Vhi96c=F?i7>Z|Q5uc2}fWM>?_H!9qs&|Ga1Qj?Iw?
zTl|xkHF}4hbF&(C?5KyOxJ1;jM+KhNn>I=Db_cXfq1jyFwR$aWmw$1m&mqowwWcN~
zuTZ1miG{EhsIaq{$p_zkqdf?TNl!@bxF*RxSBM65f;$WD@}{-$*@(-Aw;JEHEkxbA
zd+mr3zp@Y>a^+&v4;=r3%u`M^9<n(H9Eqhz9_l#{s8@+~+f-i9<$`@>spl$jwd{+i
z(dq=;d-S*Z$1X4Lerr#{t-HDDd24V$@(}lv6+t9Kcl7ewKsr<Z01Yj7(VJhgaV4ix
z-OXC$O?-xDp7i&P+V@%5j1p5^k~`+rF4ww6K5PkxQcNP&n6w)u&xS_2y!0!_V!g)2
z{WCyIV)!9#bLpy>{MirLdR)}1i5jS!3d?~qc8<2GRsbBALa7#C{GLN^-I|{BhOOBn
zia-^2UbA8P$kuJ&{m|}Rif7}B)hA(`Nw3xV6iL<s-R&1b*~akJ{lo5N;_<1he}vlW
zsQVBXSA)Bk)Sp4<wLAy+d+%_On;l_C9f<+KKH;{c9Z6p-5YSh-bQ_Q|8YAbme;-7i
zKCS&}uLz|zH2bpKksPIKDVzVeJqC=vg`Uz>Poq&PuLy4nD$ZdwTG*1G)Px&*LL+0_
zY!h?<E?fB*#4E3O_kg>gx)0bLPYxOhda!p;DwSA06@%Kj1VJu34=B29O50AY=;<EH
zdk?4S7mB*uDXR{90_KA6SOc}p&<r%eism_E%U}GxLZE4J$<Ao0yZggeSS+-IOP%+O
zks3(KZjv!sb14q}KdS>(5>a4dWIa^ham6(j7afv^tOiizDoX>rAIKzuaLCvGN?9y0
zYD(0jUNvlWGSHw$kvgN04mr3U`?btmB+dc|Ly<T-5b{WFt7x%>^SuVeu_0TJ)2+r;
z=c+1~E6ZV9BE(x2!yOb1p8^m7A)Mj`$Jx3&9|+h(yhZoBht~Sr&Zn<Zc)Az^v{{gr
zTroS49I{bK;#fa@u1|0)6_4w>g6Be!$*<lP^Z*4vpJe6AwgdFxW`A}vt;cdOLZm3K
z%@bWWJhWEZ?wD==GCSVw6Kz&8c&^u{8XgfSJq4GlvN6wiDkjD34p)MYebr^qNM39e
z>{d;*`ei|O=93F_((nF+=4T{clthjXIvgV*>Yz2a5%_<M03W<S0lA03kEXzn-Y<NL
zXW^5S0!H?Vu0?pYoPkKgV_jEv-P-kmu7|pw0LIq$x_;mF7kGj*$p7F3dUu?vQ-i<)
zID<MDSj~3<W9vccaq5fI*Uc<&zo7mLey<ifNf)7?nV~n)yXXUE_P4jux6mi(_nG<M
zo}s@6?5&sSKhm$zZD_8nu(2UR1JV+-x61%SP_M=9kVKacjVKHlCjG_I-3^^whkBbu
z%OWq4UpfpzKtmFw2(g!N3KA6KHt9Wau>m#}3St7NuG{Rextu-}<k5|KQ{!&ZO1SEh
z1_nBYOF8Iy0}5~RTwEL)1Jn^c4FV+7B(()LQ$N`Riy+L7LKH2Lqc8>{*mby)=|tNk
z+z?{{Hz3$dIFTHK2a^-cpj?C!K_Oul5Mz3kV40e<oOElB%7r^3fXFEz5|{>af(Au;
zGW)|#Lq0HRKWUEc0bXiyZwv^nz`)GdqADVXaA3|6v`%DP)s7;R*w;H-4a^HSfWe}G
zT;2pZ1%4T(f}CUWwlwrZ%k^d;vU%IfGKQ&gfj+DPD?A*T%vm=@3G+sl9~8O7KN;!r
zT@phGZi0v+m}fk8;<8cgJT_dx9J@IhSCxn`;MB`u%bk0|siv<2IHfriWCYm3nI?xP
zmm{!T<S*gL<^v<cF$at~@+b)RM{WXg-ZH8g@fN{k<5DFPbPNw2J47&PHqy)X8oYbN
z@fhbe%u9B9X?B!mX5$i6M&#0_DFmwo@_5iG8B*tnymOrSLN%CWm^g9?($n%;=;2fE
z%MABNTm7ll|4I+_M}a1?@8(o`&7xI$LK@OH-3CKqVx@6(&^@te8*|W$g5`6ZV4YHW
z{dK2rLM+_vooVd!Vb$6l(vJpbrh{?OZEJ5H3FW4!xuD@GrViR7@7TGOpXsxFE#_TN
zDQl@T^x!%JXw??)%&5~cZ0UO*`tveuG^1ewD4@R{6h?TD+v7}W?Vsn1I>3y?Fem+u
za=RS~N-0?=xcA1W!Htd$z6`gY_E8q$T0_eUw-;nXzo-P<8d}^p+Bz7?FqDUWuhq(L
z<|Bm`moQuo>b?H;RDQjmZNH`(h9~?$iVrvo6`P<|64cjR`6?2<3UIezGh##twLht+
zY%!WXI9wkbZ@-k4!ePAx{3mEh?6Ow1B6uJcRyaLwG5UP`&pgPT%!Yl&2#jW`(qPWw
zZNVxcz9Y<+j_N@pC`N0PHLa)E_Mf`-Moyx7rS?V15L*(DxrIr^Ym2CqKkK#Ia&Uas
z+85^db#}Wo!ZQiYD)kGo743;pRSidf;LNO>gIk`KurjuASUZ-rq;w{^PVfZj__#9)
zy#j@_q3K}j<9Su@gI7gX%Y`k;qex?SZ9#Gl(=e8*1CE~Jz<`B5=J$A6SU3NuCy;?Y
zDj+)kc^i_=CnawhY4!95&3-T#^SO*(@uiZrZ*s<90;+1n?JIqMEV+FNOWQps3p+Sb
z?x9|l#xc`Bu5s#Kneh$s)Ku6xwriUHqr@hWAg+C4C$%H*FT1OhF9+8FpX~t=VPT1g
zbu7NmUzd-<3FGj?S=ksHv`L1GP3)mB_2rGAOEY-QZ+l0)&*}2`+QA@RKju8@;ce8`
z_Gi4^`q{j26ScX1mMeR^t6*#uc?y7GkHtoodSoqINu|2m@28Ghv%^yW3B8RzzjgBx
z4pxS&OTxbP36M-#+0N>2WE-G*oZXaB4d@dP@a&ADZq^qP1$%pC4lti9Jqe3DVWkgf
znx_<N{}F*0oP4Adj8fFC-7dQ6^(9yNgc4t<I%TfM_A_U!NyAfPbv%QNe{`btn}X!9
zt5hNi7~lU4$&z0-_$V@H1z>@<dzeD|RjsDCH6)xn$g@Ye?kzG!8)G^8;;JXg1Ddq8
zzo$nGPr<9<&zl_D2=aTkKiSm!s8HG>%afMw*uA5+nq|~l*0+V*#b7+|gRgoMW=Mv*
zQg-(#ZoPFJiE*;pb=0jn1mOY8SCM(AuDip|v>&;Doe5r-_57n{AQULF4o{cOZVh=7
z6+We>G|uZd)pS0jA{Ae8hK>zsK|F9yU4tleX%KL0I(4t1@;*TfY9HktfJutA@3&4{
z*aRcaN|KSIt}oi{%Bg2FSx3rmQ^#!77o9_CT^^)L7Hi6hNC6*T1-8LGK=Dm0w$=^y
zdsM+^u|%?LsFzMx>Aw^N3!^#&rzPC$tirJfkhXz*PH417OMXBa0~AZ05~wksMYp(h
zwHMyr&vUY<2di)p@ay4_KR_LHE}pu>J3bxpmn?g)>!)s03!Bc3O~tQQE7S{WpDher
z+ETio8t$d{1p5`HXG*v*Yj0gs(k<QRd)CiTPb8vq?#QMSqF=uvl2MaJ))O^uXM;XZ
zPSCjp-j?-I@AZui1dJSWu=Q6p6}sgdTRbtnu|BH#R`xUdA_HSczNo2-;gR-IBYXy5
z*-E_*K-%-{&SdP$ZyWFLca2U^|7H<aIh1Zj4H-&&;`#_f^{tpHl?J=uMZBhcx9}uS
zb=?Tt*1fQQJ_h^Nm%F~x_2aHzbp1EH1AsM*ToDOq@_MOJYL;3@?S^Eutdy%m#t`hl
z6c_B~de_t|*})xw0#25EghiWdkvN$y?~oO9x@u3m$;P=6B8m-Cjqbv6GhI!?hY%Vn
zY&v>{ox}w`6NTD}@EhW&zRbs$<pGB9SyMrT%oW&2JMzaY(i>>pkz*jqbXY6c8gc70
zg$W{CfXAJdB*-oi*~lqGQZm&LW=kqbL>_Q>Abmq|VTvUt3ntbeBC?Q+pc~}kB_bKY
zwOkgNIxG~I?hLV$FAyBu^er?&MoAqyg?-K(Hjxvt2~WOyBDK1|Z#Cy{d;Y-u)}k-y
zdf3<K>A5qc8IiY@-{<p1V@$;7{#tBpFqifIQ5mQEpPRLAyKG^&{o3!|amTg^aV9jN
zcCU{;M*rfW_kZy(AE!2M{6Nq4-r+B>X)0m>LHhEGXf8A|s8I35wlf+uqS|AzWU>@x
zg#P}CtRW?vtCiN@+312@C{qJcPiahai0S93Xkc#9vo@6~p1ONV8`YT~y`~{|XROg!
zXnPO2or{td0O`qY($_d_J@g0GE}of|*`7qAkYTk<H1^s{?LRuVexCk85RL+(*#3i6
z+NS!fBlHh9dMvKcITpJiF(-d)Q#Wfn1?3hC{R)y1OJ#3+9hXDaR%CIxTJGs-2x^nE
z3-&dX;<XG7`|X)rajAWsc7?K-lZ|E~k(z7Y-IG~`)ntKIejA|+=h^8E)cX{BLO^C{
z_l?fn0q5~(G@&TEBj}Nb&sSA%e^Y%IE7Rxet!=mL-}QB6$gr-peYkP)=bw7$TU1wk
zVgJSSCu5e-19bltk6yfuI&zG9+;SOBHL{s^g=uDfMdH;zjqEz;lxf}S00Miy(Cc6y
zQQ;mHP&J*V)4tFhA?mXBcik>mG{m<4?6qsY0Fu;%ZB{$|zP073x-H;4`L)RReY)f-
zm#3&ZU3=iHBy5HWAVj^-myGh(D$9OqF_k{+wcp8oeG_SCX{cJ|-u^&t;NYp_wV@Sk
z$dk35Ay6N;%q3`1m_BvA<<k{wT&r78ad6k-kp@IQ^^xS#Mr1#H>&77UOGPSVg>c|9
zIT*+kcWU}|``{{i-yc;yaMlrb{+HBFb%!+CTZzX4eZYu2-rmL?gWfQV4DA(A0%+s~
z_?D9|4vH!A>Y94NPL?hJ6m(=}@);1afR|k0j-7aatM4zF#?t!Ix&!*Q^_jhE2mbf%
z?|A45%0}6qcyRFU`(AnV!*{>uzQ4Wp;di(GE0tn)wO@PwyU`~u?SJb{&E1K<*n#qU
zuI(*<<Jpsx>)(I!lYejjuJ!aczwvbY<TKy;`sZ8EUUEq%XXv|yPjkOD{p>x+c$Mrb
zB4Xs5UEc>~`z7*joTLQcH3zVE+(%uA`!H<|5Xt#YoCLC0cXm2|8`TQTO3i;QL>`!q
z@w<+j22sNdnA$ypWdvt$5D0wr1P1}+wWA})+?aWmI_*gd)SC)6vQHKk0%!?@f1*hP
zEowj|*ioU@A&KMc&NP?Y7OZv1F@S48SRlO<fCn^P4sHCO<2-%L;9^i7cGeUa9m!lV
zOqm$B%S)AIYG#r|;=)`fD<!iKa1KPtTgFID4J6Tfn#3^#-LXluK#EECoeU6AQWA%A
zG$xN88_d}7$?j}CY-(7HBpbrT`D7~hAEM|)eu6(5h>dMsFff?#47|vA*w%={<#I5e
z8o@t`%XU{pE|7?w9}EQ-g;7?1%wkEWdkb&bHdzRa23k+HV{ypxUXO=rmAuXIn&!GS
z<yMNp%_A{REEu*7M=NlL9Z$lG-Nn;uQpT~-!I4IvedSzGolpP{zkxp7dORC_^zDU0
zJ=1>drUWywYGU_n+MDY^=4Q@U-u2p=6bK7*SvU|1p1flS|A18hk7qmgD^6B4rwlv<
zPX%DAab5Dbv{tyAv#Q|ce#X*%*5hWOB{^pGP~l-MnDYXr8~8Ls@_QU{!Qr?Kl2cG}
zF#o;2>7%$N7gxlLgYzCjtgt-<WBOK++OX}KZP%=#^VSP~GjO&{k5O~?bN3{Z`Swc!
zvKO{7d(_AJ`#tefeh=%RUoZ^))HHJTeYJP>7TzOFk4LXfmMbwoXN??{S;XF~XjC>x
z^VO8CeM9>j7K_~7Un;Ysf_G<nc*AGPYA`T9G#ZQ3k}zesd*oQaky--wPHleXqGK2B
zhtDl{_xttT7uyru+6KJ^V2;XrSNj7I=_kia<-S-MS+*Fc6!aSPU_6#Qg^WKTwjaZ3
z-=>iakgu~sFc@{nSR$<qI^gOk!~*mO!Yd`9^!odI&Yj*IvP{4e_S9{@c!Tp*CDD$o
z7FG%dT9R!08PzZ8))6ZMKh3emUfQ!s2~;WC!-i#NT+a_^5y>HKWxqp@b>FdxZPZ?E
z+m8KL&{g~D0b>8?f!uSm@G;(jXgCX^sUjwQsKLHD+I24l9WN+Dg31B~X8;NRR#1;o
zp8^ujbJX+HH|Q`Or}Oam8KftHiL;L02CttZ^hNZQ^xNrM>37lZryl~QJJBkA4|GLH
zyYb~fRRGHgl=}dFwh+V<e1mTDBL~D&(}gv*Sxb>W_})5afS^E~($Ofue9)l_rVP^2
z$rF|PX|hA8hDn4#MMy2_|BXsinM$3G$YeUFb#|BOSLYMu1>%qc;5So2)alUdl5}nU
zpN5=f3N+~4BwR##a(4_W#J)kO-@n#_K#-9@?_n$xHlm{<w+WhAMV^`pnH1bFegup+
zg<_&4S)Psb>50L#5!&*m&dDJGX2%;wC}C$rZ#3%ku{>~8<EBpE1tFRymW^q|A@{M|
zv*9v2gQXyV@+6Q+AS1&7DWO!S5J-dRLUT~A&M%>1BtD9eJu>^Jr@V87i$XeHeij|^
z*K9{dL*j7Ag$>*_9<h19%a5H*2hptof(hCn60k++FX0sE9_8dO;Vou4(KV7e0SM1>
z&2mdqS!6a{E?Cy%nWvI+GrtY~5_K6)MJJv8<$lcb3CC^-m<n=<<*S==EdMv>&Oac(
zscn_qel|AhNNK-aY8`4FTKe^e{&0jj?{^>k<u&f^I(O=OwwRKEah<t8Bn*c&?$l?H
z^eZ-_9S#*d%&%RXkcCh!Gf;7_jfb;EuRLtEIx=2|^=uGSVK_8f$wX6Xl2;tXsonZI
zM?CLEWQ?_HA*jE?-u6dpnaa+l(d%8q2(y>@95QXO*gc4uL7s_-?vwiGoi<l2KGNO0
zb=8!^rgX~-6FX9|c;#5wP-4CHfr-uiOEk0x6QjK=#u;atLX?M3u(W<XV^^IB<h~~;
z$+MitbMhO5skEPFjzUC^iwEsF&6mm1En%mV{(;Stba6_~TJ0{MKe5W%7;Kgs)0H)S
zaG|0&M<S9LtqhM;#sICJcTThVP^o(uN!K}txKo@G1^bv5<JGcS@2<}_XOQ!UD>_$B
z?WC5D9(~o_BduoXQ@>VRYh8Bc=3^}YKugq-ZH(Pb7o&lI<SDOa7kcRak$SUSj|F;S
zvm@cY>adq{ZAg|5)YL50I?Yw-odZk}QIbrI8a<k9JxEPT&N7m8q%%I%?ZIBxQ&+FK
zBTXlgHhs35YrnL%;>q?6^!06syAvBSR4o=PN5)!G=3T3<`fP^Vh7@Em5h3;MdymzG
zkr8X0x=-@}mqv}Ax_xyy9_^o@*Jl@I_2h=h))zD9ICF{hJ>wTwjTQZRvHbw+vj-y?
zS2uN4HS1sNjU3QdwsXF~G$mOb3y!4S?qcCTkF@o{7-MmknYG(0e^or8yia@1?sG(3
zlyTh=>Z<lt7heA1-@HJ7^LM9;qID!l|3Z&x5iX^iT06zX2k6V~Hlvg<X5H@1){|}f
zsGWBD8<!>{7COp!N25-@Ih*!4-2qoM8I8pQ9{*~%clXJBFgKU&bNd^!j=D3tbu%?l
zqD8gRq!`Y5y;@aexU5IVvRuLKSZkE~Gmf|;ZohfXwSuFg&TYElFU?dl9B_*0K(c?-
zxkIQqrEGqSTDApNO8!Xy+%82oMi^IUFzR-WX07F!P%4ov&*j*SO3)jL_Jx68&dC`I
zNBukz3(JCjYF&?N>66(3kG|c}`f*W!ibv9&-d}NsJ#94vdQD|p>wqt$3(!?j{oS$f
zCGd6fmlElExwpj2Wt9z>Ax+*$|3KKgtuok*+oCX=O^%IiTkX#TU4FNwjs$Wy9w^2S
zH%3NA{n8F&kW+l&N@MK&Slwc?iJa;VpSrWZavU*X6FQfo4+aW}oN;Qgc^N$)=)Ys)
zF8G@l27#TMZszmR@r%cU*37%)p=t%03d_Z$?VO&$Y=W+axJb27-D0QDtU8qQa|7Ec
zUY$v#3IIQ_pL%cekb}CHDY&~st>5s1H6j}_ciA;xSU=r<cBJ(&cg#;Mbvx@1`q_H>
zM{>}{ZW~|w%+-7Ar}nWind;7m%C7cWA*?b7^Ujghv&nFc`fyYje7P8F`l*!?t64Q8
z)OyLGO3{HhwMNQHfd^P*@X;9Y1QG&TWg-_4{M_$BhWjBM1&^PgH^Tpc2aPr5dN8vP
zZ8A>qo{k{fFv#kkh_^(*HR22bh$BTHnGRBF5PwuJ)$A~Uj>JrOxp_V^;}NdZIUOyC
z7;maj-ta*%9e<bG$3cS|gwMeR!5qLF%+(y-@+i#Cf~MI8eG^s#lfAjU;dR_mdYEFs
z=_=CD^kX%1e_{-sQwU?i1_pt?bi$h9i%yErbCZnsjkCzeP1Z<GBr%kv0MVXci{{qp
z4-94bxZyTi6K0B8AZM8E%tZ|Nzq#SI2x}tjs&n6+DZ;?bdQ!aH+Z$IVHD+^i0z8yR
zJy}ViywjUGJ*2;m%XH^Ckm=5w8QpMyE_bI88Z7*`yv8w4Gph(Me4`WcFd(4`$+}t8
znRU~b1T#q9flgDi++6c?1PqiqM6G%?(mmx9sc0}dVVwwX$#Z^A3uJ9@rEhGv3}>=J
zy%&&loXv9`6%Zoyu&yX#`;TxA7;&#;%C_)49r9O2D{o89S*;Vv=%8NL<5fN`Qi5zK
zhgZb~L)@sA<|p&TsfAdkJhzl(@7N3^|4=D0D|y$Cc~{ZY;2t(QRQ2>)@8x+b5;^%4
z1wMoVU-7D;h@Pb3otmo3K~V@pr`zkS01^$4&T7?zIt9=<i;*xIfsz_SnhZXgkH^=R
z*ah~&xj9$H*hs6xeSJaUOFd(&DXZFDa)@>>a<1h>gJy(4M6d;c&&L)E!?E}#HB%J@
zbuz}vy=MwL7PKSj)m(JSg9t{(dDKoN4Ojmq{noJPH(c~ZbLG&Gs@>r<VlGS6Qg&t<
zt9idaZL9)3N6LuI6j_?z?QYl_Za*a_fbkc~3htC8Zb_Vncr7UfC_jytb5d#NmPO7$
z<fgBO1%woG;B`Bqp{us<bQh%+jD<fUt=_=Po}{#*E=Gp~J!J?hj5P02eX?xl)nr2U
zB#<$^z6<6D*;%tEeY<@^y;5HBk5@zO3pYMp+^De?&Cnx^g*(sYDGCl5c>pr4#pu9h
zvG*)z(MCyPdbnJ2=ld_w7&QZ`L$u!)G{sCfr2A>!d7y{Wd*g{(wc*dN-LN`H8Co!?
z?Ww9^manxx*W>Znvg#o!LhbDi2Bq|*A8GjLWP}wnti<_CJBwN*q9!9{3rR)ib>;Mw
z&;aspRE#F0DOu{Nt1{SAqu>5F!4qhb_3Id|@05mW*^;37tE-_UvaGpJDJEd+90=__
zOV{W1t7}Wg6#vTg5}#)iLl^7m+<bHj04-6AeaaqAg~I`V$P&^TNHOP>M|$8(>(%3#
z*>iq=;9FY2$O=Bg)h$`HBDL`CZzK6&gzC$}!P+t+USWwL1PLciCc+DAY=U6KuDI4J
z2OSYajv|+xrti{Rez9DdkheWzM6x11s(ALs=`12BgX^PXaM$*`D8!8hY>1l%=simn
z0tr7W$%ybA-p*$-{er{wSG&b(HEcr>`w{@(HH`&|k8QTkr}6^Q+U!PVS)LR7QV9XZ
zIogJp6@*rw<MadiISoIY=}AU(p1G=~MD$Y4Cxiv}7>}qJhl^(9q$}IgGZ7B16nqFd
z7Nd2^=d!^X^G$C4OV?Hox~rDg-j$eJ{l47VD1D<)hBx&@pY2aK`_HIztjFUDvv;&#
zoW8jz(?PGt;-=2+;(*oCCraEnauyg}UaV5fU0wLnfB=YfWEvp0Jkr217Md(#2)zff
zBPn7}?~79ViPj6YI(?DqZ{5{;XNJCDr1g#V6ZAO%BsoGCS}&iZ)l>gC*?O7MIAgZA
zZ+^b7Id}3;^L>3QSN8SIGxxTA)ZLDmQ@fDT@A^|0hnV+oflK$VsQX&KrQPjS)S2z8
z+m}+;L#KJ7y^lKHx3JLHH@DCvfBR?Wpe0<>zJ~ueufmVx2IRbbsOxiG-|G4iyf{w5
zdm~3}qkd1lMsu_qtLj;L4ZRco8As`R=nrEJ{crRa>2K0MpnpRDn&fIQ7q)R?<p%>`
zO$KNNkhnU`*j(e1834%#0XOP|XSk}VCitS=3B8qhXhLi)>&ifd8$gQ&+ty703ZZJo
z;DF^4NOCX|Bn(~FUYaW)SBIS>$%+d6gb;U9Le)Fs0c_`B0w@^<2$RWgOa}_H0H$;}
zd4QP^y8_`!q+{atfnLCjNXQqS8S3psjYpJYgj*4FM5i^lka<^e<RgJwojCxvkcQ^9
z0X~;Zo4uQ|0?z0-BBaV4^&5tY=^*Px0*h-7yGgq3j1?>$`_Rjo-9u?f*0D`ACk(%d
z=BF3DkTuLjFBa_P=rGphzi3C&2AE8<^AOUcCF#RFgY*H8j_WkQhRHACnjOw<#@3lE
z+MGK;QJCrhCz%T}5;P4_9d~eY7JLhFQOp~#emk{bzGQ_BFB0;=$cV@<#%j(dmd8Xj
zOOzMp>E;-ay|!}-UMcw3V5Uj!>B98s{!*yK^1T94hxCB^ed9gD7$NwWqa$|+yVdeZ
zr#mqrbaAV2N<lmFw8&$2*YU{7Lm~@$6X}<fqGQaBn?y&EmxKQ}ryLH+2J!+7mfL$i
za^+|KROVcR(!NMzP^7mZbb6;^WZ|CdTJKVO0hZviMz~057eoo5(ps}UP3MSz*s1Vy
zmfcB9lyZ6e)c28%#+}o)gnX{hP<wqWRmvizqSF`LV2|ilt^KEK5=lUp(yjwhTQ6l%
zyRFS)QSAmQA)pb;?UN-<ujfXy$#}O%DN<~-6gK=>E~1IR$Bwi|UH(L#<@TIARi|_<
z5UvjaKRegGs`OgH?ku|-O5I-e+X@`@v=lt(Dk$UCj3BWN-s+6^^vYB8Sw8I<qc|6C
zpJK;t<xJQEVIrj3sms#=ptU75)hY@$#hT#!{vtyO>OfM}9CoYSB}5Bug)Zi{N0y3K
zX$EOc6*WAV>_?b-R<Et{k6y)6!+eNJQS5#|2Sk!yB;`qj-~vMB9qDRyK?<$Xi=hFl
z+*hmmGSOhb*`1wfEUg@L%-U_<ROuE!6>^V-dTmLXjl}GsfjWHY!rcS*(kLAl>?`bz
z_NV8(4$W>2>TW}9|7Ec-Y3R20Nu5J5jT&-!ya9)mekBnNr?QCIkHv%)f<yCd=Ni;B
zHMkBc*mOE$%kJS7<V6GPl(vRbiD>&J;MyWWDv^loiN&LdeF+$;&I8UaryX(%OMTpC
z&1bPMvb-LTOO6>kZFeyJPA%;``gkfFO}sUnN`;wcGqjdutIk;-a09A@)Z{C|lMXGP
z^0p2DTEs5p-BY%BcZUDwWO6j&n%ZTR+&$D*r`s1nN=`b&Ik!?CpO25IGfu<j7j}xg
znqJ{!R`3X3+R6#kUn%#UQ@og%?k|*`-J^*!ghA`AMq5@EqZW3h7>$mKtj)5`;*10(
zZ<Rf-+8m<AMk!wIu4-Z~@%%qli1zMtMPa4jZ7)26L}`BQnK%z8h29es6Xk^Bsi@a2
z10dmpH~9dK`vsMfbPwH|E%(ux%dR}5^#f|X-L2Z#Wc#C5>X9HPcptDg6(Kg+-eA+_
z!^1AC(sv%0yH2&aHqvvdeZM4q`wIc@O-RD(b+<3}8+PCnAZu|(vonlCjfr7Vv`98D
zV{k&i>GTDnT!8&hVa}hfS$L<YBSAne%LWPoTQ~Ce78*`Ljf~bEA=aH21*E9=y1h&s
zE-zly777S<z2<Vo?XtzzuLo$Z+ZM_N*u7I>q!G3B*-Oc_IktOyKh<38$RQgLl{5UI
z$qB~kWo6}Rp1rq{3<pCYU&xpF?wakFWaHl7TgDJ{rA7kDY}kMDt)WQZo2*qvvMb6F
zw}$MLvlcGUIpB|kv;M?|RG^?TmiL4L!CN>9F2SMDrGZdrC=?3WD2JOxFtDYd0}n9l
zh;tSI_aogrm+{yD{4p2~5BF6Af#CVL#Pe**x(+BIBIB~Bs?WJ~Khn%nLdD@ubL*+B
z!j?bf*WDz|eU~3{N<i%5z5y<O58?@)0+;_)*YDvypaF-p7gn|zYLVIie!qu0)AZH6
zl{!Iv2<W7bQJ<xrHTk>ATH?GrS|^_4ZwllDiA<S`*VCl<^s>_QIwv8ZAgXX6By`_R
z)|`auf<=&WLb=V;2rnV^9iD`C07UOZAb>cd5W3h-J)zC!lGo($u;{}DpYTU87O-!y
zXOq=+RORLsT_(c?B)y3()L}o!3`Ke|H*oT0MrhcR@F{>FJj&ycTL_OduR_>7;yIy7
zAOpb_&EQTqM&4MqnGuiq(=3j-TH*`>xDH9e<o)KI6EVV|P)WF}J58j6B#d-S1G^~0
zx)w#a2)qqUzdn<pL46IhD}vJ=tss7o%%ItA+!UYyGX}W@m`{W;y9ug(y_z(uO2~E|
zM+Hd>zg!`9g*Nha%6NvQ+S`80No$4Hmy<}bM<J6c?Nt<w+jgSb<8+3!QmtR}7i}9|
ztYmjNJsU>m>yQD}o#IBhXki1nV74@7-y4pH0Yc(0@)cHDaP+IO3B>a;Tt6bx*;Kgo
z4_nbGPi%2JdPC0D=~UpB=s06>xq!SF6gBFaT&~`$$N2jIESlWYp0y0KIZE<+1DcV^
zQ@0m#veg6jNjuj&faT(_(ZbM?Q%{5Q)@c<!TuH+^5Y7t1kzHlBTjK4>Y{QXUeH~y!
zM*I~$XOB|x9uc6zf-Jlxw8No#j#?M9RO`?1#P)=t)^b<qQu$r&-`S7EyPcBw^-o(I
z?={+Afj#Ny-cpY-#2kmuxi5NPeIOuebX`#nCM;TP^1(&qt^DaGhI)Z%Ki>YJ=(P<E
z4z32e(zi#jPNlunp@fTL5$DZ0xuFyz`&YJ(k(%J)5tL$Q2${zHD@Tek)n3=E0hbm`
zh+dGV1T*CIhTQT%ZOsX-udew9N<WN`t=X(mjGl<9fN<Wp&>9#WD90~zDdz#xCw)#R
z8}ZO|XmbAC9hcmkmcWIITfVe=U|7s3^yq4S+*`?o;9Cw&J+jR_HF6Q3jWWMD+?(K-
zsBiD_vM&}3w|^Vx_w?9oI`eC#EuD4nvN=~iY8z1B5gsdU{v!45n}yv$8W>BW?r?h~
zPr9{<stO18xO|P;;`jtJaCf&?ujGC0a$m-J=_i>}8?uVW>DxTgT)$SNV_$b>8UJY9
zI&4+rxrD^0W`<R#u{3CnITIFxWGWe(J0p~srr51nnjLiPdcsTP7|B=5t=rPNlnOtv
z-%6i<b}N<2P4s<pm%I1@-!F3~((MP=y%fk~W2Mhv;qE{CbJdDZT#cN6?VVJwR&)0}
z{<)8|pLDpWr~W-qb7e-y)>k?D*%-h;Y;b9}NzBLK(3i(C0-fQ;LXJQmqgV&sCg!*=
zcfG6YLtT#`FW2Yc%?=!au0Mi8ejNzSf1$hR0$ry2pmkgXlE7j5Lf8`Tqd!i6j{Y)p
z7IPVMD|0{dIP(;2ibTdWKYNo<L4w6ceHyQVe7x8Q3Z6;N2($_zFW3-*Qxi&r!kE!^
zZ|=n;c*I)O=?vY)O;k;g4?={NW!;)-Y9oCiK+la#J=i6E0%?L!Ler@40ww?&fLIbr
zLTD7KU4*9LFGw{glWDcW5n2+jcLYOq4$y{BEz-7$zh(nOgA(Ekc{^1v;TLyG$RHu8
zAp9m-f-e=~<4M8kTO&8Id=6OzkvqVdr`v!`o79vvA|0Bwo#j%80(W|Ub7x4xW4cY4
zGif?C#Buya&w$9mfw?j@2Vp*t)8wDf-p+!OtVPIEiJJ_o^H6XvXt4Z%u$CmQ;KZg^
zbJx(;B>AX>mzg<vWM;5+Sd{t9mYEjj9HTMqjphyE3OJW^%f(}5ED6bM!I(!@F=TcO
zm=Y`G%4Qof>&x>FKmLxZIKg(nweWyYV7PHr!n>BIlH3~}L%qW|Yv3(Jd29~L<Y$D7
zkfYP)OEkx3J^<XKlXTPMaI-yB9Pgt!-{vzVLnE_<Y3TeeUk~9D<Z<9;@yDEE7;Bf+
zz~(tk^Q9wCld#m~0J%51A?sT5@^sz+a6jDco1T%`Bkl&5G(Q?sHQae5otq#SsHWh6
zt6)uMUZV4K%*zsHO}gvI866`n`SwgVKTKZ7!BC)4FNnFh%Y*yRGTNc?fPVPlv6EvG
zcjTo@-XStt(2<0pYuH!gBbEbE(c!HQCF2*ZzH}<vok}4q$<&jZ^P6@hXZvO@fKzj7
zekOfsLSL{`Ydw;oYT;i5G)K3G7UH7eQ4kwT@A*b{aeORHzs8lQJ5O9PFtT5^s>N7$
zPyfQauNSdrzN>XwJZ}iGIZo{iP7Y=_vzZY-7%GX9ng>+8$Z|Pk6tVIX){2*AYn-)5
z<M+TG=Bl6PDu%DK<+t+yIdb>5J+ezzsqP@wP#oh+B#;x=;{%p6wXTo^#&yDH%LN41
zW|e*ETu9ljd7=@K>a}w@%2i7zqT&E!PXH5v-rjBVhZP>l_JC|34@44)vkZ1kqHK5A
zYYPIk*uA57Q<xEYdMXjg9_V*wD?BC2%C@a%FCETAg&l~R8@;Q%e!tt|PcNhvY+|I~
zDpq)=)$5R_4fixX?pw5IJst!G#_7*49Ajhw(9Lnh$F+WE_0=4y!qKI>sNS^C2%Wz(
zz7(v5hF3N+sXg=cRdmcA3AF!2b3CKG6MiPvGkw73(ki+jo`8ejIN!%oS|Ayk5aTPI
znM@@IpCL|1PJw17V)v|bqy%r>+WVX^Ik~D0pgBjL5*?~nv<97W)PqHtK?NNisI37%
za1#}@6?0|gg0Q#3JFV(GyQ%dBudKFDAs=?Q>hu7{CovQeSyzrmc8w^VO*olVfG5->
z2W4lxX}}c9UiVPMYq>-iL@H;iT5x2CSjBIJrW+ozvQ0^^lI9aDvpy_+mU8`JpU)og
z2FF;dr+ewn`JiCS1lR}mOu0mdz4e+u6dO;4>S2$u)g7Il%&J}kxQu!_=;X7Ecx$73
zb-!a$ix;ht0G;}Tb-K8-T-o1F*Q^MV66DaffVIW^;c!g}1XV<c4O81b-MV^e2M`WL
z<X>Tdj}44Njij#zm>y#H($OfgdzE@pA2DKZARP(?!bVO(K5n2A(D7tI*P~x;ZRBtN
z$6@|%Cd6nNA<xQ=Scx9}?=AO-95UXYd51pj5xB<4#Q=>+=Bab4Q1jZ9x=yEu89!jX
zxC*Z{k!=qNIk}wV7Y#81z*~yugFz)?kJ7xD1_F^?D`rx7OjS0~&p2Eb*Tc4i6B4L9
z%#@8VFzIuekV*QyaV2iy-}9BHScf<1N@chdFU6!ll7@$RT*1=Rqq~vtCgIG;D=69D
zw1lEOfH@^@NXc0MONejQY0C;3XIf=MSz=Zg1<je^#gvSkXvJ}!rv%B1%pS4K3~ia#
zRIf!1A%mYJDHVT0mA8y!*7lz5VFU#2*A)NidpXPcr|c`8g~2h_3mi>EF3PZP^1q4X
zXg&gnN56uw%}oMQ$IQFsptrK3-xafJd{671su6M1fS|VnVm+uc7C{pI^z8>CKL7sp
z@kYTpm8teL=eO<YQ<P-n;?{(m7OdG70zBG$imuZ@)rVb$#iCda^8t?sNv;iw54mVp
zUUR}LL+l@PNugl;c}=pYis+34<q)^raOG4gYvt3tTIaa19RhLaGw1Ou-@R()HXmkc
zmUi)+yOKKfEhA40l*n(NwIdDEZmYa2H~Qql&rZ!f!K`^8+U?VlUQT1Yu}~f$o=AC}
z;%TVS1sE9k8qcL!C_ah+q(P{>lU9A0T)WG*ilbQBCOUK;K>t`9OJX!eTWtYJLf$BZ
zXwaOF$VO>2P;dt}Hq(V@ZWB#p=E}^9>Fiogx#xFz=e*5gWJOlsST!tiFy0?bl^Xp)
zz--R=n+2_A2ZCtS>-2K=E5e0UQfg=2H|iE>thqmV&QO^C%*Q$Xr1CjVrAED!KIiUx
z1YWCa+E=qF?oYtmxCLJMU+wyC*UMeMBYvu2Z_8Ue%>&FAjLHFSgLNXfAGQX9$2$Dh
z{3U#;!*Idgh&<*Z5(HRLy=uUuW6Fr;FI<_(>88z-#0ugf1aq&$$iVGzq0TQkpKwRQ
zq7g%PdV6zU?#?j56wO8IFkL627U9QejfFXS1wcE|yrL&8B%z}gFeC?T)#=lM4x0kN
zvsdBO=+qg%1%xImAW&($>*4liv%XR$faC>LppnvCxpGEEar3@lIL;}mQMAQn&Oh}$
zF9$sQ@TI9lq^}3)EuKu;nPfy^t){qh)Mab?j{GW>Dd@?)rs4;BnSdZAq@`Ig;n%g?
z3RYr;Lwb}~B;;m2xBekTL)?mij8=}=Ix786)l+j#8m{fg_G1Ynkc1Z)r*4guT&-X2
zNf(cWV|NC^Ksb`eSmOchY^&fErv#Sy?D<uDB+k=}9*I*F^HWN0|N6f459S6JsGX~q
zzVbG!YB#N0d*STuwKxJ9m9Gu%VB;H7V>vd<QTB$y#I54?1Mu^dfgzi(^xLCrCO2*I
z_rakONM|gddyO^icHidR1}nN@zyt&@X#E(HAE+m<Mve-nlyO(T|8ikf!I4bO8U=rK
z@lN)&_ZDfO<pb4H^Dy>FJ7cRLb5u$fVqxADnri$gy&)FbF}n4AkFI2?KDj{+AF*g+
zzF(+XNIn7No@w79e3571J)t9hx7hUxWu?4`sw*HmcL?5-i_}&`=pLmmq25M3BJs@e
zl%Y%@k`#HF@UnH3A&qKBFzb{<*W#k04fq{&wvJ_<yfIb0=BB7tMHg`ZLgOG!URAta
zM8I8cW9~!BH|1^A5z(3`_0uWxcK>seAs;$%5u)igH?wcEFEm04j+^8?e`7yhA*Xk0
za9w;3xYj>A#2#L1Scr5)4U^>-8URZF^!CqNLeE^yG|u4ba$^sTaWNuenwB9_WS&l3
z0RN@xjT)lkG0($A{#i)yw#^e^T#5rh+g`0ljZU^e^P_Vye>yfJF%6)x(zHYm-ya&;
zm6a&3EJj4(y31D}_>YlYm3-2k2=@S~nSJ&jJ5#%mOrzu-LL%g?0oH8`^4cOB3Wlt;
zeU21cf45}U#Xg>%v~7qo+w@|oYVFl_+AiJ9dB*ayP_?q5xi#V?q5?Ep@iuiufnUKK
zNGwg)`RroGm107`5%X0kAg9WjSCJjTT;KZ5zNWi(#Zo}`YmW59-l2`mM9o)!pnlGp
zYIZ$8wT;^~T(5_wcJ4faOl=l{Vm<p7q5gNo=TZap3c}5x;b~sX{btw4F1u*qq^-8y
z$QM_KVhzAm8%Wf_);+^e!!r-AnlD5m-FxSv-3tr*i;;zeNOAAnYV5R+%&qPe&96d9
zcQjmRf4?UjDRoCz@97+WweyD#9)IYg$KOe<+ft6lOXXOi#Ga)mI1TxSo9;|$U5xiN
z2H?o8A%cZ{?Zk`J1CIH=^QUi^cpDvu5Y0pj5vMq+1+Jl-x+2)=sd79?`$pmsgZD)v
zti^%Syh?`^Hi{Uu!DAb<8^oKoe%jxDo_fq82y^QXY<#$Td!;huPrEgnFXgi!A*t@H
z&_f!{HA5v|fUes7Zg;eQ7^pJ>6=gJyvlg2hkH6#a*4MS3l-urWHH4!(F2C&l=^Li+
zsvX$#)vY(bY`KB5Z+v*-TIEo6hi__rKGM^3^QuC0VQ-|kuuwdXnd+t<UbSl8Jl?yo
z5H0q+5biEUqJ_>u*eq&YP8aUDqxHRuFQ#1aaycHWRk}pbja|H-uXU~MI^1<VxZGFZ
zbKOG?ceq^L-dU!ZA5CYq22}tyR4jj{_%KPrdGgKT-6!yeSW6Ptv|NHOldLXLhdri7
z5co}_D?UwA&1o*Ms|^y2g^!oSV43P(vo~_4n^gUe58JR4Y+7(oK>7g<=M8`wzD`!C
zI*YUyzyvg#;MWWaIsM(^dn9f6cnkv}_ktxm(N>>UXOokbNyKT+`$j}ZhYg$g=}vb}
zOrOXkWx#sL5hV(a@M&Wu?B@NPC1H;olFkO|IU=%dI{c$++9!SffE02Pw6A()b&#Wq
zbTSk4F79!2VV;Go%WILMe#bP#a$xhpXp@(@yR@jPDwAQ&8;@ibm9*EBw1nmMq5NIW
zTvliJw;-dgp~?`b7-)H4O=l1mZ9}*(0xyB-t$OT-HaWtUpP%}qPQ_|~zjn$21xWK>
zrn+|pA=c{l@C0)X<BJ3pAh)MID$g^tjhlGrh4yYe9){G*+59yvBkSEMYhBjsU~g*G
zx1w5C7w-1es{5_s+=e|aA;?G70DLCeS0rJ^QR{`)e*z>KxP~bk<yRtXD(Nq?C!f*#
zq1{Dx&vAz%toR%bmw$DR{u1-$%&LLh(SuP%jAi$n2_H{(tL4KM8%;&WZ_e0r)=)k@
zy`HxP;9uEQ%cTU0vmD%=WQ5Vn8yBVap6_^XX7A2mMH(KOE>kw&yAwLo`_o{9i$x;M
zQmyJp2L9`Df9rNB;ty7`>~1NsuRv{|7z{N0w+>4mhr4m>?@=T$ddVJ$sDC}{i?;}M
z<gLuaL$3V7d%yIfeag^ZuySL3KqJplvSW>X%zlHElKysRSA1&V;_g+FN2$AR_BWqy
zzvt<Pr*A0R;r=6vtR~2`%2}ieeW~Tiqdy8>Se;|yq1TS3g#?|nF%qx~GrWiRmvn6x
zKEhVIoL#xDYS&=bO8A#hN#buWAkheUshWDap0t=s6Y?gb#QX}O!AZjOk?QcJPGBRx
zD$}tXXqmv0fXeS9r-oY}M$!P$iNufAAZ7av^FHSB_5#pqOUe1?Z_558X^$UGQD35d
zn{5|u<-(lfEzH{U_Uz`k@1OKC=QFJ2ViGGT`VZ|Fe&70s2HaM|!k28+U$4@B*#1d-
zoohnj3}<3-*wFmzR|lVd?A9Bo%YnZc_j+gpgp`9hx*Gt)79~UgU8$}`#C<#pJ*?lP
zGF{7Ax6O~S^WD2mFgxMV54G<+^)1Il<I=mw_Fj7JFHT%@Jas44{Kd7GGN1bD&)Q=9
zk{#Rbz3!~Hee~=PfAlxUPt2~pfl8e?j!Phi^1k+Q;U4aFWP6$JItb+0cS76ya@SuG
z-sYylR2Em}1t9Db$~AyxCpf;Iibn)ffrJn=%za0lWYQ-PI5Nc@E$*_0>$G+k^bYe+
zBn^^t1ACx@9o$gTH=%n7u^`&v<@+<QM*8nufl#1khhVx)t5yQXr~B^6QihX5P}#EN
zzASVRk4JQCI#mz?h#r>5wR{I4R<+aDAXhNQ?n=5kV=>2NdZ=Q+4)a`>E_89}1m*4$
zFkA;^lEHKrD4lRmxpebKuRCjhihW|_>Q7Ws?O)8Zmz;6#8U8@D+$d(pdtG!~_dyDA
z+5+LS)x&q&5NFD>tuHIoHRWP$-$WW-WTD1|eWkG#BjeTbAoZBwwCzf#ve6?CR<+^L
zk4BRN&di15)_PNW$AOXlF*#2iPxn@;?QglolB7(I*m6>}vfztTp4cQsO-}DN3L{j#
ze`h(}YK@f#E-HmwNlsVoJ?A${g`=9*+ua<Wn28i-{iC}#m$G4Pw0Csh4GuU?tsc7j
zLyhXqhcDi6W^B{qf!V1?Z=Lzt<@@ONL+yJcSVu?R+5XUNk`Vd`HE+G)2Twoar)Emu
zxt{ya)YkT^=S0Rvt`C){Zsj>2wSTPMI@Ii&oF468Y=#UAUGYR~{pC!en(ao|cz+`k
zpnjs|_Xi@~)v$+2)mQ7j(nu+9_*-x;5d}#fJO9?IHGlRs)Pc#7X{WGGU$arPIOgN&
zzTT711RSci`GI^`iZ-f_ax|0f@4a$KM1l<Vth3Jz3Kk{a_l|R^pI80P)%7?7cfM>S
zcratHgnZ@N&Fsuu0u$52+ly;@W5HSFM}rHmt&KHH14mt3O9fZ^XZ66PLhC}I{fWzZ
zE~CbewYR@+M~L~Y+50~K!4G68d;T*Y>SF0Nua9u=<Q_wWx(|pzD+mr9ULTXg0d&p_
zfNmRPY`ACvm<RZ{1W<>(SPh-Tj|=I}=0?I7vNheE4Rzc*|MKu7e}32H1?oGD<A=qo
z?rneR8~+`OJ+CpjQn`@J|6$YM0r#1<4ZY0`)`NjV<2!bYpY1=>w!XKy(SE>l=Fm?c
z{>z^qdFzYC%4~&-P*=3CY5zxlx|aJ7>OT5->zq78O~+(Qygk;t0nHB#ZP_+*7Ea&T
zY;3e1^dB1Awq@j?XTM`T=mbsu;dPq(JokC{_95ME5)OR~`3mbbd=!urO#Ehi_zmv!
z*SBwKf9fU*aUO$zf6pa%e|P5>ZoG?no!;BJm-5oXOYeC1!abDm?n_>7-%fAc8oFlR
z$a`KVF|fD4{<3ft_heTCbbS=L!sffyb#3a}(X|J8rw$=!*d<+80oD4>uJ^!V|0rzm
zQF|2f4pNZkfjwHU*2yqT*~#c6s4d0cRMWxd0sb1Y<J#i}gY^Z@GWYTK|FUnE{vY*m
z^Be|#TU9eAzFITQ-XJK@*4G3OA9NNs$g~hD^e=_NRsXn=5xW}?Jsoa*;(-S~;T!mg
z^^?t^b@}YupF+v~_kY4WKz+*fmdRE0oxXkP_qSfA?=AJGPyYH&_8s`!uJ5KTrQPPA
zv(l}~UCbCt<E5PsRv5N&euZW$*C{+x<|Rg(6h~*UUjgEoby6IQFvreL78do-*h^kY
z%oacJ-2Igv%cAqsj<ScA`^L^{fB)16=&|<Wf2Tin<Vb7w@6;UjIqmrI*Z$nuXDp%6
zsaLSydb+b~wr2i(+ij<`P7AY+x+E~&QwvNto*T~5$gRS0Q2X}urgtt{({Cy%HAxAc
zIlbrgm$~<IpXi#z)Bbwb3tcaE{j}>hU4MqZB~LlvbD5-S=9+vxR^%6$Jg{R>5gK?B
zCSL%>Cj5e!D@;<oY@jhkX(GR#-Z9NK<^j`jv#aWOK!}pYIynsi+59C3z^?C9m`~6U
z(kSROA^ITm1at$Z57J}2^LzRLtPS6;@c;Ec*h_~wGI&!u>s~Na2*-p$rHMdIv`}ty
zhltq!+%r&zS`-rL27|;)2Isv0^Au!NHI-G%E&fNRr1yVqKvw^6J^_J>Z$9MSKQp|2
zOt<r;B}*U{syKZ&Mw}n~_Zy!8I2awZ_(h+^iv$joS8`iwuiRhKo$~Y#lb2hr<E@uK
z=GHD|;W$M*F5=Es?FZ$vEy@S^6B6yalY0-))YRkL3D-R0*Ah{O+Dr#kv04bIecxt-
zoL>ovVFg*0CAfdf$a1D6goKh4vua+*C|2d-wQCP<I?xJiapT|3iF_h|{H>wH*}|dG
z>-AfW#C~yi)^(fnol4}8us`a$S-Q~a-O26tIjEo1W4+dpt^M@1cJCSd-pr+=H|n7?
zg*{R0@t@4P9gBuH{N&Y9*M-9QmA88?jEmO@=k#2+b;)U62^`a{sf^RQLUG1-t#IfQ
zk|RPlHjXykM^k!^p>`(IJ%dI05@$V1zu0*DAn<p~vh0sqbv22lNmB3#Mb7Ec0eQ#L
z5xYwaF_Bs;c%I({Rl@${!I;G_JKU0AlDrl;bXgpN7cScl4q!Gx4nffxPpM%`fb%Fp
z#V)u+QB*_XDo)V>l|%s;q6pAG*r`O#?I_kR^7tJgSIHSQdiAJYb;X?xchp_?BwW=%
zG%y+rg^{(+snv(tt`}c?G#CsrS9UkMf2>N%lris;E)aQX!oE@#r1LdKn)J*{g0dl?
zisHCy!NRwL>Ftg)6Ub78ObH4vPJ0%tmP0l{TIrvWIY;|_{)>6bg|a0fs-LzhmU-Wj
zL)&Y&vs(fi4CmLpw@A`eHbgjBR(MAzMB!4hFAcdb7rD3Ci9L<PHvOV~J$pG{N4&Ei
zxg(Je1Ft>&tVj-WtfWEg!E$hn9OXFbWYw&jxibY2clPp9tR=@vr5OFUSg8_e$&m>C
zx5$rgIdtO0p<6QTPqbemm4b!*zWRz_i9}v~CBiP9`aY9?fSPar+xq@~_^`iu40*(1
zk918yN}lUl4K2V%WJEjwbm@zbk>g4ek>;MR5B~p*(kY|~_b0+Ls1=a=>QO9S{<SO(
zn-{R&kP^@2CL}c;IqsO+1tRde%({On(#&LY0_cew?MxJF-fSnlsR<*H&~4rP{ePL9
zYnC?p4(|-@T=~dlmpyWB`v&Twb62m69NM1TzJin-LrCFy;*7A?8nV8)^kT>gXXj~g
zW-qg0aA*T1ZRo8n{k322|MhrJX?(oYGv5B)N@1mSai=gXQg45w(M8hfdiRoOTccUb
z-~a2=;NEiKrj<)urZ${?*&~m%UfJ7v;@F0bd-lw)J&a@KNqJZfTI1Ho_*wq5Hrtoy
zgxU7XDQo(=!KDpDjfv6iy-M$kJrm=l()h#+F>7qC%{F08SzB_a{>#f%%(qu)@=EE{
zrRE<zzOG99V(t;%2`?BEO_;1mmYItk=-Y%;{<9#-J@U3oPi*cRx%!fu{vXcX1741*
z>;t}M>dwyW&TO0Qz3**%@7}w&_uP_l({6fC2<fCJKoSxX5=tma6Qo5@1f{*8qM%6e
zRf-i66!k^@P*B10`l>G^+41|I*?VJn+wc2*+3ek!bIzPOQ_k}|=PCbZf4P!AZ-<?J
z+szj&D-;)9y>V?L$A0t7?(=qk`!-#BedJu!!TTd!|JQTzQ|CH%>3Qceci8Fe=XGxT
z=9xq1?VdHy<*E5O<f}Bl2&gDxjf`34s_|lGMS+t}XICTE(``T$IR6c=ky!JMqHooC
zUj$F3&)Yq}YHIs`X(Fc2bQ+g&FWO>VQE~`>jJ@Y=b;p?HMy2w52$pTJ?ilL2V`%k%
zY%xBx{~g*Nq^<Tu(f%O*{Bw)-pM8<(W!u*_<{FLJjkzLuU~;PwTlvN>BRKbV<H&Xt
z(wZV|V{SDX<Hh{s*16+;Lyj7^8JFK#ZId^9JnuN<ysi7k3Gp@liJIlW1KkYTa9Pb&
zHP-?W^k#Tc-C1)A-c(pkLr5^u5hs7a(#_TI|N4_9I`r)jO6V^H0=j<wpML-nhIO^s
z;Gg>W|8WZ~k?7HdTStG--xgmhsFjgGeYQ=lj0PG)eyAs);&vf9k=GSdY;IRvwz~>$
z=9y?N(d%Zu7R?7j(2dD(K#M4LuR8%>K_|9GjDN3eBdYOE+#bRIE_|c*SWnU(#{d3=
zJsh(~msi{HFHiq)`YB`hL-MsBjej`aJhk`L*RaPS^Laow3YpeSz-tt;j<}?y#k5V!
zNXWSetSy_C5JKTxFhbsJC@0{D|C4%G$f+e{WWI|l31lpk(wdf3Hjo>QA!7$|rF^ix
zPEY#mN#C5T&z|+oNu$KKm)wN<?OaVW+0|rB7_Y<ix3;phh3smne6xw{Y&PbfUq*E&
z^NlOSKM0|kF9EOqUHAvTMt()!fo~kLn=>&cOSyq5wN1w8nBeu3sbr{dmw`?JYmCVs
zI{m3MN2OHyOZO+^IzfO;KVf=M^{{F+wFE({O6e0VH-AlyGF@C!jY`#Pm<q+n3+whG
z`w}2>@OLWa70je*GRQ?o#wP@!Qu#F9nxy`2RTn9&W2u!2VKL?w9iS<cnoC&vMpCOO
z6vL)5mil#>&FMkatC+kFb45h?UMu>kE{~{-Z}o$zfYVN0_oS~Dtpm^xt*MI4NM1un
z(%i^YPhr~1Fg2*JAVht$kE%kwdKp;sd9Vh=glIt*Q+J3?CVG3Sx6GvF<`rPz_|R1a
zeFC&QG^;kI`}E;>uwQmz6!1nvpEy^BTJj)})3KTwb92>?TY~9I4@XV1wG9^LYAt2_
zfXtW__mS)mw-{$Ei+@<=E;ssY{?)Z7g>0^zu{no>eyb<Hg>~N3Y?FeXM!3j+(;o5U
zkHkY^m&@nc+#s*msYZBlzP37?;w%EZsiHo?Dh7SF=}4^??z1hbUzY4{N!q>ec}Ui!
z-2~C=(4`bYZY35gHLK+kr}QL-+REdRU>w}N&Xdp7AwQf5r2c_ob7gPjeyz`lx;2f&
zxP};vZO9ZSO9{!9k3?)CzCM?ey;e~M0?>{3#6ouNp}8H-oXB)~!V#^Hv#F9R=b96&
z&t!V<_Gz9q&LmJYl645%-1dpO*`i<%g=G&?tT7tPGO%d3ZHaNSddkj_d%Cw!vJW>v
zUM4P^s~tI9IESpQbkB2-wg-{Sk+ZE_=H0g3+c?di>0c~5;{`b^UuXpgkIN4Ie;7(>
zM3!2^a){YkYE)#q&Y$u`KD?J8|Du?blgSK{X)+v-rH(ae75()-o)c4UAviCH)Lxx-
zTPQ|8pW_kBID->rj&$p4z0=+RhwV`9naA6LqcZdBjN*t-vz+;}4`^?QNSGr78>o)F
z^yNXj?nF8}*HDwLB!RyvZj~(c1;v$HJKq=~j}WV|f_$D$*gU+gw>#>xtAM2T3ELY4
zyWQ1tQ9-FwE}MzS>c<X^!#l)nBlEnD0lu@8O<S<UaQlMsuz>I<cT&sL71@$tPp#Qr
zvM2Wh8e;7Hvv)8t_W0S`7^md%`x0)=qGswcgz<Oxf8N=rG7q}bp-`d3$v$3zo3+JW
z=l8hlTSRSST+wW2Z|~aVW|2nLhqQunO!qHq18Ao`z;feG$AIQ;vlUlaNX)V>-I3N}
z4FhTx?!v^DwIS1wL-7Wr{<ZVw?YDZDd2?QWyIY&jCW74o<Oh!P_D(B+>IONfAT7+>
zMIj>~3RRY4c7LRGj6;?qOYl;KuSbMe!r~4AXiDU~E<e%bKE%D)gK23zU1m1<>O@t&
z!e)2)kdhSnUM!45)damjY(itavTKW*AFtPDMWjCgb5kH!x+QyehsF&H&S@GS^xWj<
z6i*#{!dh~UuxAfQt8_eirmng60t8_HDg%**_niH;h$KlsibL$`eB)}QcTLy)0s07v
z;jO@8mmy7Ne8@cHQ(Fz4#CBv=J3_7^A0xMsyU1tAW8{nE8S*^&HhGo2j=<CZAZLNz
z2gEHV#KcT)fZ1N9DIh6fV)BJ5{RYAKNEM}qv}V#nMi5;n!FmS-1Q8xp8U^ZjUMn;P
zU4sq-9}r(t^-=9%N?Cw2(`vJ@svSs75=L{6Qp8E60UWWb1ahk29D%JKKsEQ2MA8%t
z^djgsrPDabtb%cqA_Y+xN^`JYic@KNS({Ecw5bU!RlRDHKT-D_q&a7GFYF5-x0xg?
zBQR+qPM}O(A!u*t-sPai!z!J20ih2#bRfW)EOdX(1i98x2ActHGmgr-N@bCy?hSOD
zI=we$FNhMU{<fyg@Djwc;m%D~0$C@M#VE{kvB31E<er*f0eJ~$4AUnW%n_qS018l-
z&;ZW_2b=Vt4wA3}-K#oMv#q!ioUKHSPN<~!Ve%J0JlvfUS+;~O@GFYW)L}8`mIa64
zx7GEh9*b;XOT!NdJj=2^+qU=<;hqKyQA-;(N7YI|jc#sTk4ST6Yxs$HU%kzT^qw~k
zB6+ar^=^(lmg*~Tc0anZdPE<;ul6EjUXD1Eb}TvhA$x#mA=M%T7q95P(u!zIkB(H>
z)*DL87ikXS4{0RlEAU<oS#td$(G|39GuCoWQ6V9q0Rf^ey24wqCbNF^XOZ=5nq2Iq
z7m?14Zd0S7Fjvc8kg8i6<9_GT9=U8*FeZlhNS?gyHg=O6+=%ECBR9`=ShrlltrbI-
zxYx?N*AM<S#oX2C+uIkv?`%xa7>;9KHTGGx-(FUE`gftFsXB5kPrmgpbL7a3&AN{?
zCz5X<DsYe$=OYZpRj;X0Ke^u6?RGP_uT7J?c?%l?_5LN}3T|Oy$wWz8+eIpO6s!o>
z53}r7TNSM&^HxML);qqTS&e<2SG@W!(|yK`p^zH2=@}%oVlUk@+HK=%yZt*{Gk|tH
zQ`#CummaR%+AV7BBkb`TdK-H0Ay?Qsr|)^(KMM|<>`-H(eY+j$hi!b`GFaE8M~fR_
z+pOpQ^>UR9ASZOjyQV(jZEqN2kugIHh1!f`yEwO-+eHrfyOHZ!1XdK<l>N~nZ9^PV
zfK&He=W-(xq`s~>>~Aj&b5a0dZhpnC-paUod;3{6&HJ2!oESoGb7T&h7hnN6rDg@M
z#}()bQHMbI3B~{mAowi=_&Po{*n?!0&{KlxSvW}%`}{EUE7?H6SF{Q)pP&m~uA98b
zI7QL85gK;5s-=|9(UOJq_w%F=3t-|6Mg}VH`8%9#oCAz<c-?{tWEv(HEGwsbj2DpZ
z^|px))_90>-Zj4dl7amjm@is#{a))(C}I@ILbe0Yw2j6Sx^ca2?9STsLH0q55+#+~
zF~4qnaRqsUbPk8>)?aC_{O$weM_QB|bs`^!YDpfLKOec1V|ew$?DgVkiIe(`9}HZw
zroJd|glNwi|IvYHCrOPGa+{+EX~m8bd1B%a+)ivp#mao>fcvfDIP>psuz=>UH8NqJ
z_t@=g-#*hsR*tM)F_V*W4za9td7D;qX93s=k;&q)aKp8Q7|A!<yl%&s6%Mz&)a}aJ
ze7T^yYu&@PXE**wPD;9r-}{<ZUc$angLUA1<I}=($PXdG-;8Rn8f!Xg2B0^ZfDPkn
zSXl3%yucKLAtP1;vOzb!fM%g4P47AD5o)Kxv~8eql+cvZ=fp=!N@+>kR2$@g$kb9B
z6Q%$7F@<YSb)(ghM7GFes_LMIll|}A2=|scGA>u_S~$D8TJDY-EB#W7Zu}(cb|GP%
zJ9VVJsjZnP#uX4<?8qQk`A)f5F8=yEc75B7C6@i=`f@$@-PI>Y_?3cu(W=!AX&`p2
zUD`glZpns&#PUY-#sj<Ve*f#=Jbj?Gp{4QNZ!|QtjWjmyX|FBU^H0{7osqQA)Z&WV
z`QkKfsKXs%Id>xJa;2hk+nZaSe>$0{5BR*XTa1r&l*(I-Yk8%+6u;sg*L@wOj?+Kl
zmk*p?&!1vDPv6dm8(O?8FObf{`{Ctvds*YwpB!BI7Ww9mx6WSliH$~0TTA<T<Al!_
zZHQmJWXWgI8`a6s{Bie*PY678d5^*p{vv!?e_=*^;$~tk0rCwemNp<ePc3h%?0jnV
z0@gIi4$PGReX3<@QqZzYJO&;H*F_p(V=_yuqbQ%KKBX%E6lw4d<q$X*)&+RBbm5P4
zQkI@cny-hs;6jp4T3L#@bYM~I=(YMh+bC<*!3QamtiBy+#$#DVc~CR0psbKClcw@0
z(F+it5G?@z+~rnS(UxO4N2#5&Xx^@b2KNp4Us#GwU0LL3A3^39&;0E>#`pFt7~tIZ
ze$9Buc*D?(?Zrjx3YJ&x<vM$BEtALxvsNM1E_8X5)5%3vkGmL6=xt!`miA()52vye
zrKC02U{}>mX>VP5-&2o2OP>4TLLVSza%cRjFVq70bSh`uZguH%v(cp0k`$MeNurhI
z7$n6p4(q`vA_x?x_e%}_U~M57XqX>fwLy+$Q=>-(zJy#WL=bpSrartz(?W_O+Z4_3
zvAaC67Iyo*@m;%Ri90bsHlHTxmmN**a^=_FPWC1d5@<S7aC4S%eIko!WxoxGI_&5Y
z)hBBaC+KHgqF>1;e6hN+>P;c=z1TL`+1>C7zwBi+ec<{zvy8fDjITTEb6%sAW1pTl
z$=;X(`dzBMxO%_WpZ0oPPA=uWKxuXI@xe0h^19%Moo+UK{(LqVNT=yLxYLw9-+~Tu
z!pvTH2Q){Ysd*51BsAaiSAa_L0#MIiLDcdOYu-Ry-Y;t2u6Y+IC4WM;ng6UgQ}Yi<
zt0IulRbU2tVMU9=j#hwPxEX-oz;`Eu@N%6&W|R4dab8ANA<B6J1z3SBdoei(dG;8&
zlAI*hlN-sch<m=5+z-vhV~BnJ3S`?C$cyAVkZ#`~KP7LG{|7Se@5vv@U&!CdX<{%8
zuw|^s$mT>&Hb}foipe2Pu*kF`qs;&_Omnm`moP_}TYx+IS>|y{1!<a&>iU`zEpsm5
zZw=kT8*je)4Gexv_!PX#CbBwyt5XASIHs5hgpQfU(RUwyqaqD=!!gu(WNI3qnoblG
z0SlAs|7u~zJ$qY`w-GWSwdN*8?0M)nOSSCOatE;%+3vE)Ycg5Fo2AuS+5(1Q)2>Wy
z%jVZCq!s7B=)v5EGWEQ&^G`#|OE`sqptf^O&hO%*r}(d@ni?$~8$BMPEWmhLv+#t<
z>NpR+$;lrbZSkL$pcbV_DCBY1ltg+My%jwDLq~!G%=<yRq_+rPq{2bjWDD9X`Oo`e
zp7*@5(=knrCp}qSy$%1oE*%|Cju^kFr9(2mwA?g{cyUTlGSgIo!m39Qh@2_sQ~C;&
zl<M1KQd9amQ55Q_w+D|7(l;7W)s0I1j?lQZ#k8(aJCo_VffoyMJ=#qfQYfK(%Q8(u
zHba^;QEx8YdBxD@{$RW?U7a>+wTz3BOYzFH6`SM`!?k(!39@$Vq~MDU*b;0a#3npa
zOtP+O*^?b7@&e$SU%X&s?c8;4X1JrhzqPlwwRc)G=WCracjC<Tn?f#r?f6=qkqXBL
zN<G~zeei^Bj?bAhn|)vQuCWGJ33mC@HbzLL-%2lyuSwq`>!gpfh{nU|HF4rk--4et
z>6=-n@r5*5lE&Xt*r#Qm@ENV~H3@dTxmP{<W{+&G{94vm#!s20Yw$aH;3Wxwa~OXy
zi(kXx#E(BlH-qfNOpnJ>`HhEr(XY((-Ru{x52+7_-V92!Lo%5byvsOgydPxt1g9y+
zB?zg}ZEj<apx&%`*i$z5DVy(<=1Dwh^ROf!28~v$k5QtU@#)0Ra4KU@{8a8#{PqM1
z;QEZepwM^%MQ>rx#lIK-Df0Cs$SqF6SmhMR;kfnQgmofeU7g}w-%haczXD|O`r|iW
zHxD6UPFtk#)82(CzB@ZJe0yrh*=Vz=zT9(<7!U2c_A6x1;Lz;8WJl9k&&5YZ+jpcm
zD=Wx+>kXW!T_AE#X7tc(<BhD>mCyQIxij9zHHGk3J%Z%+N<L02w;V?NpX81r-A*pl
zQdheC_r{BZwn8mjr;##RnB((GF6S7dj0`xQCKr$2BX-WdD?Q97A{Kaj>b2IUpg!wQ
z?p)7V@7NYwIx*56&&7@P&GAqq+1;58hsf{zwT0R;`{BWoJ)WJ`70)G&&5~<rDAC=O
ziiXKM%^rmB^*Ag_x-V!=cgcGEX`UO1bLpq>J&;a!#p6%eS<z>_CTj^K&Wp$U(&@h?
z5>J{{*goJ<Q>2tm8{bW($nJRj@Ki;2B5@h|Adlk^{GuuPqFc1*%MyuR#5+0?F7nd^
zuQ+H&X4g0h6$cXuvV-=SPLtjE^~U3*m`+zK|7!O1fw@cmATeU)F`2b6J`Zbo8Aja^
z|0jH`bd67aB=|;Dp5?O`PlbLKBpuL%1uEAOV8QP3*b;vQf-Cua$m%@ccBBt@ZK;DO
z+~CMP<+Z2(78DcY4_<4$@}b8{mZnlq#^Zyz9K8|@?6P$FDf1RQl}P*z+o-@0516f<
zPWY_2IjAAK6A5Fp%#%C(@SY6e{qkA6uvWboDQuAS_*TxT|7Y56EE%}z<kdFBhViLj
zOZQLfdhD)x{m#S;-_l~SJ=OdAQ^s|lTkr^hiF7#cg^KNaqYrPNxjx43^*Ssq*OA2z
zNs*uN&cWItn{(m&OK;tpSmt90l|t%8Dhn`>1#ai>69P54nmSX11otIKH}nIyCjc6N
zL``x*DoVyDx3Lr`@%R1cL(;w9c=xFB_v57NedFU~i)(Xz>z$V!d1U_*^2ke{I(qPd
z%D?T~$9?d`cH^RFD^BLY$`a<6-`nvZ6FfDixodda;m<yBWch8ukyno1_rQl~=46c>
z<GC9PL?<ltHq&a@UejAM2!E})@Yh-fyVpke$JfB)4Gv=XA`e~3V^UNYZs29p3Z`Mg
zk$|{D?L!qGlz}5hOB`T-9>ivY-j=hJ&w%olnj5RCb8i~FcB&3c42+p(a6>hu2d|)?
z?q=R*ezm=FUFAB){~7YtqiYn!VA-9!x%rzeU$Ol1#eZ9L`SRtL8!s92$YZ}~E~XZ)
z3rDig_QhW4?eeDFGuCoJ)%YOSv2UH8OFd;BaeUof=<<bax%KP9R^x8|m*iGs>**U1
zoV?t)|MU+IALfp%y_6W=+QXE8*tUwbT|BYk*wGamrq8-y`LUyCez=W&dK%eiT~LS=
z(=Dqvx=KHvm{6{XunOntm%rE}Z5+);(#4Kt8)MlY2U{kTE8}^kY@yE^KF-Dw@fU&>
zR>M0W^F3l_LT;%FMo89T3PiYRRQ!Qsep`v+&z$=-ndk&yf;x5F2PoT=ZO7XOOM@x?
z;HI0R)zm>$!&nU_DnX{1?3wmX1DYT-nFpDx8}Rwb9fas079TCV<!budsYM0YDxM8&
zkW&R%tKeeX3jh_TUB_kjk2sRKGFO{{Wa`<nMRr<PR`ASQe3{epRmYy%C{q`+7OY}I
zYS09?r^C+VqHQb7rLAi5@Rp_%YwNAag}%T@F;KDyuEnl~NWW+6>?Q7r#mX-c19sC*
zLgxBuTp*z>To7>~8*%!UpO5_;!`KViJ?-jer@3u5mqkuav!A)pG0qB2Bl%LB66$aS
z9NlDxrSrK3j$~R2ZSb$!I`i&TVnfdQG;l*L9<6tpd*;k}Nxoj{J-+I`z&bt6<e89l
z?z+cWp8JxPUw`LKH$FOSbr$;?vQqPbvDqIl@Ab>Rtw&U6h9zP3?<Z=vj5o;9m@vu)
z)?98GS{kr=!f-m(74ItUi(1@yzttED#%GO=TAa&Ep`~OaC)mSZ7>lPeMZM%ww&1;>
zacgJ9zwn1@#^DpW0dwq^HGd{G&`Jkr6bhvI)#M^_2;hdd64MI>p<~sTX6n_U>&lOO
zsxJ|J)L2JSMKJxOCl|7ME7ecq1)#GNzG_v`+(T_%XijG$-GXRLC3b2kq?S1<HDST(
z#!DcWfs!c7!s(i)jp%f*HZjlGW_E=41N~2`r76b4<foOc38vn?>MxQV>5~Vc0~pxM
zF;T2{IwI4PpB@ZbUezF3eF<r8)wO~SjlR!QjuunzIxVAEeN-J|4hPHgszJ}Zo=K6A
z4&7XW(0wehsol;r#M3ZU8Wl(1cylOp7qb84E)9j7s)3dCTszE*zcg8wc%<><^wRdd
zP4?x}5^s~b(d+LR73vr0oiTeXZMB50!CBvH-X;|O_z;<KZ+zDf@|}K06-IVFZ_Vnp
zuIaA(_TTTYzW;jv?%!|$vTpPSx%Ov;;QFL`lSg6v3*6u{nd8!mSj+sdA^;l<k*Rgf
zeVY*P$pGBkTimO=dycysSM@}rx$a1pG;!G?ZvRqStIc<%J$lu<>f%3KIzD!|ZDt68
z){N2-%I|g8edT_8F5%I?l^o_`ox3)_7;d@t>`1R=VRH#;$>9mc|A%-}PpgNQ8wMhB
z-t9J?cDq&Rq2(ZdZ*yyTUAd`y$juwC)picF>wYH_Qw9>ns9taEI?^<daxM4iZi}aK
za|#f6siwZf%2cVJ>{R<cZXeTR^}^(?jLaekzTWMSSPStP&#57wC!`7l9(BgGT(A})
z)Va#X-N7cT-PwSb6kHMA8FWZ|lzef|0pDS_RP@(}3iTF7*A#m!mty0+&SKHC_`-qm
z{@n8HtWQ5tH=R`%3P_XOBsKn+NLF{tg4=g^{41<Weg0dSXXL}XQ^Qv~xz_Y7VW#7N
zJRaW%P=HW(<uA83&S_lSGGl%M8Kl&>&Ee$-8_Tltw6A$6KSH#`rdD_VQMs>orcGi8
z*0n5IXPsx$2PEH6p?BMi3y*JSfQ-0VP$M^IyJo1qIUWX@dBTWdD1W({xsp-E-l2S6
z*WsgL-I5;ZYL5@KmK4@mmpA^VhkbfMUK42V?mN+uOV!JN$d;!EBJG0EU2t>(lpwgX
z>ENv4yr)$a+L^|5L*8ZUDW(VerWw2~db}x^?(rw*4!MUIbQgBm{A}zBS3@r9*KB^V
zb0-!&eX5(ZFgI%>Sel49WxuO2n{0H;VE5EtZ$9EkUc$<~6aLyqfUI_2F7`>iSvFNA
zK<5Y#Tb$aABX1;dFxkmDPYDVo1<80dIV`xnNe-OVCA=3|+u~*(AxwS1&A_z{-Vf-U
zTIDlUK8H9nCOb((#FrwzzS-A|-Fm}P_l}a#H-4+};N8I{mp>GWwMToKE?A)0o!0n|
zNsg>|H#IyPS_^OO?vWwmONj5BzV$k!bgKK#)^OS8bOZl8=wun*IXeD1EL?UjbvCxy
z{TBV~8)_XAC^W53O_%e&qTm=E)tel~tEV^4^|tPw_0o#5j)j{Cli{FDJpTTteia{%
zO`8$wD|M=j0K3dmDN<Y1BzeXbM|;1&@*d%3-^?3NvNs@wH#ek*E$O)E5ml>O4>&aA
zF5|Va>5JM^N%osAyUfYRw=6WBX>ry;p|2NVCbh7`EMUE+$E;x@pOWo|^Rusyn6led
z;tTwL!hdlE{Ob3bo{QJjd>mf&cfmL5^U!!c0og5ybj4yE+G8XV2DlPLN|`1UaZ)-<
zKh7RAK?h=!se=l&I#LR565cNI&tSkQ@(nqadTnG)jzR5#@F@BxBbt0fC@DI!4xT#Z
zSM}C-{v}H1;~qASLjlK1`IG7I43!8~y@3Cie*AHd_(J>=;;ww(nKhmZhbupDlYOal
zy3beW_~ubh?ScCl;EcQTjT)<ERM-<Wx8ktcdII@*f#!|N5<}N44F=<~Bb7XR%r@9o
zB;g=X5`ax|?Hq6Eel1+5u(BnPVm)4`VEwwJ%w(Q7nvBb18Pj5;U5F^QIYz0$n0t8H
zirV&4(i(^xg}Rx6&K1+iijL+~!23g^iG0^68CNm+N`;Rz>y>!rWu`6Qs@xUl8MgA{
zZ~QCiOS?lCo(Ol|Pm2DFg^9dQ_@d?&;_l@xU*34rbyt4ksWrj!&ODGz^~9Y|^9NV|
zgvm}HKl7?%xUIM{*tVfP+T;u%M|Sy!JA;xq_Y^ts(AoEY_}F7GNKemq1-C3%uy**=
z%(Gv7;RU95o8L9V*_2=|jm&J{e$4oW%m1@jslof$W5%u*Uch`#Al5D*e!z9ZQ!qT4
zkE{ooug7Z^)~u{qi)`1MA%pA!Qu3wnaywdc0yF;lnj7&ZeG-`&@2$DN=5vr;ABShu
zQ_xq|0KS{P1c=!%-xY*m!~rSTihb~8(cz}dw;B!h|K}ITxh447lw9~`@umCp*L&VC
zfB?;U+OCm&w9QoA`R%8Ur|rcLjO}(oiLs{}`B%A+#U+xPJB-hfc<l59|F9HDa54Og
zBodKWED@>xPVLj*SgdkcD0D$X!wgk@87aSVPUq{<=*QCOU%;Qi=`_CG+<a*?+NY{_
zg+e5V^=CA?2gNTnH}6r^BZ<V<qS2*J=Y7%WibP^jIvvn7F5z;W^|D_Jh0ab3h1mJ=
zWbE2VBzko`mb@VzquYraP<CB796cFNM#=L>jvO)mHmm=LF=Nx{%+u!g`$voqXU?42
z!yTL~eDyLERO@J)O`Gr@SV7m1iGPKUTMUs+1!OyKscA=q4vo!O0a_tC#CRg>pv$;(
zJ_MMxpydz?`DQO`n#oCAjAP2eU~X<@c`r{(=<~0BX^wKw)W;+OC=mauI6in(aC#Vv
z;+osh{%QX1k~pi_czUUDr6fPs*lN5Pg9_jHN|{VEip3V=yU7`3)c9(V^cu@H89&%S
z8jSA@kuGk2Wj}MW@;X!d!F$ZS%46KxGpFcR^nCCh_gv-c%plujJF^4s=_mXNxlsla
z4%s|NU{Fs!chc#_N^&7^@7`%lFAKFA>z0t0>JkgE_3jcfG;i608<w11l_t&vIh0Hr
zSEepbU7Wlds+9jE$m~~B13bNdcz`u}F;;e)Yjz-t=~I{!G}h(yn$tiWRiKw|C*#n;
z?}zk$CAp5=gv{`Fk<Ze5n^g(2_#rgZE1C-{F$*a)OZj2~&fKQ7X_lDVC`WKe77;4o
zv#cp?i@<<rZDFcQJZwR76)_J@l3OLmZC=bj<aMIX;bvf3TLkiLUse940xdu;%$a-6
zm_!xpVpWoMVH}f{bOf{~%;9r|;O*y1;X8qKAt*nMG6(U89PGsz=_u*-n9IdU|3x%`
zLp!DRWfSU6HCG|#ArPb~Q=vhlW)Iafn(tj1xZt!?6h%$$gmkUA8}y#ws_}Z#Lg6FF
z(F)wYDU5J)MWaI_jNw27G1Z$_G<&7Pg!&ks_f2MEaTi_cK;FQk`K)+_<mU-_V6Nw)
zxHhLQP<P?c`#-Vp(#M{9tjXT_v4`*4wPa&mAzRB9Y7^1?#=1axYkZxuveS5Q|CT#r
z>7F@{Klm@V?1NHr*+4Oyi}*jc?@-T--Zx%8^-`*_amOR4muNj-v3wD)<K=BWZDY|Q
z9vVYN3!Q6$pA>Izv8%Gx1qZEZ{cCL&amRQ=ITne|iph0yQm}cD`&#lYXjJpv=@u4?
z<bvRGBkWu$q%y!W3Rpk6swJr2$lKa`X8ByQV`eVi9`Lj;bu^z03^(g5gghLlU*(<|
zQMiF`<)m!gGBz1%UO6U72j>(<kpRmr)@$%05Co-B$?ZO}()fC&JbpX-@v(B!Th}mu
z!xK6g${|U2<f@5jwY3aM=^o!;0F6TmF9$Hl*bJX)S3Pk)<#hVIfrwgwP>~c1My1`i
zv|-0RnTCN;$9PvF6dCVS+6Ngm5mD<Z9kvYLzi{!gb}=uF5>F&{CHEEP=ZlS}$5tHo
zZ`twC#&Jjgg*Ux+*%z<(?f>Ex-@V@F)@{zQV83hB-`m~TbaLARmD3-8ckQN2%dcoV
zE*~WW%l6$&8XG$^!->XNc*d5o=9i_FGfvIbAF2Goy)6<A-OcP&ay<a&KH%{L-MLVN
zxLleRj0J;xSFLGl#o}UVYvqaH9HGGy=Vzw6r-^x&kP=6@pL(RwPj1hjy0+CBi_YmC
z;=`7}%JCHk7Jgx(bA@+!)`3?dS8Z508eM*9`HG7M1F>Be>sHMcOk@~Y?EVqi+Ohb8
zy&g}<l?Ub;Q3pcb7+-OP__5$vc*r-VwYGH3b~K4$C709SQD>|T_baJrLKvwP3#_gO
znw0KgE7_sk_uWS0UUwvwwa>8m>;)yKd41%!$Qx*1J+N|7<+Yc-IVYbRob%}45d}W~
zA3w2h+<lM{?}7g532^ThL9KoUE91McFa86TMb(T9&miAm4;cVB_yoBC*27E530Ms8
z1l=+<Owd0-?5DE`v%9*5>6e_Gg7~3iz|>r}I?sXTU`kS;PPie{$w}osB%eW6R+DB-
z(hVUg3RP-Ad#-*am)?^H;b@aUQBp?b)v2y1f@fRV#Fa6HR_b^`8CR(p=p9p=|16}#
zMpP-1tDdXWsiYuMoc(fB>3lB@Gv=<^7kqjtiA6Nu<ge$y?DH8Q>tjr<nRD6z-Ai>Q
zIvp;xiNT<S9c*D6S~mo=p3|wB*G3gE^bVQ_n8U+3%UO7mP;y4o6J>RJNmJXjJOPO0
zHr>KG7=KvM8+*gEo^XpD-63bm7x;Kb>kU!Kp-DrBnb^D;dxkYp8+F=w*TY;-WQI2r
zi`BUY2|uXC<68Mg<?GhlJCnV9{Y@iFrrA@aS+c)t`kbc*6Ek}D?C;p!v0xVI@@A&V
zgyU|DMYW}aL&1E}sW;b8OXP>9)uu-4I(@c=jKAEj4r-A|eJI^5IIk$BCMHs)lM~5O
zOJbs!G=HvKkZf*BE%?U*($ixZe|ceF-=f96eG84NKJ%I9yP0LnJB;@?jL+D#aptUz
zZ!hfaU$nTdcOiR6Kk|ZIIndkJ-{03eaOJ?@;DB)&NRe^jOSWJzlJ@cGz)r4XL%ppt
z;4yC5KNcICMvT8LT`@7S@=OCF^(`S@XFcxVNXrUIs<U+k-0WAw4*28+8R?pkgI5_=
zi!cIo4$kV<m0@6tL=duS-_|B%>&39=Pe}j^&zVi;9NJ}J9b@I%9df|}4V_DvmK(51
z$Q=|TktVS(F+*Hwyk@-j)^8BP(lgkMj4&PxA*vS4ttZ>kv!DHxoQgRA<W=@BibB&C
z(^OT9S@~3`LtErcc-2l%H&dG|PD~V6Ekw@aX5(`vUQMZ<-ofIxN=HiX^i3@6>z!D@
zT&R@%rLplX7tNTtd6O~GyI?_o-~5Gy!OePpU|{fh+@^0}JJ+yiwFhZryiS#Dw?;;Z
z8u8uG*SC66L+*-Y3l}Y0vh>Z6>hQyPn=lM}i9Q_-yyUPWV{LG1mpY<6Y1S0uuWFnl
zB~7_RO<4<0nygHM9Jx>Y4*y5UK~}6OJdh*jK#E+BwFD#`Q~scTvyfk?=O_%dM5~F%
zY8+adw@q+NZlgrRO23SXscG3}k_o*3R5EF#8H=m(Ocvc?hl)<<@zK2M&#IdXZoROp
zP{@0kx2&nNuWL!+#me`My~f_k_wUH>eVV+Fl<^D6Zw)Un4qp9fi{1Mw@~U3PG*!O)
z-hHRu?_aq#JYaJs@d)RBb;<sF-#hb%i)@jLcJ2tu8##XW7HjGv8-7q^-+Gbi-?e>v
z?M2SB+w&3|b7#)JfV2F7DMG~a|2E(B8{_9VhZ`wn7UG=0|LRefdK-qa=f2;+cWTGR
zW$WUd(ooXnvW<VK=RI<FL5kGxstY<ZdkaD;3rj&BbovU5&i%=Z=gPwVvZUrPq7ZL|
z)!<W*FMoi%HNUEPhv@MCNI+~U!P{doFdHr)TM^cBH@Oc!9bX2T{m;lR;KT7gG9-M+
z=u8mVVkzPWgm3!6+8+zHHcI{=Jkga9gfdgg16f57h}meW9+ddMHGnS~L?kNZQP-uU
zgH$^#Pj*R(H^|t3?Uo+pO;Qtw8KIBu>cMW%W5Bp0+=Hi9B@>JTdsV`Tp_SUQlvdJ*
z4$oYgpQW4y>>kcd;on=SMWY0=daj%EdTE{PW%5|`qtotbd`;<p=!(W&Qy-FQkGhyd
zt0c}xag{w#Wniu*>HCN;CHBeIIH6~yS`-lJ>U|PW3~`y3edL0`U~uk9zD2JB9w6xI
zykXF;yjA7|eaJ_~fga6);E4Y=lIlR{4TM9q`Kah$>JmnOyw$(Stp0x<s#hO#b5pgw
zMgO2%{8#!Ns=Ppo!TNN>pL6Ioesl&e=uOEU1bE1Ddw0rcs60oSgAIv<x54I?1b%eX
z$^{yueX`eXmD>lRY|D?zEcx29A644XvaAHWmQ>W+Xw#9{DiCMnQH$Vji1cY*MUuL6
z9c;^w+mTk;)%(T}HlAJeW8p1(@4`;eA!FHDdB3#T4=?IEEzG%OVU{HN*rqPOXwzKq
z6qYj_w3}t)3Rdo#&J9x^TV#zeK5Oq?(k9weqEvoY#^Lso76YCp+<DzjNsN>_SjoYX
zL<z?eYt%g6+C9TE*dek{iu{1X5@rP;xT)Q2^zdMiO(oZQwO9htaxC(?N~>BJ_vr`J
zUhdI0$tCTv_Vod^aeAxo%)w6ChA~T(_Zy*;v6YG}=V3%aanu6;OmFuQCe;$OM_EN@
zI*lXt_8E*g&<T)-heb=T!|LNikz?#VR>ujP(;7&u^@e;=C95EGB)Y7f@qW-of}3TW
zP2@(JY{nCuIM~VCU7c3nk)c2`x;CK3lL1{}UAEZDCdU0?r`;j$WyS8=AjgfAY|Iws
z#OYg@XS<l%%Io9F`bN*&h2-3^kgm^LGMARkh}8!?)j|w+-s<U<HO!og_rNKFaI3d1
zsyqQtFEopV9LajW$HS1f0V+Bc)V=e%x6!88-L|!9cmU1jTyuNF&8sU<a1Xg$d3(^l
zdgp?WO|v?JZLCkS^K%vyIH%ptDv^MV6J=+;XweBA{At^Z&{VZ6YN(8`JEDs0ym`n-
zW9OhvNBc0)G0pb=GhY`ygz%jq{EIFQcZNGz&ZgNdl6&z^4qctOOtb^bfY+HemJ7ML
z4fde*f}IP(9#PijGrWysd~CXI0TBPRdR7evao1cOoZouprE0&(*Wk8>7dNM!!;I*#
zD%jq+f~^B~uFe#ZOOE0FVz=LqL_N{Pk&a@PwYUVULL0e4HlE?#b<Pl2B{*ciai#d2
zARtcH3mbbE^lmj%+>r7_(o&O5)KK@V<{FR_N<-;#lzvSD270S!TPV#2@dXu}^7MqN
z?YYX!#>K|PRQpJ-A=fZ%MvL*|Z@*%^LGs^zg%tiYclx$%)92o_b8KMQvVpOkH{IUb
z*w{<I@rkaki5qTUM$SK&cJ^(OH{N*V+s2PcA-=i0t*v|WO)WE5FD^GVl^3s`+4952
z?(W9Mo*v`P&gs)TVHT*Vi9i<k8vg<R&6<?y)lh^7!3gw?>uR<@KXN7fqwj$(`bl^>
zeh=P_@4&C|16VpO$a793aHzhdpG=>!FHqYet{>VZiVQ%>W_nWOr};rV2y_M4p`3><
zOH3P|d5fm<be&(C{^zayNSn!g-sf)be?O*r<EP3g|Dli`^r6u0sdD;osF&_k`T1?m
z-=<@mY6D9MeTX8~1!jPdh=-X4$3wxned;O<?TrVtoVG5a(rg6J2(-c?LpPm$;Zval
zGSD?yVjd6kX_@~Z9f^F>_<rqTzr(r3;PqUfF_pT8xcawS6vwVBi86hazP@r}<$7ih
zv%m5{XXOE|BOQ*eOa!B`aN4+I<=V9?$$S1#I^_xEGsa8E2NaAZQ;~2enlkQKzIyfY
zFC;^eXe5R6L_$gOULYLL=z&bmcqkA_CfxpXtzk)qqpMfPLdknm*`N<N)n2mLA5JIW
z6jNJSn8^mbnN-O4U@8^z=hJ@u;i*=}!<kIbtYg<@6dRK@?nv@h7n}HUl0`g1(zqM3
zW_FT(7_-%)V!nHgd$I^Q%zjMKy)m0&Jf<mO@PvnDN8D#u<ooGvgceJ&xJ}+2@N15x
zj|ZESUXqvny3XDfj(XhlK2>OE2gmQs_2?d%Y&C8)ZZ#}y-1yAdx7jdRarPJN?x1Gt
z3~2~fd!ehNT={+ufKBzaEe8TFfRX!=hf8%l*WTV{91S>tuO39&E4x;CC0XCx1C7fM
zGj&Z}g<KPPH0ZFmciFVc;~m9(p{u!I%t1%R`dU!Bj>cS}ySdgl+0|T^?P$sy*OXDx
zQ>weStErIhDAuyxu#{vOmm>Ya0u<Ar&0#fu5CONhc<g^p5H+AUZSeZC15B9X&m>3^
zc!f&k??jgbdxkVV>vk2{TH{Gh;&^LQo$-tZ`;E_tDkr-lfa9nEb((KnApQk$4l7~v
zyQpSA>`7O_Z~g(y+g~GUuBr(z%|w`;cx&lIom{aaCt^)&3kaB(3ODA|qSK=qNrs}y
zspCP&G<0mH1axlxRT}{#ld1vCS~w^m`!-%|b5G2)CB2}3=c=hWkq!WBa_SY)YHAUy
zG8T0#75T~f>hP-7I0>8(Xd`nll(5jCUfR#3B9Zzt0Ml#A`0q6vi+}0WT5Z#P>oN^V
z-YvP~3%d|f3ztHD*!cd}&l-1;^=H~PWK?%nji>dmdULbAkExm2PRkgR796?8x!daG
zOjplA!Mk?9_FZrGU!L5$TYJtHWSGxdUkC$t@`U#ljUB6Zgn8wFD$WzPSS(8{PVek?
zPkTCk_Rhx;N_#8<-JViTr1ExOvl~FVTDEn1s@4TeCcN0$ctTKIN|T~?t5%gPd95;Q
z>5|!F9)Et}+?nLnW7oEAaz?$u72!5}Ag=R*JKxp*#A{?d;$b#;=SL20xZ1M2<kG!=
zZ+xM+Y4pU2`foIR&)0PI%S*ZW4=f&9Qh%g%;oz)8(b3i)wvL}T$(*vs4u55P>~`bl
zt*vC%Hy>fI82c_9-hb&_rWPKK9BZ$1?%9<X@i$3Q@2~oX#QVPF3VYqHSMFn0wl_*=
z{XOG~w^0zLbzREx<xcCI?*0)mwN@EZ{TKMhuI6K5!w8HnA0PKM34%qB6dB(O(Tn$N
zSy>xP?c9ual-i{~#gE_}WwGwmVb`jms~gy#95i@>Dn{^L;my;hoP6;Z%lyb0h5KvU
znJd2V3i*Ecr=R@fn{R&d?l)SVId<%8&m2AWjPWUP{h9ULinEUlkwdiZlW)F$*RiiZ
zd+g{luyx@~^Nr8(UlU?A{aE3`dxvNgw+6fbeNVnat%ykkm%!49PKtA{wzn-?!<wrO
z%Di+l#TB-wBfB|!XxfjqvWKp5AjF$xl=qmQ44pvy*NhKGjt3l(aQ>zpJ1?6>I-7n_
zxN6ULUwC=O=$1<ktzJbq<B#`x$rwOP8;Q^L>d6I%$0yEYLeuBYa9M4xZ!{pohW|va
zVQyAWWZPSt;0}ubFxki4WSqWyBvjk7qCcN&zltzy;{(?l6N~5WKJegUuWat?-n)4-
zE0SL@#kupWt(q@SZn{A1&DT%cwy)B+Y4iB-EURkc+fT<Wd+g2Ymu-M&h*Prlb$7ec
zsSbyE&+ZX_f_oMR8rVjYc1-%{XQ&^4m5NLXIC%T;p=@=^)8A}!{+;~)+(htyWls~*
z61a&~zjSy}-_TJ1!igTP?a@WiD0#NFv}{j{ctO8|akYJHVgIygeG5m%xuzSh40zA1
zYiL=tr`fi2z{4mlcP{K78tPjxZ;&l+Jro_`mi)1`x3GPzAT=i&D>rK)Bn|6WFwx%9
z$ozKU_Hs*G#d5*;a;VWR9WL<YWJBdDHM^^&ePW{AoMV19d)1PzR^#`p=Pq~l*6tW7
z$i-w`<>U6q(bo2f`EBUqz44KGiE&DUVW%}75g!#~6C>}48C`ZS(1{<ddCs&k{T{ZZ
zC5Z0WMJ|V3=>hTt&`aMS|Ax%9JDEew<;*qAoo4ph=b7&?2wkJjQIoG4rF8%0W4>xI
zOPS6VkSjn;@mxR<DJmI0DJt#I&m@J$X35--Qr~+lmT8Si(9Ke6lA(%HuPNHl6*u&n
zAk!egu<TQ?P7jR4FdLcP15~J;Y@uiA5v}n4ucoTStN>%7vTo6Iv7%?mnxZenLP$N}
z1<;q$WIa@oQ8jD98LN7ExG4JKm@|teJ*6&`U?V!PBXB3MWqN#>(-$%pD$qG58ofpw
zM)&B&l#s+1w}948mST@G3}67#7KDo9W=uA%rfh`{4IXw`s>#I|Xru|s%}@mF(1>ct
zag;8BMVgK15YY)jtI^CPBWQz7TnCl$CQog40#R?WHSLDpVVumPi{|sBC!@F__%%Io
z>Al3DGU#4F&OD@MXamE=<D|v3>&aI106a!|O|%t0sH2i++I*TWn$-}e!++cldV8>8
z>hdSca383D4lW0MgIA*-BQx&{HZe*X+#x2Y!UQlIaH7Mrr%wTAGv5t*Msw7(#EV<w
z#V&o!)DD?7HB)%USloY;pu+@>tHv$IdnZ1c@z=45&9}C6Sc2WPqDu?uxh%A{gk$Y8
zksZcQTuX(Z%ceJmZ@AGVDP0<)trn&OCqeo+Q8Me2`k3OkIU}+j>x-s)bUn&=td2QN
z?+p$$E>inspCi(G_HrrUcDsvK1YnDt^&%ebI&9HRB;W~?&wzy4$_x{?36T-aExi-4
z**3aat0)Kv`*lZb<n5Vp$9!#O+BMsF!h!@TiVsPQI3O9oIkAaTIXknf;0Pw-cuia(
zEm#hgGrjN1O9j`4fk98>2#cUqzi7!edl=;CiCC5Vw9%GKnuH}?QG2vrZ!(_VXtzs|
zVCkaD>5xYdkS+0OOVE>^rCM68b?z3~_=>2y)z!e8gZExM=u%0O#hMymU4GHSAU#SB
zCMD_jZV@0FfDnu&V`q7mBW|b2|J>)+09@xO+HKPv#SUYItg}|PDp~6@O7cO!OAOy5
zDMahFv?)c4qmh;2exq2e?mVLfRn1Z_+ZB(8bATO+)`&Il0y1_^>~gD?P$&@#Zpt6J
zN+AsKTUz4U?sw;Csu%hS3SA^{nqtior7oZ_Zr?Vq+*(^V6x9*f?ufRZ5ZuTL<q}1i
zw54o)Y$PsP?Paf)YX6d^Ik^tTui5QOosz5DN`h@;Pmt>`&j!m<Tq!8qf8s7i6oQyO
zR&-kho*ygDYK|~!LyAw#+>OZhU}W=pjn|;cK|mkx<~8OT;R}MRtOlJfJM`CF#GcLD
zd`RD++m{0NRpIQsb(D~fy$d$uiRVSdTN`!{*Jh>#+>gZv;?u5T-w1pBDF<S=MLe6!
ztyaxNYzmw9Ns>=m%Z3$6(HwvgIa#oX&d2;hFa@o~EE~h9yaE^#Tg=$d6L2ba!5MM}
zNpCbOdjRYtFe+mgkZ`Ms3s%x6mIm5auH3#L3B{I-ggJ3X+Q})%tSSPD5jywWy34f~
z*|$8UNr@e+hZA_>efgH&m>?7YrY;~BcfK4$mge|I7A~+ki+7OOW#{@Wb}qp?j4ub8
zGB(|5b@pKKCVOgSm(CovN)qo8Z6)3KIn$F;{1Uucb-UCIV39YR45NsuJ>ibAKhta;
zzr?gfPv2mdtui1BRC_L&B-e#Go{=pM+;S!TU__JbR^D$5Mtf=#4y3J>2Ym2QWa=D<
zNN{n^bj%^xmEL?#WcwpL$J?b^zdS^<K1y>Xg?DV@t+r#Nvuh+5*PIB_N^y!9{hQ(c
zw9_I6RLRLAEv{8i(H_PejZ-)PtK%hv!fAnk@RWI}gtfd-FSx9+uzSL8C%{9O--A(!
zvqOoLiZ=BI{BfUkP_jg&$A!IVWMp9+{p_DQGA!?ORUU~&6u*o2P^5F&3f>(6?>+(d
zco#fF9*3XQ^U&MBUh`JX@1XJcTTO-V@D6c9e;<bpq6vEYOW+@JD|GjtLo6obOk(PZ
zDWR>BX^O)^X&>cyV3eSbCWitsM46Z|S1nW{P1!f)I8<c-ywYj~l};(xlF4GK^wX?0
zNjnb_kTONHSIW;!8DZ)#&Ym^hG|?v|?UNszf07AcG$^cr`!?l5l;{_$zasWqVIC;K
z-GY|TEz{CT831M4Ny<bZ>LS>~+agl6IyL8*2@&WoN@<or?3c11-Nog?U4vdUMeeA!
z1y7;87EA<xDKiu3ACrgSdcgQaoQ$$Ae5OptQ(0C_|8Od%<F+Cs9~~h0VroyU_J^tn
z14kE=mr>r6LEp3^Y&TKfZ*HN?-1^0c0JjMw2Dd|*n<2T7L)79n3iKh#UW+6#Ak_{~
z7BVi%iYP`svdTId1RmI8Ks6IYCCY`-P|yVXu%xTeX5$AP#w{aPhFV-h4re0b?}I!h
zadFW$+B<rU<2w8BW8I1E>-IM_wZ<ITKz}*yX<!;vj~a_#^CIa}!p|s*RplpaND<yH
zsIqA1M?}qnTs@jYu&9!_oYh&)@)+`P*w%|O&pT%D5}e}rSpuTBkVmRdP-H9L!oodK
zP}mlhQ$<UyB*`itmIY)?6EGc+;Q{emt|2{?s1tf+by<I*J8y5Sw;_FNb8K$9^#@sD
zG`~U#NXM-^23u+iR%i5r+Cs_r%a9^{f(**m+n*c;qUt52->Q6aSDBX_$D8a{eY1ne
z$8DDhwsb7kVg*CpWo56s+`{j(iIH_7NjNC7{Ef4aBMK?6^J$x)hILugVs=3XngoMe
zio|Y;G)H%OK?ZHAtjhu~sA9pvIwBE9Vx_3VZt>$jF!nKb&g%#oJ;uS&TN9Di=8`Mi
z-INN4eYMk$Dc;KpjUln+`0oCvcdnZ7@Vu0DFYS&7@(2e+HnEr(zW5o^Ap8FfY2PG!
zm)~Y_7c7d0;UtDzBv>uTCc{YAYZiwnE`i52V_~$4stO{z26$GEAs(76fGW?$U6go%
zKg?MH&pOUaoK+P0-Sn?mYnSb8T$WLtM4@D5SGpSm@nYXXyJeJ=^O3H$Xzxr<EU@9l
zv2ok1h6S>dPt+%8jSVy`ofWgk^O7=lH`EpVw>~S6g${BSdFbXtTr;^`Q%mw@Kk*;K
zlROl4B;sX@w*NZ$uqYpn+7F7>LsdMy2gT1LmjDZ2V;^uYsAhKzYv5I&aC_htUNgD&
z23#uyKICwQ&K8?gE9pogjjKb%9?Bsc(+VAW%WC=m+&*4y41H<5r40*uILjsD<+gYm
z-GsO4M+%VyrPwBZ{(}d_C2hv9ESq(nEDu!vLyB05wCED)Mrl`oED_vBjWr@GmcFgl
zM>o3#vLsOXv)N?D<&tqaK$Z(`e$Z{a48J`=Hp(vJ+gKmxB*9{|$%65cjnwm2qr+)@
zi<3ysq8bm1i$DA!-*EPzF`M@=5evs=&ps@xhEATeu!qhbw-}>t2V>(bD8H9D?FLJp
zq7{dX8G_@y_I~mO6rcV{-W`hw3in4|J_EigTgWa!H1^q$j_p!TGLCo!#ln(ZHlVaq
zd;2?xBYU*w%ZT`&4lkW$WH-EYt|gx$50jV4_sNgRzmeaNKhw1~rC=r{q|_a`%&G+5
z6yvdtb)H#7i6^M;<Y#h^=0v53ql&JSK)Fp00INHC6q1z2PT}*J%;moo(Pf57O3{%i
z#Z!KP!^__4!olp%RKkJ6QtFHq4}1cPKr^5xrQm*8c}$JUjPoWGp>UF4;fU%|rh1+#
zkYctC3kWbm3dP~US+Q#_cP1CIlc%J4Vym|WIp6+SRVw0`YB>%w2bIK7=-@Flp^2_#
zC|VRPfNIe+o||jD>h+uBLOdg__D<eUTGmE^MNFQB8v<VAZZj`}>J_Pil0F`KEx1(5
zdg$UA*PNvYSkweuy)`1v>MdhQZpr`{G){uQ)Cy0d*m0X_WMx@=r`D;BdYTqE*DdMt
z_v^RlCEnrCe6>iy=EN*=A^B#=?QWhed-zyqpmzACZceHl?NoL5m<(NJeH32wEEm3d
z<M$CfVwJ>z$Q7NE<e}+wz_f&V;0d|4lmug~vqiSq1Rz#p4I=@(2<C9zzVW+Dm+Xm#
zot>wyZw?y+obh=p5G#7gfrkB;4O?V?-J)6Jhj!Jk_^r{TAT$_UYjA$}ggp<Fh8i5H
zcSrpvtibg4?eJ}iv>vz0Y;0p9><UU3>cPc9r_5V4X>`@|t$d0T$Tcp%JJ>c8^6i|B
zj%cu<wrh4_lnDxZuG4h2ym0MsgCj-Gg44ASuR?l8vjc(@F;2N1VNP@+^Av1}EYgFz
zRE={6a<i@7#*@6Yz*_v{y4SWLovz(zcMILMq?Ta^lWRf{(w%x+Q{Pgf5Mz0V%S#e<
zZhk?xF`FZ|ae~I}|KJdLnUO=9kSJMfNL1c9&&4fcyPP?_p<c9Q)x={tKNP+xyTz?D
zo_t%7TjY!;iq?fK2j_P&qtpElMO)C3=9L4@3~NPbh^jgCkjvdaPDD1@rv)#x1yggq
zv6!Xg@;AG4EaCjuZTqoJ$=D_2^lA{PNNka9aljvP8q$>lu!?ipQmO)|sG<YpPt_qv
zJL4s+E+G9&``*9s!jI3>=X#vcn~%+?t^A6!8pi=9HOQo9UUDQMGoJ8#F;H5*ap{tq
zj<sz3ol)mh8D?i|>x@F(Cp91~MTY#^Jx=acxSmF``#rk@Hv#m|bD75jJFRuKo|u4V
znuVXW>6I2f7mzcO%OyE>$@cC!(CRK+!C2#MrDA`r%8>hA9<IC8E~=FyywpN$s&Ry!
zJIJ>s$vTfC!%NzqS&1w891fe!-5D(Ryd_v_1=;;((4{PmMr$+k;{9TLu>RlOgH4eX
z-{*EA^=vK`QqlxjM{DIE*AwnC77MJE+{Tbyf4P)A$q<jdmZVdy;iWG71n0@P8rnRL
z*yjXyn8O<{`E;>K<XxPnwli5{(%qBdOW=WDhsWeQKo9&I&;xm5B^sFq)RjwtuW|w|
zK%XUuvM}i`=5Lkwf+B&im~$UwjZzPj{?Y;}wO6U`IqBOx#v~9_$`&U-XiFto96$L1
z^)(Y|PI_n4jz9%aW`0bfLAO9m%wlSR@nScNI44RiN<}oG!~<n0HOY)gYACIS_MB3F
zoVzH}1%gPssD^aam}Hg3pmlg5R%x9{!a%@8bJvxniG^s_F5sU~w{ToACFo{{IL=(x
zpac4;G9r`Kf*N8VpxoHQ08N5Pk2G%(F5iqZrRSw=sd}in{J;g6Ookq3D&KHYIxy^4
zhes{2CN-v{8dpuFblMb~v?qEaOc!}dLnrTq8!EM@A~F*4YBtu&vhG%o*pLp|e8~J1
zQawH!5L|syA;716Y0-Z2;h81<h!?637=PUB1a=^%>G9fd``m`H?t?CmYKbF4B1E`g
zVKg1zvNLYu+<Y+QuG{1!9*0v6CB#)1k2lx%Ui=OqE&OUW#c+KoPu3Q8xKbgD#~DJ}
zX9o$gO2*;{g)Fe}J45OWI|E@>n(^hzd*ib%m?>Hqax)NmY^jEZ1Q0R-xa5@FOVoJ7
zkeziA9ttU^a#D5P6*j(ND8<I<q~EbutlMfiz)R$g-c@ma&h&7nE$Y2?UMi{1+2^!}
zBArO~(g(;sJ7=4aSXtH6=@xP8k}p}ri#U<Fw7mA&5m{mnC;=@sB9Pg4c?y|<;emC%
z{=TM`nJ2p%AQ+by2P&VjD9c6a_PoFnUBy|~S+wZJsNKS;@p;3gf?W}qx{|Jk!imS2
z?m0nCVR(l&d<F4Ik+4ActK@`k^{|1sEu0PM9-FEorz+Crs(EW53zb$PoFv@MPcA;P
zuhTbQZLY1|;+36RN5G?rO4rOpUq~C*qiML%h<1PDhNlx_1GSBH&1}o6IxcK+x*>K;
z#ZJp!x3gu<%dTXqPGz&C!&c|WdF%z3#TVu+$&jMk{i5g#>w2EEcoctSr996<Sbq9L
zhJAe2DnHP9#h6E6FC)(}`>o;e2IhLV#bsM+QAbo?OPd`UXK|m?a?-6-o(~wujaj*D
zzlT?$qTFjqmsrbQQDnv%9m3lBUQx`-bC0&nj5n#yr05>HOjb6mAnbb4;;^c*SkWh0
z*U$gEWgo+n_?&_DFVA9+*<j6AB0W|s5!&}?k&aBhO<z8$$BNyb%|*(o6?MiN7Gb#@
zx>#XW@u9FqS}xcl#8RtCT69{jkxQ`6eqZPpc4^uQi{{Zf5=TX1kJx~t2xSJvh1d;z
z`FmjVng%S0g@_JXgDA1BK(pEl)Vq(>d;(En$l5bGud9<0J4thzfh@r)N9P)Xfaui4
z4+Itb1y#hvtM2RGI8Sjcpn<NEj#60!WKo&LvFOm11&?naNiS=5MkON;pG0+4{xPv8
zTu{hk9)kuY>C&98M{p$7#e;TaaGaPn6x+`E)7yIb>T0{U24Q0Fvz}eW{H$rXCCA7{
z4Q#RY%G>n|z0B2>%Y}ez(?AzXwizD_Ud=m6<+SkTo9xe(<td+sn|HxAF^*Nrm3_={
z`-Ik<Cu`+Z(;~Oal|AISHsTEzdr99l(M`V<Ke?SfEG#$`zgA8;9rE1liQuh^L&m=t
zi^we=@?(ouo7=c_af7jJ{XlWvrhNTK{k*~2HHA?A!a|8ZeEfK!yLb7b!uC1a3qgMA
zysd?krSQB0e|U2NImyR*g5JwN4-EoYYrH;d+IZ!A3kn6}p`nRSFcbC0>nn}fH`yne
z3U}3#PbZHbL-eM9=rW`40e?ibi|*0+7cz?RdUwx~%1>hh*6xng#_Ls#yd(ThL9bba
zb=@8C)%n+&m+)+>w3>>eAAzZWTMlk9C8d;No9u@!6exF_q_9-aUwxqT*_a<l^iUsR
zvz1yz@MIw9yS>OYW%h#yjn8B`9;Jvn^RRyseIQVo=QB?Y#9TaKlSk1bz3Emr^fw-m
za)h#CF)=j~Fb4QS@;fDW!_ve^;my(+HumWs`u$;-2O3ZJR$DCNP~3LQ&629h-c=K8
zr}K)UN>3<3&SJBPwvZYO6DTBEOI|VBwydu04TO<deC0`ZK528kcmP?vrPfceY`Ce`
zGuLWgX|W=iJe$rOwnyx`{46=J`qL^vjl=G^puS)nJ<iUn)fKyx=N2FgjUNu5-E;l)
z)wf){tF$VJj8H3f?mTF9s+n*(JZ#C|qpI$J*gc?ZX(N%$t(mZWraf_CeQD?Hqh-Y=
z4#{e0`9{U7)!V&^X&<|9R$lS9`Raniqgh^*G?#GT-DwiPYLnL*(4iA)Hon(dA1?gA
zjJ*e7R8`tHo^#9G>AfVG-qYJ;X3~2|Cn13(^xk_D5CjB46h#q4v98z~_TJa-Ywx|U
zZPis*cUQ<9zu&o&p!<IN?f;+2?dP7kbM86MdFt<ZEwAPzz2_IAiWdcU-x|?rZJFwl
zS=mcU*KO=lo2%CKy!<3NXYQYE0VHr4H(^|ASD@WA<Ii;Cnfy?lcg9Mm)xAk^`b|@W
zr=j;%6qb)npY9BW4f)vs+zt&f`(-)k#zE;p@gX2&wgMq@q8ypbyh+x;pX6ld40a;2
zbl+$Og+C##^hQ}%`f$eM=yNXso$+mWI)5hXOn=V!6<SjQPcepkmq}dEoJNq>xeOj-
z^}xLA24eFjX5;+5=bYe@qH>N?);Tj6rXqTi*^!>|<$jg!U4M-DU?c+=HED(giNDaX
z88ab^Wk5Y<><EhB1S`gpxX6iISef(=*c`c-L>S{Ej%Iz~ae(+Wlw!OS?gm@rNXUTC
zU}@wFD4MQSE+?->ZyBuwqbmKa2~mDVk<}zu$8N<puxuWqg&1dtqu(#HgM@?KfiGjy
zCac1p7G_yRxNj85*dbSfM75)qyiuQ>w9L-bw`oQWF+XgW%i~{qaJ|_JC7QOScVSi`
z9ANGG-lyr+2bynNb1E_4Mk3!dx*hhZyWxjq;*@%YfBi09w$17~7Fj<quzu~N!8Kf4
zD94#I;MaJN>oq64^4(0krgk7mf1N9;Y`tW$%WR|PTcbWDQTDpZ`%DAfz54#{Uh+hC
zyl=qNJupDuifO94)^XLUe!8;1BeR?==^Yrj9#@|4@6Jlx?5ybSeP(B<?mz`MXa2yx
zyys`MC>6bXQgk1?LdKsvaIhwI>EW{ML$|mpJGyVluILEm+!QFmH61EC`|N>vynb5h
zk^`>n?OCKVyCS=|o2UnzrQJ{VdkedX7Ekj(z1`j9xxwynE)85`*BfiH$hG|)-79(n
zdEI1je|I;1ue-ND>$`s3Mc>od1*MX_9SLf!3HnU0+HMMyzJ71^3{HKx+v_vO9B1@4
zBwZ@^l;-9s6Dx)8j)}ZxPH`+>tIO8dOr~J1&L;3huJ<hKU3r|Lp>vMCNM(`CT3c4)
zjACnW+Id&sbsNxJA0OVcVI$o&!)WI?g%CP*x85PZ`Zch2{lKJEtA!5}ZbxqKpA6Zq
z8fWRbnn+Mx*`G^t68>&_zQ)<0vy;Q3(yyeib!V3M-`>&Pds8>SFyG5A>+Zj$qobcZ
zl`yVPJu^dD-%U1jbUVwR>F(~=bfei8cXYcFnk?3Wi#Ho`4wR<e;OF)3YoRl)`b??4
zF4{-_<t**(zUAEB{UPp(0|miDtZ+YD<sd6|UT^Qx-rj+0_Vvy4aGTHdHSKhL0_=|j
znlrnyoh;~f#aMwpvINgW?Nj>T7hJQtuE`k7rjPaZb`w=E-rn<lecj}V?%v+)UAV26
z7&SI?SfXtam~5P6Q8#Qwtsi&0eU+c|X8XJed#ty)BbD1UG~B$PTa%}mwz_DlmS~GM
z4b50;QAVX~r3hh=>EI4X)5IS#R)A_TYV|?JXRzgTk?HWr*g+1G!$8+O3S7-6SRUI9
z1R2Xy8iEAmc@DG%^CnV&U>!k-K^#sI@+mgtSV?xCQ6OwFqskMkJg>4n#%HnlQ~uyE
zy(c?jpbWg$*p2dMbSC{hv9mn6N)X&|*J!2kyvkTH`N_a!rR6jmgMIk7fp4{e=zyM_
zkXJ#yPzxv+qjJnAZ|qysQ#L9dlYfEtz`QCXFn*&?n-&3W$j^%$dGeF6*`GOtphWty
zv6k&ExFEyx$fXcIoEBdJ&z_#zLB?Q;k$(kb#VE{stOO_&`#mfwu$~b3%Cd)(Yh<m(
z$Y?xJYI6h~iZ~;MOh80aC*(Fp2n9O=3n?4j5==C<OVjAt^#0Vsto_l#u70=KohV&c
zTUD*_*avm3I+fOt)f})|UAiir!m6+ql^V6VLB!c{jZw8=sSp%#f7GRdp?4u4?JXNN
zYm5M+*J_Psdnn)!XC>@PDM2=ke3q+)<AQ!!W=Yi~B!a8qE2<@xNoBIxL!@ZRVx?sc
zbU7_{uR>o~S6HMd6?78~x-LSES#4Tg9d!UmTP(60L*;~AqSwxX>an!VoTurtNZYrn
zGbLW{Y*JgeWj4`_2X>gOFqN1%fe2F##yNtc!0Y|9CAX0NDvF(DpfGA<ewO&0sEnwS
zUz<Fl)=^{%51-r;-0W17pi`r^Pq=ZuM`4^h2q==pjg5}Rw$uw!gy>>^emB%sI$xfj
zyrpyAL-bIU>9zc|^&?mAq2DjrudmQ+t$7!RZKgR|ark|1{kzAmvl31WhWtcns!%He
zq-S~SNrDh)70Ap+OEBB7S7)nVHmEH@xFKKQaKPxUFbP4tlRHxD9EDa}W^Sn>R$s5w
zs%(yXG%EdVVnlVBTD#d|bs5y=kjmvTtL+*M@~r?GKU%-bKHJ6Rl&Z~UJ6WI-47}N=
z3Td6WqM&fQLVC$)?dJkb#vHQ#mE10aS7nJhm4++UM!g7)<0nlv+6%2Y*#+%f)9%C^
z&KT+SM}?By)>s*5ud3IQtF#j&Zb^5&BrK7{sHm^@Zvxw=Q*P5M7Fx;6ib%)iP>XTU
ztl3U9YJ-aYOQBn-G*3{D6Or9Q(nbokf+Xe@s!Ta>4r!?_@Oew^c@gvjgzqYJR%dp?
z`+^`4qdB6rduy{w=1sMAcn{jlTr4+h`t38ciqNcqpwgo>bQc#{nmVQ{JwB~Aq(n+!
zizkadtG1jjAP59F%PKwhZqvw-Gw2TswUIo5&s7OS?{X)-{hE+3>75FNrW6)8ZI*{F
z?CP2;c1e=nOP(wXA^uq~S-(^iXPa|rdzKaY0m;mGKIZ>_m3R|;{i+ZHI297&Zt!=P
zXWRk{_>-`KzXB`x2hg2;!#w}N(Qz!aaumzhM?#>WMI^?wXHuF{rD=de0^N}?d|43T
zi5*#W7Kw6f+~R`~D+f);d6h8yVcD>!ot+ZFv60URDP!l-{0pvQWV5K`gv7LB^7%Aj
zm5DTHgcTGR3=<<54$u#jku_$ZIrszvGF|{Kf+nVSQ7BEai6Uy^BT)xD-B?-45h(Sh
z(QiO)7;$pgg8(amD8qO`h_UPpc1rRI@Ne-Y1oxl<fb>`$GTkKr?7_)V)(}_m5a15+
z(^wQ65dUxbQ+7-{Z<bMQa|TRh72U<&ur27R9-Lh5iJOtHpr@j=EGa}jST%6ov}qQS
zaqF!lW3zUWRX<;+jKmL=!(C+AlB~mS{;QMPqmm$H74(oNf|=RKDqqoZ7V(9fTZzyr
zsjUIxvj25jW?{~(K22tcJCa{ppi5mV@t%m3sZ-dqc%3!V?$l|D$>|ksHIaZq6%bl$
zr)9tA_H-xpUO?+0fi0<RFWuJ@Gnbg#G-_QS?_WdiqxSs#yoN#gr)lPMo$-FY@P<6(
zU$%xa#jAolk=(-RjGWV@t$O8d?%CQ^o&RuG+Vcm=OPZ`{i&OvOSxR1CRXg``XF*Hb
z19Ovo^oS)aI?tP?b2#qxxMsBptDZg86jFWuere&9HPb_T{l?pubsOvK#m>G<FYR--
z+H;KE%WgNG+i><H`ibQ0@VKZ;s}QRy(MG>zc<j^ElF#nF&trGCg;id~C5EKCBoG!X
z1&irzhrKozTyw_jYwf+nTBojdST*NWs`OTW@%T()(CBh3b-q4Hk|sI)l41p)<)1<i
z8Ct4p6U8>&<gx-%ELCz#ebEM^)^0Nfy*jCeUSa0xPbAk}Fp)1SON1XOJiMJ0^U|`F
z4=&`oP3`;j?j=hJ9q&v|ttRFNA1rD}#K)20!#_QkTUM9);J&wZku4qjd5ONNpZ`GK
zxI=5m4@577Qh$HzzAK&i6?11*ZJTxpdCZyAUNPlRxa&f$EN>gcr;H3E#_wV2i1-b1
z2zn5ST7q%RvK#bgOqO#svlyOz&<k9R7#;L~xcWyUNoLNCl`#)dKF&r(Pyvu=OFYE9
z{n%{FP@;hU8I6mGV_{>J#KY_gTs+e=wGD{R0p#dG$7jjOzzcy3!rd61sF>hB_zyCI
zz%s$0iW3EJRc4$J)A@U47><mY!jnMHD;>G{hoh;XqgU)0;*(E4e;4=cUGLsrb6gSy
zl~UM!Asw+O8@Ee2F8bFE<NNP^jDDu`6gR6%xC8X#hV66cYXWbqGit6;n*qTvqV9Ub
ze$s(l9o&cBR9gVQp#lc;7ivvze9j<`PAv!_FRU)YM+Gi^(&F*+;F5dZ+B#D+B%Y0A
zXGe?Bl<&H$VSmGJw}nu*<Y+iKNx%3hOz?J6|NJ)RYXy8ARK)wW>TB)iKNNkdF>=Zg
z*LV3pD4_dwe-C5LU%vgCkfN`@`OfD3^80TD@h8HK-0*G54?lmc(b*Na_QRK=_?__2
z?|7r_oBUMn-?cmsD9JBGEitIS&SC!RGZCM)M0^HO+M5wk%<L4*(UrZ36FPLp_}~O<
zLRqE8cq;=Z6H6NmfMeR3QM#K*@{Hs$5*)=VO4lSG;<Wq%*#Tp$#=u>Wzz0WW9&h>I
zZ2?Se$3ndL({fpietBza%<2*q%5a=~kqDOgG(JoIj%c(lUS57BPjcSayobJZ_~<ut
zD+@}?E0USx7cbt@+el*i&boP99&^`PEn#?N7gem#6hMbj+t=PPZF;n<A!_ZmPMXx#
zMzk)sZrA0O$gGbX6_JUiQ;t?HcNz_=;`4~&-P4bVhphR6H@Cd4r99TI%*wK){K2YH
zV^7iGgbAlwYO_u7rIGHMw)Eho6WV8GI_t-kCRoxdZ#ajH6Qw+-lx2$^-)Rr2lA*F3
zw<pxC*XJplYHOPeR(GDG18Q}bmcE$!r*?R)BAnP&RBi}s_3=4tW=@#Huz{n$-Gy<e
zgVtmgi-!va(g=I$uz@u99LbO;8>Gw)vxXmgFYF}R8yGn(nJycEvg0!5MR|^qhon3#
ze}C(C>BuZCT@ON5b3VO0P@CJND)MDpmGm<hcpV62rq7B<_-1j&ECcQB!)2iYUzjL$
zgTW~I(spXknXV~Xb=51CM|S=zyA_Giih4edw)&10ca)cRbd@FAgx+s6O}SHE<jaRj
zms-ufBAtR<=zue$+4nYIG_|-mmh1CH!_GWk(b@J#dx!EDIDLJh>yV3^aHnH&Lw#3H
z^U3Bym$0O~t)slG3ju<BMmfDhyh3~$kxDJBh2$Qa{^9AMJU`D82}4jqQ^>->Sl1lI
ziI?$8<bE4YcYPEG-5BKz(v68VL>Ukqq*megfx8<wt}NEdA<oO3`X0e^{$%3*6;n6V
zPCM_RA5YCGBkef}1hbKx#@_5hZGGz0dzpbem++}8cd?o)p3&Ok$c09)xxznV>UJRz
zTu0{q?PRex);g}NY+NgS5E<a;-IadZDTd{PQ!bs*yLI)s6}e{;t1p??v7SQ)>MQPw
z@`YKh!u-^1t5_HeX<UYrXH;~}+Ffr@#E%f`*{t8}rHA-a6<*{rPDfhcH~jvwl`|>v
z#CXTROjAnMW!P|++e0n@-(;qDWuqDrCJ)9dDMiyCWEYY@Nk{sFYy7Devn9Jc7|by%
z^p3Is7hKjd?v8C+@962;==SDo^7D$+fckSfox@ryDJ#g&$tkGmJk5KsI<HgTqpHg*
zsL^yAJBwRdihImmn)=*=8bh15y-<8HuQ)Ha@ACQc*AEv?IXxE0<O`Hpz5Oe;-Eqg(
z4HNq;Rq^2sSu<y@9-dKWI)7fX-)b-pTHF<yKrnm8C0jNhK78TAZ5!Ku{Wh=K&}nGP
zt!pgkv5(i*<wfgE?Y6$+#=3$YbC0%$VWIu@nB)=fMXbeo=q1ksX5y_Gk09FZZD=4z
z`BCP{5lyhp#P~qWR6tF}5d(68J3N|o>>An;4(y2-RM5bAVXYdAGYDpOAG?NVwLi3X
z%#JKFexDb_5AHNDhyY9r)dJz59B%RwzDa%yVE52F0hyH+dmVD;G!SF@DkjwkvS-I-
zVs10ad?<^ei=sGicEBJqc9}&;z%M4u9!Y+|U`6pz5vIqJJlk>}-!@c3a!Mkxc)<RC
zX0cvhn5_$CM*HeEu3ojeu@8yE!rJTtgP|z%eOn+Aixfw>+Tm?a<ZgS{qA8QsbA12{
zS}}pM&X&s5)_2;<bn6rIT2DSr6DkTA!pm3Zx6{4)i*{5!c`0waaCKMDYUGFNK-~66
z7uV*&Wzs?~+p9~O#Ve+l<q&)J<_e2mA6;qm7lp{C&F%Rg(w8^1EiB68|7MR|7|FdV
zy5!6=gtPay+ABge11+SfDASsGO>-zqVKnO<k*-38I-8pcPjrh$J(bH=EAq#O9R`z8
zkrisX7DbDiNXtM?sKVa5_u@K}r;%iKb!9eqOmzo)GV^kW`e#pCxx+GX-(8;EJWn}6
zHXB_IkAO>v@RC_Fw_o}f`d+KJW6Hzd<jhRj+eu$Nty7L`aIbOGqFUFc+3U!2@RGC+
z%z5o~nj*K|wQr)uqMpC9zuY@usoXQM$+5FOQ8H2p1O&!+k&Fqyy{F6)wQ?Te^xQj2
zidc`(b2!C%0rU5PWRssJVsa-^L{FGV@Yb37hV>JWdRw};u@TJV7<|$-j`}OH>d*)9
z=22_<15$}Y8Cr$)G8=>voIzhiSy?lJLv$y6lv#$-os%aAyvW@dOwR9uDaZU)wS(7W
zPFklnO;!<&^nP|-UT!p6UmhxYw1U@KE3Dn+>e|BQJqQHws$I*n9uf*RZi(okd0s9j
zZ+Jm6pavpsVXLFCc%gHH<7S6>PzO9thtis(Py*h}&Uq~!pVF-M<V%YF*4w+Llr~DU
zC+~%VeYmXs^h~pcY+f*KoL%RPcTMs7)SAFZRE$mDtTpDi%8XO}c8kTU<r<5|m%(ti
zq<pB{TI7S`)qPQ$qrkd2vb1ml(gNk_V-*TzoZoQD+agg(#kmo!Gg7ZL6>98P28ucn
zPg1Qi>eQu5oxx2^4(?D(`Am2SRt&2+yRXyO#_~&Mf`>j=dRQDm*6k(0(0m!#ERU1#
zITcsWwR01=$=oc&XszZ>=5}-YxC?-ya6NY$cONHvjYtY!A#tPjHVpA}S77f)rp@f7
znb{j<pRt$0NJje2;{`*mlzHql=f$W*n#Z=MwQTirUP%ykiM?_#5OP<^u)w%+0;3x=
zf;p_Ae!TB7-wJdR_JyN|f4G27SqhJHd~2juhUjs~vUvJ#^vK_zz%lkHahbh@rmqw`
za2QW>fk5kHe&Wm@4_U%a6#l(BN1_zJlRX7U8QMeM8+$%D`lV0FkH(ryeu6+c5DM-$
z%-$h?<WYcL&DwU1{{(#mEV|s>W2e&F61m79FMy<`@0AH~dN|-2)1Qn{9VV`geUO4?
zY?tw0kio|apLilXS9-dY$Cm7&&Kd#FCzoYUEjJCg88CwIzO>2wHnT**n3}!`Yw+#t
z9#*{r!POY&@QQ`cC(gtS%&{;H4^xh*9HHVk#&m=0vI&=Y{EW!}$T5cE(IksQMT+AX
zqSYXc$;EIZwrE*a1ER_h>dImUV+{I+eGiI0%qy<bx4nYIE|nA2r{C$Uh|XB(?kG36
z`}Ac&o!v9jTl3CWox8eM1zKhWI!_yjWhcw6g?(O8JKogrkoP%7txE53s!FEAt6VTD
z1+`@>5~`Ry*ZfUmk~BOonF|b_V6n!dYN9_}oy^jm<f$a5{*)T7HSu|eUVLPhHIQ49
zm*X*t1`%^gK5`N(MNO$jVKEs>RLEha&~rs<DB3hY2@{o^m}6C2M2$jMs}(9l<Umg7
z#0CN{I)y<{mLY|gAS$)hNHL^UYIEULZq}BGBC?icn<azJP{v_gi@KVyRxAtXG`UJm
zl=uvMuF(V3VW67?yjrc!C^;-{jTjVpH>XvXX*AHpI`}}oE@I=(>^<VT#^LZf>>j(L
zD53Rv#6XP!zV)0YE9^Isu;?n(WM(S^F<p*6VlrD4UZuB41J}&_h*qexm>tL^6I(j*
zDxFIM>+g~Va`H0enkucu9XAKzXVY(RBH*lUy;5%qv@iB$!pSXAf94LOcgw`heX5ZQ
zN@_~WVzc(RrvOvem^1ZApc$bDU6OT{C4BNFZnd`aT&@3=Es{wPlxB%jYIuSmC2KZs
z@S39fc&TFz*RL~c092#V1{H8;vAR8i3IS++A-zxC;L=F$xDxJ_b`w|Wm)x3E*ktiV
zO=d5BQnV^XrB6|2HQ6;nwN=jv?gEulGQnG4ZPRG7I-|(xsg{b2qFP}SgzdG%chEI~
z1@zU6troYCC|2s=Iq%nW`Ln0Kvf^lT{FY0@oy2faY21@7YRy_HTNf*J)lF5+Qkr{I
zeyF+?N+JP_0jWL}s#!E;@Y@d<ym%jn7g-{U?+jFH+eon4US<f;ztUT|;X*_F;ae`s
zjQ0g}4O5y#bEVp>LvXzcemIp{lTB0=^8g}J7aA0Lo2JaDw24BY5g9pkYE3YIMj~Hw
zmKuzbAy1_aiej18th6g~wGympifXN>gvvBv5=4jKYUUjcHnSll>hc4;74cRzwoIkq
zQEJ>4r6s7+di5qmFB!EyFZ8S$wK|%kR_3d<fl`rPFnELOEW6!_xvgH%hVzwSl|CN^
zRw<v;Tg+Z%KGBo}lun1PD4-9ER;MRR8R4~cZZ723l^4O|%HhuSdTQ2pU8K|!(HgBm
zDxRN!blDA?Sg$otpItCX?*^`5!yF)NxGG8w7In7S-7u`OEn0Tj+nFN|x+_YG^JiQf
zTrqRGJv$kx*>lKKrv-kL#^5PHcgYm8?!6t}Z93>m%pGQjXsZ#!1*QV%MfndjRr;G1
znrug&R;LrcunHO|P(pU2E;^s{2$I%1H7FtL7OCdp>Fe%QU>qWRu3BT^ki;CBTi!B-
zeHJXQYa9p{^pC^%MoO*bASc0ldA!!ii9&R~#%xd-#d5q7r9qJm7C~jS@&K(vE|%X^
zl0ke5I<8YPF3xxWS@-^+b<RjrY!Fk%PmRvJ^1Pd#bHSoBYMJJz(q*yE;6b0U9lIe-
z=b;y4F-(6fD~nc4*)cX1U~V>J-XHsnRWOEw4|?mc{^2^l8?^S1AIQAyf#gX~GAKBg
zCC}N?Mt?YE(oNSDtyndXAKzt<6qWSq>W*K#`R3ctda7%F#NRidbm|hi5}!Hbt&NO#
zmY;NG(G0qIP$3{qR&RTk&|Gy&#g&yCi1krxm)X7Yls)b4Ywmjfsd-x0M2%MMTvu)A
zZrV|F#b1|=oTReM>aBh(_4Sr52Pc-!%bh#u?>pt=-m6<zPM^L=X=%N->lw?@&h7~l
z0<Amt73MZ<d+_SZuDW<-V{4OFo2g3O<J0RSA!CuSc70qwyLos2CEMt??WOT@O}0|K
zwtUL97hHdIv$dTB7k0<uMRh&RbI*>M6)FjuIN*S31FIvQ^aHxZov6%GlewyecU(PP
ztgByNG$&lYQtk8W6%FI=zvH%O&%>_<24@-zdexFmRXcg`S>o~3B2%|farS**u3Niz
z>G+Ef5VCh;-h%Z{_v}wLS5`DleV#tB|0U}=wUJQB;wv*q_QHX_gL^NUa>4%9?dO!F
zqI$1OZ}c-BUd-_R_Nuf@I1d<zC6FQ?fxScSQ_zy)^|O~22I$79#3dhFFtev&_GLsP
z)_IU%5A*#W3Z2+zGkW?U3cyd9Is4D+WZW`Va<u%3I{r|_iF;4%*kR>hES}6tq|YK?
zfZdX2rlk3q9{NhIW0E6lN|q^`+gm&Gkkk-a>x-V@_wCE6Ec}cg-@DaZgH)6jk0Zz9
z5lzI?QWy3vb9r~<xE8v6>wSS!0?w`B@+l>1>=`E83_5mxgD<!}$o@|adJ#LY+#T2+
za4m58cZ7s|$0~<ssVA^0fVDC@T;e~)kE_Acg1AdR-kFK%0SWt%KttP?=~?Xw?+FLC
z2E5C&{ny^;YN`%-mU~d8Qvd7o-L<s?gLReN-0W;i=6r8N^_}GjlBlcmlV6oiXMx|^
zxK%Qk138l$8|kW(_$+%-B0oQo@ED8obqk_J_=9RIuaqP7;&`H}NaxODr<4nT`RT*u
z{QM#z)1F_%bEno04Aj>44WLg*88^_k75(B}&{#>(RT+T!m4t2vnHb_Rgh~O=-h?e2
z(}GB^0FI5tOtB5SE;G2ya}vRmlHbCj-IL(6@IulwiP0iOe?>*h;>E{17B603Q6bzr
zo<7ys7{V`jYJ5Y;=5ldwx?HwU!*i)=H|FJClb2WS3B+OnkJlfI`Mtv4=jprTG`a=L
zo6m1beKInmwUz5n9c^vpk8s``t2Y+&T65^9ZEdp>g|S#+BA!!N2sJYFOgGS5ghS$A
z@tYc1FaN!ljN(i%{1YT-N9U;}a1jVH))a&kg6o*Uj`79vIYe~Xxw*X+6}`Qc72~;B
zfo0{M$*_~gwC$eaghHvLYhBKn0WyUb)=b#+V{A@pEz%Y1ivoEZpBoe+6+Jx_6<uAA
zml+h+OdXv$VLY#-y>lWSC3!AXn7T8!BN*d&K}()j#EsTGMHaa$D>D?+#v1w5cMkTB
ze!D@+6Pu9>VHa#0*T7c!O2#`U<^v{)V4S9jGE^#zzO#2?h2aicW~-D7urq9rc|x*j
z0~9}f4+u4MkodK7D3Bd8QCf<Ta|N?$fXVT!G?Q&?Rs)lw*aq?r-mu76e)${Fd}Fe?
zg_TErQ0FCO2sp{X$VPgaNq-HSU6|{<{A?&H%LlA);o(J1v7;zlQ@W)?Z<(9fHMzEC
zvb#b!I&NsDs#e>08|MYU+pGygcJlcC)upA*-9sBHYildAmD`r=o}6@QXI0nq{IGlW
zCAoZk>%_HnMx~>}VKS?xlus%wZml->>gFxnC!T$Z=<|QYb#EHqIik*XxXRACaNVjw
ztvjB)(YI{-87s;SSxSX@QQslIGw#l}<tnpnkPiHFqc)W}8ZDz`IiZl+AJHzTX_zvd
z6qt-i+tH0cO|9CMYapV+Qe8H+B55>;e4+pO@vTeETIb!V$|+49v5LuRWn+#<Br~u7
zLF+LXL)q4ow=ArTAl##}azcEK>CpGf&pKRK#EG}<SiLIVzi?clD*ofSj&@UauBFH+
z228pc!_Q99@7S^J@a_g%xKL^Qg5PiF@`9#ZqCge`XHhN>|8rmgSnbv-qhPeA?jF~-
zY|26lzinD)FZaCNZqGn&jT?S@RdpFTo}q+YZ3vN)^X0r6n={TrPL>;C6MsA7W1wk$
z5A1CU{JS8-z9SRhKeURhM@0A*vXg24)7`?(cF+O9JqE)`%qXGsi~_wZi{9Yvc-^4e
zY50D*|43LPz5@a(d*h($=@K|jI*@!IDlun8+$upu$ZUD6Jae;-o^bnPmU4V$Ij(uR
zB$U2z4~&N8UhiOCI*dCZ{=p<2gJv|z>J!T)REe&Pd)N{UCWBZ>{`A+gN2n%ASn<NJ
zX38}>q6t<I&knmc>SjUW=&g8K=sy`^up=ht14AL$3}ewGR2sHe6xUgLT14Tc+XWAf
zCt~6;g8ihZ0}qa4NT(6FSfzK^7OfbS2Pxo$CA5xpw4fc$5KpoigGn*!2*aL^0?ah8
z(&!f+3iVXa963+b63-OK-4D<S2KxTyL3+)gYlTzsl6~RSc13i8H9yhtX|X@Z4PNss
za)p!t4j|g7Y7v8VMvHEO*_4-;dF|lVlba4&vcLFL{e`IJtW##a>1e#=3A)!?R^{{;
zMpj5_H!>;aCa2A!Q@Hu@f-;*;EYvnhzZy2@+3A&jQdDxrkW?^ELtnQ6VPTRzlNd7{
zo~<qRHu9yHWSR199?1;VpUL4po11A@6b1>h;^<YrOtUr^Qk-Go`0P|MU&6IW4cR^X
zc<FgkZ8K_+4m;F!a&c(hgh-+=94-GgLR1RD;Doi$nuTPKoTO4)&>$915x)Y-z(@3M
zuLN^H((NF}tIi48rYtnk?SXf+vrh75>y8J_Dx*Oa)Nl$>DROFW+~v*rMTx(#+Uyd)
zbsLXo1I^Qpv<4bcb1-1<n-HCJvpx_t>dY288~$8ci%Fx>DDvkE9LeSNnWgbE<tBbs
zj@1y1s9m~<OVH&3I#rpiYiVrE^0Zp(0T8S5sVmwxnS|Q2?~eNH^gG0M?*!&e?hFE{
zth7LDHFPV?Sz4FPs#EKUE@%~O4)11OsfIDw3AKZ{h18IT?VJU+L0)6j>D*fFW$^yS
z-vr{R5{iUEp?+sVOuS&pQHnZ)wP%)UMdo$$s-uyb$`^BZgO*dNd?r1FEQ?Z^87(xK
z9hzdn*5lOblxEQ=S~)}z5{-p-X9YrKd(A|Ww0aX@VNI6G9QgGRpOk=nDQRrky09x5
z+iWty`<z%}kBK&qnzz*;-cO@b0{d(ly-!*LoXtQ+5puTljn2Vve`7i{#E~jwwhc2Y
z#+<DCk*BKkS&R&OIIUoUIl+T0;!HP&q0SuUy|DDMkF;jGTcxCzs62`hK~%+l6$Eup
zj>kf#NsCOGTaG={R#w)=7VaBB**J=8=?<r$2ofEa%^9>j&=?Cvm6cPe1)WwSCf&0H
zdYQ^>>$7PTBT8{31}RQaU?EfVYSWwzsXghs+O}A<N*_Hf+ofof1d^rC0~ET(sG&t_
z1mFOb0FTOeZFR=1-{vY>#HrvvtZ0McjM|Kjj0wn5x)OHne?wFS1yCS&mh7mQ7O=3N
zM1UBm4m-vXP*<a}5)y~((&!OWvJ*uH%R4B04MkCt1mHG*LJCDgY@an0+BcCVDN%Nu
zP_)o?`V>Cx@cyjA=ib`T^qus%y3@9t(=usQkNvcb>ylGfS6y-O_ARGpW%;xp1&cZx
ziHVz~v0IG`=3H^-vK2#yy)*pu)=#dudgQC`=<`C}(OGWpBkMEIys>WUjO_%8+5NTC
z=wE-Nbf+6BfFpl>=Y{UthI5?WyPkP{cF#?>y<5S}q)*a%q=%};=P_D;*1=6#-=9)u
zJcrDgRc%$qwrto{U%GAUrcX;bi}Jt=jWvf!M(XT_Izeb_zWe5DmQT6)wuh@)BEwzd
z{zc!Zd-7TSzDjz^u@!&Lc{o*7R&JiN==|z4zu&fY`Q_ZEQ$LT#asm(SKi%JQKv=lq
zif2yQE)~k}X#Q^|#e3+ZPH<Ma8HE|8;C-tz>g8wv@Qi5&kaax9$+DJYI%>xKjQV4;
zE(=Nwl0CX8h$G|oGmJb-cnxUt_eR#<<UeN@K<u~0!%5Mo&-?zIeJ_)nD#G#9w#|9T
zlR{18od$bzWrwY+vCr1uF>si^FqhcqOAE3WMi*u;4zJMZR%+|l8g%P);$@x3*L@J!
zzi{5r8BOyb#5iugiIN}de|>s$WB%%TF}o<UWPCg`Ib4%jJFEFYy0@RqqZ=o9`(uNi
z;nHD)VTxh=OoMK=f%Vhz^gYEg_z5e43FDFTEEQ#xWh7+38h8f#qxA@7a4-}=#;D1j
zx~w&9mMBtjU@m0L-0wemtRdLeK>Tp1T{faieQszrkZ1Yp20JkxF(TVzB_*-;f~wTq
zDsIMw7hG^*>Y_?Rm9i=yiyljEl~O)#(bLK#84<7lwak8>T2WK_>$xG=+$^Dm0Shv!
z2E<?d$4~Op{be8_7y7gOdVd!dwjGBh6UzqWVaUC!=p*7k#LF=j{dm*Gi2V3Bi6HIG
zC-b3<$l(35w+($pR8~4iBYYC_5cJyOKV~#H&tMCkbY8)+aAez_6;-)Q)<1gb{xj>w
zP4pLde(o)8DX5*jl^E%KeOcua;j(o38L4l-sWHztT(a%JqK!|VeaXtj7u-Oz02-gV
zucU7A0kSzpgJixz#x@l)GUzyv&}Z;I@{pro5uVm>l65iYaBMiUN5m73J!uSVkIY)j
z?*dGbOb8e$P4i&vM=?s0U_Xm}Mr(lGjVaCLN<|b#jK30Ik25Q>a*(`hTc~k)<Bnz3
zj%BXA_FjL-?!F_Zca8i!Ii}AED}xi;xdl>WZvP~Hg4&WfBh$G!+iEM+w@z-@wrX;P
zPv>%k8-cLoUKl>=vl#=vz2U&IpCVhmVnrz($KP9It1I*!oOaLo<2b=+ym{GMN4YH~
zljzL!G|=s4d&z05+AEaAVd14Rr@wUXyzABzQWNf~LDGn5Z^I%&GU4_V{G`NRDk&Jf
z<<e~?-UGj(pxj=5fENM#9?7bc4wkVR@q8-I&tRJ6?rUPdl<fTBGjcXflKms3{PNVu
z<)nOsoJSMfoRMPMLi0#oq-1cgB+Q<e{7kifB4LvA{PXl}`re;XpYmUiI7p~I+1i?D
zpzkyNiu~ThWQGFcs#?Y!0a8*SiH0325>=59>s+kS@qR+`G|2j#B&26V<UC|9YLY`{
zMH3LL#=J~Le<&&=DMgq_h2lX!s*-DC-bnIG6zyT=0pXCqBq|iU=%47kW!za&`YnAS
zN=k$^sa@OpF5SL;`5xMJ=&{J|ISr{lzkK1eWn{`z{pFLZ7u2@Rec_o!Pmx9R>+`4G
zdk7g#3+RRPS)O}#{^WT?_a%Lu#OUj14ie$Id;fM0aeg-P<5!h;esal`zb@hV=@m^c
zerGe$6{#Q1ocY+LdAB6<GULVF2>=F))9iJ&kN~ax$)P#936GiQ?@b7ox^7XyzmDsm
z<Eo3Zlf@Nh^-Z3P2(=!bX!V)iF3$qrIRCJ_(4-bPn=?09tEd(Pv%jx0F;H(=w=M&3
zIo;NmgLYS9X6*roF#s863h;nuWz0pE;>GZkScyok^%)y6<8DQsK#XCQ4gm{v7xEIb
z$;lj8q8s!N#@45&%XsXB76TqAh|^@Tn(TuV4{SkclRq4nl77Td`E7`6N=8vFj^Xdh
z_7VDN0iaCO<iOPMhkfbsWnJ{1&gJ;)BpqGLmMx=NnqSswcS4GF6o&H}8*{^*iIJDY
zVy+bZQ-V%GT1Fzv4<GBHufW4{XyhU~{{`+sde5mZzHre<h#kK8!V526G(zTnv~tx@
z>Ci{3R(^D1k4xNxzm{8Dj^MB5R`Sd9vt#A(e~Og1lvh{Bo2!;st|uk`x|Y8;)x<q~
zHvUo*MQzoGD_0Jsrrvrh=NTGWx$;AHc)GkdZG=*C$%`-2c@6Kq7dUY+dt?M-5Cf6X
zEpZvNi>-*yoR1i~t*q6{!x3N@l!qBZBdeC}$hjAbLwLeM9LT5PNFw_)+e%TWn-~})
z^7O@HCI_?eM{U@_1)L;~q$!4v--JjCRthI<Np`0+dL&;?zg^Ug*QCsNhQ4wUU4-Vl
z`oj-STmRfCzdm<-`njRbpMA~bxihz(d}cNAUbOd(&d~mjCubj}Kd-uJ$61qf1)o&@
z`R5I9r5-FFckBC{Vq9wQl)+2s<Ve{M7wxs9SYCd`Ik(@|*;z1+f0KSpe01EQwou5K
zKN!i6#D^l5;)0X-d(ZJKd8jyhCYiHz=?gQL7Jal~!{=8oanp_DwTs_B?~Ip+4$v>>
zzH1I$#bp$~@(3~Bc|EP^s!Hu){1CUXiaapu>C-mTdy@GB_ifm4hw0Yy&Y<Vj7N>qA
z%jtmw@0Nvj(j1~=KJDptzcnKZGCiB&(!5L@Bcm4DuU2_{Oh8=p<o}XClg%+`ShRJz
zftg1T_SgddST<;Ef84VDv14}4F?u|9{*T)~-ph}c8{3ZE$F}T^vMpN}dEQI>g}3LD
zi`H-b2p$WmmrAT9<VLLMuO(z*NeZ~+CHW<LOL%k1$lpu&oRU-pTaR3bv*d29j+by7
zOTH^1%94_jRBOpwCC`<7fnAxJ7aW3~bQ1SeYR|VXrp|njKE=)3h(FrO)+9H*$Nilh
zZQOX(#*HKIZrsR6(pzp9wqN6Tcmw`u2P;C%8#ksB*jjPxw;MO^-?))GbK}OB#{SRS
zxRK3M+R=CQ5M+YbD7V>+3<RC<V4fmpA^5|1@q^T38epTvKRQxOB8G#XgfSSx@?eOE
z*<j$q$rv(&Cgo{H3MZkR4NLJDL*QpT0mI!-^9Jc{8m>H6#>U3=2as{-dU7@Wkxu>T
z5Xt-L_;hkbay2jg^>xy^I!Ugg&(YTo(0`<2jf3wJ1Gjzfb$V>#?Q?d}1y_@vk(H<N
zXV9(J(&zTTDV=_FR)TvViNA8TN^wcx%$KtjhR4)sXL)=u5njEx*56jYj=%5kg;#Jx
zcily=9=W3M?_}P$r1!&DQm;;LPff0QkABTv+fHwOvz_j^hV-0H{3+Mf+`IJs(?%{y
z4ST;>b<dZmG{wG(yOMp=dpKn6t4g=8@Dn%!J)+=jqho^c_UPeZMiG#z6_bDkttb*c
z$Xjs4wtg%krUm(`4eg6##b?K=xX%Q}Dx50;_S`Lzb7^bpfz$)S5krSz{qa102wVCO
ztc1a)reozzO=KMo_|z}IP6X31ZO<Nh6_@?UBO~41KT>Mm)ZahyH@3%?mulp{m)Jg@
zeU$HmE?xr}qyzKWzjLV!WelDZvUJEc@LFeiCm47lV9eN#%@ivGhc2IC{^@>%+A(1p
z_k~aF@wNAE-+nJ!gvbAtv2tNo&nHbiw=U}L{-nA4$#6@3<AmuA_4#!T^)2CTWar4U
zMcNx4FmNLu7in+2AF)_7w%u~ewrxj`{<@gImoM=3#@ypaH@|g+Nqv9+Zw=(10|SuN
zE*uzmJKV8Ts;!9TY|l5%(5lDwG_W?LY1X6gAD)b8YrGql?kNF(U@oc{b=YPSFyq$J
z+Gv@BWk)z0^Wj%9HWz9D@Jmcz`1=Y?BM09Bb(R&7!wn_I05jx7R2B*P(({nt7m~Ta
zYlz_&GO@AFJ^qCfZ(($CX->zklV+3;+KXHA^7{f71?lZsJ$+4E`8YFi4C<CeCOd3(
zT%+00Kw1sDCeo@hbdx@zxUkf|W7tf{HL3P!4li<bPi#8u9-qt#bqtn8h6KL8kskTm
z&p-bNf2*nFFN_QcjU1`^DUZIhY}%rdT&Li=xL}~gY<C9K!Jbzaw7xm@?0>W)aZ3wS
zJ(ZOzlY*_pg7JchWC>z^u_+6|TYP5m<&&Fp?6uj|I-7rPW0{X{Yo9x(z3m+Iso(ix
zCu9k<GMk6fv+@7tjtP`$fVf~pN3@HAG9&c@uqDntocfNQORfT2{GZt5D`?T5>EA}U
zCOVC%uLj7FnvQ$x@8>r<Ls{{`_#gRYYQE~qmU{l)(CWnjV>E<kbBy+ZP2ks7L+5-h
zw9ZG6_wi`Poj@>p724;2AWtozdVodBqUs&MBMp%#egy(2@cwNq|JI3>2ydS_17#mu
z3w|Gq;(*!V_jL%ltl;N*Vg-gg?!X-m1cdn6+UH<vj4hA{Hrkl51#WT7hLZH76G0(>
z!NxendQxUXK|g>_OyE=?S;bhK2VzO!(8?p)Q{H#TYdJdK!n!ktB9G+SkSCcvUPL{~
zP#Dstg@wbj`b{zyIx3jq4mWZdGcB1MwIcr<{08=rY)zucFgPiZ+32t(KptdYf<$yl
zWyWo>4o6F2QF=K-Uu>$VYDh2iH~KJrkN%~(sjaTMv#qYViN1KGRg)V{FWvsDdY3<T
z+n2=f=i7+z>7Q@=c-~{Qjy_pg)=Eyl{@%pW!>M!3v1(sV387C}*EV{M&Xbp%e{kvM
z>?I={86-orlRi(I4lVHAcHMzY;ik&IacAs$Wa<SA$cmbtam`pLx2>&xNnuB4MJ0FJ
zGxs&#N1q*e$otrvWZqYQ`Rr@td?@OCaQF2Sxm&nRi!Z$HHMJvAQm1#XcDt6l^r}d4
zN%HuGt8?$1P|?`lT|2J1yS7mrDvQwHgc=q7preCcUn3;RgY<ZQxV$W!m#U0;g*hF0
zWi_Q6^yR@hSQh9XGW97m)6@di!}5AfL&HkFqEFBcYbC6wV&C+Tw8&p5&BL;!tg$e1
zN59K@^Q_L?n`U<vT{63_xc#zUcao1Khqs`2aK$vb+pH*un|xh?WF#NLBUfk0I{rOp
zFQYF0-f0Vm1{QMr*SQ?)EaW-2k-jUM=>t>!wqeUTGyS${7Ji~iqHl0y@x&7PPjfh+
zCAQMRO;wR-jfUhHT=WY&{X2m@nieQRo*$s})&0PSV*JO=kWW|IvzPcD8@7d~1s|Jg
z3(xX#JqY>?3wfUWq!3o6HkG<Evs~mAWf7B8`{{?$=i>Xa#n%W4%8M~2nb3)YD)^NJ
zO%@eNGl6~+!?%$>e<StTNanr5|8V0{M`;aLjilFa?(?QzNPWF%258wsGwBFYZtC}p
z+)Quezu+@z899YMN*_!O@alU<&gX9?)%1yxeD3j7E&pcfaxxynU&ihElTxM7A}jR+
z$QkfN#<TEee>39;1WETHHQ@oos9(w~Ofu;PQu(Ox;0S_-$IFqTfsG0#PBRgh=}TDw
zS;oM5+1e>#0x88+M^uD%BPbUR0#FP0u<0Zi$4&5~gvnG^x7v|F58>``V)uhGuxlno
zT1_o~BMa4Lx)cxwHo_d~b<zPhdS;xlNj7)@;d^1!DkC5QNS6Q=qC<*DZI(EWB{pEi
zC@eWp28eMqbQqY3GC^ULGRQ|3Og{>*C||%72UH<BjuRE9H9Bb#${~M|EU-c}3WXCY
zZj5o49~PC#iXA*8a52Yr9WfKn$PxQ-><gGm9b0C>`hA0Ij9X+s4=pP1*jbCpt;#e|
zq8|wu6Ku*>swR~va@++r4m~HEPnew&ajfd}>kj*>^G*J)DJ5Li%+sB2ty!?cD^emH
z{d}@O?7){*0!`bY;JGX~?IDAjkrVkWgHj7(3R*Z^Nly#H@?dM?`*yVD7v$D8O;p)j
zYTc%Xx~f9ewGFXCRrGHYiT2`s77}}OKq2m+cdcxXWG)GJt<<jkv^Uh6C?+?(IRD(K
zbUp{w3;l5`(FoQ+U17ptsWeK~xwWZ%p^8urVu)Q?8kpa+?9+0RJKGC$Q~_1}0);J^
zndw~|E2*ed+z4~$^aZ4q66zZ2Az51@3c=EZNm3cKsGWS+4bM4V&znLHQDe>3!hws|
z>(%hUH1QT&row79IMfO&Y*@UK*9sAzHoz$y$O>z87*R(+WuO!2CvGbVtH@>aLlStS
zWF{1^CT-GC<2T#9qA_Z%DVRJtzc68|+NrI{EgCRO^SeClDu2Tg<4)z>CF*RxL|^RJ
zyB<>ML_-#&gT^YiP7J$Uvv@;w7UJg%eE|NE)EwUzRrxud+^XKz+uW01P*y)QX&NsK
zEY9gbF79IYc#B_Ac~KRwaEUXA8hVYt+<)qIi3yfYvnXV>loh%S`Ng)pcyp|zfFAp{
z{BL&4r%uaD_wA~kxuKSRMBjEVxMt+z8w=}rr@wlfKi{KqRYh&p<H=7+B%X5G`P}lL
zuc&Ft-smh{j&^l@r@qW1Db)`BaCI_2hmc$U{$V3^5-<H=WFxmOwb!6lOF3GnCeD`_
z?G`?ldv|1QuBgpi?&6gSx0+--ED4vf#*&G|P!VmmMU@+jsujXqKY(=s3<nxh2wHcI
zNX3sp^;8);Ssw60Le7_U{k0iQzzFUG4>|=}qj~U#Ujf9hjqtcT6`mGn06FYH#s%=c
zyBtvu*UA?0J2LJ8t$G9qKu^Pa>Lp+Ry_J!n!^<Mjb&Gyt5=|^~DN_?MIRe8U3<)R=
z)(&|Mx^rTG^voYlK<&him~&0~)^w5IkN@vIxiCZ;c<PMZ#P(RW=>NSPJ2zIEZU6T^
zE5pu#HpWCsCmsKd)AN^|of7DNZiF1Ar}mFLeL9yvp042kuFckFPe;B)=X70`F6(}e
z$zvKj)MnpbtoO{4FA`m*E{g_d&n7{m*JVKwoh$X#q)FU*b{h@Ooy#s5y{QK$Pv)-B
zJ9AUt3=JKcJD2tk4sx#;y?S@*(aDqPS2JdiD~E>YSA&D(D6W2lb6?M#NsgQ-eD>tY
zdr@G<%$a8n4&s1a#@?ATXD<Fxp(TYAUOBE7_q=~>vszqxY~O3IpK*pb84kos{dT3k
zQ)&8EGW1CXms#pGOJ6HZeM<cglD<!+^SVZNm8O?ez+3D=fXmkLv`=a5GfCe{`c53*
zIX;z%J*AOs?x7P^<{s>QIez3*N#A25xAo8uCXk`=Bey7xtjL!=yT()Xgk3#U+qr8%
z-q6o`$ixBqVJF)eoRHqx#g2O9Tsso_@nw?l-}<o|{rJE2Juvv_is0zue#uAsj(y6h
zg(uEE{y9BI@RFP9uEFD1zslXyo%)EocjPv{mp=S7y`S%0{)@s+^7~&s&WZcqKekRK
zo_uWgn{OUEBvd?}dXrv9h8|;c_kVhx4(MP1+w-u_&E_0TPi+2X(@S~|gU8W{Lnf=H
zr&l=(i#+ACS^mHO0$wv~C~@PK%Vx$_m`siu0BB~pmxmH(E?d{qkkgN>+17AnWj)<8
zxw&m(G{0k9VebFyXYwP3^Co*{3>4mIvjG?_Uu&>ved_RDX<=f;g?(Ko#g-S$nmn8p
z&7a&nYg$`Zyt*dA+QX0cvr2jn{$>`)HBR7<m&1bA1iellG@;X=*;yph7N!wpsA6Z2
zQkMTjRWib&-zGOzB(1LgBXyBv>Vm*oa2o(FEssmk3NXb0a;r)H5`L8U$fkq;Z_@LB
z5u-68GD@vviXj(bdnPQh4jo&lTu;ym`6l_=?=)wOhDgs*jxGuYbA#4?3w{46Jx=~2
z9yoa1O0N{2Cy&x~la3p1c~r{{G@8i@y~`H@^|xx4kS{c;zt)k9_!kL?MD{F$OYfcq
zP$}0FE~~*mPwzIkW@%iy>?e#qqYsA;E3RrYsb~It;y3zAa7yo{o9E4AM@Aq0Xg>bv
zFE@R5*PWjpUA}nnb!*n7mM&XHzQoxqY~h|r?^(9&syTD6TDD9(GS_Ogaew*CrQ)?D
zKI!e_yG7Gy$C>~9vEy$Yd@OhSM+$>p*-Ot>>PfA`shrYB=Q5q_&p(Ur>Fr8WuhOtf
zUjL-jgLJq}%5JssN2Q@pY5J#9KY%l8V~^VMFUc^VRsVuAl9uf0q+LqWfa{+qCK<lz
zqfIEIH1+h;k2{F*_FF%@?Y7iY9UUE9VP~qLgWxN59j6W8Vh5s)Ghn^#r&mY^#ZRI0
z%0gz-L`FkKb4ItUL-MmJ31iJmAgjh~Dn3YJuw1CPAX2$9<a_XqDtH($PC61~dKd<M
z4-ZdVP?4Yo9!yXsAx|@4YGE%alMeoR-s_xo&G6hz^#Zb$#GawQ5{VwA-&{?9-q}DZ
zTFG>Jh|IW-z9pDVn>I&DV&uW89p`6C^b9h8?)sP4(j$x4LTq^A*oM^0Hb?Y}Z+i@F
zzh!(npI*Uxqx|uB&Ef*07<v2G-!kZ5xJS8nQqk+LANdd|NbrLN;z~tHJH40x+xm)e
zvk!X3RA|M>TJ9aHB>%#dzfzk}M<&k6ar^F~TV}q%Y}~AE4vAm=fd`1dD}~v(Yts}9
zIM(<OlO)gHAegWxVD=80paWzL<Rox_#SX?J3Bp}0Xpv1okk_R{^xI!wCacBQ_8)uw
z4KYTHpG-V<fGGLt-Kh%x?SW-|3y0=!-MWklXZ2n{*3g$G=e?9S@s^c*_Q=)z)DhZ0
z@Z?2`lV0iHc&tnOe&;cpMtu8N^vyTOp+o%DB$Iwcob)f`HPGGRF4ztBbkV}ai^*%p
z?*mWkd*>a{nSQ!Mx>Nk(1l`Glw@nAIZHC}$!Z1)*XKVmJ!)OlUW-iRQ6j-SLiRz?z
znfHJk{aMDBkh=aO4T9<!91fD&GJ60s4!{N=5zrjS1OGn>69T^&i<4geKY616PMDJa
zPL~+3!syKy?=rR>qf7sd$C2)&O1dl<0DbDS(2s9|ed{A}=YbSFI?4TXV`}8Gbr)Z{
zj$ZaR;Zph!OEh(eK7aGWTCTgnM3(E_)*|AeS?a~)V@>MEI&wb$ILMVYdxqYncg<wv
z>d%Z^&0&W!xx%5xoIV7(a?miyl^f&=r}F5jV1(Q*E2!0H^XFf>aN(t(O%JVFb<M(s
z^p^SaZ(Ox1wRY)J(z<97yWm;6^vLYlS1wvaACUKsEM1!Q>l~}a#(nzf#o`5|WZ=!?
z2Sx6a;|~4|uI<e?Q}=!G1-a>rGmhOY{6Y^|bIG;G)o+~lNY1wR87&)6_e%y+sSheA
z_tHgVF}>iYpTzqtjEL!X%Im)=_1Fg~>rxx#eG>>*f10?N84<%i$Xzc;*=Zf%jZFP6
zob0uK*-P6%|CFZgzW#ptdHZR7V=FG&LCx$G8SJGWu$>)j)!xqNnHT-~4r!VA3%sY8
zRjU+ydbiA}4`Vi6Ds$*(XY2<;$YHrhU!8G%#?3(IybHOE9+I(~o(1OJE9ucK$9u|5
zh0JpR<;HK9VscM5LdJ)<JEmD+o>ZWHic+Q>K%k7wt1vnU8VaKnI{m*bj7OJjYzDR^
z(WhCmW_Ax#5rDbD!g?YW+y(t0h70SFY!;1TVZD-V$Bx-Gc5ZB8_d2kQoo8k7?J;Q?
zZ98^(<2d!orI)XrI(x-ywSt;ke2^BC@z<cso<v`GdGkQ;w%IG2{R=NIZ~D|T?Zelv
znGVTZ*P>MA-B2>~&=CK9d~bYD#h&<{_+Ig*ysUZ6_QHAgLSto{T570tI01{@;LD=|
zOj%3%_D{e+ImC=y_iWvIkG$Tx^-)ZqUv1ue&-(SZu3vxKnl<!td5<2J&)u^bf0O<t
zCc^opg_q8q(b964Hgn>-*~h;TZus>0u(*owbLXBsXYx?qtON6wz8P3_>>c6!%V+d^
zA{w2^zTn*4`Nx-%K6>lQ8&3T3HJO@yRr_+uGJWQrsy)W6)NA!ib_KGNrPZ<gxN*wC
z3EMYsCV@qZQWN?p?ONDJJG&Nj|CZ6csGCH_)4#Km^3iWy#MwtXx)*o-)`hIB{q%h4
zPvV!ObHnczqqG$@?Fm%}K5h^);!0$a*}!bt|1R+{ri-xoVsshnDzGNW-9?OpH)AM7
zQ53)dCYC>T305X<i6P|-d(}`qftyRa6i3m8z#^ls;)2L7#-&6MGw`2i_pt@!ZSkb@
zj@QwPg}cd}bo0RReBllHKO~;s4lH-=CDx^00Cdm~HF=({iF7YnPxlHt=RQ1r`h)Xn
zU-7`>A0;v~$(OKBJwX4bxp`7$a|17QG}ewkdN(QU?@#@_W(~P}Zh^w9UiVK00R9GE
zKXy#K_@iTsxF@;iQi;@yzx+a)ZoZkur%(UpApS1igTLOqyk@BT_MP&}FMFm<<5J&z
z!&zT_l@2Xk+<<h|cW~UuJB!IbCv<eoZ>lczH-#tFoq9{^=HVM|;AUQW3G5YeZn8tj
z<@22^v8UfiSkBg7fw_%geE*RaFu8pZd_5S}_v^spmETP`j?mOxHo`Hp$M{jnobk?M
zA2x5X2K_@|$R7vZ*gh-szxUa|Waq}F9kvDg#PWEubfR*c1XHWAz~e~19M6s(fyj4-
zO?J@4qz7LsKt<UU3|JcQB{;*Zdh#|VM?FL2VOB4kOmCvBGFZB#8|a#22_)3HlsA(>
zIz&I>2Iw!pem;~skG{)o;O?g%&!;z}PNKKK2Xip>*dxM`9Xse*+lQy@*gkFQDMz+%
ze-+15ckFmg-b<aed-qH70sMouy|a5a9ooMA<!#$u9$RyppfyuU291J40<CP9pjPsV
zh+PdsusYwW5+%LKFRBSr*ID#P{A^+I$_ka;C#ZRmR}{FR3L`pQ0gpU}DqBdQLM7I~
z8FLi+-VLf%$Am{;d;cpsKw?Mf<7=<v+OIrzuOK~ed?ZuwLqMHy{8O@!UMQ^Hw27{L
zh6IOC+c9<8)@`Z#o}rfinZj1o@(kJj^ytpEXQ=hLsqE;v=WyZar}+V1$HPh2t@pse
zR!~N?$mk&`EgT-0Gul<~?^Wn?05~fte7Q*1NL*3`<t0Iz?Nq3Mov*Y5Voe7XooF=W
za7dizTswUN;H-N^*wXsxnbQ5@zo5l715v>x>y(PYQ&vOjV`$Qh16wKcUZ(<+EIm`*
zGO9g#M%Em?3$*A4Waelm<H=+)n=B?*BEQ~E<SwY_K?RcFu%K8%*GTf1Wh~e;B`k7R
zmP}$4ylPTD#miI&wjt03Xp?1681y9;tN<#Lz|9~y2%}(X-!OymL&r>q-2h)B7Gyb;
zVsdvy7mTu`woq0xS_U&1BV>RijA43AV&ovLSImKMKxoh*I6!1aZ)cPYF$-*s@GrKN
zu!wLJMIn3o0s}#VR|n?BI5fb_aEmB?h^{ccp{jH}5}P&ULBRCq=~01SA-jpAxU4ro
z$s~rCJU7dMS-1xTl1;RD2H7=Q*2}{V$IKQ?KMnXnH$n0}<_ZbjJX}@r2vNj*B=O4-
zG7^i%SwK_}Y6tdI41&agnvx6<7S%dXR{rW*f)f~i02IJoz!5-Op+=NMRd^sgvDGHs
z53<~S;f3T~abH$xFgo#r4F->)?szFZBK(=$*+Bm#CJ#UyeK}Pm{B>FZ$8{nn!&FUF
zx6z=TrpUkJxJSIvsBVMp?v2~e6Ex0B5up*t?V%`=4ys?D!t0QiRjWP2MHb9I?hz)0
zwYd)$66JQ`)8kJ5lX2z_<lFEOahX~W6}20+t{kJJ>Ry_C2}xRtx^EzQSB_QNRMcp!
zoT@nD6BL$mf++t=9ntE1lFC*oA`4O;{QV`K+DeM-7L|HNeUVy=Y$BW{Yz`C@HrcIp
zv)W31!qs!bCapHJqRg9xtP&=(y)yMPr%l~Wwd801Dc&rNoP``sg2$#)lYd0^k~yJW
zrT>hc$;}OYX@G5{!-@QDN~1zEK?F!z@7+qh2Epb;aWU6?is(}COHbjDw|=i`0_Q|B
z9`D1s-a@y>)mF5ku!WF0^xNJkR|<b8#mBw`^u55p{n_3RQ**hCw2stDmC*j;NHZVy
zrm9ZoxT_;0sdu>3RF>2ZCAaz?{}?&EXpytwpmerw!2%&uU1>1vShPrRaOZyfajMoR
z26yN+x12T+NsDZpPL;`N9GL;DdQN760x1HetZOU>xB`?s`MWRq!Gj0P0j)}N9Z2vE
z7thHTv$TM~Q7W<(k}zqXR+II`N2bRMPcs}iu*|GJJ<?_k*uVb7Fdc_Vi^){0Xb$)U
zTTUDD97#@{6rT?ON*IK+$RDcV!^MM=O6dZSYF3fT2t)(=d413<6#F={%^iY&rDSxu
zbIkxSDzD6rEq1Aqa0s!WR)d}p0S>7=(0q7)gIT53k!?<e+98d!+_jNxxa&@~j#&8y
zQ-!ZdrI8FOi$TaA+-S`e$x^Oqic<6l9Zr?5OA+kk>Lk6<ne{+be*U?W{DA~=`swu&
z=4Kt}-qo0!Qz!h)%Kxt!IfHrG$UF=i@rk%>^tMA)&op~Un<EU@8px2AIHNSgreR||
z$`hPoA0~XW8J5ke|8cn?_4Kh%g257=WD57!C!08HVEoX&4|D=l5!+g*ZWT4GqQ*g^
zZR!+zmSCnk=r#n9o=VOj(V?O9CrvsqG<4zc@ZsU%LlY;SH#{uS%eWekr!ZS#S8zNs
z`@VjWJ6M^T7HzKTS}(oEz46swj(@|SLN6S-PiVe?Hr+s8xq!CcN^-eJv$95-QbT+v
z-AT4%IfZVbRfiALlm7UJHe<Td(}gt(0Wx|F8VAO`FdG8AF_@&lK4WCd0hkjI6-Mvi
zACOj*GM8nPNF(K$crYw}7PIP?K_nRsf_nhSEBQa{y?1~d#g#v<>YRH*Pxs`Ub~cBZ
z*`Qr%wY$<P=bTU?NCJtB0bz19hcRG|Gd4J2pAQ2L9KqPe5$A9?ob5Y*?X%A~;`7hp
z{5_-{exK@|5i22r?|Z-B*ME3tXS%!U)vH&b->Z66^<JkBV4Z&I?-QG1z~@^R_YObJ
zkmENkh!izMOH=gs)H~%MaIx3VJOP&yoD%u$!Qw8PgZmca*F0PzFBl%4c^Zb-qwNvP
zigpg~V>)uZwcz$&JL1eA<PbBxg^d<&+@4(7Rc9WUxt_Ur<{EqtGjE!?fw_L>2y@NM
zUgnOO^YOhHVV9b>yoXHB>_^nKh`OFRGIJ?&{>&ZB*)tC?Q!`&?;xo^ae{KBz2e=Qu
z>9Y@fYUsSjKlIeYk52A-aPhu}KlJ$h{tqqL|LEh7KKl5FKD27r!;e1t@Po^DJn-nl
zk3Y0)HUHp(s~`B(ZI5ve;tlO3Gc*4Vd`~eOXYOJ4&s-Z@$n!>9S#<)r#k|pDl~kv6
z^iS&0BW<^~<sBo@bN^*$kuMy${GB~x@S%22<I$u4AV$LSmBMx<m~{lRt{mRI`{<i9
ziBvq73g=Sz%ckHh8siByg_~456?X&UkwRF@r&5uEY$G6^QbK9Xj$~5-8P_;c0UF+i
zQ@Kc13neIoX>xHj8cC({S~v?A)W8-`HS&iJ&A~jF+H`*cV~$(hc`u#qej0WmzB=dM
z=KOrluif1;C79mof_K8r<RCep+)my`?j!FbkI=pb4>QoxxIGT*&~&s3iH18*@Io}!
zt8OUnAlQrW0Z5I#A()DJ+Cy<gBDb?PMKngVSb+9`09~cQZVJG;(zdw@kC6wCReA$l
z>|3!zI5^@8c{<AQx_OEAdYTzNfB;T9jzAn<16R<(C?^fTx0cIdJVV8`P@*FSN*i(&
z=|VZCN`N347X?P+?h~e8&GXLGHd!u%K@rj*2{j;3Z43#nNh23efhNZ)y&t$j0}f7x
zyPqZrlt?#AP)TbCpBm~Lubdm>jTvm}ngatHhxiL%Z6KfimUzFL0aoC#K8RZoiJ=KC
zFkO)kRxwq88zRr7J4*A!%w|<@goVJ&=JBDSkxTf1pg)q?*V!?M@oZ^iy7v-IHKRqd
z$62Bq0YB<=<&Q!lBL-o10#cddIY!hpHFQ;U-eTRt@n=I{66%vXq>Q3pQk~p5kXEhs
zDduwJ5#G?1kxPb$=N;RiimFJq&X*S~nCjL-b0^|g8-{=3JaJEIF+A7BgA0{#H?01e
z-J+FGLd!axK4+n6lCK5}>cXz2aK<esP9u!6P8Z<9-oRG=d5x`8%(okVF9+3))3?lo
z7Bdeuo~35?tHD5x72qSd@vKzsQniap(jH05s)R7?8A9$dRq5)VnLD2??;|%JldsKP
z^Yze$o9u3QmF1bN;w-q9`MDk`{BH=$*nkrDUB3NEZRT+P0GEXkyh6azmnuwKNBdUU
z7lkumSj+tbcFzR`{OgL)_>-E!={|WAS++wr;xj*ktJL|o=f>H6xdr>Km5!0qv*fBQ
z{u+1q4Iz@AJJ{CtQ15Al3CSP3zEJ3E6X$B7U`%=;oEH4K&OQ1rnQim?f}K|`3@>L3
zTG^IyjFJ#BF513`#x4(co)#>1z$|AQEA0&J?8u3}Wb_3oHc(7NeTn=abA61rx`umC
zdkEXg$Ay11L{U(UM%zs{eXg^kXTq1=Rtv8aBE7<aw&_4V`nj8K`ht<JBv~sP&3)mf
zn}lnw(Hi%w5ox@CoP&WMZ7W$rh+>z?wwrEh98!W(XJOSxCGysrZhCRfopIA}9MO>C
zcXDmH8xDrk5y=dv1m(~T`O?vwZkicf@c!pX|7E8$>&QDV&=>E>O^Kq~?Mp7*Laz3u
zBkzmP7fQZ_Z_VftxD}Mn$rKqaEUc?^`Ltk24N2JDGyS-(C@S-K;|U)TR2XOdL6C{@
z(nl*xd_}f#`TOne7w4RDS>vlq$-g9%ajaOZY1|^bLm;jW#s{6ut#j^l^?L7}^8r_*
z_cT0Mc;0sAU~>$%{kT(ZYWxeYQC6(dy>WiLXC5~SL8FET5lT0R&UvKYp>a8ZD)4DI
zRm8w-`AZKp1g|00xd4hj4Fu`io$_8!j}KN!e-L5r?w%rjYwP`iUYKSDIVorfU_vKX
z1-rn+2Jd!=Qq^yP*pfh53{@jw-bHnUMR&r}k5f7!nj4+LfJxaR<y3q=<O>8J9vC2b
zE~$hYVJ&Qim|qV#;SpjQ))EDNvfEX~lKtJ?y-LuMJ2G$j%z<IK^R|509t|h?#|E-Q
z$tsp5Yni1M>Bjk+@zt!57_#h+e};L1*c0e%%moBHaDv6qmZN_IW6+ZCJu%VxMl$(g
zR^wpeyYU874v}#!$`Li);9{{|bhN%lhjlDv5@weCLRe+9X@+U+iZP3Y<-+h{xcim6
z;P`gAaP&Xeidu1Wn4wf>7Cg_g&tsG}FmjRpD{{L{X6jsb&+yTIVUBXFaqPG3BU<3t
zM&>9pF|&~Qa)hYK0#T2Bj~yVyV(!^FpD!<Rid!F@yis4v)@OdP=_B$;=DPISXg|MT
z-Wwawu4OZX`F5UtYo49Chh;CoHX@9COX0>5hSOGO9kL<zb{0~BX<W@P7jhD#kiAiI
zL4bYhu-@4i%+o!n+?<DA{H&A{7Glk|GG`F`u3_qu4!!EZtQgF(b@Tx$UZ}YXE(5D_
zxpdQ(F*Zh}q4l91${pZ>jSrMCGptFu#^#xG_injf?fc9l8}>eFuk?NFyI1YLP>tX?
z&-H(}cWJtDVWUw|4y!5i-=MIach=fN_x^D3sn1=wsGu)7Kc<8ZvHNB|7AY<#XTE)A
z8UL|op1Jh;p{YxXLsxxu7yrf2cGU%+-@ljn?!H>bwT+28haQ{XxNgk(CqcmucxG04
zvaeni?2CRK<Q_}CIz?TroV~j25>i6@oHX?HBbXP=q4Ey{jMi(1p@utEhpr+Gmmv`M
zEZtxS7XmOsNMByO3;qEpOI=YpPzu$A)I-mmbKbl9?B^cc9a+3I@`>+}>f(hzd9wGh
zN7jvRh^@cp>>ZzMoZC3|jn6;!vm39z^Uh!0m}*~5mI)8d+#+0OCnqOkk=x$W_|NZZ
z*ByHo^WsLW(Yv~+72C!OQSv0S|3@F0;qSR)zV%gi&4Jcki+=2^cum^T`mapj%m-hM
zn3*>>Gv%>rkrpoGAH<yC5oj-eKF9TmjXjC9O7M@`!51Fmx-rfGD?t^)8n5d^&f7DA
z0Q6AUS)tpJaYyyV^n$ciYJNq;Cd6hUYB&P}6?eNN-Q?&YZmoW}>mW$r=8VR0cPyb*
z5aeQ~SyNSz&&`MuLC-PPkuOYcz!;2J!oNvMP?>oD-7w;T(}?bWz2AY}g#L?^3U8cP
zD`7_??GnO;?;E-^xj5mk9@?{H=)B#NzRXBsa`WUv9pP?<A%~~BMx}EXr7PK*9LvTF
z<>?Ff_MtVWa|}}oRQpQd9{A~4JUBc#xS)LN>bjlJ^u$6#seF9yv^YJleDlG1D`2Fd
z<`f=Tf2Da_`#Fa*>ng$S<?9xhVn2WP;;PlTB7J!ERqM^$ciqugvaKf6+MViP+XU$f
z*`3Tpv9IQ|*ZJB`-=0jS)98%LeNwj5>`dqOZP_q3wqgCeu?<`3Ne<?hcXdrIxUD2v
zeaRh%5ABZ(Xo9hSYW|Y^+eWI1p|nsa1cj;dQfYJ1ep3tjbpQTERzC5DHI<5(Yqv%w
zyE@~8^8|m^FAlBlI<P4D?z3u33_S=xe5*&}U5oa|f3kgkJ|Nc@#5=ps?&wK%x7mZ6
z&W=geL~`jx3)kh!?U}}ZtV~Y$#mJ$#D}3Eu^FH6^>t(X-)`sNLVR@jc3@(Q&;r2Y!
zWtO{~o@}Zb>fX1nJ5)<$JHls;ZP+k2Z#{}MhGlX0eV$VlF5*9lvq^89a|>3Fz4Iva
zNJ*=6vM~JXc23$k(4XjR!tEN}=&WFzctmG(`_Bozv)RcIf&H*`_aDpZI4tS?!(@x-
z)V+Ua9u7K{@IMcIYnHlRgt(@=Q-zBTEbCkI%;kwqNxgr^Bf;D|cXXPmh3Q+rxU6f%
z;8=IK!m{t$cmDkK3rdMdPtqwRdNPySrY_jGa4myluED;BqwmY5(V$tWPmZI3GnqZU
zoi)DR?$r8<6HKQa>LL?ugH@*;T|;fwk=NubS$djp-8JWCrEtyJLX|J;;zI!`cj@)(
zv`W{qdNtNv_D7?^2d+N2VZk;7J`gqQ%&Ap-uidf8)WTY@uiqXHb%i^!shZakRe0NW
zy2@r3lWz}hPAnf(ssr-y(&PrKJ<Ig^0$z99Fg7|mM%##;^VS#NB<^JwLkHbE2SIJn
zcw&ko(&<s@rG?Kz28&d%;pQ<2G!$(wD24s7tyA*T-N10;0^ud@J^JzA&%bu}E&Tfq
z)z2aIZMPQtPTvN@cHBh#=)X07U5lDd=lt=`@<eC6TDbC?jpx?4Pfp%@%kp%`->uG`
z7E7nkGkhsFbnhoFTz~HH<Hx?mnhy_*3iCQU=S`OTiu3y-jkm45;Vo5iO}x<f>4*N-
z@3V12_i*ER;T-;Z&?!;P`D%AJW^2FHmC&Bwg1rlLL`ctvyca${AD;8!Igicx=<$7+
z&tlj3_vietIX`ZC?)g0qY#qbN5e^bpJ$`m1h11&=aM3=@kB7+^SpdI`OQ3sSgYybo
z$!TOSITN$y!{h?jw$YX3T5=<Hk-nMS<<6qtjd}Eg<Pq`_@;G^lJPnJ<pC?}?-yq*2
z-zEP_enkGA{G9w6jxzp}yg*)LSVm-2#$*DF4Ra%DCeM_aPNt8kGb7A=X3Bk&Fjs~~
z-fIiAi&JnXln8Y-;C2wU_FNv@6h!nz^2VR;oSO<uj3!HHY|nvp9ed#ELk*_gVOIzP
zOp(5RI0M!6>j*aP-6Iy>YiWFq#?t9((`yf&=m}=L(cTSx@S<OOehCzjO#t})c5mt9
z%fD41!OM)}EhbF4yaYjCcD(+xgJ$2OD6})r4tlM7a0xe`KQk50hL#jnhdUgpdEJ>}
zL4x|Ue0}*jo((FXhfqB+4_XhfU(^bQUV++wBCZ1^+I(&s(&lXfxi?tK=~D&L_#|xg
z3=HH=m`LSx)=@CMoNKo?z9_u+_QubHfp5L%{?FfuAF+^21<G$X1o@o?`*~h^PJdSA
zeivn)<(cP*WRf2-zy2-5|DI_)FN)BKbcoQ1!d{Nxz|KvCi?U*rlM?*QF)R(_+ZBK4
zaL6$7b)TW-p*j7D5(>ui+X|J!)_f&@m2F3U+q|b?iv+bTpCqi_xVafRZi||rMV_7o
zL=(0UY|d5+#Ym8Am|3BCJe0<M5?;hJvmje3=yh$pl8<pS9~Q!4xIumi+iaLqg%7h8
zEim(5Js6Zv75z%dXZ{Jc|CpQfif(_kmK?q4_L<9GXQt;V<tPDcgULb5`bzj);kV{1
zftZy?0UP@Ys&F!iI4>dnT{Gib3l+_F;uQ54q9Q-PU@69$d_FAvHXn+`-vSi37V<GG
zoUeoe+~ZhgfSqZ+;0)yR1KgATj9{x7yF--{l9YI1e=JMRmU-V3?_9=w=%H`l_1zCX
z^c}rdn}5r-<AuJ@a@>mn|1F%@W#$g(lF8+`DZ^;vS9VG{O@_BXEh-7(O#<&@dA}~I
zf*O+olBQx^80MvkB(vfM+b31#!F${3aZ|4h#4WWF(U|8nRSZ``6;O!p$3#By$>u$M
zE@6jgC9C^Ya(ksvvGBc(A&DEB_w;%8*MT{>ifG$5!<I?rI8ut}mmKq7v+%a^qgM^x
z3vP&~L@l6)Dup(DPry1mhvWBcXd^bSTg*A8FQUvw_geSN=`gW1^AR&|m_NSkLl<?|
zn6JFfOuN;r+=h&q&bC}ieXV>}RPr`Ah4PW7DoUz&obqPrz9R~sYThod6byk|h9|N(
z6*oI8{%9;wNmckyR{W;=0iak>NrkkPm3#yygs{GG8qQc86iiqTZNm!3B3KeUj1eOp
zExOW7gczc-3(r+pgU>;?>`fk^hVG{hxUtNO-58!_CAy3Y{UAN#Re~BfQ!LqRYfZ$p
zDonM}Rh<0vObP=E7G5yPAV34b)*OS@VfoKyrUb5cb4MzfV~UsP<YIf<`TqBJ4rJ0~
z_?BDlX_RvVjYo^u6E29=zJGu0O1m;sFGml?Ix!wl+ak;t+0iSPo>_gDyk;3|m(IHS
z{+*GFiGE3=99Gp(sJ-#n>5JQpAo-heyMI9?AGdXNi$CGxzYH^Kyu}ArEn7Je2+e$8
z$px(5t&Y#*4p!D|(9ejq4Hp+K+)4)HLo=Uwj(kHt_W5&^_(<6rSVESy<%QKsW6v8m
zw&OT)`@;6!Z&*>?F>f?inVR{ymX4N|GfVpy`^}lDMN#F#u;o`W@#P!4isoE87BuI~
zZ@iDcf&UGxpPcRPQ+f-|uKXi*!+mScuduY%OUB{<bq8%1k*cfV#{p+l>3k9Q7`j6{
z#o*kk`|%o#jtE`#Kf*9xtYI$z9fY_BXWToCK@b43WQXX!PInGZ+cVdLU}&^3#Blww
zW8MihdkJUw#D0q}W^l@`M4hEkPo|=cgWptyqDe8N!KmKF0|XccQN_9FPDbfifX*)<
z1d$`Xh5Fp`lF+>bq>G^*A}C0I7O3cHa*T!OPKPv7A%yNzpcDqE9<RC7fPRRQ!Lqn#
z<roA}dvkO@1U{ZZF@*smZkw1zYULIudXW!RU<B!nw?l$rq`E);hP69&hBIOlzZW|q
zL3Q<H=Fau}{2xt=lDY^Uh{kfMPL=abJujuVCqk9<Dp(9P)PB}V*EY(G#^>d3c_mXK
z-TRW{8f|ALPgbP1HR9l)L2e}z()-{tkY!*qnzhOB+{P0sC&YM7)^oMwPQt7|lf;7&
z#bOPqvaX&?7RgA$nV-f$i<PBq3mT7+>8n2Twp57Q^};hdyQ)(+#MrJKJ#axgq!&LI
zBE9W>XOzeNsUHPyCieu^3>}X5Grcb~e(=reuuPI7OfHUnFpv)(SP^`~S(|fK=-3rP
z=QbrEOBnDD`5BV4yErY;)7fGBnDa}Dy}_OsR2i+*dDFrj(VeR=*s^*513q*29U&s6
z+3N=b63fYcwmdR-61()PXEy%W_>LSk+tNN+7OM-nG8}Gh8XN2Fv^xi~lZmq6ORnh3
zwe6eKO*IL-h4B#N4u&aNe|(E$cL#{S*G}o}XLjT}xI#MDL4KifG9xf^i%O+!rN}$o
zd@Z5qf+>kI7Dw{d%x@SKOWnf!ehudP*jPGM)rgo#ILd-<Cah)>f-l?|<JFDJqJ^NT
z>G7zsx$${3wpf-F-=<KNXH;$??=Lt)I39I21~^9Z%{zpB>%T~L`Sf+)ed5Ds5dQ*y
zb<~{eD~#v?jYH3fvs^5aCgH)hOg41vl7w!u;iRKGNvTaZl5`}A1;>N^0KC(8%;{}h
zEPh=GVL#DpokMHw-ToDPm;QdvpXMB$^CDqSngQi-wzi#g<B(|`cK7Cy39<-0VI?+{
zZNwaCC)q>JAP2}HtQ}rVE+er2KyDznklSz;_wHAj1$~`-ll(LJ7xF{$6Y?|iEAk)Y
z_vBCH=&X5Aka3t8lVWmAiD_rLnSOUBG>@5J7BNeimCRaZBeRv+$?SpWnFGur=6vjB
zyNr1wa}9F?a|?4Da|is;yp6e!c{lSu=0ThZ{|NIq^Az(m^BLyz%$J$3Gv8$XnfVvy
zhuAp<t4lBcuhwxu_oRPlq+a$Pf|=qI|HYG1(Z`qLKQWDm;^o-c=9UJ!tCxOTJA7Nu
z^y;n@G~;K7zgAoe_SMq2U|QEd2loFY&HqH&{|OxbUzhjw;D0rkQ^n2hBkp#Xuisod
zc(A_zVEy1hdUJ3;y}9||!2>wXM85|Qz5>8YAZwa{F8JCO4i6tiycS42RQNqb{8fd*
zdkclN?tkOa)?M@2IPuvFojLPVp<djvPrq_p6C(av5FXsoi(Vg`2mQh~{v7E4PMX(C
z&#~7m->cQpsq40JQailVPH4IpoBhRW=Gpz_fZL~zcc@ta=pF}N>T$7Iz2?BdI{wj7
zyguWmp}pn+{(-L5T~CM?m_ng&2|ic3zw{1f66vM&AzwXy+X`aNe_0TXVk4&vcB7tt
z#V8uh?R(Ye*8#%5at5zJ)+q{cQc-7BgjYL-!e7S$e;o&SV+JY*PbDW>^09S&Juv?r
z*#DC>{}XBdCvf~Zb@SiJ@Acq+HJDSy{UweA&YPHc@5IDf_rLLI>#q51ocQd8&YXFw
zP%rM-r(Zd)2@!uS2oLV)MXwLegMQ%~e-8A2C(Y}n=h$nO@73z))OFi9sU2QwCp6vv
z{c!;Q`-zE(x8k$M{iSzAK7Q*yK61h%4Pw^6EXWN$ddgrL#lG_uqi8g2%G1lMeO?3P
zRWe{sP1Y$2K~5~{tcvhzXJP{94`=BEu$cDO`TX(u`O7Brn1G)&naAV*<a{1G{!Tm(
z{PJhd5;0^pj(DE(OHT#A>KEsfLa*{=K?2?WPd7%>YwJt*F}Ln#U+Ff(+0Q56zgBz;
z{`JEBcj5p4PWO7t^ICAP6n}DiwAxGj3z*Lz*gUoCgwF<?!aw0}!wJ#5rZz7<>F)zm
ze>?RkzVy?0Z}Y}|m^15v2Fz?ZDS!qZYo(<Rvp>g-6CP(r{q5Azr(PxU6;qxvua{BP
zm`(Tb5>Yb$?+eXO!05{fe;ZF~o=r<m`rC980C)4$)Y=pO|Lep@#FG177UZR2rd}bU
z8U3qQjrM@p+g}Gz6ZGF-Kj`bh%Dg&#uUNWM)W^#!4LbY3%4k;w|1yO;B=uiqG?fo6
z-tV3@!t-nyPUBlL<m4-bn;qYhktbhUFsHhn3_JVzmEdVOg=@vXQkqkRx6-w)EgY@u
z>@+9ew_r|nJsEcPa|^yzuk@M5&%V<8Ry(xnwI!oz`0V(<2pPS;e2x3Lx_Mn+KI!i@
z0Uj)0QT}clX#;{I<;FM5<ePZB0#Bq|Zj{Ripg)ag%U860mqyMUL4qR)^1fG;8zrpA
zw#{5YagcA)-($}nkMw|!m1#;K!tb#oz|LHOAAq^IDGY8X5Y4LfNONSaz|XNGvr?B&
zMhzrwZ4`Tp2GDaNfuI=iv`{ETt2}OI*R%?Savz~ZZbKQbDE|e>@{?Mz{F=>pG6461
za(RRM-*~aD?ZGlIl=0iZh0H;?8}=gZ2%r!_Z*d{(+uE8S6qG@WAl^%R{1+k2oVGTa
zgaXhE8VI9Tb~g0vdm2G8(nR#iA~O&%<6UTMlL9Xn`f%z%kHDFKaOtF2PQW@l%h~rV
zl6hI5NcSrjkQNNIG%M?*T56K(5kWyHC}_bi!e~Z-!2e(6erw(RuW~=soUga!&&l$n
zC1+als0Bx#TVbvHSGt}o?@lG(W~ZGE-@2b2-?~2;&+O+v_nzWxr8yOT8h5I13-(mk
z*9-qja5TIn?_2m=<A7E><p4wP|03l6TIcTYUE#O7pS!|$J8P|z{$3N{{gFe?ZyXW_
zqC?@v$0LWsBp#+g=Y$)lhe;xQ4vlOWVe%y!jewaaBW#g|90Kq;PGcVuBJxo9*hd_4
zK21W-cV?8xq3|;Rc?O7Pc7@qucxHEmd^wB=WI@5{k8^A*;-5hx7x37lK==&J<e3)c
zna7<&G=Sg;Xo6-UxVb*lM1MGZ?8CEjb;&ecWQSdlnbRD$7@2vJX3^LOT$CUXMoV`N
zE%}!tUa@`+ym!;G-W8ee`~`^qlN!=`&6YeFfcuo=Yzl`rIZorK<2)1&Zw!YYaf2Gi
z5FCjRJ{;cQIE42g5ZyQ$4l^>YD`5F;D}4skqmFaz|A|Bx#c=?FbQ=))VHX{RLm2Y}
zFucc0-gp2T5Oo*vBQEH}072@<!{KAU1E>P9<&g+$dX#twC>|hYKh{b|DMUh0$2{(4
ziw8=~L+(Q}cjh#Y2!vAvG#&}qeJvu920434DE8A&q>?75>1csHP!t6SKsNI@thf9g
zRr6t>1}V)90p-Qxm)08K2}d)>W3#qsg-0T&W?JWtvmp|J>{sWkd2w9c$P?_heGdEY
z{uAeq{=oQg`X|X$m_EAamhMb-&tKA=uHMJpm+GF>qDLli#FOr~bvK^2K(J?(#^-9G
z(n}EDp4=YnjrF#r)&&tqfN<Wcp2HqqY?#h@b~J#VZoQ^B-Ct}@g#{~`M-2}1unE@t
zU_&cn=smWux*K1s^=1@Kv%3NKZH7=M6f~@#76rGi)h%x?Finp$vDjjpBGlIfOyBim
z$1S!1!{d!-fCF1)J(@wXmy+(vb+;hHF?uaWjdIXqgvDGBMedRcQ`B?=Ft&Zu2=7#(
zyB!$^ljaf63KuPVjbf%-hnqW^MK2+W;vSrBg*tA&?&jhIaVrKfj%#CwR?G+vvf>yJ
z>Pz&pN6pX_EmJ3WfSr<Tof_zN>vDwPwi)kLG)~#UjR!?WXxqW!2=)r28tAcHY%r$3
zNKnK1E^6+_I{}N0(eAO_Ds2aBfu;u=<&B4yyzM~Y>?`gX<mJeKFP9WqJz)5aWKi~{
zWn*bzy-_p=>&|#4o9Z}gd2Co18{IFExL@rL31p+z4)gojY&ob)yBW(`9*kUCh^Pcd
zh)Ae2kP5ZM4gVQhA|M+EF>F~93syD-&lZ+pFA~pY+55k7V;8q_k__CDR^`F0T)MY>
zL3V6xNq<WAEkAtdVX3@sW#^GimxpsBo08XMYYY8DXFR~h`-dmnPRmXug?sA#J9KF)
zi7nq(zgg#}O5xt?*X(#9BA6WU@j+HsH6M?IAUgBzw0*}gA5?TnURdLFE+G8f_5)iB
zOO`JPJEKD@Z(PEp6*(uLxj@8u6@J*11fiC-d@#<TRs4KL&nFV`VmEa}4uc|`&^C3(
zSZSq1xM5j}GHfd3Fez-G7Byw?-$>l-$VH}gpQZ&hJFMU^IOA7LKJ$Uj-uzq`|5Hcz
zuNj5Mb*pL?I^Y=me3+3ma=y@HTX!(mJ|ZwR)6t4t#4!VWLDCAEkAs7B#f)$!w@9v*
zD@VVXod?Sw-MZpevl6U^D;ya>^$NlM;ffp=r6+sw_fgGc(m^ZmUYK++m>+D42C{AQ
zO}jpxp4T(CyqZbJbCdoKGZCt#m2E8J4+P|ue!t!|bec3ad_=C2NXV~@Eg?dmF~G2<
z&$J=|`P>IBEB2ts>5-_UD*+{I`QauR2GskyEfQZ#B&}~tZhA$@j`-v0g?5mz&y=G!
zqqPa;^RDk+;t%jD{J`h(@pyZu#zn#mUl`b1OJbM1&IW7_i(N#@l|p%ohe0saw`OfM
z3i}iSuY}3UNGjGYx0B?3j1ag9ySK^SotsAA<uIJiCzxQgyMBn}&LXw(dU5-b+Tiji
z;d)`LMw2xu7K<5i$*<%GBW=AI-3e^%lte|)^??qepCQ2HizvqX`qYpwwu#}26@I$T
zDA9mZCYM;+G@KfA9ND+LwkrTzb$-DgmHBku=#eEuF(RDSDfWJ#WBbZ;c;!%87`oPW
z7-bg@UAOy|z5#|Q+eSB*ddvQlRjC>NFel61L`Veu$#y5FMPP5SWQ!7K1uNxM=C#^_
z-Dfs_WL7H6)dVLCh9Js{YGzbbm_OZE&1r<NpXlxF5#Zj!C)+FR{?0+uG$0$OjoHV9
zpTqz3Q*%Ct9oJ`&^KioSO6;t@mHZvKpFDtbr5}PP^nW4$hMm)YAPsC-N4lopBg$;S
zYw5{?)~N;e;5}GNu8$tY1|Omy%4#Uva-|5p!7&CT6&$f7fO)&|)b=BVb00m~;iaLh
zm8PX^)b)GhW(Q$V2QQ-^oY`@Y@PIpk5E~58rH3+a1c3^Aw1b*<@;+dE$cM6RY9a$4
zI8H(#U|O*y14HysV;$!;>o~GX^JyaP1E)o4C=Ufw#gEH>DOacVSX_}KCJ7abz(+&i
zqYb<nfYb*Rkl9p-xx^xjAk6)EM>&v5v%*{<MnT7j%cOBvb83J^nCMjzqyQxuZiFZ`
zjvELttRdIjv$co-<A*6tB=G|1xtbicDb;E(Dl6-Vc0*`&c;XmYxDASOqTWGljkc}W
zQ$o8?>j)?;OlGzuLsJ?EKmXjd0cXb>4;*wt-67k*e&hCU6sG!?S4Sq32QE4<V#FS{
zFSu3n8LAp#m3$}^?&eb4#IP_uT5MBg#ve>95aXIJ9fY|vPSqSasRjK?gh(j~>`|(y
zO15n!J9Hj-m}3&fWQtAZb7>}#5{F=#Fdj;<{qv$eS<#Ctd(1&o*f2DG%Mn)0j0T;{
zR`E)HMQr3?w7ckg;U`&ey=*zm{vgsZ*|%E~&pczzZk<!ZsnLhl4@8+&iXG5{N*dOy
zU_4fb*K6DIPxu2-HUtwhVbf`ohb7VOj&U;ARhlaJBP<&%Z_P18P$a1%*%N`x;1z{W
z|J_+NqA2SIi$+u!iui>}fo$0@*|&XosA7lN;rCpcTsm)L-PrWJJ#Wk$y>Nctj_Z$&
z*laE*i%w9L9u4=T{l<{ysG?{DcXs%MSf}swkS^%r2rL>&0>fwmqvj-2Wz`|xkkqXs
zQqFe?qnVsYE-j_A!STtFls~m%W9EtxjjJe!CQ3bnLQI<&>DhBdvH;O?uPNK@neIx;
zO5{18K;&|yT8dVKg-W@URPk51?uQD=rc**t?GKc#)Y#PWHS^-*)9)f?BvK5;L?z)k
z^0<)E!ghdDeC<S+d@0f!8fGj_vV05-NE&f9grl2EIK`;pej(8%!AXtgAF#CGZZkzl
zfHVCP=NARpZ}=RcuzhKMMcbhpi-}~W689&9tH8inEv3b7ePYwuQGZhC+YwLJ?DDn}
zcXP*vpyb=IwUTIDwRP$ZT~4o`tz~VE1e{M^_+wv;)b)^J^I4d@6jjF{ZoS1B$%q6@
zB_{2Yi-qN?+1EZ+-V@*>k|I`k&K7ioQ3Ob1LL|RA9MA&6E=ebb3`?Z-KzVXxW@y<h
zxnQ+t`xJ&vZ$4vreBss&D;B35E5@zzr=MbOh;%NDNFt~7@<J5HNnu;quZ)(}5oI(Y
z%0YfG5adLSwHSsEYO27qNlEvq=f;@&9{7y{qkcAN`S=cBez~x1;84;IubUT+XH`{+
zYVEnyd1<|{WuCuM&8E8iAww`VEz&+eS{^L5S7NYhMQvcdcu3m7S76QeY1rTU5`0y@
zfO9rw@)lSJ_!#*t`5MOi?t!z`XcT;a4g~274=&(xAq2U+h;kxu0FS4GakxCeWm>aA
z!NhVdBlAEhi=2h~rI;ovrrJZ1;|W|8e(3O}BT^hr^B5!zw3_%aSr{WF%7KuA@-vtF
zI+VS-_5p0l4=F2$L!K7*ro^Kd0xaZ#2Ll^?QPRBVZ!HKG)?&ld@2pE|Gczw7bDbt-
z$hk>8_++szz>oj}^6p5UmJt6StC{$v8}LUeG?3K8L(k+<f@ry1X6lM05bcVDCQ!?F
z9|Q#oHybe|3Jx;XskES3VchOXJNI;-i%{AS8Rl|bQG4Wy`HHUP^U2gYl`rKMWUUl8
zq_jt;F`|l=4qcsNyR(5n*ypqN<~oJ`^8OKp;5@KkbNO@`OvMO?Pfy1p<uRh*<e4<2
z=e4fNDpg}7qVT4AxFa`q4rv=W^XljCITIGu^1M8?cQbEh(h}iwcCaIjNx(`)U!X*M
zswAl|&WQ}9GUJlc6D0HFYS-q`f>6xzOM`mvL@;3p$#uqPY)yb+<*cwEyO@mU!d);c
z_|xK&wOeh)5_KVE%Zetc<M~j1G$>bV3E3(v@VECB$$^D0?%ddMYvZ@KboAwlilGde
ziq51pNx?8X;m0xZWH=mcbA}BV=<R^flz~`06Yn~FQ>GAi)brG+EjiP<$eQiPR^B2q
zK66sX5zekcnb(<Iq*uv{GcWqm{$Wx0+w;w~GJB&MOeTV=k??V=J2x2q*y*w4;pAK^
za7l2ew>uQ@*RSi3s68D@w>%V+<$@U86Fn<BaO7qy83e*?B$8Y*c<`PHxsr7%3Ny;o
z4j7x38~#-h3|-~mr5EN#z5$PWdOXt2YoZ-o9&EqA9g-|^_{BNwNY_ARw;3*V1eU(z
zo>d(iEBjP=u4+nBcOY&UgQia*l|pxWVK|p8Eb3;ii0S>iMWbV}&+!K@RW#eqE-}Lk
z<AKMmy;^^ejYXKcFBDV-cC>Bjg>{{0nRKTSj?3_LSZw@Kovc`Gq7uj$g~{9BvCdv&
z`}ByFMK6Gbx9Pq6`;*D6CBI|G{t4bJOk0Lp9N~F3UN@srD|SKbtXTJlyUn_(SP_2L
zYRFDW)>x%Kj7fktJUm(3{<cjTi$VOdEp{lvONGkYuG(O4w5Nz&vZcg3maI8@#jW?v
z+_&_P(<!--71X?-$ay)ojK~{z_&X<<m0*!#Ii+V<b1XpqDY8^8MH*k$+Ou35!&!`H
zM_xQEmH4&ri1%SwVfh+4hg^+Qg5Ps3pGb@k7EgMaLA1aGvy9oqoW-2WT-ZEy?7r+6
zIMKInfHE<RfM6XQhP~YnxS(sr)16&=v2=WNJknJ?cuZ2H7Pm1*0!9p7oBY#bCiK@G
z-MT4Df;+awxR!DY@VOAp-95N$_qvJ_%KN~WGB73H{6OzP`9J~YQ7J=kj~)XhZkqtm
zbXZ<ybV!R&7mig@j)@O7?g`5J!1!RQlok=`lJMb6ZK8Szz-eh9h@j_>{gg}55h&<&
zWrBOE*()~OdDF1gfSYP|+#}2IKl~CZij1aj#(`tG18>U0>B#(eEal854$9*|bBWFq
z+{5=&GebWVnvT6ems<cgm3xOG*r+v>G(@9NKsPJ*$aD_~Zyt}P4MkHU#BDH72SRU=
z9gLYE2h<1@AFz%}Pf?dJvK34MU@%^^d@hRv-9X?nd<TFIR7hf|AH<0cn=8Q%V+r-v
zp92k!;0~NAZw^tD$(|IgQ?#}ILUZU0gSH{5WQY;iG7j1}GhH`WR>%gXndu=xvrJvn
zgwtd-%L?iFh8c1)HM3Y!G%GjH4ENZb`MGyTRV$Gs7YiMNx_i_QJz^+X)H;ir8qdYV
zgm{_ZV}wKFStCTu#Kv_IqbqDy9$6k7R)dbX{q2vQ9oV@nO&H^T|9uI@;?t2#GN3iS
z&hnf%vzdgF^M1EuC&Mnee0w235Z=eWRr0M~`quFauj}_&aiREN*Eb!xZE2;wYl4lY
z4(MlKU|%ik!JaG1#c+2;4W*(f9~aUhL8eWM8R;yy%oI2_)T0<N!3PtanD>QYa$`I>
zdflRaF+4uK0)|>RdBMo=Xb)=#b8*4Z<hik=t+S2i3@w`RkH)&=KB>L3;1NOMb+|xK
zk4eV-o^FBHxN>@(*&Egqp@j?5(>YET;~^#>#S$t>YPpU?0!>L&N9d5!<4ma1-ac2c
zjRnzI;|o%0`u%JCX(bVkxBHD~-6|PlMwrnsWtP|<il$&6y_sR+<3=)7x`tEoEbO%I
zvICdlH2LU4=5jeC8frX9vWldI7?BN~Pm^4hP^36HQ*0wqHf8pu0!Aic1=EiVbcCX%
zE_t{&X;jU|m!q~FJ?MkyutaH$)gt$P++^b$>URXBzg@n3$3Q$35O#BXz+OIC%Ek13
z>I(Q9eP6NI6Nt8%Qc{YCI(DBiXmPTsILfvoS16&7a+?E<l6v-NINc?7Z8^9k+}~cv
zmV5a{p<KyFM$)F0#7rf2#sS^P27K9{204x>X}&!>sh$0aEgz07AB$Dyt&@hdn!$3s
zC~(Z}TKZ3m6_YW-!?9?g@e6Uq-CNi9*$h!wGsIeDE-}Beqm=622z&P=-sX&2!jgsg
z_CiA8M>n2TQWCzx*_j9-d`VZ!D%t4Isc9m1#PvTsFuy(ABPx5;Vdts+(wRQn92wAs
zfDU88+*@)PLdd!6=gnWd?ah;1z>tEh_KvgHx4*MJK7SFPZd?_w_#*kv$Fd^<C$N3{
z?TsazgcRJ~WI$C-Q6b3?47%95X|$_8h3A5B=^K%fYMT`?3|SU<kfd>}Xcmo#6-uY&
zkfu9iSoz7^pcECmJM(2R)y0WyFE2BquZy)__zHm!VD1Q8iwFGSMuR2t*X&JxCYCt1
zJ##~DesAnPqh>_6`8Z4Cv*FM+ENtYvNzT#~aZDGq(iwJG_iIY2@vnvs&yBXkCA90E
zc<^G0Rbd}v<VASk<lA5o<4f>!_MB@W?C0bttaX`85PJGSoJL>eN-8>5hjkLL@D@Yz
z)XJ34c;X5kU0ha0`Mb-1T&Cy=nPvzcsPdO`Rs$*v%G$j-00a`nf_NmNdW+Tv1~UZr
zOT`)hs4@XpjH|toE*KwWe&Db!?*_M{?A4QBEpb2zhAC2*g{Nu@PyOPuR7!wT3=PzH
zFw~IKPqp00otClr0bYtPMHL&a3a2RYLN7Ik>Wb46RlJ}E>Qu-zmkL}(krz$Z9w>`%
z))>8dQr7*Y3>}57d#*Y>;pG;NVsqyn)DFEzfUAFZ;bFa(Iw-02QV|W67M%h>{6HL0
zNs%J1C_)UarKW&yp`)^f%312kgVwSqH|tbt1rdNsv#4?ks}w*jLeOJM0JRHkEz~ll
z-l@5EK59Y85l@fRO`Fki4Uf=u4cL6Oa#U}RG(ZTOn;6>A(MGLG>&5LBRoqBE+2DoP
zC{IKfk+2pDgFUIRUos8|J_5r%DGqLCwqz3`jOvH|p^&7BqHLs8zZ&MB@fF_Mb$MJ&
z$YqV?q^`D5Lh`9bM9c<l!URJFJDEr`xu8@FWc@3nmN=j~9fci2Pq{rC1%FGfuNU8C
zt+w>rzrFK2laClHhYF=`KL-U+f{i+g@usk<$;Ror1Jl2PFVrpi8~?ztA}bU$O=J|^
zkPImqi3W`>Ns{#}t63<77~}j_sPT&%8eiG*^b+0PV3*dI-D9;*KI|l7J{Sm=om?J8
zjU|0T#ox_vK{K*R;+U$BOTk<RSgY)?ENpVF^Hs%=5o8v03xQ-^6S9hrB*w9ZL6}kS
zBOxuo6A$5(0PpAC-Z?Qi_)~qzQF+TM^9&TvBsn67xga}O-)gMtJ<Sa1fgwrt2U*J)
z<;aLR87jf>G|vm%3&~6@7~wNvU=u~t8F-HoNSB6V(vl3E{J;>Tf-O$-=qN!92N@p*
z{mN)S{ER{PF(b%kVwF!RA}fm)qbhQ2k0AM=APW;vEXy*f#;k(AY^>y8;LGN0!4aai
z6_NbBwm&+3({{D2WF$?<<vPOAG&ua_9M5+7i3$ERt@^lRUJZXGf+mVF=AZxzSxNL+
zP3O$W+}uiQv447}k=t;1e}5ddMrfavms?8c?2PK@xrOjJ!25$(NQn#<rC{7)Oclzo
z!E-NuK2q;X2c`l_5i{FMwjVCr`hrV~R#7Q$9x4Zy1w(7?xV1_(syk&Un}zq6dH;OB
zYFZq_)>dXK*&J_WGi~H<J;t%VBmX<>M46PC(%=kfcQC&&3hg344SRFM7v#lgK@s>3
zQ6mU1CeD?HCU*!@fXN#nIlYP>QLHGt{j1roq@k%DD%_E;y_LTy+q;Z|ugoOhpCrrH
zYZxuXs$-W+=~$SmTiS&IRcqHm1yMC%Oo`gGi?MPr%gSkmm+FICb!}1i)?}sYtiH(!
z30g5&NDV4%In^t|I?nyO(+k=HWY5A%Li%6iN>fu{V8?<qg<*Vk0I!a`BBsiMjLDhS
zcn}uzXP!tbS{<`|3THgXB@%&QxC7yrrrECrWrm-}1-dt3)FkK}<aO{@l4<xb2igLi
z{(Gc{_$0h9d<Xs)egh2<3tN*x5``XU0G3sjz>3rkvJdtoFNLoEMsg=~{SS~&ldq8P
zlmEiHaEhtH^2sjdFitjqjrkGt9CH-TM(gY<b|ZTh`$ldqH_ctc-Ojz6dq4Lf?lasM
zxqsrm&;5k^BiEn~srb+F&kJ(|U9g0L&@T)N|1SK87!V_3SsW0j#FgSkai_RXJS09T
zep>vh_$~2Y#h;146aOS0lLT)r21cG_DC>1~B~$_+#9gdx$^|;9fn;h42O2H((`5pe
zGdBf?C(vl>CI)IK$%XNT|1J6A@=aF|xICF6bA=vd+upaypXn22&LFEfk8rc2ndWFH
zok$@9lCg)<Ntd(-KsIJ5wGuV^j*O6v(*wHg5Tc!d8nqM)>g-;?xC(X(EEZud$`-Lu
zO(kH6D!#C73&EIic~0Aa2Z2S*1Vy?o4eZd^4Nw_Xg2<-QoaWiOqrtSYyi{1kr8=>a
zB~+;pqy{xzEtb1pKov}GdQd~JRMgN(5~#FYIYV(f)Sfsslbf3@!d*d0MJWV3g@UA_
zH0D5xUG=E6XuXC8U}Vy!7OI*92viFN2j!m7r$97oI!d5dc=&>wECEKX;Haa3Izcpk
zy(pU0D|WSBE7=%CV3wDn*0(^V+l+KpDdNr(gpLj4;#ko@ZFr&_Q9Tr=Cv4puY1-!E
z5JgX=sF&LS^-IzZ`)ycJLZ?Djm;t(7f)1jZeZrflx(`^v@oLBcQC?-zRzZPFRSP$>
zsB(L|3rvXtt!{^OL%p@5DkwoCQqhl&;?)$Tj@H$HSJlAhswj>pMKoHYSjBjQ_KRi}
zpp2*h+Q7$y+<YiDsuVqmF51u_msUbE2I%NpKqI`sX4SfjUpaVZnFZ@sv{$Rt>TlIo
zpf=FpDAHX^6QJIN-hdk0qdkP8^#)QXC0;A~KEr0SOBi*RU|~>-HwXO&Zvq|bxf$j9
zs#v4*DhB4(y!YK(E2Q@{wa}{2Ua#HII;cWmr@JHQxb}GKQEfEubE^te`%xqAi-wYW
z9R#Tc3RK06iUm?!;U2}Sm=d1c55}k{OPyxkpREPa-)S)Q#)7t@Wkf@OqGof@D3PLo
z+Q@FT5gODT_EFU~&Bj$Hc_Uqb=6Zn9t!=lxYp%+{9Rj<EXo+YBbO`S*nYxvLDjEPq
zu09zw(70x;qfXuaES7p`)3p<U_A?4dVZ6>S(ymWy9u?56QFxF*0CFnPmkG_+ghp$k
zZ&@^d>T1s|DF&RP+q~#IG+Sgy;hX9i^k!HFZu;HvUeA(?kAQmup0X=DBxXwkE)doV
zXe%QF%0=q6LKf_^-|M=~CZPR+cDH7qr4+gWA#hZW-*^as*P|Se=ucin91kj1TV-`q
zp;0l|&(Vy*J89NfHO50z(4bh*ZUL|8btkunxnZ-o0~I}0QZ0!^?BayF%6&a)Rk@_%
zO`z$iu88h6D)l*iXevs*%aJG}qaanh9&{4qc0jz!=qofcWb1&LQ&^Wq+NlBNQbYS3
zeWuL072gyHNbI6&zJ$oYeIIGRq(tTVfQ)8E(R;gzXxDJ*t%4bPb=Kd<QW(@h3Lccu
z`)DxbI#nbKqA0X>9m^HswB~64z?wc9w+@<ZT5ph2Za$O~NDu8>ao(rD7RYb!nt~NP
zEhTD+bjT-5NhM<DuJUV3*Ug>os3m&E0M{ueJEtA7gX?yDKDB+Nx_yNn!B!8aI%2_>
zPC%MFuhY`G5I+zy3T>r8!0*hp{mkOA3>R~tDl4hJ0<5Vf)2X@@@6_2oE*whRkwQpd
zSy9zT7i1D^S4@qMZ|X75zAe0NS@&Z7H0Mk29PAACZS9QIHb6Jn6_9)jbA47%&h+>9
z%AGO6QsO!%lwqM*$y<s)T!Dwg0@pXFruc3j69Zg26c$EDg@q&+V2!*g_wZ)YpniEq
z5<XT9%T|9W$k^<Bb-rF?qC&uwV?%13OPBe?T>+KlP7fqw1vxQD^eAgZ1|6cyq|OF}
zV0z36U<-&a^RoeXHZ3xvj#VDw0@}B=5JwosR4Q2pOSNJ;Xnc60U-gMxI2yMYmeVmk
z2#v#8pI)%ouxP_sqsHEDh!`5{+oxg5w>_xa<c;wnVdPrl9!X}1%8Oda;(R?rEUD#r
zxPsA%EnEIeG2SoQvf5_|`CP7ZTev^-wsD!L5@GySDq~@-_`X1-ST3Q*W@Eq~Q{ipz
z7qTL7Dj8s$YS1r7VhMOySe;=;GIT)}3r(>0+!yvom}IBS!Ednbi-lz=(qIg%A_+wC
z#mx8stHFm5^l5`56a6a(^_v&xRKZlH{Txp=FW<U1ruY{I*3BRGu?BUhihAZ{&WUVN
z+4i*G)WvjUn<z63D;?T64pmWBe%gT*R#r=L@Go=vqHuX&W1?h4PV=v@S)we4t||9K
ze>{;rdmxh(WC4mppWnumZP7>8TJ6d;{kr2zF}xx2*s;@lep@s(FLQ7-8iv-i+`E3N
z!%2Q2M*LY;6fm0%7Y5E4c0}EmI(MY5Y9gyPX14jIgeX~>GB+3JRcDJ5%9su>2@!!r
zB~jRQwa)f08HRanSWMN-g>sY-0XnN_&c~%yu@71?LY9chXJLt%V5O($XF=JF`~Br{
zW4RD2!M}O}-eoiCWHMm02_qpIJV_OZ6<L`RjesNg#U+iKzdOt+iSn|~GU7P#*Y&Pm
zzx)A1(n#YEnkni`C9cYPRQ>{w>1|3*^s;^av`B<t<6CLC{ai3G(iI)=Ca2A8)JB2|
zCpH?<skEt^U6bQu@bM$W#7M!i2j*H8Jrk`;eo{%#lLL#xc$X{zjx;nImHK2(v5F?2
z<@hqMS&roNPGu+jBbadpW8${4h^=pMm~%+ym?lOgHcy>Yl3=z&SA&@@OmO*XND}!J
z$H#d=mo-80Rq&>T!m8OR2uhN*bw3xZ%3;+P>{I-0LZm35GpG_9%ao?2jL4rGkUQEK
zLFg~~)7d1?agsbXCiaK;0!jGc*oxuX{FuQin7oCQpkGUD2u$WvjgR<b*xNM|D$53j
z;u-QZ`u{Gy7~%8jdgFc8lnOU`dsqj%1Xxy<!wIs@SfvU|EMoO1?Z)?~RVcT~d*kUF
zS;=lI`&gyI3rte;1x%-3Q8wE=yU`5Uay*0aLD@{Dis@LP7DI8=JxZV*tuYw4csA&y
zM*Rspr1-92ShAxB<C>@v*ujx?9dbxY6tfwhp!MP9=SjYUiKL*+Pl#zLjAtx#j*g3r
z9@rhI&b$XoVMUR}`?z2wAa5{XD_aW4s#WUCnHf2db2Rv1=Ep9&hBa2U2O7_XMU+V(
zhG-S=+84@6fhpz7jPye;91xwD<cldf`QfGjv}=`A<KawH&crj3VyVA<q7Y(r5*!K#
zeS}G{0}qI6%z&XK%yur;Ehi;-8BRx|FteOVX!T;Y#Ps+v+vN0gOpNkIa9^k-<hmrj
zI~Nx8Q12BnEf|3tGv5OiChTE0_(xW}9y@zDE^42i2#85L%cM#V#`p;ID4=VM%Ln*#
zjJTrR#lpvJ2)&fyBB%G47j_r&{y3Jx_b2^-18<3OA2CyMX)-l=x+L&|zb%qke(&5j
zgw};hC0&|~M9?-Ye`BV7Pl{K1_jZl!KD*1;+ZIyN*$_WE9riJ7bk)MC?d=_XxF4-@
z;ttl5YAGLT(q{#e)upw;Ta<)}T_^&Kp%40Z)_QW~Vu#P?&$e|aa1%W;ckartsOTg4
z&E`C1y-)1)Pv#@VeI#W1E9j(&VJ=<rb@#67D6ksG`#3XYvG8gunTZ12I_mjoywi%s
zMI{d17hh!@B~bNAf}}f|7}A822BYXY1XU&rpV^`^EObM~#Vg4GF(Q4EF7T-+5%?97
zT8f#sO0uo7>Xcu=8U+(Acj&Uo1$e#7QoEA;y_*`pV6e?6n+n?_<12DXUJ^Jy&#dkg
zjG2dut0doP6S~0`NL#KTtnFaPz|`JwH&|Pr*0Xn%ogZPHgKK`aZ1Wr1bU&-viN&kI
zH$M_&r9rW4XdpScXzHkxk>C%$O+k{CQdWwnf0Mm2YYv(DXt*QXIXn%fd1WwsV^Ya0
zGKt^HcC$Xw`3{?(yC`g)AIS$DXr;0@WD6N%ZSMW%`*XwfUisplsi9#$ToIwJI=qt0
z<}5;TDK==CA>~Z{bAlNj*|0b16Mc5|s+D(4T>qxF>QJa>^kadcu4E3p%4z&pYTGWT
zfK;I#71|TU(ENo)kz<Ri7=D+3bCd++K1?UWT7*-qbcb)QZ0MZNkW0yk9WalOozcE=
z-71fY`H^;|hZWSGk#IY9Y>XSeCE>2|_D)A!Q;J6W1J|dgWsBdwsoqoYEg0QsB=ra%
z>)c9s6K(D{EAftkoL8WPT0L)id9OI#ky|NTn61TQMb#hQct()_vYDEmOgZZ|q58_J
zBadX>ZRev{pqzVCaA3pxtawrRc|cs!eMAjg<@VTuFGuoSx<7kcl;0CMveCR~KEp`L
zruuMNi(J+_PmP-oFHsjwGH=$$S0wU1{O|Qq|9L5u%f$ODwiY?BZ&KxDK~0~w>9WxD
za*nx&koJnnaoEh36I3RU6)aW^i~jfRE#FtNHMQQc(w7btwFvf^Pi<Igv@cnU7n2O`
zOpE^Q_C%=21r7zmhZbUCkW@d~6)HW*VjC8=rnLtb<$j^HClaHp%7b_6gzD)ey^@k;
zqgy2$3tyCQ3tukw>aplR>Y9O1Oc7}!AoIbcjsJ>7mvu1QwkdxqbN=@1L=L-fe*>$~
zTq@#|{BmQlHW;@%FNv<`PfsKUYoWGIY?qxFvxu#AuWanNe~me|vFoxeq~zxr)~7G;
z=HZOMkPQ+M{m>o9cy^1>8Rdl@3BHsSj>~O{vdK^=z(Z71F`kFhI6dNH=8`0l@yfBh
zA%ubqk+=vH#hhiNnW&0n;zYO?JBFpyShp|CW_+q<g~AbsVI0G>`&da8OM*o>Ygo@}
z?Q^q2Ut1Vk);YdXUS3~-cQ6#_hf8VVQ%CxW@mL`gs#M>evhOx~`lURMr1?aw0hn>l
z4#vXix&0&_P)*ffVq$tIT3yt5DmXrLWsksEkqWs^SFjMrAErBwsaHG5N$WqAyW^bh
z$V&#lVMm#piYqoPR;_4#{#v{J{1r)q7xmIwyK`4*-jJnly6^fZceDJK(={$I9UPe-
z$rM$c35OGj%HhomICI%Z=bO@unC&;$j4agqRNmRJWbPVuC-%p!C+7v%GD;-JaHDo{
zT!dyl83YNCcuKV>N=l!PQy4)XX-{P$$&v1dJFmHv<V=V(?DQk|LWNpjeU7PND5(UN
zsxmx1Lv~%THysF$2S|~NNkJwaWAq(zq`bEAbUYg8NGw_4Kg#>C#+a*$n#JHO1Y<Ss
z9f9X;i`=Z6vK%R860z%yWIUxdejA9%0lR9LVKXp29Og=Ds6FU2nOFoC>Wi^RSgKzq
zYX{>dr-j<mJ)N@51yGAZBoRcXma(uIcq#=G=9(!iz_2YuIOd@sT~@zDPBK9@cR>&)
zwN>maOkhxcsbIjvAPaqJ5PJfDBp+bEhtB>PuEwqB`}i?_DZiTE%<tmQ;xFdk2+RC;
z@%Qt8&wr4Ag8vl%CH`6d`}~jjU-G}>k3p{K5I%7sFLVl3VN{rcFU9r3c441zws4_v
zM7UMBOL)8Rfbfv;kHW`=&k0`@zAgMf_^I%`D2YD2!fEJzhs6crQgN-gRoo*U5HAof
z7q1oHB;F~$U3@@%Nc>0f<KpL_3I4YD1MxX%f{#j^gdL<9#O0+9X+Rp47D}t6Ez)jj
zzjU5-sdTk;yL6BAPU-#9homQ^Pf1^t{z>}2^keCl((j}fWC$5KA{XRNxhjv!Q}SAQ
ztGq`(AfGQ^CSN1JNxoBlyZk=+5&3cXv+`HuZ^=K9e=0vO|52V%1Z*U;m84Qsx|EtS
zrYuxeC>xZW${ETb<r3ve<woUp<sRjo%0DO{QJzvhqkKjAmhuDTr^@rnAJrUI5C+t_
z>ZH0--K3tTo}nI6FIL~E-k{#5-mTuNzDNCg^@Hk@>ZjCa)Gw*es^3?Cto~B{o%(_{
zN0T%k9B!qxyw;%&XrtO9ZKbwR+oc`WF4eBqZr1M7-mbk@dq{gy`;_)2?OE-6+7Gqo
zwBKld(q6>&5ly%BsGirm^}0TyPv}eaHTpLFH2tuCfqq24LBCypKz~?&On+K`M*ouj
zto{T2=lXB;7Yqic5G*5Z6pT)zYK$6F#tLJjv9q}w3Uhv_0qC3^6M5VV&=b3w59n&3
zz-eh#FuC{U{}dhyKImxROVrhUL-XOOi@c5fC4uTD=v*IP{6m>Q)6gdXK-<wrgD5g6
zEHHaToLDMS?T@Ewn61rs^$`@Jslx+MQ<n_oQ4dvS(8%TrwWsBRVgibuEPOp-=Mzpj
z)qxp)#qm!yNEC(^wWY<v0x8|}14JTKz`L8KvUJ6@E>OjkS0nCX0;qSd%?na^&u(}f
zrS)KGd8jHJWEGpMue3I+tz=MyxGC$%kme$~>($hO9jd~uW2(jhGN`^=NTJH3^+omM
z2=|n)$D7Mj8PZ=M5TUUadR-kDC8JLSQP=|(a!@i9r#9l|;+=7WX01r~%A!)BM5ojj
zTiXe2gwYs$Q3j+%9lG~U>q=XpZsW)r7S9|P3Q8oJ2Yyhy_zk%vqowI;yFfM9I3zIu
zAB}DWxtdOBk#apQO1E9G^NT8z+*+oz(Dnl%wUDdZql$0~P300yH!XPHGU)a>=&>lV
z=weBjBSc%H0_d(fYyoz=3+SP=QV$(esb4MP30hkkih_YSs=}p&d&JXtO1HaoK}*tu
zg%H{ofSIZ`Y1_DuKtMxV-3A@kjYlx;d9*!gbpY1YuAy*_S2&kiw<Ip*^oWdG0%*lR
zA$?Jb)gF|memq+@S7h&9-Ok%=5A35TiaB%*SLy0jUrE60M=5Zj>Fb4rctC&j`l#E|
z*eOr@nShrPsqmY1gHaj1l;k?9quEj@B@MvWd-<r^4=AziL2%Ww*av|MLUqxO<n+1Q
z51{50+DX;b3umEirf!DuPSSR()lo<f^$EXjuXo#l=H}4lAiTzuX&@0^ANLog6Y+o$
z+8wCQ5j)b+CrkYUbtsmdDou(6;4K5qwI_$Z+4#`T<wl}l?yG@vQ=Kg~Tza)m`$(<c
z;|$=Xu$>a{fldd#4_BwwOE3MkQWeXOP2Dtoh20M_r;2@`Ywh~;8X9^|x51GkuHGBu
z_M&EJE4F~jFQT0&F-YUpin~ozq}|=7lU&@;{hqU~W6;ggCIW=JQbox<Aww5KivUy#
z)>05J&Q3u+$hW9yUBN==Le#8B)bT0dJYrgat!u07uXJs}d4;JLdr>g@#<mLAO4oXB
z!MCmil|`!xOMkS;&6monV_M`E+{^H|9Uax&tV}ev``V$>Pfk*>yozt3aBIzN7q?Em
z%)J(I0g*YS)}zX+l~&S|uO7Kg@<$16IWIxZEza>`^}nn>T11|Fb(a8uuvM-T<FUYi
z93Uz^%F(#ZV|3YO-)iL#iH=vx4xL=>$KzW)smY;jy!Nf4nuM;?fp%0aUeIQB%x;Vp
zQ7vq(T+oPg=^G5vee+vjts}`Ec>Q=?w34;ZwBX$xPc&bU<d(Dr*aB!JXkCwo54ibz
zjP0eq1F~AZ<apk#BrVjfYmjm(2djD~WZa5vW!Sp5u(X~joLgnB1a47Kmvm{n9g8~X
z;jO4vTH5nbU!DML1-7ooo28YimD6#6X0y>}H|JADxV@zb*h190I<)6NmYj^Z#r#0t
ziJYMYNVye#N1T&$blDhq5!T!=5SrBqTb1F^8@w%WYTqR4cn?8d)TrNa-WUwET5eW3
zXBP*fPp{4Cnq@8IZLjMuij**yu{3|d9S}tG!|3xR{FIUshBB=(&}X_piWd#|a#TL`
zw}=E|Z{eUQT1k#y5nV;X7I-Th6<Dgb0*RP=>AqF87Gw$d>rM#5s#)09^>}JZe)Gkc
zT?qs^^t()JcIa`mt*Qgm$r!;4UAF5ACAa?o&54|tg3vPqkS(;bsPw=nkya)Iotva7
z(WsR1l9t>B!|DKKSCHN4_2~b!$*D~9K=|f6=^|<oh#Chls+O`fI>K~e9n=eCHw~o4
zY~?`*3odtR@~z{Qgl0oIy>5-9Rb*}wH}igsjA$whf2tH8O;54E)Fe$xnhV$%Q$f(W
z{lx|H2G$T$&9Gdx)urhMS6Uf$_f5~a6;`7SfaHjAo28eQ)oXydb6iq*LZ7}yUSVhV
z5IPp444w`NFaV?FrIpgEfhMuo!PmTNy|W_CnD)hHb{O&_#3j1b0cZfFs&#FJm)!6X
zczJhwCpBKtgp?1|I{MEz?<-e^Hv}skZ~lMDdJizkuIgNLPR==>I+bHrS9Mochw2=r
zCv;EliJByhMw*c{%19cNh(bbS1V#uW<A6ZeCK!L%fIqOYO)}W#`r6mvfH4?9+m~x!
zu%AuPbn*Uus$0U}>zb*qK6S!A`|Q2e+H3vmU*Q!+)-1u4Rp1rpd3A)gD|bK7l)~F5
z^In0@i#}W$x@GLtv8cC}_wp>ypahvl(<a<zCdC>GkJMQ31DKQ)sl3Hfos-n4ZW|oM
zhNE)McNjY<mzbd-@F+Q1emt4i^GN!g1}y>&fOmn@!j`=J$l)>mHB>1UjY(s)Ojp^(
z=>j4;@Un3kU%n{GR7(|oYLb_|Ivw})r91Q8W%FGpZrj*>%l`cb?mB;<x-uFkBU}aN
zmAH*#qUgtwZYFHm<@F@Y(4y2-gAs{GHiQCy+BrCd8IQ><adLqwxQv%mqK;^YE;~-u
zOvMxIBbJ?^XT>->B^foEBSBE!QmUfu2zHi1W+@9OrexxY60e6Sga}wu5+l<5tALh7
z?u3WLWZBU{W#P~<<0DmoQy5vVAE!J<p{a}_dvK63w1^&d7+KOtNSD7}K|cZ4$j}PK
zQyRnOvK#N`8B4J#T0nqPKv+;<X{7D)k5h<{u#zkTE(|saBtJ{|lLN<sAQx3|R`5KJ
z$TB5J=xPiB)CA5O0I|aDN-HWO6?sA6H5H*7Rx@?_W{Kr>(O^)El|dkl<rT&?N`hoF
z5~pMYy=pq45i^FMI{MDeluN@y#^BPDj22V0Mya&KYLr0xa6m@r6N<4C1S%LCosT9B
zacaynGMz;%P{{Ec`w<k$2E1gLz}c#nN(+-Yy-lGI9*aV;o<=FQ>gPDPGhOkdZ-ktJ
z#9*D}*^*J#%SM)D3*)6qHpL>Opewozr>E|+$Ifa}OQ?8~S74~coo8>UHOkT4wX;qW
z9#;zubQ#OwG>|peGQ4$CA>*;46^NRsQ;MOnaJiyPcPt~gf(vMrDF+lS*A=yg;0MDL
zSYcX}`H*)sBn)QYZRA<`<K8tlvL+ajV;G8~foWz0+!nf;$;y<4&?CnJ*o?=4;3#&{
z@z@PkR9Hnu1QWhP8kc17&eHB(LYX4th&(&3uJkyS2HsfWRE|*)30G-e#jHf#JesB8
z<VC<770oeVa4aCih&0oDVj;S$uo}WOjG$*I8<%!$)?|!>vWGwvC@4a7ti+?OID-5_
zZXf*Kyri*=ME{CHDKyWTLSE%W)-Vi4s7Z$u$Astlal<mrbD203zd_a|<8!7jAnTJ7
zzak@5`W`!H<@^81u#C!~`Xh(JmGG2vw8lqrzK6KKewI}-rbB(yv@Em#ZXTnAF>8pQ
zGn^D~Dx<$s*9~n<Hf6IaxRQMtE^Ur2;#)>QwMvWuL6|_vVEYc&^PLaU5F*Oog<%kV
z3Ejxj99)-%Xk2n)C;l}79=fY~V0xd*NBL-<Y3la8<2vr0Hh!wQZ+IsRPxn#dQWH@s
z6T_C<{8!|Sxizu_wTd*<{HAR?*0Yx77?4U*j^X%xe>Z1w)*Y_xIBzyw!~Hb)Jj~k-
z7wKMk89(z3$LYu@=Mn`GdWJS7o^O8AitO-$l{X9hf8caZzXT|Z^E4hZ!Y-mOiyFvW
zs2@s#DE9N5O`(D`^$DX$@lt8?^W{t_*%=i5(z|q1H=hByh?Ja*i?Uhle}YzEstZUY
z$nan}q5db*+Bv5Ge%X|)qT(pd=YwpN>1mp-u6UmBQs3ZM8^gqyNAj>8J*ykK@iN6U
z7-@}%nWl4Ij{%>8GC{M5f9GUNwq}3|VUSS_ZRelJM%m~q$mJ;<cU{l<sED7CS40U#
zycNjEGq^ZXQqhlp7iY`vJ1|nLz1cV$U-TTuqn{w$2Adzv(ip@*fDGAh$tKz4&ooWd
zT~UIR_&pVaX!BtYj)&O9&l_Slc9Cf3=47Q*Fp-|(^?%O52)QMj<TAZXl4MQ<VGuqA
z3JCf036kj<1c<K2ag?DRFjdZVc-8D@p#Y*baG)+dE-A9S`Ag+|CHF4^i*lca1Likb
zk(K`CTsD_=O<l7_<E&TuZO6BRoD<p+?F%%=QR3#kxlA^p@5V>WZOALk8BXjUPCzsC
zDaUqDW)$)lQIEhWJ%>gG>lka!ufn|?^}klg<dZk+s-|6^i89fLNx!ek9Dd{juH(38
zMOl*ekjA~wC<QU~K?#*aH~&J#PrzA%@$N7RqpOlBnf;$;q9mkT8r4dTzb_OE#h0my
zqWb7hoQ)QaB(<cLBhA^x&>p5V=#Yqzu>1cM_<jJ@gWLp`?dPDwdA<KZ(wjfBEzQ3H
zspldsa{V7T`6&9P#5$%KC@6>e5wHwd;PVKa{}&MssDGK`@y;hoUQ;+zjG%UG<ar^K
zM<EXaX4mr?%W7i(O%8sj0~p~l)YA6@OjE=`3|xhh5cum4A?pxQOQaarcJ2N@GXT<v
z4E0$}*YrBMseiJ4-~KRz!l#T#J?LN-)@{%B`tO3~qA4=C`YO~f?O`g~{cj@XsB(Of
zwE5c{WC0*S_o7FYaqNhMQlzBm{l_4oAvFI^hctK)k3;Q01+fdUStWyD2v0$NJ%Sk4
zA=S|Ir=S9U$1qKxtu_374G4Sje?tS|jsR)8%tND3n1*3~9Z^G`{W@eYOaz=vfDC2;
z@`nbdX)VVv$P#!x$1@@l8llQ*<ri=`#~lV^iC(8Ho~0yT5ltU@sehjiadHzB08-6-
zr~xQ}{~)u<VtHEpH$YHmR`@n6a>5^BD}Fd%AcB_qBs8JcFX8#HyIAmB97ZF=e}mCL
z3*SVZIZd$~ZIeSd#$XwW?vNqa{~MSOQvZt%0<lmLhj~^IrM>{MME67r&w)|Z&Ck*t
zHN>*8F8COl+CaX8@J$ASM)@GDAT$l>k0|uZ8^4P|iyGI83j7pDlU5CrhHm~6jmy8C
z$e?dQI6%8X$KZ!$cqW3H<X&)PFmqro;rRZK$fOyAErH;g9Fw`R%c2EKaxB}j$4%K5
z3y}UIWR_ue4UA<P^@jyXpl4NCR_W@<WGfu|y~_P_58O4m>x;)Al%UZWo!@|5Q$Vt^
zd?Q_4vgR%QwabnsNs0+GO$f|$(gkPyGvi)K@nlagw}h-Asj*-n@+Ue7J1Zg}Nr^1T
zuBpWIs}BuLDoS3AGkK(4vEb3!k9^mWo39kgp4WL*Zi>zFs)HV~d839=P<!u9mVG6M
zIF&uCg|@#(ALB`254bgufg#rh9Z#tWgf1m2nu&>|ma>oCbkpgEGu1c^gcG}nuy~M!
zdKEJ;3bSlp1NKlJlDP9?!!{n~^O6`^iU*s6)lk>ob(n}(Ma=kEGBYfX^d>3DNg&OE
zd~$3#XmhfF%q}*7re+fjMj<b<$jj8Hp*awRV|7IWffq;7SZ?_ij0ouG45(^=mLfrE
zv3Y=^bVwW&DVFf72|})r<%<-D`N0dO%OZOX^92k9&<J#V@I4~t46Q2`$PAD`19h$f
z!$O<hO&LmpX(N^(Sdj82=7mIIh0>!m3_M!NP%4zZJ_)_AWh;_^iO(oyoC#JfgQ-Ko
z){>BB%8v7L(wJAJpmmfm_pr=e0xN+$2D6<8E0@Xec!(@rn3c=JHiEh^6>6L#fI1FY
zGpcE1kVplgp_Db~QKYvOWeu!ptS?kp2UrHfO$xwph@3>3Ufg0R7qzryo7On4JxALz
zNNNPeLaMXISe)!Avpg>0!mt6MnJJ0~zaHCoHo$a3OtW0zFv?I_!4!;Hv{s;MF^D{H
zG#D(jK%r!iESUFP6-TrntHw2fr~Q^=he47pEbXH+J(Uhw!#08R3usBmB>~g9NJ*j^
z`B)J!Tt-CwX%OMq5JeOyo%S0Vw*)D@#6VASU$Epke;?g0jWZUFPA4!7ED0!*IL9!+
zWni^{)Hv9dEEJqX!T7WA3?NVNC>bm&c3PYbOcfDDfV8r(#7PP;mL4(%ToDm25GNGA
zktzzK0Zu`~#FQZyVacJ%GLMN5TOOtxrK)%^fMzgR3=$h_CKjGM36GOiu-t)g01i;V
z-Vi}hZ#;|_NCie_iS{)>H^=HcZJ>3KHj3+M`c*1hI1b%+1s1>wK@tDbint&uVNiYp
zg6>u`G5;F(1jP&P4MR8%jSb849Is3L-I{JtJ3$k~t;!y-$HTas$q0`?N9@*IeZLZ_
zPcUSnDj7(5T98WstYO^B$kS8LLr#4Q>or}I|1pfBpFrM1BpGU;p0;E6f610~s~y|V
znVR{4=Xo~<f&Vznr$sBWX6)GMKdWgn4ZaohF6}$EJqM}R|B&jd|Bq!_S2b1H`~vNZ
zJoPSgKnPRhVd&Lgvjg*e(1x!wBeVZ`nBJ@CWDxT4zKo?Q^th%MKj38CS1N(}?;K2L
zQMesi@)dZ>oC|A-+x!=-TV(31bdIIH{stfObk{bl^G0a?G0fjzQ!>CQYKcf?F{eRk
zHvwFlObb5W2lSCBQI<NZ`P#hd>7O)g%Y&&h53{2$b2>XG`SNQa$In3fUJ^YvkOJxy
zRKBJhr7%xeEhFkuLYo+?ETy=vvtsG?x79#ifLQ+;tAWaqZE?U3PaqMVhl$&N8xbZP
zJ?2>M1(+i<wrRZ{UAcK2%AVff>b%Bjf{dc>qvxY2?)MGL=%_l@(EWJ@&3*`&oE6X^
zzQTmkyI0IghdeBZsRdZ>FipMFnK*tmOi_3m#E;O^BB6y8S%s;Nz{KodmKZe?qm2EZ
z;^;_~)y)sXj-}6dw%`9LqF92!NqSqz_CE$&ih4(q$*$|VwHD`-x1b>XJk|)CUqC)0
zN52Pl?dB0c137RgBF!Jt;Sb^{dK2v5{-0poDFcy~las5ke@F2Mz9i|1M@5e5{uYo1
z*SU`OC+O3n$O_!NWrAQvmKI<vJa6a2ehr2*U4ZJHqXWr%1I)#PnydWKwe9{N@{A*Y
zGtS!YgH6@oc#%2lCEh-?^=1YujVTE;lBbHWk*@s@7V?4m8r%a0bpv()v7v1~Le{KQ
z#*MB1Pg&lPJ9wxcz?$%=6PPb(6BHZ;m@6zRcmNgBf(^y5V;(Co39x?Q`W_^VOx*+P
zt&atd!2ihi{r=x#fy+@}hT#H%-v1#MgD*gyi2dETAq|TByI?_n5{oB}>%R#L0T)w{
z+6OaD=qtn?`zw~;`~l25tXLJ5k71mB5er|Ko-}hOnm274R{s;Gg?vw*7r%ua->Iq^
zbrM%#`hSDHr?5_YQ1z@S%~9_GF~jc=Tk;Ed4xa+|0#ItS`cD7`<Kk}<c*=msrH6s}
zS=guODn|b%FG6w9STXnCMANbX;ScO6BRmYF2vdZ40&7uI{xn%oVt}6$VS!^A&B5}c
zzwfhw9SM2rjAhyDu!E37DiEi^CQ^(sBw!3faeNQDg8OG^P~yS)lz^Gdlwd>mcVWU)
zUxK4%Rp1PHnk*mbAE6J(^8c%_Eg>c$#>w1dW%SkN-;%xpZdj#GI&DGDIGeu;?F^5Q
zPJIVf-sZO?k;d{K>lqG-5twFw#L0@#Bfc&u*MEVvCc@)KJr^iYZIo_cjr@O9`1@#~
z0=YO1x;-|4)lL>38w}fj2$S)rz^Xz_N^BicTO!U7R-hF)xnSkFJk|euEE&Irc?6mY
zft_#xxr5cAkaam`y<V_HYaUiPaugJ*1_nBM1+Cv9?AZI$HR03TV>>QTJ`j0B$fVs*
z9VKj-0`Rf5avJv~&d?qS!|?E&)&@Rb9|7h`B!8tjtJp@iBHsPtiv-|Fun1mV&&9e1
z0q0^0M;UDMg$Z)<T6qF-^NBiLEC|GxOM+9tj0{uo^^?~YyCbel+{A;k57-^CWt-v+
z9}w0jF?7Vz$(7JH65dPmCE*>$hrzDoZqmJQYVs}F4Oju3m}D@)o9mIYqJePX<5o!n
zc@M~P5<4#<jSN{?q!-2)DIuk!2*|N%M8HMV9><bgCfo$VtYFqjeahssFbM)4<imZs
za<YG<{=WLL6Hae5bD#vnyFK-YnJwrKy%sQDRh&AfWZtYxjvl*~Iol}?9jM;wj%80?
z*fT9s2WzYS4|1Gcc|Apc^=)rlDl^Lya|g2vW4pmxrN$5TZ|#5idYuyIbZHK5Mt^dT
zx_<QB-qO>LtY4N5ZRcV<H@}u&xZyg>46$fwjIHuV7RI`Uw1~yKsJHH#P#Q}G`8~TH
zvD!MD%fnq27^P7?bNQa7ZdU^V2sh4!yJkdwqkUi8V&!KS);rpQCTY%o=l%u^x2XQ^
zI&Ck%vU>g}zbEDdB{Jn#1qVAW+-x;km3CftxGbxA=l?Ewa^L9rPGc<c8zn79wnB4m
z=ps^7G-ckOcIfKTBs|mVsY@K#)c%myT}d*r)UB1G<ffyosk{*%e)iy*ODl3+7FmDs
z`Ts#nPURQxzT@+EuKu~uzHY9&`vPao8DE(=OFj2>r1)e-eI^kDHxY*R9D1l&di?OG
zp^$?+F6Fx2#hsNaH?OwO#!(LR40Leg(W8=yBgWw|3D`)DHCC?qU$NSUHJV@9ZTU@A
z<dvblM^0S_4wH>2M@y$qj4XF<vq$09i)MB{ePL2hY~8$3Fl4&~S9|q7QAwtS#+16=
zwX9&A{o|GgzTHvTIK8n3wjIe?{AYdhyWSA|M%7&2(aaKul=qbP@VEFG?$bNIgeC7A
zz;pO#)c*o&?RRL64(J*^LQies+ERcN8MuR?j**zo*hM;xH4~5-=IvnmERYmCyvXRp
z@ZLUv%#idjY{XYDO|`+q9>k2(v`cbi9h6>!$(oLO0$CBrZ2g%R<}pr!zzw$Hom>a4
zOke31%&BdB8~GYhN^<2F?_eNj$oxawJA~JTd?K-DoHae$R{A0Nn;&z>fgwu6NMsHY
zp+VX*XhRx~ODA!!M)(uS(do^i$;f+5<pDYA0N_Iod+|`5frzz~);5(ZxC?@O>ZDB>
zCpX4V5?V3H4+ybz_q6{Yz0k$!-2kpcIv0Q>BAR+B3I_)uSVx+Yl0o*;gnH5@k7O}|
z3x)>+7vZ}lI2)werlNPN1JF3qRwC=jy_1_kx1_u*Q%ov-dT5i7iXZeJT0)wM{AALE
z`XpKf7#crQQs*c)UscC$$HLJs&Fw9=)l!wKv=uj)Ny1zW#0?!o1;0WrcYiJi<f>t0
z%5VZ%^V6BYHu*?cD%z#Ig<PJfVZ^MiVr^u4xiUPYnr5r2Sfs|Y3@cb>1ekV=Wsg3k
zXf}V`FnuNRY^E?HShQJaE<W@41^>7|IX!VhB{Q}(7mrSkSiyzRZ;scsAR{G}PktIi
zBKkgGx-eyhh5O(Dw^inx&$H5aqB?9*m%voT%#|i_t*oNM`yuQ-H*@#2s5kHJG<l<x
z(5e!<HsUn}!4bG-49iMfneSMox^rv)Tj#vd1-;kRbjt$27gj)th()p&E7EnF(`&4%
znZit{(V~H>MeJb{ft#Al8wF1%P9Ps9tz;{-n>`Nt?oy|~(Itx!^Y=(!rGAXy)8^}E
z9fr-^&egz?<b0bBbFjZ_!bpzzojlf7c!!SQNK$f<WFXGj%Q^0WyeY&0sPnppG?~&K
zT2H7pQZ0EbC_lD-BKH7W?p;6iVExF-qRM^DDtSeJs;HXg1FCN4=hllcOw<LItAj~Q
z%PK*QVofvV?0gVR+!9aJJ*;YWsl7=F2`~3<>`fFV-`xiW5N%cmrreRVF=}xoTUFW$
zLl}T_qbI5Qsk&XX^orz!Ga(~s9g6nz;mAJ6NlN*Qmd`GF3D&ej&3r~Zb8L3u?n-9#
z&dUdTm+q<9$sO~{6QiTE@XgUHw5g48v#$t{`#O8}JbuaS@cO%N$u_b@+Ay2W0x}NO
zs)M8}QyiM!xERNPlppa_#V*^TthHw(mHN<fCL=#2VP3(JCWCF3QmaU23K6}t63Rbw
z)YZDtqYDq^PwlHn+*huBR6n^;rE1k;U{B9s4enx$up?3h2Av}QHvOT6<=AmDg>#@t
zo6t!@n%o|X6~p!w$|x~8IA3`s009oT4E2MKE0-5@qA`(^nLV3#QnE<D$AZ6=8$wR0
z(?8@(TH$Kv%7`R!lN_6e6GSva3%Qb6<Pjji!Ej}yl*P>Nt6JhsvP&ZWX3*b&Sj3C(
z;Pl)QtWALjXUGn9$Ho3@h4*orDYwau)GMerQoliciu&DD6Z{qRozzMrk}(C#3J{j%
zR0P$xL}eZFjxY=mK{yagwQ-VUPr#=H(oBRhfFBSjr8MO}-5tUrHM?9Q`H4^_a%Zsn
ze?N@qmVpvUK^NpS6M*pwgg**vxAD|cte45LNY5tX9zw5HCN>_CNIo&YQV|9;VcHNP
z&eCg=-$a-X4)TeNOD_aDH`s*ZQ`t`1N=}8tiFAeJ9GHJzjR@%UlIi#4ut9Sn&Y=&;
z0lsCDt{A`~vFpzoY$?IT;A(_AVjC)qe%$^@;FBN(z*l^#Q(zGiF`d5BE+dyn&yC-t
zWn1m3re{E#i8=w@Ssm}7P)Jo@y8AX*K^SnW0D|y7*_=+;+cY@|4L*TOcwvkkt|519
zA1kbL$oOm_3g7e%OLg+SDZOgks>e;Ni>UfuLkq%s$=b7=8ByDDHgN1@cBDC9J^Hrp
zvXQMFh`WWJU`~~Sal4!i;6yEmEAH9azN9Wuj*VD98!_#S0U*C9U$2*FIEh2cj5A;g
z(uaDvm@;=sx2ogW5u?<2%RQNJ48r)#)UOm@Q=9~qw`Q={BUkO=Ou1CvIGw9qSrFDO
zTbmh;z46jYE>|5|+Wq*ETsOMnX3k9Xj%H81`Yro2^Ns1-@13aMFh5rQ)5fa(AJ4++
z#bP|^GrFm4PQB*(3$J|i;>A}`zq~pzp;T9=H(QGCdeRbC3&nkbczbUD{%Wk3nucaZ
zr%EjmMFSkaJi6yprlKn5k~Ow-t~1=#4nF*IAM5YS7jnh%up?Hai%Bcz%FOf3jq7Wd
zkN0-X9^U-?^4#2VP7*AO`%CzGvl`-f%Gr|1FqUrlhN+b@F(`rAhIpW)$!x7A-NXoD
z)gSI!c&K(qI%fMVrdBHPlgfS>!Pg5?qMp>*dTV24=aJWaYW{UjI9gsE^?=kE2Y-%J
zl#M-xRIFagWmdACM%|K(hT5*{Ecj_z=@wzQ%4Y-Lo*i+df+)^(=A?t2{P`!q>8)tT
zCPu4=ihgxnuUWxaXL|kTybMUjC{8&U-rcQr_Z))T6|A$%{O)#je7&W%TH`KzX-Nup
zPSqOJ`Q4Wv`_jl`S6jbv^)r9<mg0Rk+-65^@lYxE#r|LQe|VQu<>6uNUp)Wd)f;Yn
z`OA_1Xv6u#=5GFem?`=&!&_A&oJYJ`SmO%0VR!7S;3?Lb2`5K)&NhopFb!7?bMc@W
zEE!(d8XjrFvm;v7m4i>^^Mx7N9?BGoEY)<w7rwoI=BBlc*R%gMzql~1OQyAhL$1#$
z@q6sP9q$F-+YGfrt#9XZY)>sP#1T0Ip+jaQ`GheCq*{+qGhh?;gPbIGQkU!r{Al1~
z7kq<vvNL8b#8bLsjo^s3rZQHyL>Q$gBO>7Nf><Jk+d#PVCTmrmn23XK$QM{ULM{+W
zZCsQHr&QYD5~Qu^g;H5NFlYx7D7DZ$@@0DJ^eiuZBGQA9eiLCwq|V@lzlacn%ozL)
zLK(7wh!w~}NENbsDqhJBpnoAYWZG&_=)t~+VA&Ey;`ho`;$~L)p=!t~dIo4MiwCu2
zG8u-1_g}ti@*6k!Cw$3|1?Lwv_?(e*wn*4VRj^&+ndhOL;m1y<uY5ci-F?oZhBND>
z(rEs`!3S)%gwieC()7r|XWW@?EBZ%YKD0|4-gzWB^NC;Xe`D?KeEpffe)*n<pDO)j
zYomUpb0e7VzxBwQe);f27vJ*C+Rhv7yAM{q{d0|}>Cuk&*HNxJJ+gRx>)`PG!urI>
zUE@qH=$!oc?`iqmr6>8`zGFxX@6L_i91pV+vobjXFw2+-l8J8eK&1zE0tN1AxwC(I
z-~IC=Ba>hRR3#x+JXJVhCPo&#ZkBI5)gf@!)5cHUoSCT~a+T7=+N~rKjj*MzA#ZzW
z)y%Fg7R|W{TN;<n^VzJfuNsu`d3VhS6IQ899L<NJQj(IAJ0lH;9KXAEv=ii5c8@3T
zE0=~P+s-=dF8J7Gg&S%&M3gk@wq{grt{Wr>{IGY!y~-$B{-Lb7sNZRK^4}h<f6e*#
zVr{8Z9c^hNh$nMNP%D?Ug^_VkTS!L7_alwBf}j&t9N;Ci;Z9T0$6_DW3@w$XN5CCY
z&`T>+wZNPDaPQ(Mo7sQbY)3HFhwK{>6SdcyaA;f4jq--0`{HOto0>BV3#&8V51P3-
z;0UN6x7+Pe-zRizJJ=oF{#S)R<=7n)J1*_GYsaI583|e{G6*@mr$arRMr3vjCIV6T
z>69A$jdwCB1Q-B;PX;YKPDF*0x#F4I)cH`{6^kfW?B1Iq`Y|;Q;0+^Z-#WAKr+atb
zE3N(ZFZ6%hy5Y$?XD<Ej6Q8>2hO>v?|J;Y4e8V&Mee(b%-tw@SJ#gy4)T6)JUOB!t
zviF&Xq?b8%+~P0wfBdTVz2V8{-~HtLI{m?$hc91M6>*lnHKX@#L@VC#LU%P&U0(fw
z9Bkb6WRuOfXXob+vcG@N+AfXx`Nx0qfw#^4#@s^>EPlAO@6sne^7Z%anmu;#(6Q$k
z*8ln2^5)Fg?q^qox!RdOv|lwXss8xilW!Z{*KYpWLm%lr%v+_Ie|R1Bo2QS|A1Lz8
z{#REUnbrO^yHtJXnd0=#yLQ19CxH9zBf|4Mwd1iJZ`$$p9Y3VrP5lD({vA6wcPORr
zPkWhk+&~V&G$L5i)IuWm;6Uo6Ujp-pM?)5jM81%Ox3n+u$BSDB_R7{CFA1Ae9u2<3
z6Wiw14t!8`L*zhx;eDH5EPa5);vs%CpO`g+r%ogl20}`PMIL-wd|)s-Qt1b1^JG13
z9C^}cd5v&<lZF1E#oOdf&cL)Jm*KW<Zu{=ZK`?t=NWApkdg=Eb#2r$hQY$OHSAl#c
zVsLO=+Dk+_lg40PfmA5%pmZ>&H-fuB@)Xe+Xv)uQCc6<JDSoBq8=H>NdP(rG)+X=5
z^ZhSh`)j*U*4Nff%p?<!cZVgvQ806C;d+=grM#rJ8m%~*6TCbXjQRQVk4GgtK)``O
z7!4Jf!nCB7>5+$iaqj9@KI+yEw;Pr{wK(B6I_Jvc)46ha<|l9EM1%?junY?n`&3lC
zIi9`slV5oHVz6#|yRY8W)F!mT{IMHWhDHzE|JfzIl@aZ+sYvfdSNzP#f){!`UC5S)
z>s9aiu-m)I9o7y#B~MLv{htqh?!m*;W52a9=8d-e)$3)oe_pi@PAAvT^L1mzlT=NP
zBB9U}Gzk&quH<E+>iBNn8biI1n!r!f<s2{tlo(b+zMF|QPJ}g18`2O`Z3VlN`cyW#
z!4ZREofXfAhuZn6o9%8+&Bf--cW2H}x1G6fhWqjRIYChzlydmb>v`NB!#h&>x_fW>
z@cw%D^63#ikwYiuLBwcvx!?O;+y{uFn}yu&$e1<ap#}E9Ge@4CJ>Pw+Ddmp)i-KFK
zp>RMwaHdDHQn4o0_Se>!k%wlyi*m4V-z|3^-@EV9eL1jC%6V&X)v?TkKN$%&Mb$L~
z%&zTv`p}gFes%2eQzP&E+|t^qU9}1?CB5Id^alsWn!Bz9Z(GpMXxUa*9=>y|JaodB
z4W`JN2g=#_#1ZqBU59A(H;<^J>f#;uChEwE>BnBS`SQ9o-_tRXDNAZ*7%#fxA7@@R
z#wUCBIb*UoXT94hzoE=}O4L%CVKqO4sTAzJa`^&6jvH^|4(-CaQn0xiWslSW-Kid0
zbF#}p`?c!19v8a&v?&HjwW-NMh4*fK#4PRl>sJ+Lin4_u2B>&|>e;YVE2B%=jvbjD
z8~x{mXSsjh@ljM-`P_~#@Aw+HHveJA_jdf}j!gv7ZR#lXr>Hvc&(yzBKLqqpr9HYr
zcTsm>H+_sgKZqG@**K|48rVE!rf(|)%rCn-)tgMsF6=Xyk(l4ufvgJ2Bq9=vs1IV%
z;P1gS#=b<R4LB|b%4A?yk+Tn8+Y7!_%9Mi6_FjXzIglqrMB*}o$qflnCpJ-sh>Ci;
zA|uU))kgTmz;c(CO@LHO?L^?p)47d&U(_MY4@ll12dBv5Efszw>2Z95@Rp%Po(o>b
zUKhw}B2`jhHc)J-JR8`Lq#-Yg)Pbl?#c_b$Q*jM-mrAHD8b`A4i#_=>J#4^dh%dGd
z8Qf_q--uo%jV_baO*k#LUvNndx`2E+c#U@<tBJTC96>gcbjv!qDZfXY#^hO%%vQW`
zgSc_j6#)MoE`X));MDL!E>cw@B4MhgcDILbN$-+66NEGk3WKzC&^kPc)K9rYk^DXm
z`T&-9kRI=Q>FOU8dPrF&8UW#wXD?oVwDt5`_RfbWiNdRmY@{a>@ApRz+;Z33PaFky
z&bUDB;X3Yycm4?H+MrZAwb+U*QQ-{EZsnDO(-1qF92ATk2nRgo)nmn-_g~m`)9po+
zV9`v}cG9h-rzR(tI>Rka8(XO_9jI~nslC_TGZm{8Y&E;tDkUzsj>~RPZ+Az$<XWX*
zl}ZM4xunMo*fUV~#Sy4N|B+&mwpWz?p-Xi{<sSwOjWC5!Ual?nCrS_IGaEA>L)p4f
zH7f`GuP4$f9}dSfiX^d$&Agw6eF%|^l3D#gi%(7^M@P;1v)$(5+B1^(^w`3r@QT*_
zXytC%&Kw&V(fmTE`LM3-pSvY0o6K7g#c83&VX-0?-q|`GP97@JqOE($x~!k<%uPx~
z#%i8?)B0mp{%zfZ!#B^`rN>IjNoI7YaB66ee!hEuyFH$ir<Jh0><NzZ>Q^T(zrB@f
zhwXB4IJdxSvFg+&e}2_Ddg!Ra^#522f>tLZc+G>GKVgaq>zuO2*mzjoT+CW-@Jhxu
zLKe6ke$2P6EL*p<$iLM84}CPt-wBy50SYpor)hUcTLZ@$AUl%+IFH~IY%Fji<$VBx
zPK5jWPvzutFv?Mh2Y?%p;vBmy!fWj%CqHuOLc=?~f3YyV%Wv(itUt9!b;FI$C;fco
z*Bc{L?Z@nFMIELcGf^vt$-3WCg}gltFw6vSJEq$5j(KrO&vc`3Hp@PkDA8EGIhLJ0
zegAxGtYep_a(Dj0($cZT#zm+4szp$F3$5ODL$}utk9C$$u1#e&^j0D7wcTK4ZgP$J
zP)~bc{vq?4e4Dk4zdat82*jKQbfH&I<Q017zEH_C*0q1(b}L?UEug+LnsfJ2%*f`)
zRc-b44)uINsEh5*PqPSjIrm3hRkI8Sp=cCV9BRCy9+(}8v9(I!H9^_yntFZmNcaBJ
zZ;`#)FE=HMA6gs+S;)N<KPetXF$nM44evQ+H%AMNw!gRZqca&ZxS3yh2YsQn06e5S
zkF<Sr<M}u4d!)MhS2M4;b>%i+t0@`R64c9$xmz1UomTs%-26uN^7_@fl2tc`s!PMS
zEgp!JS-tQ?zB9guk2g+i_`mHp!mjBLEied3<>MP&=fErz+sqf?P-QdyFPc4nMr`mx
zD>6#qEF89vf3yUu75i^lc0xSQwncwf%Vs8qZraOpD_jgP+V7XgPBg;CtDPbM1G6ee
zn5s~Bt%tZ<h4cB4tUt0lmVY`07(s2v57OGd1Tydx^)&TK>T@JUM*lkf+w^DYFVWv&
z>dY`R!z?lTnCqAunaj)_%>B%(nAbCJ8t5yMgqMoaf!G#OAquew!3Qxlpp;L=IgyP2
zO#qX?HE}C!*@N&AxC2r8qV0(s{H?R1R>zCN7ZN=6CxFTUt08zydwx(K$W>yV6EhM4
zwN5W}%))y+uu2D~9{5C&0uByMNKYI!?xpeVv~g%Mu9tcf@d?tFG#KB!^g^{wYRajX
zL41n!6RuT<j>grHi-<%lT=Yd>EL6upP(x=7IBVgt7&uw6VT%z|NRzRNN`UrEZvj^%
zH%c}UZ82DoprND&5ZPe~fpw3xoEHYGLTJh<5Qh?<3tkNT$7!(~+{g9{=SxYGw;li*
z4V{oWPJ8H7awhyskM5ECoq{&UO${C@G;a_0Nj9UK2agZR2Q5rr=%rM3fqJ$+P||27
z={lsrrRxLq2^j;zi(Qebut7@(A2C$YhLSrand3yok!|=J{hqD~$Yt?@#zcA=>=|MV
zq^Jq(v8CzB?j)!OV+8x82d114y{&U0op5pj@j#-uQw#!mjJT21<RC?$L2fX(C4ryp
zkbvZtF~E?UHK1L|10fD+P$iVpeX(iKb%O)J8#3rVbnn1VM4rds1)=Qq(y>MQj@%Sk
zKOu{~hT+4fe6?g*K8pI&gm%OAkqgQT<cZ<|mC1$cQ^<ZmFJcpECeB5^t*6h8+*{d`
zxRH90^?*}1=xC9?D(u`n7U{WhWKrzTgEU9K;il8K?@_XiKpHtaTyb@ke{`64gl>0!
zJm0BC<vQa@0iPI$6*RyNo8^ucv(@2Jd333?sxy%fG9-2W&swt!<xp~L?)moB*PmGY
z_i6Z*r2=Yl!91ao2wENm963FZ#<lt0kW@oq6+;Kj2q2n{rX^WJ)FyYIUQDV;3=nsr
zKr{p9)sAT=)X?ZoMw0hLQ+xaO1mT~vKxs?gsqCGS?6}xm9C|xai3HW>UDi?<90ydq
zG!L9XxzUEATpt}(UmbvAaU`EFvGZ{7h^;i)j|x>o2c!+KUL9PhKrx|c0PEY5Dv<ii
zbOm)^P>_N;;>17{qnrhb3<LNF7-clux)sDxsIW}E(<+*kqLq^v*%+Dyk*8QXoXZv5
zEP_|Y8F#h-sXKq|GghJ^Rw_u#!yG|9FiK3l%d&ga8}bjiW%$G-4~cPL5tWr$6fw<}
zvI)RfFsTSRXPHLe3@9y?qZ|wQQ#uMif_|0v3c1pXwbOe1;>^BUE~w;D*J7@5oJ}%~
z`ZUMpP-4eqPwkv|%Y7A7%NlX{jg=1apqw1|gOHrmL8xvfG55>0gV|0}0Hb9iG3&Fe
zuREL~Rj3ZSB?yH6Gf3qS?akW=Ec&9y!XwSoMX&#(8`Q#H72#JsUj!n%EF|VF7p}<d
zN8W4TPUOYo6Gz3`72v6;LLob0Huh3-mg}9f5AgTz8nPK=0BXp-V1O%3b}qa!7%$HI
zFqF7!W42!P<<NE{@9Zcax(7;zu}1AhZjy{BD(F0ibr#H7!0H2%-~W4Q=k6#OZ(lpg
zPw=k$$^}OL(0`0wI#r_YI?J5dK<*RUeoVV*q{9`m7SI1Nzhv9SIN;*~UE4|TKO^n2
z!s>!i+|{v!Fv`>7qZc}LbNX(u>dAWJ$x$iWM98vOC=BgCueA+BmV!m;t;&N_9sr2b
zvf9y*;>B>a=8C_*5CaycH!G+hCHi~<PoL<l<|p{bRJ|O{WhO5lI7!W6w3$?sLDCK;
z5V&voVP7hjP-Tyb5x_(RR4~68$?WwHRkFLS0>hUXVe$6Tt4cv#i>%SiG#A36YLBtc
z6=m7z{|?+VRDeoA(NNf?nSy4rwhR=!0Omj78I6EJHCi5Uca}w|SPr#PGKIva1TH(a
z)1z5=Q6Fv~eQ$_Yj_yMmBbTs^L-C#^W8BbsiG*R;qWE5ws@K;$c$5?8E>p%iY7UIw
zLX`DDjK?J-p~`GR<%#{*DxqBn0I-q~Z>@m>H@2AKu-R;DE(tVw4AAI`Px;KwK;%sf
z@FGI|F6=S*W%d53ABc4I<lDRv01&f+kpV^zWh4d6Y-NNAJrw6=K_02_g&7AV$ta!<
zX4auX07!o<0ClCpk0GnV&Qhtf)R`!)xx?;3x4sLt4adgTvVLLWj!R3F5LSGvy<AY)
zPEROIg(DM4AP7dx9CfR+*O9#paD5rn8E-a<FE6}t4B1*L<D1DS+hVdHhePE`wi+XT
zckOTaQl7?Q1tp6A52Fy2@8*B{GT@q@aGzL-vmN9ks>`pw%6fvQUDwO6tx{iEJ9`?`
zs(X*C8x)%)o-zsG09T_IGjyP}IR=<Spf^$1TnxOc!H`~a_wBTsKLA`Z1N5c>XFtYB
zu=x$y1+3j?|5Y{sgJh(J9L0f{b@aY0t`$c2ofMjP_rE(=&e5erTXY0G(?vk|Gl1<g
z%MAG4c6hMwJ}JDHJHO-mNKZ#CJL;!&fgYw$(>KvqP~Y&)^t1GHsN?Yho`b`TGwaO8
zOEDqn;BCVFlt2o#vWe~|u^_1Vflf<x@U|uJ(r==gpqa+f5IC4b(q-?9mLRm=w)bxm
z5F2vR!7tSI+g^5Wso``#oGev?<U1&2qWHJ1n!#`4EJ$Ct1pFIYN}IG0YWQdDwp4#(
z>(6Yj;R+1#^pao|v9+-Kq)VVs#3D)et%LQRuoemFWnpQhwh2Kq4Q!UJ+a@knT%R<A
zR5AD&cg5fqNuQ8Qr1uN$jSo0c`a&bOKW?=aS0CIZ>F8|?DESTnkbxPJ2G=~|h9PZ(
zzjc7*8gx;5+XFWQj(M>U2JohBON#&vNN1wEKzKlIYw&&Afn+-|PGHZ%gvEFGzvV?j
zZxe?yDY?-F=8AYFuq$paHT21DFSR)RjP_v*-qVUEq`AZ&0SgFDV)6@?*Y?oCSxLuZ
z;E;!e|I{QFSU5dS+kqK}1Jlo>#7S!Wr4KuGauCNfF{nrfrwvZcUD)REo8Yy51#+9I
z(Vsqo?UoHjGr=Oj7E5=5rHCa!+AZBFxV_VdkMGh7#i`McsAV1fS0Be3gA|1%Lv}J9
zH|SQJ5MVY!r8b58ey;^XNYRF*Y*C~m-DRL)??Xbk<)M~z90DcDIm;wPDUWP-B!Fng
zP-_b5GgiEsHS&?IN)dlg+1K>omT(l6Q$xUyY3eeVcDwg+*>GsM=7%Jm%Z&NsqY-nW
z#3`tvn+>BqIx17;z!4tpwUD(F?2>7fsk%MpT-ZPgmDzoKrYU(*GrLC_S!Cw5yq(C^
z{dV=OtNMvA-|3WRkkY>d3SiVP(!e9$s3DaMkRnN8{>%l`+#ZkAZpNe)cV5m@^_V^X
z8Lv4%!9TF}b}ddOctDMEeDl~mEGEWcP^K!dXx*Q?VPRBo6qFVYkV6k3fT-JAfEm%6
z(+WPS^m&wTHbrPZ)<W8VYV2ZEufkFl-i&wyR+*>_iL%l8(h-)Xh9dQqHQ5U^4JmO-
zC_^KGNf=>B+E!s9nprneGpN;VP*uSL=D^U&GWaKd5vs9-L?2+^725Esw&ENW6p*J2
z3Uc(3M5u;2fI^T)FXm^EAOdn|I-?`S54;SZ?MB0J@1Bl)%t9S$i%9MQCJ!2d6=lRh
zZ4;c=x@_Qyq8KmlfT90|k1{qAyc{!teOE*hjnh+Y<c!D+DE^V<B$_+`<{?UTQYZ_|
z8ka<c2~3dnOO)R@%;+Q=iKkrC)Ow6iKu!<RjwCwqpXUJXH&psi8$}r%od3V(6;J>q
zHy~?C8wNZcrY7<mnQ!@?Vl4Xwg;zl+!qAibQmD7Y*k$;Yvg2~S6(<1*Mpo`D*6ZR1
zk5Y*&9Bu|oFJ6M9gSHCY&U#MHYOPyJr8dR-cos;BRIJ5ue<WK9Z#s6qr7=uK8A8Sb
z(qt*7{>qXN!O%^_48`c#AV0LcyVoj&b<RUlCZ9)O=J>px>>rkj5{L?7kbE@jMiZw1
z@GsK|>XJ2G%1sD$AVy+dzwC|*?K1eW71wBVPJvh+U?Z7EqN?D@;Ym5{#B^Ps+HAPT
z{a0|vG{Tx;pFcdJ_y~?58`(q#;ScOAueCCI-l80FUw&#BNyhWV`+9H|!bk<~gog0}
ziO1MTA>+M(AED%ivYPB)(gVT9Is?Uf0XNhtS==JhokLTdP->bbhrJ|$?H&qrBn6RJ
zu9=0ZA<g^UQl_1m@x?Zh2RPMl4QaxBH9t#nNZBi15#tSkpC4)fQYkwC38<`OA;V3V
zWHYuX%gXb1US|qC(+E$;=8A=kideWXEeDQMq+SO*0;@4O&jEN~gNYUSUM>f+2&`<>
zj)EMJgLngVgoU(3&2-f)s4F<$nP&u4;Z{w_KCX%2=ijfP_pd#rgS$D40<)@ws^3UI
z;q&uV<~JltvPi|Wr68|>vKuiZB)tJLn$R37!EqKk3K4zeN?;O1&x?}4WIZdU?Z#OH
znH3Zr*rEX<`y`{H7H<4`lxF3)&2@=c=K%h6eev%Z<G8Vh3Epeu49P)|o!1$paDv<Z
zlhN49)gj45!iSop#e#o7^R<jx2A=zgpXT_GJC2MGflBB-^ikL{chis2Ptrd}KTrP=
z{TIY11r-3pA{Fuw%rAL=zz9k70fMhv-xIM7)r@xmN-R}8L>r_6A74Omkgst>`Z?9x
zX|Wt)wrpJ_^|%i-DS1yXkiL_X3^WJXmY#|D$#5#@^%tWs1C0qqy>$ubd9<9=rh@Js
zhyK9tfub6Cw$d{WY#7``o`3~X?+g!@13sqzKt_WIi<kOuhzf^~1n0qjAHUEA+nS%;
z=Zh_`r~VFNKBek4JsY|Afo{X6k^lo|yED*b=q_@q9<B*!O%LikMfz-)J4+jiz9g~W
zt$V{MU|bEFIdJTBQuBhSWIO@14j)pl9AP^m?Z&?3UqG(2{dWomCq@apEonTdml}q!
z{Ra0!`W9c36X0}%lM-_UpVDq07(MW(Z5a&Yd;@bSeYB|^gv*h*5pIpNlYCAe9NB;q
zWBj10WS~&6hS1w-XePBy$pPf$z@;`p{51mUZQRu;wPp8iwG!JXVQZX_z6*K*Y#MTt
z9$y#ggYyW)5sAHkbLT^3pvr6^Nw9WA=uwndRjyVs{YLXpTbP5uD*`mCjO(O`rG$V%
z#wnwuhq+|J`+Hr46*ABDWP~v#9htRA=^Ry0i5eIW0*<l-RK&39Rg_5Pq&VQf4-Oev
zfFlE|vhlpw;~0}}g|uC}xe%jFd#tH#)vB1udGHF^2_!wT>q>if=H?2oDR>*+KBcbY
zd?4;ZIvhdK56u{&YhZW4+OGQovToS|<Xkk|<9ramh^W^Ij19wou7EsbMMSQA4MY_N
zpxSEeS3;eRC%&+&r`3xt3zfpYIcH|Y4VSCTa8cVvK-(P2nv|2sNY|^HZp>RvUCx)S
zQ-WDQb!+ZMf!s^Xi*X*rPO=35gx(O864H46swo3_4nQ$-YZWQ<j2x<QSS^eRF@*5)
zO{~2DOs8ys14037?uyFBa0EaFmUv{Yf;5N$=yM<R+`Dxe#686^RF)LjY{J;Xc6mZm
zp+3<tPY{3dO}hZ=L4d<&w+zK4n(~<8BeM~0L)!NX-xEQ}L%j>UI?Q1grAC2!ha&yo
zS_p4Z01uj-6c}WmCx%S@kp<(S5CbvEnzTsODTNI|QX<%4h7tZlCng1QeXR25GPh^c
zG1ZJz!7m_l5t^kS1??<DRc>`VW4r<&xh8c^89Cp}a<p$pTqn-XXc;rVr#LIyktD<T
zpt<^ZJ=7*Ob64|(0;mHNNyw``TM1Em2WrJ&m75hNlJ_OEdn(IE6s5daGz6ow&u>=b
z2CdBrqa%yvxF$Nwd1F@q^taJfqMIj`nkYC$!=%bZEXEC}`UI$fHs9nNut<sgh_+@k
zRw&f?@CM|RvyDgDIixAF!ZoC?M<e^;2oOyhsQio4O}#Og2}oE1vA9$<IiOvU@y+Z9
zTwIF`V9*upT7rMWsK_oLoxs}dV|ezWG+XgHY6RW_XL?4lp@j>4G9^#5Di?M~u8+hi
zYbH6WXGU3VmD8o+t}?8kRssT<5z_#dK%@ks8X})vk(k<n>C^n8xnLF#smNJWqY|UH
z-VeuJv|ve^Drd%kgS9d%C`W-_JED*47&+H>tfN^$@q!V<2K|UC9yW5w!1N9pqXKe<
zBcUtpWX$lMuzIR-##$UY++jj@?{cHf{E{@i8<mt)E_dyWio!>pQ(Hc6*T>@QD*ZST
z45lpc+U=kXkQ*xI(+6eKo>>KfeAxdw@|qd$5N;o}k%Y3B1?!o`8VwQL|ES?w*^JeE
zq)!ZofcX1x8yUeq!_sF*Vo)R?C$v4zhsUx_#;N5O2$0Q&pWzpHm%D>HMV+Vaq#mUI
zhS>p&e}p;2oI$kcaprx@XP7@?{*w7S=DS-S2C`mFV+uqWprj?l9#q-nU>lK|ywFL1
zLGKVP1?ih=0`d(}#SoQ5{_+GGP=|m_QST7iTbdf)a<UtFBY@WQ52A$tS|wNAg4mHW
zrssoN-mYW#-!DVd4z5EQfKTZg`7lDGLFtRIO@kGi{E@y-4PY4q$SayyLyR<y%tIA*
zQq4xRLkaqT{7yY9J}{@`4?pN3m5Hc|^bH^Ufj&e7uyO1EK$WL^3=SgiIFFAeU;!FT
z)S$H{2RatVQ>26??id{mb(U%<qNZQc`b0Zn7yQS+!5>?juwm;aalp0;PdlGzq}qSq
zvc3KPw>9l1(jE8!QsnecSP|Ro(c2~#PDf%aq}_;&ZQX4zz1cxDDIF5EGHx~PDn3u8
zro&5pK=f{^K8Zy^Mio2&r2oL_o%STLZl+-W!SOM;doq5AeK8n@shTI=m94$gV^fo1
z`%{M)4`ig`{AtP>03kR&JrJf^5BqHm0x}e!{<mEx_=4CY<kwUW!@N$0@YX}Y7C0Tq
z-&+HZ>^Mge-^{?5wdEZFMLYsM=oo(BB*E`=T#{;kFc;7bFmTYh82IE5;#I-@Vmgpb
zXh`~>L=VxWq@~UP--vJV1Yp9T8`7Po80-(fOlrlDjX01PMCsV*rEryUdPbZh-Ls5S
z6SoaPL=$fZN`m%+9`EV`5{f*AR0DItBSpc($XLh?MOhNb#FA9bE@)#WxNE>2BsWZm
zYn1M0SOC~XI*+xC%FtLLgQrbJZ6a~V3^ZsN(I`j_Mdmb#_Yk3BDIWwYiipyASjsC)
z1*DTtg{-J?5x{)IJWLqfqCHb3JVIdOQ+O^wn1waqWl1!Rmblmp!Dch6B5gIdGb@=u
z7RX@RL#?h%NF2{L3$93DlN~Ngs|n*vdGHH4)nXUb!TGF<B1VC0icsp%hdQ*N2xy0*
z7EBLSr&z(wY7B0XS937jL@2r}6{(Ae^bD&cK~4~a7k(!|VK9N6w}~Q0=!>&d$>2gA
zKpF-GT@aa}%e2jna?pNE9>g~+1T9rzEmS&p7&;=x2$rU>Zy>?xy5f`MsDuyzN;wJn
z&<J=%T9zrQ$OO|tf92>I7K8ydtRgIN;erT7_%vJwN8`ardf3bsL7XF-2D^I*MX`~-
zi^xAm;c*~3gxG}}aWPylf<oD%K7nFjmIBsC+M-3Cu-)a6f3LG1WdzX8h9l#&vPRpW
zK0{QC);S<C;1|JNgz%3bAOPa11YVVd$5U2>j_OnJ)#Pa^3848b6bi8otc~4IQ&}#e
za*BnHQ8lH)Bjll?C=kl0f!R$kJ|GJo3ks(YCEEn;<**$juv3CZlCiO<XRet|BP`KA
z2F8fYf(tYdq)yM&l4VY-v-@ooCCOPN)p5)nauykp$g{NgWOLaDuMfQ!Ww;S*1e22n
zq5ugsw_$@`5je0>C>*jEiKmG-P4;ChXbp9+!%(;=i4rmt>}dKn)XoE~7qEXiS9&wc
zXy7Ks5}l3zd{mX7XBQ6Jhrqt^e~WqW3=Xkncq@F6H;NJOH+V(y^q3Q*2r(d)3vRm+
z<VA4vv?kA8f?*m<u*rtKaL9qD2~<#vHQ}{10=n=;P+SJfeh~H{0a7$zqocT;glEI5
zHiKbd$Ym?<)}F4g!m=yL0(H6b$`-GUcgz(tXLs~~a}C~$xXHzPhVo!_<csi*$dYP_
z1rY5NB+1BwiAm(g9gtaS5|A)E5gUOQq9L32yIGVO<XjCE=|RB8ivT@>J<QGsfH6rb
z!a=B4=fl~ht2R%%9;}xzy=_2Tc|<<plS9!tF0sl^t>7L|EU*;5Txt2r1aZB=OlPS-
zk-D(v5CaOXUAD<O1?&`d0BR~(gb<5(Oj=l9vS%lR6A@ev9tIk*2<avUI|$Y?9ICg|
zu>k(a07>-<0Q>@LhG4Bg5hjp`Wx||?*qQ=U609|m7EuJ5#^v$QiTh9Dj2e7*2=DD#
z0N;+iJ_B|pK2%5GK^2)b(-h<pMXShx8n6oZTS3-mmGh3OBjuJ0IG9EfQYIV)V^$yI
zB&jN+z@`9VRWQVf4NI3|1r#_kY*s~eB+1ttNrj=zSg21(J5eapYyq@&MXmxjpRJF9
zcc@@y{0xHy0~k9{o-?qKegX>|d>;^vd%)bIw^n*RRWmqg&u5W!Bs=?@u!aEv%#$1l
zi*RnWn7`>b8LVbor)i{tGC~cN4k=cc@>gGo!KzEh(AX79g;x=ge2%(~@ogmS26P4B
zVwqDdOSEMTE>J_!g8rxM{m#u|oiJivx4%^cPZoT~)Eom%ATh{~7ITgI8gL4DP~h8G
zG^WR-{)Yq^VJrbA*>0>k3^<E$#s686yL<Lp>l{TeOB!(e-xYp~`@oK0q(W+q`UmR!
zVC*yL1iAcedYqo4S6_-@rRaEA7DUHwzo)5{Bvu2>n7#%U9^4eEvV_tkI7%NF)Pc$)
zHW1kcMU5@wJLq*pV#se|JCOG+)lJkY*~=URDWD9=9=JGhnvlzE9qS{`03!@GByce>
zdj=Ji3F3w{^u--v)J>4SATQF~fuTn9Ie8&PiR=xtiClzSi&z=k78}V;O4~X3VhY9q
zS_TV{9FQh`;CJfD82A}*EKCbrh5WhY+8FGgb`r4|Qbf>;jYzwWTs*Z)(_VlTPiz5K
zuu?V<7*}b}pcy1bB8By&Eg!TW@3<BWt{#b%^~iDLu(a94P}=Gau)BBB`6)gNmdn=5
zA%J0WD_f{mw1yy?VQ!-j2X{nnW1I6GcRJw9#%Th4Bt4lUNf!hz4f_iz25`W@U>rv%
zhZthPl<-?86>r~-wS99BbThYPDz#JY5x4urQOFTZ%0_QOvEIBLYs0O47{!^{@GwKy
zM*V8(rUKF<d46>4!d;{~t;-yL#dUwMY@tGHCZpExIAu*K?@$+yfAHm~aQEKVRLq`P
znHXtyFNf67rO&RfO|I)Gbou%jjo-}%=X{i^oQlTY8J~%t&MV7OV_L2})tMOe)x2$1
z)bRLYE9|4wLtdd;E8P-JtvV?9Ygj@oOr4~S!s*t>Tdf#uuZV}_OA3%Xap|yc79J?z
zCSGg2PW|BvpSDKt9Lec<EHsTujb242Owlv!gS!=O>gJ=<=IFhPS7>8*E3~LeFEb)K
zcA1Hdm$maXRhLlVmQ#-GZalX#%+4<kH&<-;W7JVIFE&q=G!gKVB**SQgSf_?>^&FO
zN0)9@tWunTN1=l?W*I4^Z3@e6xbgM(s2*0;uql|y7J^2y5ygtl{?gDbojon1fB!|b
ztqqBdeV3p3wJ0;4&tzJDav)!;iK41{Uo7M2ZKmdd<EsqP1gN=Fh67i~ufwit!lA8m
zuLUc$NuT<Y-?uBT+nXRIa|6bZjACnAu0@MF176|XMaWtw0hf_F)M>76RJ(0QC`jRj
zaBtnFz4oK}+F2L6C)xAl&Sh&gXz|XCZ|_X#BeTJo;I9ALXwK!Rrk>pPJQbX)Wo9d#
zVpa-gZ~WF;QsPxB`%C{kex&>kxikYCRPMcdt=*lg=jR)0a=G2;WIkSUpMLCs*Lr`|
zPQWiWZJpS)y84MHi{)VpB;5>KL9Oa(*v+i3I6&y+i{QV4U9g<A#5wifm}9$Zw^>GP
z8qS%_<Q!dXo36>wOY-57LLBWoH7^<RXsQ3@B{<}Cp9ed`r`DU4$mHZIh*?B4@|{ys
zW~4Y?tQ`K8;?kVtDpn`o|G@=E+B<STbC<K`6vn3FFTb~JMf1P;*4g`SnyVou1afg+
zD#ySvz^l|{Ve75R>iFamQ!(tkh`51Obu>VxIXyorOnXz;KS@p9)<24R#Md>Ni?_ci
z3Py*`O0!h5#xsXTyIoQo`R4tLM>fi~Q46YGJ-ih|ghSj5I3C`Y_JAP50^d|Xd&oBA
zi!kGnZn4AIvE0AHpX5FW*CG;p=mYe1^rQ42)8C-~j{Y9qXH0}ivP=s)0n)8DC>K>9
ztd7&Q=2i;nK%!z52Z2C}fu(C9Ar*3il`aGrmas(ZdgU&WJP;m(<<-_s17)(cECz^?
zhh)K5sfZ+(PWJ|2Zy@7pMDnB;@dMx_iAI6EBHIQS#BCWC5R@wUHpf7O55ynI=}3Ll
zaDNO0>OecZ=)Nb{f^!?E11tbOa$E;;6DLY<7S|zyGHow>_*f5<SE|?sXG;b1U@t<~
zB#`m~smLVvUmGNYkx%#!Ia()5i`*c|uOK}}x*6T{(tTk=dV{3%(zc)_q*VjeID&NK
zv{$y9PhbJa5W@--XT^bD+SF7tz?p($2R*pmVS|Qlb<H+WL%KI`z3E~%Ais%zfq#Ik
zwMolK2xjXZ%4y?pnnBK5`V_Dq4%q6}6jZS77a*<@f<oBtq`|3(-XS^|504BT^2o?a
zn_!Fag1RRc73!qRaOzq;^;)GpIhnrq5JVA3|L`fU7stYpPofwYqd09a0jMe>Bm<Kq
z%_&K73TQM5li-`QkG3*gh<hh}4mcma!-2#%G<cCGkZvV$3ute64_-VRNh)xzp!NJo
zRfVxk?Ttb=uWvXfdDW9voVMcAtzipA5S+ZOcE#LW&gZJVl@M!IRcc!B7cM25L%*@4
zMg?x%FauLwm<h^&$JKfjTapnl&Wlx@4Jl*!;M@_pS}}u0XsE+QuNh1ojI3}PYdc#u
z=*4zB89GmOM}sSO79K9>+VIKoOXF&Gg1wUI!9$EH-}&W3!{uZ|$QJ?TYKM-20^%!J
z{;_oXl!g4X$Nsgk^Q6x&8zrZ#EA9bD=HCqFxa?GZ_=8A&K}6!NtNzH#_guVl!Ybe1
z-EFs;V88)&6j#eVQQ@oJ(hZ#Ax$dj)I%axmuzOrWK~f<G4S!Cdvo_&w<uid`R6&=2
zU0!^m1=sWV&Nyfc)w{FHAdN$n<6LP!*F<F4wwFwLYE~{T%ZqK#-H!}5QGGwkwf^Et
z0SL+>XL(~5Ds*QRYwfVjP<1T0*6E>wKwD~H7eJ}5SjCa!XKSKo?Y818ak(=YnfYcX
z%oc)$W3CtJVvZ3#$<l~V0u>Lkd8R!=a+*=e8faXCCt<Ke%DB<IX%uwGSP#o4;Z)l!
zU_pq;xesp$4c7wJNaI%Eg_N1Ao!97@UREE9z*_(|a+v`Z08tAA>p=kwlsrwVtm44n
z2LUGlaiG%$873hj!<w9>ZHbvFPQZiBm=ab5MGM@2I-&xMAtlIVi6qU;UE7iEEhhYH
zs-OitiBttqq=Vt{y{03Z-Dx-bD{A6}dMzi`7~4lWi<}?(#89K1k)tXgr<sY&Y%>rx
zpOZXS6h?tG0No6ipD|U{FL7ZEcZbqq_mUzEr!;ff0tFMDmp}U})gf_ofA)BOT6L{m
z%N9cVwwYH7g$z)VSPa^Zp8)|JWk(rjk7m+QoSmCL>1x#yDDAt*7jm<%TNDdnrYz5*
zY=s==RTt?|p~+n-CjNyf3}L2mY0vKQ)Bf73e=(tf+5|~42JLi)t||!U<Yo(nM((gb
zY8G<4#_u<IxjpROsEc<lA@U`zD~6+>LabGjG|xkRJyM8xPj!Ys2JL5EZi+0i3PsJZ
zoQM^(<*{=TR;Zx4r*pwL@5v?9NW~I%ZEiy6wWABWlsc+XO9oSIIh5jCQ?~36BaE`_
z*NmM8HF;FZgb4i^%d}UlSYb^GOwdbEqKUc?sC&R-peP37Pk7)3u=a8wbkaS^04=H*
z>WaY(J@6Wu_3tpw3?FitMCg`-Ol?tUh|^N`GhZd#2bBgqD!t^`b;T1HNi^(ZH8BfD
zHfYN`od6v1lR0ke2|A}RR<%0A>0Uvs!JONP+5p0#Zb`#{1if3%hDb#EeT9)jS!2$4
zs_wD8y`MUh*Yfq$!-NsS#yLfFhrIuftoMME<htsGr*f|9?n>R&Ip;Lf-IK%4%+Bo0
zrkM@1S*w*+(kkaw@LJJ9l4V<#g(L@@jcwV;JZwK~W8=g#*uZBn{=mjRz`z3@&pa>>
z`1r82!~5T=o|X8%Uv22FaPO_^y62pG&j0+6mdGmX*CH{Lq(EM)RSv6i6dnL9^?@%}
zzy>cWQtil_Rk$UM?5b{QiJZ*VP$ajd@I`utW#d?P=j6mK&dmMKFomBiyz)5ehZIG(
z^zLkB>snF$V0<!c#rL?0`E@4$PvAbzYPP90J;ig%4(*wA_|>1mYZj}Gj*c$72aiNh
z6NRi_tFTu-#NNUk8u`x1?~nW)kePQ=Pf#yXpQ1hsX1YJ2enR~{^-t6*$P10qNxF>n
z>?Qh5Kx)27f0+IZ{W<zu^!Mq%r2hx~|1e;hh9e=$<WQ}AoH@aqBkNwQUGRq}yB&)L
z!3Lt7pn!-4B0#A?8xhS0T@-A-O297vG}Hnep6VM0IDJQT4F5+fzV(1MaR^P?JwN<T
zmWWV!SClUK;Oktd8)D7)R)?<+q0e^yci<!^T8c#b$!3#)2)O}2aPAJ=GTBSchWbP^
zP>)cQfCd&zW28Fc4p^~F7WCx)f;Do`SYV#`pZ)vwZ@_;Pq=~@#f<fjtOFZMaVe*W~
z!kR3t%g8sxhOr0c3sLC7UErY%H8HwlhMLu1`I51c;SvRmvt4H#g&<)t1er@{ncNEc
zAzpioU}zrt51zQ+{TvT+N-#h&NHS>B5|*&|fWN^;cEOAY6gxQ&T$ut?x@BYJ<Ux@8
zBk)7q9@wf#cY$?={1Vq;kbmnxlHo0t$D#O#*j|#2g=6Fa;3%3V_w0{>{J!{0o|Hch
zG6sxoFb10_7*8-%V(Xw^3<z!XL0izrZ;X#P-A`P_ceH{07QAx(AeGgB?BvE#PLT8*
zG(>u%{NZ%{7SR>%1m~hw2KpewL)YUDpe_M&BIuPwRM0M2@%tsP$Qg(?k#D#JHy-@T
zIN7%_@r!e4jdY8%%4GC8^5X<!zylzIMO1@Ck{tFHyOEzuN0H*^q;peYrKS`|$K!0I
zuv>V6J%zZqHgT<-$cjuRNl{q^4l+ceLF6B?X8TDYlU;<H;A~`+w!0oE?@-Rjv+cVw
z?HG_eJl{lpcECpYI17o(fJ~YelW^VHh9;<Cy;_T8LNoDnuQj(A&53Xol4UF<gwqKv
zkFbeAfm1I6J#FYF8>?~gXKIEmOPROoye_wxFiJh3SioMvU}Y!Mef0&G@hs5%y*JJ+
z8M6phD`%j>#dsAW5k)6D@dIm9TN%X;*QDi=KCOpR5@?9|J%ZvwL9r3=SBppm;S-c8
z=t4phsZ1!DRCm$ry@&cg;FQ#J5~OT07A_=v`G&m-KfDD-R`*mhn~jZyVtRD@Cg!$z
zH6<logG-^NjvhDX`cwIKBGJZDmGaW`2zMxD72}p<YmsOrCWlPkZ8UmWwx&6j?11uK
zk-Wo+aNBIxYBN!-2TV++lP$Cc(Fn?lOpUUu@krsN*!axht}xw5Y*Q5EIwLqbn@j`q
zLAxjqBk=U!6%en82{Ah%W*aH})k+~Bj+<732EtEeOeHz_JAgw9rl&X{h=92fn(w08
zI{-CM>vA~ESF#GHD9F7q!1W_VqE@*Vc0=&E2;$yMwrGTtnf<LrZBy!~cx6J{=Y)bH
z71?lmfeIBfu@K0p{~&_gB(Tr3^7cQ-;0Q}?|93g0r)^a00d+J(85LRXtcAk`HHQKS
zdFq5DH(BstAgd{vj7gVQa^7Qjs-mhu?Z|VHh%TTo1;v`wHz8iN;^m)3`P6${M&{Db
z(kvJkL}@IlCs8JVQIsyw$f#CNX^60ZE*n(MMhHqWY{w<5#IbQ;a{#mi<FfKLVGRGp
zCHfn{IV3U;h!v3aJ2@YnsEr<z+x!$LkpXn3q|6~vd=HGyaZ-q@ytP?Do|J}CXQ~;}
z)U07-O$n77#8C2sIj5k*jMBXb-j54|gO5LZtiCri-9_MrQ;n7!jUku;a=#|!sE*=j
zDQUnbv~Z(<P+9Es3*(h02(&uK9<)+snX<HK%u)~}a$z2raswc2k&?$fEIs5t^-oG`
zmm06gU;s{x+l}Oe9CksFes>aOs~q9X9#pV-Oznqoa>GMmtPm1;i=Qt7EfOt^?h|V9
z_^na(mkzb^nZwCv@2W|zmaT|1IJuESgqW8BwS`*}QRc}`K&r58RjY<Fb~I(=-!-%6
z<C|*qgX4uQ!Sa?^raV^M8}F!ie(9<lntk={RH2qHWIFD1wiA!QT27}lh&#TS?Wh3v
zP++?jshaTI^$2F7sDP!}dS~xR`s?E1!PPLg9n{u9$t(;&j;m(QD)u{!GVwQ+jOPJ`
z+-(VtG8*0pwFhvkiy^beeuU2yTeleI7$cT>>U$Iyq7sbFTht*o96>}&=P%oOmfeUd
ziL#hxTMi|gsj7`Y7Zp}L)w8RgrY+RJ0IRoQnrH0_Vk@+rV-juxkYt_#^=~8I*NOvB
z&cP$9JZRP0{~$P(eQqz>Of;3Klh>#X<iUkdYDDqu<7|Z%w%c$Tqn-i^@`Ng83Q2ec
zlAq;pj#_MIw*N@YjvkGHPB|@Ye^;mCs;y#G5;N&ZD{Ch6@6<DLg3w4Z9N?r5ENw?k
zDIrkqUH+e8kgJ04V3hiEOU<;ukF*c{ECsqbBr6?`#&xh_>XfD()N-nB{5U2e9t%N?
z(k!(&Y8}A|hhLKm%gla`i4i-_8JXC=Us&XROx-~}PMgf<m@hJ4Wq!*1Bl91K?M2u)
zn`WokHTDMfPWD0ejqKam_p%=%Y(u_w3zRrd7-eB!<e_wkok5f+tPyesl-yvL0|I4;
z4R#9-1%F{F5c@9hV)cC3CyCdSXaQ0F#5O6@#0wx0TLwrrawTbh$2jy&guz$<#-K@W
zM3E9D=>G)}6bzH&0<^fF*bM46e-H%4fm+vOXk_!<RsNX$k;4%Iy9FD-HDmB1jQK`Z
zfGQw93Y>)T4En@x<{LVB;thjZC8~CuL|@3qq0a{QGBh9&M(`aYxRyAN$gPm?@U-~t
z1;_j^{&@g$CP_v2Axy-%67m=#YB2&T$Q2>lo;+56EWUk&9(-HJf8749klP8mB#+Pc
zr4ZC;IZXw~T+%2WD(;jFh>YKVD8cjT1NlRegm9O5fWC{U43se`KD%RAkt7@#i)e9Y
z^Is3&gzunj+>(DiX`_rsPE0NGiTnt@#R6LlPmvsY-FZQm#3>h~$KwJpt^4l=@izI-
zzeIA8$!Lg?hE8DN;7-Xu<av|7xSw%isA0o>`A8+wBI(KB5W5Oq7-HLvmjIyxJu)uC
z`_{!zh3A5QQ&gXrYI*W{lcxj2*=iGpl3{Rd2vWgQATKSsE%Gztagv^c2TuN-$IsaJ
z50S(EhIV1%1{fc-ihIVh37Wuj!kPpR-^S3!(Gb=sE*=6gnM*JZ$@Kw5N+1s5GTuwH
zMmSn_wqT;5aq^>+KoK$6VMhNafD{=mff4~ygiqw9^4}J$)#3TWb>QpAWn@l*F?!7R
z<H4<mZ?Hqj`-aSW^2PtRkMt&V5fG@B$MFKAh&yI*AHOYm6u7s*QpO8Q`c0v98cqU(
zIPMwCB)1GRm7GevoOsy2x0_hJ1Dr>4w8k8v?Bk8eLmJ?Ea;vCMKpG>zGrI4Q;GeL#
zrDp_Wog94%)v-`rM*`#o(P}qMoIPjbu2&Ov&saSG(qV-1B^_`A;8{sg3UF)*s0M@j
zk8HEwu_P*7Ow3qtsi?F9aDdL8+ecMUpNmpvHZ-6!Q1(iT!d${S8r1oK<M5IRBUWmS
zp}>NXG#994x3w2AK;@?XT*#>aiqZhfGHP~NW5_K?mIVQ`okeX=B#<WH{y^azM$e||
z*(|Tj%1Ti{jihS0GlmHJ7z!ncp?yfzfv2hlyTIZRn-?PykT}~03p$o~gpEZM$}NGE
zR8K`40^fu00xQl?NWt)=13)=A8U+kQRT!X7P$Zq(u4hZ*@PsfRCJt@Jdt#Wn{OQxk
z*#@r@P$(39IZ>9&8_1K5z&Tfju4JbsC)X0kBQ~peDbP6S4qcp7v~k0LOVveaT@(?p
zKw-5ga>D@N)c~XrP|j8s=T0dx=PCv$Qy^Lu7<b6{WP}QIrC1bD^GX87TjTVc3btg*
z29Q|Nq04g&$j=feg9efq-Zr3yL!=s+8l_Y@#YIJFz*3$I+tt9Y!LTa$58>;j74R)?
zlxeSm+He4dvTTv&JS)_KW<xTQE;u55Ks1*@PQ6%Ubgd{yM^S|Zgk>lln^&z!UPP8Y
zDa-@ckYidIzEMq#sv%G33>SAD7rOZ<or%dn1ZiBsIKYN#(jI#9YPWR}wQQyQAY5>w
z_^k<UOD|X`Cnihaodhx*_yizs88wS{&V*qLQdPjUiV}TYh-!$545-Ya>3Rk@JCv%D
zI$8o`JwU?f23<-K*a?a|0OJZw8pX;XUO-9<0AlRkF~{>bBn68$;KitNRSH$YCXFJy
zizpR_JM6r&U#f59w$F(uP|AD|Hk7DI0D_=oiy)^#-O~mt2oPMpO)bG#zWkL)TIH!a
zp8*zJl?otiTa9<wkepFt%(H+`<p;041pp`&5B?h_GL2twkxT|yn&jG&h1@ihJ)jxA
z`SZUw2~=3oST~emUcw2eW@zYut+s1Grl6n~@Nu%LQojPAh;1vv&p!<Y1IbHMyHL60
zOo$Z>J4YF;ftjssp9BK|4KJ+4U4BVpzdDJf+|(UEejM{V%cuyEa^N`*6*^38^QYo<
zp@=sLc*cC>s`0CDoYa$JH$)`7jk*j+Ad<VeP!{i=EpW&Ttnv$aQ5esoW=<iyU{oc&
zr%>T4Ls*Dny2Ssr7zb8LicIj5T#$K(Ke~=mXhtk8z2|>XbGxl^1f&IIRC%-km=rkK
zsDx-E(iuXM1B0TyK>C429!v<R3K>)FBpWaHA~=S0LdoJ4EU{@#PQ`MNJV4;lHX!#B
z9M+*^G%5@FL6$CpWkPe@ri(Qtm%|cEk79P}Wie9JJkB;(c@vfGqWDqG0wZ>82&ahR
zC~=jn$YdCitXzN;3BxbX!yRfWdte5pQAS5tXEuJ(TC!8KkC$rf()8$*lVEgPr%H?o
zXF2tLWSF6F64)Jplu=<$%Y0JB+>FPaj+;QDm6%|iP(%Y3NI><=h>h||Nc6Kg!GKHC
z1VB5Y_km!S#+wq*^T6F;;-d5qrYOqQgiuf?ZeUpkL>-*|^3Nv#=2HyAX^r2;&NOBp
z^iXA&)GFgd*#a&S8H=P^S|e*R%VNf4i@?ZJIpi%8tUYoO@kAM<U`a?->~U^9hAL(u
z2NiZGYmydCDJe&IS5zWy7u`ZOVnv9UG}!K0EsspC8A>c<3q?rft~V1gQz`3swl=;V
zRu<q82iht!7D*s`j;4A_I3lQ{MrwT*yclLl$TlDP&D9tFcNhyd1=*mo5>|3Tk#<<-
zqjFUi_-Bx$ATTx{NLZLo@~yHFJ!Z_LL<;_75irI&A`xjo{;GxSp+l!<a_i-X`rJSb
zdnovqkgTYnE6mvsM*Foco$w~X2gNHD9!yyRabECB9C@2!HLFth7Lw(%OKH=p!iA*}
zs>Zq?e}DsHOv}2dCi_eZ$sT|&ErTSG{X;Fal%$G?=yN~+ab!<KNTG_fjO>GO4?sHw
zb#<jQn-Q`8wotw9-P?bq1O3MSA%fcc0aD2h9(hn*G~_Xq4mY(d_v$1{&fsNGz@PBy
zI7NHgm#~t<9Mg0A<ort7#(Km>iBis3*<!zs(sdRTtm3?y22-w-GW1MB=c&<{N{gN>
zfuBM~J{`SXm`=%24V969f;p?GO}a_FGD;a~Z`7NzEp0pke4%EzN)%ECP!m)cA{=X+
z@2fW9tNuOVC%iQBQ)&cNwA(b2Wl^uiMRn&XdV$`cuR-SBee_fCPJe{{GVwqAep{G9
zulb;1<CKQRC$aIc)BsYa{Mrfs-!px94onha&h0c5oE_NOXb$`HJFZ@0|6m)sb$2fC
zorYv5F>eBQEiNMAZ*qCy?DN?Pf+f(fks<mBrkgWHM)2AO(-kdYzYE(ED-hUD44U$H
z`FZgH;%i)h9g1Gj0$2se4eZ>VOE`mIW%>6-2IV(S7AHHShqXA|{A-3+q7DEOA<#YP
z8Fm`_CO&X~3+&w;fB<=31OG&<VTNatabg=f)%`ZmH#rmC2EWAczhE51U?is}DZ+k)
zPKIZaX8oRf!~cT_1I$JA2p~SWAN;mH1PivkzhPBlw`uZ+!6ynB0)GQ@I6jQw3E_7M
z76CY&!LMTz8#~y*2SEl4j5<tf@-w1$JP=~c!eR~_vkppO`#&$N*kG^!Sc#L?bp(GG
z21ojFV5Jl59iR!n*Z_GuU96;VK2E@WxdY)Rk9buSy|cr}+mYC?78g)W1dJd9*>(Ad
z7DnE@N{1-VNryF9Ql=8ku$i<~IjXAH!T{|di;I<zUCgM3NLC2*X4LIM=)idk?0HBZ
zT?B3!+$__292v`A%RCpk)RzwnhQz~&GBa$h97A0?d0}sLDM^QA!lbfc?u~GX*<K8U
zw|6(c^Vvi1z4z25YbM->4vDVX<*B_>QrSXswUW`Yqjq@|#w`lip)y;DI^gCYZBTk%
zp%7YifO`i>QWmMhx|QtSuzL2HpSHGt^L<CnJ#HT<#)pBxk5H|S!RdWZuZ72${B9{;
zuCzqCp@_B`&VU4e?_pl6Wf_aDCS6yL*mMW!x{<t4;4G9dK>m9y#lr2yi&{F7(3F_l
zu!~5YGd{a;HwXMQt4ZEyAq?lV>>xo{*5Vw6Wd8_-Vpj3^b=&{QC|O3ll@Z^;3fs>S
z79ET?3=eojO+cBWt|9E!izuaQUB2vei^Yj_PNhB{?J^$$b+;N4#5992_Dv|6ZDgK3
z-E9`=Ujs|Ic=<nOZ82FozY9TKc_F|1>QCfVQ<QZ=hZh!}Y*iE5maWL;w^t)!5T}Tl
z<YT0mvH9%wKX<Q39C3CuYag*w7K#iu(h<Hn_RTTSBAIJua=9pm^l=@K5_w`?F3L?L
zFjDPuN|Lo?sV8q9@HSMpE5~n($Ii#<FEl{aA7fk)Nn(u@jpEAQL9ef!&sO`b!s2>T
zN=HLL5X3ENj|(Ck#3a)o%&`=w8(WKh*v896Rh_o@72R8HrXyJt22XcSft>(ES16B~
zdGhYnk2bd!VrLJhCPq`J|6<TU!rvGhoTJQGB3qW#c)n})Kn2P2uf8DUJ%R6=fB>I9
zYJuVhMg?W&plG8!T`eC}@}N&BE??a})X83FzJK3ejeca}HgAwQ*!^YjZE6HUZ6>w0
z5))@v4%C*AUA`7FlQUAjULWu5iRareknF;=kgZMSj5=GX6^c^Gji;0|<KAd`UV9@_
zI)J5+QOwBI1(yw{N@8stGypew*AYMMo5f^%vfGVyC8wU4N<C1#myz$<b@5%Py4ETp
z687PzmO8948{4&*tV?P~omxLeYBVUk&9R7sr^VxTvQ1^?n{#7hfAH#iJsBQnCbWjX
z+waLR8R{<?Eg8;>QB!*ZLM0F*Op^t8wONc5d)wa<8Ce(T^C;X+^DYt|=%aIzT)zA)
zQq%Fqvq&C{ATKpce_fuu_|E3c`1L%u{a-~7FO?zu#NK0r2e^@GjOmQk`41IgWj-Q&
zIa<t#?AVH&t~^iykq5Fv9Dd^VglPB}HW8TS-w{5-J~Q$=)SIYhs1H&vQJ<&2LVcT{
z)_k$)!(1WPi0Xkv^CPQ)W6JS8VMI9ll9A{}Y`)GFe0PlR@9~{K7Ey%baC`Zu)cr_W
ziMWrhxODoxE@US0RG|fs;so*&isFg_3WPgyo5(RDY5ff-UVwBVQEeaAMs&eYmy+{=
zNr32{rVw=;W{6|2uUU|gHdKW~Ig?^H2=w_|-tkqqe{_zTMMN^Vt+Kzz_uKgz1**Xv
z44p~-Sc04Lp9b78S2o-gIwe#(I3e)k;rWq$fL;;rT@QQxul{K}7Xk?g73AwB+yiON
zA08gy5GYL{5fKheqDKTcZpr9?#)1`qdrlKO$5%E3;UlRTyrDIw8?k7qD%y4)6^&#n
zaV9ez&WIVUyE{9(_h2~EwGVGu`h<SWrq+^cN4y3~nMjr7OiJ6&II<Rt%r1#7*xYH^
zmJUSQopVO2?G>E~OEM;nuNyMxV5j;q4J-6~clm@>cboAXDh9LH<&OQ^W_MQgLZA}Y
zHjVT(@=S=v8q=^NApJ$+3#!y0(4{_M)|w&{O(Js}!iREmD8f~cy$wBLWu<WS=+vnT
zeR`jGLXI`kX|*=3E%R+GQkV(2`up0x{rwx)*Qwd`daSL;*?3i?u|~&&=+5b?vY{#I
znX&6rlLA;*8#)ux+3@kT^$>DX1*i@4_?}!@79z7u<YV^AqT4~p1GS!s^TloMKRT|A
zo9Wgo@#Mr4x|X~{;vRRAq7H`ETiaFl4E4PjRyes(vN%5-_SB_aSi@`c5ze6yWh-aq
zW24Jg3!5xgZ%etwy*CLahxC>xZ;QQDE1FUqECf-u*;!hhNVGvvNb6hKnWafBrNx=)
zQdrzabE<39+93+%*YybO_}#4GwZY@DJMArJ#oj9*rTLzo68GO?uADNE=tT+x+jM-Q
z=+r=N6Okio>Ha0Xa)8bQMa;-~2>~KUv?JlDY1+ywUlZa<mAh5s7M9i2;sXf*jyF_g
z1go38r!BdNW-&s3SGn9gb5ibmcG|M#qei&S)+r|E<rSCCo7~mAcNdP{VAePY7lA=3
zUCu=b-_dK1u9Z?%_;7%?LQ)7;k6`i*FC1MhAhT_nI<!=3Wc7HFP8#zG&&aG}Vaas6
zi%z3lx5Sh|y|H}ozkTsEwek6vb?q&sxf2GkU(}0{NQinVoCjT7I`sIXp9=M~LulJW
zps~+~8?bz&aE8Q5Ovtu>5?<mS82Lr&1Jtile?<K)^(u@JmreuS(xxX-%xn+6pWeb+
z;zs%|vWD21!kBSayv`5`kPbFsRwBa1pI^SAdIjsk1JCH&w#1?((#4;7egi}@5;2Fp
zej+M46`y<oM<z9y`TcMqn7l~AC36@cVDc~dLcZ<@1R*q(PekzeHu27AA#%|GcDcBK
zY=P~Jetc;PnYwc(8JN@cVJ?0Xq<H~12tsUMK#`9`cG=j8|AT+Ymtg%;CdWzG$k~xt
zxZW4(q=Wv>ih~Rt^4MQ#U?_l21oz+{cR^%>QJ?{aoG=FQ=RXHB@Hq;}=N4ZM?v8W<
zl+W;<09?V7Md$(HB=km_#1TT{PWr}}e97<sM8Kfnx#Ql@0y!u6S$!`(p>Vz8&Bj`e
zJUE<!+c2@(3BHVv0l-0S6!+~b72ot9M;5a$X5p15$NFPVnZR87e%QtTG&Wkq?~4O=
z9y*7Rs1jw^_n#0^OXH*CCe{?B8c?4^KyU}bOLM&*Y(nrkQQ=)v(K}WtT3zgFeW0t}
ze!!q94ds~;@w7bitF;F57@3wO>d|j`nF8dNj=am>NoQ?OVm7z10GO+tGF*H6^1);K
z4&2U43m-fbMpEmhTU({LVvYOI^9LTWE7P_Yjm~~tp4Q@fP8|5UVBHxt=i43rs^#2R
z$^p@JthjLG%XK+i&2Gq6I2X@OsluFKTyrYvcJs?-I-lxpN=Ske_QIBMq_${WuUC0_
zY*eqqde7Dwr;WTdLZu|6r&r=&0Sb-IEw4S$=+`6tWL%@Ij4rF9ovFrUUb#-qPbp)x
zL--_RoiMy7@>JpAfe9v2Mmn64dE2UY(HU16IF*l?p$Rv+wCn*Thx*tpz*0PE`$ZZH
zo5EVu@W6>EG?maR|5DwZ*DLdLKRR1>Yj9&BBNJke&2v%qo!~D+o$(OTDP>mM2Kgx%
z71ZV=tx2eSSj@49e`_@qjUo9}-v*H^&)M+^uaxRsnz@dXQN4|BzWQ8eWp<J|<D@vI
z!9R>N;#Ju6Ih1#&r$d$PaZR}DR_d;>dUX54G+!vghkYAO*E%!}`xt;#Rzl53WSbc(
zbLrx5y!fJ#3%%o7b)mu6IX$GeAy88_mAO`0cmjoj>`e5twJ3O1J_C#hDs&=;Q=W59
zIocr=+$!xcN_=Yby`HFr!dc5jA&u^ITs6!dz8=fIyL|2V()9FdDUXQ$@4ay3iFcoh
z&X}zM;1%6X#cMalPoKMo>b+A8^Ga+{b5A_7x0W3%mAI={BJr{_$164D4Hl1oAO*6N
z!-IMoUh8Zvo{TG+gW8SJxRIDsLCrfC&upz0DbRZ=SiV+3#6&YOod-#U;}-NpSaX^J
zh#`@Q>bi%{?%gYtH*UVK*t~i9;f`dtQ{xNn{MaIU8<z{6DC<d0Iw}8h<|)2nXYwWF
z2Zpm+;>`2>94b_)Tx_4<#;IRvAG!-g?6;77J!ZBmIubG_>|6PjyPiIu*p;yU-H4^+
ztKWF@O@+P9%fA#|oXm2X_kX1)6O$T<p$-+s*bgu8;Y;^-Z}|45$Zj{bn?k9PXa^w~
zEsE0L4~0B%WUx}Bo5>>76$S&WSs#bXSI7Y`6utaM_EU6-sdsp%K^@mrDM!<GwfL&V
zfoerzj$U)siC1GZn5vG-$P%8{P%=n!F?<J<Wn8$1lx#xVf~UdkONa%QD;Br}=u_O0
z5e53{IpG3tj66x#=sxOl?17)_IDH;`nQx%qx>KKH7>9;zfjB1rLR$KwhDc`!8M2Fr
z#K7G|_TVoOqP`7IM4c~hiP#(J333iOj5LoxP?LXsDT`(T=}OFOa)p02sgOqGBk74;
zyVD*%6D>k^_Xlp@kGu}RgFQUcKbH(7(1w9B2|5Tmd9CxH`(P>I%SnusC?*0i9QK0v
z8-@hPMj&OO1$?C)43l($UWb|r_cFZ9FLyykFi*ko4jvnB1O`7jm8i8V7m}<Lavh$X
zuSn2j2T{)8vAot5S$jayl8lC+yBz7;e=5VF`488>X)<zjf{p)A8q^<O@a#}@g#0K(
z$zm{mQ~$pw?N>bC8QeHI4IKt*d3X;)y@-JmRX)^OMRKELmvv>Auh`IliHGHLI{@D5
z_WdOe)GQuG5$Xy<!KYw%uvfSc^D26rDV9g$EBgy}*@;efg@dE9!y8d4azR2#qBt90
z3(rr?<ST;4ylK1=j?z**Tk=+x=43CH)e|0SN5pFfQg29>-xT|1>}R=K_Qv}8F2cG7
z*juzhc5gHmlV<f+ZBB}HPS%R?!J+wNc5>pIs|BQIdEI_GR&9xig#lblAeAfHsSA_b
z@$%wb3s!8>Hq}_?&HZpf*`KsZ7hk$?AiIoUdt%&3gaj*1%Zd6RnRL&@o%y?$>y><H
z{I--`G?1;X+Wm#Ny5-DY%U`goyT36xo=wNZ8RVFGOgJfzD+&1EkamVtzV)k=?3=P|
z_dpG*gyN^neTSVB&RE@8h$y{gcl^K%0)ZOpSWa|1m5IvQk@`tVYDi{w!Zxof#+zM(
zOGbpgY95G7QE*k4LkgXZXr)Xg6q}l};R~bLvV<UrlzM#30@EGijaH*hXF6n>uoyzl
z?7qoes4}m17gG18+?o4%tF|_pdn!jCUGK+$3*(WcKQ1BIoQ*5W92eUTRnD9(u@7IL
zWQ~jW+;eezzH-&s68FgMu5sVpci%_Z%NwWqg?Fr+wvf6At^$g`1#%2|lBQ)hE`Li@
zU9eH!L3YK$*z?^^x91>HJ$|ZE4@r6Zh@p1V{hK17Tvv8opRIt)^5z(CCo=JFCR(aL
z(>{yUh?FaLb?Jzi3T0Dax2%h9VWs`e?;kmK@0{8JSB0HzuX+6=`t^(Ijn#dlOOc3^
zPUQBCt_hJs=7f3M{7j|ws8k-+saPx#vCM>WJg?@F_e~j+2M{M)KJ>9rv0h%y8g}gs
z|M%|uXP4ru2;WYIL1v)IP9r%ucGpU>I>)6Z7Td9?*SvAr`dB636sHlHkPN^O<&0L`
z5{u!&0p83vq(|%J$vv(ZhhtERs^Pw?Pzoa7ax7!*x>Yiw2NZ`9JZnR#gJ|ojkhECy
z+<oI4<1TEBrnYOgw(E_}tKM;!kh*tYG}gaqrI}0h4WQ_*le#Ij+zu6afcz4`l8Fc#
zx?NT3X1h*KQJpEi@rgQ5Q7d+Lw0`K?uxNVRXfact*rg@45Eb=OhbH$F)5k+=YDe;V
zXEnYyH3>^+Ykm;d05G-1@Hm2d29xm;VwL&xn{NHYO@{uvPe1*19v>f~MDlU_7f+l}
zfyhw77_aUJ$$prd9X(c*Vjj2Xuvuny6tw~mZGT31miy_*5#+r$sHxYllpt8ik_M`0
zXTu7~S44212cj=9%*l!dvJvtJe}a%iAPcYjOO(oRyRr{5l-T0ff>?sDE;=M}3@rr$
zcITp<&Vuh(bdLW4QVbS)AS8WM7m?M0B0@Vup-u-}g4pd3GthlIn!y*_K8gowEKGD>
z;FR%4x}$U;ca32rfvir*{ouF{gYnT=L>>#zcBF*6zHj2#h5Q}#d*<J@@14v>_vGkc
zA{<ZkKu91T0&383H*>LRO3bPC<;62|_gouJID^5S`1&qBx%#%#H{8`=gqdR@ZDD%p
z!0m-q<gJONy}PI8!*IEKquuV2I7oQC)O1sv*@rUVYPXzBWcRkco@A&j9o_3Fso6U(
zy$RF{u2-^JyA|XwFAbE6LN#Oi<XVNvWLopeiLDx{@9s}KPV-G`QZ%>wyiw~Ysv_3Y
z>FG&*v)w)9eIP#btxrU|#d$TMTQLxFL<?+l&^_G}Ha2&)B3S^?FF)bN!0sQ5Ct^K{
zDtX@FhPXWgC=aSEX<14$=O?K1H~-h}Ra5&8TIq$hJxkAL_x4YmUAXa=(u>y8LISLQ
zGlzC17%R-WTW)qerE`;yQ^3%~qPy->4)C70xVFkg-hbQFv6YSWa?=rw=$PA56Un9Z
z-QhuYzLl_@BYpK=ZSnR88pkMV3^93NfsxXEHk7U0vYOQP{@sDXX5+{s$IgnmPAF$A
ztLZy6dpA$d&Yn!p)>02Y$i&n7XarE<NOSwY&#c@|-7<CWt)U!h+&44Xl{4<2S#Nyw
z&Bqh>MoY(0=AnEvyUSy!ysTe5Qa|bydcuK1&XV`dZRNh#YK~J+-OpZKIXIeKN=|{$
zXT8%c+-*^^5_Ow3L_PF&ZG^(Sd!O(!_b=2s@y24UNi?|s!r{#)bAp&wS9S#R1nRms
zd{_Nbe4_+A5Zbq`5kfb)Gg)_zIDu6)G?$3w1^aF1An)5?zHwv|YY!CTemxbkr%$Z0
z9ixs|E&fL46J{qSk^lXQr-J~`N~FXNnFM6Rq#?k#5puGBYG6tF2N9?xXA|ZId?z**
zTqI+oq&g!xHR!|dGH8z2g8tWWoR5b?8V{!TaEI?OAP3N#@G@`->svS5p_5b_;cw9K
zGvTjp0E{1*nqCg+ylUQX2lAIAw`DVRUP`|E!Orw`i%X+nZu@gZYQJpQTCB7GY!zsn
zUN^pcES#SFi;!Nsn%Y<zedJv|-R`uSA$#q;;YP}f#q8W}TjSV*w66t@T3~D<K#YJ5
zY5lJ0Hp__Y?@bw&B&2JH>_P>et5zzteml2+|E;WsDAew^BooD4(*F7uAEo$CxIpcH
zM>=0Y4x^sey<6YXI)3+4lK5c#z6GhU{h?T!vc1~$or~cuIyL`uZ)I*`!;I`+MZG|K
zYUK&996q^qh7FCXF&CvP*|>w^9JE!T1aoV;$oxJEk;o_L{$wfI%!T4n_uz*>AGzz6
zOUp*gY3}}oj~Z09|Lw`i{bh;y{;wQvWeblTJ-R*~rjBGz>)ZcQ2orF2v@tqM?HvP;
zP_3#L4BfsoFuc7~uff~zE=p8+W_qlr{pp>pg<emuAAdht2~BKu;x<*_W_zi8Rj3t2
zO`uZk)yWk1QDk<Qskv~g7YT8-WO9B$AKHB5m|o$uTOUfqQ{kt7OjFxGY(!?CEG+FS
zA}?0R%o>@Oax1&}{_SsF(!viGZ`8vtnw@{q?Qh)l*h*xt^KZL0_rW=Ec-Kbk@Y4Ca
zLN%^@{cR@@f2)_nv2df96(%}4J6+Nx8wAFvU#+x=FOkf}j|iXP{@tI8#G&LTwEH^3
zpCVX};MEE=hyM-^lbM3o7z;Ju2}Lwkuwmw0acu?b1!8LN93B3T89*Qlc$NJ)_c&Q`
zmGa;@BPO~(grSNhFFV<SxrMwZvXR*t<YQxM_{9J*-^eMJYq~{p1}N^yf(MyWWL}s>
zau8*E8B8BCjmS(I;DE2l$XJHMAPY&H;SZANN5^K!xdA%BpLm4x1!oNJ)#tsz3>18b
zG8(@!Tu1nfcI15Gw72!<J$2DcmJmU+`B)cf%!@}0aAr*1G46P`=5{YnmDJWe9}0uX
zL&>+JfT(eR`KR3?XxN%1_;yHHo?W9+K2|C<#*ht#+|?83xLx(Sm=P;)t?(y5$vK?%
zo=6lPE(O3%aqK3y23ys9;)cwL&D21vf<v{@3Ylrfg`2s%{Y#<=uMz5(aR5ekcxo9K
zlz4>|nuaGj@%|^bPiQjtCMpr)KD8E;7%N>)^d?W!oly={>wEP~J!I;ZB8SHLlq(%J
z%(rk;d_ARrmt`aMYoHxZsZ4VDt<mN2@dNga90s(<1D;U3<BgG6r+)m*{UQ@mL^>`W
z0gD@AE=C0WPpSiw`7pRwJEza2AF<rVczfA77CWFE=Wa>L(L?WE$kwKdcX;utdh^-l
z8E;I#bisj^@5PbZEuCFQ?0GPl&d<%Cw2<nZ7C)cbyQxH+@j`)nD}t#9^~lYL7IR*T
zOV4>V3Y?rkxsA1^jcz76R#x!TDG;u?%fBosOMl+J3LH<=quc)|d@|nSyqHmk2Tup$
zN~V^N>Q-Ghwm;dWaHow_r9sQywOs1x$>Qy|A?}k=J_`bMK<gYZ$jh$uQ3*s@+uNn5
zJ-H;U^J5?xK6eH|c;Mxl2+V1?k-gyG&oSj1M@d#80|E{byZpTHc^<_Gs1`Lt9i&cB
z=c(JNr+gM}%oKkX_%ngX{b250nG<BP1zdw<<_2C1GGm5U`PL-nP%snG7}0y=aA0QQ
z4c=)UFFJXp18+!hInh;^H)J>LzQ6*-b@&7hYJcJf*Ps!<IihWcCNa@bLtRE@obP`o
zlambJ^?d{W5QsJGUYYVZhI#1UA+S6|VFvvVuS3F#Z#o1wL*~3c0f}10h~TRso^@dA
z{eFh-?VYKMp^?>pk3;}4uz^3PgBk2Yh;SUc{ZgX1#P{p_2%zA)@j*oReAfVPgJc@H
zvi|-z@Y;uNxV5S-PiOikXW!|{Ivl%PJj1-bGfnA>b7@^VpI6f*)09vUHy7awp=?{y
z1S56rM@s`%n4Z6VbLsTf+U{%4-MOC0#!_R^hO0E@-%&kWM@rsCKiVx7+6gYcd2Ogv
zJf0FbiY6%C-byImomdxH>fm$-?>*D*GfY)-V#X3zt~5aIqRT0eIZS{vFcO!`9Rr|_
zJxSFLX=6glQxiweS+`$1U+`jdCSf1n{^x5uoW<(JiJR{Oc9lJH(7f@{aI|}P!+zk<
z8LM&?&+QjapSfYioy|%`=K5FvESt`V9*Q-I8bGn{l)MlFzi)!~Tqk8Oe&Qb^_20yr
zc<+z;i-q}q(w<oqBCkH*%4Vfrrud{hc;XXJKKa`}JlH5t@oKyM*7WYykM->19L0;(
zw(_v)_0u=q`GLE~Lxz?#pPq4=lL8Rh55HKOkxE|FGV0fvoAo*)*!NvnisOhDs?D8E
z?Hc@-cq$XiEzTTX$ut`MQC(Au0syx5fxT>2AFD_zqPo^bByEGmLSXmxotl|s<P5wI
ztsdQSE><LNbFFHr@nk^(C4f?1X{LHh2ZbodU7gETW1~kSVyv<`)zwm|y=B$A-(Jdw
zzxao#Pn}&ou(^hks?+gS=eN>I$I4dBLZvJka=92cyc^ld(&Xk-#qF1Figso)sEZa~
zh`u{hR(WP~`#WiHggd6=#J4{P1bIh|hmx|Sg=?RCFlHV7cFp>W*@LB}9LULI^m`mH
zg7`yreEU^(-<wbDUcPhvh!dFuS9x4a%@;N(u=9*akRx9aKEa1aeq-djBR@njF^$Sl
zqtrb0x|&3o`d4(fU$oqxl77DOP$WQ$2kMrHjMqsDUjPMy#rGwWN$F2ravcfNLl0x}
z6Jg=cOVZB3pT7j_a7CvFM}47V55>!l3<##X@6HV7aL@s1BZ!X$)3Qt~jGZZpIX@I&
zL@4=NVA1%t{!kJG10poA!^=3|xl0B<M+YJX5Eg{de7QIrE3l%&?+|hf4!`y+$R)xj
zY<AV|Sgomns@R5ZdHL<%AKR-&!J0W=iS?XlUe0@?D);g@J;iCKJvcf-aXk@_WKGaZ
z=(DHoTB}i1!1V;uFb3h|E}yRIGn1rfoUYA{#Su25Dq6+1Y-I6)NISV!;}S7eDAi;m
zsnqzf&~c|#lgm_QA-YSUh;8mU_1U=UEbIy8-Ra6E2p7FnJ^#w%rI<B3sO{+*+wjoe
zZ-U~1sx$wbJ+iTK>`2;b)zXd`nf*d#C0~j}m&4_2KIXJ1?)>!^oXU7Q`pS>fMynQ%
z7|grY=2{ayj-82BQg$ch<)lpJS~mJ{Rw-sD_ik<<c)ndrCN9m@mc2~k;NHnSp=3gr
z7PrpQe`$DJKJ0SovrC25sp<7xdlh*QMfGI#p-R4-jfXiZqeLDx_`_9tN?6Iu<!B1I
zzp^p!W+yqSrBv$S(zrFL)7elay|8rC{&|7t8&bCi#_!`54doHls@QQoFWjcV6=O3X
zs1AYqHPd6IN&Zl~5xW+S(?TST;x=(D<|Yp7tUUQ>W6lAgzLBiNEb2EZ(O4*zkN`4&
z&^6Nqs($%vr+(q?n|lj+EgC81^4EPRUyV4qR@r(mGkyPt?pRAwto_U#)VJzaN0w)M
z_s(yeJwE2B(j*cA7ALlg8%8dx@4Zi(lQR7Y>iPEj3fcPH8wT5Avyx90mKUvbnjRe=
zk^S}YXSshJxpU-=BTtRIK!vHRsO!N3ejoMl>wQ#sLxVYr_uqfhhi`tFy!SXVRI5aH
z`<mPTZi9fzf5lmUvf?u_5{QZ;vx_*Nf{zZFx1?+o6enrV2?Ei>z%;?`!Yf4dEKc{&
zB>{tA!jWMN0Y1UJB_@i$ng|5I(2ggkfhgd0#z@(ppTP)xnGwuIUpEs*M;FWNVDzs$
zhYSM_1HSLu^%w!><(NMrKg{r&l@hd$+wwUINCwwyeumfL7KFxuJS|GV;E13>rXAc1
zE+PeZ2#8|{pRFZR5A2ERJP<FlszG0MsX38lnV4cV@<+F>o*&CZV+)K(4X&BL?oe+m
zxlAMJIHVXSw_c(`S7`}n?Vy3I8o>V}laDAjJg!;iE|_YzA*^+FjlKG_+n9wy?=hX)
z(^I0Q4pJ?ug;%d$jz&UV-L*{^=Dl;=d@alC+;!VGC+Dhvmwx!k_U<hs3e2Val@p+c
zoqFa1Yw*XHpUCkJtN|+W?axM|$(($`LOyl0bCA*`hz+IINzre8yVpHy#A{3+{7qc9
zakjtrWIQRFf|EG9|COh*7t-vWIXhSK4jXK?F`ajlUda(AgxqL1@-7_=$yymkyr(B)
zHqQtvQJEV(Dd@en-C8Zq_kr~Pqf)+-Mb5*IxW>lW%YP1{Sb?KW#RNevOC2@Srgi$`
z6Bo9w;h6S&M-N_z&0FeK=Obdc`Rnc0#6)Ihax(N`bH6!m({p#c>u=w7Jl5*6;vn5a
z$-;1`xViyRTPUYQc3DWw+%PwFTx~hK)8+i&<zII*Y|>=@xkG0w#V2)S6P(ySj7%-+
z0hCgRo7BH9H;M_pn9scG0qMx6m_~xtV$vI^e=V&wJ}W=8E3=uHUQdQ1s<;q^S3>40
znOU9HOiFwBJ;iFRWAkxdXw6(hMcmZI)WIpuEA*$gPAEzeU{0zoJOdhphqq8kAyX?n
zU6^?A)bZx=gC{nbcTKk2EkjuuJ$^7Au~rMk*sf{K8BI;+CdQRUdSzl_Q<N)(R0bu<
zoBZY{t?HxYaAEc_)r<b_WP9TB+oW4`tx!i@5m7>U5{?3_8i=lu5gu~m&BBj(W#l<(
zh1#S}LuTAg<OOCZvbu=6BAc)Dh}{jpuy0xink+b21_}joU^owVE*Tyh+5tqE<c8pV
zU%C4MSSL`b_}91LiBJjJA5O(!<_3GAEn%5Mf&}scIkR~TEAWUz-uPDp-gV#kwR6@L
zjgG|zyz^KX2;^=cS^QD^7m~}+#Bf<Oyp!P_`7#S<?c87>#DZ}X;f32JQipiw{D5L`
zqJP!+fN-l2N)(`Ad?-A2qaUFkRJ0ol3f9>K5dWit22k8n_uSmUtgDHp-g`T;Y$#QW
z96k`bM=KpWR0A2X?9A9ej;rmDTmZv}+*su!umrqhW>?pVw)tv#09<gv=8Nskt<9<4
z`S#lS+wW;hh)<@lsGf7*EJ*cwtk_hik51OhVk*>Mnn<~&mHiDZGqcVJJQEX)P+Nb3
zb}LV_mRGap3%T5`iz^>!F2p<O)m!i0s+oy_Cp5y*IS?J7VzAgWrw1wJ;n+9xDAvpF
z-xt52PbZTavi0P_cr`!u1q$58W0MD-11B;&_hlmryc=qr$IJ8G5Z7uWmr;&VUZjw6
zqYHPWXVs+c$UlE0r-;B}v(-*$u9_O1DIYQNmZW75SpYsHC3>xSUv8}K*}La^xm>X+
zvxT>89o_!HQB?HMTu&BPmZG2emMSB+N6^-GTaEpWlQD{V=V$iO!dha#nL;X8Ds6?e
zOd-+aV)+(|+|&mP`HVz`3gfNou3FBZ+<o|wG+*z%)iT$thi5BgcVQ#6nYP2BxlreL
z{e$gYpE>R3SA^8Wk<9ECO*!3D){~+4$11z6b*uhxvD2=U?>IkwQ>i6WrOMT9nT_aa
zrvr{^IuH8xWc=*YsXLPbwe{}Btl|_qv1oc?Pq=sNWHM%b=ZBiZ7r};Y%q$!K_J(A0
zeD*XPiq_WLSnGW!!jqE=dm{PhZl;{gF3oE3Oz8kv?yPTdbx!o!(uGQEG*ud$&qi%d
z31wTL>)<5cNAMpJ;Y-{fjckql{mB1IDb!umB_N%j4eSG7*%F;SoZ!&kWP1(mMrJfT
zaOB-4e_xxtWbV9v{*Vdbe@C7NkPm2t;Ds^cceH&S8P&vT;P>DQ3}R;ZXZpg%?|7&4
zBmqE^LHR)|A|Qz3CHs8u{FRxRMMRBkCg>W8`wi0^-IDVH<nqo`1qKfHgmnc@ChSN%
zJ%Ve&?<j!Ckx?Of=NAz1J%T~6zHGrFCFm8S4rB>Y`-JPszYX8}fu<bd&A)>AAl=}x
z1-qvyq|02vDWehM^nhc*2e7~w1FK5-Qvdi&Vl<sNO_xfYnb8$N$uvWUv#ZIErptR*
zKKQlkLYbTL>2ypuW>tk^rz}s`kKg~PpMUNRlVwyCH{4uhYI@H?Uasd7Ra%b}W{xup
zP$SXY0^O|vI)CRukPA-4YR|Iz;*@jTjpQfY;_Qo;Za%UcA6(pOE^7&UzhcF_YO^0<
z&L(4(b<;2{S5@Ux=}|5cT8Xq)_C5?NYVegGDQ0IL^ZQ6Yx~mYrd+J~@e^WhvU0jv)
zt?3zkJ6o4P?O`~U!)+gO;!b9wTm<vT)yetJ1od*acWS&BaY|O%$V$4BQ6~Aap+;`6
zfWR_~%%8g3>)fNZ6=3S*Mmuz;JkRIs<Sogn9AV+d<R^vFSu43@UoWsl)~Is{qc1Cm
zllRPBHg7*4O-*0(aLo3s3&?P%6rhH!8MgRmcYNtn`x7j~mzHLe^SRNtEV`@d32U7f
z^R+wN)-SyK@%C>C`?Kj{B6XvVyjP$*gp^w>@A`+;u|c&rZzimz#r@gHBR9NRE`p)H
zT%k>^TtF;4zixHtev9@VZ$=|V(QbddRk0R7)k{^5FR!%{4nTdeL1K>)(?L);ioy<F
zF}d0IqR%VRK<ADQc0alGuJYQE)&V*Hr%LoF)>w>v+F3eknEcemkH^1Vv(tJ4$(}Ll
z3I1^%g*>A3Q*nNK(b1=!R8%%qZ!VeJ{`A8SKC;=JyYV?z6;R#-q(v<Ig$vd5;pv7D
zva1~f40-0+m5oz$PM1)IYBJVsmGT9OLB6{%Yc1H|xshCJ>Z<?o3(qXJrte87E!Aq8
z!1uAJHO;6C&5@BTY=_?xe!!GQesScZBQKBq8hi%7J@N-5e>(CvBmXe+FH{~#piydp
z+MrHRH-lgAKI&0qRlG=j3|SRlroKu2F7?;o*K<(|xk4COFy8|agt<WGDscwDSORm!
zj@vMBJNnq2os%Ic$XPJVVQKFmSV=Cy@S0!(`*MK@5q~2R%-`et`2BrIFd)W<-#?nP
z$<z%}*aG7NITJX~_jN!*;-DWgAZ8DiBB&BIX!|L9q%EdTIPr*w66Q*<d;lc`*-3(h
zBo~1wd>5Cw1I{;CfC?jaM9DW*{GQ3;g&0CEF^v4bzSyA3J~_s~&+a5k7<3?zlgJIB
zJJJAIcKC7!C;RbGd?7$vgh+UpP-q?(;<JD!;9?9|fekyxz=<W7f-?iqrz__KkyRc&
z`v7AMv`lmadL;wEP59)1coe=%*Kfaw$K`M6hWA6TBqlk)53nO^$<h<p1Ka->t1!}<
z|NHpAi|;id_e5+ZvOq*{xRh`a4}>4sqKe9_teixhmvqVy1~jUXR8hGEA%Wx`O6o6N
z`zzajasm;|bq#E46(#1CX(1d!4PH${DSNG2%%Nmnq!Hc~e(*+XDH=|I-XLWmMq;EJ
z$HWSdqmNMZwU7SkAFJ*=to;#jOIm7#rb3`*NFu<}3h~u^Zq#mUPtO>nW?C*Ro?@hl
zywl$PoRZu;EiF^A!BmHPoWA&NhGC3IXNCLj<9wN-zhP~jpgb)z$}arzA~UD8v92k-
zFk#)l^jz=QLg!ja=_%Th9P5Mafty&Ol9A#%>dM(QkjJN4T}$(3woQz#%Tt+8+o8sk
z{jq(ASm}KNbxomEK71~-i(+1GT$IiTOg;R|a%>xXS-n*yc9c`wckgG6c@(ptC_I`}
zZu_^A&qw3uE~>@MU*AC+$7F5BwO8Mfnte+=wi3}$BX0Xs#l1?XIt^0Suvk?PIZ|v?
zTsdfgBi`Wm6qfn}Q<1hmFmX@zZR?FjV|Cvj?4h;u`)t&^+5XqL;{M_u-qB&gbR)Ew
zeqkNS<MHpSofhLoHPsshOsY*A5kSpFic5tOhMSNS1th84U#y3-y<TAwkZL$qq<yF)
z9Fe@cNZ}C{<A`$gP#k(s7be2;S(+I$qw}V@|Ix6L@6qahgOI$U5G&T6^@L+F)bxo_
zUAWbL+G`}0L>RS<!@!bhs17UHvl1f~ro;Ei=55cxrK!|r-KIT@Qf%NO0U=o@96Lfc
zE+xC8iFcT;p0JAFtgcndv1GdVxuo}$R2IH_eL7um;<+wLARURyVN3sF<Y+oJeKSCT
z?D?;Z({$3?eo=gQAN`qIR-)0f?=Jmgf!@r?%fOW7+4eZ4x9M1CT@#b2h7`A}ZXy)#
z)AWO%zi~NUG^q*}tl3a)`}9;Xm)rN%@n{?5{H?ziADB5QmZ0oV`Q&S#u_x~A47Pvv
z2NN@)RBuI_&_mR#d@j8!)zg0G<zsK#-gusGWsc0r)D3yFP!8LNk~#4-wT}^<woI2U
znME*hjLn6%zXz_B=Sh`XuUVo}^nvMj-uC7<6^k=UqggAQ-=M3vfsEDzJwh1FcF{RW
zTh_hhbJ8z!weoRbt&CX~bi-B>HB>rau47^bhdlUhqg$f(g$GrT0j_BR;jlr$9GZ!P
zND*PH5f3`#Y2ho}FO66u`H|+xT_cZ;ymREkBcC1l!pN5p%W|j$wMHGH&Qdo*e>_gT
zlX`*ru+P%^CF(bb-5RJ2@-LA%z7R2qj3VE#?t<M&yt3HQ2h}C<&te-MF7-oKWDZXE
z-Cd;iMPx@9`C<-|m$;&cKz1RGiN!c<gj@~+prFN|CW-G8-f4?mPHK|kJAuSHxIFN8
z!Bax2!1>LP(LmA#c4e?w4VJ*eQDPT5_5<n;(nGF9vv$Tv{zqvwQYRf5a!@W%8xYiJ
zd_W>y_#Y1@XbZa3-w}Kx_k;2Ii*YmpHm))h6UwFI0(3gGhW%$po=lPK<w26~i)BLJ
zNuC%P4l1k?1?)fkaiZP=Q#Np}4T{4(Br2AK*^mGHA-Y7N@ISS+yDWJx3Jb6iP+9jL
zKGZDzmk<|TP9`ht1DY96WS--A<ILZuw?DZYDc*SLy6^tY2In1G?M|puxjbrdF{iiA
zAKiB^+uAyKI``n=a<8~nXQbQunNlO!Z}eKNO!AcjdDr#&hF)CNWA|_m^X2u!8RxjI
zMSuQ<7emTSJYl&grMhrP<MxfJ&S<3%&&~a13MDxE&;M$qwEZ(~flU;}84zX+DieG2
z%P-|B&bdXEFGRf(y?20GVeXwxH<}d@FG5kTLmPT7J8)23b-m!!Ld@yLdN};mS01>b
zz;(F)md(d%&D-^`<1R+brR!s%T!VS1rS}(RlgU=xEykkZ@wN9IE&T0`_dZliWnRhL
zd*o2qSYsaNVyK{&j#SiA(TdgP4=-*1S~8|cCgpK8r(Bq;#cbR14!_({3^4qt^+qRq
zn~Z5TCxsJIbNf9JEu#H4Uuz(4mXL}MSGf?+e!PCPK&QrA&Di4Pb^_!RtZ02Fwy+ex
z++^NQUllnZUjO7nUhnyCb()QBJb&S<)a?g4olq;E&uyGJ(z)sqw?y%G8k`#Hp8JOO
zz{+H9Zn@EGu;R?h!o&A4cgZ=&$t{MPlq#M1dCauDWL*8E-P9jHu((oBq8^h~RJrSm
z+Cfk|&2?+B?L(UQX#Lpb@f9P*Jn!g8f{Ahy-7xoXruXRQqlm0kKJ#4r1vkU9g+9HE
zI<MizE%0JS40aV^O5^Fb=6k(^RAu*Ub>rMVNw`&0KTAEf_sG>!Mp*m#{jF-_REUmF
zUw6rAUX1Pga&waT)llTzy%$=orNw6BV)c6;_`!I}OMa}gab)``Ej6Kk+8pD)>6O!<
zLituRU%PNmIi8eQ#ZLa=O^sqJv|HW&h*_U8&4n@gr8gLau7uOZI365|F(GjS@WRN7
zh;9GNQgv5K`}HJE$HTw?6n_}YBt`_tzGwNDxxXEGZsgzKJc&?o*v#!K-g-X<6$GM)
z#RbX+Ogc<9f89tH%fSM2Xz5~wO_tQYYs+8T5;C@(t=A^@Trg*G8UomX)Un7U#*RUD
z$2f*SK)x0sn)Cet<ZEC!!~2E?hVFpiA|kYW!_sg1^%=~h<3N}}Hu%=8-wv^g(HRk=
zJKK)@A%h?YJ|axWIe}!y${3OeBM5-|<O6n*5FYG7tQdmw&-}}6PUQ9E<AcdsI4=Vc
zuJ1b|1Jd{b#9{0ls<O?rVyR?_+bs$2Hsi$vDCU!o<t-3!jXiMN<k6$2*A7iuX_N@$
z<XXmpd%(cLD!ghRyxvh&CGiu=?JN~1T4ty_n|6-4u?gMW59gPlPF&(GR3v5=tm`k>
zLS*&$`K0TdIrC<Etdf3DhTGf)A|<z)%hxl}XgCe#|622^i;r|qsJ4l(rF25Q#YDL>
zv4g3g3W9SqUF|-8+s5%D-hJL^X?)r|u-*PJiWG!R{`^=na`_7;Sg+Q2FBUJ}Y~FTp
zxpT*(Su>KmR)kwRDm6gIW^Ao;ik|4+<;Gwq8p(rGQ<Zr=%7t#8*%OX)*R#ch4akp>
zeY<C8pq{9B%FuW{@^P3vTCH<?cBR+PE%6lU#i1a5D(-=GsFr_{5>9rfX6xnD|LS;`
zF6^GZ;h{Lq%tN9iqRiS{C)@L8mm5rYadM%k8q?Ef5Og0+t8^(%d#-Dm&CS)7-0paP
zd}8*h%swTWI{vaV*(vlx8|#Ft*A;JD*?s4koEtYoB7?katJzIGw0*T^E$j`K9esgw
zY;G-TXa4<>$GgXl$FrdQQ1vu5foerTEwX#~XSu%^dGE;ohJ71G=42CTr7J@e%w5#Q
zU{3j}hrmAZk_E_6--FcmHIhF&%CDPMc*n61DT;W1@w(#O^-T=&f?|K5vjw6K$*YT*
zhYgnu|Hl*pc@0sx*f+$8b*{YhzCnShwc{n*nJhaC*#B$|U@l_Nfzd){NT9gMh=w2i
z#UTk?4aX3S2vg|ws+@2VUb#CmrG1T#Gkk@f4mu$7njG_WIu_qFkt7%=CLQ|15n{Cv
zOiht^zAz9h6p4+2r6ul|vEabM7wpHanRzJqXP>`xBZb1p*Pd>je3^IXA2M~_)Md}g
z&oF$UKF5r<9=a(sXCTd`n#(rDqLPlqfa#J&BU_{YI2pfnWjEDW+;zy(L+_n`B0+s~
zkhm#93!{Q`+Nw3?zWk9^-!tt(s}hl7QADVy!<9W(75C0X)$zxs<Yp!ckTR86SX--o
z?(5}dy_3+ql$k2YqZe1Bp`$aC%O_*T6KdT3Bq}a0<X?hsnoUOgi>M)Tbh{<RLYAG1
zO&IpTFd|-LbS|3cI<e~ZwXu|)LhX!!oi8K~kEUZ~BiBv3KXCGt5>8lob<}l>x%Lw#
z%0#+rS*i>U=lb?s$OViNFK8>`L@5Wwy+6PKtsV(sen;Lrm6Yjso|<TZYz%3b*H!jA
zm+qG7lX6YcbKs%k<a3b_zq=Y4rBX?+$lPX7=OyGuHV)c$B5A-ghs9_indIZzDbNN_
zNfwG$fHC*j(XE^J5A5O%;Yj%iQ#+QWqeq>@^asDzI+bZ4H&spbFWr8yveKUz10A|7
z+Xv#hpn%8?HN{f{dVl%cOJ8-h)y+4)eZ9UG?`Mn-3W>^chRf!o;CEJ><Xy?PpO8VJ
zW2}E^KRgIwC89_aO^fk7{e&itqI_Yq{q=lfRFfX+*Lza^RH+L}$j<cdy?LTNeljZc
zYTF-UU8=q-AHArCXQq$8nDoSW6G}a4RoMA+awG>|+4gt3r=9kgLsKKH32Fr3|LVE)
z_Frzqv5XkupiAE?e4hQ$$a^sVVQ9XlM*-p_Q-!?z!_A+EWa|5`ZZMnuNj%hx0Ce~>
z+CSg-O22N-`MNH+kj(7?5fbITAI^eeeVrH>PW)g(LEW)#ktkVACsIE^-~$&p=Nskz
zWjj)UjFL>Y0qA?Nkpc9F0X9rU;(6i6vcCE4FK~zrk3aqm3<&=zxhCiP*GrhTWOV4$
z*S9`JQ((Y5W#2cCsY+Zc1Pne9J|9zl_r>k+7YbtuV{+-1uu-vdb`v#z(zQbJCeX9S
zm<i7XVS;4R_Er?NE^p0=x*po{nq6COa|(?r9w}Ey%aX??YQ=E5JYGrevTBb~df0m~
zRu;gxc=s)jfr5U9&W-MNWJRn^K6F@*Dj6#JKdFD>8TXpBtiN@CYW}YTIr83ed|Rlz
ztNh0o&6oftiNvEKH)$s{r#^mLcsb1JrV@#`0z5kll{XzOd}glnrdEAM-2T(To&%tL
z2=5zIuLc`NA)*&{zs0Jhc&7PcJALRwxz#7CVE&oc($|;m`qHL%xlp%yxkxHv%&}qE
z3@yQk^JbViU6VlgSWKqsQ7bG~+=4iBcXGb}C#nSoPcPH4si{ToT-q%qQ6`n5GOmuI
zxv|j`Z<nU%Fv<d_ruo^fZYMn+jEEo>WwWW|!oo4r41rL8CK^f^;No2Bo@1@$L)S$2
z=Y9`da=BKalPOe;{mIx^W~zAI*C^|d`;3@h8l_d4uNFdImzU%Twz2_P!fSMNuv?Yg
zoL%Sa7>cw}>Q_U``rZ9ZCpER-+w+uJuBSB)m7gRLw2g+-*O2i}8Dn8<5Fb4ZLRgbm
z^Ht@qtk!9BP(bY$5k-Y%DGDO?BnYdLWNr~`>HD}6&jMNU<jAul9~t??$QMUmrC5S3
zC6j14jr`g5+T03?ybWJLzz%m57(N8bGngyn4fVedOGiTC1YXfAOI^~WKNE-=CUe<;
zm+^@Spx=1A5o!gsGPuje;Rhv(iMT}lq$s#v^ERwTG7jP$#q1#(&-a~T>Y;NS!4jJc
zzVFAjUzg>CmV>c4m|etM$p;2!FxLpF0hvEsX@B^z3W#rE*I_Vju+sk_>pcJ@InMLY
z?cCEjPtG~*?99$=&UyE4_j1kwhXd}Ab0Ua9fD{3O1Pzb`NKhg{3Zh6cNP46x$x7Cv
zqHWm{MOhYU%aY|s*?zWY$`XVdzOTAx540cVurt%sU0qdO_19m2_&!rlIkiw8fGY8{
zyT?V_1@xZdvbM+VJq}*TV#JD5a{%3{NDEhmo!Ax|^Q3t53kP?$otiy7JUn4_j@o%K
zIWjWp7D6&@mAH242VjMYUNuJ@quA<yIucTNL*3{$7E8&jsE2jo*F4#5!?_<Flk>EZ
z)yor_jsUBtbJT5#m|7kFr&?mftVt%UUk}viP;%VJGS!T-rL3`(dRJqkpuO|EVaMbq
z{(82m6*t@GpMS=TBxF5B^P;XQX`lp0(~bjx7eqvuY=kR`R&JDf<tR7G4rhN-hW+*4
zhd(y@Z{=puRJ-co%JT67g3Jstq!d^$G^Hj+J2O+4e=Y<A)VVvf%X`@~e9=%f>$+}O
zlq{a#GY>50Qn{uf>p}DCN*V;-#dTH#?!3Hs<J+G-Qf@4HVKE)~_twUWw@Mi=mY(>1
zHRjDcGrZpd4j5BF--ZoJ0Jnte3X9euJ=Xcxw|wrW7iXheOLaDPWXQx={tUl>IH|{m
zehmnpI+dcT)Ce_3{TB6as6PWL%G)qcsetiM5uFjkql~9ap0gE<k%9Oxl}%zH@r^q~
z$0N!Y@fG^&5|PIK;P%BY)&YN^Ad;ULYRH%10)iiflHoq^7YXt^Mzz0F+BGwgo3wF>
z>EFx0EV!Hh7e~j(%9zZ&Yjy_;A<85cBV;5w9vS7R10o;%wS|myOaW3oe^2I5Bt$0#
z!#UXXA=P%^M|HcUHoUwr{rEEq)j~8A=?@f)bH~Tr;49+KC`@8d^+FI}8S$qUIT1JY
zD~!7m&Dqx%eXMtX2J^m`W!#_AL9>Hu__LNw^X{OlNu1VhucIixBorT%hwZUTVn?7L
z`(5XEB-)QFP#4mdOde<A{9qNlnE)P?z~{%%=>g?VP+h+Oj|=Qn#8CqWHtGwiqh0`?
zzI$YhUzn(RF-oUh?N*Rt-15lM2ai4&UY!qbc?PS+rqaDgGi&p8;FPfiBOz`s${3zI
zrD4Y!rjNN%in%0;bBM_16VoZJkstr~$yKq_<ghXw|0i!h4lrGYUa@UCCJ8F1fai`H
zk)a#f@er8U_l=HkdV82R?MU<a6N%D+gJ;yz+F8U>#y7S3MbOs(0UZ2*8(tcQW|OTO
zsRx?cs&s0yapQkQ8?KhylXv$_a>&YV<f-^f=7dCrzQWvi8@zFrJmLqJGT(xC`OQ~;
z;nBOVnTzRK2I$3dIs+W+*|3*SCNeW&HPPr?K6(g%g2nvk*m7#D)?@hGz3U~07IT8h
zB*YQTbT8Ca7c9%OGc8~rwFDJd#6nWw(jhaeOu*hYv77@KEl*X&@uNod<?p}xH_vHa
zf_K4;qC4}3y)d~n-hWAkn=%AoS9!Jy*;5v!8Vdpv(~H;!wJc~znP6*{&8kj+nb8#_
z?t;OUW>;#nO7j@sN+!<tKYV^)%U%CeH&GDAI??{$eI;>sLOKM{t?azB<~V63mQI-B
z80!Mn>jRI9t4<`N59<oGKLwfUa?=-I0<wv~g;YS@f!Q@AgD51yB;)$$-~O7F$ji}*
z&2lFFLZ12nX#T8u3$ZBXl8HrN@~<Yf0#9*bl6NNi4~hw~e=l2z)Zh@&nxYVUaU_ur
z{bu|&_B(qwcB%(BzSZkaZJWw59&tsRx36oZYHhANdN?(rgcg+kpG&k@`$&_iy(aOm
zsL;={UsvOxf^~}p{{DHd+0Jr0^(ojgSQczT>^ryL_t_78VE^XwC!>tmvBJaLQY%x<
z(=j&=i-QTk%iPYV-oGfvB2hagrLu=8J9%g3qe_UaXzJ*Bt-=f0GE(=4+nrgDae-1s
zYe_-lXXHoZ3d7Z4Ah3j4zRnbvzx0>vWiahndi}OjOJ~lyx=?&IkrE<~2yCwzE|iFj
zC_tx|VOywXOEU0^Z;fDNheW0lO>*F$AM)k%M+JxbhoL`(7x@R2NPUv}N$O|eE&g5V
zPpJQbDWT9&x<FUy5u$y#n47-ZK_)m!D<;Af@(fazh#!b#BCf(6XvoBXHaItsCV^Zg
zf}5P_OL-LK%S2LW9z~K<h|DAxkdg<b`+^EZ`@tbM?}@uQq^O_<fh->w?!yBnZX#?*
zH6XQ!gd@V=fA{qWd<yRx+k6>{TjK;`@*)+4Y$e`X@=G0#5mGJxYNGrEr~4=Qrv`QQ
zR{_7t<P$j$Roty0dT5{_k(QH1!#^PaK5@Ig9~m`*p!d7;X2VD={a4WOyJCLa?>};%
ztbZTW33?ZVXVA*Qs^E~k9CW4sP*5Xy8;GEV8IOQKp{kJONXdbffkfGoPRC!;PRMcM
z_Qw%a#6RLU2u-lbnI!TKf%pCyq*btH;3V?=a2!aBE_~Er74HfTwGfA!OPWuCR6&c+
znQSR{1&ji~^6$hvWTy|GQrT)TLxOL+l-gwJBabJuw5Xr{sptsMDl;Lwcxr87G2R-N
z)%3B5U?eJTB@C{vj9Jd<;Ff&38n1W8q(rk;qvjFbZ5qd@)18q!A6CNgc65&%D(D+r
zB&3z6Ph6Z{$y;EIPNox7R26znz>NblF0L1{)&7%MgSw50{eN<SsvBPY!1@*&n))EM
zKbp16l333tV_8d%KQ+wU_-Ak}IoWt;%}r^uo2Tx%cu6v?q<uD*D^Z=8GSyR~nGA~L
zq>*C8K^VudUCCC%O&C3ZNBd|blqrZ0N;}e#h}pdZ6b^<cv(|xi-As8~s~b-)53>|&
zmDmgCGvn0JYol*Hek38h^M_X36F>{ivf+H5szNn9SuZtWwe5d=3kSi#aOgTfp5k*k
zO8Wy<>gv#R#R#u%@SzVc?ezb9H_oILupjV~z?IF+SZjKT^8_ZY+L5~qfV^@B8`q3y
z9Kd|mx{WDT5PC>+*%Pv?(9)a^*O9A)Qi4`o8;J>-G$%bKFakf4-Z7Sohne}hR&vwr
zhQY{G-T^_SEH-Y*UWNI*4z>7918i?P9SR-cjESe_+Rd4kWqPJ$Mboa8sNZWzO9@?(
zZEn;_RARRjH#TZ=rm?tZZjSzFmSR(}*{Q<O9+kC5L_^I-o-Z!FC*Mg<cbs%_;^4W&
zZDNfNDaqQfRuk9^T|GXLNA&N`3Lw&vq#4UFD+|NYQT6D=r(d;?BhisBK6}Qz@h0%<
zYkaL#bf-k_y&`?<*70yXW{c60TVGB*TpgX^G%ve<qa`f=RJXg((WT}68(4N#)yWw7
zn#jOl)S8(P!1U0BNhe;&%sW-a6Mkl_csQ%3b1}YqeZHRV-4)5%*x;qgLUPYiqchJO
zTWD1Fc1M*&uOlcYKJm&-apqRJaBA+SD%Af-CUY6W<iX1v_fBKnv4A=S(z1xWJW)$V
zr7O(i8cj32_0EI$ieiFLxkaCg*;+xiCp5Qn|M8zio~1~|+S#p6BI68uN7z1Mi(+X-
z;9T=TzCm-t+mjY}e511DAQX8>1<v_j2|wh1cIc0WemL|aC_F7{f_@+U)AU#9Z_vL@
z|2h3vzD`c$F%b$xXblWIJ)$kbH{pwH0^bCw9%LB@CkKBaAp+q{7KlJvlAs)4a1hb;
z<F7!x;W}a<h2->$4CFAx%)6qNd~$dFx4{>Gd4NR1znh|x;RE>_{1zyg!H-09g>NOO
zJE_+|ybV?dUrrCasH6xRVpV{%cXx$DWyqTKV{2Ow<FngP#B1UV$lCvNjUaXPLz4X7
zyxC2}!!wYiXeC+(^Z{RsFY}{BzzTp&BxjVdEg|1XKjBgMttHQ6x5WbkJN6-DQS@5@
zk|h%4Ns=;tthZAHY75u*9MaJNl8C>sVeJea0$JptfRB^+QDmY7UE+5@P&0o`BUh7$
z)C-;$p-lHHM_ShNA8zmjek@ystRX?o#{AwUb>DsNxMd2??cL`!xGQ;Z1i<{qJCnH9
za9MCMsiJ>T84uF0w(qqgN#%Zc*#ONK;bykqji~x8g&#>Tpu#wL1d$3I;fG-00S>xs
zmUVdK1p^El`|P=qp1{Rw0QCfMjvmuJP;w-(1YJ?`3)M_C+5n)aTtM)}=&g?yUM!lL
z$;b{Rf-%Ek5PF%Lck0p9*?1&N@e$i&34=-WecKyn3lkm9p+S&>d`~yaFSw3j0F{mJ
z*4zu$rd4%gvYqj=92FZbCzG;QI$><jz5d+Q`!~b&a=EtkLa_n55GZg+tBzVsDZ?}6
z{?{ULC8ANEU{#mS>4dICjU=qfJVS$lG?{{jG?k6^T+1?x>9@bt0wr)J3+4n+)j+CP
zZbeB{KNB5qmFhV<eD1<SJ@EQikDZXhT9ntofNp`*2DpVZ4{Y<e!j~9s4XNogQvuw1
z^2Ax)ZSgj*Weg$799MbpM<Th6*I+8lfDi}{H3ry+REWwW0{pY}tJadG#6Z;}%Qe#9
zOhX3TB+#g(q>(cx6yV<?7@r~`W`O86Ebx*L1`?iPbWuKjB>d8)^M+u`nqktSXT(9<
zp5(%?`U@hZW=AQ&{YFF%l-)qm)j{J2^8yc=?|1&K?b0!jrC_@TdK%p>vpk;*)9{zY
zE~j`$6yNzF54*q0-#cZ5G7L*6WO;-C`<Y}aJ1+yfTV+S(Sr7tJ*LXG$aK29f(g?}%
z^>9fW)nfERT!jlaqx9{emVs3JwluqJC@<)@R+*A)WWvMQs#!9yL}~F-7PQu}sm|zu
zZmCnN^)81>fHEsiZCmO2=!hIH?G24}SQU2EXpuG}yi=KA)Td0RGNL<geb@#mhn<=M
zby7Usa;sg@Ub9;^B8-u4n&$!S$WJRkAc!(_NR9AQ{qGLXv{7htuN1bQxc+D<6_2Oa
ze{Nzia^@G|lFg~ss+H8K@GRDLhV?dCVT8@YX&&ADe3fZoai#ljh5#pA6k~Qqw+prU
zoEX06YjQemsoSmAWP-OwGRxSJA%<k%B=a{?JXE{!%Vr{@lq;=7q~lda?zh%vHG^~a
zU5tn(7n*n#z>0COBT`nH7HUHB{^XZ51Z1&bPp>c$C6s8T?2?J45L6}cge2HNM>vDz
zr;Hfpq_PVKFBqDraAPkI!X{PWE6xn8vr0Xx0mQ3HH|$(|($%PLSmGEn<~Zkmor$vf
zHDle0RXT=P&P93Fu;e7|uxbuX1t+{1=fef(kdw32Oww=<y07kV7N#;tr($Wb5a9(W
zrwO{AJj5D2U=S{z{qU?4IUC`+lVa!clm&zdo~H6b0`xl-dTHB?Wu!}uRSJ-*aow_%
zNNL;Im@H(T%-r(X@w~;q^IaCw<<Pj5FKk6e88u#hX6m}2LCq^kjt2Ipu|pwK=+qSU
z2S7pNwzRk*D7=~A`rndU(nMCz=aXZ~Xp^GfsS2LTU_FlvE&S+$nC1TE(EmVuLz#km
ziB4hfcA37DzL$OqEBlM|E8x@q8Tyau?}AJFZ|NJ1$hZtFZ^c2_17!DLF#_PvAgY0^
z-2T$AE2`n3^;hJ99SaiO&r)y#_ieC!>kw<uO%YARJTBQ?Js_wFZWmcHcl82%#%hJV
z25wJQN`G5Nj^GFKIRGQ@mv}4*s7bJ;dw0PI*8bfkCrEGlu^Nzd##dmVV32xsg7v~C
zjSE&GAe!S|{%$8&zHkMxgJaDi)eIIUC=NJ-s6tQ-$mifSj0HOAlM>eG!2*v42PzV7
zfRgYcC83@O^$6NWzJPnszb07Ff*SjOaTYPNAv731CUT#k_X0zw-#xx>i?H6k+v;G)
zjAF^!jW&bV6dy=={=*9ksFGg|>>qu@d{F9m_~x_3oyPssarZ&;H9S?g4E6A<;WrSb
zd4$&ut|H4lzV^WNhx-SoVc91ANB+l+!lYx7eFbd<iW59wWUop(%nvB>pK`b?kf?2R
zt~ZMPsITI{!XT8rwiiY%31{g4rdAEwb+c{QI^!nbjKPz_`S=SW6*8X6!l<tk5bTLj
z1Sg^zWI*H7phuwv0E6FalhK8oale&i@@V|a#?fD5)`iX=XH=Wf1dw)N*GOk55E?{7
zMaM2s5wE%(H#E@2x}dB}r1&YRSO8%1A`L33o@$NF8q0@uaB*=uld^cXvQ#bS*OO*$
z!D+Zr#5(Cr<ULf1Us!wNmm0YoosCg>7GbjyS}9ZA;=x!Mx#2NE06pRQ)>f|<%M^|J
zM_6mM7B-TZw$hv*e%1~tN_fo5o*74!9><0h%1Vq=jCxm*eaJN}3X~HzJu3lmN)wYg
z&Mhz!5Y)YriZl_L65Ve~3V<lor?shj*Wx-@=cFeK^AC)B^;S4mY1ZTEuxDmJ`uLH{
zN>47zn#PNg;&pd!dA-%jvPw9iWb!iwD}v2)j7EPYbUCbaCUtkDT5#PkkY~AaNU!o1
zYjG;UQfu&Fs^<Bcq*)M>tRC(>xFXNCJ!{HDKRX&1Dkv16NOM9*FVUd6kV5P<<8?T%
z)s;0CK{PTev7V!Y!K4B9ESLX>Z)+?<DeCZxiVPQRs*0Nj9WFRHqR7Go=@csfn~<Qy
z0q+nY=$>SUttuG3Env;S`srl9Z-I?Qf0UgA2)(3IVuZ=S0{L~=_5|*>yd_A(77f^I
zRu`_6Bn4oUB6BcTnYGhA!2kCEkOq8v8BtZ!EUU?&5u@R3VYKMKXCzhU)Cp?O6)W=0
z8$u`-YKu-(i&c8xs>xwDd*hV{LeV3)1FA%6LRI1=Wu%buoc@8c#fP@_%lpkg3ss$i
zpVxITeFy>oyCXWR#<$##eXu@nWh1IQd2PO^i85#p8NCu?_wBWpkBB+(TJ)JbsIPLR
z1`N%5vb?RVH-_<1Jp7Zru5N|W;#W43rTr(q3I6o*$o#>QHJ{9VwT<59_!67D^TBJ^
z_;jR7zB|*FsDKd;02^YnF<z);z&<Ur_0Jt#U(YS<jjpJjqa)3ArMbWAUW~S5f;snr
z(g85Uz&Z;?$*P1b{LtimtnlqWIvsJI>pvbZrBZY!gZ!rK`vGBn^!%QGvLL(lo-+2-
z#2MOPJ=Rc5^|>>WQyK@YPa+iOm4>2I-~NP||L|mfBr!5;X4by4|F~wj>iqC<c;v5s
zVOgT1Aq}>Qxwl5<94(v_RCjFT8@<sLNzp{LS1kQhCt9pHi4$8z*NH|fQ!1<83-NhM
zH5p;USQ$&efIQz+)mUVtw2nAx&oe2m<YY2jvyh|cZ?H~p3h6kLv8%C=Z5eT)(3^>s
zUw!UcVV<$U?MXN52RM80req^*Uo0w??M2!vA1L2;YAhR#M4Vwg){D2Ni}a;%o|Bx+
zBm<1+j8Qfi4tj0~>=1E27LtnyTsdaJcn=UKj#U_tDmeu?Jd4;m%~ABa;d*S&=ABFv
zOhlp(R>fyjmBr}YR~Dg2DT}Piyau}ti0^KXC=){b95`9jZdNt5<Yh^e-}!&NZ0Vjt
zgAI#Z>&We%U8+{wg$otY2B&rsa9oa}7ANzw{r5rd=XEYqX<2grx3oHabs{mDyt9A*
zrWwJ*&6L1wx00C8IXAY9&UAjsO_atv;Lmtaxk`N5B<Au>;p4#Xd<wq57?q=H$WfXh
zb_Gc0K-31SK3P}DAzyU+Ypbt}+&m{(zklo^|6;Oa6RTsesJ-jL_V>sBqU#$#2WCxw
zVI@aNv?av<&BAxf!V2IK<b#{bIXQz|JlLcMYpK6dU}?jePt+t|Be+>K7D8WZ@o!F!
zVnxC^sOZfjVb(XJpfH5742}{D3Zhg<#TeX?SXfETeT!-j7HA*1pY#;*hzlRDBK1Lw
zPwdgdEhi84HLR;z($ZU2?!Ke<F;S%5N1S@e5F^nhD2__QWo*on&5drXx9|9!E<c)l
z4_s&n3wp}j|M{oi%bwWBvJa+}x_EH?qOJ9`#G=GSJU7{NMkK`R+G90dI&jJ=xZv)A
zqZ13lw1g*r_P|X1J}_-YA`kzJ*E;`%cSR466w>c!ycg4t55w<dGeS}fP3=8<SC*SX
zD)eY=-{~iFZ%VXeO7Mo*hsusDrsN(Eh|WmduqqQ073Rh|Zs-vyQcWg>bMycBdujS0
zN4FFw7aQq%?ApS@!ramxu&V$keNi+)JS9Z>|7|PjdD+5<5^dY;gjmaEFUL7ey!^!3
zJ+!N<^3-TLI&9ZyR;UV-QzOIO)6w#>3$(@V;%vmzjJbtMlNIyz+&N}zaag64-0)l@
zzMe9oBMZH;Ltl9O?;7FwiNyXbQ{u-Do~|GM&~N1yKHcpuR_5o|_*y1DnTmw3Z7Fs#
zr$yTvk<Nk^2ay*IU`H`mZ6WC{=ee58x{Z6%Z$vF*{2<ka-)@hbxZF}_3SVAw900#O
z@^m~EEs8&Q&5$!`!(MAhDY})*3hN`xTh`PBb3n500X^&L%)+_f+}=JgZE#2sYPd9Q
z7b8PHCdq5USGc!_UZb8s=HI8NuTsB4eGA+p-=)3}9iPmdEHNlSAN5DAfZ-V+YZ7%1
zHm$&I9P9;f_5geXDziT+gKID=!81Yh#jZbPL1sjBtuPt1JmEG6L^zogEgw73pUy;=
z3S&Tr$yMYXHzWEev^vi<gbb21aDhKZedXD|h@1*7l^6s`aisK{U&@0?)5Z)TKjP)9
z;DH?rW#ceWfXR)5moEkCNE#d%&Ts;%l=tTtDI2qtRLs|F(J8)iNmNOHE)$g&F<nUe
z7$>CPB)kjfgGrop3qBK5k}om*Zt@#Ru0*YP|8&w6KR9$CSfF>3PB760_?_&Y2z!UW
z@j`3yHRz<>Od50tShWNDmJgDSatAgx6ug`85%xVh2&U;mU;j#iZok_9;imJ2ldIhL
zosGxAbo9uFGxWvcU0j9PShBRtW>nY@z_Chd=e?f9ZHV!8v24y(Dj`Eqb1TxyjF@@l
z0g7^O`*aUU0oA+Cu5(xZ-J6H>3(uYWDK)w|H-kWB&%Lm;w(sz2c;%@Nef058baF9K
z($bTS_EOTVe4pBQt^fZN>`q+luwm1POIC&g!k6Vl7ram<u2L5xlY4f?_1jrFs(2YS
zk@X}VTU;xwI~HrpY>ewliL1+*$Q;!uCJR$$Y%$icD(ucu7D`2dms$w*iCVP`%|l^G
z0BTSWT@#QDQpl<5X~oma*<?Chh6gAEkOKOUZiMDQGAw~}f#WwEkyB7Wi`FXGwig!<
zBJ%p)k!mWWy3}X{nrp6-N%jA4<N+#fBAhgw(cEw>?8L`n(fr=KZv0OU6wUT<LSuo8
zp7)|kF@~kxzH6I$kLjv#sayl=p==?VNOjB`UydmjaJoJCNFtFD$z7bWjA4**hv2?t
zwGFQbgH4Ak7qXs_99yuQyl1XSiO}>IU(Oh%a5&_e8D3|A*>;d-*h~eaupuF9>c}xq
zY6z_r^zjcod;Ye<zT@(9e{t~irCYKu?%jKD?W`qQ+3h3Oe)>w2=7*18=)eApcd=hj
zU5U(frLkZ5>ADh=JP`q~xzBuY{QOw!V6@&4Y>R7!o6h+D#B4EnaAxMCqnUUvWgow9
z`4MI6xyRaH&m&5m$=jdlt^IbkGo|Nj*vi;wSO!6L)B~Lqx{IYJ!BQ`ZS`<zUB@{Dt
z&58pKhwgE_gh;n&nv&DJlJYFz&<b%mY$L|W%5EK4d8t0yShx(6PZW4gcU<asY&Dl{
z?2qMV%enr4Sf1RMDBnBrxdylYE>Vw`@|i?d?SJQqN@8bn>38l>MYp7iY~|q@nzw-P
zY$r+~B~kdYO-CZ0)VbZ|BrD6n&2n^dXvlzW@@?TaxU)l-;rsp}tdl;%ICUH-P9*c~
z)6`qk|3&>O_1n-^h`R$XkOunu>fkRXFEj(1%;CTpPTu`ZW$?E=68sc6uKhU=5i)o|
z0+7WXe|*X%=p#f9LEPmAWN^cDK1;l@<TY>w1hR}M6p%DThWbJd1qPyvoa$qu5~Tyj
z@E89EqR4m7_r{6ff!fg<Aix4e#XrRtQIJ@u0!ha9zmmF;o5NNU2sSu1h?w<VG-D{+
z4MN;;P9Vd`g<i3X--#^u#Uybu4>|!Apz}mE!j(Zo2AP6He4_wdjY2{9>$hRxSqgM1
zLU-g_jKVl0%s{;F9w!C{c)tB8E0`5Xl1dL^iL?L#L<4IBu{&U`854d(ivCWxwQL`1
zGu!27K_AX?tJ5DJi63@pjMuu2p;*|WNA{+dVk1{O$>u+68?mF~<0;9DCY#ps&d2`x
zlvz}?1PccEZ>8j^Zw|kIHM7}nb5W(Ogn`=@xn}kMD0;=T8;Ra9<$X4N+Z8cWz(qS7
z8djgtBwLo`Y_SCj?PSdXvnsg2)pYu?bo630^K_<Vs=7%FIkg6>91MIin6nMgvAdGZ
z*0p_S4|bz^_(q*OdG5sC`SjC`Y?lUq7_HgTc(ZuOoz%SRcSXznj~eMH7m09H$7#o_
zGzja((fXc9!81eDjZHQh6T?Y8RkWI4in^0w@S-J=2rSIzBJ7;_GC)@&4ez%q4mWDT
z8Xi^zJzR)wQU5KG;}alxZ1Rd1|6s8*+%9sF%S(~}l5{r{p2)0FKa)~m@880vMq~hR
zeq$nx?6wQ48!@Zwv%-PjeG<raf8Fzrd$H@Bxom%pvWv+DLyYd_kxr!Lxl*QXZmR6{
zO!#!T`{yyiTiR~EHhyB$UT=*=z_-4c1bD-|ybY#GI{q1NZT;*@tK}4E5gv6roz`Ma
zIaT<~*~z;OEEtIfEVotRKfJf)9&x1wakSKAEZ!<zFRd|UPM&2r9q{h}b1c?`>APa!
zf@Zqay1Z)sywIBt9e7W)5L%enDlFXg_8&P)NSqyInWo0=QKEeI`8%)H%*393{om7K
zNlv!YG3#P1(ixqL@l0bY{X)l}Pl(Z2R4rE0%A^Cb@@P3*Dmm-m^5L?_W!Y78k^Zku
zG^p*=ao!N(oY8sq#@}Saz>+Msx?!y-U?nrv?0(0Iv8>X6du-U;^tQrU%=G5yqeUo_
zVtOP&(}^i6lo6}BMw?af1QE8XscVchS0(&&Py9&d4spkZ9vOOd=$pvWA;=J$kZWIJ
zC??4?n9nkQ#C)ImTcjX*EQ!4o%9zGwVWb6OM<Pi4Z<v^v??m6gPh_5w59AfR5m|>r
zfgLS)BY%l_8W`b-xcM<MIWm2Hqu@>dAGSNb#}tw*P{Htls9_MZWD?^(<Qj6zf!ala
z{vn3jzEu-Hz_ZsS$`?6hoCp@2?*%5)Fb<IyIqJ(D^6nq;_i^MS$yg?PE!+%NM_eD=
z@8;H!2rpCzMfk={qSg7TD~y^X6NmK9c-SxCU8G9ir7ZYLw&$X*!3F5ifu$DkJY(b7
zQ2I)=uQHcM!zg*+<@Dn=1HtY~IU?0|RZe^)UQ(P%Do>7*hN0Slx=EVKmx4fWJQo}+
z;rXBmqza`m;!-A0#(%un0}OQ5K-@#*``=M2tgb`_B?}cW_XEW{7!uegpd?ZPdB^_%
z*BFPCC4GQ6BE&S2BnlXOal*~VN#cY2??JDUwPfHFh7H-TBk|`8q#>k1xGw<|BF`6B
zkq3r44}gDg3I^v`8+v=to4CuMR6NLFP(eu-#xa6O5q_cgzyS}ObOVl)H`3x@1qp_W
zUsb_J?Fh8+L180d6o&r^{0OlCpnLu9#@Cz9ax8Ed0)9LMahc;AxkWELN54CW23?H>
zkc`GOHvQy(6dcBt!SX#ejzi>D!42__Uk6{%Dfk*h7Wg*^kGrI&a49LoZ-f6%klF`T
z#GVAT1TZ3cg|sQy4WUDc;l<xj_$3M0#dXL)!KoPf<N=^}%9v45Iy$>Ji`*d=Xgi|3
zM$w?o7VkPhArVo7vn{m571X%MSLKZBa=fi8ikYKZTA?(006cRhV{{8g>555B$CJ&i
znPUv)By0KEV|z<`Pj8GCvIi?n3Q5$V+#M6G$u+f2wX`&+yL3Iz)f16F^Z<Fx8kNhj
zQ#|KvJFri%znTC_aDMFMJ_S(mS0%12b6V!89cj$L{0jGQMoV<^Y@-rwt1;dXo0L?}
zF~Dt~)(T!i-7kfmD81Jl=3-ee%sTH&QX#v1O6Ah<_(q}m1LA>;wm5;Ev)ZjqtI_uI
z+lfp+EDBO~Vf!dOJu;H@z*Vh+U3#a@Mx#*}-IS;a^x#QTO2*@IC7Dko<p?!ui+jKd
zXd)aaSxwMkwRYo$sZsDA+<Kyzk)wu-JF&`CjN$|_lw!pU^@E%m@6v3nU8O=v+OUf8
ziAWX*2MQ8WIZFU!ImbIn1nRoUhsN1xuM?6P8jmp|B#|4GlH;)=9|~>3V40bG2FQaT
zkc+hFl#*JEv@RCpgpBk!$uh@{G%Sl<Gr^?eA*Pe0C^pN7ilLAl&QqX(m(epkWv>YW
z43w|3qZjXyJzEC=YtCjJL&$UKd`YK7)nQGEMV)KY%|cDF;a*Ve@MJk+rFcNGJBq>B
zS|SC`c#B~=RybNv%WjiGUW^%Ec<<8vg{U*N)63V|AL2DJfz;EG-j3^lZx(t6;%>p4
z7fUmU#bEHjh5m=MBEzeuo*l(8CIi=owoq<Tg=}__F%_}cG|Q=rd$QfD-;jY8H<{fm
z&V(5bF!vG@DUU{5;qhZ1SrR1V;7eKxk#91ci!gA}7-?EQm{!2zCGyZf(lgWfQO=Ar
zf*C_Nf}v|{|69ET8YbqJtCU=zP<@Gk2UrpTx{(4EZkRI+nwCIx-=AQ__yWU=^1SM@
zlC6if>6H-v!!|>vSjMCX;9s(eAsY(YYN0HsbFmVI&H-;#C`7ke{m^H1^`jp9fkOSD
zd~u^KTX{{hr-gRN1OX&lPbQFESIy<Bd$^<Fnd*2p`cj6Wr4HN%ET<^db-;y$q(=dr
z!lbyv-BzX1TvR~=Zt3=gX05w#vQk4#yggPbR^zwOE3Ks+jm?;F<{;>dR#h%n&BMh`
zu?e^lC|X0jTq#R@4(ga0r^J3gs_BVNgksHFR+A}lwy<tY(&GX!ITQe7s|*XSCyzzk
zhLi&vxIU^Ulw>J;x>DyJo!bVP@X|@@q?*pyaK3w0lV9PG33D`b`svDZ=Pu2kJa%CD
zcyfNWhh(m3)N4ejxT*Bt4+H~OHH@UCs?iP;3D+5V-&%a8kWZyGH}Bat0yX3XIS1TS
zwHBwGkrx*m4_G_YgJz?wNcZpW=!RTomxk36LL@{uVwf7u!y1sx-gw$MXE-&$KAr-2
zL}(;0v=Gb}8BWZ=Ny$6w^=iSB>tH`Or`cB2Ts07dGASyKo+^W+Go*W!CNCihB}KF8
z)uR+0&l(cuCmj)-v6=V?Z%C$Kf;2hL@(DaYb(M4FX`Qb;B!kM}l0Xdu;YSqd5ca?<
zFxkNkstEDu)-f$U{nFXJ&qYo~yf#gbw-S$}fd-VOS-w8M;mInkjp+xoN|xp9X)%$j
z0dpxVMZ;~;yIomIKam~_DW2g(#mR!ZxN6F_;YEg{hTfqgov}zor<A0*u_wJ*V1(ix
zaPw$uZa7`IoW)GD<JD|J<TI7HAjsfP<5fh%WQuj^NNHS->Y2T1o)`Jn^Y__@yq&|t
z^K_<KN~Oz)c`8LKZi&v$R<7*aORqDbHm53L$Zf8hu}GB>Bt+d*o4<Z1=j2ydx3FgE
z*R#}gsK8~d0<$tX4f+<9)l*TVu3ui>3{A|jUgCtF-?~59e=H7n8U~}Dr4ueQ#$%6*
zEMB0L2nyJ{6-HoyaHG-6Un0JE-cZCsh|SUrq?k;-2eWF`DzY2H@ynT5#=<^BM+A-(
zx;C3NiU6PnO5@Ow20Os#g)j0Ha#>S|fn1>WQkQ_A_82Uv-=Kbz`WMunQiy~^`q}Q@
zKkRFizO|mX0D_eifAiVEA3)YpqAQaH70NI^f%K7B5utEmeI-Z9`t2t$L8bFwf%ZcR
zzWJK=x#~$QBu>Urs9b{$KGY2Ye@M<mL5#m#<2Ss>HaRE}b_stcy<1+O9R+nI7ecEo
zx&@Tt3R$R1L6uyRy$kb!A5~r|5)G3>NMaVcHO_?b2I?V*8U0(3=s#a+Lv!X3_>a30
z6EbPY_}DbegT5hvs9=8Co`C8@HNtlo5=c|XH*=tQ1g)`eDy5{&#J~_JD}(rQ-;gqB
zH;?;_BI^oe`<>|*IJkimB<iArpy`bQmnRP$5LN+L2#CpssPn{b`u{&VM+skC{Qyt%
zV{R>VvFj--Sm?A{IN7W0yWDsqNA;(a){)#|+bTSs=fuQ#NG#Msx-fM*`Upp}i%*H{
zb!5ugmxQG{=-TP1U6@<iOQ+j=N@*d??QJc;c%<FLXy(!nusg$V4S#%2C@i`9=Hfp7
zlAY$J+04O_Lh%|ye`M>}q374Pk|M~G{zb?J?_;b~{*`Y?LP<>uv5|w^<fvW>Ik%7Q
zjofwD7h|&2zfR30#==tnigND!J^Ngve<`+O7O%XQ`uq3Z`Cyvs-xgBdLm6uS3Q#w`
zN&RL2x+F)b=R2#(v3Xa_86z|F*0j|;y?RAEno3_tZXUIr{(nN!kee<@IaRD1bzOH#
z*|2+L@y2f=Bnc{yP^;)?b}(;mIUQNPH`G!<o9vdN1+yXUtS=s>7KcNNov8(>6jtJv
z84goQ771ZO4ASaNm^QrliO2r)ffj3Jlw^#WIJWc;Th@bMQ{Y^6RzaX4XS0gfcSX%$
zEn^mBI1qSDD3th9$s>F;Ncaf>+KNY(&`HVGxVV)cFRa6kjMa=+J=tBj%aY;HlogHd
zWChSE15j{X(7BLsd5cRRqH&HhruE#$#b4$g{G}78a|lQS(cCA`KKsZW<$a77`_@-)
z``qxd?9?+`@A=)YJtN)9!*Hw|rKIR&<BY<7Wbevd4?Ox-<2BDadi3JjEz?wjmc3f%
z)zM3jJ}2&3=Iy<9W1VC4(!?HB4STXo&7745i!bwe3pO2f>TpL5w?@bBrp9$?YB(C=
z5IcW%1~Hl8wtAtcLnl#=EB3l=&Tg|0f4KQ}c<xi~cg(lXz4D6>7uFBI^Euueu7!BD
z#4+V>G)to(tNdx|mFP)CV}__9>(<NRmp9eRXR7z!cv~zDyK0%Om_PsUv+wQi53TU^
zmM{-@dm<!-n3Z}mqdX{>Tq*lr20X!@Qr>Age5$M@CCz<;`Wy)KWO$ULM_L@<C@IzD
zpOuV=f<wmM;E)V|G-N4wgn#q|-{t0q_7DB!&|5=a8~P>?D*troKLP>we-7P%oq-4-
zva6#>N<Cg=yGTSM@_UGc*_9|HjM<kYgXvD><yc`F3$rf<d;a#H>_N%wCR@}J{`zvs
zx6xwjNcMjaWjX~<KiodPkU*qgAlX_F$E0LnLUTEYA#8f_!Zv6uur5ME1@Z|JWOo<j
zX93|hz7QjuNYn{`eVK!Ipgxw#JxSgsGAM~)D*6FWMC=R>@ZHR5x1OHKF8)&g#cw=+
z-`$*$UDT4pbX|7NxJwblD*y>1J#HC#B76Bv?nLhOt*zJdl)IitTfMAe(1M&T#Vxt^
z`Kv#_UH{|JiPF+`!3duZ8=86P@~4<k|4U;Qa_0`GxKRJUev_)d_VnZ1r@yX=R98%Y
z3IKThuOl&zTf27Zl-#@JoxAV3=kEUZLg`#6GF_<Gzj^<C_dG~F=$;=2ZzKM-+GEzl
zDGYjjTJP;-6Yg-KmHc&N572z%o)(ohQ<)ntnl_hIuC&C6naomOVvXqsW$e8AZ=T%y
zmdFbh;)|$z=0F-Jan1o}<FM8&gz2&KFSnM)$48opjkf14e2u=oJp9zv1tv8zW46cV
zH);Bx9+@*&K9kMv9nDpSr%wOU<?`jDv-67*HYrli^6u5bRw&W`<AXaNlr5w<^65L8
zJyuIeys%yQ+CyjhPd@g@d-|V|!qF-AKRx!?<NftgOO~VYa@{l!6sjTW-$XfHu>_7^
zP1)iUEqQmCA>bQqrD7EMM)ZQv&`0|JTDXh*y`lU3Ec`zh`jer52T#G@4!wPI9Fx_O
zjA!z~=xdX~St|N&eDaBmaExOAJ@`b%v_EXfz8z<i!Bm8ig$&l4h8UdTPXxS&F^tGS
zMQJ2v5yQ_{LV_(j#$xb|m;r!4hhKMxJ<KRVu(ZMg6_{{H8GdPaC$rE$H@Ihza*PU$
z`K`f>@)Zfd=J`?dSiw=}T_`BwuF1*O<FKHnZ@c{0zepR$hI7$#|MK;1=~Mk5(X_yM
zi*v6&@W7p8#X>r*Cz3yR?eP8=7yfZ!ZGr{7$eC>_)PLuLq3_;3Y)SQl2RApj&Za)`
zxV}A=EpkHi%&AuC)Z>r1u~JcgR7G^WmeOB{WPa}03op<2((zPzgz;2)<ueNh^mx2_
zPC0OJacN_1+3U1tYUiK6=YrR4EZDCe{P_1?`>S{UIWmVluY5s!%w7J1jhMZP6Df7+
zU*BqX78knh&8bW>onrp{=#leT@a_ot7ank!(CC?^$7=23Bd>I7&s{*+xi(W@dhmR&
zTp7D}wF$a}F|*j*{z~eBr#`r~S|42pKbyAq9F;Qu@Z)>ZR&I5EZc1TC^l^P^J!HiX
z9bUQg%!R*cc4iyqvUzfC!78MSF%8k;&xcBfrl!yJpXhB`PD-x#*i5y2@8PM9^8S7M
zmuBaX0DMcmu4(3h!zZ>44sfdRr9$uU6Ms83<rNAqg@*UFALW^)2|C$cS?+XK*2Ae(
zdLVz_FZ>0^AiF0#^dBH~{}*)HOVm9+^7x0yxFs4D!f7GvVEpvIL0fVISRo8X9Dz)R
zrLauashgi+Ln4Rqh7n9g`zVNLF`CHe9L2yviai;e7*=Hz?Tc<QY{NH4Zx}%YgEROx
z@iF1YcVD<>_ed}z$;pEi0FpX5aRB-fe8bei%?3h#FmwE00t44LMmsc4(pdj;SkGWN
zBrh@<eJ7DW8(^v=6W7;Kp~VuL?(WNP4X)^!q@AOrw!wXZn);uEcK9~gch7+mjB81m
zM28J3;dc~fB&o3PsDkedvz9rmW1j`+=j1jJfB>w^E*M>{ke^x`JG{8JRyyrcAz`9+
zXlA9`+2_%{*+VOtb!|c_*V_9%TR?E>1y;`O-!s90On_r2!Xq06&PcFAqqS!>&E>er
z-5Vpwz)YPqospPf+UeZOZ^#QH$Il})M`JWgw_wN66%P=hsW{7*x}zIl2&G+@jYQTK
zs$#KtoNco)7PxwVm8xuwhQw$R`4t|=2r2CI<NxqG;YdPfcM@SF*n|WS{FHi&VSTi?
z_gF&v_EI{X;7s~>gO!_$K-ehW_>F=oNHIS9sFDA|zyAL6h$q^78EKn3+^@;@zB2a9
zGAKau8Mjj{O0>pvtSn48?kcbtk*^X<4aaWOEWRLg`4QJDg{SAiL7>BFqltPMc)Ljs
z_}agV#0QT{xoPXZm()aZB{TX?nOh2%qsNXN8%u$p?BJneQ!(Mxv59n7NF48&sXb}}
z+-TqUvSgLhDT;sOQ)f#jid!rd3gtuFlXKnBRpE`v-qwUBYEKV`MjDOI_xLfk8eh5e
zTz>sN`&5>N`k3r#aSA*^mDK(?(u0<qOe~sgc?C<?kr@Eq1+N_$NhTvTWlA)fjrB|}
zm9JzIj-KoonFy;#im|h_?CgIol8LSWn)gQE-ecudLk%sggyZRJZ0F(i7go7yDaRg-
zttg3wt@W&Eaijf9z3ni_79KsO$Ic&LIGg)mgYCZ@YF5fxuh=}NC*;m_*zFCE(MqJ{
zj8yIHjMS-)P*1foOvs7H%`e=2T|LKe^N1-h5bAlfgB?m#wF;$R9X#0o3S#*F4m;)8
zP#G-TF9B8jv((Q~-wfml8SMl(!%qbEXB<8ve7cLt<4YUB?~~yktUHh?H>Vg82sowe
z&rGre`U_p22q*s>vRdK=f#PRvVYc}tBZ6u0@+aY-5d1n$C`)&X$44THg0I1ScKs;0
zBDjc12eL6Hcl0X(0YSE~V*_E~$3o>vazYT><X4AO>D||ezXbap=nf=^FKq@Z?4XiK
zWTN;VedU)FNt!yKFve|n_srv@3Vtv6Zi-=G>iH6FAWw16QT!ZqV|dK=D-LP$?$0;@
zvL{G!BLRh^MG!JX_Mwl7`w332JW>P+h{qUrL6G?fFZZ;zktoM^HZ25kxd!!5l02`p
zN9{QG{wcAX&AE+kK2j91)y?(<>|QyWJG7Jp+lP_wQXPFkPYOLXqPdRBjY-<LRO=FB
zvYSY)#2Z$skV61QwH;z5ZN{1h!P<MXk#!BuOgb4=O4gPG=rR^KbX$dxZY-MH4x5b~
z^O~pG$dsm(HA#w2xG4rGI`qc<Uvut1&I~h*q*34e-lwiARiHte<6ODE^OY~{i_R@Y
z*l>h53)n0_hyZNMgnAdsa$2NfBMR4<me)(~e8xR=pFH&e#TF%2PSp$2g-0TxNEGlA
zG#9^u*aOL^<g|)KNA(0<FD)5q_;fPhD*jx`(-BXfubn%1>0n3ge{tR{*VIRtdo|v0
zYw<<`u(dL0n(l;Xf!<WD1A1AgX7r5mEjWy`70l+p6vo#=GoVA@E}VDGWHJh}Q?n}<
z6A8s-(n)c{X;-T4)!gJ!`r2w~Wv11e)DBg)s!Z(2{<N~pA@L@&2_OzT=EXUuFgfFi
zrjz8uWA2`D_l()&?b0$gHOjp#6(ldNtS>66Er+wBou=0AiR|BQz_4GPi{?3X_@vzg
zMY#pAyPlKc^5>X)Wv?zrqw?pconbEJIFZB&p%<w~Bg6XHOAf<_?Y$0SIa!Y3-_o4w
z@VHmaq!YH8Yqm|(@%~U4oqtg8#Oa@}SH{KapRL_<tXCXn%iQGyo$sCoTIkfgRz5+i
z-QQY2QdD`B>$tZ#tK8|yyr^`PBWG4#*f_@W+LU(meX&vYi&SO`tS@(-=T&U-&wT6`
z&g>7{-M1TOZ@oLqeU<w`WGd{G5)*M_y-xz2Ia9J@nvqkh$Yu(G++b)($3B!6zQg_2
z(BYvwz?JZuL%#>@{rk|}Zy?I2fH;;(YLVIt`Sq^dXm|b(-v4(wHIP&cWP`8L5R+FR
z1a|cne~J_Fl%j+#$%-X{2Vy6f(t#6vAe?;d%l{P<l)QfYGm!v+A2AS!q+B2Whup4c
z5`lKJRA?kX588F<k*zC!^&@OZq~bvHM??HN2Mj3KsG`ZfScYxSzkSeBw-*ShK*t$p
z@RR=o#H#J@EPSP{2kRN{r|s;*6hWjwxCC*@-vRF8^mVsl1G110M_k!Ev~O;Hdvam*
z{+~?Grj8s43wl|F4+WjVe|?2p-G0cN52Ye^R)t$LORZNv(n`&g_uRg%g8Fz-KRhzA
zy-E#_t_U!DF&VQM+LK$&@%`5=FU{mHZdTexyJ_rzL>QLh!r^0k6xtha0vhq69*2+N
zsuUUfqMps~)b^izqskli|Ks(T5VfpRp@kE?nVB^vRCfF$`0smZZ5qj*$sR)W=*Nba
z=d0ej#!}(U=YOjIo3DKM<&U-&SfM-_PtkF$G<Mf**LzQWV$+gVj#Q5w9G}{Mq_%(i
zk8=yljn=|U>Gf{+FMzXW2u|i%grM=YtlhhjN+%NO_i;r-sAS^9OlU0|?R+i9vCQ_!
z_R)+SIo+y&OI2A>V%o7od8>HtL^x7pDcw2w*oAAE*3sr85w@gzp^)q;sj(NswXP1M
z{96wLdRN-qb5IgG(jDJ@W`s)3J>d5Ldt-bN6e?QnKR$lTxDI%-$CP+s^(WeQa+Fco
zr)P8f{%lmHC2MZ9_1a5zetAPwL$$4*8hhivQd9QRdbg`zfA7TyC5z0H&DUOgqfZyd
zG(pXdAJLYLP)(v^hn{)ulb`I5xU*C~KK*mmeaCv8Lj4;}s!M-tHi@|LNNVbn{g3C;
znM|_KVUA0#5mPrZ48;|MrO5}9>BtO>dG)2)!1n%^!pq#>5B(1HCB)kO9#Fylg8FaN
z-_coM&h+RxdXv8N?kpv9$wT=1NEvg)U&D!30TVpth>JIp<3~nqFm{8*(jUbB0Wxpi
z{YDmf4Bf#I97iPcVByb$1BLv6xlXRBBO;d=nEVSc!N`k<f&b%07G`4g2?PR}M*b&1
z%5R_vAlRhqyX6O^kg1I6kDDVjz@LlQJ_VB>hyB-0ArP$dyYh#e<Oc}jEG+woy&!^&
zREe0r@Bz1i4V|3jApOp-im&M43_>|FiX-GBauLxKs2O9fziUH9eej$hjKG%&<b<I9
zyX`K)UgirrU(fL+DDE=ok07&yw2MTWKys!149CEUG1v|H4geqC0AOiEUfHB0P$qef
z!G>wqM?e~Ys`@euJW%*Z`p$Qq1a=hC$s`2GS8sZxFTFrMk$4XOAPL?m`!Ru(FA`lJ
zz5zv%8<GO?*oBwV{An}CBV)L%x5Wml0EQ)=l*SE1uJAKV-q0lwHHK;inBWr8Z~;Km
zW3RxZjDI_`%N|>Zc?nMCIHLjTA436ANkJ&6)iTnHlW~dx!$?JpTZl6=O;brUsRc<e
zW<G5ds;4v{(5P+i8QWQnx7Mr3y<1R42f&fDYAo6m;nsRwOZ3JXZE30h{mg90wsQ&)
zW3@^XT=6Wskceqjj?2ttrzeUGmq#uR?|GHt&gngOboAV;l#*{PYUzAYlP3+fqjF+u
z)?1=k<lT$;1)Vp5N~uT25)73>Py`@Dcx17`-%rn}P-hA|U8E>md#ltmw*t&BJqkM>
zBim*q&7?<XX)12V;~m&ZfRvq#)y7RJuFvt{YYlfmG=dCo`Bov#2;s)L{({U1^Yv<~
zN}IQj&1K@H`|m9Yn`bsN3H$kHo_YSpH(B?9TTNE1_dFFVK6pn>czJ%-RJ>=NfBqTj
zR5q1{4a6SbvpPBR=;B2{|BKNammWPh1q}hw;EnmpW-=O0KE`W~O4VViys>6Np)uZX
z<>`!?iFpoXMeFHFb8$?8Vutw)6tn3y<|~hGsITXiMO#lIh!Ze4c-&M|i>QvHmtvf?
zlQoP|sWI$jwJ|M;2S+uoh+?6#&Qw!bB#ULs^=h%C07XY+&Gj&C2^nT46w#U#UyZ7^
z2s3J-f>_SNEOqYG<Bk?xIwj}{upQ)=fpOYnB0_?l(juPHvXit2E%_R#F7++sE*7%W
zt=yyc%PCQ1F!(ZTtX#J=K(94o5n7h88Q>1mdNoyx6rh5ZO5Hv4ckE3~9Wi@Lk9?x^
za!Ibr)!7w3Row5={r@~wmLu=GuC3G5OgPbS9N7}``BK=-T#0mqIjh@%v)xMOW;;nC
z!B<_?tQ_h94(363nYZkNGm+UQ7IRPFxLmTbQ#10~5s<J@xsa-k9YV;p7iU9m_1LRd
z`Gcd+UIzAS$ha>h+JILYW7nJMpSdNuBRi?7_fe8STcT`^l>67OpV~9t&iuiPFMWt|
z*btx{%#r?|+<o;k)#<AIOE10n;Tw-+szn3ZJZEA9lQ?SvmlzPt_P*TI4nxD&|D8DK
z$|DS$7H7xK00<&nr+F>G%mSzQX~4=GH9HeC!ePs<wiCWi*#D^TtK2(7d*PM%=R?0g
z^zEVVQXHI?C8|wLQLEHN>Tc?3f^!y#Uc_HR)D(6NU1bQ<V0ZiDGJf#+rrh_FPher%
zmD{^kSby2@#U>JP;MpY(4+tnCtWhfY)n5t*pLf3jMT>}O|3!>Rjxa(laG{Y0?*pCf
zCJI<k4g}k-AA>A6fo$D9va9m$-gkE~3k-QEFj%pC`s|GF_Z|3yQ48$keQ)zX7bGh!
zNk}Ua1#z&y+&%X0Mm%WPZhd{<GV!U9Hbe5FS){{vzX$y({OZwtkFI_0=NJ1QUb%GW
zV1K*db?c4yQ0|_o%D%0crQ_9C4={xc%je7d{7;;nPtIo6_CHcOxU#tKU}a)>m=%f-
zMTd_c4C~b+x!Js<!|?~?<PTnHwkTHmaxoUQK5RrH;gXWdhkEzj-4#c&QKc|UhbL#f
zm^=HvVv9v6Sz~U$M{_{Om?|jxn<sLj3Z1TU_z!=!O>1kvxVUpBd8+@BWUjdKP+R`g
zr}PiK^wNiJJe$fER-ei<pM70^`9mLinf{fop4ur+?QDJeiKW>qMrwRt?bC1739>|c
z$!jvd9bXEYo$0rJ(0_72yF_nX*h@9oRAs+dO4v)>8);J#ob=PYnT77?wcq*AUI_3V
z&u|5>Vr62(^vm7EShG3#NSckW)sEC^qp|MaS7|CERQ~?qO)*)|<SXXt+5Uy`sVPMb
ziF~a&MHdS1f8vf?dZ|i1;(6DpD{tJlc5dIkzkh>Eg^$miSRa`mq2pl{j0~n?Myt7r
z;k~D4k9!URZKT@we!sBi%|E<vwRg)WSD(CN_RH~JNu#f<%3l7fn$%Ss$FLkMaZK1q
z6e!K{c<T!-1F;>F-JS!_Ljv|^B!ArcX8%8Z;)>VEKE1DXta)y%(X~sh(xc3;Ek@%H
z{bK(kAOHC4`Nc@=zOVLQ{=~;$zj5KEaV0X3xN_u|?3bfs4?J<Gaq(6vFT3<p;fdvT
z|4hX09Zgyho{?!8WbWTc8&P#R!E$+Vaq`}flMYWq<1F%vvwiE(Y&Hwu!Ma|_%pt@q
zHFN&iqndW?qx-x}Z>nvk?-`$2*<ejWNz6_y5URY8pTqhx`$O2&ufiAfp`nk#xA}#k
zUl{r|qM7opuR{h_W-`_MkOu7jf*lkFIk8D0HUx?Z(U&mL{kbbRCOI3*l|7i?yVIP^
zY0MJLj9_*{zkz`so)|J+Fav!vl3!rK$0-<`PcHX&YGfh`5J9m007n%O%R!C@iRy&p
zfW||t+^7#y0ka+MNtO<=>Ij$6z-n(N6&a3wS{l9NIL_4KIfbF_ZuF-*w^Oa|frB|=
z@2HdJ0L4;9C?Ocp+BzcDi%z#yOXS>BhjP?!l)t(3g#s5*GbI_C>_3*fNF+v#9P{1e
z&)3dhDfXXtZteg6j2as5D!H%Src+;*&aQr-ek5%c3M2P5xmY{2V5Z*L*@pnin3qX?
zvS{QJ+Ay<Wl(MD%pUux+r<N%C%YX*urd=p5|M=H5P2Dbh=;CPY@Xu1m5((${k{;14
z<@|X~JUqX$H~e2ddHb9Hp6x$D)9uK|sHL~guRZ+iMEYa*&SYS*5>FiX)nDFuy>sAP
z?q~X^AB!`$D?L?F>RkVO=MRDoDRKA(aMJU(Eb#_U|DIVK>28Nt1?Sjo?G`>ZmpU{v
zd8Sh^wA?$tZzatIWMTUJ7(dDh|B5@0c%m18ruk)H9e;-|(<Af@y-pvY&(gP&Xd++W
zk!J*zwd5m%g<bN{$c6wv2EXG$;SeCI$cK_INC!(0IZn<YV+SJ)t4WV&v;I)pb)J&}
z6s#Zqr+3E}8HYXJ+)7Tsm?GN=;*h{ASXl;lfsw;EWZ-8E;lNK$4v?DoE8M%rOTThK
zoygCAyfo@ek}k=(FJtVEgSXK?w7WXGL|w-<07(vpI!^RkTE;jHV*&)h%NVJsCoCOk
z25Ny0BEN+J@q>@P^M$m}Z%Uxi2eDTEYD;=9=*?j91qz72sSCQ!?-$>I;x{SSv-tPf
zwUW$Xvjp-EVp_o^h!yasp??Z6#ZVjaV90JTs6w!~>J+TP{^P-8@&y2SF2q$#T25+A
zsx{bG`CkX_U_Wd=2t>f?DT*w%$mk>?1Y{S3i%}4<yr9d--h~_vd%;X683~y9E=a|M
z9(t8@sqn7^iC^B!r$$H5u&VGRU`Nxlo0<91Yt6%n+5FwG)b8XudUyZm)#PkwJ2yuI
zD_@=~mo;{=R&7+(rCGrelCzO!%{pKekQ%N4N-|+P>H3L%x2Ssb#C5%Q>2ps#q6tze
zpBNrHR!=A7Y=ISJJ_NwsLScul3(*`Ce*Ckig=70^W4+s*z3q0_wu^;ko)rXUVozfl
z%<?gti$rOCL*o%OY<k5c?5djE(Ei|!&pei#&K5PjR*suixNr~_U;zm&(Nw~jju@kj
z2BURvvu$^IY5z$3)|_@=PL5>0moi^H{Ax7yK<e58Z&#z#;?wgsuQrO)Cxm<MaHJ5Q
zH<)JT)dH;9Ora!JrnauJfObh9IjI>Lw;+qowfmT}>kfW*W!_$Sc!LWsQggSZ9!=R4
zFWUF-9Y5sO`tJ>KwM<4v-YE@JZ+9hDb`#^TDic|ErI5JsIbA6wcv<1~gvG^`%$izp
z4wUAi*j~l+YuRE>=BYo6XAaqUzG*jh6h*l@pJ+=UtQNJ1tJ<e?aw-iBcuo=>VF`@$
zSxMnT2jx`ztjtb>I>2=r^;l7jMxTvEn1)f(k~j85r7$=v%NM|TLT8Zlq{()aQrmPW
zlJbOoA+`;~b?38EG(nFpB-gbQB_p>8M{Ts~W=37QGA#&NxE>#6wN<S^IY2CqhV*hc
z(%fR=QOV8-=0n~4Bw4bJ&8^TPSO_<__uYBqp|5(`GOM*3G~1g`jXZqp+O3DPEW7Wh
z>@{kJ?Xc{Z?*k4ok}QYECfKQ-&5z{s<wDsW+nS#PKn&J2Guobb=%4LScWkdV!lQec
z_OHd7x#jS1x0>;)asEUb==#mW)6x2UNB$rL=&p0HYqhG|Cr`a~XpwNSS<KSh{MMKq
z2`5wK6`Pkrm0`(tPM*x%8PTJr5VCS3Mh40L5o%^m&{PQ~K4(PCm)OV!7LocPjkPTS
ziOpe?RunB|ZAU=GsjwkFbd=`UjL4=y`Vf<<{jbioW`C5+FWDzo|Hi6Q8BTWGP$=I2
z9}hg@8ogHf(DErPuXew4dSoI>sAPsU-c6;boqXlAxC|OBUeL4U;kJ|PTA55@W+JT2
zG{YixeD@;2XZqNjJ3kDT&3WMJODYoUI%`a`d)5>=guTZA9aH^cEiO%S?WlnKv!;;f
z>Dk_mzbkN8jbiUA2kfAnWd=M=pA$y7za6@D=zBx|72!(+ePf3@L)`)<@+YaEpkDnk
z%bJInQr~ohKjgD7TOqHAARmNkL1dAaO9EPgf4-b0`y*fYK{WZ|_s71GY##q>unpQ>
zBLsgjA*Bt(q~MoKe)d-tUs47{P!MB~d%^PHZ%lCJuDHd;?{1GEV6ifdV?p$5M+(Hf
zNm`Zwsf`r|rl`Tz$G;hxK!iEY8OI_;-XMbm)ry4C`Zw_#baUV2FGFN8Bi-VcK`H_{
zO<p;jtYIX)0yhq_$RK{PY!LGnviI}8Kql2CFjskJAixK|1jor)1Rx7ie1zpf;Zk_-
zq0})I*xf6Q69!v7m=!k{*x@RFN$S5ao3B?wPNOk(ET3le;gcKLrBj*_pD^OjM-pE<
z^sCjwlx+fo$%vKQdL@|*jf$e1wXz?4dG*Wb$ey&+s$0?ht2>KJu))Q1iC9L|tJSQ7
z&+*|`9^G=JJ2OQoWjtx7<5MNKP-`!=_iKquMeBgutj*U-rFbK)xc~GuPq|V)Rbb22
zlSVC^&*g^Sw^AK*3ne=r@{G*r@tqr|cD#Ds8}=sRuh5S!Y56h6t~*&K^sy{Rp!Cv#
z&gDY*nTa#Don-3$f9H)%8`AXuN7#FSNm8BX!d*F6SFX-E=P=zpIqjs~*_jQqIVV_l
z*~|uZSwO&&vxovAK*A^^Sq3B&0E4nETgbY;vSrD-lCG|8*$P*>dSq$0x!<XpS&;w#
z`TwVOd%7!}I#uVK_k8CI@7E!0uw{jh1{8Yu$|F}Dy7=|?r_=pvl*&PPS7wZXe8Q5X
zHhlGLu6coJ?#*E<fC{iZAUC#2ym_L!(>{3Q$U%IV%83bv0XIgAKT5KG78giwH^t@1
zjBG%{@S|dwARtx9H|g8V;*nL2v(qdwa99*X<{ZxDWo>}BBJ6$VxwT0uXh7oI%+_rO
zd_2_=wG76ell&*FoUfF~eG@Yd>^%0-+D>eAaOPoHfD)tBiRojfPj30f-yY$3zFAr~
zGed`7sMq>wfoG>9zWNJt=1ViB=()4^A4yLI&V!k<)F13KQfnyL--!9EzT3;2mS<q1
zlQV^N1v{U&@~4NR#N>+mQe#1h<D~eIzAg|<*871z!Jwt`mDm6A%>brKCN=u-eUbbK
z8EcXTSpquEP(==zz5y-SLmld_0>WwFuZ)4dCLL#EX7~4J4?Te`;}!6fCAgHqQS<rD
z{@PX7_=@p(ZrTE$d<7!){oMzt7(_B8;xTFNGY3yU@P32u5Rj%TD)*;>7Sv0IDM{y=
zbUox77X=2?n4IX*VD0oQ^C7^X^`0++C+NR=euoK;m;D)#jh}?v<S$`wV1I-C0Q(p0
zH}66tG{Rt898B(bg->U^IZ<>=!!zLwJ~RLk%($Z%q0kaRFC1YE7YZD)3XORO)Ru<u
zqEroV=Ms&e(R&$(;MCTlnC#wXQE|Rx`*T2J@uq}pj{pF3WoHKxA!xATk^{mb5S{Jp
zMLKSTs{j=U9bApMD^>&YxN_=}8Xc?yOK=AonWc-|f&k7Om~JB!eYfww^TOb=MHc~h
z2}=?ussb#0&~*T32zG!gmw>w>*m5g}cEVY(Xa$aV7mwjLm`9M9o@@~46}l+xo@pc3
zDtH#BG$%@tMk4Dl2A09hyGqcVH4VTZ+y<>)5U2yvedyT6S9xP_CCMoR!^@ldZ=XKV
zB6*@WIjzP|9X>u5*-sSL09CHfSKSwda6UCTJQkSXw4Xfn@oyK4t$yz|i0C`7`KFBA
z#K^K4Z}#ETSWV`%%JTf`o?alrh3Jql0bUDFKG5HP_X9DW^zjPNdFpfVc)HzJ)8=C%
zPsXLAf;sY)>~uEDnQPVtnvFo5HTEd61SA1p8!jFf!J8_r1WR*4+Q)6^@n-YALz|+e
zX?A~Z5OYSLz77Y{zEo&D(2{LP_{h!%N3*fJ&s<CwA`GrC8|N}!swcl`xDS*39MPO8
z^acHW$&K?RNb<`Lsaq0KQy&^kMe#E#x7=rBA)kCQuqNJUHAD<IGX5m+ErG%-lPrUc
zvv4@wDi3vP5Fy20X+tdsj`peX=o>RrSC98txB+qs8C-QZK?X!WW>Th=1Zv!<q1=%+
zVs!KezO`$>A<L%^3@D_)wJ0O)%_#<Ge=q&OW>`xM5$b6&=1T(G8nn?b*#uXH@V4-P
zbelOQkEn_nD&p34Z$5sWRl+q+4YWF%7_MyQRT847Sas?%FJCx#s(mk^thSiqzFkK9
zpanixtT`XwuO_d*erjq}UI;KZ&sDE#&-4rSvg>c##*BURZ>(0UFSBW*e{6hWc{ws3
zEy~_phX)O0y(ca1G-D%Eq2`8kIzHyx`uqyJ{?^kY_~x&BqdV?Yit&OsFpXglq#rEm
z3978b*7E~H{8XTQkci8>L+e`8TW8lwirQ^VaVvdb7Of$MKGP>&8ZHJpll@bl!jjV_
z-8&N4BKs?AXS-jEVzWI#AiwhuvE4sRO)7;o(G`b#&B123Q7hQXA;dr^CL3kLTPruU
zBqd9Uly4v!hM>%%P%al#wrEERd%e>E-*d^FK1?vhEx{9g-CY|xK0{V<NyT*z{~bpX
znJ6J!L6)p$_eT_^>{YtIFNakQLYROwktN?lX=H|q2_p6*#sZ17il=A5?UW1^2|56L
zeC2%iUSJruqaPtkdPoWeVxWTnKYYO5k5QLAbDn#^5C03Ee+2J`-vP(FADCg=fV4db
zF)nWiMvye*3NHvg96D4O_sBZt0vB`z8vz64u0`GtAWqp3#|+9PWYvT#kk2SmYNPe8
zqh4|_2HgWt%ZZX&l<iPK4p^Xa(e{r17hMgCf<>1mghwt8x<Kh%gz$2);%;@Jeh7~j
zW6F^X=0G8O2<HOF{Ru#8Q9lik1n3Jw7RtfxJaZDB8@>S`AwP?y)0Y<5&Ou~4MRaY<
z$CwbN4FodO(E94CKl9%mWlsZT_m*>kp3y6p-7??HCK*Du^RQMre)`&}s}0DDSDY_n
z;ayw7WBp)3e(>DY6h^PI)1l>-Va#(eRl2XgxXQj6>z>4J#vzqV_R73<I~`@E1tI}c
z@bcla<A>rC<8R$Kn%}bfiqY$qhl}0+9INMgAt?-(ZP2MKYgoybW~J_b|NX?_2eZ_s
z$hFbd!3FQ8OaGRr78OtcRQ3XE2PEj-l<qC>U=kFz2cn*ZJ!})!4{Q6x4GcC)5fT}<
zlN%wJCy4pYX!nzT973*n)8GT^b=+TEdvmLB>3PV)OU7ZYPi$mpAYTsp<TUmKk$H?5
zo=^ITSSdPwP64|Rxxy;7CKI!b)7ockcH6+|Eiblis7Yt9I=o>5CLcjfW;^N8+fH9&
z-_}_7@sH2$yZ6ks0?)h>lQZ5L83NvNPRXZ@=P*Wyy!GI&$M??l#Fv*Ag7u;y&CHJ^
zRyOBP#O|o2>I=NrAEP2Zt!zS0hIA<Y<wW<|TM2T#5LpMdH_X5b(Xh?Wx7Q2RY<N{I
zcTfv$6AD7zN?iIaqy((-dMYk5_!%0)Tx%&WP?}R2FHY%+h3<KXw}80BxGiG;NLi4l
zw95KJ5EQLuaJtM4dr0sx3NjB+FME1DhdlRso`q4RTpm%-3IEHw$sI>-kAK%X2{=m^
z2N3G9XhRaiyUKAWeU^rf8=2>f8pq-fz0<wQQLnwLSSS?IPcn4<vUee<`M`<)fgN}!
zHg@BO#eN|j(YvcB_OkuYPRXI%Bo!VFu}Xc{z};WZy*SB6ky&-<M?F_##W~6F9ZM$s
zwQZ~B8&}09xhF_%YS`biVrO7}en(YZLtHqyC$Mgdiv7;qxH|mw4S-AkyT+!28du3n
zy|sEjc=Q78DDpPs%e_6m%q8>u?%1B9YEFpdy0B9k!IRy;yN;+QC(cy~&=N2qJTN`2
z#AC~uk-MLIbd#1ov3u~q<H73*;_>|IzyFM{v2lHR%f|TVbpJqpd#smUo&*i@)D~-C
zV0y&*q8Yv>y!ozkbtw{yhP`V)otpf7V`LjHu(_mn^ytae%1VZS%z^rFe`ECvXMQ<m
z?lVpftXS(!Wmda9dap4TsGk6e20b}X$Ft0{%CikJ*gfuf-jz|8Bs{d9L=AwN7J-$k
zG(-pnE%B!Z;U_|pcOOEs9|Abozf^#Gl7mW4p>A)1;89onTq@GR*~R{}=vV>S=Pp+U
z-JL0vYct0R<(bnLQ?b-gEfGy-dwXJ`Z-nBd>db7ZIE?*MzSLihhBAfz>L~W$?sj=-
z%V2fz503?7jfc;Ur4#rkSM;tAMSH6ufA<q-W-{;37%Ppw72B*r)beY|<$-uq@)}#$
z5PB**5Na>y;&;Vwo9uLkvuYxAbBsRxhgU+ep1yQ!v|3w*J-xi$`<@j&y+mfTSZkD;
z{gp<w(EX2Et+S?9UKqJ_Yyi@UXX-;eeQUb;*3O~w;MQUCl}>Z$<4@K~fBZq;?1}zd
zIiJFAp1#8J&h_oAb3Usz2;svR77z-(>t`>TL#0|IPe=i&=fYeJ+|m<jWWO;mb}jir
zJDqD*2CI|Xow@N?_X_3#y6D;MdC>E!=PRCXdA<iLlizx}z)@<y%l_+X*I^2Dr$)4b
zN3DXU0_QJsvw;DNH0Ed*>IbfO&tlV{lR&eE)ZZu{Ez%sodC)p2l!k$$$O8$9!f1m5
zyQsl-)G*F2SHMP!T@+OTxhb4Ks1WBG_zTwntE5|>#n}{NvUs{fI;se`7yLw^0u^zz
z6VAOHs{tHySW!@KL6a&RK_yr)KSJrytryFK84+p=G&#%z8^`zey>I*AU;l===c)q-
zPiN~rf88_LS6i)Whw{Vf_WAPW{KEMi6WGq@)(<S(l~{vaL+)PoVC?Y0LeD&TDkP0<
z4o(kY+#BELlJ$u{uiZ4?oMONFsefN(5^VLe*<5F4`<+nY%=zG{9Sdt0PQ<_QTK4e$
zmF+{TFXm>qHz3-yLHV1;xxwi6UHnI8w{`DrGoL?sa(fbdZ}3m%hex{mg4oY5{!{Pr
zXv4oYPYe`>@`vZ&ivH~Q^_NcVyFJhxr~G49w6{@jZ<)NO=a%{}Z)$>{=?3zdy*uCk
zfx+ci|3a$z**`ne-t>ht|D268@#Y`*sv?m5`qLl1c56%(nU!k_wjG+r6CesDIum{~
z0NG~Sn=C6q8j%jU9uitdQ+}0~_eHg0XZwyDR`e9(+03msTOrmkr)OG~g#+W+T;J{Z
zZI53{+?m+3DfPvBXK%X;zW(^`>#!TQ8rdHNZ@BTPH3yP>YY^D5)nH_Z6{O&rtI1Ek
zQ0+?;ds>Igu-)HD=3`AdYaF}AuSw16Ezj)jN!gm3tp$UjTI%4fm)@SwVlT{hVi>m7
zyz1hL`Rupfv-SRgUFYw@e-jv9Lz>x`)fgD)S@+Xui@k_Hv3)bOdTz&uc=6oS*4YWZ
zo}V9Xtp_VWRAQv4?V(|=yN><^`9tumje15rv!1Ixr<SnL!9NY0xGd^21a;is(7n-I
zhB~N=kZ7d}UCZg}t|h}&`JuFzm(PWchmi5Vo{NqnA&&mV=Hsuud3gPXqi=la_~wfz
zHXQlO*N<)9eEdtVAKOUuj%|G3qdR6XvesU`8&I#jZDCNJUAy;*jpN;cz6cO~sG+`Y
z|FVrwJhW>L!z=C8yXwhUW!w5bdF9%@??Yz^N~E{bkH>%T&9}Q>`N>cJ7UR3W{q7Hb
z^tHF&{>Be~_;;At{XgIS@vATW>K{J!0<EuKx8tte=g#c9`^^3gJAU@Uw;mZOm2%~w
zTfX%2um1VPPw>j-b^GqxcjnaIyU_9f^{KxC+<ol59*`Zvo}<i9$XDTg`aN~eD7;J1
zF~?)s6rrWt@t92#cp8xm(M-w>?8}mb2HC3tQfzpiFk;)VwsvNe4n?3b%>3lh?r-1r
zbYJhj_ICHTkG~J&-v(Rh*xQ(x{c?B94Uay29rmH${=;LdmS?(K-+Tl6;B^m$w+FuW
z_~YN(^4y7QKBQuyTid-Sp2HvQ{`&qq@4O$NP(gpYzrr?6wg36f+kVuU#x^|mR(#`3
z_ha3U&vbrt+uHf?*!W{_z4h3Mr=LF2EZ>9$d`|<u;;{C3lKdd`8|WuToj&5AmeUa!
zz$yoUpym$z0SF?&ok7UBgm!?UpgKkHh<X7;jyPb4`VFX>Ap}BMIuVo?3Yf7`_W~(L
z>7e&!5x>|vwQlW}$B(a^!LifLdR;3OC-#=JSMFJ;N78;VTrStTKT6$O{NWd#`0Byk
zFTUr78#1|aVDI1k$evN&e_?I4(ny^=dA_Us@|s=3ym;mgcoWroZYOR!^=jy2N8f+&
z<ihG}{_!8SZe6{mxMuv?$kmb16`><XSJzUvBrCP#<n+|s`WIfj>v-$IUp)EN&DXyC
z-Pb<$v4P_^)IN`m?mKu>r~9j8qqo1e|LLbc_j%m+=MP<)U$JT<7I^N9?|ZM4Q~jUl
z0QI^j<{9)Xcy9810Nx%vyQw0a?{P&9XRtXdGDkK*84aA*<H`{5Mhpk;omb~zI(pLv
z?04J}z((vYsod6B)ce2>bk?E}W7if}XRc%cLG$jq4vsr}P>mLqVkT7xRZ1z~FHsd;
zjrt8BbYX2@px4gHzw$9XLNw3`<RyC@O$Fl&<Y-BbUt}TUfv%)Af6$zgr1Z0drvtL4
zeCoQQzn|Z^X<;Ev;&HJ94u6{}ll9@0f6rKHwX!J?izY7`5QG+$cR{WfYK_78e7?v!
zAW8>)><6oRZ{OE_ec=qy@<%vcyYavXe@}FnimYEhw<aF=!{9*0I}15D;~`!4tz9h@
z(v1P1R9c6>GJNC~g-@`njzCgk;r4^KhfA;h;f;nkJ_&}sa!C^#5mRf-rUKq<aDy7x
z%x5LY52U4g`UZVRrCMz;zh=DvDGk_=6Z?LN{vOru8Ss3<^Rnj+&$qEH*h%aH_A$gG
zibjI7&O}c4NN7ZGw)omzF>mS9nUB#Ar~AL-jkVO!P6NZ`z?q5We;5sDVQ!-Tki`Ot
z8>oR`CPyP`=>#yupflai8oIRIF`Pdw=W_JhJ;9y!iB_fwnY>{a*ei<2@{GJmvY_jO
zY9nC<Ruhmi(XERsAE5*AY+=yv0y@F1(1zGXod8kC*%<wH_o6f4JdmKwcGGb%c5BCg
zP~wP9=u}i8cz*Y50_;1^KFH<;yKJZrf(PejFnJ_vj8g%qsaq0U4K4#Hk0sO!y%My#
z2ZNA1%`CNn`)jE~J9mT%q7~Q@Brz@U&M?8Xg8rTk*5J|ZZ=bImx#hzzz5l6w5Zg$Z
zUO|ZFtA>AKq)uk->iXWy%`so3z}IT0?!IkVU^Qf$RGyCauHAEmo_h><B98SO+`cu*
zYiZxrCsHi%-*O5Mq>ywJBTP{s4NZka9HJr60_f-sRfnuhq8HJF8@LeSF~Z_GNKXd(
zq2QLeXjYd*RXrO8(jgzitj}>V34Gs-^W>n6IO!@eD}$XH>jZM4Pu?8AF`?fV#qWP+
z?{?rJrnos8qVi2hTfhNnlm_{`kb&0A0W+Bl`8qhrkz_(>ssy5+PopUzJ9)j2;~7ka
zg!ZhDWMxPg3~9)Cv=dTR;9de0RwfpqXwrtvU^?WGkhy7*6fb?>e+Xp1nr!-#8yJQr
zDP}?(GrAvaDw03Uk<m~!#^I+cnbexBe||C;@MkiWOn6N;S;7P^dHtDAtkM@x-}bqS
ze;pIjR3XTaCw*ibOd$BrgY1W|G8_AM?r5+;FfB=yjr)?tp<dum6U}f{(g<n&n*F&~
za+qK3{w6SS&DO&ZE*jJHK+lPzC*zW!Pn51W$fC?FkTDXHq7-2k)<~dbiZI!Rk!7aJ
z>2Ti)+t4c_lHhQi$WW?}2vfL?16u<IEN|oKTEORvGT70uQeh`W-BhY1Yh;8HZz!#Z
zmWWH+=3@>0TsFp>oBd>75iw?nmjf6sfRP&1uzG-^e7F)76w**t$e}`rK|REzSg*(-
zaxO!bSSl%EMo<D)RILcwMvVhrFi5LGQ+`7iErx|0b&z0H>SvCpc}3yGaxmxvh{yym
zWwpWrhgF8p8kO!Bq9)|5n;0<S@hp(d>Is3<xY$5PW?61z19lcP$8<RpDF&1X%fehP
zf!xQ?*HX(oqnM6`P=-is8Mc632@&PjJ8_^6t}$>cw4tGfpv?sW7q1wU*4*JgasUC1
z*`({r1LGSBdB{Suc<N>3LVfq$n~Rt3O`J~z37{neO{2SW(YykHgN{HLD111_5mYP!
zA8>dgWavR~)CMd=zYwUkz^Z{HQn<o$5D%3BY(X8QBm^6Zd$}W@ptwmV3KRYy;6V@O
zf^7yK#06m*O0vLQg75>`O;GS9GPt-3MRa2@09#<WZYPo51aUJiQ7)pHwb>ZKfKJJQ
zDR_}CGNC(VTaJPjox#9UcWA~D1Hpq3y#pFd%IIA1Z$iHiU_lN_q>lyL4!X@E4Fp`{
z7Kv(!itV)NYY78vLJPm?-O|(Ct$7!Q2Vy<htt)HWr@c`~vjYk{jGuV#1-m*ty1c!d
z;#Un!f9vO>$rKW@7!&MvxD#l4@x}>J2ga|0KSu~X12eP3*B&1p@5f@LIZR6Q0ogB5
z84hie{5^xFT8IJ6S!OVbK^6yrghYPew=ZB2whek28W;&R18BP70C2Y1QdA%zU0?<?
zN!li6M4pMT5HwFhIHLmj<ajRu8LSy5!v_S5=43nrfX3(wjzJ#50KtJy1@w9>1|IZ>
z{=z0TZkRQF1O{wwB;>sfZ#S|8U~2FR#g^LAbnVfC0=etV&8jJ2;tMjD7OP^EB0`or
z;^kh3Q*5O+{RE`t#<XNu73O3NqvQx1N<$^Dz!?OK9Ptw-%a1>-;};^))8RrbwAyMB
z3IO`(^vuMe=Ueym6o}0@Pc5sIpE=|gZNp2GJ;l`YeVJYcgGfwBz&AblNCy~7G@noV
zE^F{BhZ!u8f6t(rn>CAp)=NYZ!c6Lq17PQTm9=RuqDHnZ-yHU-S`8}?Ua!T}M4*}&
z!|}Zx0!V^iiWF;Rd@xmxnjzCn#IrKsg+K;L9J#%CfdSqpMQl~qykQLY(%}dp0Rc6y
z0*OUb_Cd6mFTw#^fCjl1!84fCd<1CnNKh$(a|<L+jAKknNdO*U0^=jO02$W^Mhu~6
zft*Em++bo5rJ-QK1WZzFga=0&NSoP6mPmH6Q(eIE_}a-Lki40xc}$Y}i6lpP2eTq@
zVn(!SAUa+fXE<FRqxqCp0gg+ZQerHWq%~+tgv7gCh3!JP@(QLlIZmrqYZ&MdZ*5Bc
zxrsSVjjg-o0Ek|&COJ#qMyEWlI4cqdT#&1UgFrAm9I@H~D3EC?$gdD~x(b@5uZ|lp
z9LPB0w1RL4;T$T(a8@;oK7X)q0dX5eUxVgWb?^ryc;^;?2d;dMN><@l$3YOtrGdtw
zBhDZkLJ}NUR?s&PZ<apb7kL}QV{Bg!kTvqHAg|^ol>jN20+2W|;SgUmS`;Og%F<y;
zQnH|ZjX|p4j4F$mS0fBDCC8z^$dGty;t?V3>jd#2$DA1655k1G%m+S7UY_*QF{7U0
zM#HksiaL*BYB<B2fw=82C#5*)t5l<Y?7eC@A@rWQdT6>gCJYpVffW1uty}L5^_#h|
z>FYXL3af7ylA)uac&bwAFA7;<Q!te;R5U-YuFlml^*|9cj~U;;L4cDqbj8`+Uu<Yb
zAR)x`&i<f@bL_C*ePrc5*>PLyZjED-t!<jvz?|tlXNMtJ7z=t!`yjt(`<??2Z2CkZ
z=O?Ve$TlrC_Y7YZMGmr=Qh^x9Dlu^qa3OpGsr;Pwe~jD)90p%N?GH;TG{HFHDr)L?
zghA8~T&)}e)j!!(<iL8FVPJ7}y0n~i{8dpCE=^&VzoHI+<`ZX*TY_E$ywIOem@phf
zyuEO~g=RfC16kKvDgyBgtlFFdDC)!M59BtEHAj6#F9kfEz+0=YWVqpw0?8qD4pTyD
zPKSpV{pF~ncqw0L505eZEjW{F`b9aHO(r14w^5)&VK%QfNlGXd#UL{+N^&Lu7Dg<B
z)3jz;z}kd)RS@A)VE$$RmSz9yoA{I+$q509!)9g<DH8F3SP{Fw6f(PQmTtWD`MJkq
zSs!8cCDy6Qb<aWaAMjMf!JOiYK<+g)EGD8PqmKg5W|SGf@l0!3Z;Tzt2Yo5_Z?2u#
zxMI1U9bI;I4^iDL^qZUQY@}4~6o53RPou0{wygR&HJb49#UI_S#Dn2vIpzN!qTeSD
z>^_<O_}WG|Akxb>jQA{^We0U^+m=)5Q83#)1d;uGwC_Dr(}%-8)CW9Am~WAH04tdj
z_w5Q5OY}&{eEBEsy~sJev=bT}nkohVo$Xx?`p}k6CK+&(Lx)fyNGpMw3<(-e*bblx
z{H~$7cxm~J`T&q-JLfseDLB>XCGJ&=Jq!JCp@I39s{6zBJ|o=jEiQ}<7v=_qm#)h2
zA|GzVRGgzLW(ZPpJvFbUtYSS^4UZddVjn8W&<OheAn-AYH8ElitlwEWR$FDH;@vCB
zC{_%I(_`&U_h~H>2Le#&K@X>8e<c0ih7O*o?fe~H^Cdc^;`Kk6i_b#ZIklY6u|7@M
zz-RfwV6m8t1rG!>ysz9+>4(nWbItyb^nRJe5&>TjSW1ahFr+}xp_wf6aw1xnd}5Dp
zEC}<3NU&l&Tb?TEu&fBMksQ@Xa-5vqejrKnjR9Tt@?34W*&|6Z6~(2P9G6uEk}Ff3
znl^YL%4&f$1eL^^KCu%MD6+>W$Uc!}>5)WVGb6j>{ZHH4X%1)v1lc`HgVx;%gMX2>
zbFnKd%?5zSj*JHlinLVF5~yvRug+4^X=#)f2pxe&a%PSsg}RZG`NM$-_bM>y#oZB%
ztb$GvaFyGUpkOemyJ!!eR2%Nfe5;zPTSW-Jd<vS>M}+be45C=PB8Xh(s+WYpxx&cs
zy23~;Wc1a5HdST6-1+GKYwkJ!5MA5KXP{ML$zpM+2<@~1a?sehd>Qh!$+PjfA6#E7
zbrQZB-u=$tp3}Kc?#M;_GBkQffn-%9TKDPMJHp{27A3n^##2I`sU0irTt8q&p!0w=
zH30c(p=EKognek?!g!eQm$PwbPGH65H9V7!)c}0zQ5ABDCCxtI#tj8ikl{`U`T_tk
z&A!A49rDQqqX(cT20=aIv?MC&fW}5)rb??EB{;YP4IYz#tVRwjdoRa(RehiVY}UyG
z+d*#OR0(op=OSzX!u9o%$3wsx<<IHglRpElha=$U;Ee61_J+2AR!3tPbQI9OKxhwG
z3VT2@t^mEUgTHOme(%z{K%2o&w@Coc!)PjYT^yWZ9VaXRYIgyUB0v;y3kMk+9fMy>
zJq!LiUi+?^0y+$c^(ZI#V(}Wf2MGTJIMpuQ(CtkC{O+g+3Bv7NsDHKT-zPHZy|;!Z
zW+J7&a&9%YP{a+1XEp{SBjHKKjJEI0%LA;a1h{&s#zgGq==T6cO|PjYr=mXy83(hE
zmT@3#rkJt0?I$t+0l~m!GF|AK4h+X?rrEQ?#^itKH8Rp6U$F4yP?FnR)>r7Ole!{<
zH>c?5+xa9<Xzb{+NSfwNkPskU66phy5rYqE^?Qf}W(PsW077utXl#h4!YbtPjBNCp
zQI4ttRUft*N=WWnuloXFdmcDQRWZZrich6GvUMl6_qzDi*`$Q4_X)wY6kO>4Vq>42
zOPE0T`D$c*RSksAjoJCk3bED+L{cO_$W`Q@fcGFb<sVpE9OEJHMvTRIRt6gC!f^4m
zlmBxhYFZ`y^IQ1eg7>+aT;2VPg@VKm;Wz7;9q;?mtB>|tu~@o^?{1VSEVJv<$6_%~
z*!kY67rBHJ`*jEXBK2br>oGjXK_`2+=UMQ{G%@ISpqoWl5B_t`-;OhcU7ah410WYJ
z^#Z2@I<7G|;UEYa_|9DMj-$&W$iIUFHncZ%PxwUG;`WZq?#0Nr8E&ULHGnfLEQ3l$
z%SERaZZS<aw=kM;pgO46qxw1<%BG7>dS`-iDhtQZ{mdSZTiCm*bGaM3PzT)@GFBMq
zuISXINzI0RjI+<F_d6jk)LnEDD66N23WEhBJ9HtkA=r+a*mp!&KhZ;xP4n}C#s^<d
zj8FNwnaTQ&Z(k2-uVWGs3Go3vLrs>WnXTTmmSKEmy#zgN&)!p8g)_25h2y=&?7YJ2
zjX(T(n!-crOkQOaC9aprQChBS=;Jrx#}B`pSZk8AN!7cvu_Io9011Y;Frpg6ieC|f
zNsRcbjpIj7ci47~h~%o9`_C3o#!~QDC~x?}wQ@v)PU`Re#HPWOSYEs1bUs%v?L6(H
z_a3Bc;okd4<E;fcbg}x?a361{bg>i|DVA0~2`rZJNF*t0lB)O`97Kqd9rA-1*MCen
zH`o1)kyy6>x$uZx9~tcaN>741CLFmoa>E->uR5?}L=Nwgy<Tc&Zsa4tM9oRFGnO{T
z;liEy5z)_qtIM)-IH!g<3=8@-uK3I|U%JkF#1vtvO8e;*E7rvW4Cx!YxY~#n3(ZPu
zhNPRjneI;oNy?-`*zhj=KmQImb`DuP?S!J=z5L<MDl<!BeM&pf+p|xqNmp9f6F2UD
z`77(h0je<b@bMomr(yLj2(g`CO-|EZjxLwSIT?FVr<Rwk%18e4uV$tfTF0|&4EG7)
zef!gEU;PDeh8~IC*!`q{ZK&@tvsGb?39s+%h4BbPNCk+zj8=~Hm8(_3Of1un6)k=a
z=4}SnX)jQ3Qa^&2g|nW!Ac9W8l342<n>@m9BpJV}GrL{T9axJ41r|*(xq=DOk;WNk
zo?RM6&g5@j9#U=(ccpe151<|fPkpqxvva2n9{SD=9V<U7WKrehD3f5UfS0Rtfh*dh
z(qWvze>4i5;fqF;%UQUXtOQPn0qKOcc`=xjoZ*6okrONTUx%DC@{!WakulIL;0(P*
zpE)P!&p872S11@zXUP%-7gBHHsmcC<m95&Y_Ek-Sn)uZ0KnoOwpver9s!3@LT;!Ko
zR&P&9X4M?7#oALBV0}$yx94)h0V`U{W!U64+{jLK%1I%n1aO6eP%jdu^zQRRLUMX%
zk!-(Dlh!8moVQysIGdGw3K&gZAov8H@%n+}MsKG=M3ASxhUw8rG-wMz-vwN((@aQ=
z8nOI(1vm8&vC@pkQ?clM++HHXH<*vDqQ567UY4V375^9qQ11ms21qGF2gPKuvi{mQ
zZ^jFPStxU>io?@;%o3+x`q$*)O*;qryuIF`mEfhS$M+E79l>(BTH-a`y8@#UQxg*#
z!hwW_Q&Xe8tMCK;b8E0nVPYZhD3)iE5w@n%`DB0Z;qza97SsQjKI#3|I!w6gQ=2#6
zDhWNc3RQUJOE`o_4eJZ>i9{b~s}ufx{^1BD8YJHztE_nFD<}B%e*Xuyj9;j4dOD+-
zoUyOV3dyh*NKQW86*!x=6n_655<Z!y*+`JV32Vh*MO7>baxCxR?8MBu5&EnG456Tg
zu2DyXaB=NiE`-O1!19nbFd)4T7FX=De_OD(KlR0t^vZ*G*Y|FHu>}mHBB<aYW+cA$
zxSo@NnBqBOF0BOCKzh@*S5~_}qqv)z>(xy?3!5}jL2F_PtW>`wKS%wCr{LM)Ip{g*
zx!#eTQ2&Q64569OaZ%@8{2zBZG>ia8HPJy55u%%_;%Lok*`Ps0X>Bq|h=j>H;}B+;
zrGJhH1Hs4{RBRS57y#m#ECVBF@f#>X2Qcz;^+)z!n=+bXsp3QUA$*P1#&$@BiJtuS
z#w)|S?Dv7Nef`M5O7<JMebp6I_o;=!p_lTLsg>30nq`gm3?xQCuFDQLqt}HkCU)z>
zUD2*TS$|}3A}gId_LFGheILZ|qiepK^xeO0cO1Xx^qJEgLeutw)?l|NS#!~3|Mbgy
zXU`36tfs9Wer4lfFLup^Jv+mz_OpNgN@7QK&5e)TI5>x4YlmZa0}J1*MCa7-R5(4+
zp|QCmTiaD>nW-tm$+S8FqQO9;tc}vkocH|p_sP$Z{{Zi~=^64Y_uPQqa~#md!6GLn
zmT^$RMJ1r~fdlBE^B+w9DF3hBv6ub==D2%ch{JctwTi%K1hbun11WRqpCgDOntR)k
zW}`Tu2LMfs{9N~gfAU`cAMd^Ue|E>8gBSJ9qibG6FAiUR^4Kej?=t!S``Q!N$0L`U
z3EPXm^j}}=+5eY!k6l48TLJIv$iRB%4W1lc>%7rd{y*ON!k(R8`CaXU`ZW)8$SGi|
zdlUF7Bj8&xh2_9%F^BEMUdMiq-aLxQKyd3U!yqGtBe1)vYr%`c{S6}kz}uZp-r42Q
z4xyb9mnk-RIV&}Kt+2U<(6ke;W>lS^3TH1^0vvG*HTj|#=8hT*xZd0yORD}Q{C{T+
zVxnfvEKW->IF~jwlAIQYTcAM-VjJp3P-|#^*x<VpsN#Nwo$f*CG{a!JSQP!7=>_VB
zoI{~AL46kEz-@3JMKxPotRlAo_r|c(rAtRI0=-T50Z`Zqlme3I(jI5pbmlrJ9FD?2
zr^8=<fG{Mfa;mjd3H0pf6t_t(pT~en1=)<;jY1E%c+8!2?ZqR_MdCcSo^Wh&zk411
zy&zu$MMC13FY=@ANzI$$fhfsOauK2N0Yyv+{Dh>>XtW&9W6uZZUWgV3odeU6d0n#`
z#Ko<81+rS`kfJ$c?cO#9377JMCU$!Z8|-|^FAh$#k%K3A1FLLJ&ok8>@%)M0+SYzm
zQzo*nD8Bkmwo&4Jn^zaYP1)b~^4v3b<fW!0ZM@YxvJ$4$=;ksddP8|JlG^$Gp1q8>
zviypAHTU2LXr`|E3><r^DdYaDPds0ru9WH%#0!au>g3d2ih(sGRV7)taXDt6q+y<r
z`{daZFUWk*mQRy8i0<GZIYMpdR{h8S`L!TlIdsy8-^wSKLCD_9v3PL(4w2K$)rV+)
z)u<i%<EKx8*qiJxl^L(G!uVv6{M*|p&>}QHzpe9~tJmIGEDUxw4ElEYB%oWz{4H-p
z&-NYOb5-aWj4VtPOv#tPPY+$Owp5x_I1?@;fY-aUF@6*zVL`@1Bt5wE^p#g``RI!7
z{!O3AuCoHw@7&V7hET&kU+X(_4`mO4hq+kp`Gl{*s^!&N<f+|Hq2w3$W>z<QmXmMA
z)4qTi+UB#rTh5fNbP%V?n<JT~2BcGXfxpfdXc90%j}bT-?|v@CKsGXnY2y;T*v=LA
z-8SII@fD!MVC*uEWlN-7ssS6OSq(J^J*|XVp;n-u5wLi8D7hEBSExJ)By*D{AF(p4
z|7@zi&Tujzl}jR)0nV;?$D6PR58G{8i1^~k18oS$&XE>(Bz^#=vPzhqyz%yVilI`u
z;%E!+mw>srx_`3Z)tRy0kfH*Wf4tq~C}4fUSXzTc5UDY=Vz&-{E3n}OUT^nj0y8A%
z*Dh*me_ewhKqll*)PSV7K`hVX0n3UoA#h@s`RQc#;lJ71BYQ!|l2mJ65RvMf4rb?>
z<xdtU_V)XvjAaA46IL~WdzqGu1Vi%iG+|YNU0An6aUZRPhT5IN6>S;vfhIyq_^u7b
zy(?uA<UC^Q?b%Ji1CZQE?OS$OixI3nyO0!Re|rPL`$rc7Wz&oyf3`7Cig}Irv1bzE
zO@4?q97)0%q%OKG;u1iBGs2yL33%b)0UD-D-<Q4uC9ks+c@(0}Ed`+wDgvb#cfW!C
z_FdoK_0<BA<MKHc)#HE?+OeqCb-%h;wY1y06{?ftZVNgY=j6+1;vo2vGR9dJz~xAi
zuOTc)+Ikcj?QC#2bii@Y`_u0(Vl5q6#4l7?cwXkU+|+HciJMPu-rlz*-3#3JUSBm6
zu<gj^*(oa!?oWq9WG2&&2HQf<=0biT60UtP7R!Yq#f!sRBb{NrI&|S%<cj`%S|u2{
zf~?n<)g!^aY>q4z2OFVK{~R3-=Y|4?7&w1ICGc=3*=r`Jy~KTC?Jrp-^1HbGV}VKk
zyTKX1W%<lkV#a|R$V`5B6_RZ4D5Qe{-e;J$F6x6<B?q=&7wV&KI(QMpE!h{%!3n0`
z*gd`sv<GI~%lp2P;`rZbto82+p8Khl*wzmnT429qL=P@omfyB>wv$UG@5lZ&7b)#d
zE<15`?dZfz?a|`8YPB~O&iM}+N48Cv?NGRyNaCP2>j@fa-@atB))Ow=#2SXb*}QI>
z-CX8Peuu0l*BGH-dpMWxO-EYAc&t<!PK28688Vfs2LrvV`tV)&?sRH+>f{^wNaVU4
zt9(_DznN$GU+J9vt2od8yAe76D47yY?%B}KO8pZf4>A6Glbwb9+E#0%mhB|0$-VJI
zk$!63B$2&i-N1o%{6YJ^;h`}vH?(Qb3ICd96MkRP;Pqc{T<ljiYy48+a&Jb}`D!h}
z3EAr+zNu2Fymm63N#B6{{5-3ePm_lsHtSzJzw%tfNEj`IJMn=H!Rf>u0=hZsR^aG_
zdc33Vfhp9H-<+WVb0v%m=w(jdxqK2bFt#BK`*L&$j3j5?MVaN{a@6CYSQ)ZQqi&Ci
zMz%_raZ&Gu>)c+8WOP&}s+C(O<izP-3%gKI30&%4>DIXIIEF0>I3W2$0TgJq6P*;C
z)qx;<2Lh0|g)W7>hR!X~Etd8%pFVTNPe1<3r47~5?<~A{#hLWR1#LE3$<-^BHfJRg
z)li}*YTK1^CzI)vE4Cf&Nd)SNM07mbo0Y@a%&fLK8|DF}Tk%LJ8tpS?W1nr0<|6S@
zg|{ZD?yt=qW8pc5DU6QohzCkFE52iFu);7?sj(eq_t#3^6j-h@7s-vbKO39X`=dZ3
z3%SsII5_xmmC*=6=mvfzw&8+?|2;Q~y>uXl6H!GEcfSxx#A4m;rAWA3ibRWDE)j{v
z$itWJ7`pP2kt!Pq58rk^i(gw@ubq^uYadFdGqd4PrjrQNQYlG-#C1TF(zFwuOelOj
zov!U3ACgb1*A{!29jTFOIDbt$b!NV{>I@a?iImInmRVXq*ApJwn~K*#)wFjkH^wj{
zg|WTG5nn5s+B+7j_eUT;Umlz<MQbtg`W5Y|vneBZz6hieeLZ{z)JDHn*EO+)n@D5J
zy$Q(s_sAyuzhli<BtdORBocv0p%{)<t6BK&$kU#K%+=u6xC6Ma9`(H6^I6aDvEASU
z^a1R{NHep9%`Wu4`_oz4xFY0|SZiBoDFQth;6338qKijdKS$JmP^X4I=GwlIzur5W
zv!JmSWmoq?bbb%$=NHkL$)foJ)Q~9O1AM|2ZthnH*4=U~G-Qxt4gz@h)49cx2@ooP
zKp(0B)q#_tlcIY$U(mHqPi`a5B~&%EqFt&Y3f)2-+x>jk?xkD7b1$9i{QXmv&(b?s
zd?kyI1dGWYhZ}xTFoqjA(;upPyX8QG`y3s3vCac^&|3uVKtK%$HF3Nb8_d;b&Tau_
zfj!=+RY=}Hd(tXL`WKFaXH7kPmzWsj{VjhwJwlZ7YJ#-+N;{j4)NwkPl{2G5YlOa?
zrQ}BN1351c;3f!ZqwU-psbBg=cV7UD2qDSG`v-c*Ur&}AK%$u?!Tt+NFd;hzN<$nQ
zI<F?5rY%~wtYAcGT~f(_7Q{UR6p(je1ZCnOyCw$lo)j1a3)^Kz#LL4t$(IN`lHh>p
zr%@~vb#P1pMpDXWNsW9Qha5yuUOFoUI>Z2FHaCAkG1u=T6B)YQnTpUNJq2WNgj%Nv
z@NR_s6*gySaXlkc@jyV+>A~;-B<vP_mBa`oFaoP;d%xMby4VM#prAm`<mPjc!ccT%
z;G`0_%1^Y$FMb@<x2suj-4k<ST7yCbNq{Vbkb4mPl?17ZhY7_X!0Ux-7O_y8^}oC_
z0Im!r!C-V_EHQ89jl#%5PBjaGd#UK8ksh^LdID3y7K4dYP&a}@G#J!tCQxWgy(I5_
zC2khvFfbr>WO!=1RNf@l<Zt0)+h*}ru+H0Rs1Ql2MgXgUlcttlXZn>kBc<7JxJ9s~
zFxzbOr<oOaLoot=q5E(GtQI0i`GcId7SJp#ZsS*enSv*<X#$vKbSjwdCs<hoPA13~
zG*Ai}Mp&bO>n*Bq+48D1ID&Gc3PviIb|+GuE8p}|w*fO6P;h{upGpxmI*1d3Xi#2=
z<r@Mb2}0`QypY@%PbfSuk~Aq97L|qcvj@Lj*;Z=eG#iD4IY!YJ)q+~Wu7ejB8zK5|
zoF#2JtR|8XB4A5+1X2`0j!G}ZL%1u&CwW$C4U~Yej+A&Y#Y7m66tT^5UI`;#Mb94Q
zr^Nq)EENv}N<9NO^{VIVkg@3(p5Fjsfqw+dvkVM72Ss2Mx#Jjs$Qj;{b=np6-u<~W
zw$a@8?)~WdlG*t3Fn32b#1_NUj4ni$zJ^_Mig%5LOZS3V&lUL`N=?SmKv;GaOM;*O
zJ2z?puA$QaJkrSogj2VvBv_UK-5j+v0vo7D#;untN;;(uV~*D|T#Eo07V_ZB3S4FA
z+{H(3LSrD?5hU)u`9H*!=Q**k_5wlYl9jEAX=8Na<$F}}3Kk;+Nd~B>WFuT1)ibPW
zb(+A`YUJj^ZSXXcQ|T684T3dK3=9lW_BfFU#!Ld3<oxyZ(^{IAqyX-ZP?|qlV7xe{
z`#5Uh<7AE`Mtcq%e)9g+jKu4ZtDv?iI}slE+N-RZ0bF5BRy`G#!*e|^JRQrakOz=9
z^G}X%->Y>$Es8h9sG&<wl}fArf?U6DFZN7C+~o~cd(7s(XroVpka;fpfN#gMb*ul<
zJzfZ3j^cQhX`FtJdW@Nmut_t!QW%<Icu6HMu?IG@!q+8YUsB2p17kT>s`z7L!J5#{
z>*Oq-VVeUh{br$%uUjb-7*2o}3sMK#<0pIkT7PL_tjXIF%P^28m;!~iFFehSmwj4l
zc+yPalw^~ULd_7K4_3eh5ihO;Rw>zpxPOL{CL%T?x70yO#_1D={zPt>XlSuuC`D7N
z-rqa;in*qDz!nmPUaw`@yJKG3Bq<DXtlEB%FvIuH+pDzbT;eMbi);?szWT2BS)s}9
zzxpRd$qy-uGX+kH65eM{fh*iukSvkB**!%cq5daiLOAES-}4mYL-1f(6!MR@r5>I|
zzf7Z!tOyM4#gfR6)ZKJ62g7XV99g=;i?ytd%Z}%`Ng!eX3whk5&FSAuvsecOMLJzo
zZz6|$<YuurwYeuEn~HPX*$YY*e95ec?uZi@edL>vc{&^_ro0*`_Inuv{1*NGz`x)$
z-n;z^kkWyS4vbwHs+07;V60b;iC)H=iUaLyu`iPm*l*50tnSX2$^LK~kK*7rih1CJ
zErvRLjv$$+Xt#zTS9Us6j=k+E&Vc=}lT5xxW((clRpt)Q6uhzyzD0afQF~ZP7P^m~
zwu6;;EZir8qa=erGjt6_v$B6qX|j~re;zAR(FR>LSFYS2#?9az{tDscHg1g()E_?r
zS(oYyf5tInpr?16RReN|O*k$3Bj-c#xoeZ(cx3k;6>sG57QM!(=mi|onPdz|!~~Y2
zCQI@nXi?1aAX$sXx?i9UJ(5gzddKpVu0v{f&(TsWzWlwZWz-*E!s_^5AcykhgEDuh
z`=v|gx_^YeAVOcbz`PE8JWqH&?D>@EbJ(N6Q27b$73{wO@BYuR|Ae05v@$dYa%E_t
zbpY6o0f-jmGA9-ZIt?_~JD+v<T?IWg@@aEc-L4b@9RaNnKtKY89qLOAT2s3{<iCC*
zkW6+E0X*8E|19+$=v>ZM2!?}x17w(vWxd%3EOU}hKtdZ>hkzp`*1Fu4-EO<|>4;};
zbscdF3P;*b7l0ib;ZmQ5IxhBcxRJZL^)Q#%fm|mZw~mWF9cfI#wabyX+=l~yP$XzV
z0j?yw^i0s(;cE?z6SUr6l0A_<@3JiFaPh-Iw^W4griI=WkpDQ5{7vL7?@$84-X=2Y
zLrXA7`3lMU+&aT+08$@!>OhyG6LmPz9nJ8r($->G?o&A@LjyBlelP4`tG!;BTumI;
z1xB>MV{~QJ-fk=7O8KR7;ll;Z{{~*-88Ob=AiY7ZFrSz)XS8rXKRXa0qc~PlfOCoq
zvohoL<xlSSjtS*V{E1o`dzNg0bEXl(ebP;Eu(qQ(#cM3&mW9|6Jaq9Qqz8mZ1wz#Z
ziMc^i^gXB*IbW4HNy;#jNMg_uGX=%pJ7m$`#IT+dO(78s1+EHMv(i1fpQ=Mnk<FlS
z+!>$*RuG#Ib<s@5<AE9pJe9Qc!B+{t*UN2Yq)06>V@-78kY>D9Du&lmA}|8?g*sv>
ztxF~WY2$gI?7~f-N`aP+z|ut6!cDSzUhgRf<UXad{ZJ0#WYV1C*MU0B5WOVFidKG2
ze3~*9ua?fu*S6EUmwjIkkRg@qZ3QJS&O$y7Kg_{F@Qbu7gmmfUnqV>7+=^4L1$o~S
zD`yI#rG|lQur7X)WC<Cfek_r`crV6+geCjcP&gL{cXMw#gHMu5B#kk+7ZQh4ARa!;
z4P|>7SaH|r?nTHOz*fPJmytD$n*|y9JN#%eZLZeA9`DoTL`1`jv2p^(I3g3lLcqUC
zVb2e3I}<JUVvG{>hIb?=&^mg7H4=C*_=JEJAUww34!qAB4IS%Olc`CnLE?WTFq~FU
z#19|Rv?4R9$EXlTT>QRQ%P(xqZXSrPSf%*=A(fFhjh9F|6;`YOg;A1#b1?6BxG~^f
zR#Uu8tDMSy7%yP#iqG-p@RzMLOA)q)`zT;&Xn=qqD;7K~#PgK1nYQqTo=AI7Xv?%}
zb3D|bFr1aW%;;5IC+9Oan4K*^wuw;`2i=wyIsPZs78~A>I^_K<u#pD#2iPzxDb<}g
z__E``PzGnpm=Cx+@oEhFNpgx3gIndDCr+wtzQzum?v{A)ht(PUS4stfndH*P4aq*M
zuwD)VI=I{)Zv<j%um1dIY&-vH+Ivb=g)c5&u`gsQioI^54tNWBh`P6suT%dFzC-6c
z7hwJTgy(}`cl|Ul(0|qQH=cil9490AiY3%Vz5sxt01O=+(8~c-A_)SJvml0qAC?Qp
z2vVKV3}-mw`yKdz{2|D73^vEWsP=#j_T5<I;u(M`B+g|3avN<&i<5=9-*SqCxtW2f
zAI-<$5ew|@S%kBY|B!JMJZL=(`E1QBid})LtR@0Y#8YoWB|zSUx}r1SI9v_~7Uy=9
z3<T+>-l-|n@iGEBPYQ<+Cc-J8Rz;;d<~Afsv^z;>N2`JXf-`7Aj^?8!*oKt9Fk69}
z9(qvcU7^p#Da*E6OBw~R);UL!;118{O3di-;jIH4!>fnahH8MmIJ==rZsvCPH6w%C
z;^_leyABsZE#XXOasiht$G<O&u-MTXbnK3eE=1-wP}Tu%Bf$rr4BZ{^S^~XXkL{=z
zoO~{5;ea-zOm?b&c?yB|2u%h}<XE`SLpT+JhCovyd`CvHq+@op$kz*okcsMVD^Y(h
z)`5hnd~JVP;v|0u>-8(qxAkaR6dSOfmhhZT`@BKZVgosXn2J<vGw8)3xdg2#0S3oN
zT>l(%4Y8eOeLlUvjZ2%ZA{ZVxaWk+Cmc0}n1o=0qtp2pB9n=~Eu)+#FKmIuQHeeB6
zRFw#$z?lM8y@vI%_$F_f%T)9UVw9yKa+Z=-U}a5&`m5=PFBp&O7_XWlb8L(ct29`l
zF#Hh+At9t8^+{l}0Qwj;#`K<LBmyH17UMBJ9>+pHA5La8L)6OH3RTE^!;oxj<;qQc
zU{8vTcQmhJ^C}jQ{n~N~qc{zM?o8ewFsam%*j^EWdF=?5(3k+jfNzBmfP|AnV!kBm
z5a4s@5X&l%$ZCcWhX@Vum}5jpN8zVIL1D4rumu-Wmcex@EQ_(0DnsT<jM|_{pkatB
z@eUZ*0s*3b<LpYBuqKYCmv8<QbLl<VHHX%DW6d?^x<9A}fayk#+(b7ia-PDD(m}-s
z`9dh{tKF|(2cgHJtwyo#gXAibYS1^!u-L_vz6XdHJ-R@Gq7!0~>R)Tl*qtE~+i>L#
z)$uF2<&Rx`ZTBP0NGCcsmk5saCxog1RQM5LU=)G{NV*?9glIMTltAr};mHOW$USLf
z`GGu^>c>fHxmAY1L0aW`l}{N)WI0J1X=N2f^_3|CR^Jmb+{;F<8l-tlnhFc@ALb#8
zo+@4CqhTcv=1?xmm4j07)@^3Uum=gH0<ncK-*PekE-*x<r=zS+1UcFwSmiS+_8IW?
zWeAI=qqxr61RSSw<SsiQghY~@u&J6x7HA0m3VE+TaEgMm;SR|VB?`20fL8^Qr$aKs
z3b7H(^m;|n41@>`{vO~ULA40&We$*%;<r>H)JMw@QsrIvGsa8!AQcagZHhW+U@B1e
zLL15e@;u}X^)s4Gr_(fKE1*deGKunrOz}1i{2L;UL4+sx%KBLFEv0meX}!sdQh?_}
zeLf8&1#w7bAw5cxx=IY1p#W4wQNYrc;Nk*wt*y1B630|bH)63GBk%+)%+R{*B`QMw
z%=1x90yfOQ#gTrZhj9ohGYH5WFwg+h7S~H*v~XIYM0d~+0SVwqwuO)geE}F~I$v6i
z4($RONZkNU@7f$h1Bk0aoFSl@!;gz_*;%&L7qy)=kh@(e8N8Lz)sClG&A~RP7r3ay
ztrlSvgz~nDc-5Bb1V@r+2?>R|W`WCMbJEE!)m&0^A~_ha9Fej+8-zAO;m&k|b`Y%|
z9Nh(#xA^E;1pG@FkGS*U7{t#YxQ4qs2cQ~g7Ih%pDHSxqi|+;=^0Fg^J1as|W(RB_
z2(r<qg_OL`N5ksaFtfo8z(sFyxwBZ8#dn=F0LjtZ<C5VyWx$gx7UC8KMO<DefwLbf
zV5y<pDxo<GU5S!%IVHGqdvdW9DnfWw@6a(dWF#n^E}tcNh%>}x0h`L1;HWuVv#Z%<
zl2^c%5A6)DB{*4~P}xyAVB=(;6{poguo_QMcz~oblU9<~VZq7J2~fX5`X`<yFj$Y$
zG>I3VY4&!^5HNIUZ6j++LGPoW!(#$ej~)}W0j5AFydbB>ay*`^a2j361Z62CQC1~n
zNP2Rez0KZLNmqw(nh?Egh)Y6LSeW4iU$vJ~f)s1X(Xk|5%}6v&8=(@0uVsWY9H=uO
zZ7~g+Q!1X#m4f>@i1!TCv@j87lBw~S%;F)O)QcTX@@bku22x{G2p1tyIHy{~XvHQe
zuPl~2pbzxgR5;Km+XhamQH9m~83N*BUTKgs!TGq_P{o+^Wm$Wk77MXTSnd~cG5=7=
zs;F_!ZvY#+6pN}d2&kk61XAP*VuY01Cqo1{jPNBj|A9P`8ynJd1pNYl5HLIjt_Y<2
zCC~>cz>+qc4i6A%Efg29R6IzN^o$|{E1*9iab)&%IWMgQ@Ad2hHu=9XU6d*bOnD}G
z^1hz^{=2)kM?{tmMra*~X@q`UQDn)IEFkMsDV&QCg4YtlO^8+1!f^%SS&fmK>Ua1X
zX~-^aJqs%qB?aWI5E??rWa%MHTUH)ix7DJB;*i7x7?GTu9}5GufIPlR!qYe<k{ee^
zSBemNejg#x*jPbJ;HmKT`~nRLG<#)xZGWF6sI1_Rm*!c*n){iqfld$if{vYvube%L
zTNo*ONfp}S50_*aTL;Mk=(9h4ujKX3hnq8*$5OBcql0v&pA06*T=muJ+-Og0sEQUT
z3XlRQ#2`~%$*`-g7yQ`}mI-2(rKc>`ZtSb?jUV3~4IV#`iV*^)YrKM)!|6mmf*(o^
zXl5dm2Hh5@dw{kx8d9=3j7jTdK}i=xWdLMxIt^MQmQW>*mu$agL84N&4BC3g2t|iT
zh$XhhKpc1UACEK7Q9t)=_ni0K;&}w*@n=8}@_EP*`tRUtjJ)~*##|sp((95)<_cyA
zdmNBk3>aF%RTQnU=r@cmHPv?72^3pG6-S3bp)x>-&Zg2%Az=)hpV06JaCD9VR)I|k
zfX)U%5}o42jCUYcUk8MAIIGh_etsZZ1L~L!y8(#NsevOx9AsJe)}&g_w`L8g&m74R
zl>(TEu+716$9FjDJ{7`VWL+~+dSfI5XNZhjGq?!0Fh)5SVT_9ESaW0YLB@o=XtL<E
z^)~a|054I?Z+zgob2#{)qRgJKT8FgV%$(v|Hf?Z~v6};}kv6PHc}n0QIy1ZWiw|7G
zQQ|-jo^?ZmfE==ZQlHpFr`06i{Btb1>R!y3Fx2jB_kZ{71q%WeWa4N!cRhw<I})Sb
zVBq2!?+j$ITllUw$R3)G(IF;aNOCIib6>5Hczb8qIP~TY^1}oRF7StaScvHUhwyTG
z#c|Bj{Qz;((}c<-(t`Kwk>sJP-!oSR3e52vKXOmj@)L{(c3x2FVizHmIStE5F$)Rz
zAO*1uLAD^NVa<U<mVtM7KLH0pco*~x9tuzl#;GDPi~SXo9J>D4QKc!&pMN%A-(A`~
z_hhI~xnoigN1*R&0tXBgdVcodP~XV)SF-p#xeF_;e{sbC_ZEpYi`U#7#4XShOm2n@
z#&Yd^WCAn(@}mm-!-3IT{f#&yi9PF55J?c_uK6L>YvclV-h#bCE{ks51$ypNa|7CP
zmB%tOoqzHHDkTI(*c6F+cZ1Tb!`QwcFEqnGGl+dkDU=FXFQklWeMI@GCMl^kH$Gb?
ziJ}tOLg16383-IW@`vM_&u`QO%Mz?iL3;zcMJKO*;=+Zi-YP7xK~vsY<WoYDAe+HU
zucKJ`-NG7X_MAdXqj%msE$TjI2*ciVd7wT<e4qNYX97kWj4NkY!3+<7p?4znq9Y$T
zT@Q7r0f$OqaiqE0IcE+B@de@}o&8H}M~vIS;d*DD>{!HWo96mLP^q+Cgh>orc7J*8
z@l6nIM9OB$s92%u@Rs<X6shZ+n#~T%S09W~?S;Z<sG^5Pa@k6#KGc8iuIEPL*zLpr
zG50^7Wr?rOU#S=ZLl1TiuWfzIl<g1~8SJ0jJN(@BK_gk+n`<*ZJ+pG|bbtxI)sG+V
zyREXT_u{MGQ_Gj{D$Ha*a{R^uCoF9GsDyCG09o%o`tNBH@aB2Q9rbJMYV4=je_+4E
zx;W&rz$1|Dw2lu!exOzOCVUTma7iP82I8V12rs}DS<pV`6(Yd|jZ8GuO$0nipzMY>
zgEsUNggOI_Q+IR5IKmePwcJ<lNM8s>+^vTGI-mtOv-AxKB(T%DJ*okSevYsOJKz9l
zT}=w~6>vkSlzV4X!7Th=s=9lF#fl+SCA!c}R0@SG1~v?1@0j{8m*vWoE+Bh>gvf$O
zdRXte?*SJ4ZZC1`2j7>{6*;$ZG0J^1cqT_|v>o$199c@9?nd6jogLjZXky>F^*fRq
zdJ^|(;Q1ZV6#x)kAn0mc_=YzDJ6v-gJdwLyZmi3D9MR6v#5(#~c-NqWfmJ)m*`WAw
zQyHa^pH9=Nrx!D$+EyJgpdn)=oQ8M=&~rh4zaDodJQ=JRkV3eLd~p|zj;0Rt40IfL
zGd8pg^dRT2!wLe2P=|qcM>vOoQ19>W*`8WXa+1z8MGNy$jS8gr;cdBZ&>J4bsVF_i
z>NZ``yr3{-G<&`$<*Nl-NF%1*pvEWqd<{q^sRJp2&UrB|d-a<@;-OoUEi121s+>*8
zLD64bZN&!srYsqRHa|MhW3yClYkN<Wgz&=XD2Gj31{;;1Im7@>Z0b{&%0t-DR+Qmp
zqqz~%+W0k!P!u5Umaq^nd6g(fZl!q|<_-b(aw12r39lPm1DWUSh-i=EKA#C%0$^_Y
zsTrqOR!Beq<T6!`=eY0yMX>~J4Gr~)yZ~}D2669rkQXBfp3Xy*t3D`jbm~kpMbhDv
z)Nf=c4n$M|L=RRXDSG+>xNG`si3hDU<eIxwR=m<N<_c|t1f(S}|M4}LVaC+5U#4hF
z(+S*!SyAOB0yH-)7Fe|bTpT0{BOxaR#z0g`MF@q8wmo=1gskP^IU7Cu6kTKE;gFUN
z>V!%6F)7G@tzY`}?oTm9;Kg`=Tp!eJ`_jK9J2hCkDwtOvjSC%+v;8%{q|p3OLCjwI
ziXOCW+)6_(G&>#PKxHBSU(((Kyp8Kj8|Cx?1_KNRWzc&ENss`+-b7Mjr$mYpMfKjT
z-et)umLqq`z1O%TcHEt^DYj!f*(7#0ZIeyn^gm@2+na2%-q;r5`<?+I+qt{<KKHpC
zQ6Q$AIdkTmuYd0c#3m~dmr*)ZG@4nX!N&3d%4;;L5kU>9jC+}#=3%V$s4d$capjp#
zdG{6u<^lL7Ezx*TLHBu46A`H@S{O6HbVpewA7M^(9k->NXDqb|SFb|=9@f54Fl*HM
z>UK2M)In9FX#sW%Yaq}SG&^XM2h(+0s@8<|5F7QMX-_#Fy(YHKw8@9!o}+YcDCB8f
zY!Ooeqrfujiqevk*2Iv%u3$Gt2u?|zubGcI;h2?zt!=G+8Jc$meI6yqDWxY0scvgD
z8dXIeaowWo4Dlu<xX}kdnbQC^D*Z@lH*0Tn?>^qpG5V%J<Q2tDX@@l?+r)}BI}(3d
z(3h|0q(GfL<7<}qRj?F@jBh~DY|@h9I!lX%n#)KiRBDw=-&T?k{Qq6_is$mR25TbG
zYUu|Ak2jG^rv(wwFKXBU+i|C88?Y&cTTPNp6Vz0OAlj_vnPkzP3D=-Jc5UJd4VxA&
zOAWU4vPOu!kl2B+^+lUEtIA8CFO=>#2mzMf;N7g&y5>I`7o#=bkmI$Y>-Q!AWG74i
zR+qAha_NhVo2p65)PK>nQ6cgEKSx9qcQpptAHu3=7Hz_74#i~T{toM$Q2MKk;#ZCm
zqNqLKOC(p~S>Yh}Zq<USB~=^XA>LDUu<BIRV^!Zlb=28Ps5*`{p*rBkb^ys%ShLP7
z!i^{!0eMwt#UQUBO@t_dra3;$Y6q<^>XI~pk|k70D@I6F9zyhBK%U)+k_RMi3;T%t
zOE?^?&lRSCP7o5TvlQILrdw4%yn}|)hh@e`#8{mTh0DcN%U9{wg@NlvxT$bZ^MtJ0
zyRRjE#ReuCjK>AhN(v(LM%6sjtWs%~J!JA&6lpYLlVzhfSetQ~4^kPmxz}zMjjG9#
ziu;31+l6mOtE1JIngC-G@R>w4;y#Y=QKr_LNttG9m8=>UMKzj2UgmBa6P7v6n9n-j
z|B{x;qoS8ANmh7mMX^a^hY&fzt31ncVc}G|x*Fz0zhq%(Q48AM|D72SpIGWZW9o9I
zd<(e0EqM1A8Lyx3-gF>p8@l$9yRH`J&*SK}dzgUJxpvLov5v6Y8>luK4ZZ;{thwo6
z$X(sy4s=%^z43aMx_geub`J=5v42E4`ojULMq}8ek9b4r3(s#jE75;S4JAgV8Fn5M
zn0d)_e$m6V0S}_rBfq!~1*ZkoL{$gsT!pa1-o9hWRI|l6GjQciXV1nEudGnnf}FJ2
zLnglM(@&Vf;%lA9*WYyh(B+J_h80kQ*M|9ai|`EUz4s%-^EBdfzEkzDz+V1u%8o3Z
zc4X<?PdyC7;CHD%Qy<U*jATUhC?ly8EEF>3;4LjrGrc09zDu8px`=24v#kg)n2JPX
zBHWmGI|$dq%qUAv;FRSfWw1b95z^1l=NQrZ5UQXzRA{snbsVkA^nzQ0@Xzu_vO<f%
z3M*Q5+3CZMfNxvvK{9&@d}4qm;s^Q)c25An^oZLeUysfa;ROdY-6>Gkt}wlI`GUx3
z9SFP7d45AjSv)R80L@4QKV2FkvO^OFrVPbMI#up95wW0a;ye^w#Rw2kvPMct;tcXD
zlpRVKSx5{p6gD=Izlg+A79ogT4Hv;>q3<B8n^@Qo1EM2aBzY1B5DgOzvWWI!<04un
z5s4a`h+`;0MhF>8`seIGlNF06Yao#)v$7%<V_AaYiR*&U6^_WXv&004Dx^VpW{$;g
zpx(XC5$*DuP@Xo#JG~ZF5OU*RlUYa`*6OJ(N1Nx`A}^yb2fw9mGl24dTxRZ64Ni@z
zIb=~mj(siT4TgvTK4K#uGP?~1DY);D(=+qSMGKhviGXWY-0aYd%M9~dPW6lIGUIV8
zEtv&cutt^8)PBw{CW^yjEq-tgjWU=Q%Lc(IIt#6hBmD(&sLw0P_W`*vW@D;FjyH-c
zREgRcjM)*M2f7Xm5YJ0n0d;D(i3-aheDR79A|yq*4ah7OtNX>S6~Vxe!9RC=z|EIl
z5}eg`kOP7D0pJA8%P?*?8b#QkX%x{#6)S<gZ_<9tWnP{(c;l4c&h-ZaekKrSMZdyP
z?zxj2>fFHkvGTM#<MP%tn*wIkxekj=AhP`v*2%<Lk@s0fWA9Tc#kp-wCYc9@wkRW6
z29=-$&x-=$CCwhx+&RV?IlmlQPFyDfiUOd{Ij9u4vk5*XtHnf}^m?LhCp{9ji;+k?
z9(ir54ib(twUmk_o{96l?c5r16ta+HyJqLIKwsg^sy#7-<L=TcYre`Tpt<Tqd^y|F
zVYqEK^^!N8w=lq>L<Nr(5l%r36&C;kZhz<KKBnMUeZbc?-TZ5z1y#@mX`=L&or#++
zdu&yFXxq3ee~k)Px$Dr>K6_?i>7igp9`-+)`eRdi+~2sOn9mtjPCe03^77hcW*34J
zOh&KU(gDwX+ng}HGTYt3^Vcz#vP>j`bP4;_C^|0HOi`szS&ah@We&jNm<0$Qg4o8g
zHQOTHW7LHyS?)7L4W+}1LS4sMU%WKDl|n`OY?cPOWhTzrQNoQDYNlYWEFGmLUttm<
zt{qk@{}z|X*YLFM_GTc1*0Suwa*M^%CVZM<lA4{}ztYMYk__kDgybeqci10eep340
zu@TL^n(hmm93A;-jT%pwCHeEfW@3=VVX061f-)~DekEv<xSrAvW838bjHG^cip2{p
zc;NO&(MoQjH|=)IQm-3{%d*est^(5V#0SfSZ*vW(Z?GPi-g{By;50BU&Q*P;>Um&g
zeHB&Ge^B+)s^3)o2{DxKR?Sd61soV4K}Jzauoiihom3z7FwK?iX2r^K28F?<MT>;k
z5R#&AvAF(8XvwUPdX|u5;eV)Y5<;Nc!-%E@0s&&|B$^6bqVP)txPs_1XcuAxS|tKR
z9%^rt9M<;}LYKr|N=H1N4bleUVkMA>kVB`SUx_n`4;wfc_@8_sw;`mHM2~}P<q4%H
z?UUP*-9=q~D7&=v@4Ns*Tof(f(!72O_7ocQcs6ojxjjN9QG!s1mDRiF(C>u{fKz}p
zQGh|hd{{sa;6a~dHWx>&Ja(1mK!f_&5;~6?z&bc<8X-@m51amc`orqf6`Th=4&#f&
z9E?1OIs#Y0JfM%@7PGd$GI_@!m5F@$mgWD+%d5OV{j=Ny#3I1@P6`0w#(EcYCywxK
zC}$+(Td-8KO;O53OP*AdpO*~rPS@q7H)ft5y44!q$|E9#;vB=-Cd4+InmVPL;gKb3
z)O5S$z<AR=)HR-J)YMFgex83*gz|#Q<1Poq1F>{9!e`*RJBo-KAVL`tXl_H1PT@CD
z#Q-^IDg8|o4I*_*s1S1Ratjt)x*gGjjsuETFgd)<C{vf<IK_nO>!mw*XlO2An9@dv
zWGW3X@I8>YZUglj)+HEb{zeNy2AX4#W&Db0p!b_KvpBQPAy9FL!Aid>IpsEv<uCjg
zB%Nz0GCUKKz3~fog+y7kSj~M_#!9MGGcQXv=|VIl*j*->`HRo^{*M?VL%ZOfWO|_*
zN!(^ZK@cHIT}bS>p=~$o72#bpI!qq5J<%_iBR7PQ%@=*6u(@8agj%PY>g?bpMw<<A
zcW`smnmn@i73ylUSF{FNtEa<V!BL5mtyDXg<!nK-Ffwli<6}E~lF<^z>a_#2g|hP9
zW*g8{dQXbhxmT@x!2qxx!Qx1}koD=z0_SUc&=zwjOr)0@rymOR@{L2B(d?Q^1!?o3
z|59peLnzJxW55uAsu9iBu~BD~;S3f<gy&XZ!$Y5PrI0$176HZ6(orxv%--RYM#r<9
z9RWeCp9wln@+vL}X_Mc=$o*b!ped`F5$Gn#YUY;VU9#RAMFVS4I|YDCng7B&;j*$Y
zluZ(uQWfP~kev(QZv^BTc>~alxF$K!ELeS)!244ts+ew8jyf!G#?m6uN^=nt^+UnS
z&b*T{Xq@1ndo;F23Wzh;cmaMXu=Hbs-#im(;*GV&46{Jc)C)i1WviE2Cpv^I=GBEh
z$<1-h@4=C6@BbI;=Gj`-Omn;qMa^U!zWK$&0N^_&wl1O#Kty7B2qCnE6)c(zt(mRY
zh{?e`$7G;H7)YRIP;BEGK%WY%0U-&pG|w*wO*wh6^s_;i&q*`tDbsx3{bQt=%STLR
zRYb}`$l7X9<<9rIGERUThBHZX3kw&XiF32OCG17rT^J}3xW@{j!3?L`n!(nYKN-}u
zUlb9`2H;d+c$$0Z-O%~0h?6%6N7xmh_Lo(iK}7Jahzb5Atdh@GeZK0;RsT$_px4p6
z=*#G<D;i+oqoM8}wUFs@p<O5LW#R849cL>>InXH$zeFe0cWDGB6GRa5DM&|?POZpa
zA8tw5uCVE`nmT2MWSLBq1$JFVM?*QdT_JZ8{-Q@9k;@y=GXWhSo)|*s$Z<l@b?Qgi
zaVp7rtI)DCb;JK<%@*B3mu5Sme<D2zrp|Jo(RjU1ZZBR%df24XXxxnmu{v4A=d5U}
zpI9c9I)2!Pk5?9S2|b2(AZR4ClvwXHlD`kWr2_;M;gi<KR`+U?+u#&D03>z950SWi
zTu!uP^bakNqo}Y!9#%I86UweX*~KR!R#qG)d&`}g70N5aPMX7m5as|*rgy&F0_i6~
zIWAPr#3$GeLYj04;{q8pm>F=`!9#&?68}9khl|ZS^mj{mO=Uz#-j|*eQ4hv}hB*B}
z$+Pf69sp^07VJrqW*XzT4r4*?s0l}Wi*Jn^{$hwUY#bX~S3mK)BF&EQrY(m76r&<q
z$VeGk-e-p$G32*<eC9}my4B5QC0Jv?W$2<6knVsrx1%z-L2_6HK%YCCQG_oN&eP6X
zrc2W1FIdzl+ngh|O!4auSy-`RLutg?$P2b76st3a*oDtoO$JdD3|$@ukhE<fjtf#p
zB^N~*|A{upF-j4Y9TEV*zbShd?spc+pSB1ZXJ`J3hciU>I!nvNp`O$BtjQIqmE5jc
zCE8-8jh-5r5{<_uMSGxCFe5C~!ZcETUmIhzG+8u}5rW<VqO^Fc8e%2BnBl|WYLtrO
zMA^#3jSPax>mv-SaDcy>GYw?l+BsbXb0EB>Ux}%B<+=FKjqQj1>Q|Qva|40U%%~ul
zXy8JM<kg^#cK|VzT+CyX%x1<)r2!giR?R?_OVTtz0XYLFShFl*qkIHU*=fp+O-C0&
zhqCeg>knqkRu_Bc`DouFT43)Di0^ZSgc?*em&49VBwe_3V|ZAGG-}F785^W%fe#ww
zfN*LPK<_=Eg-EGFiU%zK9n$Y!y2=r4m`?FEu-!7qNkS|u%bS29q*yh?fFe<enCw^?
zB{Urp0S988tfQqS@rj0klsM{lWI7vqnTV%2gBNWArZljMzTvPKJ*-Kvu*@-woMT`C
zh5h)}YPAuWR-9rq$iCc@sg`&(N`&%A$N(6!DHG`t%nL_~yN?3kS|VoWZK}c40E0NJ
zz9<RK8J)&z3*XL>RG*kl%OE)06p3UyOumL5$(c@%i0Kq4lvE2yhbwHV%Ww30>@Rq%
z+8j&^gVG^6S<$i8;zA(B87?h5Mdgs>Gv94;GxR%>62n}c30WGEEN2HoFI-Q^5Qqbf
z7r}eg3Y9k5-6}O8sYW-RfJ5jREyh#>=Rv7Ddq{xioENw-u$nzE(z*>$-(;$YI4w9W
zBcUu%^X+~y6p@VGt%?s($!@P;@L+gMRL~@=)b%nHWeY8faCmxSl-Z;iMDS$VU=Ynw
zk&Rd^HUr0a(m_SB(Uj3_(I`d<K$enhPF7)zK_kluZUq(KXxcSzVKFQzbZ>^m>&-5q
z;h6Vcy0h2?k=ZJ6yeIDrS(yTF_E{yPN*Qflwve{Vo({D*&)cNNf!<(H5l$7h6`OgZ
z!o(;VtBHi2qx?H1TN)Jvl8KVh!0`sB$-x-xz!SByE<7+F^(8g4FXN49)`_QZP8vlD
zoHd+f+NRP-xK%B3^B^y<?;E3>jbVt7E(2ZYa^VT~6(AU#2T#1S>Ot5+pGMu{m!Spy
zsOo1`zl9d`pH=T7lTJe|^*q%|4WPcqrPO)qF6se2i{k6l52&A0zo-6_w$UznA^qRX
zTxJ_{gt@Z9NoTd8vK8ebnI)vQyn*-;f?NI{w3Sdk?9l%pVWed>X_n0-!0?hJC=?rE
z96U*cCFB|BlRrNElT;GIYOnA&Cxzl3gsb9|9Ocl;Tow8g$Sz^i=nI&d9*n@lKc(-0
zf>l6*8V?;0r=h#xBcyx8za%s=Wp=Fz-~qS|VYaYyl^GO=o00T44L08-Pna}e55(w2
zHWGqHOjHP{1+yoO>1qpM<Yg!sr^b=Jggt;GlrNYat=ZjpTy&&K_fnR}tK2kcfjlD7
z8(~%|x1zV9Ur=U+7oB9t7S_2fxeF0Hh#^XsSr8$I;5IN%eL%~dLSsY$r4W%!{A@%9
zY0^Il9uv`~h;0vsIx;q84#`I&APH!t*hHS6bhr_ZgnN~FJf82OX_Aavx$Gn9J?iny
zzDfO}C?0k;%?g*I8|7pZVk9IsI<$gGL>MUUg&1ri8$eXhhe|(0crG~)H!q({UIV!!
z1T%68_L~uA4c!n<(WW{wN;nVi5<m$0V3r#rdL{Y#j~iG!x=9`yt)fdDY5L-(H#Gb9
zz?sM!$A&?yG(#pz0!`pn9|?)mWe)VSjJly;gRn+joWU0|ohsLp5ba6`4|#Gl1)wrK
z0|}<VX^``tIJ9uS`uKghft1l6)hs?X+QVDa$f>Q=&c23$E4__?p0qf?U=?dv47jWF
zH_2wrYiRW$HW!p0pvL>s^9LZl+c{+Hig6>|8aBbo7*>F+20xq1N?}8iwtDQGs+;}H
zZq60!e$J6a#tGed;W-E%CZ6fF+O#$kTmV99ColAV!^$*A4BjVcC_2c0X44|W(HV)q
z%@i~vc=k4%1id56!JlY!AO@NJq)G#k<9C5>B<UjnIv^WYn+;aU@1$%+gVR9Oc8W3+
zVdZB~^f!>O87=H}tfXe0U4DOh<`$cT`UyOE>M_aZvKZ<_E!?Zl{5ujT9Xu;i$1Rde
zi#elU{m4tCPZ;Hp-yfKRZ0WU&lYWV2#Hc)76nr9{u-?ndfX0weydl*v^SE3faaz(E
zl>rd3(O@^pq9F;_G(h=n=iSJ&$lLkpSDj{8ZA<CTtTE^Whw7wW#bcWUn+1g*INJeW
zTJuIhq*<qID%}P>$t8e4QJP9QOb!|Z{_6qW;*!|KA`GZY7KKx1E{B+uO4VmgB=-Y>
zZ(whN|E}CQYdWBDV<Bf-kJ9Jeaj&J_f;^BFOQrioj<z#yXt8m7=DHhE-xc{hyXNLh
zhy<s+)BDw=dFDnI(6v^Jj655c&=vPm<MqY@uecI{fQS+nl-WAsH7H!j9x=ewm+5su
z#Y%`SyR^U%aOKS&HEk4Cg{oy0D6Iy@Waw}-1U-c|)Xllx;Wr1yYDJ(fhB{kQ-eQ+c
zO{7v8--?{sG;Kt8qycXOSEO5@>1$q3YNBS^kzLTtw6AW-P8c2Tq{Wxm%)y#^^3rxg
z#AEW+^k`|OR^G~^`mQ>mI6P519F0&rhsKoR)_(Tcb3Hey@Be4iS1|iIBRtY(M_?$m
zux83O1XRU*X4C52n%5EGTpH~U2W(L*OuyCLF;UA|vb5RiM#b>%YA+Usz(Ta5SQ}Ja
zQ{5=Fv`MqJTIcezb6KiwQf}Ho*VL~G7q#UGy%A8LhmH9pMpYOKi|ECOOdHH@Q-Jd!
zu}I5EOxEPK`3VTP2@R+wckr~QV20q<!`vh>XSuKy82t>(ZZ#!jHu|KXAZ6=r7C~f&
znIDNUMv5L+gJSxApGa{U#kN8Y@CwHqS%vbnNx;(b`&FyhPP-jh-x8VbYyY<pk08nr
zsv3kQB-WWQBbeVv{Xh_`*052U`4eMP6d9)W>Zn$0px*GZqUGxjt0%tz<g3`wT!Q7^
z;dQAtSG8wyus7dHSxJa2RBK|)VkL8cS}$hIK^RlMVKKR_Rz*l6P3)xC9#S0L{~{H9
z)EKbzZRP+?cg}nh^E7LZvU^cF$-s(|Kp}!op|#RavAR%&owL1ei6INi!S6tdK4)be
zHY>GSl9OS^90){sL>5?$v>Wka<F1XU;bFb-Y{P&Oip3Bm%=?)xR0tn}%T0hW#Aq-m
z)r<iVrlPmo;tWxbsiM&UoG7tAW8)$SU{gkXZY~~KGsst4{hAe3Gpw$roXjzC6jCvp
zQL3c_kj%W8;0t!q))lZvC_xxC!`RX$t1y7nh1Uf|&1d3F<L;)?Pud59tSFca4mavX
zAQ#tTw`&nYb&4@e_uE-!{aX^_Gr=Y9r2*E0EI|W>Dw8BJ%-WB*Q2Y3pm6AMGUoarp
zj4pPZ89-6Fpj^**03T*GyQKwu&cw-Kh@LEkpf^h~*k-Gih7!)sK!eW}j|K-%$9;S~
z{o`9AO0Cvk-`&>N5w@gz!Y;qp<t4J72w5*6yuuyUz1};kUV?P@cT_h5TqBrA;$!@(
z%>2MwiOm5r$i;)4UQ`GCXI5w<eDr_Zzze~im{}%RB!XJfo`l~Jl2qAmeUU$2Y#e)t
zz))e8vnNy-ogN+@!rgR$zkj$XDKPi34NR}nF#;P)wrJ&=S+h9!BxSdd2h`;=@{u5X
zA5T}On*+ef%d+QeTM$Oe!1uEuqXa*(au=uY%HkBMCt-j!N<>npU{)j*hAM^a+v|=}
zPNrtjdi&z|Q0X-E$m9N<8`HLUPiO}~K-}RK?)u0O%6PR}0?JOw*|7O^<g&3qgXCEH
zpcw^mB#9F}W_UY{Z>O#E4YjggN%-p8T61-YL4%bQLUYHbjJ#=Zbd!q_E%qgYeRJ2i
z2kNVB@c|EYlJ|&IZY)03(VR8AV)-Ut{YrCuNlR->ms6W5*`iZTg5r$Qyl1j$yTAEN
zV`^+}xVJi$GE-gjC)aB+qeV)^lwj17rdZBrp%J$2nt4qz(4waZT%GpAi&&T%SR?xv
zB{(ML+YL<~lh@nnt`j1jLib@VOVi%i+#}0peirEJ?HjGjcpD6=q=kDD>uk)c_b+0e
z+r2B;X0W*~fo0HSp<nQy80LHL@i(FB`m)F8nGuZuXcetvH82>G_JkfW(j$BAt^S@B
z>(!`jzY^$Ox+{8W+#I;N6i2;;Yo?cks8wLZi=;VA9K-M)cF=E}+FEl|TI<V(yWDLX
zZoB;ShH=r#n{tJA#I$;&fX8w)<^vvY($#xV_CY5#iAG7ZNWog!TfcT&w&PMyZhkTr
zt7+}LRt~P%pafk-!BT8VxEQ&<SeKl?YURq*F5Y<6$wUn=AKIRt=!nl%W18Ja2lxxW
zltNhOX&Wsls1U-yR%%f>lc&qTS_LE}nBsKQq;w7;aLKGD{N^Z30|tk=EvVO5Y(eb6
zV^t$nOREk+LwmOB`&GZJ`aSSH{;LYv?UlJrCU03p)Xiq)C1fQ#A@<HLC>_44A~Rle
z4aF-yqFH=Ta<YC>WgWr|M3xWHRxaXE>RLu+onq0DGb-y;7fZ`tFUX+eQgQ^g(eipE
zn9bqxLM!*Ua^1z|$&KTr3q%P>T9KQGpliKbHmGlCt`T1Tq$4jplQDSf?!KXK(Y<$H
zVhKJ}5EZ-6Q4ImLshKl$BGF9?(vHu3XDpo<P9~I~vnJkaA6+WDYd0VZEB->v!8nF{
zGZ&7yTP%UhyskD+K~42D@0fk|jB|2WlokxzZs=m{fuq8{!p7R=-V88ZF8p@%TycfF
zTB#lF89(F!8c&THSvs%(>Y~3UQe?j5UcAmj+%lj2-1lz~Y*b&1$?j?xJ#p_m>2C*S
zevgz2ras<qk0ZUkty}V(xO25(6+IcBJaOXr_g6VO)|K8EIJ>B!#+m+0tCCWZYD@^W
zh*LCev`cY=s`T&4LYN5pX{KPXPEE=6?Z7ALIO53M-CO#W&-N){eAVi+aoYaCr8i5c
zeOG6VMS4<`v2$l-@0=t1=)xx(0=-%)-c9`}JKqwjzxH@@&9cnGQ!@vRc1KdJPS)32
z4vq;%i2<wzJkb^#b#~~U-siGQ>X&WJHqe|m7%upmM%&s?Ev?(I`~NswItQcBC8n2b
zS<E?Yh40!zoeS3-Ed5|LUmP`RgFEc@af@%C*DBDm*&L*nZ2Ru}?<{y|&+!{OE`62q
zDDw@a9g^jr-%&!JFMTg3K>!SJoP*=sz(ikAx|TbK7_AjRwfRleTUCDpW)OmD%K82b
zQ6?P?7V@oLr{9>gWTxqVcL0%@%y}~3>MJx~|3nzg?0SI9u{<3SOF||rv^U_m60HeZ
zAYlReq$Nj?TC6wx5l}1?9KF~qNu7nthx{@d)OwwNgyHriLEA7t%=StD)E5<LaW?oD
zO%UxBm5y~KmL@SiXa-EFtf=BRt|I|7g5E5AHRQV!e2^fD;0cKyPI4CXmZOC_?i^#Z
zdTLDzk(B8YgWe>dTI{ac_#C6-`)^FETem&nr%CxR(Hid)6|F|nZfgR>Jxo|4V{AWU
z@Hoxy_;{LD!_KA7o&Jp3ms|wxVQOioBJm=l8fZhybucAI46ADad&3XUQ=+ib(U6sB
zSn9kvrt}IgK|LyMv=%AeYyxt(QELFWjheRA45D765~!D?#+<d&XAiM5BQp(+ZefX?
zM|hP53Q$ha#zd6)WJ^6`YQH+j*|W>jla86{uCdZ3E^x~9{NT17j5X$}Z)E<;K3&M<
zR^3+mm(|YRce-hq%VgDX(nDElt+7-cYVnLfe`Jg(tx2L;jRr3-!E<U^^Obqp?>OqG
z{Cz9_$!2|$i7-aQ3D_O5rR{!x`XTt%D3@{0RQswEzE9Ve1Ul(Re{yrk2naCM(b=X%
zQLkL8%?eDGYkQn&zvWh{)=9NE5H!zT=rRbjc}Y);Jsh_uM}Y36c>PGWhbK%_6A`7Y
zA-3A&l~9-Hlw;C?7~o~p=H&)IPZ^ExEp5w$yXN|QykjrL&Ex&aYjRA3)mIajWV3Y>
zk6aQ_jaTP@4<JeuhbS>ppS*Nd_yKPKm&gOl{9M)T$gal<(XAq|0iYryW?-2w5V=OT
zb3n!^n+PxyA<yW3s*4#0v(uGa@=^J&!a`;*#1z#nYd}XXw~ov7#z}euxw71<hM7yG
zzzWnMPA7*e8yfrQ$-1>}_Wl))Ko*N|Lrt$=g;(4;gpu$AWlKQ#51n#x)@&l)3MBm)
zL?anBfhY@8e~oA_w5ooK=$6y<^(JLaDi?C)Ga1S)$c=6-JsAzTn$BJ|Uk$bP<apbA
zm$%0=3C?VkRKLgyR^BJdCRnf)w&)MgtZBd&Y$`q8Thnd#Q4f4>#ax>isaC<(rNV$g
zO*Ur@OONenlVQm7RcEcCV7oOL4oh0jEVJUgqAf2_wl!8y08;|8KZL#N*hr7bEF>(U
zcH_+NTD`qHj^`&v=ik}dKEP9nnyxcF^=(-FwUV}D?J}1^3D4`Eqt)-eZ7AQz&5`5u
zW3lR9u^R4kM2n-mj8};n+w-E52sPhaoYzqIe(=F-QyYedhZgO5+tb&%o-r2Mhi{*2
znN-uQ9j>^UF}wS>pG{Q9<7#xEz6SWU6Qxh_OHdy!41D$_Kx?R?!XJI@#FSN4$XAtL
zHhCE~XXWjcKM4g(U~1_vto-uI5KD}1F(k$(w1HVr(E|jYxhREWdPMX5l6T(|QR~rQ
z$#tG7Zh3^Vz4QttKQeaH)_Rvw_SmN28R8{h_4>iV4IwxE=5O!2_jlcWo2i&`$q7@}
z1`#TGgxOg$aQzGBuBT6|dvW~1csz-E0~TMqW@cp}m#tG<@3Oa*K4p^nH@<e{$hrBO
zL!#~UAHGU?O22>g?aPE{=2+*N>q@`*TIa$4Sg~Sn*IK)1keq62%Ln(r_13+6Hf>GR
zIgBR2zU`Vb@0y;{RS5Eb?RrGVPHZ~)l?&&=Cpn|vvG=Lco4>rH>sU=90`*uWWBb9E
zQA5XHl|WVV<%lk-;yyaI<xwfGK;lTP<OXBO>WghQ@&#ZJ<q;+fq`WHhmqF~>WNkoF
zf^r7lh1kgt-%RBlR^AN)R-k^N3G!|T>n!lky?YN-W}_CKZ#%#L)pK3vGua!uul?p>
z?_SSj*dg+~ty_gvtT|A#)#VO2AN%Ctx+X1CXHjXj&OKl}gL0T6Rr)REk?bZj=lnlr
z!6tR2N0$ZSKv4<CnjhW2|B+=QOnPFK8txQ1ugdr4rB|n>wskHEivHcVpa0IBTyD+}
zu6=qbuo9yiy4NjS_;q8(^w`p8!viKOvJBXWedx<a9(Nf05k&|kxnkRn;b7e9?D*Nr
zFOAFeleEWRqv@IPknNgfpPj0K++Z>XWpvzHJFxk{Q%~=oyaADhUN>r^8@t2K(%bN2
zf@WH))Y2uw+q?-F`At>xs`jJ)!xca%AzqJX;q`b$kNx^3Flzr+ku}KBlPwxzW@#73
z7k^boxe(GY!CAZy#)<cV*P^S;80J~P3b1pbLiO~P*s`8kp>n$I_(Oq$V2ctGs@u&;
zs4G+1p^Fo^7Qh|221k&!T?sCaH<W|S%dw=G5@j|(KxfO%5j5y>6ndFfBh0+9auE_O
zL7D9c;>tG)Z=Yx>N_MHSdH4RKCq7X+@QucloM>Hq<QXjgw!*;bU;OK7YHgq^euffj
zWG!{N<QSXa{Fw`P4_{@i&IxO#8as{L@DuwMY&__<n<dF}h1M9Exw(;P;u_cV_wMYw
z@{#+rrP^C}Tz-k<XTrJ0?WO5wpLpWg($-*CPsH1q2)+LFQ%^ljElx)r(c00KwSoZ_
z=kF_>3QGkZxcA-%W{yAjzyl9b^)dA+HP$;kOdY!Rs<YS69JvZV)GvJaxmgC4X3~C7
z^M(Hix;=rb70wW<$5&c-W=pM=Hd_uHy<~SPLuD6C#JU2-b<cgZ!?R^Yer)Mj<KUdm
zONFP8hUS$1y`M@yv)=QJn_3xPZt0w3R=O-VE~#x(F1&bMFy6D{L|?AIqa*Xp<h<xx
zx!p}WMh88gz3T<(=+-~@^9Z6!Em-%J7hf#(FI))E+>0;1IP)1xDq?o#yKS^dHc>Y`
z_so+|KJ(0ze>a=wQ}5hZ{#g?V`8u2|o2BQ@*%yj<=6G1vtIq9247pmm2lF;r)l$`k
zdAk5{EXNSXLa=Ect$GeK_tmP`5mo+EXoi2Ox<F#c3B5?rn5A?$M1YnNAEF0XW2Tj7
zuReokSv8?S`Y&cL96;oMLSY)oR7N`>)qv{)g+XCEVrjwLCiDlJO5&mQ4K9cePp(W^
zGOx%?C9WiWQkMmirdd16>;x{;wnF~meAN9=|KlW1lHd=0x<VAzr*N77U@uS|lI5Mk
z+l|goyiLDUT2ngk8uQ<mIUDEq?^@g3`03z_&tBLyvSaMM=U<9G{gb`J6BmBa-6mVB
z=^KxNt#+8+duM3Dh_|C-oZHZs&#y1-{pOELXNp@7>{yDNbce<K1?u!0H(s{U;<jju
zcf7l*RrI-1W`PSlc;5r}mo81_n<D<|bo7ba?!5aJD(7xreV~)En|m|e?b*2uOWAIj
zmx{N<ns1tU`s(YhyZVD{V5&9VF}Ii6aq8%?6EiO!KY8*v^=yQ-tH;fvAs~c2uKY~9
z23xHwaGDKjR8n*2ec1=I)qZ4oUu8Cz?x*G}*5e;oywTdnYj-Rfjb@fFx#V*lgKOTo
z=f>*l8}I(FmE-N7e`9-aY%#m`ul=0^&i7upPfhl<io6iK?#e~h&I1STpXq9tl8xF<
zs=4&}bq2e3*^2A^i0H~kBBhi2*8eD43**a8rK{$cvrX0o-F-2dfAYzvOP7p{$bWw7
zsi$UsAqIzbn2ArGp|(6&SKYrMrrr18gZI6~$n&UgoxS3U(^sDP#9}wy(5SL(l<Do-
zBG}!66V7=iM)!7tCflkyN=t;7`3B7GZrC}<jD8AHxZkY$Ue&Lw-h`dw14=@TjR2K|
zwX)$NU8X-C)}+(pveMVo$&@E05kIl%+*NP_Swkn!BpCnVtWN5XPmMNA9Wq&G8E=_a
z;w;4c16c!8pV&Am6kBi9SqLE^=i)}_Et!gBo|om`3f(3I{o_aUbVy9^i>m@xm5F+}
z!Yc9w$YMm>dN7wxw&9IMtPvs5WZjlmnlrBJtNOW>tN{&+;3MZb>{J+c5?<aEFZ$d5
zyEHmIed)3N6MYdWn3}gxv$xs#qKXM-JJ)+hG%%6ey}tFKFaC6mD_<MnIj(l&4>yR2
zFtvYKJK%^1ll#{*?w!SH+Q9l<E9!Tw`es@(f6L%PB%U$h|B}Jva0Oz6jK$*Y$+{h*
zxgxw*O>>W&I61J8y5h%?u%K{uH*57wmL7?+SJo9z8=?bU(^Eaen{T}7rW;FqRJ^>H
zzg!9qc26(q9(uw%m~V-sH~#RZ8*jXc`o-4Yf9(^3tgUiUi(RWVdF7hk@j}r5kj3b5
zSWctTx@7m%J)BCpt!7kydR+5lEu+I*?sns6H`PSN9PYYDQ>h|-RjGEz(KFQF?%V0f
z_3kh2v$__|-@bGr-0ADyc*AHe+x*G;S9@)BLDwpT(uNxq*_3Nu>Rh*U>Acp~uQXC?
zl?A7@%qr>{pNTOlMMKjPhw;L|Nz0=Qy@{GCMd}<BwcOy!&ZTpUQaepbb-nyS75$K8
zV%ppL8Zx=vQ{fcVUBCM9s*P?lwY_!RnKYnguraWTdbMM0tYcAqwmM(hjNy1@_G>mj
zbLrA)`CaUqd1>P^8@vY8-8*c)^@k)X6&v)Jy;>S57jCAlttmD(8WmHKU@(%}QVYY>
zu5Frpix(#dai*=KH8DCIkB-eRU6IAILw>eedR%y$d$X#wsu%0-Xw{WfH_S$WJg2X|
zpCJ0<Ev&y1B_gLjaB<~fx)O<qtiLkwPDQ*)6qP0wYeK`+oi(hK*9sVl1!jsyRDc8{
zDN7=l<={xV*h=O<X#<VwLh8kZMpmwFIMg$x$>G@r2dhcB6`@F?FR;r0QQ#>rGSUlN
zhV~oF#Gq`3gb}i#e0_!IPzVqwr{Q+CS!Q)nbRr!iOK)~HqD@X`K~53~kKKAx*ekqU
z-?=c|;5^W1_a+}J{q4Q4bW`RAv)0pZ;*wgwD^<T@=Xb^9d$Y@~yX4<m_Z+OD2YdYu
zA!}^Q`@g!=>7H+kxa>@K7_s!l%ti)K_>A+p<fG%C*ngGMuwL!z&ECZ<3nwI?Z`D0D
zz5Vd-KXd=!(6aZA8@q?O4X6;{RYH-te)YNyG8cESH=YLhoq6l@6=yF0b+V;1?yhM{
zy`7$(nELu=PEvz$Y3{)zy;3}&a;p#GXXcOl59~WgopN&vbBm|%*m%{IzgWL+-TIlg
z)~#Q^4#<Z=)h2th2N7%s<8|p09zI>f7ch?WI)?+e<aE`s>z+N>rU-&7a?Le46|OfX
z@4uyX)xE1I=bx$I9@Z7`WU4(r57pc0FV?5VzE5Y>CCM$8@T%DRw>lzCd1~Wfpc#98
zQ6oDhx>Cz8Ik@?I=}o)Cb8MdDL#o@~psiYXb2xSW>~BL?Fq#-lUuyVbB%F>rd*)qm
zkp}KteRsCbYbyAuznwpS?i_wg=f=m)H_T1Pua}5>7XNta@a31EIfLKQ?*&#`O8tH7
z)-BsMZ{2c$;ye(N=GXzelTcXJq86$AsLQ27oPs|0l<)|*5!s_!RkZ4l6d(?C^G8{e
zBW8F|d0p3q!Q;cfiDykW@9DrQpwuweB>*m>pJ7F~3Bima8SW^1p1{rFBGX%9qSgj@
zq-W3j@DH1{60xc;m=6!kwn2{Si>b`4K61Q#$7mC<3vfGPY@FqeYK3886=6Ysbmfx8
z#*>QBameDZxs#?592G4_i-lr=m?q203;r(f|5=R3TbpAmN+W?#eO=$&Tz%)v-#ha8
zp1!(#2fKTpHfI4BF^XJRF-EMM1V?JMIlx<ej3p|oR?nzy=gzo8PWjV{65qGmDcOu3
z#p5@NUdfNDL$;)=Rf(f!E|*GrtyT^dQWpkgbHJZuCEto=&UmtKYg^4YA~2b{=(n%(
z7+Jw?UgAtXS!-`|7zCq*^H|!$e-<pq-$RzTEn+Lyxs))xv>uPgnaiiW6t8K_U*e6;
z@o4eBd^9m!S2sME&kqh1>W2nr4#ux-l*JXIae2DG$-UIYn%ILBSGv#QLfFY>V|>uO
z+E}_T>6EDr9Q|X4`tjPMijR7v^fS8j>(VMm2$k8NEsa}TZVUAps+zL*T)yElw_SR!
z|Jn<4v}jPJduF~+?Y1!A-SdCO*UahhbzIR|yQlPo>_Ll*OZOtcf|~yGx4-3X+`Vmx
zmtcaV#^|hO?a&rnxqHvCt1w$lUA`qJCwkVo7--M0{MrZOOMAOD?6dj;a&OBOv>VoQ
zy>9es_KRFEY=#>2hmX$Tf0(zJl9*!uzosFXOyv#4b9S~7CeR4KDZUq+m3_>GfqZ^o
zAYV5$^YhMPLvLT9&`tj;q57@PgnjScq{EaAXRS)|;C{`bxJ~Ae!y>!9suI&oS%15d
z1a80CU1Km&2%J#VJM5$OwqTD9>Hby{OIwq;PKkt-qYkTVl)UUK`H_))esrw9I5=1=
zj0|7+b2PZ;+>@mr)1@Dj#vFc+M7>bzv$#D9Afj6-*S`Iqce*X6yB=G7A)v)jfqU)D
z!!=$D^VhHao2R>OXp6P0Yq+kN=A<@x^NOpN4jyI}*sauX`|{DzhY6oWt?tr0oSU1%
zn7e?$^uLXHnT36PS!4VwBmkD1$}6et`tTT8^dF8k8QhPJH(ciBp+>yw&{$*R*jQu3
zf|;j#TUrK(o0?)_CXf!wMvInlrZqWd@YSkn#_O$><8GhVZ?`7haxR#0su`y<X4dLO
z1Ya|}VqT|QYU#2hJp*>$2=6q!wC0h!Z*$I5xq_elcGJSi#>Rz{#nuJmElm^Y)P*OL
zQO}xNUVi@(XUJ!w&l_g8BF@UnuKh{r17GNo&#!#{TfoOM(KpZRbNH}-;OB2!=NZN(
zSM>Fb7js5TYN=b<dBfJ_Uue^+BaC6LTKf9av*Y_gHT!q2pwH=R{@3x<C4`U9=_IIb
zd4%=9J|wQ?(+C09Df7q9A^C0eM+dwzi^<F;8$=9}p;or(u?-{jg`uHBVQA(@eGLtL
zeGSE4`mLnRr)mku{{5gBb}d?MwW^LIhg@pdK${a07YLl==+S0ZJdm`hHs_HetZ1`D
zF~>6=Ijs~EU+?pG+u_tOvB3Q`TD(V`HPy~>Z%-8I^*;9L{DS#~!u+v@hOyCNadh;;
z&*R~Jw>??<E>-%MQm-QbTxsf?r520F1SE}DsX0_|{~zZXa=EV@I#_xgYhbh^;i8@?
zb*erSa;nG)US@CU?{k77!`(Z7(r!kYXs3Va<y(2{vCbR4^%QG7wrXttW8__^Rh`h~
zz6xEgST(<D3e|HSK#t8b$f_jPiJ$3pDc*rT2O!fAy?K!8^iAhmWaP2UPG&+tk^mNi
z9g8J}Rdq>^NyMTNjwNOa;*?GT>f5OaVT6XjD+UIr6$IEYNNg=}q|x{V-^F_@OReR*
zR5Udr+Tr)2z)36`AJgk9=D3P5_@P)?Hf89xxQg2L4<hCNYR32nfs$BA%5o?XS1SjF
zuda!tfxKZ!%(>$AbKiU5q1(3f#|2xaeOj{wy{yU7_V7(q1J(T0b5wz<zVlOElF5}w
zKC)`&<zvT7zbXA<mA~8Y>HAaPbvt}dySzU5PpPi(%yE-zlV%R=|K07LwPHKNMs|4f
z1IpB5YXDe(u4sd>@zAjiVlLuT+7TJHY(g4i`*!#Oxlo$1McluoE~n1_%;)1Qq9a7-
zV&PKvwKv>w?aWuNJAeJTzoomoYQ6P+nNsTL17AG_Wer)o3xK0;TXy2)$rCd#oH%~$
zBz0!Z*d+rS4sY8-*|y_n=EZIJq4U;=-EQ{Ro<Q^$Nq3z2m8Q9PWt%n3M`VAF`qOm>
z(k@oE#aFC&X}o3i^fjwiIa0yGntLYe10J9X@4R963tKjB-n3!cs|U{1_d8R0`o!>;
zR;?O|bqZ$rNJCw!<(S{n?a0Qw$2Ix5H&;quE=Kz)>T4}F3sT16r9+)7vk{$;?9Jbu
z5w;3vI=XrzfG4jW&6G}2m(~qfLnZ^Dct!^n-F^36cj33RV{+1TpX}&fViQa->0N*Q
zxpVj}eV^kp)bID~*|Trgo;@dME+DkD^g98lD%iYUTL6A^V@nGvw(Kh1ChX?(@DYq5
z8|_V~sbkb)Y7?*^zCwMC`VsX<67)}pfMS@T^K>iSM-S3t^kRA?y_rxsvT7=8MhCsZ
zs?li?2{W(w=*nOcl@qb75IyxjpGRc7*>y0xVu}s*WHFMP5dT4i#pp_#9_U=AcFqd7
z!O4zt4<JimdE%OKgL;rPoEfAgvefmcYxE_7wTlf6UThrwZonD(6I^UqH*;ez;-85n
zhL|7GazRICCDCd6KAqr})jQH8Ry(00fcYaIpcHx~@=mIZnL-)?`9OQbdV*t!vPMgK
zIsihn_26)F2Jy!0bmJdxO{|_on#Vc7*ZyBSK%NjHa(y0;IIF@Utc4hKi0cLyBke)I
zFCLCO5t=1F1V=e6t-OQm!V|y@r4Ln^is?;2c}BFHeoQBfl~&1<);D5;BpWTHxr#z7
zfC}nUguI6)JX;e?w)#26|A%w<r{~w!45pLe3{#uys~3E2wV8a@wZ@grXKLHMHR^?@
z`*O8RCY($U*3`~d%>iHgN6u&yz4ff6xcEHSKTsP?ktI`;!W2cjJT7Z+YE}DKS6!XN
z<V;QBUv6AAN0GHfns>rn7jEeR_Cj;D-D;LET>8s!lPSkYb#+~1?W?AOR$NTcQ^Mrb
z5~R5zBs`itzqklTxxKns;KZJmaGiO=i<V?%&Z>>{S$n#elWJRxb;Y#3FV?P249yAj
zex9OL)^0<rM(f~U8|v8r|BF#+suj-50I!Y2x_@AjEr?m5t+X#ROlg-7%QH`TtHa3-
zc0iqXiivl*=o=31iuh*!h#S-yTWX~oZqOYY(fB}uVp?$n#%}Xbwzk2+R@}gEv$MFt
z=X(Qlh9<Q3SRZqGak_O%sLow@AYAQbJMOxHc6G&>?A<nhWEV8?mRj1xr!#XC>B$AM
z<wA`{4TpT_jsnav*(49sUznRo^Cr5s#Vn6crW2*!*7V|BwZJ~R(3X11yquc*hiD`c
z{S?CGBdZb0qVZ;z+dR`xEjK4#ur2I-lN@+75{*VyXb8;Y&2ATp5oJY|Y19CP$w@Kp
zXLZZw%`YY+nG8&nWBtwlvd|EdIF9mbjR-}^3Jd$LZ0#SboG^c$a`b0!F6}LblRF28
zHpi^ymw$cB=4GF~jb>=-;AI<jEo>UZOYDxhY`(KQwl8X3yui%+w2<WVFKVRQ(y^73
z=N4_>an@%;@&G2rVAH}~8!kIY(KK`0XP0fh<<~Ept+CBRgFBPqV(-%Y<jPpOjc!bg
zIHi#0<IM{eGqSI*J;w>Tj=8?{E=Qw98&>AFWkuetA?q%@aihsWnMBRa8zjysalUaN
z$x?oo%~P*!pXtsmm<}MxTv|P*npK)rLv3}TYJbEZ^q+*%I^nC%#H?%ElSA{El5cKD
zPT+FweZKT|t=?mE!4ksp<33Izpr8M@+lkq>xyrC+X>{y*cj+5nlEiyIx1yW*0RDoI
z>JQr6*IHwlYF}i+sD$PXmBPHqV;`AgOeKeFvujrtJLq49fLVf0jjfiD1|OJSkjr0K
zSUa3d8Rv}HJtqE8OL65|>Qkchr8jnTulOAIorxm9cRyFVR4F|d3I&7sy;swW0B!%?
z(pqlsZoW8SE<N+HBSd}+!Y242{7mtxWL0%lLscg*i&j@{0YcUhAY@&G7!y)o>}!zZ
zNCe{FsVZ0o6_g?h0m-P2DpGT)32GU&9&w3DTbL*;NhWL)Y)xfLIlMlghR9hio8_IF
zP0P_BVW6;to+XJ*PlxN%|I$eulLX}kfz`<)p;+ZFIz!M2=0yv+FxyI{HRL4ekqID*
zFtO;OU_$RvB1wN-<U^~KkYY;r@!BeFFap!qL=ttt;VRBE5MkTJrU{D^7+?(O78N{O
z#iajnaS;c|STq*6ia1#@J61k5Vx_n7;Db7-C85$z2Z!%Td?()=@gkmwj0w3!A0^@K
zt0!how{JUtep~y@>4~df+C07gK4Ze2qH2zIbseptQtpJ&vvqJ_dh-i~O~vF=pU3MR
z_lZ29(W0Azmg?$SrugX3Qr7VlV2KyD^`xop_WlhszMO(Wn1^L^I4m#m1_EA24f+EC
zM+(q%?Ohi}lDE{e-|UfGR}J0x*yPBhd+HR0NajdGbmyVHi#&sk%O0<GMr`ppsKxU5
z*yhu%7d{j6`9iHfdUWkeg9q6{d&BgWh^8S-`c%^8Om=i#dwTQO<HOWD%r%^%+6~6H
zw{P9Ht+aCsem?1}DJoe{%@@~y;*mbqL49GSUbERW#<FVpvel)X%T}#e@%9H*^V%m~
zbepVlz-ciLdh1Gi+$Njs%MT1wNJdo@sdNZX_sEirI7-{;s;(}8Dcs~>{y0b_j6ODK
z<0mJ1TacAZf>`>=;MJd!I6?6FJ#C^zwi{|J-s<f8HfHmq%bv||Sk_9VeQMiq4aW_P
z^t)xYRP9k}40hS!0Jx0z!o%UPZ>cMpbhWTPUb(+CJfXPiUZbe{)3rmTxBiJ5<yW;f
zG+PhtI}R7M^Qy_F9?9KwVVc@%b$AC#GJ`B<AN|T>7j8Fr9CwXo`U=eB!;3;TyJ5+S
znFd!p?QB^;;B{C_w=idnR#r7!cbFJ%5AQF1r>BQMS>Iq`?@;ZwGcadv-nM1yZ-9`_
zFs`KAsSSlZ8pC**<h-G7#cH%F_)j)gDOm3hzz6WFsz&60zEt&%s_$0)1oe5z$_64e
z<)va&4b?*RROC$}1(L=1QQJS#<;eCw+x|&NCE3FIbxE>bu<62=uD@aN>Br%DgCK*&
zRo;NKqHiqH{wkr$Wio)v2_3+Bu$~gpkz7tzm;Q;Pv);XO0~Z|#IKQ&?KE5`I%7q^3
z%TuRI<;MTNc?fjc^HJq3uFJY`5P))g)IZQMN&Ev%HgEFL(qG>F;#?a30cCJR@W-12
zdEy>0UJCcX)w_OL_)KDG-?q)EY`fpJ^x()Xr8inPpF4bH--g8-e2I9`XNm=b4RoT-
zzK|KLj|J=HoJYId0%NAlKKdx%o=PuR)Iy1OiigZ;%ZSAki@P*)WPCC-qN;;kog?RG
z{R{VWJT`X4fq(EX7#nlXE#9@C_!qLy^`%`Ox)FZs?`_L^bFGPgPcI$+e{&<S6RpF;
zk8Zs3s-LgJ&&=E8f9gILd<E8xO3<dlnK1JoWiNtYPnMks)ZdR^|IFdC6XEK!c~zFV
zSZ-g-fxB0ieFz-!A!Muh!0>H1Ty@jCUp{x}#HX5f#DgJ6!~7LX_w0S7;fqHKea$VK
z=%y5R-KvbU+WLfdEZ{{!EL$O!x}LHbcMT;5{kDK1yTIOIQ|1nsw4u4az5_=)Q?46t
ze0DoL5MtQ_A!w-;AMrq(7*t(>f@|gY?Lp#!P}TW&>K=x3=S$a)jhW7W+{bW8_b{Bf
z96kolw3PbqEnBv3+q`A#AlwN)n)C6+2GvT8mBsq9hoK6!Jk`=9cyA8a(PM~v-Ud9X
zFID}#>OXX(z#x?-73Mi;2IcG%JsyeRNMI?HR}lWkxAGo+8G-H0E+Z_RSuRSfCeR7U
zb}^i<yrh|Ugem`p7z?t#%5lh87+7k+LrUmylq9U_BkB%r5Nn#{(8O{=G&(3#`t8wz
zUN01j3!N(Dfx%7|FA(m~WANsrBdJHFV)>FvNknIj*CG5GE4Zv`qW>RpmDeRv0!lBf
zfh!Y;lfz>Z>kHzN$m-QS5n#=D1RY%%{1S-qAQd2QO6jp!Y<lk}Un^bv3wxmSsCx5?
z709v*W->|1u*O?l`1~W^Ho4T^Owb_QKK$;%tL@|S<6SoMiWN7P{+Kzo@7~n-zYaZr
z!8x^lrK7RMu4Nt=p+2j=ZZ;0wd-f)0xaToZ>1R(bx2dKfS@hG02<<9$e^B-Ecjg)R
z)rK{ku|IBdx|5Xc3?z#8ulzAJLM?jj_BR=Ww3uphrl?>c9xdH0$kg0;`$~>qb4zw(
zS6kW_qL6cmECwjPMj-X_!<?`Fi!TLd7OwEaq0lQ^$2;qLy>EwFYVxV3`V;PXtUFg@
zwaRAaNZi#3zuE&YHoZBpXlkAcBaCP3)h;vAY<YF&^8k1-Nc?AjnQ%pY-Ok?CR6ZEF
zf;IbklF3jVYjw7_)Mpw`HC?;p;oZ+1+!3a@cE6~(LR+tU=)K7Y8ZZ6Cq^s4_m`wJu
zJ$D}6)1|04m0ol>4&C{5P!Pn(snTm4^)Jr)6W8A6@VCrd*u6tZ#7*3PC}a7&(Xz{)
zxFgBfk0+ejwJIwYMwT%QfQ}_sSLrpXr6CgZu52BkWM_X5wOI5*a1*$6|NTe`Fu2>A
zSSBF&sd|nJ2LlOMv3B3dF(EaoSpzd~4-QJ-))L`%PZp=7-F9zd0wsp!OM;~pbLK$q
zeZh&qch1Xt4Uls!SZhnL)*7lJRdrZz`%$Ot8e|#}TP3NB@Ost1Rs9Oc2gJ$(TW@7!
zKMVpyuCo$v42LvUhuI9x!jP#93AciTr8UNNyCpFN6O#j}PK#*@Utp8Iew`oZQy<1r
zk^DBjl<lk$1dFSpw-aQTN;8DnF!+M5VX<9Y1(@#@5wsjY2-9R4{F*EUK+q=5lpY>(
zQHmt{DxrU-%;}Dz#b;C9{AB6NUoPG7ugDyA*b_sGPEae}qi&^cd5>B-VZCiv>ABK|
z>G!_A{jRP1GM}Dlp0S+|Zs?{QzXe2I@Hu-rZQo=|ZY=$wk9RI|Dru#3_b(1^QW+Df
z`6&t1QgQooFH?hiHcqXWu8q`KL#{cc%iSxR{SGVT4vr(A(XtsorMxJ^m4i5W?P#Ji
zZ;DShdu=Et;+Z$kZ~sxEz6Ok-@#XECw{E3wy5x@AcPy||^Rg}!#0AKuu+ythn$aVr
zW}emz27};U>()>fB+I<kxUTf+pKng`nmgBJdgLW)sv+e~n|-Zcp@MMtti5B$jyp=v
z&(Ao{=C(}^ZGRXwl>Z7B+=IhIr5j#<=cW5bhN%npsI9l&9CO>?;``LbHIpsT4qD0A
z+KRpNY_!_Gy!3n`v}AJe*pz5f);+%`?CO|^)zl`MP98e6=S`FqQw#CZUk-(wor~T1
zLZo!p=%DG#I8^HB?iQ$hc9ZB6iyCXxsJhHzC%&L4l$Wck!Mycj-hLkh?G?<~X`mP0
zt|M4|9r3Dvt$H7|mTF=2?xGf<QvG)7G<7qo)jv)>M}3KUg?bIuPJc=Lf%>aHrz^|=
zlV_IXV`}M40aJ>6!arQ*D`mQjxkETY8--xk@@yk=9l4Z9ayUd(J3zZvR*G(Bb2?@l
zCH#rdb$%A+0`v^`C<}oQ&?**p-9R?mCNb&58mFsc<QBx&4u}qN6eac&Fs2nkkowS$
zzN}_%gu}#0R%QiQce)KS*-+nv0-|L#imbg48`60tRua(=$^B-N5E==T1mR@lv7HsM
z@nS%38JnIkTe9qQ<0ozjQyRGh|IpiVe**Bj%?3rHqh#rm=Pn!G%EO17>enMDhymx)
zHQEY}BHF}3vRl`LNt5_qvE@~SSRHBtmy>EK<#nvPL3AM*v0&w(F{BW^-Rnvqu-#sB
zBj0K>$Ljr|@BIDk@6;luf{8rSDf_DpM!H#`CYPR-3o^B}^Z0@JC93KVQoya;Iytng
zx#wt`$P9-d%nY;Rlq%<ZowlgM9h9cdE0^)pY^FNQ1C9CC)0@Aw`Sk6rOd^vGqMrTU
zD*^aqH@;1Mg4+4(Xu+B7n*UzhvtUzeU7~*h3JCkhLhkm$^ny|L%Q4o}m+R<A_ZizH
zjt_Qas3MX*>PIbM0NGUEQ|(7~#lmCC0lR<I!j|M6>E!KocYOJDYCb2PyIuO`zFoWa
zl@=Nd*1XW1>*}oS6`A<toUsEG&>qIl<Q-`XZ%f;HLbd&U%_!qxIJ=0Sxeq4#Jyf`N
zVBTQ7YqISdpV-~hy6db<p1fmD>TVPVWVD(3+)7zU%|F2icT;pf^Vs5a!lLZY?Jm7J
z+Sodg%VoM2$jh2@wguN3>ge4QE%T-dEF;>v0oT+a$uhCArg8m-QbT^~%MODfd__d-
z5rSR19DK=FW%;W+*KT}kbYO5~=D#LJM#rhASXmUUNUI;SxB?c{W}SHm8RdZB=T~W}
zT~eH?h57!?t%)tEw^~|zYSz0cK3?y2-+Oz+4fW}`=e|EL%y>LO8TDaKUA=L;sTg!Q
z5vI)_*!1A3#T#O>`|W3_ny{yaX^PM63b%;x=r+jwZPXL@g&W=K=g&<otZhk#Ly2a_
zIprL@?(Qgy6yNYeuOCsOa@t-xKrL+TSEB7-ps#N6?_0Si-d__8CYVPqTvD?jHkIn>
zpU14`3W{WLXKJe5wPQ(FfT4RWsEFPa4Z7_8y)(Z|Ix+_PNV35iJ$&fUZ!(#TYLS#Y
z+neyuEa8%z+w2XPwyO;ZHJNB#SM2RF0E(&A@b8BX9V#80SfpMV^t;`DKqN?JhT7^b
z7;W}!(&%ZBXMT8JCNWhrO`UYMb&V{V@Oh)1)9bUS)#^#N8tCeR+lmx)x5r%i>-Nst
z?bMUSHAdN8`T!27(wBHXN_}h56n+*>Hz8LaugVMAJV<wkfE>Yd7N9MgTugU7Smm3Q
z(W6yE$j7}3`M5739~TkV$jaBiKa$i2YBwnFO+ZI_oO*%!I_U0CP-Xg$)ZeHXTA-~J
zJ=)PQD>RoWW>q*eE0pUb2_iDo={N`+5g3Rmh<F;Dg|cuDmabpSlJL*6Q0~M&U0^SN
zC;23>?4xbn#Q>716UB1kAt74&1_3{z(;SeM^2MM|WDn422%#n0#}swF9h^yMF*z>^
zNJ8`uNh>-<Cwqu|g6jw+B>mQjn@u2{As7Dx8P?mV<fByx+pO4<=SX8@1QG@Ohn_VS
zNO%(d(1m`TRC6#M5C)~QBp~vYyW3Q-qk1j~Ev_lzQOh+_NgGW%y~Pvg&xwAb%qsfd
zfSM$;R2E$#k4-#5H~{KRF2gOz@RLCUL9d)jEOvMU<lU4>GX|#2WG>QXVzSdsbvj@a
zk7UlWz0X-+Xw)!-WDlXuPR8r93c2D!TZoEhJ*EFD-CugDRI=43qDKlvg9(0<REz4m
ztfM|R*EXNMf7uheucfkA@B7Re+Eh}{ty@!iV)>E>6({qU85Jb%edyG47j93E#NvXB
zcPkw?wd6wf>clk*w=b!m{HsilE}UpG-+9?xH5Oh=H@<tSH56<rL_^*n-@nPyKXrQX
z=-Qte_}91o)8P|QS54$Qvg}-N?4i9^?pV5V!}ft})9a;c;=FNN@4zHu9JP#`=<eOk
zaN@FLsCVwC6~`Up1AgNUR*5VhX&Ji8=RZC2@bjk+a?*LWZ8^t&ZQt(Q`$~(9e6uXB
z>+4xZaj`XnLrd*@_w3nA1?LTo&x!5aLH+0vyLFE|{`l@YEhnvpg;SzneBhRRDlI5-
zkGS4R)r~q`_0@(#k~L?t_5IDR+x{=Q-UPsos!SX1+V{G*>eh1ied&8|-+k+SU(=m*
zmd@58d&ojU2w4eaA%U<j0znWF5JeCe*%T2JMNt@BK^YuzKt~*%ahv&cMul|wzo%|@
z)bF1!mF~V(_tdFVRp-3tJ@4{7CUGu!8&4nfZDEWJMSL|e*3~)KH41<rL#;y-PAukL
zH{v&IB_0o5rCcz?EWdCY2<FO6WpdCXc_2z?Vx@e>jXT_AaBzt)r&H2cpM#$J{<bY!
zwqciA7i>Iu(E4i5ye=vNvtQ3iJUBH0V*3y1H};eOXf6!L&9Dv!L7T&K4+DjqDJ&y=
z8f6-WmpHb$moK%kuBDOMzJphGa6kvr6STg8`L*#b--b;Wet0~Vr>Wr$N3hrhUHrlF
z<U|34BC}NSESgRG{OPq5USUt!t4QvS{(#2{d};HPL^A+P?&14uGsA~2np8bMy?8)V
zdJGRskFR;Wy~szV@T;QLYBXFkJm<E4EP2(D+f&}LvHeHhW7Cawe>uzqs$1{rZS(lX
z7H=I}d_9iSt-8+`8d3bW$o?$P_B1%WK!(DGIyyS{t4yEZTAFeN2{Cr`=w+|QfNDWc
zQ?;OJ9Y1pPGVAD)CBpS9@?5prXwArMqFl=RG#4OKV5=l;grdeAN;(0+Co+WF<pXg)
zSj;8t;8IEJmb@`i^htBylBB-2WUexqPAA%R;+Pv~x`1ZT>A(c*-}mgf82e~Qf*f8K
zAPG9>ic~z4#>U%ldJ(JnOzbTvV0}6LNj}~#g|<-24(!MpB+gf_o-lddWSk^q|K`Yz
zV00EqjQ}VPLeXIjxCqvO&%zoo*Rrx@XUo2pQy|fA2d=6oTE5)!O~3$u4<tKaEHpjs
z3)u!ud4pum!e;xLk+`rW#Dc*S1l3=)Y#M3CAWK!#KyfO_9Ri{SNrxn3OE7e{em-LW
z1gI^CY|#TXH)SFystY9+<We(_21>wx@JgiM8c3cYVP-<Tb`SuBEh7O1o&_j|<j?=R
zkS&p*6xd(TDFzr%o_$=I`1suK-#+u=#RuibT7jj7p;Y(wi*6WQUaoZQ(t1|h@WWsI
z%bp8Fpi>HrNi(xwc<EU_ADigyJv8;L=#&|GM1A5cwgKC5<HP#Oc+q-MmIpTOtn*H?
zzdqXCIZD3t)vtVQZX55<Up$&~gx%y|`|zhQN3N|<jK<o$Z@&1_OD|#<Hm<4;j>%GA
zVahe(0%Q;Iuv_wl!(V^;sln2N4;FgL63@ixLc|S7V-Ze|1mAk{nfBCOAKiY<5Kw+5
zSUMZ_cVU;QunO!7^$c}l-+6Aw&ktJB(y1H%yya_as~(4!>c8adH8+;M5~LE=#^@EF
zy7!xpztw%uP}J}G;J!z1xJ~nUCQ|`m#xtuoS!)7jc>J~ttf!9c*m@XSQ_6H;e_}Uo
zqyYPSAQcJ3>eiaif9{Jv<f)BGBSunUUovv;`$MB{Ec&_6KR@^2hjXQ}EOL~9{k!U9
zJhDIk_-8H(x2}8m;n{RK94D##%*ef|5bw=D{`i(ya@E5RpD`R40-tFsJp%wTG(7`r
zL6j4=5^NZymKop`xdieUp8_P~W**otkk!!EN<@g<j{vk?9s2S7{FqEN(evzy4*DhJ
zBSL3w&b44uhmX+50RXU(0#lwnx!PSFb+Wq6ux@wt`Th>w7o7{;7_IRXbOHq+^f9`m
zq?Gx|l#Vg6=2$>8D3}$YEb3th2Be4#f)EsqMu$Cq&Mybi82M|gapnKk5B|=~VfS?u
zMg`-*{Qrga+rG8`ZEm(li#<9th#Ff+h%|t%q?u!8K!86?&#wXH04D3RQBM@)WRacP
zVLkUs|LU8ryK*sr;f}L{E7H1w0B6zn9s81i&W(?1l;@foZWA)Rw-rmog8}ywx1J6t
zQByGU>nG{fWx5o|nFmiltscJO&tr3U=YNuKsE=H65zr{Ld4i{DoWPD<adsQ|#3qb+
zIcUt9b2qxzyZ@aaHcX|`xao|)hONQYzvOM_%`m-Y?us?DGs|aZ&z-vR%2U>lTC4Sp
zwmb2qYfqoP7Q1)f=R0?wa`-Ox|H8M+D>Ew(96EBT)pFV4BS)}t>*&m$o4+@^Y16F5
zZ(6@@3wA9;%&Ni;iX+VgK>d~HKCU?lFS85qa5XGymhcBv(dF=jI6&#EADij)*U0F)
z2rWGJyrgg2cqQH$40f3Lk#%Q)%59JScCLhD<>2int^yw3-W+k?ZO;<HZk)QRrs7mO
zNMbMCa{t_NlMLdoV#`*{b<p@@H(vI1$b~JVWgz6BWyxt>x!D*g3~*dO;Fdbc70ktZ
z`b;m83-?&x#gg?cK!Zkh;`?T1)-G8*_x6=n9<yGYoaDZXKBQNALUBnHX>9Su7hie_
z{Ie`Cc5?OVnHl(LGdV*k1MIk@mXm9A1Mumke%N&r^*D?zlpAvajIA0(Fzy3u;BQ<0
z2eM!oNMb=AF@%CTV#jK2z;<B=uq&{u7iJ06qd-YT-O%pw_RvDI)RxU)duXbY=zCiX
z&-<?y<^WskHyda(%m%X6gXP|?3@NmrMWYP`J=zL83?g8ZLYj50Y8y5HJd3o)5&Gu*
zh_a)vY^YA8zt)_#DvpLU8gKTzghnm21kf`VX1Bj`>mY3y>BDG41`Rk5dCM1c-37x6
zx;5J%vhW28Jexn%G|;0~+ivi3y@X&VqQ>73RA`$`l@kMEod3nn0qp}ZfiP5&GQBXH
z&Cht~*`Vo-`K>?s(nDht-F2-$5m~?Ls+&67n3qov?^xA`O$=Xna%OEbG2kdw2m6*4
z_H78Ytyyu%=bgef1z)O6&o0{_`(H?XX36PY{@Cf|8|S8vitb`|a%MVnI<w)9T~GIO
z_&vu~fZv+@YNc4Qp3&s}KmO8fZtLOhO63`1)4)hRu=Z4B>4lA;pB|i<-1GWBIkqmp
z_TI`ROFpspl(46(@V&i@X1d9PyYBDo><=fci5m_cs4vRw*IM003z%&iPA(FCb@8Ih
z_NP60SHyZl)m_@v;aDvE0DymJgoHhUOb6CUx392mZ^omal1w1%l2m$Mad=TiYcQb@
zi}yW&dbo9R*=#)?a~o%wVMa`b-xwSj8MJQc8z1k(;xa(bF@tW7)M%H(Z!OgT?lCVI
zv=aa}aB^v5(aDQ9EUTAsxmFxJxoCKH<gU+kmAZ+QTRUo_lgEY%HJK@PEL%2|njXyd
zY&kGKOs?L7#SWj{e)RB*FCNa1Z~fF%-_9G3j}nc3{J&<R!<~f(AKbNl+4F8s-&|nD
zQ49}{Pc>dRwQMLBczoZ_J10BZowd#lYq}Es7etnCIo+CQgjVeAs=bO`zUpHG^=!%8
zaq;HsANW-2z7se7W3B6=iPke$U2`ZN&$JI+Bk#ED<nUP5o#&j4bItYs&hARb?$J{-
z)1#St!yUvMK2Jc%X4{r<p0IRo-Q~wF+g?s&uevN9vwrFG;>QLCvTk=9Hj83VFTFJ0
z9|>BIQZ&Ojv9qhdf(t*LJP=`kO<4wzOlMo73pjvOw+p8vqAl6vIK7W~4meI91+T&P
z!DH~>;5nyZ&fN@goEKx4VOIjn{T~3ZL<MZ*Af9g`c7YUtRV(ypG`7GTi9XsfE)0YW
z!%h;c^hkq)UX9k$=r1ZVf7q5L_E9JUV+?)2@Toa|0Y(TUO1)%<KEg;x**=Zhd=dZ>
zC+G+5!ay_iU=t;_DX?nb-?PISVZ7T~W<3SPk>L^sT~nrXVaVlSx6Kw$APk_z@I5rv
z0NT400$m2T2OO`#4%!DD6r~D6D?z11%?0_<tOAjX!oY=mKAUFCmSwgy1UUl*;qIEU
zr)dEJ!^pg3vuz7V5}lW$U@=Aq7tEiCw}ye07HB1Coxk9Qho&?i7eGPRsuZZhsMScu
zqVNLb-L#kUaACNi6!7(-H-xljJG;w%32+`fHp7Hxjot#>7~Gc~qyRX;&}^s+UC%B9
zAK>Y!6lx5r2R$cL8Wn`pMUZ0v_sP_XF#t6~JZXpwz<#vw9-s~=^jx7jstKH2qy%5v
zFdgs>k(A6uk{*qy`vt?bVS-k;VPBSZj%{*@8W!jPo+@w33&AAVkg4Ds^SD&-$@*9|
z&oP}v0P-&GOy%0Lfzf2(SSc(pY|4Gh(CRDA4C9Oe`qt{1_;^r_EfU-p7An0IXB9Mu
z1E5U9G^F@d3W{6ydaEUOqo(Q+Ms@faWHhSHZLCwQ?oMU+h=&YEc@HfLbgWp%J5)aw
zm3Xy(TMSljoZHjO0h<;!;FY~*Ak3{$MgKnx=lZ=QfaJuYZIm;t`yB`NJ4-@@%Em%I
zV!IrzYqXaUbG+bo6Ta=+eNr1HcRNH*vu*`4G2j$E-Q#mCw{G@x8kKY^YH5dNDqdg3
zIc^3+7_q<FU(4?-;UL0vIo7I@eZffN){5wMi}|j>u7u0q$pO&;BVf*MZ^Yv+gr@o`
zL#}dIh|$Z`=wzT>j%-D!qJDN;G}CJ&YHYeNZ5`1?Uu5ZuFkwnYSbwTrQo0bHE{?nO
z?#ii5pTSn5A(xy~W1M3t&3$aq_)?0;1jkg0-m~&r$}excz~9K{gKcGpkT~pBBA%ns
z&?Nv5-|y-0)wX4-7dy2u=Dj@0iCSPR+L)oYt>mNBAN^ha>7c+Z9h*!#g!Wv(@T~Rb
z_TUGD^{~&Yn-8V8yRJyIhXQ`b%#0(@MX$cXwLA4G#blLaUu)|cj@%h+-62%-?V?V;
zMG!zZ1G!_mmfo_RgWM<UsTjDOogqg!(BpLIx{Ccs`T=k*C@zKoK8Y2d!c3p#1)>=_
zMmQtpEawaX;8#s$JsfTwVQ0%%%JEjCk=qo<TH3|{RxA;48EaL|8)Bowviz}+x#NR$
z0`j_68rmSu;+|9&TLSQ9R|?1LN@qJY>WflX{lkI@CSGgum5u$a*na?iSP%lJTt3Jx
zT~SL*8w$FnvEt$r>k^rf^rj1zR}yXvYIFg%WEaNzJ^oD2fPIz~aDVSq-0$~}WaQo&
zE394r>dH@PYcRl@)BqbTU1G8P5N0UAH=ygdThvuurkDv6;Fle^-%q&jedVi4YeF2q
z8GI4(Sr-CQZSsenrG9VQ431%A*e2`{c02gm9>Jbm&;xC+F}P)b<78fZ*hAl5RwIGe
z6eQ>vSS67t1=)Zippeu+-!~RyAV|TcOb4L?LZ&HHKvXLRRRe*6L@m@cFS8L=xUFC!
ziH}50)0k=3ZOdz0=L=xqH-k%pxB~&x0QrRC;GqTRLQokE#%c5g2v;QEQPWUO_LKxF
zB76hBZD<HgN~k=1hl(^qG3*nOQVAP~YPh}TXH)^mJ$pi0xQFIlqMG2&nv&D5uX(@7
z)N%gwSZ$ta5<LY5rUYo0{dF?MAcS_;eCcL8QMd_IYaqyYR6A-7l!n%JLHK_XWHGu!
z01QD&W1Tsx1Xhw_=gktem;m4~HuJTC4p)ClARGdNcLin}T#DD6vK;n8N~tGGQP*Dc
zz$J}9+t3Z0>Z|wk*AE1vo{&F2#fGR{AeeC*PXbHgRgpDanNFEndrkt{B$5U=RSC#V
z?-^hnijdSUx?4z_#R>Yt-nhyVwS1KuDvKm%@^mQF<`WoE%C2(-E9)f>mQ5R6&=9ND
zA+O|>xnJ&CHTstxM^{BJT%X50FHGEi2bO#+4Y<w{_(n3iv(L$pxyeMpLvBh8<_T}6
zGev2a9ZRdC*k1rkCzePgJWEKIH0g12ECb=quE|9J@U0s;Kdns{BCR1JmgU3W)x~&*
z$t@GzOjHTWL9x4+H8)3>t+-&?=}Z+Bprn{QJ>iJ{d5J<1p|HE}t6NCU#d!pRA>{Gx
zqxU7E?@0NCDaXlDB2fMcDMLEhu$RyR8s5DtzetLWTK{?p&&e+CmT?&LK$o@&gY_o>
zIJ8ar%9207fmT(WlV|gru7~9y|C`WF%eLh@s+2G3aHRbH<djnkr@Z;TDPODgrA)z1
zMKEA{R5%>iIB<Yctsd0~CINKZZwD^a_F%D0AMN7PTDaa_TN?s0wU5UaZ%Sv{#nJ7P
zkwoVgleuf2S7Ln~OH7W$miA3jAE9YBD38mu`q8K}!~2D0=2{gvyqw;0fOi2e3*|L>
zfF3ql$!2^?s1{y-;jKU`J5<YNC74!=6iyuH?&PyVM6E_T3I(V5pvOJhmCyAnBeQ)c
zw}wfX^iq_Z$8R=ky>xok0Kyov;w?e0|FLh~e&JF6WZl7PA)oK)n~!CdV=F%Rq6;rb
zd{%9hdAW~NfCU<8V*n6ZWbxI2!EZubz7ld`T2M(r&iaR}Z!?!s>mbHu5~2lmv>XQQ
z(;kj67|?(~Kehw{i;ojrP!LIlWDGilL&Rpd1u>pBH#AmbH5g0igUyKmR>^tU&{T(-
zDezDe2$6;F=67HOUPki%$>r;V`8%K7y5e&WUEEa*`qphpW*{3ngSCG9#Zkjd_kE<z
z?dkvcQ`Y;|U#wd?jqS^VnlCzW?B+{OeCd;mCXQcnU^ck_{*t<J?yRB(+q_zLBJ8)u
zAa>vHQbMs<2X@Br<vQ271BL!{@_TA*<Jh$0srF0ig^M?zxOUgU``}VfedTHE2Oqol
zjy;v9?z;~Y?tRR<!TQT%$MUxyyaecom#*9PVEx2$|EAbsg%HEx#89O^+uulZR!5WJ
zP^z<k?$gCYW=CfwTkQseT1$%#xxJ4ww^Of!HTgfmLXZYa=ZCOQV?V+_fj@(P1%Cto
z7yMWFp9vrjARJ(L_7hPwLo}cJyc%i1K7=+jx27z$p*<HqqPK(u9)iZMAyJ!L_-1})
zKoRQb^uNB%W?diz;Z;Cv26~6hY*e#?3fiHzwyuoiF`6roOt%H5EiV^dx~&o0-!zZF
zKB)3g78w9g@dYIpEgkH3q1ap4(5y7yanRodi(gam1(a0O*yfEiizEFUHK8f_QQda+
zQF{_YH)G#1{6@urQxb$aY62<<_0Pxn!pwzc2Nbs0ya0p#*jFmf2MVJp46X$1VbCgc
zNputT@&$<3(A~~Aq})J{uDPy(<9~%DxARM(9k#*`^GfqBn~g^&P)%bfG#9lLUI@Gz
zdv;uC3S0!;2F#ZBRA)C2Dzlr~Tz$Zy=8DIz+g==@+d^AiN0YkUZO~E*=56Hjgbmp)
zD>g4BdW01SywNLY_BNYKIiPArt1Z|^)4N>-Dx}TFc{YzVI~6p`CVjJ`C!4omHvtyK
zwu*on4({F<@_E2o72QS&UIK#_P0f*?ve&ApHlz_S3o=5pUskh}(XgM50g4aYMj4T?
zp_NZ9hVWG2e7#OBdSmC|E2aj%ef+NBf#vvk7gvxwvR<Yw;${MjSLf79t13h~-9c8C
zdDW{^%n(C5fP<GdXwcO=M1~$vWQX9YY)$y0Wbtv;Qwe(9k|6;ipd|Aif(3g=M2qWD
zuo22`p}vg}gEcwM0iB>`IGBJ>YFz<qerkDiz^}Dw#T@XaNfDq}P*cFKl;AEHZclh<
zxB{@9n;P&Hgc3d%ui<7=Y=b>Q<{e!DZ_zNF;W~gGDG^R1G<ELMfkxrv)=%b7zx^P-
zgiCmwirxjqJ>aHL!#Ut;b9mh(F2yA$g9jKOP&P<$Zn)}CPdgLdUhgE$g}GF+=z|RW
zyeei0Aw*CO)u)JE;!Gw8{7_N>qwxQd6`XZTEVPHfxRJ2n;ITTc7caUeGE942^>{B>
zsbRSy(WLdMgON+NbXF!Mhp8C68lP;3L|1FX=fD?5)81A=1#h3KM54vK81hBHr-$QG
z*gMcWEEjW1mzR=i*v{@<tOhJ2TLfcZ(VFqC-leoulQvB`DByACBnPO|6vF`lgN~6R
zkSY^0%`lReBjHvd4}x|%%~~73SaJ3{yQ}aV%PX8ZMnzdd@B@unH3*zuc{b$I;A~*6
z2P|9>3v-AH4W_=3rYHH3H^bphndZkbDY`4%+398jVU_BD2{k<wW7E>Mb2kPE5&Xyy
z0xJbPKu=c(a?r6EAK@HqANVyx0^T*E81*_FLNep_J6(a`t3dh@qg|Atv_@6UFR)-2
zX^T$F&Kwnu<9a%2D6a$9F<p{b7vcP~%<^RlK;p=EHYL-2^}?pQyVU#V*UA!!V=k(m
zMi^<%4fzlW>GuTDYVH9aDD<8}Ax|fOErnxU;h{!XAMR12J)NC`;f$sQw?~gdaFyf;
z0CZK*f7~w`e7~pw14OR^$p3jRtFTday;NwEQcMo8!8u?m33g{1!T7M7(j~=g;~MF3
zI%?>ggJ39t#3j-KyainX_-6nnOkA*39=(H7%37RthI(0_Nz<uH)|s7-r4P=n_Rs+K
zUnIgQh6ondamg6;aG;{~gaFOXh5ci2kwlxa&SwO7aERwBnA^RThJ?p-4-n3AkU$fS
zv^mNj06&LGhWiwX*W-kzD@f?VlbcDG`|iqnX&TrN8cB=^VKja`a_RUJi-x-+x>F<R
zkq@=;CJ#g`HC$%~a6n~_Q#dQ;Qpx^nOPvwj%_*Uju(UnzaceFiIc;Q4{Ie&tL=DQ5
z#SIfPA$HnB-X6#$lcHPf*LYUO!R#5xlTi|=PIR&du(EZ|Ah<40Ae?~N9(Se948#<7
zOG!4`yCl@@$&pls^;DM9zEC3z5MIj2B2jmQC0A}1i20l~co>lyAvVCrPyqTGis)h4
zm7-r_i36qnD4U2<GSz+E#zk?pIM!G^s7Dh~Hx~{#&n(dZq>RwBYy!02-sP-R>nLVO
zN)sF;O}RIC+9AF<x*Zg3!Yjy*%Y(iUraDOX%Kv1&4Cx~CMvgsU0Oct~aI$_}hd2OW
zu=6-t05=`!BVkyZ7F)K0Kl?%O3BCY6!FeAxtV(6vmc7mS$o>styE&PjpHN}0S@2>f
zl9dQr`q|SAZ5s#esi-+2*>fm54Q)UZ)trs!3WVt|m>w4@#r|d*oWCq`UZ3A+7Z~cI
zjIBJvj1J7l^R?9}TfITkJQG$Ne$Myd=Uvy7%d?way*V+Wuh=`Y+9YVkO;%ZaI6Qvz
zp~K(&%i(kPw|dPLemo)jK5RYF!&v{Z{$%j1Z(VQ@BK!liE8g%Q4GeW$H*)m@mu8pr
zOfL&{_&T>vxMFRy=@b0~L=DbpvA(N=%T}4J%Qu&m>aw<>PmaY8uLO1oCtqQ=W|s?Q
z&205Os^S0KGqQR`olTzUj>&^qr`a}~a{^Jz<L7=PZB2=Bk~4M_z9)|qH>Q_apS@b@
z2Hxf&Ddw2H>{Fllh;isc%I1q)*Gj}xdU8kH8(;j#-h(@ij2+_klt%t7#iY0u#-fgs
zKONv<padRiTXXV2=T(V;wv<+s)1~!W29NIj53KXR$Adk~mL*Ca-V_SLBTswl`}-VT
zKUJFRrhsfn_RpRT_f}>*ocq1N3@V46{?M1trRTmGfd|yXk!69bvu0_`lN~0m{ZaYj
zaX}H?0|2EWw%l#~gxN`V14co;Wf1aGwnHxH35b*UaLavw)A%&3D4Y}-2`AzZ4v*W*
zZdgOW#BbIcD9Qm;7l0tNJ5(YGJqg@XlmW47afnQ9npB}g;%`19H*eE$(NrjGwE@om
z8?Y^d`fJ=81T=s?g)}Enf&T6|)Ppo76upa-T!e(%ydo$iJFPET=d2%D?^<)#SF!7U
z)!8~RQ;j_N@-yFN8W-l6!ce-~dg5byue!*3@7=$&{N-oXkFoGiFyhZY!=k$njxXAC
z@rvQSR&4K*$xHW-FFM!=GQ#RTyEpSpP)<#ZHtNHZQE_hW$jHQjy+g|m6Gvw1jm68$
z^%*O+rdnAt)u^qs^3#p>iKX?@Qlht~cc9aX_oA%9UaJ`M>dD^D_pNjH96Rw*FxEPs
z$L>A|&3XS5PqbIGm$1$EI}eRyY5<9U={0BHIlg7nvA5qnwrR`p*T*m2zi7p-E5;XZ
z-#s~g@Q@V>(S;%v5`iJpFx(NCb4HFFm>9ln&(hlT;zoJ-lCM@*uBtQ^FWu0-e7e0h
zwRo(*yKnhG9yrjx;mxJ>9<;vUK%SgtaGD3?<VZ^b_#z9C72FP4!D~RKpfzKQ;%q3k
zMvf^4F@MCYBiwKk@!;t(B?*B5z-pyX5eR+(mjEzsHQxkUNdl_N!i%wEr;+Z<;1+M)
z2OIxGZ1$GB@4f|_{oyui#Cip`k@pNN|E+HU=>B`w6Tao!CRc7-If>tQZs#}QVPSLs
zxZFo9S~onpwy5y`GIi$6+;7&7jLzP9rPTG)xCj&8k5H}H|6p6Nk>6u~vi?x5Vxq<V
z-g*I&9AB_6@zOi5VovKnUw!9u`&Yh#X&K&n4jbn))~~nSi?zJ6azB1{7{DM$+hp~p
zQ#XW8jI3KTdaU(oSLaWYUN1l-Hf8Yr^l9q1fYSRt$fS%yO#UKl{eld(*GUVK(%wND
zd2?&(;IIQS8J<n^gDqSahJk4)AZC%9q6%IM6uJOKL4jYe9l}}w$~QIog*q25hR!ol
zy-4>*pEVQ*0>cfgh-moOiz)cn9KQA*9Gm~97mSk4FHrT(!?u42y-K^?@Ee)a&~g(h
zYruIngEA~cU{!R!1TsCMOTzM{f~szywIceBJTK5QP-CG+)OLH+qLFXUSm><g!A8(#
zJA_#Y9cr#ROoKihNViXv#0-$`!D_|r*|usmD4~bAp7F&|zwGb<)oo4o8TpB&1GL*k
za-I=E-~BQ*`H55Ce%M#@mF5DnD>%?Axkm<YY6nDJQcPyKn*>VRNI2YiM9Y2TH#^4M
z#cNj%PWQ`naJeJOOYN6n10%4iD2%JdGJ_|JI>Z73gEJKlFsA6Dij0sIxDdycdDB6s
zJuDw-lenGQB8~g7wI>I07D0~o(W35jq$E5t%R(3-P#z1SN=87Rpdspnvz`V$A|*Rq
z4p9YaT7{#^MVgWPl#8T*)PjL9B49!Ocvkl5s_=p{BWfMfKTSwhAK)1JwFc!BIi6h{
z3ofxNT~28)soj3p(B!?fZ~%jJyPoQ(quSP%7%i1DIL1U1ZSk!eLzqMK&Rme`N|==k
zMbF^9pT0|pzq}lGrF)%WG5nUbZ+m};RfYhiE7|KI%fV1ErKDeT2+KKs^p5sCx49ne
z8S3udyIk>hNvsr^?!9r}irC&wjXQibewk!^r-yZ^e9T=XJ(0dOUQEauYx@!*Ul5p%
zGfpQk%7M-kNP2rO@jh<tPI!Zva#B2&Qe}6IFj54=3W+O^iOF(?*SrZaD>*YdE&#E(
z1IJ;01G3)TkMwJbG|ah!)ho;;y@s`WTh5=)i`+oNo4Lhn-iEEetQyt$_5+JI^c$Ym
zL<?ZEEw>(FZlIzqds_|y4(cPIJAJO@pAq{EM0S?}ou>z&uvTL0!Lxe;y9T=zy9XF>
zAH@KKjEW>v(DQ9I3jIRk?{CMlJ%pQM#vaJXVqu#bpi@JKx5pfO0Xa0b-ei|-z)8(P
z2_?_7V}KF_!IP0%BLZ;HC=~`(jZ`I|SViLoU3GqR!#GBDz#su}(X3gsb4!3irVOHk
zX&`HYz1af}j=<7;-r~1l(y((t?RvoH8$(h9Y<nqtjG{A<Z`B@`^MJ_}7_+uV){NMM
zt1!kvo<PV~vIf=yl#XIw05uDF2EgHw(yLf1!azN!?aaJrfm<@ccF>%{!LY?7Yhb$v
z*D?B-3SwR8%p?j>gl7b>CeQ}>j6%Y|m<56g9hiUK0Gw=F`60~>nT}90HduL>8~*ey
z9Pbd4^af2n?g%j)-RA<^LEaG68OhmJ>5LmNZix=A>rn`J*yfOCfRU@i^nf;l|K<$Q
z2gya1$d+a1MY1nbcW@Q|n8&TsqG$W?(1l}o4*w^7@wqRayLuP?#npr_ey_+=YH!`C
zM5|Mjuw}}%94yPshIByF_AhzS&wXHqvuR$Sv3&yAuYrC{QJEE7gmh{YDP7fnLxkJ!
zr6#=@Tu!XJ`N7qUs)miZvvhaTlVyM&j`Oo_o!t3}aJb^aS|j6o_ZsOHVCZ14?%uDD
zFh1`CX&sjR*nc?!6vYIn-0V%3O0L!mX*X4i#zMh7Mkq0Yo!i?=v~<s1I*nhdB}HJ(
z#5?(vq^pLB^Jb}9E&XUK;pE(k5BRl;Nm)&hz!IUExXVy|?(%liX=<Dz_f>Pn(sPB0
z@uH@TDy}6(S`cN&FFD{-4^gndVcSIa)|a#$EbS*~+2!M?I#7&<Zre1{J2|z+r#OPR
z9Ee=oU0r|YwX(>n0EU;A?;>V~9D}iN#9hdMTMvslNgjxW<WR=#$t~qo&H94%8UKI(
zmUw_HNiI_lP(mO`@S-D2YuouzT5<^dg`RHEEpE-SISQmZ(4Sfvoi&82q4?j-xO53@
zE`m1Mkd^mbWGL@7V??z7=!0fL42H2;@Y1YRGr$sQ4T~HOr(1_M=5nJ%v}a=J10?-6
z7v&cl(_cAd4hZy2JUS8`O}VRdaD8+bdlOW5L*QF^b-E0;xD{4^m2tG;_r<AFj5x<U
z^9=bj$(QrX`~alJ3)Ip=t#}A%ki;7^Iq?6mI3WT_yHUF*5+PQU;*RonD;1i)1I#EQ
zkd!N=2&hE`0Js3%!vGm}Fa0w0K}!^5)g-nS+X`&m&tgBs{tf$2>;qf`D%}v?ikARQ
zY!qLFFUM!`t)Q78Cc}CIP17l*-cYIyn2i-QbYasKWMs96t^uyYTGF0}(ddV%7YQ#L
z8rH5r2V)+p2n|ytP0%p3B@7yKc5M}ukb%sWa1sjen2!s!3p2EB5462^f46=FK?r%@
z3pGKd%_j7K*&8WJAaiQ-AJDa%hY+23QvxjfHer9>oN59BjSU`#66es-5NJ0@BHKT<
zY(_V(F}6}-{{mw#Z1!#0V%FY;&>0h+36w=CAE+T9du*Uw`~G03DZ@}p5_yos^H0G*
z;uUt23+7^!9s`f6WG|A@4cchbs0H?;wEep&xC~O5&^6F~z`Y_5X7h1Cpvt^H1kbRF
z9<?1KXlsb``W>v$=hsTG0z$7EGE<-s2x9n%ZqD|XLc5x`G9Pu0@@~M>16OI<ospzP
zfqZDHK~XbkoesxrTRMc?=n#C4`UC|0z<i;DmlbZ2E`ht1e)$1G(rDV};2BZoBw(}0
zJucSCv(Gq~66pcX)$V$Av#w3tDTK_#gc3;&65a|<nmNto2&d@rtUf%X=SPTa#K{DV
z98OAgsXb)o%{7L@7kYtoVw5m5($=daNT9cG1K|2}B2gXR4Jlp1IDui3$*7PKqeIqV
z%<l%O=~gDjxJ^isGab9geZVjbU>t-?_XE+TLUNL8$dGjk!cJKZ!^t*?m2}~9Mdor~
zQYF3P+$9hn;SJ&v>*bP68lxmPZb%*i^c@JJF&Uuab$e<suU!7QxtXdKi)q!8Aq;z~
z#zqQ6|7a-z`FHr4z`vIiS8A%Whlqy=LFB9%T#iHuR#wcM$}>4Y=>(Is49;WtgFF3V
znRXU5P0e9ZQEY>h`Y5CJ87?Nwm8)$XMr>oq%>eqoE<{Dh8t&<?bB0_#9#J<xHXWb1
zdiTYrCQ6;NQ=4LM7z_(x8KjeA6rhe4tZOKT>03D&4;BE0HB#H1#>Z-UpuK?IuQFIy
zIKy)>i;TD`h4vZErOB$uixr_w#0J!2+#2EfI%wL&$4VxPol}P)_JR`i_X$-c3XDUP
zbnCuLA(@}h2^L!pKYze|l!LNF(m?|V9U)o&h7-biAuECjxOfD2Npj8<fO4Aj2P%%h
zo8Js{4FQc>d>fHWEpbNmP=d@kAy+bow+2*KB00qcc7%9>9#TiY`KBCX$HSmeP&^;f
z+SDKp2&LRs-h@PQ(8kk2!-!}>wp>m#0fN-Ca*u~~Cn5%y7AT@BXVsEekqlq87-3^D
zHFDl1W1=wVlflYpco`;6`EUyJQi==cj;Ri>#4lT>aDG2v<r-qflYj_<nw&TJ44;9n
z>j3;^8puRhJ&|nnwF2p<I_i+pYxh^cZXNrlFLGUG?u*}Ex$@!GxDk(kGQOiEc(f$$
zbwlLVU|a?n?}M-@-h(?xK_DHtL!${7pCEypEP{1(jY7}F!NA`Y=lI)7PABl5OH;#x
z0#BxHP762oy&74wCOu$ySB9+H7|q3ccgTSJLt!CTFap57t?k}ShQ;Pa62|1*x4jS_
z?!~^KrG|z+CCfw~FGQ_R<8IyScVS<H;)0W9WIe@EbdcmiGLD;cKyLxm-F?;$@*wpd
zWJliG@+?F_zTNUa7zNqr9+Y{ou<o@5)%>i{6k;Hxz~jt-jlh<$^FF$!oJZ?G5P!58
zgD6HM<!oOQlI>{Lfb&7T*pjDt#Qu%MB^*Ob%fFHR_Ca(hB$n(AW$-acsK&km6#w55
z9BrUTR3}87K(+7(Rh?`y{=$ve7fK*C76o(8x9EHuKr&Y0*3d?S`VMdqND!g`W+=Ll
z%dnu~+WIP5F*k^#eYu=7;z>lxo?LER$&0mXZY!`J+^2pZ`qE;rrf8!(<3s+jh#w=}
zf{vSz;2Rm<>)jFs^$~buiE5e7t>2RG)J#7c^#`)RNUq?y{zlq;fjh7#(EI-C-tl~{
z;)s0CGt}Li^n|U~T$B^X{$YS28W=8vH^xUgYZGHN2y*o)znUHCB7_SX`0QA8kar4I
zfQ3r6ExX`kaz%ovS|>$qOEu)cWC&9e!SyB?@<#lJm|1iL@;#lk{KO9kOE1J_)+njJ
z4o4#42hgvzhNc^!ExSdsC&p0}Aa%qPaA{@4iB~-PR>_CC^*tXD0LDrw{YqoAm`P_M
z)s_C<(AyY(>eQXPf%BtRQQT3;CvdC7`?fBBEjh`{!)H!SguNc0f9up$A4xbkuj;_U
zStXcZmh3PTr<|5T-|H$57Gj}LYrZ?R=h{Lq5lB*LH_ay-Llj(pi5HgC@Sk=Yj6eo9
zZx%FyXRM{EMIGR9g6V7^H0C4}o)jDzCs^I(j=pTFG?Whc%zOL+=*H6@V@eSdGKPUY
zSaeM-y>V&z+|dSUq``yrV}bbej(dd1&oR=UT=#ZOJM`mJHrV`kmtk-WW83eap?^*N
zprs2q`Bnq=-u9Lw!1Q#U=NBndEvQr3YfRL=kh)|4MtvLU26i8Z1*`oT=_WA4!&0ev
zyiw=SjLiVTsr{d`zvRF~l}y2`j`mPE0P5RzeW)~6r+?kmaXGcJp?Ot)?mY+^(s8e@
z_doQKucLiY|Ca69N6nzdGnY-?9h(G)7-?=eh2i<d^ashQsf#<!fON=}q1Z4!ZMiG`
z)f)EewA%_e!`QnC{KwYy9Y;CUx*hNRlNA7!{1i!BgVkC;X;6G`xlG}Pr4{|yFMVZK
zcmEaCaGL}{SztV%7}@~%{=uhS=fi>S?&Xay@1;fqpY<@*sTH4WopiF>ueW~NHp`J~
zmn_*WENxXUH?tHLwn}(Qu(w*B`%^TCSq{U(BXcifw+&p*($+(BAO8~JB{}OR3ct0p
zbF#Z$jx0`<+{ON4k+oWIHj}gfHXr^WKg$!$bs+Pi@P5t!cG|}vZxF2E_QORF7)Nhv
zK57jqvq}Z&(=ftaV9!EQ0{KWlG$7>(J|h9r6d|yWmdmzCfn#>~fc;KjeQqn+@LtjR
zri$J*l5Xf-!HctXM;%?F&e*ypZTt5ZjN-Q30j13rTX2Q>Pf++e9P(CK7waznYqs8>
z&*kdFMmvUy2CcfRo3mVgWjo#<Z6E$<$LphOACiKjBg^QUc0E&_gSdA3k}Y4XVz}^?
zuHMb2o(Xk^2TyJvy=pb_(|cAH(gLgg9D5$}Hd8#mIA(%++bfpk@`<!Rv}#{?Ze6Rh
z_g&?Yv+M_IYwsVO&&|D=cZ~gBzyGTk^<MGEKO;%=(;u<EV*2BY*RI)Fy%Qkyu=lJ2
zC~_F~?)$5jt%=50jx8P{wLT+y``4B{qNfH2S1!|ow>&v_4x$8fiQBv3Yu$BX1LO?p
zWy%p;FGWJ#J5G+=y`%@z``Xu}OK~bzq99HOz~%S5#l}HQIJYA8MtOrnf44X2{mO-u
zwK)F!UT5a#_%CGlZ^z@xbJybN{foc{5(ZxG|AL<2!Md>_z-|5%tg~JP)aGAdzei=@
zHA9p{qXH2S&9MrBQw&%~0m*TGnu1<(ep>(*f+YkB-Gr`z7E1G@5RJrzARjcAlc`$M
zu5w-oG!G&R637749=>RG&@61L@F;l1-bZJmdQl82#N5M`=EH};goQ3-8;~Iu40Xr~
z>Rzxle?!lK|MtQIeFB{xOg#)hr-1PXhbqz9t74yLpKJF``*ax(zy#Pdk5yppx3Ga*
z@qBT(m4!}kB)~|F!dak?LP7zQ)|+@VT{guW7`@PP58XR5exqxlp@t5i8jzRCp6cz^
zHX8x=1v4*TyrBC*0~0nIaS6gkA@mBZf12wX!25@^d_X|3YeoYM{6~Oq2#4kiz~A$`
z_EHR?>cTO2p6FqqZ+kG<p&xR~n!4L0R4-<TQW(dx0qio(M^KD9vfcs8GrjTt$KJKJ
z|3R-5i(>>(<>aMQ+cX~}Yd3V`SV7~pfX9%SN_Vfm;dOU}CuXJ#qQOeeVpSnn@}iQ|
zzf&XP;1~DBB*~?9T}88GM3r@%WMyd()7_rBhKF1ih=vAW!CF$63_nK2>R-Svz@Gbz
z*+Ger&5p}{TrKtJUb8yD#2R^*psTyPInCh=GX5eC!JjhIsT2$BVl%H$K#pM+IVV>A
zJnqTr>s`Scjn*k6D;jbei|BIj<g)c)CE7NX#T~pmPU3%lLpCv$P;SO4HYj+p1c-Ho
z$&$rVbO%Jj`dFM#MV+p#R8Lf;x}UY4dhDXBcc*lQ0}kr8*2Sv?Culh|U4~q^+!wH0
zzWI?`4(X1?MkuG{N&UL(bYi-#For2PVEfIKEW?uzrogzaUwac+@2T))X^_whfL5I?
ze=S`q$5Q#+S-QWgcTbl#cJKsY;ZcPNyzGz}n&)MVgsDr4F9Rq}n)@|N^iE!As;znX
z%_FC<uh)0<^=<%r60u(yRLG8^r`!Kse`nhUGeM|@E?lcH@YErOfoQ7~Jd^vSGC^gR
zO-UFhn`Sts>eNuEfbR!vYJUhPv+V<{rkmI;8`#iNhtuIEm|UbloBm{`?CcO%P52a=
zSJ(IT6*gVgxpfl5Bc%`hD?S$)(#?2L=sL_gN;si=Ps5#-ulLmh^Z=)>WK3$^7Bxm2
z5dzS+1Vi>Y6t-JVV9By836#M>FUw{W9pgW41PM>l5fRl(Jiac7XU0OXil91GJP~U(
zU5VD&L60(^TpZNQC}~7P2IoDFIY?Z`SQqJ4L_wZ=R8|{wiVlN+MfLO2XrJjnNf%{x
zSd}~EO~r>p$?epznSiw%JT0+I5S5)L0}lY+vXc~fA_%Knr!{r?KKxxxr5LAHvVN#f
zP3eV@&mVe4l{piRyh2iAQ^3Op!ThbCA0HR~p(~qO88FEyh_pm@`rE1B0Xp$(z$)>R
zmVa;g9dzlffO&NYI}Vol8^JbzS99HA4|b4R^TNp91t|f8bzVGz3<GIkTcwcnLmNmG
zH1fgd(UiX+G?2hRBE%M5e<dD-fC$r;Ip}K;j7eKgz>e+yYU*W3D1$tLZvl!P39I?)
zZDY=P+Z43VHtN)o$Te#7g4PbywA%tp7Ptu{dm+RhE`#JS(%Eb|45>(9bOC`6R(7N#
zKr0b%Fth_LKG3bhC$#24;t`G@V?Epq`U1J*nokE6Fd+#F0{rc@4xDS>K5aj<=97Rn
zBXSJn;(+B0Tr&jz0r&%MKO2b>wF^1i(F1OpqoB#Qc*Igr7PS%u+~4jGW`=qS1w807
z{6@|#hCSx?wpLuDho;6c@hMyu1CW*?2(m6k{QiLI>&*t-)@+&s>T}?o2o_?aMx4{`
zvcB=;iS4tI3ahYU)$0X#>#&fQ2nwRI{0Yj16BV4(fI&6tmSd{VBb(&9tN`H<D<2Bx
zN(M-XA(i&h&Q9mQEOFCho&l|)T@!T%jIKPRNdk6kXmQzxl@#l{o<KG~9L`$za4t&W
z36%gEW2$k$=k%1OIyeF6*#H3KYm!#1nRpG>?3}7#hDx|E1|TOqC<$qN>9T2(cZp`J
zS5;wEuRB6UnD5eCm-dhBz=T^^H`6Ys=17JiS#~q!rc@<nJ(Lze#B?lPws_ggQotKb
zfDz&D{?l6_@mM95r2$%zQpD%llIii@UV;uB2*e9D02Yw?+tb%1snM)>@fG`d*Y{H!
zR+h+s-#0eCvK|2(twF^%)R_C7P^D>qi1i12T|22^yepTSnv`Rng7u?aE1z^%)My{;
zHd^<VX7ofP;!I(LpA0$zKArPxUU!D00v-Vm6wX4dp`flqM(QA8{9|ujk=Qmuau{7W
z7w1fsg0&RocVpi>aNO7C>o}WFwk^N9X8FPcY=C7NM316pk|A2Bz8oWs47c7z4&I;|
zUZHfx)H2-!U6EYVezFuL0eRl3NbSz7BS2!p>{)>oiZV?Om-!W|SFlbahh-DV^o8A$
zPd0*-Vy=r-$Gm<_3N`qk*50oITR2$iz!((q?pd7bXzkv)ZrSST@3|6HYG1L4`ACIo
zQ$!}=0xZ_$*6qaW)PF$KL$;;T($jJ=@S`7VxfYnbZw1u7k3qgCXn4r|g*I@<K}IK1
zMk=;KQVGM*0uf?|MA=F^c%;$S4dlIVeu4x@7<r&Egi~OPK!eOaAF*Q98+xUw>cbhR
z3_}6fBN$haQ5Ae{_P|9Sk>Ub4{k4dWOs`B09CWtMpMoRksIBH9fkV6=xf_>5pFVu}
zZtKPn9aVZoWB0Np*kN*oQ~J`ES3P#@`16wG4iy4kGp-wcj~D;s9`f|6gVuXF8skbq
zR^x;=NH7uUMTye#1Fji;NLo8QgdNeH6DvZKeR2OS)IfVVG_d+G_Px0m@wpYD{?Lds
zTJ4>HJ<i&7$<$Jl^Q79yrv|jv>TFlnFV_~Z(UL@mx+;F-qfW);oV#Y=!tB~#3=Qq5
zZ#O&NGUH)+ZUvPz&F_1oA$e}Hjg}HC5}tjIevA^g=0zu#u3T_9lIau*az6ELr6Z9b
zMDnr8$uoUEkM3J4Is1G*H}EX=o|&9{|CiI#NBf4`TrT76^z@;w&a5G01R_O~;axw-
zd=`8r{VfxKp12vi2-}Ap1E!msuseVP>>Jp3upc1gU3d>D<RDqoAaEIWnv$^rd@5+k
z3?w`-mw<q7&K@v-z+BRF;DVM5f*!e2LDZT^Y=a;~0o5(`D}-|Jl6Ct;TWOuI8^k%(
zsG~^+B(BkCQ+?DM&{aUp!^PqCqbATLTau&6!PfLq3mVOt45BKauK7-i!ZJ!|W&+H|
zGEnA#`G0=OfgE64W1gS;V7h9y8~Hp;y9rIxSyQ8i5R!TAJBAtoy%x<-u+7Keqi^kJ
zU^fdr5NJJMJHi}<CMVlzjRIHfIn_SVPQQguXi*ARsv`$8{I-1*5FZW?51}8xxkgF`
zC=>Vq1!A=Z<klfa2Eqh}zsLh_&$I9}k*Bu-)2O}gnr|k0$_C7skYbHag+CSMv+cPq
zX^n%A<bPk>Vz$LFe}Hlvn(L3Al&q^du+4buw`dXIT;)JI82B)j8`@0r<byyd_=V@D
zonqjFkwLjGNyKkBiT9LhJ-5DV{ca7-x!i(@#enwS1rUs3O;9A7@cA&EF-ZX|Lzt)l
zU=~=tIhKUX+J?w>^W)?&2@n?{+LSU0Nr0$vS(DDrJP`7#)(H{tsI=BVC-21>2Z4o2
z2+4{#<%pals2&Pq<f0Rjb7h|_sZNLqmB3Sg;Q-PIfypUK28#w=${va_&wyuwplO1i
zV1r<wg*i-gvntO8*gT=S8G?S$%*IO)p6tE+gWn4xg5XH;3?SzNAqW=j7j>K_5<ny+
zOQymWXj(I~6817=doe7&ULnD=LK-xE?*EKYQbnU<c!V>JSVZ&)3E@?-BtWCcAggpz
z41t3uhUYZ_=4!(ATS1`OO%Ea87iVP$u$)CiDJM;JPIP7YP^-YLf5%^EU0RsRe-eM~
zlDkN7#A7F{`*G<b1TJyOVDK*M`{V0~jr(5s*Mvc8beiFX9HGwL;0C&^aP;)gG51Pb
zfrL(qPYZ<M2niltiUmc6fY|96j&licRzP?y5M)8xrwG|>JPvq5U0n%k1~Tz#jFw@N
zQPpfS!WhHfx%|_PWJJbJQ6dloctgE_nZmFlI8S)qSH|P51fvBRUL`me0GQysN@9{j
z6d+FlmP9(|5(}*^=`M;+;ztSafTL{aZjNyP&=npaXa{RjtPqZ?1mrw#8~`{=DT{}<
z;|DaC8w2VO5uh<?psH!eAy%ehJ}2RJ7MO-smc+R?SzKhuxqWW%o<KKvwVPlBpFt{o
zTmY<b&ZT+YkR4!kWmv+%f%!&OG4$C%14kl{F`zD4?=gKe1<DF8x}IYLUZd#Aw9p_Q
zUuUkO9%%6aCrG7bq-9mh9Zl`JDOpfphdp^AlOhaOSTv)73^J;zvc|#S4F^CT+R-FP
z^r1L0djrHov=1ebu!Lg?+bGtQtw^jk%Qf{^+th%Hqj+REBS_dz&iOKR=Bh`Xb8kI#
zG_(5B%L5-dbNwCsbNJVaTld`f^tG$3&$gx(U3|fFPt`c=eGHp0zT{6Smg-95XGuBQ
z|G>#Bg$?)iU8V$E=cd!vv*q2fXjxKu|Ag;m?B%h~9_hV$`+Aq+?4BTY-*Di-ZpYFA
zlaw~RlS&m*oWd<<;vzR&J{B0C$R+#rV_RPhH+bT`<DYQM{qduhv`(!*eDtnYZsb0R
zA8cE>@)JA1F0WpE_iY>-{Q0ll5SpB}M)ef70*Kzm_uP75zr5;>u9IqOpY>#i^|RtC
zmn)#jX+E!<S<-#oeY<=1FZP<+B8NAOPhEfTz&4?m;MRPvHC+V2V0ybWxUG^2U6ZLP
za=~$M!xubV4m)4@92=)jV<+&>;Ge~x$6v<3i@%Nk6#qQ|hAOnES(r=UE&bhR`!(3_
z2Oc`IDWatUh+c4=pa}%Z!hcvO{Ox%F9A&>xByAT?MQ;q=*ZeL5ywH)Y2CaVJWSBwh
zoHWgTk#-~_99k%VIzUpl%c2Dp+R#h@(?tW!U})yCbK20X45l;G{pJlp%_-1c=Am8*
z-OK(G;n1V6kRPczRe`e_W<<Nj`BQB}82StqqG(B@F@N^_;t&>3Py_IIp^06Gs?drE
zKEY}XcF-vcQ$KnLHTW7ewE6Wy)H~X%LM`Yip_vjrNju1(xg2XgSWxKDyRl!9?XE)e
zy={&|nn(%;fjt)BqpeY(lWbd-jUrJ;-$P667|-+Tyr#7ehicHbx(2yo=w=p5#q7pF
zJ@EXYOmlq*`Dr%MHyD}W`P;7%E%M+A*>4AwiiHiZL*YT3e_H6FR?Z(VY{oYDvMD9t
zQGuCr;Y|38gu=qfe^&(%#x5KOH3BAgr0&imiJ@Brm8t>yg#FRhBJBHy!?wx=`u2Rs
zfk%jL)r2+lc|bC_CJV82CKY$`2|n!SAt(UmPcA6a5iw%81aPg3&LEAa2&bsHBnDzj
z%^aJT*8{%1I$`eeLOP2|DHP*loIxMv1yWAD&m7@!M}X6*GUy8_pqVE4bhn?93WRqE
z!psN<2k=%Ht!TR9)YCm4sziu5_>~h<!ZFBD5y+duVCv=kiKJWD9CRkL94P>BkHX@r
z;_;F$zY-!rMIc;`5T;O6A4M3PqOm^O1KwtEC3WDcQ^Q1!!s86#1Dp&JBP5Rkb}pQu
zA#RBCIti#MKoh{3%b8FG=J2#Tao~3C;AN-UiZf1?NP$lbu!khsL2{6JWn#Ll;XYZ&
zc}kFKEIBZVl6-hj<=q&A^R%Rz4q4)P6}TE9T)}C=T9zJ&w$daplMoID?2nubEtO0N
ziFHsACJRcqPK(=mS&|_%J}TxiyvX|qz5-Dq5Yz?w1;8PLb5W(*C77;g0@AcpLV$@<
zNXlLolJQ*>rIW0Kh)ewxPD>%DUvh~A7#}IfonxGZDY8|Mf<j2cnF252ybDVEz3>w7
zey6V{By_MAn2cK%{j>t{_JRR1Ub%1xu)tKs>DHtShR1-4lBQJPyrrCiNd$0s;VMuM
zNcFjKoF=gc4VIbP;ijBEp2Y<hE-18Lr13qpcS=%J=iD&QdOgr~0I!@Roqhm;^jJaN
zp(QCmGG_b~(N4%dlYs21lvD8G2`{KcqSrL3Rbe3uVS(+Ja?i#WF_=@r9UQ0`ako=R
z@W6-~0vb@zGXgXXolOS&EYO=#jK?FF9L|&i$eS{&s;WYfE^vJ@45Q0_KVSCne#mu;
zK&QZc1v=J_ryQX$ANK*QQEYrVOuVQz`k3$lC=4Dh%*I3&bQ&QkI7OqNWrAsn=`C-S
zg)YcQ(IhDl6%?7SwlR3cDdSF$?8TJ`kln#>aEnT%p)n$a<Zhsayh-A5#W0LOpjFu<
zY9`m3p<dVD<oxO}!4Y!LdI&6AqGX8Plfwxu2SMH$DvAqffeboH2QW*x*bs}U-1p*!
zXwn*`1|go3kXcb3Q-gx+R#Y>^cnvR3k2}^@F{%QO3iLk0?V>q8)>>s$AU$#!*sGp0
z<M6j@Uf=EJYFCK?&OlgiP_3fe&61*l5i*8Ryi}4{#mSBvU@uU+lxR0W`B|Np8ZzZ?
zA3hDKU00G`Cl3)930{U=#1J%8)p&w{yvD4<A>yJ5zP^}~R@@M&#H%Gf)stezOhNMC
zBxv`b0WJ|adXx+~AO^|IOOnr1a0HDwIUQmm7+{ZyPS(l^0*ie$7-Z<6P^27lZw1?3
zSjf@EF`srlTa~ZkCGdv*o*ZE%`OAW|p2bOjq3u#JJUBAC)!fbm{SY`Lm?o2ui{O(2
zzNh8Zb<B@w3D6_WmUK&Z%T&uUz>h?J=3Nl?d^uP+Zn7;L3mIe02^Xec6GSi|hQXuy
zyF<23bp8mGK&2KA*=AO>4^Ows!GlU71p*mNAsGiPIO`OUOHmGtK>FgsH-B3SfaB0Y
zkOD9DLILvI+1A!#D45Npa~JkSa~(Sf>4UfDK19Z_FEvIu)9>~8M-uK}bmW7>r#_^m
zhq}53myE9N=vs5T_5JoCo*k(UrA$|02>(MhAP}wA#BS?hzp~ULtZ`XAOHw>55Z9dh
zI{q|%_1rHK&n&{PcXBldQc~W3w9Pye7mm|z%mXP@_`7rOW1pWZm~_=aQy+(wb*flt
z%cV2b>YhU3+yfuHjbB10-~VpBebgBZc)a28h~H0swCBXlmC@0zuEk@ct4Bu8y%uX9
z*5rvsax@eocCt|cn<Jps_lbS-`cNd~U44qH2!!;tb6>yy^NXHI%>Ck*Y!488$sJU?
zdR-w`j-ABk%7h69mREOL6U0`w%Tyi8fStE<ihhK8A2jx&ow3sm){RZT-}hWo<7+C|
zw(ixOfZ-J)`x8vSk+N-IYR;4fmWY{5Dh5*$fN903ikX7Q^QLJTPHC$73osEdvB$wY
zTu-51a()A%hWY++UQ4hqiBuxAxggmPIrN&P7V2c^5-29~CWU4b>+~ac-SXUrUVP*D
zSI^uDSSTCM^t{mBwY7t}`3eRrLm(RdqfpO7J1*$+T6?Uy;!Pu$Z@C<IS}(euw0>N)
z-hcEbF6+gIh?@bAKE7o6x~E^g;>sJ>{O-YB_q&VR50wsK=JRSeKJD@)mvnnedT!~>
z6E5q&ZgW@KGbK%$Y8zw{dYiZEZ|_;XbeJ3pb-%VtUyt#4v_3+XZg}q5n_SV6dQ51&
zYhdrwM;FZuRO&r4K(D^={F5W~`pn0l{@SgRfzG$qriX_H_wiDix@3!Gku>=MZ}cA7
z{mdd__*>ti-*}_)jD&stTfcthD|4-v6{Evj)@{rzkGBrLVBPrer}qx<POs96$==5F
zxTABXysIF(CC$rIdjs|Q*i8SK-t6^D%alt3av2VgYB3kBPFcTbKg>hCL}!Rxd|5jY
zoSEUxu0xaI>Za=-57k_HwRLc+JPEQP46@-_mZ837TRiI^8~P#7Yf;N`;G){uvIh`m
z4}*L-1xz`}3VIi0NZjA@aLZ#h>g+2m-vPYjAKJW-|GCh^!0-fmr2X#E?`HRE_5mBh
zzWMr@W&xuBIiJ-OXp0PyVkqc!@X`s&Y}67F2&V*!Md(pBtX#c-5g=6zq(-8m1awG<
zoCW7aDxsT+X1~J{W~#<uDaHjkXw7a4C!}hWNu?O2x#nc*FkcWDfs91WBj}oqI#z&0
zR7j%$@{O2H>q8(Fxq>MvCINmP6L=}+2S+MN*tMrvW{tCR_@C$gz;HYj{Pv@te(hLM
z;=OKPcJGdnt>1`I*l)?`ch-0BI}~5iBPP7%Y-TOcChj`6LN#X&+}Vi@S-%vH2im#c
zSs%Qev7WJpt!J=N>=oSODTMkMr-RK_m!7zqbD&9PV8uuO^cFV$gmvAE*lR1KRU>5B
z`p#q6m*QjOnZmlcpIIN|CePrHz4fOXuy2ZqkjoWHh?@w)X?^Efocz#d=91Y=&2&bt
z`E%!;2e8+#K6M`*!QU)y^;dPQbF1If=KgyN!3Euptupr;!TP1U!{2fIn5hycKJy{#
zkLxGgW&D$WazS*Nr<D0hW>cx$S#aq@{n##7*T}!ly^UePw;q4|J0I>WCswx(bjLe3
zugeV#i{eCga_f%rZap;-O@=~OPd#|2^%K{zzf2Ee<L0~19sDuo1lFh>%m47g4L7`S
z*4j=wv=mnH{oHy9;_J$oW7{jg#h!cI`l1kJdf)l)U<?<rz7yw&ukHBa`*%KQUH9@f
z>xl~?5{_muW$4fE)Jj^#Dp67>oC+tWu73Vq(|XSOBi8rxb=D6Se<Zau+15B-nCi!h
zVUoln*qMW|Dg^}ICzQa7bDzP!ThaCpI{dXcZy7t@-#=BzR<ds%!3ekMg&=##iTq2A
zZ=<>(^3iOGffsTLxF8O|xcC_K{P_$>lo^@$o6lIaB^GVbHIx^LRwZa)G#9{NwFNr+
z`L9qIdGiZ2IFKvtuX{k{4B{4Hh1hc;g9emchaIqezPh?S0XLU(XxR$OT>DQI{_t(q
zjn<!GyAeF43~Yx!2>#zk$P?B#-gyVm={w(f2kZPGh(#lnp~V$xP1cdfS^x6f`LD>9
za>oU`Dh_pcSHa4cx>s$hsA_d@{!Sp!^HK?)NAyiZcJ}j|g>$D?bsqLIHFc&zyXg|P
zDDOV)^#EIQNyUal)8+mDn0xQ=xQZ)oSaa+4-MhW_qTSVMrCn)Pz4u;iS(fB(x!bt+
z-YZ}*28=PybTBr(69OdkP(lmE5CTa^0TP0d_VS&%D;Wa`@AudHyt~hBbLY01GiT16
zIp=r8CC&kK&xP;B?_+;_nEETc&G?(4FQjUz)1MWuRGj{JJh37k$cpAE@>J}$m^T!Q
ztD-9QjdCQjSPL1AE|RDyDADLlE$H_A`aFd+cN)#tMb$P}3sXh`N?#cX*1ky$>Vy5j
zwla5tjC2fUmp?&e=m@$IEPMWjz9o8zTZvP|Bg6~DyToUJ=%XcFq@RqENwS=5gW69s
zAFP?j{a<<%3RS^^B0&H!6M8w!@p98Sg>|};(~J>R1$eZI)!J#@ioi85@CC)(GLAiE
zp`L+8Ks%3lmH{gu@KzA3;0%5?=oIjH7qGR3Ibc#N82V#YmWL;+1bu~|`5D*a<2#IV
zOU&{x^*|b?SNt&oye6pSg^8yzZjNC+@u#N00Tcr8+QOrS8-wm+Ot+BsoDgQM(|Qtk
zJ**l?yJ^6OV2=iP5YRi;EC?SnR*GYq23({U-Z?##hq8qe@S;#0dQiLIRQ%RZi1;pP
ztpT2T5Nbp?DVYB<Y#MkpIsWEQW;(bP<P%)nm|WNg^#)EBK0bX@_&Pjs4v#CwCX?W$
zA>0xdkx*ZPPDIefj4564b0G_8%iw&PCJeZk;l@xs;5w2n;`F=XHV?<xCJR@yACx1Y
z;Di##<&VoaT`=hiz=Z)-E7&WImCTO{8IwTz=HtbH{e<y7g*wIhpgiCua7&NyO_+fQ
z1`NW@pzjlE7MFPX0=QVvF@g67{@n9wAh-+)33^|6btrYA{>MHfp@E4iz!L-Fz<Mya
zF~p;XY<S`nJQwi}{-(5(KHjDU2BFxYD0IwS!+kJ$Tq(_!wHP(kbxr^{u|%#_NZfI~
z*>uG0FIKt@A(_=xCX;b0t=-C!1v0}92%}st*%y+SW|$ayH77UAvSw<%wrrVE<K`-#
z7inq~-ugzF&&#TpFmiuxx5zHG=Y_)6Vu;1PbRk;F6w43C^C)9Zn_gw&GIRB;1p%a_
z8gv?z7yyDI1k5k*6k81n#SG3`;_1+7BDvBSzrbb4Dp85NVrMa$YxjAKcAZXP4-#4j
zW7H~GFp|zy<pBrmQ=n`xiz)&iW4*y-wdL2zEJXw*Zb{Gttp{%lN?fj0@}EW&0k>8f
z_xhwdk98u<t*bbz%;&Nh^d?E2&nyO23xql}%la*PYXNxU0<wizZ3QEJN0bhzEF!U@
zHDt&^>lB%~0;^Q1lxXTz%;?;~5{JU!)>(Re^+@a11&skQsfNfHrf?V8S=z&fE9~HE
z%;~K;TD02VTA&1<>R$5*-((~w_*lEoZy`z7d|kKB)uJd>={X3;z*(I^z0;PNrP4|r
zvIdDytYFKQ5qg!#st>?4l%Ij9>mnyW3^ERnTTF-z-a?U*nXND8=TxYi8jV?DXCwgg
zqf@CXA&w22U^ZzD7jsIR)#h<~22@gw-zu?zrIbSJa@8nZQklk6!|7a%7QHXh)FFji
zTuId@W3*o+ONyL>to*NDq${wIt$=?)pf4mcQfGHKOeS-xM=H{RmL@LN8FKR#Vhu&A
zC}W|i(g0N<(`+<oe*-3O+q4=YTTN<Ji|;w9Q;X2KungQk)Ctt<2s$%I{}~8GTxf!g
z;LJ9_djUid^kpP7dy=Y<P|7N*q_QTN-0F)D_d}#jxg@_Mo@2G!w~M?9ja%t4gsml<
zS|82QgJTf@QN=y74N|6oHC-1Lk@b6ZZ7>U#HHS4iyle|h-RU*^#B*z5UI<WbIIAh9
z*PDn4cy&u87t5U*U8BJ!Gqf1X90TB((Ve4mPY|h^h-ws-x<Sc^=~d@f2TA0R+t?hr
zT7#!f2uY{~;6uSi-H%j?B37HJlH@R1DSbB+Q<xPhi9~M9m4Hgrt`yM{uXsiSCy&Xw
z<;Gl6;~^Nvj8&65z$Pj;Qqwdvpj}Dqy>cyJ@~SjJ^cG!2k~)h*1RhxVfO@UfO9RqQ
zQP?f<Go}UxY!z)tOoKyY$gU=2wjqbzN2v7Lb}j2fIo{OUMwbYjr_^3EX(^H_%zd($
zI9J5F)W)FLM?mbz(T5$`Y&HNwu`EFN00LNZgU_sL1hN58r$Vt?%d1pYzg{=X<F!L9
zo8^8Kh}i>G5~*2BnOUnsmnj7oDx?9L@zTo;lsZDSf$9$ctq7MxqmyavQjW4HJ!o~d
zlazuLl0gRU!Dg#mDsI&few9pFu2dPVKD7pXS@jl!vRJWz_Dao3Q#5k|L)$D;nc1o&
zDMFm;7Ap$!2-UpI0&%%q!x;yCu2Q|m8I>nW=_a&M&gJSrr^OM<gfw+7SEK3nMk10J
z$%!%<MH6GwQ$a(kCMu&Ujo~`IE0`stb3^<w6T#4c0~G0rh|GFL$H|5Q`blTN&M&ij
zd@8>sz*kEYN~PS&A|oZ(D)S2^S%BezrPXLgKE#gffat<&U>tV>MsLrbAFm0W&RACj
z+!;(5E|6e<B+Uw9M!Hi4xggz9{=XsOvTc()J10hRj!w0f<m3%3Z|<8tIT0s5_^Fut
zbHNvt%q&*OGk+D2)QA0X?NFncT0JgX{@)da>G+hn9UYUphb|rPck~VwmQI;cUOY1C
z#{%(B<YVFsS)Gc>(OU}QP1QxUiN=W|w*Na4vmNB+&FpRT+kl1{0Kb(kh)cQ`(1C6Q
ze~1S%9tT|fS0JYRpEACH7^UAsoV<L9o>2$B$(>*`-w)O{3n6~Srk~OvP@f<qje$x5
zWeQ@3ATwY|f*qq(oDa(p7p4iMi<1RI`yXc%U}#uZJ_e)-fQ3mK!Vn~)IOw53`bu~V
zI`NNhH};70Bo73S)m0z^rnQrTga_fAu%;43opgJEcN!CgAnS$6*r5iVkiH1FAe>)^
zWgm_Wa2k{!&-a5R27C`jQvvA{CM%O%db-@82N4cSb6BX4>*5?d5kGePHi8HRavJzn
zV*^jH3I$YoSYh+fd|e#0c)GOc4=Oq=&B0BCkw8M@$&a(Qg)##nfX?>&LIB@EW@?>N
zrrWGmuq10Os1KTr(VEm6tJUh%Lzic<)rU<kPaSH_4EQ5vBcQB>5@Ef~%>?rYM;>XJ
zA+tol6mNR5BbYZtJrwNW|I9x*fv?;tvtLF?C?g${0%Tlap{WCAc2qW!C9WFDvREx{
zgAN;fHe?xexwZ6FK@W5@vz_8*9otSRo5Es|k$;l3X3=6h|0lCSBqu64WdX;Oic%Xn
zxxvX%XtF`wW?(uch)X@~u%ov|J`wUe7a26II;uxZeS33aChzhZw6mR+5bDVUAkVx@
z9h~0naYtMdwUH5JPF-ZBYu=e_8jV^FEZ1mci_}zsgji*EY6^Fn8GrK=hK+IW%8hp+
zo#|rQxhsM;Kfh)T-Io*d2f`5h(jSOr&B{b(d8*&%vRa%TQE!>A(GHHNK9|Mf@@E2~
zuiFa={Gr^a-<OpY%!Viek#M0*t`5Ih)HYj}mF@TEX3YwRM;<cA_`X}0gQA8p-G)}5
zU=EtRk^aF)oB1!jpj3xZb36Kj&uKQh{P^Z>Z@t})USR>Jk<*EKO)jZg-AktKm8)qZ
zs`ioKis&Luv@G>&QI%P(P&W__qD-R`z>?efv(i4h)nJ*J3ZpejO*wxjHNi)*&;?F(
z>ndgK=SI=YJ{>=k5TjZD%mcU6J*)nqkyCN<Z~ReXq%QThNTdkh6%beiaT8~&(G#~3
znmQZth*-mNB2k6bs8ZF99xqdJL(@>M#(I3qak2EoiB&6)qS=pK3_u4axzB8hSh(xR
zNwgFKckUwhUk$@?(6V%WKL|08uLI4C3P$Hvz@MrBy<`X2p$vjuCd9SEZ9EChSBVH;
z(hh1*T9}d!fOUyxTo*0y0b!7X8<5b55Jjf*;h~A(#0f1L?v!4G5)kts8rmox65(DB
zw>|dnZOqE$cV|AZbN6)(Rs31siFb56_-_NotFP5I@sDPraBXe=g8u$v^XDJy?_ZE#
z+c$W_Ll<BC&<%rqBk%DqB^zXmS6p3i-Ifh)TX)|673F$=UgdiV)5}jZQ;{RPLtWNN
zeqs0U?&i9wp-H{F%gN=M(+BouHD+IT;|FrI&{SslHWj_=T$lR#lXf?MUmfzJEvr^c
zUeGu3*gdDNnb@~r@`_bA4KFxxV!<%d+xesNtG4XccDk;;`YO$-J5IU2dj-`#zr_XU
zp2=6=@(^EMoZV+E^c3{>>|L{S!|a`%?NHuyMhAaDR7BsGp$2}Q0~SBk=eaY3T||9Y
z{R+at7!y8UrZC6IVpb;<8>nuD{R>J?R5Z8qrh^Ap4qyK|{}!sAe*deV?AS88sj2eh
zdpmbs(>814_CMZ!=_&p=y7EclJ%#?3s|~aAC!gj&DCQ5&So!Fj>AMSu7e7@-p1kko
zZHHH_nza<&_dC>5iuPS~aPN2bO&s|CH)~cO*?RKM&-PzBgJ0gxAAFUPqpbr|{Z)K8
zQB71NR$lb@L-!or|IFI0VAIsWuVzm%T9ApNfNWQn(F(NmlQ}Pe)22W5NBzqM>HnQX
z{ukw(S|EFTWoPHgC!`Ci>(=dGxN!fvy6RNsI^|ot1_pM$rCit2vH!&S^(Xdsw4gUG
z8g`UxWBe;+?ZXB64UX!H;W)p2>k4m!p@6@szJEn!Nw>G9X+;tB?Z$12$5-syx$<$v
zwv8KFyVk7fY8}lvbVU8uuA@hHy`?^K=uqF_-o1l;<f(<8YIWEgswtm4ICHRlc4_hG
zm+LcIwYm13*2YzHmM`dAURMqFuu%W(Df(Hk_wopH0mVQ8%^BSplL1q5K4?1EWo$cN
zRt!l%<AcA@I>2oV2d8DD5Gl)nlJwZtH?{@Mx{&_=cRPOl|H{vvn$~h;<HpyIAAf!0
z#v?7$)`6{G#>+3Gj8C_&yZQG9<2!HI%qSzKQzm0tJwG{W;PUb~4%H2tjq~T5OsV+^
zr8$}eFX094Mq5jp*^+vAkHN5Kx6zEIcbcs&-NpcFO@OmYOs7NZb{I@MHaZQX@5MP~
zegqo8)!VJ+ZJTXIbP)2y<7x$Y{|zTMU%6)OEBpweUs=26%FQQl`26CdXU`tJSZ;pf
z4U_fFH~*|k#I(v}vQ<@>ujS&o{0-&>bL{rv1%y!(E0k$tG5#rYTZaJ_w9K$`r@^*u
z2mg_^txIofo5-Jr^Z4pd3_IbuySEWeZ7f%(%+KflYTU8YVBEEhpNX@;l5WRi^%#fx
z>&lq^%e981`atU)=XbzQG5<S1o%cg6kFihRf2aOms+3O#XWaGlv13o)HDmCo{reNE
zSD*Oae)QD^ng^D5cdd9pv!JSe-M&SO_N}Y0;zywY)X3ue?|x_idB0G;{6qIFTz32I
z%NE{q_ru<i<Ig^Oe8l^3--hjm`<Ct5v+O>@_6=iAWAQ>ygCt_YjbLDw&<KF%iGb$!
zLs^~6Ai<+k3TT(1jO>gUlo|9cfn)#{m<3G=f?)>h#|lNDcYp-L>><q}#<B?6eke!>
zkS=C{xG=|x6BMea-KB0o`E|eJE_2g=?<?8C|8@U<{;xYq`kMJj4f@@*gZCUbaL+w+
zW}J)lmiF!wma<-m@YAyA#PQ=NX4l>?Zatk_6`R%7y>V!0V|UlASQWjnr?gkqTh{vy
zWKWs*?HSm{|KqdI5Vvh$&%UeYqc>{!Xxq-6t1d!+fT!+<Wgomj>Xm)HlTV+H-`^rS
z({a(<g<Uf{+Bfdszp=ezW*2m=(hGQj6L>*>MiKPA4S)mM4G{%~ewm&GYJ%xE7w#xv
z1y)xsTox`tPG*ry54)@j96ep&g*<kYPQufG9w@J0qNR^!Tzlm@V!PUxniHw2ilpZF
z)XYKp+&r)XI!26qv+l}kXE54xs})Wr%UScC)nABcFDhI*(vsImKHRu>^f%jxn0=6M
zsf@iGn>EJ@!G->J>s{2}|71f!R$E(ELBo+qFc{GRLzv&+&sV^2b4fKq)!Pf}>vwIo
z57m^EtoL~#h@kj_vU6u-0zDPLTu}{3F5SOeZctj#26NM{_t<(LCGZ-zzx3Wu*Fah@
zO8CXXn#xQWzF&_n<1KYnM3t)|b#pjLEQ(A>T`bnjZ5&=h{;FiosJy3!3On0IUQD>D
zEKkSCrzVPg&)GQIX}G=~$=@Ch{z3`8`oMw}JcmA2W~Lr*+DS}u7pD#v&L@^g4I7f}
ziqX>Yh2+<?d*t_y7Ah}XGV-RUld{wejC#Gj<lVPD(Zip6{a6{m99&RlH^AKT89*<7
z8e;KcOp#9@y4u$nBVb1&1qccY@_;Kq9FX9uVJz8=CWHUqe1u~$ZUg_n!{};s1G*iZ
zL67`$S(5;ql%I!9NEt!B4)eQMa}SLhWJ1te!<;kL)PqwTsItMrPzaG2kEQcNh5V3P
z*n|A>1kUc!W7Ys#@3DqIwlA=Y^sHT)w~p;+;P^Fo_;wx<WbD{5wjI}$k01YZ`@hcr
zG=2Q||CR0dcl@vS`6UK0og|BjD8qi0r-+OdN{Wi;yc|(3M0(Dl;6yRfS}a;r3|YvW
zh***<%E_aPiX??GvdE*_Z=i}mO9@!?oVCc{u26{f)QfY93VaTgMx%203W{>X^?O8$
z3b&!i%7F!75&T}mtGVY_{J{C$|DAY2rt~f$$5;J)|K}+e=1iX@@A=`{U(PSQ(9g5{
zLIdXiUQ|N7Jm@Hrh-FC06&1;(5(7ZLN8ypA!Ra(WnHEKzWR5{1l@%3nN(8u~MUKIj
ziISq%_<!n)tZG-8NU@_0N|DG4OQqo~0!p!MheA~5Qd^5anTTG*uMfZP#uij}!2wSE
zQNsBHVJEe7{QM7lzkFhp8NcFx<~#q)AMW`hzU_h$P$VNMSi-dapZGTB&tM&L;X19U
zf>beP(8&zw`*ZMc62?hC<ozWYzsj8$d9l<(UQ^RED%UkrUsI-$PfNiCcFl0(T(Kr~
zv9p9;KiXLo9DW<g>#rZt=<gq%!Vni#)$taIi+DE~PTlN`{6e+sOTr^B7JI1s+%!C(
zk$7^TZsgN)FFjw;p4=eQr!MxDqu-Bq)|DN59kD%65Lc~O@Bo^aspKt9P3XyDck1SX
z!VHj_@R-p_{}W_{-i%p4@Lc#*`2T2(00I-1D#ryU7%k*ssS`?1==aiB2qSJi%wK{9
z7yz9JS3u#7%cf&vagnpQM^eIM71mueFmT~0VD$Mwq0{QGY%KDHpV_$5v9{vlK&HH}
zql(Na=*l%}Li(%<*3?#0n#`3yk`vhxEVg@9USDLSWbT$nho`KM&RX<jExE6}W~zFT
zxLnz@uy5i|Wcqiqd#lZ!D7|dKLpjSfDT+!Gl1VL-oSALjoO-dtk_>y**?SS6DlTc%
z2Lie1xw7@kpS<<X{ac^exEsd}&EXfbufq6Kmtg}t%yKBT0T^Aa0o%(fKzDjO=uRKX
zcozD-cQejH^x^YS=+otto|uLr)PuQ`;B78QrZDRb`V0Xu8A?$o&mVIBSgAQy{4j`D
zBDe;`3tYtiBhQaUzvEYe1!wxn=}`b4Hl&p#kYQ|OFg6bULH!A*eteL=_WziVy{fXL
zv?dm-DJ`k&YV4`3>}l*uUC&86CrPNOM4U7^DVxp^Ox6878@cr7Y2WQWR2?wZoFw1B
z^&J~`a@XjsKhHy0f1Z}wC_#e&tDH~!tIO10h2ueAbaR%bz0{t%J)J;aoZgQ7e*6r%
zZG3O!=JYwDD7{T(jh`VR<9pN<Ev==cHQn7crKPPcO;Z~ir<Uj~PMOgzPZ_`wT;a={
zIm2XJO<el3d?VNVEQ$DN<?Tl9nSCQmFLiqC{$<4MpJhp9{Va)gc)AvOw6myHRXV>M
z9NZ5kOADi=4WA2#BmWdO0G~aUJo3r-9vT)-r8Ws0V(oZ(YU%hMj7gjMtJwP(8gvQ6
z8Ji$x{pBF^VL1z|A;7UYA5_<1L*T+@78pGTh{_KGDA3Xa56I_mFjwsJ1B4Ei5q@1h
zpe5+RmJl3&1l$B@5Do-qbl3`k(}Jl2#G;40!9L{rVJ_jk$_f*+{=bZ4A)USN6yV;~
zgt}DSdV2IyM%S$*8nbH=p*5d+mWJ1T_7p@~s|~_=9YZdn_1#LcAyNkdg>CFS|7!L~
zS9XAUG%#g3`^J_D6Slm;E^lbvessl(quW~>_|MiZc2$}Z{QcFvi^>Yy+y@tf`7BW%
zYK)K%z!NmgbN5T_s4lxv18+dCg*Q+Wb)lvx{lIgKR!2Ygpx92-M;g@KI(l?Fquoh8
z<`0b22FQWk2SjgfIdo{to1z1|clJ!$wrx_+nw9=KebgFhs<~+9f>}L_wql+QSh0X%
zGy;6*B;fX8?H6|H5{!k$rC))4W8)s-FE|}#6S!j1DX^Dj%>qMCGxag%E(pF*Yf!@2
ziZ?9^r^AW>yC26d6FNgYD7;YZ0Bm0{V8UbOv<V9^w&d8ZppV6z4j;pn>}i|%si3@E
zEb%2YcFw{m)kWFaYkIQ1`O|0H6e`9pa;W7E3f57c+tsX$m5HYh01%|a<8r86a=Tcs
zJhGv+dR}mT3?jU+cGj(y)&jPeukrg?ld3BNHM#n|DqFmJPBOl5rpu<<YshKJd3j2B
zs;}7NIi$(#Zp-ny3x>11oSH)c2ZZI-zmb~S*WEbX<ys$&u6Gd)!C2OBjUt1=tXEgr
zBockdUl0zh)jRu#qJ{ztG|_Ae0_cg`*Vmz|PL^~^7tA(+1)biJ6$HRVbIfvRRiAqS
z7`HKCBp?9<ca<#bFLQE-TN6(8fq<*jU)?ZypgWlpw`LtshaZ?!I5*a7(p}>62YcF^
zZ2F<h{z!?(dx=gi(mvYd^9{B(P4)Q}mezsV1KTq453=9VcS6e)gXT{QUH}V0!*>~2
zzGWa7yZiJSSH26PC<=W9UXSb3g)OdCXbOT|)_BK_x92Gadz%TiSZRwaTyJBfgSVJ`
za0>)La~C$$_35!?5vB=2Wr9)9&r^UlO=;MU3YbC|PMv>p`uXW=#>fue7hiDUvw>)V
zZ?M1O{{lW!1~eVpI3_~;pTzDFkHW@(W>wHvIwUm(5FCJ}bZQ)6ieV%2dKthh(h4#^
zpJe1x9T=h%KrkK(3?o>%f<^{wsGIU0Kl0VrmmeRg#P_V=|E#nllalJ%v*q>Ix9o9>
zYxDEH)@L5`+8FR<(2D2O@*`6B9=Ch1TcU^IhDu(L$0?QIuBFjPrFvyy0^F)pDm7x{
zdV1C=W#SA<z0%9;8t&94i8;ocQ&Cgu^QrCDZ40aNtDP0Pkk_h}nQ2DLfHzdq7x74f
z5bX#|G{BEVOt5l;(qV#_Y7k7!2+nIP#77G{r3S03W_xGXjiO1j{=RS9w!Qp+dijm_
z7_!e8kn7czi<hi?Wm1c7<Fw0;<^al`Dk*6}f!d_;xoxQeiNwn|z<-UV3=G&)V-GAX
zEe`k?f+VE~A_KdW;4Y;X&Y5V4tVK)35@!Ylw00+Zkp3Lz6@nRsppgXK+BmHw$D2Ax
zBI$~RQ$Qk^*MM0g;49-}p+X@wsZP)N2&BRWyqJcVYpErhuOGN!f8l|vo0^8_HgB3f
z4K*!YdH}%wkZThwbsf5{`g6uI62GzM?V+U?9V}1e-}EcumTP21wRt^VwOg5ohfw0F
zYY(<l8`zpe&5c!G3|+MJKzUv~^;}cq@Z8>ILqn{#o>G@1&A#jQ7wt#Umg9#SH(b@!
zICr>p<J74`{BtACL-h3Jg#+c}%<G@JesbFO;tKX<;IS0=;c7BWFq)`<*@kBDx|skH
z-#lCfc*coM1d;&X32L7t7`dmvb<Fxgu=2&tBoTK)?zI1A0J1@8#G$MLLcw4hRnSqw
zN*@4Kq@IRkaIo=vgeaaue9su!w@z$cd-3fgc{|D9Y*M;S;Nf(i($NmCZ>#wM{$u_v
ze%_KLSGzO|Z-$6B=z4Hpag?hG39A8QVx*)k;xCZqPLXo&V+{G&pG_9M$+3BhcZ--X
zOwmea$;g7!uk!!q_ik;1u=nb#=!L5o^E&=Ro!Dzqpy3A}LXV1+SIZP5o8d{5&@mKz
z`_@&g>&V<C{B$(m3*o0puYpo9$jo|}s+Vcs1f`At#OdT5|9X(3?<R`2csDYlSu*K#
zQD`T>oB#JaHy^kSsS)&L2sE`~5!lIqJe?s%E**}M01G%^jBi9Tz84+*b_Tkgzl4~_
zcR|GFJ7I6Guy-4O2~|0|`9X5y!=qd7CD%MWy7>&OGYFvBE$px8ub|F$WMo7@dc}w<
z8qC9x8ek}t*yTMLpz+!t0Voh~2>?<CrFmN0tHHG-_#|M)gnLui!o^s01`IlwsRRp7
zV1!th1~XwFkbgQOTn1GRwx@zoFLrnqP)0DNv%gAx0;WnLLx2Cgetu1zlaSROX0!bS
zkvex%bY+)@UykksfQU=aJ@U;Rfa2KyIJaVs(@CpJM^X8)rVSITX7=<nw@fJL+H%pH
zuI|Co=#{rM9eMQ;{-1d?5~<4$RNSvQ$p0P{&N$r{pA<TL?|WB;p=}!t`NM=NXVaeB
zmx;ji@4ncbVT62>wS4JCOE&fL^N{2Yh*wsiYALgkr|ybxSs?E}LMx)LA!=}-f_Q1i
ztS4kI+*iT(6102Ye?D9O^bJ~tR9aYAQ`j@Dizq8=tf<^6DnT+tU2(udt~k5pyZA#l
z&G2sKcO)y-a)bW#!xI9)U52s^X5yj`Z{2>ym2<>5b$95&B0odmEqmE#p`AHkCT~92
zpN!At;Ub5SEKoga?3$GR<5E1|k->Qo5plM$zhDzFmeq@~&Y?yClQG>f;XEWm3O52^
zgY-Y$Yhg3$^EZJrAabTp(@zopZIZH2AHMBnC;temQ@fVGM8zz{nH_^$hvv+gF(0fx
zHAM<L5wH|a&g1V^n(dO<bk!@qdQUC-Ai1Js0yzUoHwTx7#hN3j)wRm7r=Zi&SiN@I
z^%cK~O^wa%LjB#XD|58a9}yYS%vmynK~}KP*EFYY;;i1@`23aGsAtyFXm$+z1JAXI
z?_MMd9_eb{s(mMWQlK58;#M*x-db06XLF*Zb7Xc~PN-OAMVu1c9T@P2q?%=ReFU6m
znWcZPT9-@`(M=p9?IBkwCyUJ<Nh~xpz@MALzvQUOYKxu93w374on6+E*GqLx$fdMr
zh7&`*J*JSyDbI>Vq(Ymzg1CiYA*PfM<Lco4TwwER4gRNN&k<0_P}JiB0CCH8d-q(Q
z%#IG0SSPi%n%i6s=TwWnAex;|WSv@2oG99R(@lH#{r%C$pj|%({ADqJ2Y<)9{so8D
zu0y*JeL4Tu{SUl<sY?84Z3WN^mVKXQSJLlgOasrRRhU}fEuhU}ITi2W77Bl?lEu}J
zg^6*|1*buRaEvQl&=z9|0GuIB0qG=sDZU*m7^j0XhYNovPz9h&j_<N7-?~Cp*^-+-
zcW_@(mNwu}`vX};7PDK_yl|+rTI)Tmw0e^0Xyw8iJGy7p*LKlKX-;ElUv=@&WtAd>
z!cb(H{MMeKIr;G>X<UBf-BELP%Enof#OrzIcZk*_Z?c&UtzA1?YC&cZOAXlxZ+<Aj
zmPO)|9VH7ZX{pkk<-U92@T38iCZtj5J)ZqFlXJ8BwO&=+5Wb|oeMfs+lTY-{+B~;9
zk-9PNQYX`P0!NsS=)Xa~mV}<{FxV0b9uR415KH*!YE1*_v2ZX}hJsQ;Fp$TkiuDH2
z8gUdkK_UcK2I0E#Qchcx<ERh<OT<NrStK+`K@=1Q2IG~1MM9vaaS0Nt4Qk4OWzKXm
ztnvO2bd^j{f6NL-<~NHB%gPH{`410Asc9RsON`mgiRpz31#1kIJwQ76D*kQ$asJCq
z?@H8H^-+_1wnWZEvMz1Wc#uR<l~b{_p~C$nJ6w>*zk4WnCfb>=%?i)DCz)R<k!Igr
z895c1UEi}}_N0Hz=$`YpkD|exp4&68%8Wl7-&fl+t-reBktH9!_RMdu|BC)V2F_XG
zt(m!AxykI=THX})Bi^0Up)r`0lG5x>m0Sbx@J0ExUHLL4X>e4;+D2}9Vz4yS^j3aO
z-=!j#Z9_wqep7g!OASJqBx%vk=v!4EMQ{73PD1|aK97RCZB}_s1Z8zq9Mebgr*@X*
zw;OJaCUW)5%^`!OUoxR<@N|XW>8hEH`6`|lT_!rokT5=wW|%X4Fym5-rl7gFmknr=
zppx*A$v8H&!^I8-%|f@uVq8I1z-+)XrC{uj*<!j?LDdL@OlHjT4w?;w8^N6+^lvz7
z1yui->p~v5Dgep@9^L09;hq>=OQ5OpvGL@EtrG4#-gX6=f(NGmLJP$ExFrfOBm(td
z3IfG}(7ZhXA>0O#2Ke_0t$vKJ3+#K$wMNLA9?uFlNK<+GA;M5(><e*!4m#cdur7dx
z#oYkrAn7fh<-rete;T?(=!Jx|<k(wbZH9msLSn5bB*tT+ll*TDS9*5xPY;=gtjALo
zfD8daU&LIl#MXGJTp=sf08#?^WnP}YtNHS6j6=^UO?Gi%&%^-J)mh)L*s9Fx3r<C1
znUe4WY+rRQAoW?ahFVTT15C2g=OV;JmM;Wj4=@_EDNPQW8$zv$l|g`egUL2ALoB<m
zv#1(e*;%c)B`?nh9-~s3jm%UPOg>HxHE9EXMFlxe7M0hk+h+F;a%HRMeS7(f{Fh5z
z?M}G?0i2;(Rv%k&t&OuQC3)FvT#L$Er`rG^z^_;OC>Rwfh^QhHJdE86jl0OsX>$y0
zX#^q%g8RO+X!s(hIoH#$?r#%UZw|xkah0LK3~<{1_QqabCUQTwa&T2H;14oVrOU5H
zHfbL#(JSR$HmX%3mIr;*Uj7LMx{2yp$Ty+;^->C=p#lB_rJpa87qV)JJ4G3d$|RwK
z$iN7|nEcr#B?HpTj(EQ`M~*s7S$Ukqnrq2Hv#kXhvY@D0Ka(i*JtcE0b{Va|lGq8O
zHK;06NiLFpEFwIdAs)4wvSSWQBG;lbgI9%A#8j&7E{i!=sS{_~`-_S~{o8h<vYwk2
z!|<jp;bs)llA=Uzn|8?trA=erQJ~MOwphqqT3Ir1f5|nAE`BC#zR0Kw`7*&4U7Qn}
zE`mr`U`46%Ftye!l9gmixpEe48XELk3$u=^Qa#A3{UU`5z>LdAuZnp*4c>Bq6ObCp
z8qhpzcDtOrMnsB4Dy_+40}y`Vt;qq8CxF{K^o!sBUQ|P!hWY9kpdLcM2*`$M5(Y|y
z9?t9Yf<6s`cp6xNl=JgkPMF)EXjTKxwgHy~89V_zch4pb0Z|SA%>DnUXRK8{ih;J@
zzrugRPv*<`SKdRCyMK2JlX+(UZ@`)8R$}36&mnp0fiEZg<Ew#xqwJ|e*FITM@#Jt`
z@ri4TkniTwCY6>@E|_!O%eUS;f8E1tXDReE*WR`5HvXNNSO3m<FaMWYZb$kDkcs~+
z{J;Zkk$V>|d;q=$+a+Jeo}|Bl(Pkq^g`J>dp9EH3(_nrAYdJ2;SONO>4dBtdBV$j-
z0l;v-TtIfbF5{+*TQlwyqQ5<aO91l`k4tFjV|{%hA4&x?3SeD;?SoC8psOc2EC8fM
zNvwU00{|mjn}AuLBo+lpY-Niz9e4{1)~pDc57-B7C)nqvw|HL|w~TFZethg3JCCo!
z`$B$vkFoRs>~pY;-=96{&t6g}<tIw?^WQm|9r0QXLB51Y3>FtiwO0(&W_RhXfU5n3
zPyF4Vlvxd#o^^}RpF&x=2a&?ZvgrO_JL#KhYnSuSp~B^7&V2Uhqo47wqX_SYvD?kE
zU;PTrY-spfLj#(8|NW^_*uKrbjAE&RM;}FJ@g<)<@<{4#{v{OWk3!O%#>T(lRQ_0P
z?U(iS#4CIUIyL%mZ7rHpTf2&X9wqRy>d{BPgv<|Dcg+AdjnH!kXJji{OB%NhOEo?1
z)4>}jIcuFd^FWa=r6fLnA^;&LYDzj%&P7{`CtP|g8AjTJ7R56Tl5J~i<KOM<?Bw5R
zM^o@FPqpo8=c!I2hIfhlHl7+g+$HS(0Z#AkNM(&>fV_W5-vQ_-6ULSy_9$)5SOIni
z4zN22faO6Hdcq`FAC!arK|NR?w1W-8M6g1b0(J<)V2Q98Y!OxiisWX%k=zYPl9!;%
zAzt8dh!}VhVg}xYPNTHO6*{ee(02;m2ks;>wZR$|tZu~vPL>G>9fu$!V>u|TRZDk<
zKwN^GB5tHYF9Ttm&hHz9J$xp;2*MMK<ucq!LOi`dUN*Kx7y6{MW(}|XI0+Vb3D~4x
z2(kd&>3K~pn*ib#M7P{A{U7e|u&VdG%$^qD{>K_#8{SDT@Dv!`LRUT}E@H86T<RZh
z6%bP^ju%Yv|7{<)4xElDALkKT3~a|+2HuXR1wcv>4)6s(ZboA#gdF3y8PA0;$GPz_
zd$dO}WayV?%V^yShdmi>iHX(rV38+O<}Q?mWPl?@t6S?EZz_tG6xmu_QLl=gW$@WE
zGkc1}Vsfp!N@Or)YHBq^(&d|?RG0%znbG{7ESD+Aokv##&P%*X(_ApgTEfO9TH2?#
zIWz!C48ZA`P&Xy6m?N_=%Rf2C!8jRuB7pGH8l6b3XDn43K(Y*~%_bX-w5mp*bqN5%
z1I}S>alGOx)})hV$z)-f!E1MxLf|8}Go+EVm~$OYakec4A?V!_QIV(^@D;^Mi&AZ_
z{w`zg(x}gBb7#?QJ9do3Vm+}~do1>!ci!pQvZW~!`D)9STi$%LXXj3S5Da>Q)Q%ma
zvDht;Vapa?5sRUwH{ReCJ9eP<ciy=HlBU1;=ExR$C*0?b4?g%lBRBWvNCbU@c}nV$
z7@hnkH@Evu`rXmJdq>}VvwO!5{+_*iZ-LA1NhXi)-Al^a-Bom#Xt##!)Ku9-3a!r<
zLJ;nzI^bni=xy<&SuQJc6%=}1@x*{QDyABBJrFvus0mHds2w_M$S09-K4+b=R571!
z%Ci;tn<G9eSz)cwh}Dv?*C5p)v&!ESibg|5OUR>!n2?AOaY}hap->qpA7?IgG)YP&
z(Q*TbE*3cpOLl3A&#{(MD}2FVwy)i4P)6mhW~Bm9gs6bTFA+IKsR#3Nbt;HGOp233
zi5HT;OMWY?XTaVI33LDs_^T5`N&W;J;9W@KuO2%bGTLGP1vot;$un>Yj*lgVOm;ZD
zI`Kl{Yn<<E$N+qbh5qgYdkdq?*bUemw`V*7E+Dz69QR;?EGqP4LSL31AYm8uG^4?7
z9PdG71!(2z1A!w5YyvY2JR&>KZpK?KZo-0in{LRk7TAm+$etIJ&(97(GK`Qhx53X6
zp2Oln9Pm3qJWgxs(=+@(FdpoDEX2crr{jy#f8ieRqVP58!36#+K_C~H&)BdV_J!9F
zglKPWjKbrEAGnS`7mqu@rT}~|gaOKVH*y>k?}ytZ*jr`>e2#$LCzF}VAi6L_Cy?ZZ
z>{M^xfFq{h!rp=YDdIU0%aXQ8L(*mo!G=Sfftd-EoEc~f1Cbirq?uAP1#!T#LpE#a
zj2>@XD#`P9Pis;+gSldoqRo(@&??fN49rXtRuliB)u@JGbWTv=D+{gOnQdrCIC+s#
z4JDUYHqzp;CY9hq>4YqtT_#PQwo>PoB^GtGHV?=|QxttI`W&-4YN(#v;G|^=by+y8
zxoc5k+3(a&IT-h78z2y}m!afkjVMl{Xj8F@A_<GCSk+)u%W2p9scBV}Jp|d%B2{~u
z!p2+xAu-2BUnpAPU6xp&L=RU2<Ezm40&b2rCi45`fdZ{UCRtKZu|$#$;b!EQa883E
zw?bD&%d#u8=CSjtV>wbup|(6~Fc38x#hy3`0gt)m6&1@lXj<U4B5u;n>S)oFF_PSh
zqFIVqHgQO;YE&BhwWMGAB9jVKWHwG}xQ$bryxM$&(@nl9^%He|0~huim0TU~c6uGU
z0$n`pl+bco^`zmFo}L}^2EeHppleC7D;$TjPOoLly>h#f<19XQVCLQWMz8;>tNhXu
zzy7{?QyWw&#`e_cHO4?J6rlk)r@NcDH95aL>T$aa`P#g!8^+q$cJ?=*XVidYPz`7r
z4}rDD9ni)AO%IcGex3%*RiHbA*6?4`@HBUt+JxpObm@sCp1~N4Y7NPP`xmqlIH^YY
z=^dcd^dIgEE!jh#ze&1DkKG8<Hx@@Vc~Rs~w~Ba7lK@mzXf7DX1|PA%nYr!kvXc15
z!*_}7BFd-Unp!b?+sDg_b2lD7MLQTG#BD{pvUSIqHK(?<UDDLlSGKyYq-5`R==XQI
zR1(do!)-EK3VW}N$~mMd@Au3@88>X1YO~qhd6&<z*@C`as!XM}@YhoXd2?^y9qOHY
zziG!FOJ(1dHy6A!_r?2b(2z+D9;$MScX>}!<K<n&sihK@+_!kJ@#>Bw&GLWezvXWk
zY+v&dvZGdshW{6&e8ZpYZ(Z{$a-t5o=DWY^>j3yoYU5Oz#uAHC>9rS1m}2Vw%%Pf^
z_G^B}PrR&k2AQ*_YaYNt4Ul)1`4nQYJg|7Z&zE)XX`9JTvW!%t1wcMG?R4d5x#KzJ
zsLo=vn&>$}9U=@(pTB&=4pi~!OI9`F-~ZR`>rma<3;|2^diD-_6y~q$GNu47($b8L
zfD`gNu+#YjEE!Z-i$wwzKwSmKDh{d^%teKNx{}WGNnBZJ8&Ql20~I9H51ua=8)pa{
zE<Gavkr&_u&SQYfAU54tUVItmeVDi5n}7}j6BZWq;4XqfErV0hdY4le$iRH64(6Kh
z+kn&sP!4IfD!iDG1S1)kivUp?kY<2!`tWmrG~<F24F`5-@8D<gpY!YZz#kT#S^qEM
z^qnhL_D<+ML;7n9i&R!qYh8goBu*R}sDR;5VN;zxYn8Kxs2$y+(W!Oax#nOt(*0}m
zoNy+%pNFS!xXjbpv5wUwQD?s<b-hlMd5p@eDLi0qbJ`5r!&|q6E4#9`zNV-CZO(fy
zi+{phH}zqcH&l^rH&>=UMF7t3C*S7(R*^Y`AT+nUth6%67>KMz$UQgQv5Ip76nC!F
z&|f9d$FmXgc6aykC#|(CSuOcGD>JB*I!mA6U)(zdv0Lwb|M`8_qEKbI+ZY6YI*SOf
zyYrfAG!k9QP<gqes;vIu9j07<8u5EmqV$Lfg1t?DtUXbZlPj}Sw^w9m*Sl2jN4IjD
z{GO0E^>A6`C8f2c@h_b!tyKx8bzk*$-S~LmOPS6vTw7CGAN1xlErU{A#echb2Ku-?
z$LUnroHALRf}y1#XlD~-;8La5*FIFrsGMb##97H^8nV>{DcY}AySjF&3)ON)|5Ub8
zEItm%eoRIue=~a-{de$OC<Us-R%FM7p8o>wAW%v=vJoacph`iN4U?;2Jp)r_@b~0{
zBn|&Kii-&?%x*!7K)K~G#@EL=*dJ#!*yP5b^Lubuv#~KUpwI%{dE7$S5`kR_<P8Lj
zsnZh!)K-C3flj#uL)dENd70+y!py*x*KJs`7P)7(mTmH^e4Wb6(%IY|bSeLvPxud!
zi~sOe{sX-Elz;YFF#paNZN6p?y}GG!sg_1^+w3WkLnWOW|4rIVa`gwpEA@>p5JxY(
zRjo??(<hDm8mxXSXyx|pa0fk$#B7!YP{{|vQD4YsV-*7f5>IHtq;09a*DSsI@yD)O
zdV*My`iwA*KD76YoLadU&`af{{29>jp^GZZdUwT2*GEVIR9d;-`%;+yvox?E<^SPE
zcSHOo$%PLg5B$Mu@Hg|?>4p4<X6RS&e8kP{G5TxpJHgQ=FelNufb~0l8a*u(yq8mf
z`9;1<2ev?X$`Bep2dAL+aI1%?&0fT%ix*}HkBxrLKSfdePX37f8kBQaSL5N-UkHc)
z4pja;x<n%vZRB<zK59aSkB3k2`|eo3UbGNJQ#Q?<=?7Qc^d-N@eEcX;fb?F68hymM
z)_|9xt(217c%3Z3j~YmYl0Ph}FRGn)x-a3d^V<lyhj;+F^{(==>~bMC+9vimRRWQE
zOyEHlxB!C?+w#AXp7X&oARLTbT@cL<BlLpe1ZGwd=Mpq0u>{HHV>sk|FhIdd4KPB1
zQwY8vb4MU$%-w*=;;rA~_vEBg;fk?Tn8g!f4WzM`g-g<Oh`Z5Zq|e3jFy^Hg5E>+8
zgD^`2gz5)~oHSd;y||!@74$ej#22K;a3Fbj;e-#cu-W51fpfP7yC#I0rqIOppz_=^
zsxSj?ngIn<BMn6o%1pphTY_P?&OOL9Sox<=`MG~mQ$$L@4OS!otPkM&trNXcw<u=!
z$qfp<#gZv9xRQjg--M{yS{+Md%Os$Tg$Pt4EhSaNq*_VX$7#rz+f4#SiU|fQBuUCh
zlTD^DBM~K4D@__e#-*5YX9zOUQtK=W#-LRIRQwZaW!*5phqRF>69UANkAx>o2zjy;
zexE8lx|lebnx+f|$d`N#5JFQ`D;|Z2gvDQ`9z=-$9xZ+3k$e%OW2Jf`q$G6_&ICbp
zGl>d_e<hO3r4Df2g}#Fn(b)ls)}_}Yg@U6fKsP4IkduT-3AGaDdMIb1ORHDN=}d)4
zN$B!)c@Xxgl+puU1(`7w1~Vt<0@!0=J~tx>L?Ki@8P|Dqc=6=JC>$?IGHyZaiEp1|
zEBenZCw~3--qWW~&Ajj4d-oBKufFyeT`=ONwvVi*EWB}L|C-AVujyY&Lkz(g2%y^7
z3!b9@Z6VeYwt<dt{CUu{gnEa*7RU|vu~-?O9xw<@5Xcc|2z%SR@gx*xl#mWKiJ<(%
zt|HKT=EGG&`_#q8-ZJ&<*0!eBj%_b&*!%p8d)BYp{qk@2ZA^K$w>CAlY)$=^YON}q
zFnQWc<~HpzuIlN5i7n#V-kDi7{Og0r8}zsrr9Y|vx~p$IdELzeMAK`xKlaFNufKKb
znP<=Ny9RE#_SPG(I?+F}9zEU_25+Z)%Vg8tAxUP-a&2Kgp`NW~wi)c%8;4OS`+cWc
zD%~&eo(s!6_x$&BV3`6W&brvN*B0x-7+pynG&FC(lf=D85;h5tUC-A5H7&6HrTw2q
zh&wY=b7-2F8BDz$`E>vD+b(_NZvOL}>w|Mi^3vd%9Av!v{qf2n@8~&x<Mv*+!QkrM
ze&f-VtKYn}7cc;<y|=#k6IuYiI8F;=OaM1_EW!XO!0SNsggWyi;H{yufKbvED70~0
zb^7z~Nd_a!qW45|OAFex`M!;li*H-Ct)^@koot#`|M)RQP*x?)@ftllJkA2q_<KIu
zoR{4-!P-<7&1+mzz4G|P_Fd0UX-w{Dj0f^7)ZK(qnjH{9c>>1n_g{zrN*U(2-5J+`
zCHFH3PzeFv(gY*&0GbW)WwwDn@Hp<Dv5=O2b9g~`e-_VQLcyL#kQcgEp;rwE1BM^3
zv4jVIVQ!0IeE~2`5o|Q!CIRql@(XP8yt+^zP+@d}d7w~OShg!h8ra7g{WQ!3J~94J
z&x^wwjt^>}N#G}5kb=kXV@64SJdZa1$L&Q>2EtwS2AD;Io8tBZO$FBQjRHAAtATfc
zc{dgqFKHls;5ZH(mGrT+0TKZG0$@7v7#;t?6d2!K_^>p78~zHYY`9~34Ks%0J3l;(
z#y7<`NWub?0x~lGz_Dp$Z1ox*i>-t0%;3|6;)iauBocI*l4`Nksn#ZB#?oT-N>&Gu
zPHMUZ;1o!idp$eBts+>3-C+dKb%$6>Xc!}H_b~<$MX3S+tj>TB#kr=b_8OVd1aYuT
zz$GcYiGf%tg~*trVu|UF+InT7GBOc@B}FUbv{yTr$*8i4eaK(#;Hcpwqvy&BqawLJ
z>9#@)-gARNaTwwaOATHy<Wm(};yzIJNej&)vxreMn?+4Ed08r2p0HCkR-9`noXjb8
z-h2T_N=;cg2-YH!Dm9FVaF~oV0zIHr%Q>XciS?;P$dY3fsWPkL{9F!g?Qh_k!TiaD
zb~iEcB9?Qik(nPDOd2>p#4=%`*_na7N=1RfZ<(W)Mx?AH$7RU|eT2z_7`IdbLC66_
zpJQT~N)fu2U*Ca_w@T#s^NuKDGxiX&2)|jZD_VXnAzS*18~xVB)`(qHlOb0$8n!pX
zteJ*%TG4fOz!ouz0rKKTb<r$VtJ7H{=v&e~EvA)}=%reNMy(bDDm`*S;3_>Mr;~%S
zlJ(zKzla8zpf;#dpb%LB)-_@UV`8o9Ky90Ng{Qi&KvzDm%u|Twid4t?rWHIA?#!$=
z`l>fqX(+vd{}?>T!r8&avRfsE3a2?sM2057H0DADOPG7=W4g@!q)2^Jd|gl^xkqGy
zSUv_$E;f1%nQ}jvuNdt?GASn=oSbvZ9h_DQUL|z>sn;|<{)%k`VdA%%e|z|{W2oGA
zt@#1vV*VPf@4y|R3euu5OP%$d^24;Ey|$)K3{p>mM$V8I0M~<nea|wAe6<1s&IG6k
zHQCJHS9->%VpN2kmXcB(n_~}&3<P6UxG3^Ed%m<pf%HCmF}Yf#nj2Bc^<g&CgZ)mr
z_$y&f><jQ^+5(6?|IGMT#<v-xC<AbLL|}XMv$+l6Q4H$=Gc<saiQ_#zI7Z^w>CpWO
zE1f?%b|#O_Ct(+61@Lq@TrhS%aN(uUU20hl>}u2hbbAJU2ZG5ljbKX$+yMS+A(o7=
z8z)@=&y(-LO&y=o8+5=O;Ys;;57LE`$#@<{<-w8D##11kL_YWf2zkdZ0RAwR!S5+U
z2F!+jNJ=DekTuQN0z!rmRt?9RIKOzL$fJR0>+llKhkM~={Pg(c<HzG$HeYI3DKma>
z86)4q%2Aj@0AqI<p}6s5AN|=rQnki2V^fJZPWTteOqYD5(tW&NO08!>Y+}V;w!6Bz
zJ=EM@S;hacsIbOe(^6i}fB1Cgw@5-GeI%g($nhDMgJA=jT#%nVp`o!BoikFRgAoOU
zGbI4rju8z@wL8wrjAw5k#aDDvbOZ8z{sbjHU4qoClTxZ#R%|#(Do>ncAwt3j*U^fD
zG9#l<Af*m{d<oda$W4Kd@X!A~`s5@2jStbMcxQCa{)g_~^Un1zzWCDe=U;f?YQp{}
z;veq^Kl<py)bk$^U;Qcd@<-&if1<yT8COaTNB^khK7_a!Q?ljA_p#XW=|%OyPbk+%
zs4J6CorNN8)r2>y<>pTgNOTL&8kHYW2-qwVQ+>>RoyEoVr3)WCdX%uwnX`WK8UE`}
zK7nb-Xg5*D|CJysPd*<#FlW=lNN-JjPQ1FYxw5sQ^4mLQhL8P7689KM@j|Kb<83m-
zR9pmL^jcHnHg22@2Ok6SuQSJ#M=7+QP>zp>q<XQs@2uGJ5yV~~0c_D0B$k|2=oiXO
zsp)6W^53NwSpVnjStL$xaVjh2UqpHQRnyuAHf<hgpE5e{?Ag?pkcUZMLF&@Sg!1g!
z(Z8MrHIiVjcqKE3L0}JD3Nz9e#Rg;nk|1HG8TzMEz{gAn!U4^@7W!%z^z1<1YGF76
zofj6(a2tY7Hr-&LA5AwYY<>z#cNXTM!CM(yli)wLeT2ai7Gw1WNMz=y3>6I*+eD)?
z!=WmLRnpAnndG%%(s!#?t2-dqdjgVIMOk-N$xPP#YQrk6N+NY#rZ!ehmf8%4OK47Q
z%p1Ldjg}GQAJv6ogGMf2A%jq5p3!^7S(Hpg)<IZ{VQJ?I{(64n=%~rz$mQ;$$Wqoa
z%NR<CndSKe<#hO65;Vme(iYJc(&=1(Z64PkQ^x~=sm*P2*(+bG0Az@lX?#|uCK+=q
zH+i|x`bqu7tg7w3Bj0!WvI!BV$GQ)Q#Vu;0KL(vFj@4L}Q3blW3>qt1(}jq~dsx2;
z*1%9SFk;pLy1XkVijn~zOyzSf0Q`Yc*SKg9C1Hjl2P6X+b8sl&Vns~~(Zha&yw9(d
zRYbuh_7c7;HC-m*P|XXo`7dU_fDr28Qp5E7^J($9VMcTXy$b<UsG4@lt^9-E{fC}f
z|J}PyTRE%hPPsNllO%gsLokbwlqD<kwGaf&WUZSNBtJj54FW9ZpsH3I0PV9<jgK&q
z`q96nx^B7&+uC*Uud;8`9{?hIix98jD$o%?E#tpuZ2m&vs)8(oWhKF^DxN4u2@rJz
z!45{kX-fqM!UJ1iqQFt1RDAH&I&h7^rVBb>024`iDg=SU6}}aY1%zQ@S%_JYrZSHk
z7!C~7lVAV=@)sVm$C5rTC@Ap146$$Pb3;K!vcyBO4O1)s#{0InS>jTKWI1D)*stVr
zZ={s};3O=&P;L{8WpO<^BR1<T;5MLX(@5TxNe(HEY%ta7@wxa<IKVBC@IwxTG6DhS
z>O7R)BsW!07SZ%JQatK0bD~*=v}g;`wuoCoUPf=J5idbr6eL>x&4z4;N)k0&YF&Vm
zX^e@av?(YCJ0CKO@uBSy2JK>-ty>zAAw8##O!9bwnOxP7IgcO<Y@C8hvK6{`)^fB|
z%WZv4><t_t-u-SewM-d?c^LvR2AEyY_<Sf6D#ER%5+3u&esd?HuCXgA3o){f%aWMQ
zITYZz(oz;ICe!`^SF$~f2z(&i0v2Nxj5!|!KhKXd{sN{}&_!d3`@D6@xOxN>vH*>S
z$vBQtjzL?3=g4tin9u-{9h4Am+Zgl>2M&dKHpq|X!{S&|43#HTqEMCT3MGMi;7(c~
zps_&&u47QBa4hEua1i$gGZ(!s4>ox~K|lJ#P^B2TfwY9`#%s6~k8{&ZNnlID1%Q+Q
zlz|n~n6Kq?0TMgnrKkAECNkU*=^iKsXfS;>j0a$>k$#>q8p7`ngv!DP!L1-)T+jA+
z*mK)hpIWIXi!j4-k4dVN#%We0XXG*n^y8QM%n%b8;`Fjo`N(cwYOzU;N~MEYr()cc
zQ%fR%{8i{^k#gJ3`Y<DNmWpVZbOzwc$;`bkihUEy3e*IcN!e8zHUHM7tgIX&wP-0$
zZd8Dtwt1q;etB7I1qj?Pa}^72pJFWzCUOi)5&%C>a1$=6s#SwU7AMjbL>$&)2p>b0
zT}~`TTG6>9c?xQXnXEncNSm*?fIQx*Mk1NUPw6F&tyZ_y$|yP(n>&HFSQ)n<Y>CLZ
zgjOuiPD-s1yM}*^wQ(Z1!@wMlltGk8FQ^~D+vcAVU0lYAm5ey>T?a9VWK)mJnbT?o
zoh5(%RkizEkmdZOm{5>b2pzagyHTsllIg{o7lx%q_*_HkWoqTN^)X7MvUf|()un?H
z#U+b15{ih)Q?IEB%~Jk-iSE!mh*Saay%nm1)syvEjuOthsF>vjRS@sko#=Fz`@vT(
zt5W4kgbrBt<Y=4_MyFuCCZ6Syh|z{rF(tR=sOb~(@0xlUqYw1syH@1OARuCb=@IAa
z>o}E4q^t~p{4Q2I<CdsI9<Ec0?S)<$<>s(H5&RU_!kn8O+6+eKiG#gyG5AbZ12=5W
z0L(JzJ6$o*fr45OvpTG=08$CWvHt`}tO73wDUQWF9rMe4E-6@Efr=Hh-alX1wWf0l
z(y0`^OUv(Jl$40DXjtOX%S4<^%<mq}r&5z^zPpXep+(;)q=-S1?>?uE|7+nNWntu3
zsFHAEH46bAwd<UOWU>VD$B6FKog>#26)mSEBi~Tpk}UYXyeAo*t-hSwuf9@!x%Mb`
zvsw6l@F8M2u)yV@47`BJmViF4LFfnOLsX6*MIB)M0T{|798>_Bw*XLtU`mL_)98X?
zL}-vg3fMP5+edns827>u8()Ui576Fl69hA%^ZBv;(a)3Fms4-@3;BhqH;E9s3|&qH
zmq^X2QAUDJZQ<8^`2MrcuS9=excA~=Vq)quT0}64)EBpH+;r=$n>OB-I+OZFtS3wq
zrRUWP_wHTDtJk1I?|pzS9$i3-QlCjoRL+sbi;o;xxadmVff+Ln9GW)m(1vCCWfk%K
zGJQN0%!`KxiC*F1VZeL2jL1yAUF{D4QEo;nA9!ha-u?X7OO~WwdqQshqZKXNbnltX
zn@*iV;XkU2A6KN-An}qV{J-vd?KJ|)%}+S9(4oagk1k$#&9Ox@F28)n^rJ_oud7Yu
zH8m84i%UY`63n|fu!Y{mzQ|DEW8?#!b_vu$y?}OrV?XSL*gD5E?#g&F<2M<<PfK%Y
z3B()lgXZ4ra)KvZTHgcq1}q094EjN^o(2WxPm{;$0#qQ0bbJx0NE$A{(bl0(((Dy0
zQE03N!}SJrngmvl&*i!UoDe4k1U{jbLGyuY7OSfvGbdyne<Ei2_(iZ^u0StXpcHc8
z8pnKh{7gEXeeuta@?R~BzM5FTe|+X+)PYoJ5Uk!f)VXTn>E*dqB6`K_`zEbR4WB#p
z%_UDh%_~+;IFnAEb*6tkbyCZvzNf^5DfOA0K$^Zy?>_R%i;sV>4t+82z@a%gb0>nI
z-P}37^XB!=L67p<jcc|o=e4WPKKtuup84>tf0lU^B1R5QxEo9QMy^bKuU8T#0t|Xn
zp8=YB_o%8uC1!lZYl|lk?+!Fg8EP6FY91J99@0;!?+Thr@=AIeJG<+9*Dr&g-eqyQ
zEl#J!JxH$k>gHX!I$d)6Ns#4A?>>0w6#vYq^t$qF63imhlI)7%)ZYm;-;D0#|8v6+
zsZ?>8xtP)MAFMSVW{JWLRRx7r>+fi8K0K6+WF@CeO=e{!Kf1NK`PQ{{Wo31#n;!&V
zD*gzv2C08sEDElrpAo6n21TQPdx&NDD=A3c+8g!zqrF{GpD(++Im<_hgV_bmIl;_m
zb6Z<yk3+3eY8(!Y5@-?67hOpYfG?#5_(7&XZ-U})+=88hsxv^Z3|%x$ay}MhUoH{g
zAXMOhL3D*${`m9!qT&^fgx)KgLwJcL^+`0;!JpfadW_tWyLB|izo}8ux<$)A^VBN6
zIs=tyt~hQZ`KwF)&wlqI_4U!&sAW~^&!bwJCC?D0qm^UtbPc1T{{@(enIPK;l8hT=
z1hR<?p$FGo@H!lYsW$zGz_b1U@FJB%rREEHNzf3n@V|-b{!RFa)xmx=y^H^5cj|tK
zSUf35=}-|?CRa1}z6H^PDHHPZ&#P=mf_yruF-qR6$UclpeFT5RSN_|P4r=2yGf^A=
z>6O2>$c%1svih>Z)U$*Fb%#394Wmclovl!gdzr7m7fAy%4FMQGM1R)1bZ1P=m<)6M
zGXSw*K14xU2L3|p0J~rt;AbBJ(HtZsP)VjmHY|3-c!Gx2SUbw6T`;(S)`@KpIatOG
z3-J~&=WP_BAHo*Acp10$9nX6{&)7BW*mZ)%FYM!Ejhl6+M?3-;0`nEv1r;@oP-3Ul
zT<fvY96H3?My|*VH!X80sK-YxBNCLHbInRU`!xK{J^AFhrY2bb<JZ4Ni<_EKV5dv`
zfqxp6ev8d^|AF@q%qgOB{!l~1znYph0Q}46Pd}Y<*Vp6x-!wI?17qIL;08GBbI*NS
zTkE2v5}MOU7;XImQCCYriI@}{rZn|29p7mXea*RdT4ITda*y?1(J6J)yF2+eI`(v@
zzU$bV-k=%XDO>kmI7~S@_QDSTdUxtST|{L^>Kq(*cc;EdCw6!9Zy<_@iZn98hTRNx
zdNJKY|3{cVlEN&cIztb>E925b9^kOy*j6>rgSG&QY)?iXc;Ze4)M^~%D&wd1gk0cH
z`roStxwts4?jKCB$1Cbb6^kovEDyFI9XH>`#6V4c>Z!)Yub+BqU1MYFE?jcN^SHdf
z#;bqg6*|lR7A5&BAXj4}Iq^Hbiy9pLBe^)`ZEQrJJoQv6R9A=Q3ulRe`ubEB971yX
z+WAlYf84!yfK)}gH#~J>=NzVU_jJ$n<ec*iIZcEi=O9V4fUcq<D59bwDnZ160d>_i
zW59$thc)b)NQ#J}?ykzrobvnC>25@K?|tumzwfVadQPfz>eQ)I_0$u7&$IN}{rgwb
z{iL2=I~adF?W7;HZ)7`?Psa3*Z{N_qp<9V{U5b-FzxZ_T)zV8H{bSpeU)#A_>=A)j
zu8sw4=u-M|O+QHN@cne4t#5;@?jOmvX8628%#Lgw&QL>#L+gG5a3|+O+kO?knM;!R
zHn(G@d?f9uQ`l|?)4obOk@hq2!DYf&SwTpg^Zy4L)~gtHIHW0;0Q2oiPyyEi_iY!D
z-|hhR+kHTPdz3suo+i(em+)TkqEsm&nw=qzl%0ZFQw1(qpfI@$)O*V--Kohhbxfg@
zv1@!?Zj~45U{|WFIF;=5BTJ?lPNV`;Wu%UYa5$omGI8^%TmC*8F3Z?W7{8OHN|lv5
zo=Tjm{Ap=Yaj9dRIbAuu@@&w6`{6%4gELua7F#M}$J&i?e;GSe#Fm*nvUA4YWXII@
z$Ls%;=6@P?dRdvtd$2k{hWCKn)_$^6YMnEO?lD?O&<E!lexKm=wi&Dea#_%&@dfa=
z$cMiwUkGQOK;@zu-ec02`AkNW(O2mW1ia<G5P+I|zRLL(lFMM+$?}w`c>;lu?`EH$
zRL-x|+YH9}KEK~r#iAE^{eEwmKOMpwL|Od{*`2Fc^n4a`BfI~tH5#X5tKaAISNekf
zKskd;zu77ID$i7Fu+yS985h7Wr^)EAV%30**k~-b=yg{5&CHqN%HFv6an<(n?PTtD
zs%$6o)RWR3WKQy2nTZozZY5{1sQxX<@I(T3Iadu~X|}V(sY_b4jb)jq7CRSrz^B`G
zl1TTT>=5@Y^!O_91ZM`*`F0<i$iB~MY{Y{H>p*BnAn0!~S#|GujbeVl7%=+q*ogF6
ztybOpa6!KXkJ}y$1iFynPgVz!-q%|!Q;@3@56?<)IDFi@dP{pU-+H85&u;UccU`jl
zE`PwgI(d)lOr}cXs??1x#tm|ua+Pmk?=<0#LwDit(4IXwVt@Fad&o<vvjcnfaCasm
z@4ovWBKPd!FaM9%$cDs-=k};&BreE{sceYB|DHV<;$Q>WMYqULi4+JaR?H+JjBmx5
zIcBmkr6OXp!#*)Wu!v;-oS=il@uD?qWwSo`jT|4bowlgLiXGuH1R4N?W2Udre1UUo
zMufxLo6PYp5b|;aQgwS}1<a`8Rb}#1ClAsG|5{~`y6Le#qa+U2=iW)CHqsXj{(g(_
zSf8BpvhdUE%Fo#zPiD5Kk=#UghMP!Fsq(m-p<7CB9e&<csc>|A{mhG%Y)9TWLF29|
zp?4I`2@Y{`OXd8&>2%8_+~wS7yJC;f$A22D%ht{8%Mst`->B?Sq*qTK%x<d`FHo*m
zmT+76GH+3V*Hfr$=%?@bs{UL#%`%a6-9M?P#x>R%bU7}ZY}!npr@J}szI$en6^p{$
zfNfh?8(PtZo8-qNJ9ym-Fc+*z+n)AN+T&^OrhT3EQyK+rF#>CeDP$G_A_lW2P5m%B
zfn$YsI>oI@D5<kh4A%*6)+zKjr^>=gait*db-6PW!fa4u_%U5I_9Nh@B^NZzp(8ls
zSpVPzKRCGsp{eS-vxQL<lpDK?O29H0KUNX7QZmryG3+L*NB9aTzhRY?^kkZP0JX%b
zO88zASrEGgI1?$hSpjMRR}SS^rh`C)44lO?+}C8m>NBdT8A~jo7MyAsR{!7s*cz~^
z(v4?<I396~3Bn}imC)Tpkt~QMQ2|F>yv&+Me#|OrqLSBZi)N-Tc|ppH>CC0Z44^$`
z|H)IZWW~|Jm%z_-8<%G?I!qkzE3k)ngFb5X>LQaigz5))B*P~<J2CRMQ8!+ltKlO<
zHrUN>n7P(aDZ{A?@RI#UGtgi-?lp@u)8rzupw%e*=`YGnB>qso-WM#f3(iQ6-ej`-
zU4cv;`IbJo$sF;>I&zjBY&w|I*rCHD-cHWA98T2I`C%m25VaX?((s{VRQOgaSL++R
zK&N~JS2r$WdYx#ro-l2!hSPOfr`%2VY0V@(B5LUh+nB4Iaf6pUOW*KU&hTa1Csk=p
zjsioiZ%kKI8<zUY%IZR<sMf?81X&myZqT`G5ofiAGmf%EE1JfSYKZDSk+=pp@3y#f
z^TW=(aJM{j=GonY2Tv&|b<~p|_M0R71Ly76n4Z!+K07MvOW-$N(3!h<kJHgIBCD|`
zU<g|Zil%yNY*ABot3@bvK{`n)7S${d*M&59PQ5%bAXqh{!34KV_N*LRH0)k>K)T$S
zC3~w@(w{WmEZ&wg9t>1LC?%C<izO)bzpgE-7^Ke_5^Rw9Ysu!NbVOCU&8w*+dJ_kq
z4kouRBGLoI6EAm$BPE=@G_2EmiUkseLS>iP#YOvH65yk~wj-EhNzc&CDIyVXv1rQV
z;{1ZE#@*-7HwW7@25ZM|v&AH%f5Ztp3|i0Ui|L;SjJt+pw%8-4kU5}?BLf73PjH-R
z^p{l)pXGzp-zpPwQAS2iuD#QqQ@ac-<<fz#4B137UHQQ}SvKZC6E?$_XS`;NEJfxR
z$}0*61vd^1H*05^bHd@M5C~>k%ea;t8+3c<k$hJ{u7!;wK8z!~;A`e5SaM#H_9MoQ
zUW^`K#bXI*0u+pkctJa6fO^a&g#^t6Uo(xQ75-+1lQzQ8yqOI9e<IChV-TnfRp$Nw
zADK2Is{Xed6Kb<OOfG(U-qf{Rqj#?|xWBmebm8{3f*!(c;ppX}>1?x3fADfao0M>i
z;mrq4u0vNyx>FMFu>%G&33u!167El*>-vT0Pm^%Nb6`TkJ&Z}X9b!_#&GT^aE<?h7
z@gazOcMIC<yC8BRnO{F6Xdi4yNx1b=`X<qIvnt{K;ug+&rP(E!6B6#tI_GkuH-3Qq
z_3uBx|NLqH)1Q;C4hZxBWZnJGeJ*jI_CI?-5)LTu9OZss=UFWB0E;7E9^n3Y^ypFL
z%>&|3kaQc|+m6_5kY00B3ydV|pwa#1(qZw#THgVK-|5IZXh=Vl6n5LC@S)2!?lTV>
zy-e6`u)w}=oU~UJb}xEt>ozWw5O)7?=rAdyg`>G9dW_?n?|ijb6?Qv9P)BCM?luU!
z_du4N#p%jo>4LmSpMK~fy?Z)tb-?LJ3A>HI3A-KUgK{7x>=q)Q3#SRYEzUCy5O#m@
z1wEM%T??MWhx@)daDW||sJrhF#M-*Vb?>J*1`ZrxN6rEf_xHFCe*QTT6X{rbA&@AG
z#j$JNrHa4R@A!K88Sql)rfvQYdMFkUO6kN;!jR)-V<lKj%1Je;C(UFa8A?Wi>yibv
zl9Yl;iV}b(Mk?sHkJnYk)Y#R}nNbU;r73P8iS&s~r#^R8za^Ox#?%QK19(qaJUiv$
znCr{zkTlrT>6a<St3Nqn{k^uyDa8_~p}32aN-If4lmKCCI>_hBPo=6*HBy)iPK`+>
zWXdk=OJhqP_Vux2>We)6Yy7XyQ~6k))cNUY*;C74lCN;;w;TZo0^!YqId&Cqx%Gf(
z(3p<g%2}_L0j?m!pST<oO$`r=n&*yL9m6@fYn!0G{c!BaB|7IkQ#vPk1ViCfq6Q=X
z;Nio2iYluMi|AMS8)lbPHBU0p@B6x6Aeqh0qXtC>0q8k2ptWmwUdO<J%T9_`hfbE#
z*Knpy_;|j&*5F;po1Nu?)OaDj@*}ZxCBqd*iQ91G4&Hd3HXRNGc}ZsuIM?Yl*B@}1
zR~x1u&N@K8!7k?@_tRnJ)nnxQL*!c)q@E`O={twB4s$;r%08HNkQ_fuzCA?WK1{wl
zoOSRAqi2!Rd}NuN<9Eq2W|QC%F?@Ku)~<I?JuE~H@-{0k7(F(78%N~85rgOOq{5Ny
zJEe@n#`Gi8qw9}YoQq8Pqc~3ILF6yjw6wOhj=W(0eC2?Pgr8Wu=^z=5mf!}Bq1mML
z%P;A-4^3J#Z$6i`W5>Sv4MXeeyQH^$?Sjd9SQq?qvE8`ou*oYKv%7B7dk-5tNAgBW
zhYaaQh2pq<@lk{4AaC&TP*rh6TF_cYw>!`P(#XU3qdy<QAJHB@tQ<Rhm~$mU=syxi
z&UNSzJ6FC%oIRCVIez#s(W$wALfAjQ{E`@O{MV5q<jXJ9z{v$KO@90oFU^iGH>B$H
z|Mz@Stc<{ILDynk*N(MO88)^?!h$I|k+5slr4wQ7n7aP$_@BZOc~}}&w*2@nTjjZ-
z3-NbS-b@1G@ZQJxdx#Hq!-wfU?sFXayFmgJkQVy1dP(>7uiV5Pqc8Ax(Wm=YUd0`!
zFVN3f$n*4o8bLq5>Z(n6>@)hmKX#1%a{M@NJ$`)ED%yMeo3qd9|MBauiSW%g%FhV5
z96Ppbnewl%zgGTr;slY79~bP$k1PK=e!Tz36DI`Mv12Tb@CZXGMEors?LBdV(K8Ga
z@oMoI$pfioEBKJpFtVxgf2O{n>T6V0vJnB=v$$enai*E!Vn!37@0r;IWBEchmk{nS
zl^1mp%EGa*h``_`p`8JhpA^Kt_{_ZGzWqh>Go}|2uSwzqhH_qG)izmNLp27%<(3L=
z60DeJHT+s_J8!Jus<Bs9_(}~1e(X8!N+As4o77(&cQv-A3l{eP<)ysb+`KnRmM$+A
zhg-)r>%~r;Ks;r3eR|C9D<I2;mBloXnbw?HmtDcl%5zQXeOa96sx)YK++XGD-R7>W
zlrGE3%SBr-`{h5w2BsI%-A>rmZG{c<Q^3Gxas*id^NXl!z{HX(4hUgYB&o%+iH-l2
zSgkRI;uy0dcCgE|-$YmNVayhD%x#`SW|CpH++%H~E~XIfR?CJhv1*EpHIkYjkqBxP
zSZk$LVd_kR9A%}A1Xh)huqFyo<B`!JCoEI23PT!<<;i#gqnzPWgTyeM_D0JpYv)&q
zgELw-&>!gDu~G;V+pJ-hptE^(dB89pge<R><4><3`9tD2-_it!2KlBTvBK67p)nc5
zUnp+qit6Pi**tXM#=I_DoOHx3y1S<FrhylS>%#OE8?PO*&yhD~XujFoy3z}Gs?K=9
zD0q|`S=cz*-)W(*)!XOMF?rpV>S5(mA6R<V=T)=#ARH6RfOyO<k`2X@qyLr1|Jrdo
z|2SV_62{J&>(v<PHxuSJv<z}^+4h_@ee_+wI1Zw}b*p2;=2<eA3Y`BZo4MXh0=Lq4
z&mLR;*R1RYT?{G%zQG;w;X+OaSJu+yh01|`*wCx|4Ymx@Q8vKuGX8mrS#G%~*qoyr
z_6)a#?p$ql2SrVnck`dzA!sg)D9Fjr$Y^o}n=0<pm&vGgZjW`;toFu@bMO1Iawg|4
ztd;fovb)|C($y*7J@;Yv&HP5b(wh3Vz5w>$li*0_qEA6aMI7ifaVhyqurg)~X14OK
zC{II&f$cK;UYIfy(`Iq1snv^9c_6F%>V>P%yO}<jw>H!q8$8<Mba}$XPu)i*&LY13
zF93w5Yf)R<;xjus7LvK;^pg*&YF1r&=l4oh_)hvz$ufVru9N@l1^QL@Zn`&bO{gvy
zFM_XyK{<_2-9b9n@7@m;>#wYB%a*mZpSf`Q)VcZ(=*Qa0-#!_-h3+j`>8mkZ#jq~v
zM)`J0uSzSDI$&xiWS>TY1H$+TWf|zEDIFhxyt6RI=SawT(FV+PKEVZ1n}Na9B$Ff(
z5qLU+$C*Sh`+nrxZ`-)?ta;zPS90IN0RWPoJ3ac@Ve+OuuOf@D8F*1m9IC13(mR_z
zC4X@QEuoB9Q=YZ)8G7NUw#gH8MrYxr@iDE1H~vT}yQlB-mlyHrJ*{h6mpn<|r{f2E
z!rZ3qXJoY(<yT*n+y1(+X8hah7B8Cf^WTf^td5QzxA?qeIUgP%PdPFoy1>|-Io&lN
zBF>>V5B``u;VgoJT0wEp(EK!AJ8bxbjsC1*?u-%D1$kTgNNe|mz5e=^Wp2~ryvWjh
z^b5LRU^vWOy=`{ZuxyJnI0_PrF1l9!n`BXC7)D3}J(%NS=re_B<*L7<!K%*PM94Ab
zr7eQK#Tp<6T@Jc6P1Hg|H^EOqdxD>mJV(1F&l8BOZst2m4NP4BF&V@7#LH7h3)uEm
z!giQhwqWc~uV9gj{0t(L(T3^~%2Vv94li+-R^kqo5Z3>VzJGEz$(Q6_?rl-&A2Gq8
z>6YmEo(6Z1hJR|jXzmvJzaMMRcT42<Zi8w3)^5q#qq(NX(L?t1NVaZiTer^GW9<8D
zx9pf8^W{BS+XQ{zS5eVuNZ%R(WPrh^=R!WM?BioAtuB+*CX!pC0-P!buGRXivHoL{
zPc$3c;ugKjV2B9<*`;@h<|tBWea>7?*b=w-jKJP`N195CPTnC2ANF#>`X13To+s<V
z4ekk2e*;WuCUCs9N3xFP>7?<JX~M1^&Ne~5cD!Q(g;l<7EWfQsFiwz!EU-hy%Ka~Q
z%f_)H|4@t=E$Q1LCZk(YK8cxx*jX;C$!#HYO3Y;PZZr6-*}PNhgQbp(Ty6A<h8Ue}
z^m67HQW$*B@U?L({5HAJA8wF$izk3oDZ=90s`iJ3Osg7NM?--nH5&Yf>5vC6N?QR8
zsWrf{2gO5pD>?(-N#Ye%VRBKG+1Tr=WLJqO*d?kl<w&STFpC-ntesG}Kp#q^W`Qj0
zZ>iN1SUIU~02GL1nTbTq#A)|0_sU)4Pktc2X3K%>Le%QVik6UUa#@I#ck!;VoF&Se
zv&_IYG)?tn5UVj@b7;~h3Z^I|5}bvrXl`imW+`8}roh>^s7r@^j7MXflAa+MEFP2D
zD4V8ue2uaxi@<zduoV@#qUxPw{R|KMwHhLV$&Uu?KFLeDsK!iNrd_*5Hfh>*=4G&k
zF}Su#uE~;Rk;ar`mN#qd6G-|}-l7cvaP$h#6pd*SbogA7MOjr}-xworIVVW=vm}Gf
zAsM!5tP|7E5_ATSXfka!X(oEoCrgG*-fp-`W6dphF0*CXwAW~?Q#@zMW^KgeRQb-k
z<a?nzmXiM_B>Xk1mN3($WnM%l;me-O-k>!CvH(s8ie*R&*~$xJ9#i#?V6h1e*?59P
zg%z|F%g6*B%Pt(?`UCq5JGQA;*hQ>Zq((qmsC!sAojRBArEm1@s+~=UAg{SeXut1*
zh6NnC_s^vKwx-X*WPh{rqQ`o9?ssu|ujD1eBHg()Ihf>WZU1QgE3KoyTk8_u)4KY*
z^=|HIgR#F$HVc14c#mWuU-v&U;c*h<coGr$`!26o&f7nma>3TEj~9eSQr*_A<R_Bu
zHPGjlE~PI_nL<6nM#<B69S>vB3;Lhr418t(tFyRwm2<RoEe<Os@-{P|yuzAci_jNr
z5o^W=7BAlK3nstWmj>B-7kyLO4d2f*F*dG9dm7%v|C;s%Jazp9T^f;C;HN7>GFjWI
zWEv)*1i8i(KL0Pz{=E#0d?1P4eBxc8V9erf1mYcF0#x-^PaPOBrv|D<DpJMo59Ns&
z6CS}%rBUfkyz5h?g2A4;!T;uz#3SziTng4nn1@;KlXmysAvQl`1qd?Z3H_h;zok2)
zO_QM!zFa@bk<+)Vv%Gc~sTwgvIIHid-KZ7t&*_auqo7UvYXw1zP`%gW3uKN_Q&)~0
zR<E9vbPj1u<^RLU=~2SI{JyjD48Ko_1dH^Y0#Sa2+WwoG6~_B4r2>3CJFOO%=oQs7
zn5-wy{@XCyZ?TR_BDh6|{Zxp(ZJu;%Z<hFhJ>EN&7d!3cZ4>G$dM_65F3z<UNkYgJ
zb`%Tj;5LRuuE=Jt)R7{4*n+{S&=|5r1pp?-F((N@V}_p{k<?gX&;&I8@*3*{!b7(5
zw()i4FD43pDRFqwR^E=={QgR5ZfheaPbEOE3i{p;d4tXrGKikhpiFQ70pSCTKg`o?
zV(qNzMJ24?tC;aDSV1s>&#VyHkfE-daTGqtH1xeMhkZJJRG|JQjg_8I{>FU*<LvL1
zC%8fR)J~5W;$c~m0xr#g{O5d{*yhbAe--cS9mg*Pa>8|_mF`P}rb`$7R_ql&MNOFY
z=we_V{wZxOv=ui4>+oja9R3A<hM3Oc+i4%+yZsWrhL}7~0yo{IYGJ?%1=6`eWE2@g
zCP6;8kgNcz-8vxJZ2^M&ZnB5`h3qBIl2^!E<U<0+DLFxYCcm;To{gc2ZxR-R7$xKC
z=g4Nc%8CR~M3rix>ts~w?{}~>`?oMPNiw1=3l{p!*B)pd)ezb3OboV(y<OGiIHlon
zN?qc=2u{wtsbmRLo2u01ZweHN2|9J{2CZF3<UeFi#invIwJeq{b)AY&9aG_ImH$0i
zDms<i{og;rZ^;;1{J$4>Dn40j_6&g5O+47Y-7A%dJ;8sODwT_gMO7(j@+kK986Or7
zymXT$aK1V4m;Nt=V1#cGf;n=70Jrl0_UChxScq`78egVZOM*NP$kM(KjV@t<$<+6O
z)^VraVK?|9_-hJfWP~Q1x;!rsi3A$Mk&MvUp=c!Xp5CDGZDC>OvBZx>B2h%J93elC
z{L#>Pp%5~#phN~v@L0@S1CdY&fw4eSG8-!jw|wu^W#UG^zxiYAmUX9UFaau>EJrky
z2xE!W@_ew^JyjjVsrN#iBu_|vrr*j&ouVPOsU^^FNt5`O7khsZ;~Iaj!XFS98oj+w
zYwr@_N+ulT^}JRWDU&r3zRG2E>S~R4r>@RuvzcnSV5rt^^yn&GMi&bYhzQ4-$rgh1
zz7WaGif~+JmMD2RF1E`ax5t+SY?hGtOdNz2s)}a{K9+6JvGZ|wpednH80SIyx*&*l
zpA<y+j&L}*9bwy0-N!YN^hrQvpBN5>CL#R<gaQ7Ol@kh2LgGoWjL`Ks($^yacKtE7
z31}Y_8h8{pniPvg5RbTMXmU6ldO~Z}d#0jvWQ<M^u~H+!^E4ix#7=NqR!WfF<_VIK
zjykgx>{c1!aVQ!IBB*mn)!%qX$_8I4;oJ8&&ShF+w2gvjQ-3OhoH5Ch8?^g=|BED3
zir`kVP0H@g6+ak1tbJ7b@U{^nJ4SZ3cXYIO;bhcErD<6Ea530>5Zf2@A$f4`8Dc~4
z^NDT${ukB1-sgEo|8ZvLmD*Bi-kd*wMKO?l(%^Hq>sOsdCoYDzY8LcUYoK+`Rv;6g
zlR6tC`pUF(F`{3Rb{P<C8S2k1X?Fm<c5m8CX>S6R>Wj1^kgxoh_6z7S4ZLqVL6L=2
z`Dl?kvbT_77~4l<Y@Y#Kf+b`nMt3;W5P|ZGl?K+IS<$d)RlRzH=~b-q*)XVsiJ+>m
zLuip9V-yyD3t}ORui$VZ7l>a7KjbW?P3FeHs$Rq^+?jv}uOk2hjDreHUL!>!IhMA}
ziYcQcp&{$ek}FC}5}An_qm~m#a9Nxsg$`}992Ak_hBAFQcNHs;m7Cy?R5SwYAbAfc
z)UoB2S`D?l<Xu5KA}U(uW_2!RIV-A4%K)Z^swa}T5t1yI>2tEvWDK}}?83#=KT$JQ
zP!&3pnxwQutr}p@BT&m{&xf^rvTmuWuvOftbB&IEOkdx*RIDkHh3{^s@6scGCFHp~
zg|=2r=Mx8iJ<<H?!GC^!;QQmx-TTe$cdtC}SEcF1&j+4+{Ohmhy|DG`dkOi02$u+r
zwx}&SdFkal9Bq>gIgZHWy6HF2&v#7<#mE|+)svwqKjS1lw0)Jx`$&MLRrcAkxJq)Q
zrskQ3hG}`$`lk%gMWCT=6C24odzLx(Sz}TCw2N0>z9d;d!xV4P{ZCmf4Howl_pnL1
zF}YuHWSitT*IGA>tBrX)e-3z+iB*diRdcQN&iMYaGe(I+mC3bpD;JVAj+ik|X}iSP
z?tDY2I%9h4^j7Ykwh@;ICK}nfaPunVPHW5-eRk(ga{V1MtPM}l*X!#^dDvgC-0AUK
zBjjh^np@AkU0*+QQdf&+(vF%Ma=mwh_3AhL!06mZc=~SG<H#h1I$`Gsu7{qbwuU{+
zo;8^-v&EjhWpwqvpSDLir+xVK;<u~oNZ1z|I=A;L;rq^sea4w@RE{o9mxO=J9oMJp
zSzR&OA&5GixI`EtYMMoDp1IlbYnrHO;^ln3)N22eyWUMlLUTnlG{-jUnshvE6%9?I
zp1dN$vx!-Gx9LyKCpfN|e#bIN<daxax<T2?OU=A|0mn5gFl9ECD_b>s&LB0#H%Zzi
z9V`%vQHDi1$yta+S8s@sTQs&NqfyDI5u^`z+=VN0+L{bL<x`EJi8pbV+MC?H+Gd^N
zvACP!WOE^D)n}4Y+)>oL<!*A*(gLBWV8;Mjq!$M`$RSaW8Y*AdKu$I33|pEO2u^EL
z$ozd1Ez^0LV>_g}d6Lj93UrRHSqC9CE9YZ%-$OL@qW*1XdXqC9<CFzHEr)3ykp{qz
zm=!iM9(cCQ0IE(wT8Zj6oZ00LhqYrT^BsWYa3SbQf`P#0W(Z1bgYs|U2XIS#RZNM=
zekv>x<BlT$8;j3mjC(sW77<zVh_bBz=5zlsXFtEZL|9N}9eQt9jd$7YhrRUR9pq{c
zt-OP4@G6&%igFK<Pg<hNJz>kLNy?xW?q#o1(#n16RRXQtk6uM?;T~T6rgCWuIXR6E
zZiPbj=Us-ri#+WkW^ACX7ffr(5Kf$&P$hb7Z_Rd#|FF+JZ$tYDxu$uU`EUyfn&{#d
z@~TOBzJ*&QH!7nzXVuc)Jno8S{ub_u6-spr_ttVH+RPnVu9#Z5lPi=FlAc?&g32O!
zd^rSA5B8kbG`Xf)A`ZIz0<lH4JJO%lt_e-{2s98=?FvksKenbQ!*WR7;IAmriXu}w
zOa>++F`lXo_#axXAB4px-v0D9{ughbGD>ie>B$!Rpzq)ap}^bs%1~jDx9=})!W>WE
zm4k&f-oDkP!ltrROZ|r?>S-)*Ex#<*61&)TIN2t``?ht>7ucHZ=(4tRvYWEUH_{K2
z4S@dSI_<exZ;B+Jxdxp46rTHJ%z!B*_X|}N_dm7<24vQcz>5%5Pn_bkG3Hqu{53I2
zv8KY|sYRt^?T91E&Hjfpsq53zq{>OfWg_ptw{AwVDai}{;r?T%HJUiD27ld?>L$K%
zM(r8&8+JuLV|)4~+rNYu+P1uA1>xt^&cXOxQ=@!aQ&U^5ra3UNeiHSrs9sJ2Ecad(
z{S({K+n3cW`}Y?zAo&vH+@9X6ertDW39`I%F#X`}Pko<`#<_A3yDL~Z^AACJ<?RoH
zAJJz&^L?f~QBzY*_T%<+CySlJVvl}=*oP5Y&w{SRZo!Aa5AiOYX|426^8Jt_Gp>3y
zxNk#&sy-=g4(ONP>;iUya=9<<QE-u7VkmK#O{4h2*-9{ZfSN71KOkJN$J`lD93#XP
z2bT#F8^-Q|a;+Q(CO(1Xvntht64<F2geB7;EE$WiC~k#h$#?w6MbiIQ;qv{3_f*?W
zIup<m^o4z`%D=M6_^hlyS7v1iW4P71JCqOmM}glq*4Fo~)hgsWo~!MjMi(w3Z;uMn
z9@sU$U=eh-zISXkA>Ub^I_Vn`qGQ#_a&t4?!cuX$aC}{RKifUVcFK!v|3AOxb}v~}
z;{d2-Lqocwy`^BuBJPR?_jz{nl6v==1$hkv69;8YUJh5Lyzyp7Szgby;+hxg$S=wp
z#B^1R6AR0S)hcgT>9UTp!tTjs&Ga}snNn6y_FR$0NvY^>dTPmw!)lOH>Od7wV(Y`E
z`s@BbUnJz`o8)s~zZFyG7N+3`B;H6ET45GDqX3yhSSG<@r|#5Q8gBt9#|X3p-FOPs
z0JLaU9C)d2;H3g57c4n2F|6`AKP!MZpVs%&(Pfzi9Y1(;!3DlXgC)Ia{Kdu%u40|Z
zR!@qi&?7|?U9OBk2qcfLB|4~Tq0gU_;R`w(rL*YK4?id8aWn48yRY|0(Ny0zpBqRg
z&_4Pvpzg@<3b33k1hV8AA2jaG?=TL!=rQ}t(E-Lm^j7MDQOlaaS7yeF0s3g1UOcUB
zXMTQdP9!{XD;-U*rx$$t6IXlX&)jRunJ}}3#=4NU9as@_#0T)zdGWPXK%<&d?bEP|
zw?}L$2n4<pUNyrP0sFwd8XhD&!1x{Uh`kaD8xs4B=GY$VdvZ==HQzyBlU@}jPAkhL
z9ep?VoFV+s+5ab>ID(%u4vgjwa-@GSAK`ZlsHEFR4VgDIE?CLziNoe~8v9NN>o2|3
zeN)A#<t_b1@u64UW0?pu`o1ZiuG#{O3nuWVu9jcM`{RJ)p~JN;Y193i)g80RiddP|
z6tkFOb}5X!#s?1Bdo=FEJ7OC{-%I=unUz$I#`2BP2<+!Xa@CMaCD~6ah!w~RCz)6c
zFqjl^65ZFsET)DGSvhLdzn*_ycs`=s)oLLxtUl5EFMehJ--LMuBdlh<p}oYIF$&Ij
z2Gp(X62{m1r(gJ2j#dmF#P#$&$ZWUh=4YNEi%`t);lHT+A6c>dFuHtYi!jwXrbGBM
z8B4`3SiW_1Z0zc-<T?fprnN_p$}2lg<{pcV@s;P~{;-B?7vp+K@VE*&*yVA4ySx3;
z1KeEla(bO|hj0lqm+Nb9Z{LVQ=!fm}<J*Qt%4qL^E~v=~X``Vpdk^fhhC;%z4jez|
zm%s@9wB8TPZ$2qCuBudxf7Av8!<>B{C2S>!0H)=p>X$P$lth!NZrh!Vjzha6F%q)x
zOU>;DvL<n)-U!o5NyH}es-Wu(&Mhlm9G6Odr^ybE-aST#!>qA}=PoR6y10Bcy_1f7
zb7jt`;ki}-T~sz$yV_0O{E{w<KT_iG7_Pg5qz8l9F@I372=jE7Ap@Mxjf-VMhoX3?
z<uRuzP$b#%Gcv0rbD(bYutK{jr*Ej3-DVnMv!%OD_KW54fNr}h&z0F@N#_bZ1@<wW
zw|)^F0PctuF2@_s9l9mZ=*kl;1x}BbGx_pc29EI6zE4gZBkt+3{DpJVWl3i&>Kx_C
zpLlMSp+{r#c|u|Hjw_h!%9u85h^`~urJuf{nD-E|y-nXPaxme@td&YVrK4m{;~LS@
zlxZ6-cm?-kOC7_Vj`XEgOUM?<C`&Kjx?0=cF4#?@yKnn6V{m!CNfRAdT-0#Rh-*US
zCVW1SMt1$WR?{dlZ#N7Zp(1S%tW_66B6(HXt!WRY?T3ZMCqSnD1~^}e%GGsa^`C>4
ze>1$6bdqso8kq-<?m6J-UI7m!JIU?jezK3eLf#>NCx^&)<Rr&&CeFzPV2oSH)p7&5
zPHr4GlUu-@#huHo<F4SY<It;Mv%%B}62puY`Zrj{GVqc_SAnKd)ak~?G$@fqg=Z*>
zWbjFK1lGq`@3I4M2GML}PPpt=6>(IB1vW+{U}?}x8H)iKFsLUwWhF>Eru)QF;EqfW
zC^HE{oZ?1c@Ml^-N#2B-ErGNGO)Iq=)D;eVaQCFb6e=eJDMG~pOn?FcWigIx)n<;d
zbYYH%6fmh%1-^&@Lm`pUg&39<4!}}*m^X8V-{Ms5@R*)Pq5z3~1PqG@b%#d+RseH%
z76ii>>Rs$+s<_wb#`8h$TZW<;b&AYjGcYWRxSI3S-C5>Sw@+2aoq^o!Nz@uAa<k^d
zEuE~|E?KQFdue!<-z8<4*lm!`4N+RMdPtAF(6eGsn5>Wb2I4Fso+k19sr%!$zcmN$
zfv0h*ZOdAOJy2rYK{EChS>wPiGF60`s4e0`%O!4!n1t07RAgDoWRqZQK?3#pQ9ZO3
zdl>fM8F2>^X&Uv?KwC%Q$>%EO<%wo}ptN3ElU+~;Js6J<zJhGLrpkA6e^s`aAxeV<
zQ*}vmOKELQSyM}Cbx}}z^5a5ly4yTZ>M_P>ZH?C}R5eJ|#N=D7wT~3Iy%R>xx^RX;
z_R8iabC#aZNVjB<atI4EW8tvBxYjNirSoa8C1SR7<IUchpeQdiyi#4<+FD#yRopzF
zq*_di8BV?|xkI9{+$etUGF~vQ_ggs%e+ENIwyD7?j23{H;-BIcCD(|`oD667jn)R;
zXhA3H^s;QY(PZ~%degOf*ABnNX&ySxDhZkC*XQaj26NOEztPHkk{IMp!J-o-!;>bv
zi|CYq?Ajg>Ig@Rekdr4E#0K%os_ZPY<kj6M8X81#o?aq0jZS;3$!yar9=*+Wy-T+1
z+6@(uCbo#1Z3AS#GtVgS0IabCd`C0W50nqBX{ZpYFg1wR>4wPozh2Ten1tC9JjTt0
zRSsOWjVvt82n2Qjy~l1aiQU9vvW0h;>`sH?g8S<oel2e|kKo4$R*8?=uBgc2bP<Es
zybGpEM!Uf#jy3A+fg1#kEkOFz3;_XN81cvr;^x|n@@%cn?h$6V;mcN%<aR?55E_Z8
zK|i1|WUUdM86!=?G7f<AK8xREh3~m=)-xkUya)$YcL3osBkJg{fKQiDtf4+DBa%r*
zbK|t|1e4*iD+e2L=p9oFof(<DC8E)|Ji{Ap+Wqj`4&sRfo%DdO#^`aob?_ce^lOa)
z;LSLNwlZI%Mj8^+-roqeeyph>6SD%DX$adTZj@7(PBY1^85uG?OBW)S>T*1iAaFT#
zC1D_O<_z=->ALCe^Ib022FYWS%-kkkh={pPz58)~u}@!Fq@5j$Xk7d}m-G6%B0)dX
zle5eqxQK7NlNcrU2GPS4!UZ&(=^{XKcJ0m_<q6wEVL_gq@30Ll3B4Z55Iais!TEsy
zF&i$!eK^Z4=5(XiaXyhe8e3+r{77W9I~;Nc^%r+rW$l>E;u}lzwWc$9$N7TEW4KJP
znk09XJse~BLqd5v(4Ad{)mocvpqbNVFBbHE!xg;4Bol{em(iQ67x{W)sZrKAtQj$X
zL(rmgYOR{p4$nOHjNnUacu~w4P+)d+TOY^*%2P!)nGg(HIdPfSe@9l1rl2QioQoy`
zbT_#$9rZO_&AAEjh`d-+mS;7#`TpiD7Xt8FXE$1|Z3qame355QL%}$FnW)fGE$`89
zbUD*UxJJTtL`k~UQ(Pcsw`)27DnX;oW=2MXL6cq}_k-WQ1R4$N;Y;VvwEHoOevx)K
z?dbo~R$(+5539x*@Cde$EX6E)KIYj=VX1yC*+y=|O#2vlk-SSjAYYK9<VVuS37ipg
zt(S{(d0a79#np2y++c15hjk6~f|(Kn93V1<-&4*mG4Wwgj%Kl0G0uk1V&-@irlS>E
z0Pw-^h<OlPdo~@biy*{Rx{-oKF%2Uanj!`xHsCZd1(z~F19oC9gSgg8c&r3)H$JH|
z;bw4Rab9u*m$#A?q2{iP0~?MJmAq8pER)qL!HGFjKE}{q9tScB!rZE`mrV_TXmYD=
zEHKEs)oQ`>c|{e7a3=tz8FkN&7~G*Xo^W;N#<d+AkL#3^FO{(#;jz?bM(PO+1~m@n
ztPD4fEDbv+5qrXY9%dM}=0nXf>4U6g=%pY`93@P{2PZB$amB(hF-M_I?QkOw;mM>f
z87e}_YnKdzIT=eRhQ`KPt<tW}R&2g;Cg&|kp@CbQn3xcXD@HT0Y0HU+F2kf2W%D{_
z^W+(3)@Wi1gsD8<cv*QRAXQNjoWxTnEQH0xqjFifGZo5QwBZ`*vB!&ogdCAbhbI6N
z<+L;AL$^}y=LPBHRayYk@J5)ILTgBC(E4G(0sUjVa<?dO=^-c=c{yj4*lfVVG0T#m
z2O(>ewOX4ogEQOt&w{X2#_Km~1fR}q56=9czd(3>aPL1Q3#Nozmn2z?W^NJ`%?!Yw
zku!)aYOUpWW0@|Rjehfet%8jJi3GlcL=#WUZm6elTvQh$Hh`MB2$A5p#VpA1lH_!X
zexY?ReTNhc7Fw4xIEw+;vuk?mBabW}#J3(p#4+ZK46X!^wc?Mvf<A5``TY+*{4jYR
zKq2`wzqR!k60`HK1`Ya(9rx~Ch3Gew!(Q^E@*Z$Z_7&&U)Z`Qw=T%hYmyiP-S2v(0
zURGbl^Vip(%k#}d6yS}ETriO5Z{WD9rdpoIdZCr)2XR~z$30@C6D_1;*|MxiUVbFA
ziG(=(7sA>zR0xbd{1<S34*%sgTTD!s2y|mep`f0`)e9+|)S3kg&s$)R1Dt&`kE4ZW
zXY3*e;L`{YaNaHGIni!6=a>b%-I9yFO+XNQ!in}_c6^dtuwZN<aRy`|&noHc>5^XH
zM+LROYxaZ%BA{vE3{}jQ0zixP+Bwn0iG&m2m_QOu!orX4BU8-wba~*If1z8fqZe~L
zRd{Zs@{l5PuT-7MG{?d=Krb1!T)!*bZ|r|k=Qdkz65|qIM}m$l*_`>aSu0lW*hb&n
zD$7^8gHYy6zhb4)Yqx`I2Y3~rzHx#@<I);ApN9bjpg%j(#k0fVYX2+2s>sUF>(MIz
zVgD;3dLRhH5Bh0zV`!OQA!I8z!cVIJi<Jl~kG_IL<xwEYLbY1CzB1(Vg`fu=3}ldK
zj-g^&YwNTM?6dqhd&cLjpod~X_#My~o@$MTrd1kRC%0DXCKubVt2ETf+uwcn)$!wV
zfGiCyJOdvlQNb1_g}g<MO17wMHp@7Ti6D{SNX8}x;C$8soyhc<;H?1cA0{Gig;*4V
zuU==Kju)MxXbXxq5zt3@zz0Qtj)+bP7a_Yh5ggTo1hX$_E8>aH>4eumN62o_z@INW
zI7Ob*VSdtLe!5n=L5g6tHvp30@o7_FQ@;dq;B!=-DI4IN%z*{gG8ky;plJs(8+ZfE
z&$7AzPdFG(tf<r#6R&EtCC0Eu!YnJ;L<6ol8$=RI|4K+*5D+72Si?z9OIoB9G90jA
zAOTJa!*96vst0B)+6AApzUu1hJo>S*VRT2^l-)Z%d2lmKIky|CCYL#LgY}o5vF6?S
zfaVg?V>EcC(x>S~zqHSo+r5l`aryYQv}4^hPh8kGnciQad_K5_8v##HPtcDq9u&&r
z29ud9lv^`Lq-T)}3I*!rj`X*a)wfRT2wivi6=N6n95O`mdN9Ave(>u1*PL-_q}nid
zN|n3SUn7XuJn#v3Bv8BDCiCOXtEQ2*sqJf@xb{N2?~3QIyMoHgy5`O14HYzNY$jdE
z42Yosb=kQKmeHNclS8~EkzD%2-S&O2tXhTkXLc$t$iG0RsuL3T-D#hu9RPOCKN4+^
z!8`TKV#?cCa3=U1N#;};ro>EZW`s?9iJyw1sV?Wx;D7ir3zpM=Z1tM@1@JoHZ8P;2
zIfSPsp(=*@%1Tezxx}Erim@DhBF1bTSb-`yta|_WsRC04Cywg-KfOAb=*q+jr~)v|
zSG9De^(z0O6D)wz^h$bO11hk|%Llk<`&^UHSnxy6u0Xvx=-_PqA{_vp!<`nZscTn!
zXkKSi+?bU=wqUBs735$Z3^!gFl{7lL!77`yZQyc?7Evo2EiT#A+}t|Z;^ZVya%R)+
zTkP2euSuVond!Mjtao%Si+Bb?7g^8J+pf`T%sTp4FUjL2`l8-JO0;mF=#GgxvyIbP
zC5uBN8g&j+xUA8UWlh)G-GLmb@}+P?U0vZ=qi4^XTw$ca9J2bAD1Gm9g;dagSV9g@
zA)W#L$GADhi`sWOa^@@)^=9A58Zyp6CR-w6+q<z2i(k}h4+ePSGcRC<Yj+Qb4sWRv
zD}!}`I50gt;!Kwad#Iezf%@EsmtXq#ap9)Q4vjU^R9B);KX17uV9n4vsus@Hbp#xo
zWQndXsK~*pj`ok?HF00g?WXwqv7yGoiAI0ho(`v37DG3OTXKE*f?0Vv>jK;ST{&cF
z_5-oO18rpijoz-YrWdx98~ipW6pTGlAvRR!i_Bh>>GyJS-A!DczcIbgnk7tHle6?X
zWi@nxCJt!ncJdloIfvV%K>LGXD$~XCkFbf*LUS>oN^9Wr9c)9^eX3k(JWkR8_lq9F
zPSr4bf~Al$uSs+?b<9ch7e;Hs$_72l5iiFW1N#~<`_yD{7+s>@fhJ+5Zs=X|kDiQG
zFTMI)>}hgGS(QOg|3R;`+W)fu>3GHX$L`-9yOT^e8*M|tpQG}NZ*f|&u)En?-CQYQ
zt>KD!J#%}ey%h62!3`tBl_QH{TzG!8Ei-)nXFrO!(Z}4SRpxn<?Hp&=J#*%9zR>92
z|I%yA8qc9)>D$>_E7|fzM&Qi-&(JSoH$Hsd%<@I_Cfe;b+TfuiM1P&S)Dkk}71X8=
zZnIip`rvG@u72mXXUX{*W#8kXPCIlFmmY=b=Rl36`QXoI(pQzM3nz)*%c~qVx2vnT
zWHp*sZQq^pX4w51AU9{2Sy5nSrDcNAO@I=oB~fNR31uB-9f{9ZW{_}YnHBK4g|Ci<
zS>?^jx4rLiW1hSgeuu|i&E3&ShmsY_aeB^Le$}Y{U+Eg|hc}f$bi@t(b4&Y2EqGix
zL>>bx?*>>HeW}c*=YB_PzT<vu@3<M}M321uB3(9`en)I~+(Exf)bBQVg~X*9A<Ors
zg&}bUzdljFI9nsYlXaqk=n?=^`HwYRq5P}&Yi`6{7i}gNUUe~dO*?HTi<HedmD4mI
z@N-8fdb*A~{F>59ySDKUEb5;$f3I?!{DqSjGcEKbbnP+Pa*X>jGq?T54tnK7`=6(0
zchet<Y4>jWBifMZp5G!bgI<>lnzb<?a;EeQhQYhR*i)EpiCTl?PfUJgIIuwzHHMHQ
z$$^Bh17j=JC6%C1t-$Jokp<vfD&dnpl5k0iUW-)=Rs>jjfz)ToFq8t9lchj=;DuS`
zWy(*z$H*;HSN6;wRn;(h*<<6E@Z^>&>Hg-`Wa3jfvGQ{#k~ZDQb<#z8oBL9(^yZtD
zShF@g2fQba8=xF{ma|c5;+nEpPG@w`FNV;g`jYlPWysu{&nTih&m16A>9CK<Tij~p
z`EKfbL^&=@CFji<H)h_D@}<Y;j(0f6b~h1cX~1)>cge+)rlfx^zw7q?DL3%P9UZfD
z4&6I1a^zZ%zhrnzu<>Zg^wQFpuJ1{H*Z%$~qQT%bct^k3_a*;Qe+}E1Z7L?ad&M5;
z&6&}fu#iZ2-@$W(aKqHE`ai-1cWOyhh1DfyJhnJRSZa}lB@|m4CE_^Myp9nfDnl2^
zfP;i_0Bf-d3<1el`QBf4%ac0jg$^&7d-6@P!t181#nQaWSyM9_&YL)(`?`sHV%Y;m
zmo*iHM~xaV=E9Lxc@+W2ta*>zc;dv<n;y|inU01fv&MWzza-wL-dVeb?pZiu+K`gL
zg?VC6Z@(~)K2;JY#q`C@Vluq%daiMC&%zn=V+Gx7hU97a!6jA2#)feIsLs;-(G4qp
zX_`K0@MFtX{hGGx>94xPxZMbnkk~%kNAfP;K>v2JgbrQYT3LoZ3EJ$}Z251ZA*pL<
zhBcWBx(h*QFF-RPigr7-K^n!xi#TXGIj#ka#ouVra`FyLLe;~MiNklaXbE|T@8}JS
zUv$xdWMSW2ZX`F7j@-JHjwEyGK+!<U$?K<Yy?%a`qT?3RkH~m>4t<min=u3Xvq`3M
zb>iFJDiup1RpMsE_~XO~l&0m_XZ^=Ii56N$i(cl8<m=uH@iSI|xqXYcVW`0H>#n22
z$pSi%|B+ry&fyA__j+&VmnkN05&al9KAY|(L#9v1el>|Ho7tH6>rl}z4#C%&4a+))
zzX)$zgrQ{tbKDBvMJ61=CFTlzqaba-kVkg{QYcXBVOzs2MiR*LPy=N11%o_gy)09N
z`aDEYjA~^L3oAs?Psfj(J=AFzD7U0F<A=2u?l`mdLT_f_m1|8(UzbNySTQc1mj_u6
zf8^oH%0VH$$5a5op*NK!^cWNaMhU{GY&bpS&N!yL#@T9UoIGNk!F3JV>NS;TM6=t<
zhUC*BWZs3FF0RTmEz>I3N!);fZAMez;%p3JhMq^^swUmwEp%A<yGCaZh~6g{C6jmI
zO&aYmz_qgZ^*m{?_%$pI%R$9=!3t>_>mgPE=Ciht(G<z4Ff%c3rP_miM(QsCpsKbD
zyH3!CPI&FI;`38&qbn<{nFKB4j-zeVW|0Of-*xlr$9nC`dFj^0jl#<Z$xB*8!zfqY
z{F1_EsUfc>V~o8_S+gq7V6==VD6S}~9UHAI$l)*B=Ph;@fFDeQ^iIf)E~*U{wUhDO
z1bRSe<*pi{Jj#Wv+BMvphDpumdPr&gnVdz?XHB2DlzPeMvPYghxWum4aq_KYYr~=3
zbR}KlK4|FZPIub;lg12Cw(!D0`m!h3l;;L5#}&0vZ9#X|NA{OZ{62%e2X4t2-Mv$O
zQG7!6nbCqVeuip+r?y(62PH^XMsl-WfuFUi!lCvk5X5N5aH3EBq4|h4GcLvxqfb)G
zS^39Sl%VseCl%ON$S+c%Yh6$Lj3<gVoSjvD+srd{=2c@xuebOs7nqxNyg_#8fC)Y}
ztFASt%6_wQ-O3!j-aJm(%60#fP8Wv`nKZk7^onyEw=5yQo@&zuchTV0_dK_s>!in&
z8QfVzly^DKHFRyDJFKg$Zz~8DbXHc7jV*5quq)1!%$Zd)xIM$q0G`A>H;gE>N$wje
z*Z2dOPNn=~@-h9KriTZ-#NSd-(9|>}C)^UA*Umrn`_@$+)jQVtp?~o0nPcytupC1d
z8}ENzCRK<w=vh^O3pzIWZNj|(>yYa2^rlrmRkd^C>r8y9vdBJE8TzgGu@wXx_c5m?
zzE+I&$=4!P&=muX6B-AcxuVurF|&61m@}&#JyWO6uD0AjmR>(7(lm5n?uK)0=hAKY
z^Lyy|ng>Q2%Q_lcCrm6`IEPz(<I`p>Z?<N;H5W{OhMW3#<va3&R8EJH>q4D9L7g)v
zR@7ZzY%8m2CV#8H(k;a&M7@FaIdlf;K6_nwvhJ2*<*C9&!oosbPF{65y}&bK2)U~B
z?x7Z)!I<YUi-pl4Xb*<_w^n{z;xR%xFhT}Ep_RgpycTqj$T*8kPds9cS7FeUBO<5(
zVC;e)r@9Vdjyf4093Yof;5V33q6f;NU4EMmq;HNnIY!xa`Q@Bj`1|I*H|PeTk~{*J
zx>v5dqgvqp)VFCpKdUp-)Bov%d@a38$c&EeII@toJxj#P=pH&=`P;`If6STgTg5ez
ziZLJeJt!PG+!x`e?0!_}e@=LVj$8WBYq=T9sQ2kTyxtC<8#29z`+{z9L}o<k>+D@~
z7;z5ELxthcC$GbMPL3YzwK4C0Y=BW|d-V+_NGC=!v3Cl91-OGmhQwT5DGwc3-?2L5
zhU%)8^17xU=$RMgWClYS1B`oGH_i&{v{P={u<VXu5+Q@E^uD<x+Gful*>(nb##Le(
z;qwJ_`j1~}n$p#!cfGczB$7_fSh```J<Au4gF+;KX>VNzeP#F=GuuYa2H4_iypIQ^
zFmxH%oW<UVA9N{0zs?69<A0Cp%Q*R~p(lR<bRagscKfQdEx?z!A?+rt-|vL~?)!m8
z_*mMLu!PzVTd3Dz4fQ_kq5ki9{=g@KO3Y}Ck&_@@pGD?^_rC-(_SMj=zX1II4X~ZM
z3f5CwVLx>fEU4}z_dpWx5M%*Ql4r<%@-lgyyiMLGACXTW7dT9gs_QQ1Jp(ddYniJ8
z(;K5W8Q+`nw^c4Oj*MT<!czQkl?R>-XXmLc70=S9!dTu^{?xg84H6}lj^$%vEDyrm
zEIhfX=c%$%ai`zsw6ux*a<t;~Fm|3SS3RbbbXa(@UVpqt>fY)xndVd(r<cd#{zG|c
zS{9eeo4OafPSu5lLEZ4wy;9-qnA+HLvUI6?rqZO!O&wEd*ipR)+BT)pBqNM%QrH^p
z-Ciydea0o86aAY7Q}27iN9)!Bm^Kob-_~}6-%mfk`s!~(q0)8hc6N5+dM-{Pkuw5;
z54UW&$?KgNgdh1xq<q~vI(l?TXXhI@slD#HDVJPQ-r0G^`t{^SdN&!P6htED*3=vt
zJ^Ib{>vseKTumTAX9R=vwMc}!2{t;j!r}S2>4puQ7zil2>({>%iM$gG@(n0%MrS9x
z1>L$~0}Oz;n|N>kebFd+I~Y`6M3jh{27{~=R*BaU@@{9Ra!ok=&gjwPtw5mv>Wqwv
z_3Lj$#Nr4vIuZGc-_QMZ-MaF&Hd?Y_!#nHO^Sa9}>z}CBfzzs0r!S*+*tieZuiuU=
z`Qb2Xw{!I99jGza(V=V!262PL<IqA>{B5-{QdQcqaU<E4dMMlh&qH%NJGtFx74<pj
zwWCLuC93}>%D)Qj_}6flPDxY~Y2KlCk)B|%WaCEM6;BA9j%b-EzDFwj^q(;y{L)Lk
z_2SarD}{@r>%!r1OZ1yuBDT?savRk1%QEY6c4r$shD-WTygvIzq&u2P7PLK#lS^`y
zpI~M=Gdhr^I2y0bRkmdDWO9s%VWmnvYe)uiU$Oi*hx^~lB4gw9nJh9P)(}^EqEUWC
zSot-|g;+caD9&ok{AXP0&)_m*pG1}8ae*JI)`oV+=u=tb36|uND0w1&bG-kpOnxvT
zk$+>>$>d$XiE<aAqQ}+TnOq?LdDb^sjmVhU|4vpTA4a(-XG^Bi7i~oNEm8WHEV3`A
zlw~y{fQ-*v%|gD(;{0(WA@ifOBYH_zBN<6Mva-O#%gn-D#PBz6;x|f8tdbZ4f5N*<
zC)Nhz(<TFDVKywwQ##(~!E51qRnPnSgf5!|Cb!DYtYkt>wy0F;4kvt^!KT*A469W@
zBpBl}8&t*zO$ho_i*8WOOxp;$MsAfk9x3G!%S3@J6+36g|LQ!IjvbkD6NH!<P)V*M
zFc4xBsuSc7zj0Kd@@!E~R?jdwqlV`hB1U7EvQw|ukUr%@Zk%LOp67L3)84&%zb`dJ
zoK!O|WX!fi=a367HtqGkPIm46^%1h;-;N#xzUq7Ap@+y4-DFAY5Jv0lny|-UPItXg
zG^?_#MDz}uB1A4cw_cm6^_NwrYsWQSPqf-{{~~{u(#-jkBgI^aWK~|5jknC0aqiTq
z{8on+*q<ZA=H5r$IpRjEr>gJn@#9y1_Sxs{?PTJN89$C6e{||pGG*#i1RO<Jry6j+
zdNFV6)Oqdg9PDFe>vZjvMqLe)Re11j@00gQY^IK@vvdM^|G)OAa2XKduSwg9Ihjek
zL5|@4LWIp;j~k?<$|wgFQpzYzEdl)%slcM?zj@7t1VzB=|F?I{aKlpX?*Gj@M#p2C
zjW9_@t>k@q)=*g4pAm56<>U_|W^Ja<BpNW=Tk9wEuc4PK8=*0Gy#epNSNVwR(O8rh
z;0UDw@BJUb$SkUh4)Nl(&mwD9h<iP+k)3;$hsn0nj*tGzu07bj;(PeP2gxGcWU#zN
zymn&HXx*Sa4Hl>Q1=nbU%WawH74;*E%cbSlI-Ny(OnxZo)+yz*azCegk!&JbSDkmR
z*RKrZ(v_nnT(N9c-qILvnm(O%gDtVT{3dhnGrqWZ5$gl@j~{>5r=Na?_dQ|y^dH8L
z|7yw<GHL2m1bl_C4mDtndNFUx6xIiL^Z~7|tyV*{wde#PtShdQ4+_u10zDHvI_7;L
z;kjuFR&aCR8(<O8zL@lC4eS^%hHd&LSf^j7B1At8>&5TWeumwm8&nX4PGKl#v%QK5
zh8N2u8R!_0b1_4D_R$l@S_YFDJf$?Sl$iXUQA;8N=!pF8>p$(=XR3;)cZ*c_V4wbf
zI!}eMqx$JX^9;U^8Hx|sSygN-V!9Qq3XUR@7!^vHgS6j%iS>G7S#|nyDKj~CpihA;
zXLjz4&lp9?YF<fBeFg4JRqp^S^n-Lg{h3m_9@d*OyvUv1yEZ8Mz4WGxikd>n?<eL^
zlUPIV`Q|9SpY$C5nv6bKXB6Pd<3@6Ug<d0&W%#?U$w}YJ@q_}o4l*bpE^}T)bj$Xv
zAR6_!lITtyt?a_Oa^*_t_PHSqw{+z42cDr{F4*FlnKya#u;+=pccjf^4VlB*bg{U;
z)dcWJjo!~SiM0hLjV$U*O$NIu9u8+;J@Jg$)354%R%?Npni0}wU$cW0WD{#B8oWtg
zm}M_7Yjx$hH6t2pKCh}9Y@^@j<mTpZ0X*zl5Ym8$CTr=1N=#EN+6G1W=Au?99GvR6
z-C7c&(~pxe^p2y4>20Kk`}nT#Oq)(mn-O+*2AKov!cEfL=H~X=T5hDl9`=O%{kIvT
z{FRPurJ<^7<ds)mU0nP{Q`3&Bs;!NUhihwbxuv-HWA(CIJ#T4jY$+}#Z{B=qEIeW^
z@jiXym0Onx()40jNFSl^La;42%FBKAEv1g^+M2d>F4PP|08VgZhStt43IsC4wO)(O
zyEv+mV>0Odm|r<j%9mGwqR?gN@`}Q~bYGq(uOJ^9@eDhC3*^1ku%H|KZyrmQoVKn3
z*g6v#Fv5~8*Vy0*Eo-&!s1qDK=&~g^MpEokvt<HI5KbOccP3D|iDU5!^JZwzLxrXS
z5_h$ar~3NoeV=_F#1aXoyxsgUEpLftSS{$HTj(PsMnBz}8822ItIUcLzM=EM&J81`
z9+*(cdCR+b$oI<qoSy71>NW`Ez!+M#fn?B6-&Ee>N@?i^k_Db(?WLDq>K$|x8}UA&
z?!aVxi@s7h?6C)iRgyE`dh4yg-o1~Gxc|Wi{=z*Prf<^ie=RMmsw}Dg$Uf{G((wJc
zJ6yuR6&ZuH12?3{Jwq)`mT{4$0`m=TU)ui^nRD4I?<`*YPV!WFb^7#G6DF*hKK)>4
z=Yk0nj!&C*VQ1%YP>jdOLv+L|GuCaGO$Sb!wg9o}9srUDpj#cqs<i9ZxU^GTjq%Qc
zS+5Q{*&U~-nK_WuFF&;w-435&x1`;kb{G7i{I&x9-AI=i#~3Ci8GM-e%2hYVczK{M
z*oX-FB^qaob6h*E_DV1g<JKsqBnYuFuDCHULKh!K5+S@C*jYNE^b~hOl7RqFDRCEu
zDrXTyO^|K;ZmbglfS2q-6`-9MU1ftoH{N)PC`$DNco+n{M^!Q=)la0IG)5n#PtqVc
z2-x01<ct3C5E`ttwv72pdnnIG^1Pja6@gjg1MsN-VGqUO5moq7zVzqKwAy%{KA2DF
z3sZAP7G60<wD4piz4nLABkQso9JEhzzHA8U+AZ~%*SsZ-5WV?E-@A-hHWJH9GJKQ9
zl}l$k)16B%-dyk+x%F3iS29jbbCbq?2fKD)%;P%fBQ!#epn3zzVH$XRy|!-f@G3#H
zr4P$BYT%Y|sME;f0gU7-sKg8^avQ}zDIfis_WVy|iKL^K>bXCK?a_iwYsC_(A=8(B
ze@R2bu3FfbXB!;hKidK^eQ~B$DhOCMK4~z}y%ulofrf?~tE;y)G_2h0FATKjWVyMe
ztImJ)*!C%O968b2dRcDnwz9HM)Fg|!b2V1w2E$DVD=8V!&@iA3LI%b=z8f|jZ>ur}
zMp;Fn`JV=nA(o)nm=qQy5#9-YOzMU2n@0q%;u^^JJoq48xOXpo&;*9-iih9&$m%y$
zWbm)W%0@o&$h*%y_B0C5{N?ZBKyn$B(%Wc#-zwqKBmLHx+mlgVdeX?x;mx0X0@}`k
ze*T*Lg|Iz|2wMQIVFRppMkf6!&4+DY!kRA)KCsZ!7$pYaEP%nP3MlHZ1GPh3CpuEZ
zouJ24?m?Z&`ArWf8Fey+hzK&fs?(THYH!4V$HOQv3PTd~b>M6{VT}L=mdYttg;DGZ
zn0ly#15<P<L*}ePcaE$2iIU9h1**!~<eg-7VKN7*0mjMH4Esg@Kj(K><ZDOr{r?<J
zX1%RR7v_l|!KTYP*IQ)f$n7r>qjJ!`sYydW&@^!;!Xdz81cQ+;2GQ7{{0U=w#@)*;
zR!&$7qR(G)@k=jWvf;V@w&%(F%0W)Q&7;e37ZrTsiYq6C<sc^WWe!qhOI)wh*||Jk
zgg=lHd88l1GB0Ry_2<-C4W(n+q9G|Kx?tDN1q-hEG%5`?IQ_N(@XF#7i}hTTe{lP@
z>^9wkIp*y4?OV;Qt&hx{**A2kvJw~`tpLmbD*h(AY-mx@B;}K_f!c2_dFHwGmpuO*
z&kr2fJ(I>@8hvZ&?f$y4U)HukD}0Cv9Bfmwv7tmFfkJ+e-CX4Oe~5bz@VJVrZ`^bH
z-tBw0_g<uxw5!!>)w`@NS;eyD-g_??+qi%YwgCg78VuMN2-v2Z-a|qsAz(@f9TJkz
zA&`Kj9e-!;O4#A${lDMyJ<tF9yw>i$bLY01GiT16@;l)1M5|2<yHr$Gf>T<hcnv(r
zrIOGbSMuu}P8ZMz<or1KqOb>W^hmUFB}DBugSXN|SkWyQmG^eSO78h_uZ(*OsF$~-
zOcvf`0U_;|XeGirP==S%yhZY5_y`SA4;IJ>gIEaR4auuGM6zd$_SYEY(2(MJly)rt
zuV_cu^KM9c;6OC`izKvgBJwp{{jzP5li!Me&>vi%d}_zzAGH1I8VI#t^z^~(Eu$2r
zRmXhak5LuYoO}TH%XGD633zP$-=HgI`B4Mk9sQ=uoc;QA65D$znu3o#GmNh_fjO@D
z=+!4Np7ZB{^hNnFVb@*qd~tVYYb!45Qn}w5Bfd`ts(WSX>(3tl|B3pHz$5nyQHX(D
z42W0T#_fgm#F25o8TUE@oHam{?*xzRHRu|MyF3D#*GJLw@@kX#Yk^Z+n80rmW+02`
zqyYFRFc7eyk*%C%sWcPJ8Rq0LB;vS5X3L!CF5x_KXfj*@;(LHD-Qe<R1U-Z7;04oe
zF;pc?s5Fv>+Z2;+J{^(oXv&b8olk=kpFG9u3lT}>YL?A?quD#*G2qI%Cj`&!Vn|a1
z+zQDoKg1JZO#Uz+A;`>9UON<05fCF_-JA=Yf*Pl}kHPE?Ajx1alg*B@Z~@L@;KV6=
zJLIf5FsHzkr8L}_+~0+y1bGE`Sq=mX(m1(Ds^U@rMwZ)(JU4j~lhFh>ko_wnFhuzT
zFy9nOOEXpr+8c^MXgSr!#3ewMYKUWdPW*tUfoFvDZ19`%gLxDpHleL*kOXn7Ake@o
zz&i=imay*1cX6lB3?h)|Fc~--=QwxLAl{=hu~vx|)hbJY%~T(ryV%NzC{9hw4-M4V
zD9*r!^O}6NfM^zYMzket45z7AAsW&?hiG=e)8-g1;)^sxEEg2mX#5+9H-x0$yz+d8
z5@{~U0)iYhRHqZeqLO~qoHz1Uoy~ea+Bf;A!@()cMq#9jRhhhyn}!x>VIqf0q!`6`
zSv9>%tMk=mOEo^JB0nE8TG=fEe$6TXma3%WRAQsA2%o52hY@39csI{GSe3;!Pmv$=
z=2@&ZM$!3{j$6Zt0a2hT8O=yRLrtSUzzRmm$w}y@bqRmGnPwoXCIGZp^;&@y5yeJQ
ztRR3(YOoIHJH3Uq%DiHWC)iM*00F`y>9hc#!mE{r7QJYwK;c4#Ay8nnxYKHz&n*gW
zZ>Xg_&5H{0Qk9WW8XnRFVgaqINNJv}=fmbAdVJg<3JuCKCjKeU+1@`Hs!ugsrnblC
z(10#Nl?H=brq1C6PWK$e>o{F(!9Y(}Q`F%!(vG!nXhK@Opq|_?F&0;87?n;}qni*^
zT0}qyHBtyEt%lj=A$3ZPZ(#Llos0H34Xi3;G#44*Ng!o3EgBd$WJD(F#~)~oWPCOp
zm}e+bNFy)tJ~g8iR2l_W1isB~iW+`}_80^~cfUT{ZuT4XDph&;boK$UNT*U+4fPs+
zDrdX{i8>`9bt(oO=QSm3%R)Mx(W!4V&=%a&O5Lc_bG5n=R=;Ar<gt|?jYLx;KcWNp
zpjlF)-?tkXsZf(WYBAb44WnSd6P`i8R?uFxZ`R7ZO5Uv!+=YFE9eP+M1swXk$n-qk
zt2gL0LYKk_Sxf*A%^qv0?dLf#syQN&!s52(HhqlqXsk(NROfFW)JBwAkyqQ4MxR*{
z41oa0TGaTRV$(cL1z_@MHOdB<i#6j`;iKFZP6fIbG7opi2<w|5hw0vNSHK$Np>a>c
zJUot=Dq$KO&2S|zEr`iB$83lW&Ie+Y46J0fl#+D?Swvb)FvuZ>9HwDE2%a+RDVRP(
z;6s%nc<6A=7^pyC5TEio9mSJ^5l$P4RTu!IMt>m`krcpnN4LffK}jx6S2#%?jC=^o
z01KrLn2_l-p)hpXHn&A#4lQK){vk&=oL$9DFm}xc5>NycOM;Zo?7UFNiw%)TsG&X{
zn=UFj-35v$<qKucGo888OJ`2p&D_Q)YgqlrrfS-dk(hcTtE$J(<H)b(Y|$$nfobJu
zx~n&$amkK*$4`{lz@*88L%1v&4QrfB^P_f+#<e^O|M2+(lM<mp`dgjzp>nJ(pR&{$
z(<$uX<%3qLy==-l$RY<3%X<ItXI@F?_v;M4$3P{*P(e+-tFUmkwbbWARE90~c%zX&
znH3AFYqZ*q^HmD-pHz)$9i-cU2mRZyZHvYsnPW`IMy>KU=v@1Ys<!rPQOBhEe!o#<
z7@Ae3st?EMY;q9(g~NGHO&A`OeCOp)91JDVmNy!^_vl!S&g@-M{oOfLlg)Zp=qrQY
zD;d0AgX9h9bbc?;6A$z2xqz9ima#lYUfc~pOBaw?6r_NBSb0Lk56J59Ezdo&nvS>v
zzz1Sq2-OhgPW*Skm#mmL5J2>j*)kdc3@cs`>VNSAT@D>yN`sC=B2H$b5<BRMf7%Yg
zk^;OXP5htrriCT_D(PauI8q`hE|ygBn6)~UnVd4mRV(KFj+w~L)mV*sH8-6HbiHpO
zzHrinBEc|;*OhhVo#67@>AsOWe(A3m!uRa{rk?C9>Y&(PT{UU2vSt9EGqJj+f3UK)
zAC+X^M{NbmO_5}mvn*1OA1iaRs?xG5dVa}DHE{p1uMurA>hpXqyFmq+*>K9UynuRN
zrM0VUKYmHK<aKxFC(C=wC%_+kSL9a&E&b>V)RBF)W?-<Ya<IRyx__Xia&X}7_ujkg
zGU5w)@~}|BEC!te$zz-Zgq%Kz3z!G7;AeyEa{#2DV~|Y&R*BF!0evFlGpF^?X0is=
zn1Qr7undEd&qJt_r6f}VabBQ7A|n_^6VY><%rMT!&^L*+0lwv+mxl_l`X`!HKw4m7
zg!(KnEyDzD1}VcLt15`&5#-PV<{)G5!mLlaN}kk#I>;dQmC7nA07HZ5FmMBd>Odjj
zMFP|Tfl`2Z3B3#lGeSkl59gFx`3J3W{SO!GV-Rn{&uFIUPv&Iu(DiMZ83W(e;aBn<
z1xkZSMR`g}9LidSf2EdE(<;*z8=rOaHieG*LOF6V{$Pq_U?$^18YKfWaf!+b5l~_}
z&N(MRxB#yiQ07ZPP*Ns38_{YFQ_ko(yGC#uYmA&NB+}~Pa|NB1hIPK=P^Ptfk(m~+
zz8Y159d!6|z0a?w)q=!abrr+1`PTe)t=En5!Sg?v_3OOp&w6@9K<-uQsEAZlq;86e
z(U?X<QFM#?ujp;P9*20q=6Iv%v#GsrHHr2hGq(v<7C-<Nt5pb!BEDTL?_KWEBD>)6
z*Dskg`HcH6oUKGdjKdb)WJsDp4%wtI2x`wqrAkdT8V4T6XP<n7-^8|po**%<4%X*G
z;LW)Z^zLgwbGQfWEixi4$eSrSLp7)gWCvpsKo8vj@+HB1F!Qi{Pw+&a4qZz+@h1)p
zy+s5*kVtdAP9!`)<$|6i`3FrbIRwCia2l-9ATA%+g9`;pA|M=s{Fvrp?Ve-ha3M<?
z;t0+BrW3~+YJBIO>$@;Jeel9ZUf;L$uEI}M|2}-|#CHAFwHBr!toyA#9*_8=dC^$h
zVa1y?da30K;{i{wZf-`eHtHoIQ+5Lc>$HbcRj%U9%;osyBQ#!T14kpej(xCTn<e4s
zDqhc6>=AH7>5>$nOxl0!gtWOD-%--Lbt{^w`QzSwudSSQ_%A06)$8eGhci?)r`WC(
zHJ*^Qq&OP2^)zMqUomGiH`iSPOH;i`VJzo_-bXjr77tc?&{n&hPPIn!qrpknmZgKA
z4DvcLzoe`dqG_X#9#QF+IDwB^#(7VEz<<JJPV*NfIKi#peKi&O=v2OO;<a)u_@}%i
zd!@j78F1l8oen~y7*)ja02F+HB+nB_7Z{W<cc0pl1MY(Wb0Ep12`bRAsDL0*=q|ba
zi7-!iCz4?hasUjLNWc=v{h3ItA^AJa`v+Y5NdeIl!VFKAMufA6WbY{8z(7#{-5-Et
z!Sg|ydS9`LK$4t(KIooJ-0^L~)|>QtWVru+e7CSofz~Uw3J>0Yzj3Q#8<kvw-!r=~
zcA2vsx!-@TS%c0)x4-<StIS1-;$2sx2}_ooH-COpLqqetdCd*k2ea#_TjSY%em}Lw
zuZvCedK}XYPTf?)pl0sEiS`-z6R5pwH>vyE!GgKWl8UNHLzU&_l|z%O%CpDtQt3u<
zrkIc%;-J_mwu{rmLQD1<i-nrz8~IMITTxLp8R}Bk;mPdxYlOA!JMfpfL1B#oFHx)&
zI&`zvD%OmA`}VV3o+}Aa{POqPufBAkM1d|=I}(Wm-oX10ZCbFeyM4ie_O7n>zaBh@
zGw4FUAFuN-0aT>Xf9Q<``}QrEzptwuzfghRnB36ZR6k`(eRFd|gV9(J2n6QNg|FPd
z?6+1c+G(}coL1}QjT^yhY92m=d4c`zzo0#r0WwG%AcG8{*)lT77HS5yfLcLqpte)H
zsY|GR)D6^O>K^J5>bKO3)N9l`)L*F2sqb<;WYqCn79mNG{?h(v@h=^PQwR+aa~F_q
zElJA)<TRFxmHhr}7nbBupH%<FUw~eg%gJ|X>KD!@mjj9=qKM_R-_c!@5m?damwf!E
z@>8|VW6H`g)e~9Y62_Mc3WkOJ=>Ax}v0n=rcQOvjsS;8EEOD&hzyF0(VZ@$RwN#3b
z!JcclpEroykn-1m92u=2k;mTYJte<2K(77g>;Bg^GC>V!`v2(VpZ6}gF35GzxR%V%
zdrvNuyC&DkKkM9|4$BlU))-^$oZJ7Y31DOF$k^}L8DqbIC6jCMvENb&3glU8tmNmN
zRr>RSvHh`oFfT-GjM-~tA-pSU(W+FcuuZK2pKP0?WfcuZgNdot8+Cld<S<H9#2Qhj
zg^VRA>NRR@SuyXc)T#B_nBAaZ#cH*N)`e_>f;AQwI%rm~22~LFY>r4qL1~Y9R5WXg
z<Z<R`)W}AvAVr2QXakRHs-^@YL(8op%4qOe1CU79P;28jt}2Q0icuWaI;t90t@T!`
z6)L?YKg?EPpUdrb&GFe??vFfPw+~s|kh@&4yR05O#{<C26d+~0T~lpJi%T%$kK8`D
zugB{!E1cOwPLIt`w|bl|_sDdY+wP;+8@+b>$ZAO7XNC&&6o=O?T8g=9QPk+GD6PS2
zj_7&#309(lG%B)l3c=<VH5y|TWifgRRp2V)HY%xzO|3K;s@Z6Wt?{Zjx(<N1RaIJr
zMsEu`X_l)@7DjE5sMee(X;qZA+Mwl?b&xYy4SL`_wMM5mlqi#x9!XDyZIWICQRh}z
z9Yk#=Eh|*3G$upTqSvW3(7e3T8Fw(jk%xV5zbox`h3wSrZl6iv%l_K!GKtPX^6mvL
zyW55~lDEY>-FB-8SoqF>BZzNyc%8iUBbR7(`|xq6$LX134?%RX-R^TKOlP@WcHhZy
zc9+HLu*1J~fO6tT|FA)?_-t`x(>p9NUZpkKq6&vW0x^=)>MFGwg{oGghKGz<6#{Dw
z2b9GDi(aGG3AGv4uZdO*My<sbR<atY3LJ<nwjixAc*<E`S?n|LC~P%rl|s~F(Yu&{
zEvSPiWm`n;iJFZCer>d#a~n;zu!G^mssc!BZ54QhJ7hEJG-8<#APOon3Zqz%R$7&X
zHoeGIgI|(VY0`;`hy|DtMNb2IsJGigk9*v%VW-!#$l>y#C+u!}w$A17ju*{tp9Q&G
z9#6Z+sW4NUfmlW^bpg_P+!Jt)Tno)aYecJ)S6D{w1}nQ2)fs9fy%LaZ6$&Y0HXB4m
z$XW(sNG8o0l*y1@MaS%Vty-+&dC?k2DNyn8wlL>3*sG|Z6pd@WR5}1r*p*hJo2@h&
zR6@k&)p4jM!||#@YlKorE@K|gXw6k3uh&=d7QJK%dzC4ZUawUZDC_JBPOt^kDy7z(
z4`7UHTT~6`1N8#rXSIYxmEL3vQZ|#<5oAPND2g7k+1#sLE_ZgJ(=A%4DK4PzPQTMT
z1S1D`IRaL+&JFk|c)A-l2SCMb!)M!Vq7}73BUQV7c6`F>wp&sTpB?FdV9xTpeS;1M
z2!AxJ*{<T=XFh`2xD4$25XX=vGZ_)b#y(&$Biaq}foY0J%TNh;ELlEfV81j))UP2P
z_T{QXAHuzlFI0#SaWSz>y`<}!%o(;8h?3uq<~6VG?wa>n?|i{07!znczTi3(>S?R0
zzV7^0Vnkr*>=T!H>zb<ZL3A#gKe5w8gVFwZib^O~_x-wlquCcg;<~{}YyQ+mQ!fl-
z{J`@ndrMQ(k?R?S*|+DLqn?@?B&zM>-5}S3fBDJFxcivrz<U9*zYs^QoRG<r2^mb1
zX<253afeLg1>q$!X3mVS$Zl|^)&^f#wE672sM{%V^Y**51NaKGggVz$uru)dB6=78
z?ZeL6jpZeeo^$xv#aBL_oqz1&D}IaWQT@YG=7OrkV;kZ2a@&@3pRrZou}`o@36>}<
zcA;H!4m!}DIS3Teus+hLK3KhwHU`JR(Z@MW%q?XBA3jYwBE@~SaoaKcxA?Xl55I)p
z_adu7qxG%dcoB6AT7s|4Zi%kfZqeTO&nnRR$9KR3k9_;}UAKSv&26`Riw|ws-tJ3r
z{nU;3@4fuNWh+tOr6uiDzDHy1G?v%xoxk{T{5$-}<2@nGk*lS$^Hb%IZp^-V*SFu@
zaoacFT!UVlqBhr%cZ0UYH}IFUpF(U|gv4$6z~V2jr{M*>k{LpPxPX@im5Yyrn8`Xa
zi<!SX`%g@vX{=V~>g>6y<u$aRPQc}@$MMx*V!8zayfD5=J~$q|pZ$z7Qbmfq&4mNS
zC13+?F0*4QtLsLOl-p63GG#x{{!xr=i4P<pDD?E_fzT#$OP&J9lTo^b$3USmnl|O0
zsU!oQ1mF{Li%^TNKHhqurPHO;viK%=hA%7^Hp+Ww8r<@qXh^6-3tppc!?e8|H+L5#
z2jW{|B7ox<-!3Q~DBPT<$i9;OoH8M7FGG)z_7O=m74sJuR|>E}+F*1gK<n8g+ok8_
z<kXykaSW$-4BwTgAamk~nLxvhZPTZ1k7+5#P6?fM>~wlz+UnfNI%jG>U@}g~epXUm
zn!(3PEv-?#wTXJxXR<W7jMnk{uUot3zzwTb9n7}(!$0(9u3oD}AL=mc1L&2-ovmwD
zw6(2d%<hVWs{!{_RHP7~RZaLV(PYsDTe3k@umu3vn$WDZ*B@B3a{o1FWGYfw0w+0S
zX^HC1<3p&XbLq0ywlyo|cA3jO&AbU)X7Cyyksss7^}tGVHu%@(bO5>64?#na)f~uF
z&=TO|C?m$n?@E*cq?jBy)kLHvM_Z1xkgOseYa&@oCu<T;*UK`I4U*QkNh-isB!UXM
zAS}|9qP?lReL};?`yP$BN?o8WNrJQFH~UvCyY9MWORv8)A#V3+Eo<@R#af5eRD{>g
z+%jY985^X$)lvc-THe*UZcRte3PvlP2`FnD{Id!)RkPySEKVkqpJ+UD9GapefIs5*
zSM0xL*)l*Q2`09S8t01LlWa$=Xlik~2tO=sNJy(c?OL_Evt!K)LQ9}NIa$bk2yyUg
z&~1{4SMXp!83gga+=m0W0LSo~bFzOKpjLU&8(Rm^aeN3JquMFwK=u-J&j^H2k!$Qc
zc_Y1(?SmXV<5&`4iRhi=M95M9#&l90-9ze8<DNTtBYQX0Q-D5?;Mhh=^}0yLAP0&f
z_U_-eKk`WX@3Cd<Txv6Z1^>PD1cG4Hlco6Y!$1CXF$S*X=NGfb;aU<zE(OT-5J9#@
zplX0EgI-6It^d3SB-nhe4TbPKkU#1jjN88Ystr-^{K9>U@%nN|7jZwj9jz(H>mf$;
zY<y=1QgqLTke9Lyc-8#(&qm^^E(QMe9cU?A!1nMIWDI*pM%I$KG)#S<J_g#7d77+*
z0={b?fEGEzvyflV7?X8{8PvucXe<dX0cfAn#P7qL@<X1j97iOD1p8!kr81^<1X|6&
z$#4~zQgfkBVAvqn1w|!XkfdS^lf?qmF@Q%&?#`uf@v#qiM4~l;TN2%g94wV8R-jTi
z8?4CifoO4}H-mdb;5@h=%|}2v6UkUI1nC~sH<u4(GGDxh-!7l&lH$#mpVxV*y{;f0
z4h^Fp>ds-r{(1bMt4z<EW9sFWhD_}%h6u%~AZwvQ<IqZgRqN2uKe|nMI<3j5vN{za
z#W_u^w?gNQHUgd-_#TNm-Xt_BNVaT{rU0l-rxp};a6wO&NC4!|-ZRIO&X3~12em3e
z9i?D_p{s4zTz21pw~orbcg3_=n`Y=ht8{V4!9BlHpd!j+IwCThx6@hbXT%-^iyncU
z|B;}#3tF{f`k;H#boo2`Z^xTXx=TB~tbF8K{AA-)gA`lWc*K1yYHQ6829cI>c5bEP
zbfuK1vkJ=rC9ihoGL(>fjKa<<<=m18ux?m4{?=kG^3>SvUIpNAs2GR98X{V!qgK#p
zJPEs~;0>0zs)o^O6_m*N)H<ylbj*>2ASm}cLjz55{Fm`sqspn~nNqF8D@=NPC_Z_7
z_TC%jL?%kwg4;R%fHptryT0q9g{YBgHDwud+FX#}R4s^B20NY;bVh(%!lAJjgV)Pi
zT+e}X3(PTKPix@Dfp-DPymB#QUO6-xN%km=HIfbxhybQN4YB+ifLLXMk@FbKGz2bn
zU>t!Dz>g+D4F)QBn7LE11wmdwZ{`%J=gBYt7%{kvU$(u=;dn3*!1N8`OEogW=1=3o
zlygUy?>JgaLaV_QR8B+)`guLz`N&TKhl%G@3e>IOasykS&xJ7lH2Bp+cISrGYF?cj
zT9X#M(o|PdMU?McCaPP0KN*bAI&d?$6t)i`imp}v-5V4Tt*h0V8OL<5*1!myQpu@J
z1Fen0>J~$%FKDo^yun)Cd-2wpqTTVhzTRx!r}n2bab4cj<@S-=ocMDGT7f7?9HFCk
z39i_(%6Na)5)0FGQE@!MfCdJEks2RmzFu6QG*9kRt<t{ViC^iwcUN9{LPe?cf@PCJ
zYR>@Hqxvx<So+W~Lai)I3j%%wLJsxtO<|X!hjr6$A%wqk`_cioQlqUet9evPJXe&}
zH!mvfs_0&<jKzh0j%samZ(38e)|*K8pf(aZj~{5{R5;2C==jKfd&N#q&+4?YY%zL(
zQPKf`9V`}vLV;n8BBDutp+3Bqe+F<f@_@Tl%aPrSAwwv!i^&84tR(@SmV^NTrx^2Q
z2Z>4MYJ?{d_e|hg7D@JV&w0DkP+}=n!1_&ASddzvCNhqLsd-%53~nCabPluxq+>SZ
zL=xbF#YC!hBmSAN%jK*Q4d!b6ex!-dZ+rW5{4Sn=?g1!*5W4I7@e#>cK6FoEpOAei
z6fkKm#SQozaIyXu_>*q}Z*mcBnbORQ&1wiyUA{vvYR=VFUU83B!ZYzBpF3a1_eGKU
z;a5;}+0xs@h9&!sX6LT#sF|nFOl_PyscOQ0E7<kD<w67U`r8$HkEiVh$QT!dd*6vC
z;J5$!_IQ8g<h%2Rl<3-!TQb@Ts6j~nu??Q!U-)~x3vI%;KoXVlYHUK6?ojX2DfP9N
z-pMTf3O|O%|KWkZqUbAkpT8@SXvSYm=vdiRH88tjQJyr5%%`L;F5q7S8)X6HOsWN0
zXClZsXOWo@yk<!okBv&`6ar#RRwkpvsgyXBq~#u<PwNLH_XD&vQEAB<JYJp!EXV?u
zZiqX8(AjD<+9A|0^@o{%4R_%`|M0RuKi)9=DPOBX(u>B+)qL%=2g3bIlgHkcSp+Ug
zVd$Fs2JjC29kjwWh#OTwM!wC%*F~*`5v!V0HFMfL?p&RzB_97)kM`|SGSl!K|GE*s
zUmfxz??cB?-aALc)WoAtWM{7GtXQb4>us4e5i(=rKjY3r&is6{xpvO)!i_wyxlB?T
z9F@}_%<m8aH40|nz;U?weHfz9;GWy@Hn{(Hcn8{y-wv7+5$j@3XynDb2hCf-eQ=ml
z>(JFZwA8!b<HugQdU~tj{?Ad~@jH<#=4-&8G<L3R&vedcnN>`%F$mARl7EV0AkKqC
zcw7a@ng<~M_Aq3tB9=+HPXMF}*dVbD$R^`T@M!{)hYpf^C$|QcJ1Hj(fZr3Dv{PX4
z_46>Sa_bCv5pD93Lu42bKX(`@@<DQ?h>thQ#kp~mA)|?)ym<NCl|h;S83ec@fs%l)
z5Wp4&;1B$p0(w70bOTR?^`sP#aw$yV24?;#oUBh5Z~u+LnjBVXgLd`98Ydw6COuAv
zr$|$xak+Vgb7J4%^z@F&6O@K#!%dxq3&4|nXhxT@rKZ3C-s`V>X_Y#mE<nFm#C-;(
zy719LP|oBZ$#-hhph1G=QJPACYtb2R-Ezw{gO3%cV+BrheE3g2o%n}doy(Fpeu(Wc
zC4JPk3a`@KfiI%X1tZUUECH2)-aULJ^+sjIrzL($*I1lvrh5xh@k_mmk$EY%mcBvl
zLh}^rJfPRSgqG9Tdg^Oc>VQ`@H(9s19Z+jZQgzzWgaer&hZVAM3NM>bHI$YXT;mEw
z(2tgTkit>WKvRCTt024Ll1r{c?6tS8$L|Ar)%1}Y>7%GZWPy_oa`>iP5!KKb0KQyL
z`DjaCaVw}k2yGmII58!}br%BH+%y{Hw-2ZTgkxB1@OqMnmq3(^*(G6taf(V{=t9N@
zGK0z?K!j*OIJ1!1FAceR^)(2rT4VGf&$Fbj<(}r!WZH#YLN4+lGB1-o0%jo3<b<qX
zSq(d6K9yHKIol`#8X%-eNPut?K+J<%6SY47_*G}z0$@tpHeCJTwfo=C9w{7d)%aby
zqrusz5cPMP?$FpM-=n*BJ$dOS<T`rz@W#tVo^(tcIb+HKztO*Wq7(vs;Z;GlWNt&!
ze_f5+-557G6_h$y)x1ZDY(K{*QeWi7hL3Y>IyR#uFRx_e_76+gqWYquh9a1Xru%fU
zSduw+%bWT5(Kpq2FMWOFjjh*x`st4klsh%_H99-GxT5EEJTg9x_k=W5a`y|*?cVZ;
zV`L@bHm*Q7xF5z_(T=>T#}Z`=Yhw5kv~=j8mE}RqDt^R{V1ISPGL5*j!~-mPYI?In
zsYC|%w(<Buv_;SlbX%2p*T{5w^2n{^j|=2w=H!)EoM=b2G!v{!G><PTi2=^%c%8Sf
zknn1vL)gr_VNGBnNI5bujX)eFn2{9}v@Z$fk}Z{_S7Ge(Zv6R^zuJW7-!lKm`dd$q
z!ynUUO+x0!9!KUE1|Zy~FH<(a_@2a{58y>d=ihqfQJh5{`mDA49z$mQX<bEMZ+WJF
zLe7`|CiYvnuMK>Yr$R=(xe%WruZ2&iEyEaXSs=QCuo+0aIz~i9LrEMPas^}J*eD$V
zYmrIlC)RX26%h_HN;~Yg0qMkXW6Y{~)=3cg=g)DysMX=$)kju6jF0zN0%y!EvN38~
z*M)3#VLaJh{YafTu()k%ZPk@6(K3fiN*5&Q+QPiyX%w!n`Bz0{Ye}jDAD5gSBmJV*
zi*~kmAp!r;-HJCyV`yLTdA?b%)kN`Pv~cO&J{`sLmRq|yD~I=@eaTFT&U$v-3J14#
zoNH!!I;P{R&;`+U4rIMRB!$ly3DSE<){;MJW}A;hMLWAoIw0Ewh&j-YxA8kU3Gf(l
z*6VYiHHjaPJh>7UoLidZMidz}GP8#<1Vb<dnk*QHzMo)Pd}Hkl0xub?B#aZrD(vOP
zss(m(Vh@x<y64>Z49SD?^kHe@cWR@zXJFB*P-(SxtEHf=J5}?7U@klHPf0S{RP?l{
z`Yf3D`sW2E_~+p)ezVIIQkX7<SO?d%wUy<Wt?mz_tX{jgk?X3fiU@e9C^~!w_1QP2
zS_3jRrBW>!mNuw-g{nZ<=cnk8Enb((>It>s_7J3S$beObeoW;-?^(B*pZRK_7VkrA
zN@^bXb7elRK~GV6^Dhu6PU*jME}o5Es;($CKVaeTQ8il7wB6X%)`M>u{*c}{vWxs(
zi#lkHma-M5I$BcoA%-ID4r}U@3%P^re9*Q|2BfZy5J~wfK)1LRuu6a}!PE+{9fUR|
z!uH@Jw;xa^EN{uTnM|IMFs!EKY##DXj$4k&NJP*X6?UL{$_pz9qV$m`=TTk=Hv*2F
zo2f}30-u9!hFi&Ay|U9Doa*zECz3@j$RFSX0hLe%3~KJ+;78eiz48&hrLvdaIH2~M
z+M63SH}{q#JK8#=*<$w=tJUGok0%}5N|X-G!V*uu5>b>`m=|3UMnyh<PgEaHuZhI$
zj%dS-ubw!FKKx=rc9l(Aqt#?I?#{ft@l@)AV{`HTSr2~H`#NB8-~CK^_706VTx}@}
zMX1io{D<(-I}U%=AF|zv_M>C?+rqs1NKC3>K~n=zF;eNKa8IA9FfiSdnCWSp%G`@q
zH}0ryX>>iFN%y%sdpht&-*<Z~R<|WpQdRtSG_H1Q`3}3vrS(J<L5Fn{9ke(MhT^&T
z_hsMdNZK7SmBU-$F!ei`=WL>Ai`CT)w-v{H{#erKY#*>PTf_D`W_Y3KRA-Eij9Jle
zfioIXag7GiLn|ywWgWpA!++$ifqo}h_Nu|(>oUMKxff7OeouNHnwbo|(e8|diA7!R
z|1k85ndnbWeP|x^TBKic<l#XaB$h~?MmPXbEq@3Zz}Bb)HRkI56X}rg4IK*EK%kpR
zRlq5Q56}@gB@}>f3sg8oDiAG2jZqdv;r@)O2zAJsdG4CIUa>i0PE{M+QLpE7oZ?dX
zc2g~y+0#CkYp!p!gQ~lst<&wvmsXvqTtzP{T)y6~G8Pxu(*rN?=##ZCy^n8K>D&hw
zf(w}L)=Ty=^jE9i+EDh{O-EvfVm_M*9nG^l9PZVXYM*Xt+U#cw^GX6v3Gy#;6_XO*
zqc5G6+|>3&NNMcM?)gV(LhoCCowizw56?Jq{FS3q-omNL>zGWk?HTk()l$2rLIX(m
zj`870lS^CcNYH>-(eEDLB&r-{rCQV#1cRTWk9lNB$3YW1Vd3(2cTGb>e8UBIJ_%`S
z3-DX3+1Hj1pSx_i8WxuPJAztdJ&EZSt;TsJ+NVUSJ1#sZdKsmuB5gM)Y}Pf(xYOw?
zc^Zvty|`?Pm3IjF#R0F9FEu(7qANb-1lGDsS&PxFh{Z};#;=YkJdtEk)QA3npSX^z
zDW{#D0Z7rV0H@Td8ec=i!4SSek2{Fh(>l%o9L5beJL6zIm;&hr&`$Ue8_{PVluODL
z(BLcx8B_?!yUYRt`V4w*>OGBs(}50H@dx+=tM)j{-IE4rjC)w-S#8xmX5j+r>JiqA
zPf(QC`@>q@Bai6V$zaSSyIHI;=}!EcdDm`UMp5hahT*_Xa_rkBu)aos643@|K6^<_
z2br&BQX|xR`l@b>+H?Gl_<!V>A7OuEj!$qR*#q*-amJiG)F?fI7I5sGT%A!SC^J4n
z&tunvzzTS#oJ+<y(6T^1*de@g9N~4RUxjEK2}$Rwj9p@^*6F4EGv%I(8ZPYJHooOf
zf1Phv?asliyI*by?XEg2)Lfr#9e;;E>|Zx&l07qV#rZFO*jQNL_S7`4w^$0gl-nnG
zOEs5YyJUV<<noH;DT5JQu&uYIRz|D3mbv^5Wo0F)<_gZt@zv47_EcbJYs(a?Hv3O8
zTnFf3uee1uN`M~tW{ufmrOa0R8&^SL*UBQ@9VPQZRS@<dltto0JFZR5h+n&8R(0|~
zdS2o!qp_%yopYbPsW9KHY-?ohSlto3Wc)b|?xR!7S5JuTY1rEF`(2y5<LB3G@LEj%
zyD~#V&DHA$2JDI2=PxX3w)^UuHwdi-M%T7}SDnSZWPi$cdD;5vc?~*aM5XA7IBqSS
z<67BOn_pa=EKa9u=|-K`d`@HIl-fu(s3->tJFXT3<hiqNBm+7<U=mw7zb}ZN(ptbe
zkTM*}Om)x=`sLRp7nIIkdTlCpAho<w&-NA>OjDlp1PkjS+_Oo>LBs##W9$pyOKSl=
zPASmW={kVZ@C7nDnb(<REe(*K&nt_Lq`zeni)ByXefUa@AZ}q17%>_AHNN)5Fc=AD
zo)|%M?tLI4C~Ka_O8{N?vp=?djv7!EdKH&FwR_KFkMBPJNoqRYm&MdL(6le2*lZSG
zc>>MF*AJfn6Yb1lWcfJJ_6Ph0oV?`uwtt}4QPu9pAKSD0sV8&TW#91MviHJ>vB0=3
z1)qPCad9fVOU~$u0uU1lQK6<B6{ipl>L|Sq+yg<EE=y-H%rh+LD8Y|EAmx1gh&4LL
z$|0#Ofgga-V_30UO29vun5Vfv4WA2^=55Sb$iDM0-l55m3|HxY^lbd;mu;)@H%QaA
zMrmG<vIp1P+t-K}Ez*Vm?vm!cxCP&_%C5$LMeh7?X=x)`Gj|I9>ws;6m3^>GY<SSI
z+Sy0F{v0}vUVHY02ExeSp?3U0qtNU4ZTyfAwWA5aP+M3NKk}aUoZ`7H-P8`8y4WvJ
z=Q+Z&Ce}h?h&X=j&*K^T`Uhv;3(^viQNQLVvyVgD7=f$h0jAqns}KldU?O@@DZq<@
zl8Q7Dg8%U5rqNICy`d5ryWIZa&G>Azl{xRRsS}=ESgXv;ex`4Fc3>8McFqh`IVXEA
z#23GhccXduT68A!#9OLjl~%QLT5+6u<0bSadiUAk#^1En3DjO*sPD*TK`Yirod;;y
zj{z3*c}w>$e&U^v84A}lSINBZB=;(Nzl<5|kg+ssbGCKaj84>jAfeNz8RPg<FF=Cy
zf&G!!BB<g&^>8WoD&9SECiL1?dMC#~LZeBhv+He<u-zIvIS;?Kavn-A$UZ{C?0fnz
zy}GA!VM+PWoOI&ZshJY`L!5g0Y4m&a`qPkNBszQ?$IzSEduu{ATPWO(4&zDGIk*qq
zK@!`duFI#)m^yf9T0=`?&Aj&-YlwdCBtYh}N8rtLfH52dYfvxvCd=Le1lA=0vxz<>
zLF*F~0r}zOEx;2X=0~}wO4Bm^<`xyQY0?DmCL3<dq@xHQ23K;}k{9K6ym$C&W&wJs
z_50qI@A`4&2Y)N7I_m>${@Vv1oK;nX^=&n?TKk3OS#f`?{cNHAv65M95;MBiy1MA|
z_I8F{7w^UT3(i0P0{R17{U~L4;>VTfMm!ymRtL}#{CoU3YB+CT5#ZJT28MFO5&%@5
zRur?;7W)n6SYf1@%}hMxT<Wg~g-R_|iFZL;`OZ7<egM(0a^H?{3)r_{OOieK3kl93
zfq^Dy(D1G>!e9qpTy~btjZ|}p3}Nu-XUPD}`5clLCc+t8_Hy=<m(e@4=+EnT@N87q
z8uey>sBGQ?D`9$1b7l5#51suG`X_y3$F7STv)}I?aOw5ViMyGe?4wj8y5Pi@y)~U*
zQ&%>XKYPif1!w}e(+<^V-=zX;U!DE5=BvTfl0}6*&{Z&&F5o`^9BaZW3&G0X19|D^
zz#4ipJpE~0^K>mLZRE)W2_E9WFQH#8V0t5*6ChK-ssT&|-eB}CV3k3HS15ql8L)cv
z0I!$<Yzt@+;IS!?7Gb#NW>=6gWw?B~!%O)OvcJP?@y6^^R5@e>*h|$e&0@%=c_XGN
z3Y=SKP~$E+ursK(`_8@(pTO_o{u`EV+j2kRK<|1Ozq6uy`OuW5-3zPh=ge%X#|zai
zrl9~5s8rABx;xXejJj+({8QD%6LmggWxWuH2QAiQgFOoPoolntQq^b|+C$Z6pT=v^
zbP8op!hLVaVw6SGe)#RyxXK~zJb-RNzOP?eG-=BLJPkLlSu$((l+7Eb&R95o^SqY!
zjy6<kO>lL;*ZQsgV%%{N^}v~Dm0|iq>Wuovj;e{+RnXd;NQX?3Qbo946|`8Ad945-
zPV{K+@YC2&z=G_6jDW>5+D-#x-JU`4n^|bCQN0F11ptc??1E(>K)k~BJV-1u$}SXw
zHUktb5NKn8t^(yYl*2Lt<bFW=fF+(hQJ4uPxgIQ;DPpin0VuZ2SY*79X;t1I@9<XD
zLTGxRw%Q!}@l%KIsGnl~%{iXBgR>QAhpV*(MLOm&P4d{ytoK&+3GI<LoT@`0Ro3F?
z<~Ci0YWB1&$}YtFm(Ff_cRs~v+%63ou|%ftyXxBKy_Hp7t|w4c8Ss0Y7M1qL`?)$J
zqhe0n$FLb~Jf=PIj5e0{_up{tCqyK&bBsSew%Mfm9boZ3n7ycE9eS2JbKYemkr%1=
z+wQ()!~ls+&fT~Aae%9s1Y?oV^d0>5fGbXr*$ZLrtOi-LciaHPt;>?;sHYW3cP0pj
zg_(hTh|djCVVs&jVJ?MOrvS_v#l+K;{7TSx5GVuCJ{hp)1W+pDv(P??a5bQN_zwrk
zy2{J@uMI14J(_V|?LZ$j|E!TopiMhW-#Gl{%A4_$KR&mAgWh}QvU8g1k#fg$x^W7?
zqO<vBy1Do>gf?7<w_ktWCjR5<o_k03;%6Vhf4Fiyn%A=$f3TN1?@L3w0pubTScs)|
z2?_L?y9$(aBAD2`xEIk4Cw@yGqK}Ns7&)4c4n6;FVZqeGo{pXPA5pe_%5x3)^)o-o
zE<rb%M?O}B2kAn(Xylbg9|g1j*5Pve6(D3#5e{skIor$4{1J8pA`kO`273X?Z3`f8
z=GxC60xb?{s-IeqX!*xDR|X<ZKpk{iQ~{|<mZmwe%9GO=jByBA<0`is#48gul03P|
z6S(XoAWPJQBf@nd#S&ab7U}uO%(<7l@bDE=R-Dz_y<?<zWD<QRwWw$AMSWcphxYC&
zV+`xnx8mPg5>wkt5=(nKTSxvd^|I?9dEh|T1#}wxbt<YWG6P#v^rf?#2Zy$rdMe9C
z{_HlCJo;*P{;s7?qa&X_xZ<Yznt`jv>x^D!#k?gOW9KmDE0?Z>#FF^C!Ksr^80cH*
zyGDlax0yN9F1dK-+{tl!6QW(&MG9L<eN|`Q`XYR0@jcfaxYHwC5-Ba~>n}+~nYQL7
zP53vu&X)I5cC^M*aQ1|AI(bF46D*#2wP*FGQ{%nT9ikLzt_Z6w^1N~gutG*a(s6<p
zR4bq+4?-{aNQf2jbAx6ls%{g6#s5UfWQ3Dxl^o?jeNGICP%kal<IOS~W-S>D;lqR_
zBan<z=|~{My_5YSf9AUA<b^9&=~i#~62Fcr{x~vWWRSj#J~I3y{@Z2q)}6QadTpt=
z!=2bXVe_OdCoB3IubzTGsX0R5%U-d13f_z+oqyr6W7K&Y<CB*qmQ0#C{;IN%0B~ja
zav=Y^M<!*@!v8MbU$=c7wJlt_y7sE#e@$%Zp}KcccU^VX5RKJ4M^0XZ{+0cH)9rWc
z`Dh%>N`3ft{!;c!kS^jfF3CLLgR204XD7td5VRzq2tE<WMe9dkW&--iX|QBjNs@IJ
zKef#07zel`IE&OAtqt^<Nf7}f4Q&U>abV=r5W_O&R!&Cxm<R%%hJeqM(o5-ZP9_0m
z=9sJ0*e~CaNOg;AW^Oi7Qu$>ajoq0<g(cY4MEg5u&KznPnLaX?zLCCe#5C`9T=u~O
zXdxxUQ&rWLNKa2Zc2k2#sPXsW&wq6ct-W@QCcB2Y>$ZajZ$q7HaQ{lm`)l|&;?J%@
z%<fn$H8j(u7rfLB6WTj^&?8;#?On{4-lleCK}knbqSlTXm3vw^-dtJ`6`3G4F;J06
zR{!`IeJy?S$h?vFh5)AS3w+eAtFLT|lxK>2@6U7pOS%auU%V6_YhxeYwQHpI*s*)j
z?2(rbKKQ`>?95%e0p;fKh;?n{>N7<)gu>IN&CEVNbM~xJo^gmj1o*y6@K;L97TY%9
zx<IWt7E8YAT$7UoYCw)46@+uE7T^M-Y2hJOQTCZ7qA+MDAhR6{)<2+P6d;jN#65?H
zJ^oO(F?(P3LFzH8nd&~vQ!=YP7M^FbOs(Oq9V;LchUx0;hru+}S6#UHJ(NdFo3qEC
zx$4PnTK|1Qlq!nv-5byT>SA!_Q)v^X3z#bs_z>kpBXl`tvma+0=OxODJN=JD#f&ti
z1mA^^QJ+*-xoDKPWI@Q0J%jb45o%X<WAR+e*4}~Z(YP;09!}|uEOUQueR2!TKmUX=
z8v@JqZGcRiqf_92L`y4w6X&HIGzApppd4h`kcdli9T?v-@xnVpm@S#KWx6J*`()Qw
zvRoKFGq;%&qln8Bu-}pl;jiStsAXKf792B!k&6@)-YT<Tc`qDc!1y*=03HmZ=acH!
zn~g?PHo;)>DjE_~2EZ?@sHn`-s1p049VL^MknV8gc$`uQ5a`$eUfJM++Ld88ne2Bp
z5BELMWpmnFz%o2pQl%5&GZVob-QGrC9aU;9JA50N%n;vYudsC~Bn{(HHHZ86RRt)T
zuJnb=d<Btk?R6SE+A`Y-;eh)56Z7v$QHeCq(R&-Gbav^|%gVarsRycyG%ZrH>YD<i
z(dMW;drP(Gc5SUHoWveW&ocP+Rv$aKD3HvHSqnqmnc=4z)AeU<h%8@JvTtx*M^7s&
zjh6sLEZX1hcjS3LGx_R;zX|%v_X^58#5=E#%)DaO#S{9dj@tVS>vooRnDQ4mTc*eK
z8DGW3Ipy`!bmc3h5@m19x5bxkEG>OoczeBQs>b)s>Iz*Mat2(kX^1_4->SZV(lvE%
zuo}h);b&*@pMyVQ5-6h=*7HlickWa0(a-^^Nm-6gz}`Y~F>7-^YJ{KVK4YpZ!uc~f
ze>&1ZuxbRcE|*l9h~*sYk{*_42#~rV5*Xq&p$uxu8vW6k7Y-2GfSG~ebEHPd!(vXC
z@Z|K&sT+?y0QeXY0|S{za#e{gVT{g39}<p(tseZOAa|Jz6E#*99)|^Ek35~j<V3)k
z$c{XnlZSxq^r)}1JljJ?7b3axW7p07=13Nv5*kPLD*)&eG91kO=d*WbZ!@@*3Jq6z
zUSEul^fgW>HsvkppX4=o9cLKxw=Jz)N&SWj)bB1>R<qKe4d_R1puM!V<~oDF%ws=u
z{!3MOS*+Jh6<2#AZ1vkmOO%utSH|`H1g#s)|J}h!<MZ_8uI~DaBKWU+uFWjghg9aC
z>1qJikF_CzWf%xepg66Aql@NgU22!3fKw~XDWSGltg*$9M5`G_azGMAM%CRB)m*BG
zCJcb6s4%G}>Z-2U)aZ=}yfcx9yC=I8I%8O4jT9~H;Hrzgtz|2RoE0%Z=7%g>nzF^~
z7WRZ1y-IhnA#+<*|B#<kY28W-ua?|GVSd3?wH|5@s}S=<Jzu48LpFxmfyI|)*GPrV
z?H+aiqpMu36xE5w;%PINS99|lGK-AinJI8wxEp<6yWT&gs)T1eBa68W^vb5cu?Fpm
z*-vC3Z6NEj3(R<l5vcOl@UNsIhNHMPQ-R*20#GiOR+qvr_4jzgQk8zwVXGmjv9V&_
z!;Y0vC7oxRRkjiGT4+GUtWnx{MW~8aDs_M>Npp~dk`4;yodes$oQV?@Qg~`wWf%0p
z37ux4lmbUE$S-TEOPy2D?q5<kd)d9tsSv6aa%mHy`q?XzCY^dos;tFnERC}ftI{fk
z=l4#r7o`+YMsL>^CG(VEzSX*UZRwyzEFJ6%Z86aF+l;_^RaU{l^DrdAzqb$H1^hY-
z<B|Az0ins{2wthD4*^)nlF@UjjQBC+#tleV)d=h^xnTi(my9C=3^~Hr`Rn;)vcqJn
zEE9&7_)}GRi(@ndb!j~-@GXm8wQLQ53BsGwIAdzNUbKqUy~aF?<U8|CF%sEPGfNGq
z4?5%gzo6HXJ>$pMEsg4IK3}q;bg-$zrS=YLT=95bXgfM@<HweS+9pa)rNyaVXJysF
z60KF-=o{GKmx|hIrMjS2Y4fbX-)H|-qTmJnc48Ztd9s;TvpZnR1#8W5A+R9HARr)7
z5!*ey+$awrFUCT{WO()K!(SanTdJA{6593ni_isM>^9m5ujy7-MT#qW2HG%nSY<lm
zeVeJi{VGdHwHAL7y!g|LRnFcUdexN{S9QAhE~WK$d7b;6pkZf&G`AM4odg&98X0ka
z0oovQK^bd+DByD+SUeEPA=fj6JB}4cMz;tj0qz7QP|)4V91<QrXJ^jI%A^eB3GxZC
zrAfk;pmTsDjoJ<(B`^(_T4-LPNuGx>wgbp@vXuaufVh)bXkd*w3Nf3=Ey>wof&eA!
zRYBbfk4U(!Og&-Xm{1}2++*|v77ji@UW90B$xFd2koxdR5ge2pRe2C$!eK~Z12=$&
zmTyZc!PaP%(V06#N`dD7OAW%t;dw|Tu36r$Mr;VuTjT(lc<B^xh5HjMDT@H0I!?aQ
z>GJ0n@AJ^=Hw|_(rJxw43Q(DNZB%LEB8)<zEGSOL6cf9gJ};a1R&`gqX3*g8*~om#
z>)2AjIMC?qj6&-W^x7h&r0_T)b`X^<DXdD_1aF=d!T>3as(MpfOrT$W>5&rr(H~I7
zo#9APZPA)3Lkk>cl~o^#7OtHLOtU59t8!P0x^5-Ic0^509BqPmp4OVpZUYCAV7$Ol
zNwpzRE~?5owP4jM6pSxS2?0vm!D+SQIl)n-*E4!v?T-|6OFkMvl_<9g@`~#@NNJH&
zDAl}DP30?C&S0makl5O-(o&ShENW>huRt!9Aebb!1UbNY0?{ej$&b8?zuWdLWPq@k
zj5U?F-C8>(KVDi@Ftw|z*Jkz1SbQ6z-;ZYK5XC|NZfb3vR9IT7tXJ4!7$b$im_3N0
z!bmJU=Yo_n<Wq>oMH81IbDDMiL+^DLQmZMe;8CL>B{1NvqtGfvtA23s$l*=)Od_dU
zhQtPFLsuT-v<Vkh^zF0VgO;qoD=FigGkS67g864v#wCpge_X7lj6wHy?QRk87g2pU
zGQBKn6oP3k&lypnYF?7;5{D#%jit19hn>wZOgO=%lu`xj4p2fc!8AH5tU7x_Cvhs3
zvH3TdR;CFVdyFEdkB7qyguq6FMniSEvH;fZwURfc^b`~ny7l(?cEs9BlSy0BmR~F(
zPSUih9Vlsy73uByk*G1HE>i1t_D!{%!p&LDf`ZPg3j$&%JG5<2!`1k(FA)iESq1s+
zJTuNX<MNi$sNeVbwCO9i)-Q%&4x;<NgMXMKdViwT=>sH;QQzF$@CPnUL<ypnln3EB
zAbokj0@VXbg-$Z(1Sen)a2!T7!ABt&ZnAzkGUojS8|eVZBdJpU;Tm<4VQV5%)nfcX
z`{nu7wqx04Mf3}WWq>MLiFTKj7=;V}fR}P;B<y-^ClYGwrdRWPEQ9{iwa){#w_`Nq
z=yiFl59;A{ZO3@8+Uh*GI#19btEy}+(zc&dZhZ|<X}{ij^~knpg*F68(2pdW3SG)|
zH={m|r*9ryfJgAnZ{TNIT4tl-R=lG29A~W6_9MYBbDHktB!`h;kz05d$$zc}z5Im&
z#q0qOo>hRIw*ywn??LYK&&Pd@B#1Q$Ac#7X*UhppWsn&cupz>U2=j!sS&qX&fjq~R
zjIul*v~3_)D=cF?0at?M8Te_kxv5Xau^UAtmiZZoX;2do)`_P&=pf*16I2E94<L%=
z)U$H4=WZyAw=#ZQAg4YadoZ{Jc_4T+`9b7oO6BgDg8G1S1FQ?!WKK3LO<5wuJD%fD
zt=~u2^1yj>KKVJ>7_J6FE<r>g;wY%9i6ebDEraEdYZ6pbfl4%56O`pFi|CU6;Xl`J
z(W}*Q-e=2;?2nlD7b0GrD0Sj$Rw?R@LYoQzR)Si;a}VU-UI)RwR~teA?XPmA!T&@o
z^u`3qL&co<a&QSyfeh5(Qb-c`(K*#hbOSyLxds)GbxcI(QsSic$x5?9qf)A*>1|$b
zjH3DEQ%RM^Rc_UL1Ry9HQg69*;iSr2^J2s-nw5a2G7V)J4s!;`0Nv(sdtKRsBR4Y9
zrGVr;Uh9EeJ)+y8vNH4~uDWmB=^9Pp@b!xqixS(eVhVcGw93KpTJIDk-+|xi3YO0E
z7}bo|qAF5_;`bI$37g^;Nolnx^M!ak$?A|veHB$!X=Z3iZIkG*5}@%EKCXmQELQs^
zq+n64Kuh9cQywy)Oak(4JnK<Az1edVLf%);S58YYz+)|v)V-p}^V-xYo6AKl%cz$B
zc?K|cp$_t~GTW4D&Kpvuw9d+2eiO8!LlswzKYZ1oj$_-<1Ay+Qg=D`jFa0M;!j3)e
zFj7r}EQk<BB8BrpMz+!wI2#yzjH)u3Zg))<l`5v(Cob1Qa2APgJ;2nklVmJ4z_%r7
zA96GXN^?RCWa=EXq{1vsC~wU53O0e<G7xAXy9j_#Yhg&NhYtXcAfqZ%Gh)~4e}ibs
zZ9@K3Wz=fiG9wx>7;Of%%9_Xvec^NlJxnGH9vF6*V-mtK$-yA|sy%2!_A}Os$E(b<
zmsvQ2R$(p)+q>(lW?!wZZ5LfOo7&!}*4fa_B_*|9Mz2b$1=?vutTC=EP{#2G_7biK
zzj?|2^hqi4y&jxBWP8HN7`K9b3Um=+$jwm%eit>sH5bSpX5iTebWWHb7l2oez_`p9
z%@I-vWgvBgBgK$w)d-;UkdYXq!-(u-1VU5JK2DG^Nh^`oA!C|^W97~!g>W`0gg<HQ
zit-4~U6SNT1rBVWr|LOc%W+yDaPYhb3y1VCGXv=ljF5{}PqRLn$qeG%j#AePc+b<)
zTln)oGX{fCWffWJ#FsXRjWUap0<Z-lBCpf%H<=YmD4+y|o@IlS!pc`ktQKPL854v@
z@ywDn_#OQH8Wf$r|2lR%s}lr;0uUON$ged^3a7wojY=~Q3FnJXd_M_oaMw(F0d07p
z;C-a|^Khp=!srFj$}_Jzlz`C0X_Z=&0;C4#*;>6y$wPt4%tLbb7`{khQh@xys2Pn2
z&h*1t>f@}7&J13McgQ+`?XY-KLqtO#=rm^mm%ek{;}A#p2hah)d<HOygj4Zk`AhU)
zIpzktIfCP4b|`-*<z;hDv7QqPfrg27XPnOq!GYvEw+*Xh=wO1ELA0EN(%~at8Rozg
z;Cw~W&|M(lTOz?)1otF6W6K@Vy&8(#9Ug^1f0hOa3x`nxadrgi)CiSfEWii?9?pZ$
zFH!b`ZUGLGg}Tgi$>aaWhfo-l<aj&b?kPWcQ@Cy}gD~7Qk$Wc+AV6*?U(S=8wh6Nj
zmB=n?pdFLv2Y3iLpV(&P*8}H7a=n}`fsE)32yAAKy73Z9qo)N)(8NSgtwlHu;7Lx*
zFLfiw)6GQ<9$@e)TiQ9<Jb5Br9*yn;gxNxnUyqjJmH2P?A9xj{|8gKZx&*&Evpzr3
z5Q)b;rP&whlIDC%LNGW>4FT52%;N>ME?r@uC(`%_L<y6R(tQ0)9wMJ1%#USVd?8IM
zjW%Qrumwj8B&9$}W=^B~nzt5(l{yAF6iA>T*`!df-~nvJ=0|y=2ssIOg^{LNPX?sI
z*(Nv0zclbvF+DNeUp!-xmQg8}rWW#5)!gjI@&%P%tJDjE1`s@fR7HKhfmTu+W##eH
zEX%n=d%KrUcUPo<b%nb6s}(AWZtKr)6nSS$-Na_k9KZuE52{^|sxNgner!I+>&!L-
zE0p+Dws5b7pQr#t4j(|K<~5r<A+wqbIh~3|2V1~$w;OLvSu10)C!m>%z<r<}e}rt%
zU@P(8A-BR>bTQsuW`MXdywaT1qqV%oU{qUm7PAg9Nd1P1<rNV5D2N(btZhS6L{8AT
z=_m~XG3RmSE1Q+7pvHh4v`t+M4Wi+88Wk>uxl|d3j-;y?hGCyGNSs!$Gvg3zgIwf#
zzs|3PP(^2z!J~CCN=A>ADoQk~(-l62O#&?;L>F8zN$o7_?{3#AB*2bUXtkb{saj=@
z3#Fhj1+*t^(h#(jHumO=c8^O4I1(|X=nWOMuSZ>|YE`$@sN|HfVq1by@HW{7xtRAt
zj#edD(DcB4?XbosNbg0k&L(mFx&KH4>mi_%Dv?B!BCz6+|4=e&7$=m^d$YGf49}O@
zTTwoKotg;qsg|0IU%wsqzJ-7N&_nd0w~pUBf{RarDgzRrzKaKrQ!n9*9>u?X>p1=E
z<-L8&mi6_ltiVO+6-q@Z&>wLk`)~9pz6d>uYVcDd8G<E&o`8}jTu*Pt7s2hG0i(NI
z+Pi#NU*EEoFqd?K?7fd&!~Sht1Xwr0nQ8^Ug2@mtya@8+oe42cyJ1zd4|3w&3i<FJ
zgo{6i{s>v{K0tp*U!xzWag;zAC_Ck+@~C2}f@**`>pp4<HHTV4t)Vti=TPTUmr~bI
zho~cfPxUbM6yQ@Gr{1PMraq(oNe$C5U}%YUfLS0P7GjljBi%vw(^KiW^ip~)y_w!I
zCe^}>e2T4%In4kkAUr_kA&?mg_zlEOf+^9GhPtDoC(LTeQOLuw!(<X83wSsLJQ1pf
zfo;hp5m>d$GN;Vd;JTz*2Ka1li)4MsG4Wgg6Ywb0sV#^Vh1wBQY3?U?;8caMEGFlU
z{X$i9Dv<-jG6PeDmm;D&@unbiuIxkei@zC=?BTE+M+3YPUW7Oa5Dp28BKZ}8U620e
zKwMAlkCjJ$R&T6)?DxMr{`2y&{juM%^Z&bFf@mPW+5hl+>UyArmSGIWu6XLm|M!*t
zckeWI-Jk#dpPqmEd7wG}pPT-F_l5qadjF@#`JZ*g*gm@^sZ~#Xt6{6F(dITDTKM8D
zeaZe{VW@c11)bab42^C3id8E;9>(FJS&K>`dgOns-KJ7gE{`ONCdve^Adra64N3uy
zuTV*pcaY{i4lgn?6m4-SC0-GrX~68ZyA<$4IpD{xg|C>4<4AFgQqT?;@Eg$o$j2PY
z+%W-?ThTh+MN@$9>8acRdp2i~Q>biit)3AfBwxvhYL^ngc9E5JW<T6HslJ$thQn1s
z^^VR@B=nub?R1s90Lg!)8~&A&lnwIktu7}y;2A4(d%Uh&<)d!5$0gT;DsIPz<Xm}c
z>;g{L8u>JGwA}6SxbZ*8{!00Rqc<77=ZCr5@gl&4xys40(UP&-j^2@6WYcNSGWG=J
zr>>cMTzD3|>8A%g?eYJ!B0e^HF_qGvdr@-lTLCsI_hvWCTk;G1R3_i+z0m{k{G)eq
zx^9-Ya`zv5ZYYC>8!hv=PBl#_xd0lTHfT3&!QW5Z>o93v+KM-CrSmPZ?GAIpp?jwv
zS#D^&B%mJ2mQWra3n$Q}$YTV(d6IIOlnKgZXOpZGjySBmO~vsbFIi{?aLbiSwUY?{
zqLp&%I0Y5lLOWdn2w8W!)f%89(F}pI6eP_oBVXkzotG|0PA>(%_I|dUhO#P-98iLI
zGJ1g12ue3y!gX9uIbB}Sz&V^|g`hM!AmmrAbaI@AX3e5XGE*K$*28ET4zC=7knXbZ
z$oJDrrC-m&A2ICf5bixd+QaR2PV{=ow!<a=I$flEA{=+Xu>p6k-fp0q6L1`8!`%<R
z<oE@n=k>ww`B1)BuA4hXuJII<|JJScs0ZLeWQW|O&+B&o4z?$HeU6d;#oc?rw^3w|
z<DOluR=pQXvSfA1mYXa~a__yxC2?F*>@=r1z4snMNKXiaKzcX`BybQ)2!zmkhohIH
zmpe*;0}^Zef3vcKL-~G>@7?8opTFhpv$HerO?mTbf951J?xQ4)En1)!Xz6_e&$;y0
zxZzxZq6K_}OY3E&kM@^xBiv|#Qj%JbBPmsX#wJpLfpc=7v~Y4HA0Zzm{f#RCS8J{?
z+;id+y$Nq+-v=6NE<~NX7NRhn0x#$<K{S%Tf)aTpC<%fk9??eiz%o?_#D8@8L8kCQ
z1Oi$64lEyFQY1pl5SaF}z$)WjgB4GdI}|3od5#f4Qji=W7g!8M1?d@N9=)*E@F0*M
zz+)l?g;lX0-r&|;Kr%!#BMT#vnnZO6MircK0tYa`ut%qGC@py$<wwF9Ckuund>Vdw
zcfihS!yGXZu)9d;^Ffs$=lzQ=CsDm5B_j(wfC0&YT=rK1u7DySIXZxRf$|cO31>t^
zmQVv?3GS2qHR#WdD+x<T2#1bP5-eGtK^(iU<F}-A*h?)M&#FVIez8~7GK;5G(2kHV
zF_r=rm^afHoNFAK#43cgvXqXE0wezVZ6q2mv!@K{wwtn*I;}t`Zl%hX<&<S*^JkRj
z_-hf%%V`I<BJw1NuFyR!flU~XL|eLY3P%ZK5Lil59`>0NvLnkp;rzJpQZGf7({xB6
z3{rHq98FOxK`hGS&$Q%-wVrx2ZQ~UdG4U$?a4j3B5yYW$xl5dtW~ItwFvj^Is02h!
zp!jMAy!i7_xx3+x(Sp`shDr;b{TQ8BY@o7hmQeVs<-idRnpJM9Yv=?yvxO=4rN??4
zWll$?MmmW?71?2y73g$kf2Qm_@Y|6@>*3GJ?aa$p+xWmHV1$gyi^i1>Eicd2hk0o}
zo?0eeXlEE;T4jm_{3L-zAfvv=uUd~Fi9BwJ$|8#!RiqZqxtyl0HQCt~p;~GT%afC(
zu@Y*r5~M9hAihol3gAzdo5R`l<B`T<S-bQqp{$jy8;`bSjcIBU>=_d-ucR2aUeZm`
z?NY(DYZsY(qA`s*qUz-+7QbD;p}Cue&z28qA2W@QzV<e@+gkP}>Xde`S83P9$AOPS
zahw{zkvT&vD_t*@%L@yoN-6OFV+AUlpEu8xnd!4wjM=VN#H`FHwwuhx#PVrH#p-y=
z_O4E&(X?&t6^(0X=Y%AqOzE{t<)%t1pqiPsO?=0kVspXh(}{_NX-+dQRbn*glY~m8
z*y?msV=0-!&fj$T5G9*DA~scHWyDHb26p)xN=wD@ZFUIxnyOPd?H~XL=OwUC0l$3s
zLGYLT1!&MFf*#U<e4t;2hAaqR89-FAfoTklH>xZPT|#LK(cn56g3J=dS$2^`SzSKr
z+?SI4wqQV_s;%r~c%!Q7RFV&!qH}%PG=nyQ_g3N;V<IfmK;7z04~Pp$LS=QuNJb^g
z>j?VOLv6V-uPQ-%?ni}DlfZjBp*NN~)DdAugT+D&k1OXg&}}nvHVj}!57KAgX8dMB
zp=1L^<%$PNRT`E!U?x=|t3`M#6t*d0XwtIFq^d2W&izeP#Ff0RqKn~=uB=l@=XKVd
zH`b3HS<O3JJrdS=d_j9Sfx31iGA3)!{eyAoQh0A_6AS@CaeKE^RaHKU(F|0iKz!~z
z@4LFTwz~7u>X9RO>IgVFZ=;TS)6YMnO;YK}n@L6@e-Ou{;d$)yd>x!Az*AWq$d<jJ
zhnoQ!@rA%|y;!dtg53esN$45yL;tHi$mzfV>2K^|w0b`BC|KT10(I?dv<vN`vO60Z
zwuY;!E-xr5S_!6jtFp_>*Og~yFDfc1SYDQsv$!f8p5H)~<H?anxmT{DvPc#W9gkR!
z<9FyMo6FDh%9k>e{f?i$bQJR&Ov;~HmGS(C#nexBisHXRiGRu!8~8UUO+Vdg%I2$F
zDd%>kOyKpFH}{5`AEVws{?J2E{XbTJ&N&cRpV|2AZ|rSEx&qF?f4zs%_E+_f9DouW
zr@!LLQ_fuG@Soe|ckoAY<yG<@;>r*8fZB+mRtBh@32K@B)0eIkrYB_r)V>*@@ECyO
zp@#rYgFqX36m4i|I0F!@Is@P=I#ZmVUwj6DTVD7p2oo5{!S1k$t>tG!Z}b4qBMjPr
zBxWq}R!3~~yCJsRe2`7W2zlW3oCYTygEkUM3<V&-Gq-{2U$}p%F|bM<I5PbX)S2IT
zP9n8)X@2K9Tibg>@6B`z_1bFbcZJ+fy81F9vgqJkgRBDZ*O#3gxti=z2HE4=3JXz2
zVIltb=X?Fnjd1sAcv?@M41R~I>J`#I(BJgR_sEfT_#tE+I~KopXgGdPzUP1#-(<vZ
zkMBZuJ!%o{g;x=V9i9NYIlYm?y>N_ParYxbd!4<J&2aDMWYISFGrakrT_FR%ojMp-
zEYSDd5WOu%Nb5Z;<8i=d`+2kJZS2n*M6lNnfFu|UB5BWSJycUq<ij5Ns-E7xJ-oMi
z&bRk43(sBA!`mA=|4a|v5sD~!sMrv0?s+9NIXF<$mkSEctXOg3zi>tWuK;X@R`g9}
zrZMrH&WVe&dd`A~Hl!U4Y6Pr4ihHgN3}Am?g-ioh2V6f6++(IiE{|MJ%||~T=J0qp
zdN6X(dz$P4J%g^Os)!R@pZ_J2c%OX=GEAI^Kbc~`@3eU${;0bfnI@V~!7J~>hLd_Z
zT#$1B^x*Qd(9`8$?L++i1ANtkfjbDO14Y|5y>vQyVmh8Soz_o}Sf|q`duyjruVqHA
zo`yDt@%z(?2MUEB8vtGuZrpdbf{{@>GaV#XgYg@afWY@D@oO`%v2f09T7LVv5cLsd
z9e_R@nd#@gDf<RLiH?6A8AI#8KK~Ps{kr!vYVX%z<`w#;4C?ng-w{#}G&GtqF<JWg
zgYcP%DPm%ni$AlCnSP`UKe+%MkBnJJ>&b_DKU+xc#Z3!Ps0`%zX)pmA>BUeV2DqhC
zm?^lrKr7&?0#yjIJY%m8eUBPva&VYQFYf*5i6>Cb2M~7A@&SJ2i6?$LA1JFsOJKki
zGw9$Mu^5Z#@}IL=OE2zxViw9F8R17}JprY-x$iyxS>^`d)q;CC&cjqHa#O^GR62+p
zR18>+f-r@PO3gnD^Um8FmjC79&(W30e)%dm0pqd#=fRK35j5_H^Qe=$8eDWu3AQz%
zj#nU%>#ksHBR;qo9^h;HVtxQesa-?{dGR+j6li>sk7TF{fB|F$gDNf(wt_fM;h+8d
z;lC{30J%>7^pRIrUQRNFZyxCV5nqQo`g-A$U%!HnG_?hxNRC&~$i~(nlyYq^8jTPC
z00rBNMnOBGV@CAJ_~)3Lq3!BnB))hq9wacLVHphT2#CrFHZsJAK6e3&g#wV0lhp=5
zhg^gL03I+N`1yiMtql-PD*%oUcI)^c{N(5xGzxy-)Z;w-ApG*sLnt494~>>xCzDGR
ztNt-pCc93mP)M(n$>#oJrCctR?UTv&fp>7(%8Q?^lF3ObFs~hyFZmA1ZgBQ;$Qtrm
zA(z9M6kdUo6<l6$Cfh5O&imowXFtr7O83eLZa6scFw9xQ07?S@_!ps}k3u*QJ@D)P
zuQfk50Mz;cAW|d$k98&3;czp65)dMc=!@ll&K!ce|6Fq$#6G;Z9Vl(TYzH>wFWZ6A
zHqZ_}S3ay%%G8JP<2w|JhZQOn>=Zlj;|C#Do$^to@=>``tvHA>2R}ubhm{Jo{9z?E
zQb}GX$yG`vdGld~QmG=zxd#e(U4A9XKB!V~`9l5*)j|B|m2&x`N-{t4ID8uW+dYY4
z3N?dP49ynWDX_l>pGTSe+?tvMgNHQG1IcQE6G4)7a&)l`mJ48U2a-r)FGAK7kce35
z4dluUYbz@1=qM^`!)mf8SJZ8>B5S;2_>X_zx#?;A*1C1b{_GXIzW%;d9&Z)J@@W;{
z{o<*YugA-^TD0=|mydn`;UIbZNd1NPN0L|}kQXYAX4ui2QqT~*YG?*BJoU=1T`xV0
zVuQnWg&OjA$OUnGnn&Tz^heUuA5F)dqiPPDgmNkOeg_zm4~9t<7uWR{FoDshUrs<+
z=F$2A5Wq~1fQ^{S5Do`PL|F3xohT5%jRHiw90Z5K(B+j5zy!iZzXMhO=DR^vf9al=
zuSYAjTD<&1)dztKIoGYji39Kd3{(0;4$AHAz0W<1KfS2-Xn(Z!Xn(Z!+oQ0;pAcAm
z6-CYfDBIf!Ou&HvYvz~3yq*RgL61W_VL5R!C#@!05(LY{%p5FsH32PA{S4~Bp8>I3
zg9z;K5J-A}Oc2x@2t<OgdLe8g9i%0S@j)F3wqc<Icf#=YMJdSxyCX=}cVR8Z+yMy<
zVb^eatK<v6eoXR-+HI29PGC3ubmR4FYO1?ayYf7Nr6uKUn~HYaPiF<orwm`k7i~9Z
zTSTcSwkA|Sbyp<ftDF@=jY>3MC3wGWbii0q6MQvTv$K2bO9IvH6-oFSSA_r`FI0h;
zwT2mAo`}XImkXVuB`U#Rr>=HTwzV_f5XfqH<jFW+xzHtA1mPG}w?#t9=1R3tRyLnm
z(jLsR+mrGWdbZ@%h05{%(&WU2iCH{e7D_?|c34Da+C1ln@cDVjsW4MxCoEt8U8Yi)
zM{YEKaOLLC$klO57sXvWW%2a;@v=C6KA)dYL2~>}=giCAczOMt4x}?He!kypA@A@U
zg%JIlwd^6|`7u~s*E5fE^IptF7D+)c(I(yjz^IF<2VcnWLsyXBSUmR;a{dT)d!&xK
z9d2#F^YCkrpex`3xdV-Z<jebl%lD#Od0#+2uW>nf(G|3=_j6hY+8vMq&@7}ZaqtfD
z>`Z82;87q4MV!4l3301(0rksM2W+I_k>HGBFpVPKS-_1wFy-`GqQJ|7*W@4*cTEZY
zdMEy>c+Z|<q}+)VCD-6*LEA3RX;(MB<lK_f+NehLtxamXb5q2jZfx~!r7Q5)C0K&K
zD?tkGg*~PCY<@7L98OXxn_5#gIqln>4pmcI%2JiXxhWM)`gt+O`rhC#WBv{lgcPh0
z!Oj+ef;h)243nPES!TgV0Lp_=0Vxa&R?x-{M~6*l^L&;tPvId^3xQ!1lv|)H0i6SO
zC~oqOJgSGsOPVxsBC1?>`SV-SN3L4bh9Y?l2d5>(RppOZ+1|1N_Z{6Do9Udf@!8Jh
zTWh+@KixEGPHAWN71zhcuU#n8rapoA)hU@1mjb^M&Fsk!Fsmm_1+&`CZ@CsOjAY-j
z?8va3W!0A#9^1dZvHsiVkVf&z_0O;Gx_$e^)ay&HnOATm<@SwvspjR>cer9k)7V+2
z?h_{_w?X}9;tA{)z8h@&x5j)O^CQ%s@Jq>$xQY&e;CJ9G6b5Gsfpj8;CjCA-UyzjC
zaLOH_zHk-YlcAIwP|4`o|AT%`2G#xt(Z}4d0XGRm$&ZsgN5|agpacbh9HSrN-i21e
zwV>!E1z3u{1pI9BKC~-R=ID=<lAr@3#&c>m9BN2m$jlam0B_{O{i|qpi(Bi^_#C-9
z2;%FPEHl=sP4RJM@l)DU%{r0x?RI^UM&CXCFou`_CcjprP>A#@ZCsK-6i}q<MIw(V
zC2nLzVTWX9wyV@GG%_nk+X|e#%anUnX0U@t9o?HYJvm_uuf7VRRcf6nLn{L9K|_Wm
zxx;HQCym<<Hd~(^J08xPtwnsAw_Pb>czFgZ@7QB(RY`8igw8IJx<xHlB`QI~R^(TO
zZEgthVi1U=KIEP=c9J9xG{ij~H(z4SG3SM+wq$8z{q3uCY4VgN6+1B*jD1r)mdNcE
zsWYS=H)r*Yt2Pav*nLo=R?%vCo4$jwD6$j+N4(uBRnyiy&$2>Q&{_g|hH((GLz9#!
zc8ld{9!0i710idYZW6FTxj-OEE!rl}mM>acUe@Ri<V`W?%Dl5DPnmr}k*CNvjL?G;
zTCCkPGFbsEYve4GdIU(WjmwgcsN1ljq}mb-p$%0TY9C`1r_=hO)`Z}g8HwwAW*ySE
zJ!g@0HM-sI7|=19fu9yU%Ul6{bYN|2;(Sp=_5N~z2U7u&W1IVVFjJrn6W6GWl0gg{
zT}l@$CAA*tqeMx}G3eYw&igmwN&pBwB?__^(z5@=x!~Dzr<gKsyD}oBz9k!z{kYQ<
z7iVe>BodU&>|FEHoOx7AI({V`zgD0i^1$+yDlPowt=E!>Jk>6U3j`|sUwnY>!)MOj
zo5R};ZgU<1y1)3R@@{(Z?fAAv%dj*E<I*Z<%XGUv^a%NARhPS4K1tOBOa5<#kr4F{
zVefO)i&Nwi;hP@WILm0S6N0ynu(mirGO2GCHiAUjN__ClzzxhOelGA+!ax@^fDL?C
z%uKL7hQ1F|IrIo{sS3k@jdYG^*Cqbp$uP(DQ?7@SIQRN~NfM`K0V8Axl++;9H3^kT
zXhpaJgKi?~ff*cZWWj3)7|(MYT`p%J2XtU-L^MiJQ_vekm6eD-?CO2pb(Hd31(QKN
zond4eo=(ft%0T^z_D>eX`>CV7<C~hC>X6!5oNZoY&YoI7m7azlp6u~V#t+eZddoI%
z=E=&W=kJu-oKA?WTrDj-|5|b~??7TA&7d84Djkt6vsjkBw30F?b+KJCz5v2mf!JK2
z&J1bcAkoXE0=}#(R;M(gm8dl~cC^Z1P#rfH6qpmveKFcIcC2SK)f%~hx9WVEKrIvr
z1R{}!Szy(srfRLgnd-zxnGczx;JecW*4>$$eS0m}K1uAv*}xxM1%71LgSX*rVC#KV
z%r!CBfltKi!KduapfPz{%pG7^dm225Jsk5G;DigKLIywxQo_YqR|*k#1btNiEhzs1
z{Z1JCcCC^gbc^^1;+zolC*iK6$<*+OY{<cadAuhO)(6<%J9jzs5Go$HY++yo=^@Z!
zJmT&|_rJK`{|NMHf0ds3F!FJRzof*U5&1ZE?ATPa7wsiSh?VCKl8tU{eQW2$i95-L
zHs0FXJn(=w^48vl*4A6$kN3S#rSfUD+#Wa04+Q4t=5qVUzCllTW0XP=N~Z~glsr~0
zk98>pUJ2hI6yO=@hB}2}oxvbTEKN)-ose#rYE?weammqHg8|R@^*cwY%S)0H5|T<H
z^Vt}u6Wou-;SbSbr}HE!xGNZps40J4UF12mEn51Wkx3{6Kh0aw|NLAmYR1Q?^U+jz
zJ9!A|f^d)dG(O(tvRYj@wzajp8#Xke|Bgvv6p0GJE2zn23@Xw@TJZS)zOO1S?pB|#
z3jVhH*2YosBoS8neCXDTQj)cyC}s?PnEx<e1U+5}JW~g>#UN-&SHv`cA6qidbKXyN
zpltekC$51<Ai(*(G#6fn41wtt6{Hg4zy@?ubN~SoIEE(YWIYvCA5+1SGU$xqQv7^Z
z7eiEb;dfD55Httfzjz;9C_`Ra5DQ(LmSVMJ#Jcz<p#`*|m|x#zv`)|-9+a4Wlh7vB
z+IMmL{oMWtx5pm|(}fW6@-?YVXxAR$_WQa0E^g0P8ML?^KcF>lSuPCWzv91!gv+;>
zwfF(tt~KZ_7Le1Qc?fxMAO5o@daXuDpFOZ}p4v#BYLw61c;0Rzr)u-Vps!$7lXH{(
z{EZXG!=eh#jp}&|ANUL<skP+Fpt=4=+=o05ozZaDOe*k>Vx=XX-#fO*6$-hey84P(
zFeFIzltAL&JmO<|F*wHR6m1)slxH;;#0pYV1+fKYYhKdGZ6eTu%oFRi;@d2i+r(O}
z7{7Vn8Bx0kRpOuTY9t@yH$<Jn`E$+;x+%WlN#Q635{hF7-qwg;lvBekmdK6r7sZ-^
zyWpbv2gNAigmE|gd`~YvGiScAQ-s_fOD-gYVjemI-#&96a*?8NMS^zEk7>YlY%#wW
z_^;U@nOO(p?4O{$lU4vzn8yZ<nGaq=1_;k6eaKOs1FL@S88_r=7(!BNz^o3aToB|%
z-O%PC2x<?xz&(x@2KtitZy0F0q(OzkTJne-h{nSOPbHu)0SjSRSoFI(ArovK=zd50
z4IxyEO_TQT)yP0?HDhu0EpOj&*=6tVp0qYqWaK&Z3Qe3f!JS%=kY1VMLwPS0thwVQ
zl{n5+ySg4%^VYZViqa}(kC>XBO?Svwx7+zb(NNFWHved4b)Ij0i@=sF75g%GRmx=<
zfqnSn4680qD@EITH>=81Q!RN;M}{R-8_u-WRodxs7PWb2UPET`_>-eE{cX)JF3WLy
zx?h~QrN)xQx?|(r;nKn!hax0O^~GgnRNq~ZYOgwUdI-J=d{q_FNygJAM0{?hMDFd%
z1W%&s&P3Lz$`n|^3^6X;8A!{hZ%ngW+gv3&r8j<vQm1ZDpo(O;NUR@6BkYjs#jrS!
z1vPKYOdcAZs1Qq_{ld6K^ke$m{O!yHZp}+#2ql61wVdejg4ID6cpjJ$GY{}RnCm;}
zobWxuI(2lP0joB+3c{j~)so3D=m9rgVLdnr^?=z6tbm}|{9@1W1Ayx=uqRlzmT2Si
zqnYWsEcx4UB7_;b6GIRsZ~<72{xSpi;1A)~gLa}g`0d0udu+yd@3;9<U5;uvDhJID
zgr|zV8?tGEFg-nG*szpxFMhye^_aYLoko?TllF#n(tM4Io^0}hz92rUrM#4uvD+iZ
z%MoNSI!C3+mwpxRHF>Nc;2iXEQW)-=7s@~<LVo!g{1as4F@bTG4)S4iG@5@}|K)g~
zxXi=R<42F;GYj=ElLBgbZztKBs8p*7KG3_1d`fqSd=?B!84Z;{a==ePVdG7Ig+k`&
zej7*mKx<Y5wb=sv`H3;pV&?oo9C<h#1z~wUfT3UGCVJ;Tf}y`n(tlX*_S6yd+^5G`
zml!?I@AIx{^=V6z(J4UAtf^jP{y$^qKZ74Ru`_f8fzcDiPat?n@pH@3AL=VB33h&n
ze0qtIqZyV`Sy_*60?Z6cK?nZti21Ft?O*LT&|!!S+Cv;;k&#XR8)MpkvfrH6-&bGf
zaTCmZsE>SjiBa>T*gMtNnp~nqn*lpzYrIs>{~bNQIrk7>hLzySa44*!C&cu`%=&}l
z+TdQo0Iq(XgD%F@e`Hka-7**-_{)9X_Uz~sw80x0`k$Y4-XDyNZIkrZjvsDD69H41
zU+Tfz_CG)4{Pvhea8t}-XE@j+672jzx?s@k&#<2Uk?kUk{U@k_Utnc4bRE)tF#i%G
z#Ch~6_4U!C5e3!!&!ghE#;|{9A3=mt)3agXaFvW_gXy$O(MQInXSaLz0lD^HK?$lD
zKK@$$B%sweD(&j0{&~dw4(&{E^RLilgL?zPO>i)B!j~F5%j)Xy)1L-fjbO(edG8YU
z7^FyU^-cAPfm(|aYTCE{2!ejE@BF*)199|#LeqM}5V4BuJb}U3yA-`=VP*XfN00tM
zuu~a1eTlL2Qj|c95^6~H&tv94ju)0A(O3^K)uV{H)OcCuao2xH#+Cd2E5q7{C0bwW
z8ZxX-jS_0e^3P-E_vik9i6<~<?st(nhfrq!MGTEi7YgX?4P<O7|F7Wam>IYO<G&=M
z>q1mWXf)*e14#O<K1AYQmVxZ95xldHjhO`6(|?dY<CG!8K{A$U2TwKs@$M6OC#60m
zN|n7kn1sF*oEi}b4>pZxJ$kft$zbyN4{>OIyUzq6_IeRWs@nb-j|Mnlz$J48?C1hR
zZBXZ-fpMb@5b7D0qM!ou3)b4dgNugQC=<&|Qxl>LwTnsU6S>y=NuQB~OX}C#BKro<
zJH31UMIIUoaxA>a+zYI<i&iyM?g`udIREHTGzUIETDjhO5ho4(`48~W{{M=f{LK=M
zB*@m(*MA_1q+Uw=pc%`Oig7LAXP>-A+nAe|w0rQV_TR@35v4}^5AblH|6I%#__uJO
z|F`~=e~;t?(tqkT+4Vn2BJ`!i&l-199_|A4oY2<Da~q43Q1bs<_#q6o|1y3~oUpAY
z_$diX>hHHkJeLwbmATgScq8EFLHN3I^!+yU(7%YE3W#|+o|6zP`se6@|9SoyObY-3
zr{$)iG?<Er98Mq5_`!Fj>)$sE>3Lor)%{zu(8aXDZuby^GLuO_X;k2&UGI-{{<~%(
zo}SEydLFuXCc0?idF7tA*?_fYCa^5{ot;b%zvELzODB+5e<98JpJ)YwtFau{ljsi(
zlCxdpri&AeMa5))2v-3R_vk@Hng+&lpjWKtgI}dfkE!<nO+(yCexW>$f>@uX$c>j0
zPw42;*=_eo?y%%e<_l?-oqz-A*5AR@Z_(IMnt|Zy56RvBc|6er)E&o^BLp7!RQ}f`
zqyO8Sba8Kbs)Tf=^)^E3)k`AR{kt&qJ2c%zJ&EF%MCrTrRzmBIR!TPhVVdre;0Ndj
zjsX8J;O9&|!OsVhdw|lb&yGyLl=wkUYNPaBUXmMVy~bSmxc|5CGeAB7CBd19{x|TW
z$tDQ;L9!W0z50LO2=~wQAM{p@JWAmeCoKbNFSoJq|5f||e+~w?{{nuV3QGun?k6M6
z`b&+U{b5Oz!n>c0uj`eg)BiAjhCxh_Kct)UKhHm$FfNS-DG=zSavqXd<zPDRl28el
z2<EEDn35VtnN1gq=l*?ch2JLTUL&*{l9K`T7O`Jqn#$r`H2Vw6`;XIeLxB_5$#LT5
z{#)od59RM)8->CdK*f2&%plg#r9sp6NmZopn8b>>)TCvRyZ$q)qu)jo`cZ<v!2v+l
zWY%7aCfy?0y!xL*5{g;VcZgoYG=XJR47ku#A{)I1{{<AwUImvp!*D%w3$6p19u?Ej
zcZkX2(#Z!>B9;OZQ$1g)V6q0@=}oDA=9%hK1F!Zz83OO6Dd5R8Hgq0;j=zGuc#xN!
z{|)mJd{Ykk>yBUNrv@kV3Zy65lN0WW|IIJHp{~LZT)671D*PsLR^cbWt!96LfAv+o
zFpO%@8VGye7{-s|efR)xIfN#z#zXO@EU-;`27Vi%Xfb>g?z8eg;=K)43njoa9s%<F
z8Bo5c9wz8s68jEa)F|lZJ!hOm^yH(qo<!Y}Gb>VoB4$)i6Vx=hVDYMGP@W)X^3<=^
z34!~-^DnvJ5_4z#kF?e*bz$Ax_pEhU1E6<nNSo|48d7HRl)M$Iv$n7M^MQO*)0mD$
z=hLV8DzddR(|GYVZ?$KL8MS4k$tq`-Z(6d8nfzn#0gqTGb(oxjIM#zsOl?`?%Wzuq
zwDk$uGVp*e$y9<9TCt5$<+~TYPk+84tj!LuoZGPBHHd^wvs(MejwDG=aO#?8CbUmY
z!q?u`dV1Z{_x*X+h>FBvwcYO+5Km;Bn(wplQ!;#A{1%rhtoAxmiovBrOrTHCe#0P6
zf6@;9eFChtm&aTlvjd>1;B;g;m&2g;8dZ{ws=!9iEodMZ-6aD!`^|~gik2f!Or3bw
z*7B^fHTznJ9hs8_#&F9woVb7rw>1M$5t}xNpkfxlkDy}xE&B?M%>$^&(#}lfS!~`a
zH$g=pO<FmlVk4kp(oX~xdPx)&Zt52NYVW;YymjisVTJqm{P^V)yY4-H)m^25l}n$#
z|G>gsS1jBfPIwC6^*`XtwWuFonJeZr0>0kH%wT+t@94+ZWl!Jx=UF4m{}+7GF+2O-
z1bx@PgU6XXVzm!0;ECq3lk-zRw1=ZsIz%5HFs0Xl<9|J{G{AwG2ZGPR&So8my5+Q4
zQ3e+ahuGN>i*BA4RGfhi;snLjdtdzQvlsEbDelqcfW?|R{rQH5=clK}TQba}-6^Z5
zI;=F!4(Y)W+}l&ng2yh$H1Oy<6P)CZzz@H1hp$jDzIMn2{1eK4;lW3qM_J$Rt4T|%
z*%!!5Uz#~)dS&a>IVJmbEiJnJC3B{>R!$$2ximemZAV>M*NA7=pFDZlb0fM+Yp?9-
zi<y#>KpVBSJ(C*hniu3JB;*sDrDJ`c2o-!^j21>E;(4b8*0UteSPbJLz+jY|&jzSI
znD)g}G#GM$x^~oRhU@SoBA69y0~n=84=N+vD`8gYB6asb*jNa03O1VzxB>xxMew2=
zxpYEB@AfgnTITd_JXQI(lUs&P&1ys0H-1_A@UgM}x30dsv$ndUV%a??vGaqYcwe=L
zp10WF`)+o7TUPIzuIY61xM4%upTUQ2fBgM52t~Tb&^?OD4STPDt&@7wYA6l{i<xQS
zP5IV@o;&haiO<jC(WlP$GQ6y`+T3lu9rbZK{NX+RFC?k=GqG&r`8DZ&e>!hT1^?VP
z1)<PK^dY2AKmSxh8c%TI{NIx|h7wZl%T9pt`;opksSlY?Ag*LO$kwVzYq`kp7MR<R
zp$wn}`tQU%lC&8u*s7AaY(xnijEU44L>k?HrH-n;gXJ9cA^vV{Yl4tR3sVY~4N1=|
zGL-P}v8@UDOZJKib)mGRtm2Wmcll4Y7pA@@tKYi0;hlH3oJiBf%L*vAS>iL;B?U}k
zYHf9=YizMJcI(^MrxnOd3CqxHS8h+A;_65aJ8dKJQ$BehAWJqW#F6JIe|mc4xz%LM
zS_}5;i|IbjkBN=5s|tXuig;fF|0*OB5(#4f2Do~#EYS}(djhF#zy+Hgq)@=9m4jsx
zk+Sz2eG<E5l7e0Qlc>A-ku2Nl<@*ox*|Q&M?v6Zm-`chJ-n(|~eX>=n@M}ini^=R|
zk}HHasxu|#GFcDt@2WN$?_0I%AHw7*NPNxM&IkA4@24aSQTLiV?pU+t&N~+v_pF+n
z!!D7`7c5Z>5mflZ6NwAc6RY+ciJii+zBhT-LccbE7ct^D>av(E(fLeHLjz5vIZQ>3
zVCkr*5-LoByFinL%3iQdhJFsV4bY-FZwBxHuDRI`@XXo1lEeTTKsF#8((zd`On^my
zzeyw)Nd~eY=8?qedB9YXM;G#W(v2E-QGSAEqm<`~pWL-$N7v*7hCFLkr7h3kr1|>n
zyiy}X3+AIyV^S<Gh(xq;#^rMr88+X9dd;|wr8i6li_0WYYD)L)1GzVdtaBU*tS?Pl
zKjLO<ev2^SPW)X{%g~|6jCQ0{8C_zjRP0*P*wQ?d_rS~<V#CmqfK(bN8EPsC&f3yc
zQ_~bVJvNx19~>(b%0f1&GK;T_WTz-HM+vmEbLytdEX>T%^W`NaL)A$>HAI%nS(wmd
ztK`Y%1@(y`W3pe_qIQP)v08f5uo0a@gsv1S*5DLb1%g-M8fXkj%rkv{Ho#m3b7MU8
zpb%J)<by=C7RH)kU|j&dW`4=zgm_o12Yh9KLmeP)!IqsHSMz|d0%PT{5^RsP$m7s5
z9wxd488F1-Xcllh<RQI`=uLx+6ja$rLkwU$z6pMI^bQ&Zzjs!HfBC=mJ+QK4^$xTR
z#eaEfUi;GP@uK5PmfqqoFZaKD-5dCu=gZK|jo_r`BO?x?vsi}CdS&|Z$=|0}p^x5I
z+RfLwHr+;z8=Nco3W`VDj;tKF=G0eUurz(=+;K}DC|Pp+*wS06GQYo+LMIE`&LAqS
zsxsGI70wLjW@KjKEVQrHU3><2y>%78tQ_C%@t_@G6NhwmLZeYJxUYdlXdOpA4w|W4
z(EflO?ew_Ad@%jeu?U}h_szH7#V1k4yKlYuE~@D5i#)}rm%mHXDDJi?SJwxF^;dIy
zd}rW5duC?))Erj~gOc!@bS?8T<Zp&qU<jE3z#SU2Zy3&qOL3O3Cw;*U6d&{p@>SXc
zuGLu@I4fZ3NOtP}UcmJcJroB*gg|%5080+;JnDoi+V7}?ud59_YAHqW()El<Vde1+
zl2}!IPQeTL{-TG51bok!3-#(;wW8c&q|)7d)|W)d1Wps5q7@LoTgrDD`80jwPe1ik
zm6lfZFw^yvUZxaDSdmC#Pz1eZ3!>cWM{%kGi_kw5=!NX06Aziq51mLo|F%g#dFasY
zSPM#`P^?gn7%->i&c#yPQ(2j$lgq)@f{Hl{W22nWz&HXvo)S1uuQUTL3mjp!9{wSa
z5bL5X2rNAHto)}B!i$&R@@M2Ie(t%t+it6R>7{&RzxCE1d*3Y_=R4XxS&k|vPOeOx
zjXDYn@R8Z^J&hCb-SQXEnI$IhvxGLIulS?rmoNBtU?K1-3@Kn!10W}%-?*!A)JHi1
zKiL>JM>&UF{YU;NGcp!!xvS94SH-8NgWFPf;ayvbjL3ZR<jHG7DJh{flPBMd5Bmci
zgDrA~JJ2Q4O~JLZO83MYjq!U*XRQrxlD1~08w}}L3R<U|k`ubCzW)eK0=4v6_%|}!
z$h<*T2&{@T_X5n*(YC_*zmFCcNPH+ZXMjZwoD;XT#EQ!m=IRqvgsJG{2u6g1&mjra
zkF+}-8I^+>v=01N4n8OE>v?(||Hg5{#vBl+R%>6<`CMvcmAEypxH!K}RHanAbiS8#
zt5w2-V~35C#i8e!CnpvwTwBtTlo^SMd51!Fxih(9nB7}clwcoLndFk&!-w(`6El=a
zsaxENqKQv2==nGqx?$NXcdSBRjER?7T|U>R_|~=)hbPy>8Qg`nr}s^tzW=`3LboBV
zX6k|V+tHBEAc<9B9*<*J-SP5rkIK0~q!Mb6p!(<W?JIWMrTpA3H1u`+mm5!mV`u-;
zvdqH5aQRZdM5H_YCzSL$zPT%xFSYMpj_O~)w?lXum1u!eMaBR{Uj)ws7v(OnIkkfa
zP%?_<gMC&t*k`rCs;v_&v}VODiCF`fVZrY?>jA11_&H&UhVe57{32>&P?(KD95u@V
zB0O;B0vy7;MV4(!a;^t7qF_wa2Qgd`Pa@>59{ke46c1QQ1*<wP4y>Gb^Kt<xOeVel
zJ5F+kkjE;ufSU7JPh(0h{t_1IXYrT0DUCg!%~8#uv}i~cYM`{!@5CN_YUqP^tgV`L
zWLNv5XV5z@m6n!hmv`Y?4s=rd6YYufHF=@Pd3-PSJhS$W2hp}4uX1DDzU#=WGtVsQ
zJb>=ow|{tL<%}P5+^BEH#O{d`r?0u^6z=e~oyZR5Y3SzFmwoc-WvdYT+2@h<+LF@J
zmtN|k<K4J9a%#H0DG+F~Pp8VzF?Yxb0V>A#^x$joJI)*kic$a0s4Z)YVzU=a?Krh*
z#^}<;FFdpL7K)Fo9TV{1dUE!>erWkUf1(z?gKx)uB}HquV7lS?ThN(P9a9%%=g)Wp
zX(n{w>2JO%`>|o>E%>Y5I^Ax~gKzH6nf0f8mgCn>m`o>p_iugXg~g@dTJ&6u3U&6K
z;O}J`Kwr2JY`LOdFDHWRZ*j~D=w}<i&T>c0ZtyO2GuW`lxQGF8wDV+yRblW)1^!Tg
zG|31;$AXSR4*h=CNcZ77k%z-jKUJdlL@mz;F8hx_oRVBsWT+1U!4d)!bUh0W-J)?Q
zAqQ|e4P;(Cf*qKy!w%X5Y|#@fc$bN`6d;O%JcfmK1TBfQGM2yh3A_T2nN#41OAFH9
z_xg=`9XRcmLD-UFpezdmepo^$YFjo9T^iYunV6Yq(Iy&tlp2-Z2r2bCoqoDiqLL{x
zX%aZ=Nj66zM|mo*DmbF4S)CoSwti(APFt?9H`4lXreTx;|EQ=oqsPtTX%k+g9qK}V
zf9&e&y~YL8^1jE<<1Gr6Zral?Ms7>x8N~b>zpr9-u{vWB%1kjhEobg7Q)nokgAZPd
zKqg4@nKq58>f^C5U7^*xyvULeTSUL>aJnZ~SC4K|w>W*~Sx%<|-}LzlObY(ytTQoF
zVlORKyJRv+IM!@;Xd%?tH)#sFEu5-WIJ47?3JaR11CLen6Ls=<)S<Q|i_)gM1BRJQ
zMbNxWp*z+Sn_5#=iC+&hb_ZcYf#1CuxRcTGlfZYui!mQVTrDMl-h~=aJ6Jyc8Qs$#
zIpr1fHu?a4g1&(0Dc_-=$oL$cuSsZ&Xxkt|FCl7SZs{MGwOmUI5H?P9U?x~2uFD7B
z@B#N197#l3!Ng8?z|BlFA=z`jya=5@kPW|qg)=-LBRH7>AQgE|tU6&Sbm1<U)&`0a
zB(q7>g*X>mR0lp6;0<U#Bz?dQU&;tU43_>^;4ZlZKcKSvBTsR4A~kWqH+ArF(q=hB
z^ysV<B9uS0*$fZMEzvl?=7dQ1yUB_cnrt+8E*@(R3Uh8bLR?5K=oMrvw1ZDBh}{|>
ze%LSke86q>z!ypRDdJNrS}xc_WGd)AP=5jh0t)cR0hw}d0#_{qO4uK$3JMC*X4OG=
zz@gRo1IP`9fhetnlmgeid=^MCfF?Kq30;W4K`I*3JA%Z+qD~tGk4T_`9z9`n8LsUv
zo`^SHD5W5>R>h_^H4-Sy5cxYXets3indYm-MM`v&J01EU1s=W@#PjHMahz1qB-YkD
zV&x`UF0IYT0A`m5{Llzg&Lj~d;>W3I#_Q5{v~}baYXoMk8f6qUQYy91OIwu^wMrq^
z36u3%=_Xy$-H8sPJ=S4~r+Te&B#ZOAwJ00Wd<c6zT)}FLDyu^29!IMc3Y|j!fsoBr
zY5cO$I!YiAn-wa?=z@5pr8)Ud^NB2Jy104naiPkR%YRQFUK<ye(3mOFz9&{GEqX_q
zQ0f@MprX}@YNyQrA)-@5Ar);@Enl{Pn#NP{;%J3RXtfx%TA{(*))Fr4WQHacX!uC0
zc;W#n2|}zI;{~i**%c5n+OGtDXJiMZisuQymjHtl;8z`>$f{VLjHXT|AfwZWVx?}O
zLJ0BN;~Y0j^>VRLyjUzYDBR@6w77hw#G7g|dDIZzjh)5q@%F@6i9#l|EwMS)IApS%
z1;gi?f_i`RII%=xvP0}B1w`te@u{yeF10{bDi&KAUg8T1HWT8&d)6^RzQ4gG(z4DW
z`ecepkXV;!To76+Hcg~gXazd(fGLTU#cL9BRARN;Ax=(7Zv$^aDMruuwtShyt!M9y
zuQG|ma%Fs23EU;6<BDZ*3WvUQ)8YaeBAv6e^!nO@8QaR877L&Mic%$z)bhov;$@Q3
zIHwQ->|JZ<w6<8J7FC8JKGte9db(OBI8-u|1st};>%?A0p-w`|_{`F9<om}~L)`DO
zJzGS`<87cQW^A_ZPs4Mn9h1cRsjfo4*;lTFxM6YiaaL#5f_5FHR0?I8@&>2fE=;i*
z)PK+VTkkrExUEVQ2S?P@+Ka=TBR$EtD-?yZ+(IN5<42@MfveJ;Q)WzV&t7Y%**I2x
zQj{RJ&bJym3<_$Q*eBx2Sh+A41t1`YFqS8aj1(zUQszUNQPEVhBWR_0Qkis#n#qFm
zS&1q(S<Krh7yC>QQ;^$}F&D-B(081=nn{m|1x^@*j)x$5QEs3PB0fVuk5aW)J1XW+
zZPprGQ|CL&^}A9f{50J*gVq`P2yNQ=@TcQLNbbY$bye1Q7G05Tf+ZClv!m}gZz1F>
z<v2+(h>J$Yxt)Q52FBW7e2M!GB0d43w?~ul7U~}Bd}Hj`j?Htse94hhrEVyLCe|}`
zzPnVvtH^5DOXX)woPWj8+O|h)I>u6#QHR<osbzJ~_VY0biqOYs<Gz!B?Fk`8A{1@x
zRd)uw<B);czJ2^04fa-*R+IYE;A{3gg(2pk2%?ZdXh?{e2Lpc&VPzo&4X(>zCJCe~
z72qQa&Peof0um@ATn5nP@uzcIoN?&n+!<RHg{sAiRn^9Ii{|2O1sZRI*>F2=`M0el
zLyK2pC0>P}DK=D>FI<b}qLnL_R#ocC@DmZ){LAV}T(;)#p)4w(dw@|1{2VLzgf9ke
zK@a#;S^~7u8u0bA5&Wy|jJX=(dF+ol9CHJi^#E2@n1f)HC8IjbU4&6bCM7}-15eII
z79e5bF5Cv2noKY1Ab~FdHW|HPXeUWI2NU31#b$*G0UWe(GaL;}1sh>307}eg;63sd
z@f;59J&x_A?mrS181X7jj$|9SPtpluk`u<^*At58d~v4zIDTbRLh5wXg5E_Rq7gG*
zJl9~*m45pU^1gF+h*ERFTfS>?S6NGyDPCv}<3Hgb4&y&(8Zxry?LcQKYWLin>on4~
zzb(dd7k}2QG#p#7rZIi(-0B=!xCs7U9Q2P454wN{ix$xzbh+#=7gQ7&Q}oH}b6+<*
z+EaEswQ=L=-RJ-D*uwg%DQLwPCr^HXmn{$EZJ_ODRY`7z!=Q=Xv2FU=wJTPr$`voZ
zs3`B1T)8F7u>~zYbMoZlc=MW+(lxv2_uQo#>*6HG>6Xu1@>}pK*yXoGzT^(v)#okX
z$$0?3;ussm8;yE?uK^we@jTW6+Ev8=`xMTGp&z#dOB}|c$l+$fD0VsIlBEtoEm@do
z2hdO6AsitfA+#h?FF7a2-#aJi07c&M`1Q?)M>V##Y(IeWaoRPz+FIk9(L!_|dKS%Y
zyyINMI7AUNAwi}}bAB{_YqHljzUi8+)N26R)<vimcCCvj3wPkI0OHSgIV`Uw*BX-4
zb=sXfwe8k}+c#}mf8P7~j)UmHsmm^dMNC^}{utW)k=-@XXKTbSw6yHx{_$%U&Pp$w
zUARa3t^kb#Cg^VFeU6)(#;qzU!9PSR^bI}`^rVriwGd-j&)PiUK+q9Xr-y=aAl0E;
z*sR2X5Of^yE9bFknf}GW0O#`ej{My+`<D%+MU$KS2^!7$phn~MH}|X>@}*st{498w
z-u`hC_LUu8>_XHQ)H{jFb-~{iWVeIt)?GN`?X-qfODE;!;Ht;{yN(>$<$oOAHE+sN
zRoFVFef#$IrWT>FrS~eo|620OFaBa;Y?K?XXL|X5@WxsXcH`aPe{C_05m$i^uv=mt
zig_aD&6p2jzKHoY<~+n_hbW2=n$v-NC;*YUOF&%Oj5^R*GzHB@i(%X+6dflLijsOX
z88#qdFA=tL;~WrV!10Zz0(x-l2JUPK1uO=pBn%DQ3_*q#@(ZMcJEUl2Yfz8nC}u57
z*qJb-0(JKrXL=3GBZH|Y`fga~BEu^;>O%02=rh7ofnmp=u2&OQDNxpAl5lg{w;a6<
zr!LmR204Z{Lt+b&fzL&P_Y82T_5JuAI1b?Vf4d$?H;~W3^}z9;egF5;F}-Q(GW?jw
zHa3-RDwUZfQ>>CS<P942Rtdx@HN;X7WuD<noT|j`n>1>LL8emO(rud=S2XQS2bv@?
zi%VmJ$-^CJht`EBTiu!OWQwJ0hfc5t#v}-(@SlFs;SCY~GRrLCiBc6hB!e(=Qd|}g
zh{1&vRhW<8wr8sNnThnd)gFFu8KvQEu5<KFmgZO4^b69v96~>STt^+e6a6Sw<M-BO
zAhAe=Y;cs|-SI(vo|x<uWOo#z5@*~^&W@3@`>jdVq+5((bH>4hP(lceicgA9I&KP^
zgGUmB38B9_lB}sOkSA~1lj2inlBXjRLy4h@<h=#tQbo@Go~mKRY5WS_t|iv;3G@;h
z1jDoO!`ZW9H&Jq#isf$-$!28_?M=b|fS6cbSFFK+l=Mpl0aj?@$FYLmy<<yFOVdY|
z<p>qLcM6@9N+ptn{Nj44xK1)?zgr;p83ev$3oS}ZI|l^tY<jcG$n@TB6{qK_(cO9%
zKVA`v+!q^5C7EuPu^A;Yo19Sy`QjvTbtP*u=}h>57?@EiRuVnXht+0Hmd2tkfbBM&
zS@RlPpMv9uYJ>V-IG!}wO?bD;pgN*6s~<2qOs~R&yWsc`+^d809!RiIZB#YEc`6*q
z_{VVb$r$jLOM@&(3UMtAgnO&B(cs|EMrQJ`5EQeCOL`%t6pZ<?n!PhUGLxG6<5_x~
zOskdAV<R*FZ1E;oZjH>KrbcEkkDuGfSmFHk-fLyD2&T5)YT=&UPHjE+9(;q$U(xRk
z_|eo4e9;EJ0Kq$>EeH`FqFet5e>}$D{KF4e6<JQL92?y&qgKJECNUGvT|*y5Uaa>2
z;QxmoNS~YgHVVdok7*&uQHb_P9E|KfLX|P#{V}Y!xmX)x(<82WBq}!45Te6U{dGhh
zsAiaamhO-U&{N2CloCg3@Z}5WRixV3jT;ZWkGQHo9<iW<%#^|P--%bE1l&G-4)eHN
ze)g>Yjq_JUff3n*^tWMv2t5vu>dpNbDm(Fupm%cpx%X}Y*igVjKgSUN*q;7);$aXw
zLeN?VjH9+eKgPyFK#{>4ZG#}UYMQly-g9(g&*5D^{nYTP;Z-mG6oMgp@t+K+&5I`(
z&^7tY%jfEXCk-dPCk!XN4;dcvK5lrtf;sVd4L($}N)sv6P&+h{yEIgs23s^t`8g0U
zkGyi^m7}g4`KkR;?s(-$`~&ZH{3%4YGSt-ksix+Jni@iSKG=6HJD1OZ>`D%>cLVP=
z1-P%J+<Y1U=aDuT-d%bR11NwBC~d$pr2+9|8t@Pn1wlU$B-}=L1u(r5ktz2O;-t?F
z?%ns(O1c8YP8ouljq#Dc#G`Y^*1V1nuR3yhBut0PA8L8HV(eOo`2J+?V{}#|pL#HI
zgzD(MtXrrP2=zAJ7Wiqce7c+Iade-%hbdp`G)|nA(_4BzjiDOwr_Yzwp~Q2Te#%j7
zc3<7xUYj4;Qhm1O+ZuFx8U!*F3ra*KLWx_fgD4v@Jb2?<=2m6{aG8riA1JB|1k!sK
z@Nl5ygwiKXEXo%o<Uip9)7<O>?z`X#;q`EVia1xtM0kvJ3=7N`G8@A5MchC~--ApB
z<;cm-$;&$C){*!l4VaIl%t&+L5v93-!g{r(XH;`2ungUpSo!eyqTKeb%rZ}Ank&JA
zKTK?I6UU0=nfk=sjTR&};A>0XNz|le3MACcBk{_H$wTL@Mt?FTsZA`&ud+O?yb>)>
zmr$mKyw?|%K5vVA(_TN;fImsD3Re4N$%T2@!!8?wgvRryTGLa*sdkGk#gl}N<QJ&Q
z4Q5G|9}h{$@}Z%H<%xoLC7!dW6n~aIXV~JQNTy_snUGOhiN89CVqMiDmsXq*a*=ja
z*teXY$V>tXcV5h{m?JUw#5@=CRn#{$v=zdv17!iiwB;6sd~TX2?T1L7qg*w@QRCJq
za07^ksE~wE9;8XZdL&E}SVvh=z#)SKT(EU`3fwJtnQ+#)ryQEV4?OX^2d~P&IXy`o
z^|a0Ra~}!0NVZ%vh6WB43~@k9)M9`xAukcu6!GB)S#t;{Z9Q5*XbfBx$oHc~<4BkO
zr+OXuza*Ul!hIxGmoOq}K!OUk87Y2O+Tvx`Uyr{p6dEM0L*ERwiPgp7jPznV->7HU
z*AS0Rh6!I998uqz`r!0Jn}`4Xq#PuRmGQH~Q>EgzgC>6BQX|a^3d}mEE^d*C6-uNf
zybN1B?u<3vT$0lqCy&jVXf``NrjV<s(3er`F2Q{%tPJ1Sd`&_L;w@kNB};A2&}S%0
z3)5l~)v+_i-Fq-rm{IJ*-zRmHmQL~seO_NOM!Y=Th^Y{AvkaDsCgadNu`#>RP<XXL
zfO}8Powso=b*-3Z?P`}H9#y=%uuiW`Yae^fHD9W0CXM?lG#TVWEjE90k^qT?FNmxr
zg?6aaqH_-$J!i(l7Kf*qhx;HjluT71R||4NQ<dr=H`*LXv%w?KQYMC-YgWgZ<tpG^
zz%0?4S9*&nmJ!q$7f-apP-Jr2b22rt6-W7r_+b6@{&`QXTkxX*?M*5HH{7XJWeR~p
zJm<cvv<_)nzArn7zjBmTRZUhYGQyG1<a}*<qbbhj@svPt&xR@GCPvR@EScjf6W_6L
z;pQr8zXHbe>b^JG?_fPnMnvKP)ef42Fs3s?q=V57+8ykn6~c;wj0{?qoRDTms6*0L
zF6?Q&E5v?x?z+fHRLzY3o71tU?<&{Za#QcA6zZ(a+WUY~>_zmw5?Sw~E~&|6uE_Q2
zD+&zBf#X>yT*}*j{<GugJWpTo_q$8ZG#r=PjFD9k!1XPIEV6;;7NP5X*2ra)Rb~QN
zZI;_@4<+b4_{+)>xuDMzt;3fP@hSnlx010uIxcw-$S(MVGzTGyi{oyPO7wRzBKjgi
z4MaMs9y$d%;Zj4xhfDUmXR+I<)avjp_*wkHElOF2ZP+1@C|$wNKrigsFm`!xZ1voO
zxbsyzI{a9qGwlj2zG-t?u5#tOpU__!H@wT{6_tzRcU~RG$hYprJL9xC@<mr3o2m9M
zJNqz7mC52fsB`X;u9}HU@Pi}2Mg>>l{97CFnpG!ersM=i{F$ySo^Uv)xP)CZZ7N3#
zk$S!dxN^t%L9eF?bj3Li36z@Ud$<t>IwJI37mOz^&Xa4X0CDk4xIu*kH4Vo=jUg2o
zPhcA0#5`dSbbe0hg@sQ3D=@sbZ}zl@i{d24gZS+VeZpfO+-u%664{I>`-s3zX`V*Y
zx967?XLkFS;_kUGdRCyLkt1o_p15Z3jL<vFajiNI-z0JfE3QNt839&y)%Yo_o|$A{
zc36;8S|ZlW-|A$T+Uw`H><&QS`(^KY&iXn$*S)gJt;_myDRJ9L$$>U$Y061of}dz>
z`Ed+_Abxk$T{CY-&CV^I$E?OZ>MG6D8G=9{oj20~YYARX?dT<0#l`&LljZ`|NMQCn
z#9535ip3v=7mFyCp=_k(lIn(%NuyvrWE5j~(YAo#0cjhg{XgIAYsEi)cLFD+;va15
z>ZCIlzJ>Ca!Af(<Pqt99+Fvo7!r$SJ<>FON^)tx)R!bdo{vYO%kC<8J-h@%<WASGg
zH@<}bKKK3An?-2Dwfmo1TdLJ~i_qqG56YU>3cFDH-$sn&_pa*5{Zef0Z_jT5o(14b
z%?O+_=#L)8gP`NVygSe(p^1WkR^MO9x6Y07;PENQ<Yo?kQeoe-|60es_ydvl{qe(f
zC~$=^HWF*wyYCt=Z_oLA(~sw)mULciBgVH?FRHzD;a!!H^Ywo&S^onadGbW<{E~aY
zhdj{1>}XyktiAJ~M^ypOVG5xhY-GM5pn?@Gw~;}D%>M+G08EY)2)p#^sPqTA80}#|
z+ycab4wR;%FY8@8tqufPoDKjPK|nJC;tT-%`7F#`kTyhg4jJ;C9lgVlhL$>-(&~Vd
zmlRA|I<7nKx;DDfkrYTsjC_ki6bN%pKQKAyE7E88s9pGzp?|_X_E#GVb4O>jN;Y}a
zwW*@|XECN)5$mim7?Z3wZ}EnAT!W~0gS2@>cg|(%ElW{$Rmw{I)M&NQ7Zj*bT|hG0
zV#$CoBk{SHosLa0#Ct1p^H7CI;8){Y^YdTD4{Ir9N_>UNg;a=lGMI2#VnTM=E&6al
zaypyv{lU0mIsQP-rtPl~hqc3a^_$9gzRMHsYgYT&R7ImQ%^)Xho4&jGGJYxO=#c1`
z6)|IoM407(<W41x65tjB2@?S~I9nyK<&>?XYJ5Z(rRHwJb1e{9gqR!H3&C1fAA+#}
z1Wy1}HvkzhKvZ5seA$#M$DO@t#9H2nGga&Is%rw0p&5C#s)s&3y(Sk`R?m4`5$l^I
z(F<LL2By-W;K$;7)25t_EK_bdO&^LxaMfSYLc#Rr>Yli)Il1`_q2Zh8cTRjUdj8Fi
zq)xDJ=c|yX@fwd_lJCmTal}7{yssUYF*L96t3%b}GVp@c>8(^*=V$oiVGn$kR--OU
z8euElN#$EJN<RD>dfsfPoV%y@CF;PK=iW8#ab`EPRCLJAiH!-s_t>wR1Qa~c<+-`<
z6aE~4TR~Jm0;*4jKrLyH1F}2-74e2mV5lZ1<j8r$*3fFW2@@DlR{&kOPhi6hn{JOf
zI-$`H(1am(wIF1H$IvF#7ft}k1d!2q%0U=lNz4!aoUMjbO~T^D-OFdqn--r*NiyPv
z;`@CWp3KZ+Q#50Sx)#isE?ydL7@=4qVr`jC^MlSbUsuVk3*5OAh00|RJHoN8MOu(9
zqJ}I5p0;XT)$567uj_G%$74Vptz#M|j94~9<<6&Nm+MkY;lts{TQV}H*-B``w42lU
z^juV1lkCYHfj>Z3*P5rVz$4K+*B%jJ8=7-?WFQ|~9OWv_hIa4r@HR_(W<?HqwZ@Xu
zjhlc0GA~;=97|;Asl^4FB5ZJ=uF_;n0lsl9m9l2N6-^y(x38<1v&-lwF%W--eO}Bm
zZZxH%G-%oY_&H_jXyYXS9)LYCxB%+P0oaoxOv3<U`U22BYPg0b?HB+#U^Pmd0<_aW
zS9<{DVbUuy;645v-~D2j+tNC1-mK-j6BcU{W7D?wgyuJeZ35vE#mM^1Ws>PL7Py9v
z(M&m>3DaC^f;sW^s&%SB$hNc|6%<HXwmA}g>SZc{r>MB3%a^)X>&=`Ie`-SGnAZ3_
zgU2Iz+|9cxxdxw@M`f;ApEzz>M#h#Yp~G<@ee&hQH)vGl4)lJ0VB}%E5xp%raxEw%
z9$GQoT#F|n^N37uaw*>DK%W$83Krv_j0$wDH(@P0-koEwzzO+P2D@gtcect~vnz4i
zI=g+iv)a0TO$xOZ4KM0%=P_UL?uL0F73>elOiw`Fzxfb1{JK33GAg9&$Vx2?ft{db
za%%!Bn_-KBiF6GaOje}b2Dmm))^z|svJp6jcz1_&jdTxnOywv}SGyK;U+E7?GNe^T
zZDz6Tp7ark8Kp@QG&+FyGS#W$yiaH|^GdqR_V^9MR)&qqwj}!)db+U5RY|KWvK{et
zI;CW!P{K}Bsp#;$`STXerWDfpcKIXk=v^tpGgdZt+`9bA<&CMM>?i-Cs~hSZJ*K&1
zW+g?lir5;RDOcuGCWGj-zpcH=yPNkq)E~rcP=BJa2wjygr=VRxwL@Vm?8#aGmIJCz
z(4!$}7BnsZ4H-Gf*auZ78vy}qHg3Gslb#E|90UOPb$#)HUjZfXs~V#*7a$Vv7-P26
zxxcRMoxcH;DZi?+Ii;X@Fj$mo2+$bqZ;0n%Hp48umcW3Bz@SbtWai>81qtIgif1yl
z0vMw82Rui+8i=;w4m1halm5o%7}aES<Iadmcyy>EGBA!yO>yArZ%0~<ij$Xt<cxfV
zGo%RdJW{nbmRB=*{j_!aWnziSVm7N(nqXo>nmZvwZLaZ*oSm0#N>7<8Giqy6<AgS0
ziZY)!MjtCos4|!4nb{nnL29)ql9Fpn(~|6Vt533jN_)?6r_rE+nC<9ENwQ>2sAIf?
zKa83e3SEtq`PLM-yL#A&MUy5K7S&`X=B%E0>l;O9(31Vr!}$CUb^acsmp>|%w#w3F
zdFcjm+zK>gZCv3M@%Z|@dC7@)-;JE1Ay>|xy?pGrD-(5z_$$o<kE>PXGn<WF!;{BI
zlKWvTpr2z_zzT?q^Fo@7hU-m(CKrHkG{j3jD2M3P02UIifhJeK3*~{?gw_zg02hvg
zQ>FO@Y@_;KA^JIxWoR{m>ap9Wt@j2?+(Mpcda^Z08RCO8)Y`=ODMG8PF4ZDV5XZ5(
z!e(upy2zrEQ5I7v>unag_xE&6YjvgZlqwZSMb4-z)nc7ioHBfbT{dKPD6}iDd%4p*
z)vT^kYg9?CB~)>?KWCvZa*fhH1C@z8{X(B4O;Qw2orDfes!Vk{Bd0Seo4t_SGR@+|
z->T<%T*K7f48Cc26BuV{#cD91AoGHXe<w2!=){|#osxbx2xz2X!c;&G(e@dDbC@Z(
zd0D52I5k`&l_M_L9d}ML0QiI64Rv9Tj^;`jQJxF!mZXDr%k=>=I*@kELL`jntPQ7x
zy#dWQ3h<xj?Pzljhxm6kUY)%(xO?T2brU7=l?guaE@P@L(^HgRFo9;%71rX=m<+GF
z{B~bYYVD}HGA1@fVasl5x0$lzwC(^3cl-0)sc9`)LVaks$L~$h%B#nk5^CIOE(b`?
znlnMEBsHxhH8oCAUcwib54p;p7z{sU^VM9LYV)3x)|+L`-L1oB<mFW)24^~Q$5YJ}
zS2gd=owhxcHA`V{ynJhuum=fzt$vp`cixg46z%4$`JI__()0`P(??Lr>?uj#zE-(4
zIO(=Yq2<%xo*<BRN)2dOPFrG|!lL);l3i|va)N)|jYzZ6T+o!0J^w32ZQlGser}cx
zpF7V8*(;E-t4K2$FV?6Re_x-Hj3<coZTc|&DoNWp(&5<PPs>iP-H{N6If$$a`W~e3
zW_ls2yC1auJ3)Rw8|3$7bS5(oV1i(S+d$!t8&GHus1tK4PefUj1wtPrZQ69uQFH^j
z1~}95Ss+WvOav<Cq!Wb!?c6^dO-$ASo-}w58U(Sw03AuPyZ|#5H9P@*;=8p9dc0Ju
z7_E(q9g<}sagZj~>4mh&We8W#TsdpjE(5ID>&&K{8a}Ud_Q<wTBU2l6TRm-A{B%UC
zW>~bN;$X?muAqhn#VIIORd6+`E3&2(9dxjwxD<7oVX~0P$>QlUid}x*8fu2PJzc8D
zSAW*&o{x4XAob~;e+{Nxv!O-%4c~oO=Udl>0uue4_U-YG2WEU2xh^TQW!SjMlvbwF
zc4U<ohx0QHOa1scru{)j)5Ps^&*anY+N6|~O^*~7goFPdd+!|>Rh9OS=iEMh?$k{0
zGwEd}lSw0iB(y*%p$G^{2_00VcTj97MMP9ku~!uAy1LdyL04?MzP4R;*LByjtLy5j
zBy;(G&Yc7T%I^EV-|z3Q-)3_Az2}_gInQ~{bIy56ee(VMCCZK$zG11Y=|1v|@F_PM
ztLgn!FMt%&2};(-@k}{7Z6XPtYHY+{H&B(p9^<VL?e4Lz2_)ytR#c?&bRiO>E$oF)
zgAY%hTRNh?s=UbKpAxfLo_N#|EwL*{o@g1w?q)9VC#~7N-8UJg7c3`(tEZfEuKk{+
zb(ss-H>7{@W#{ZYa`wXo=3?jaPMfpJ!Mu6qBwI4b8&hTGN$k2Mtjk0SidHrp9DdHY
zeoxj8w`+<M1*VEXrKNSat)|r8Pj0+2SYGYnFj0L1&LE`vfzX4deO&~jp=!!kdr68O
z0lG-pNsN#2lprz`NR<pgN*GAeOB%V3sKZNjCwzL@69|o15_LTKgvA=0;`bDlSJjUw
zojdvApr5&boz;C)cCS_5GrRN4U!)t>Uzn*|dXN3wbEZ_2!OIJ#XJ^<tosO!D7r33p
zoPA{nF}c_!>)1)=vXqezCT)|>JZJd9`L$2>8#ka)?q@Hpu?=svR0b+c1&LyfUAc|(
zxGX_xblj&d{~NXV@9XCD2=9|u@V|k{e}kXX0-b~D7SQJ>sueT>AgNQuw0bDBr(2Yg
zC+#F-83&(o2%nbi9dzybTT(U5;C#8>EGgftd~#0tN*kH@-it)|xSFk7HDhjv(^aiE
zNTtDHj(XpCe$J?TowU4m!)z6<KKVt$>bgFah*Yr`-D^%DPDL|Lj!J^Ur%$d_zLCuJ
za{geZCUwjDYX|KutNxe>FTO`6+E$j&VZWKfkN4F(h6PI{gTC73?3g=a)#lk7YL`p8
zd`g$cE@2z_=P(P?OP4BJ1ALgtr*P)BT<@P@(Z5+~7i5Q;mpXT<idP_0^%7*7f#8ly
zwR2+|(KdeCXgXGEf3~#@7}rnvJy+op%S}uoyUzdfZI>jUxU72tJC(Ls<%yqZvsRX+
z&D9x0%Y}(u9~eWJSuDXS5v5LwPnDqqK0#Ci`KTjj8qW@}fX9f{bmydsxT;+X9%Eca
zqfOC92q4u_Mm5{`6L!!Ga?%tm_qo6TILZtF-cPs$+ju(0)B}9l>0V%-?r?$wk?Sc(
zIxWAVv~#>J^Ps&7X7Vp;@w9dGZ&0tciJp8y{~b*J3;g_B=vA1WXa9!&I70IhdPd<)
zA_JL|wmOWb>3E24xN<t!zxAc>QK!&8`SK_2<D}+uN`4|krDNK_S*qVcH;Pp>iQW$1
z!v2l6qf_(gDFf?zPq~ve!Y5Y}<4@YCa+Kn7l(I!Uz`vO1QE^FyJAq}85#=ou!k`nz
z%n&OMOdGyy-MY7Kyz#Ad>vj#Fw)%oUk-Q^ENZy|=Sj|3q>m3`eTe<2rrHk;dty+2A
zhC6Qk%l2zO{`lJMAb+fSY*1Eky9C?u$e96P^TY~w&VrU&a*RP4RE<HZe}F|{tQJ#q
zM2MDPJgR8x5c@0-(`8~SR*LykHmXFJQPW9>sG=datFn9Y0L~HYj<WN!0&{fd&f-9z
zm~Q`6MDk<b?fq<qIef}?_4@VPJ<4bIG3O|u%1Y(=wl=ZjhqpxQ4}WET$NstN_r7(x
z#EQ2D_ozR9-23m}w|)Ea$&;VI<(BW?dyln8%??Lqz8{jDUipLgEk~n8wIU|OaLDsx
zp>0Mjk~$HQXaVMcmmJsF+y+~gYx4Hw?Zx`%-H2@b0HQKJk@rhPWjqM&tT*z0oA<7&
zpY?rSSKcw`Xo(n)n2C+#Bid3F5s^zs1*swpq(5mTL&$J4mP{a%$yCxw=8y$2nO{QI
zkPT2jxRhK0>xgT~^@yx?8+nGj1jUEf$XoF7@nMgZ#6QUQq>IU8I7VX3jE%`>yiAaZ
zG9^p}Q^nLU4NQNgl^MbeXGSq&naRvlW+pS2S;#D6mNF}0xp)C{F|(Q3#_YxnEbQD>
z+EVE&1D=+thDbr>)3_?*V(<+r%)?A9i*==FjLyQVZ3~S7&CJ1qDMGx0ZOuu?pS{QD
z-l5O>KBu$#@klr#L_|kVGQF=*<1DdSHP`9+sP{>4hP~HLb>xFC$C=0#rZ-eLZA0jS
z@Psbx+fTfqrjY4*o2E{SSKT+8K1rTbUiCg0es5OzMop~G{gdABd49ae$92v6WKQ$#
zbH5iX^&2=N;RT)(IXbJY&V8w?+O)1>nA@OzPoJWwpPrIbu6U=s8-w1*ad=Pp07kJV
z>gbeby>QTD-}B=z_jzA^PBZC!vG*nQ`Z&gWtDzb)FlDNAL?nKz{1EFuqG&*QQIX#t
zPdU6|D%#S2`qh~YYv#1K)hg$9KfKAj;z?3UN@29^`>o40d*INs>V1;w@maB1W6z9C
z>MV>WE(}FOI|~zqws<@?CJ^>_h9f~^AR5>fFD$skkJzP#!p?*#7K@lev7kN}4PF*c
zBsO?sKBj{c4TZc;%Uk@)&Tu?z2qi)~Z-GDG8;5fzYi+!`NI4uUi8Y4{f*OCqC-@Rx
zyC>@UI$9jnMoS{%sG|0iFX5}@^mf*0O?cw&&!Xi~X1RW7TQsS&S622LF<|^_-7{H(
zoz**F_u$y#AL3dQT;qchjQhLD&A~IB#SY>O4Guduc#7Q~S82ZJEVNr$jT8Tm`pSJ~
zce(puw5@;-miZ2{2AkPB!%^xu$5-Y(+fi&=<0!MwXY?+u?_+P$d#1h2`d#6O;s$r6
zXQHiCUhOP*obRb}kFiu(1{yskcZsFc{D3Rz5S*0=0$ncGSnQ_!FFdJym!rzwX(=;p
zx1_Axfta#qC&HEf>K5fItooM4@4ZF&l33SD1IwUivgGI=wSK*Kiky`1b=1ISDs4YY
zh6rbJn_b(jRc5UvX};Z7>v+lFF?bTjO8qmoYAd;}QnAMm&a|Y>8dKUZRO{3FKC{+Z
zOqPsEG*#&v4JqwHL&i{}4H!LdK#*=QWVG|mb%vRmYRz12M%rQQr?1l0Xy+LE8Kwx;
z!b~Z{kJLqUk@t;Fx_iRYo&HOu24SwgpA;2p*#fSHX<?iACHz7LY9*c8f@;m>+#Ax%
z{0i-SJ|;GivefXxSS52&Kv5Q2>@H71)$rQdit<#dLCX=_w1L%AYtv+ycksZ0EekKZ
zs75*8uxdZ~&Qj94XwjjCd|l(rF?X=0f+6IqYPou3g{fkQUAEtBHp){Svc1f1a%?gi
z<Uz8*Rw5haSx$5Q-LlEN&spp~-)3@F*i5z(i{3WJDLd~s>n+*WDhzPUz>&M1W=GNr
zn-#0kT8$53*w6MiFr?gLb5C(u@~a#cdkW8M@cfY1;%#tSymfVQ{dl|CHeI8Wd{(3V
z*B+ZkX{(<V*URDBn!ydD$`kD4l2+rknr+QapG$Nned`?s`ECAz{?~0L$MgPR%y7BO
z;x2Z|`7L&{Jt^s=8+|rkwM+Iai3dwZ2W-JlCB3%YCF3Kj?<%KkZ+BZg+eMS`de|P>
z>9n}+Dv#7`4%k9_kj4m)%{L<Kj9lZky61~Vjo)qdtPI*B{d_imrAPKH(we2;M4i#v
zpgp|XBYTGVZGqPk)_VrM`sV0M$n;^1uXO3959ybTC?vCnNTMu__gVc*qmEd8$QilW
zWA*gcn6;||_F&p?_pgpS6IqR{33@HQwNXc0s(pLz_%EQ%mca{4B&+yIQGU^YXntZy
z$R1hbvjxIIM`)cOYyMv3Dm*XZh&ZE;!aGrd1R&W`>M2<sb3t7$zvzCvR}ghXS4ej8
z`%-uL(D}vlwV%fG6KJI+%fpU%Gd|A5U2$`wxajs-#gnxUm(-V=E5=tfjw!9-XN~GV
z*t~Gc(n9LT<ep<6iR1Z^s_&%`*6q{qF3}Eu`!gYbh0=&*K;<sG^Q3cxXcpla!kLMI
zO-It;)+wt<O#%?cC4JJH2=5$17-$<pYm+|bu|DU#nEiWkF=I-nnUTF`*+*wb*A~o=
zu8SzI7p#roBD&z!_6Np{c|e)c`wrtaE30IgTx@1W_MUak=skmDpe8T5QJL;->fU_(
zlw2QQ8=W0l8?hn9+0k_|Wy9cPYDil$smwh768k=pWm)-3?*6>z1VP)?8}K_!g0K<z
zh_8fRreC!try7kpuN=*)P5B7uiqJ6~;@MDp7db_R8B7jg6c@)4a!aV13ba&ErS>pX
zu%*}3C5%V~Tx<ylv&YYS?g<~woRK_wOW7;8cC!B%RbS(tJFt6H(-mC(dBV|k`~}J{
zyZ3#;pP#K~4!X1FGSdSAc^Cfb6&?9*-PQPeobK3voI5+KD=1*TyY#6Yje(g{M~`?o
z(7fj1t<$nMk&l(YXRj3(zeeKZa%CGiL%I7mGv5z)Mz$`X`v5iyKRk}GUvVL5dz{eO
z^}shtUnySI8WvSa{Dj>|ul>lWb|by_>5=^kWxsMd917pw+1Xj#`44Qxo#X=bKrcEw
zxzN$+(?4%-U!neg-Fu>3+k1BW79DS>x)lOca53^W=h>i{;>GMj0VGcmc!#Z1ZiN6w
zq|~g1pdRReA-AC>P<_IZ&ZF1!hqAw!-`+l-ZdrB}jN_)0g$)ha%Q`yPvtk2Fuj%Z>
zE8g}63)-<U%Wu1_%S|3q+L;?0m{4;UZ#I*mbnFk>p=B|^YZRp#_#;8|`Gky#41}In
zv$v)ABo@z$2@JN;bmD0l5|->tVLd&BHQi7Wtx*=1)E0J~eXy>OXA5hUce*dFWF63X
z-dR`J{dr;S&g5MWRx+cKq@XhE{eDJa-9hf=!rI!x?8nTg?14&>ZRfel?193%x<Y1D
zW!K`n$Wx&IR>b#h?NdftyH3o6s&xrkP61yhg>Q#hS0s!TGR$l)Ia<RXnm%1w)*WMq
zE+5^ocyY(*<?Gt;#~)JO*-0iTcPQ_SUb>{CWAPHjeXy<VAT^ddq5mzSH91uaCd`LW
zjdLdyoMCVYJDZS96@??9B|1l`j{Gt)KeR4;E+BjIexj;eLC%JFnp3{)Ij73oT;p_d
z`3zE!{I3~GW_q{vAb%){8cl7VHEVn4i0mul=Df0P+bgeZvlcO5PQ7sL;AC<z-MT;T
zJ>w4@Ja}{----S8&@O-HpZ{d_v$k)aHReLckm5UL&~LZB!cWz2K0Ehi?{|X%Bm9Jc
z2>+t4D>q^GemSga*5_Ra&q}$vrxlEmbpY1kbOr$n?^M86C%6D0R&D4qi;qz1U}aEi
z2n$*=zzij;S&%0s(Ni{Rmy`k<{^^D~gq2r_w!glgiGLY>@6m^D?+Ap~)SYqW_CakW
z;|4r7AQ&j?IQORN<>@Jbsf~5q7yE}KGh2^7v@Mg_#<y>)KDcJ}YV{wxl`H9a&y7{9
zzVE(?ok~`&Te)`C+LhnmJG|p|^4mKKOF726W6nZ{!F5x6@vtdtJ$n0?;nN+1_bVmj
zH(N8Atx5^fCSht<m-|DCy{D^ItzM%%v*yK>J%7~B5)>r93SF}#&PGsdLUQjJOwzfr
zdTL?AicIbns6<6<6S0JXGQDzI!H^SlnG9cHkjCalY3gJ)C|!JYe8u_MhnANN)6H;H
zmhGPTyU*6jJCx5BOrKpA2sK=>W_;1G*ljR_YUsS9s62m`A*Guwhy81m2UZ8d@@!pA
z;0$Kbgg^#@>Q-|8#S?vI**CpvIJ0k8LHrA4f0?pu)VO(-BetKLxub(DP#z4$_GZVO
z5%LXZ4lZ}+yWGpN^}~IG?0TJ@93xNBdBe72ZwQ~kmZ2CB*FwLX&Op)j0OkQ$>DceI
z&^qi;IgW#+pf3-Dnkbu7n~Lz+@AvNg-GCXNm8I5vwZeRb@`w4;=al<H^;_n*HckS3
zHc~%pcE8GkAsdrQ_n;!?n(W-?Hedc68L{{Gzu(LJIIZ7?`W9t>sj_tRxVg!Z+Xgnh
zM4{PRJ9E#CgCcOeC&pTD%-+J3X5ZTU{Bvjy(8D^p-lzwb|Ce>gf@Ak?|F7!slhvya
zu37Wq>ec@@)yPzm&C0Ue20Vx=9=_#X#QJwXHBNXZW_z%<r}hY8D6OM%>C6ZeCwer&
zd*}8cLO{(VH>Z%BF-ax!?3km&@Z2g#dM1c5Zyf1i6qp1TQ$23LdM3{L^m~aDoYWzH
zTe~IOetF&eD_6A*G8*k?whWr$v=z@7+j{PHquEweHsYqU<WTXn-7o!t^h?T9qa!U<
z)5P-!-txqySJv&;%`TnIJalfX`%B;EV6}^R>Aux#_T9I7^?jAwXV2bFw_%+_hRmEf
zWbn*`TWabqzhmS0(Q77+9lNf+Wx^o2prJgm<Gkhxooj1GW%|8&)##aHE>vFlL*-=`
z#Aj|$mXb+()(+l!X2+UeDR;~+jj@)34bR^8+tv5&TeJGU`&Q?Y-#(kBj*Z5Lc<`8C
z{2aENEP7iRGn&P)iOpHVp5VfeaOIE{Dqu|{gw;?ghJg{6lMv;(w0)@^a8K|2GyGQN
zwWo4gJLR*d^6GTNM+FSHz&iD47bpGr7a@Q94~P1V5%S0Md*$d^LMlDvXk}YD-_^LR
zyJlHqzvb+q6%F=n+jeZd3csEBQ%`nm!(X&)ba%t(qN364uR2QS_q;;ZaI=1FxOnmU
z`|ex6n6a|obQ`lb7cXCY{f(VX=dnYVHZ&|{yvytBmv;qgd;c10GChAa4a{Xsa701D
z=<KJX3gQY=Q&XGC)SkSjZ5e%=u#|ZS);+!QUoZVqwxr55KfwfgAUan|=VFDWC3Cu_
z&M7IG!`(Eeq%u69Yij>Uq(664|Hyq^-*S4obzeGT#!mVQxt#7n2$v5CNBS#E@g~Vs
z9<01CN%;yx%ObfTThX$>C!SD9f^ioySL5iAS=k)NiGUjp9IGYQBg#kJjmk%lJVJu(
z^Cb94@_OY*-1zZ^8;FP-;`QXWxu;Bk1Rs7_`3TZe0Jrg4_G9`QZNn=3$dgJhy>r+D
zj<?|)YX(h0{mvevv~>zqV5FqtLY=#|f!JUolEa#?v~ot*)ESi}b9S;T0KRf(_vc)r
ze_+?tf&LtVl*!pYF#g`{`?l^&+q`A$iZbuc8I_eYD6&|4_ZRq{`6TPjeoQVO==Tp)
zvBs^d{66`8W%kv!wt_ORx9l`<4E<ljkrP|Mqk1_ORtEov@N|#AOUFn*d@nJ&yT*_H
z#j)&D9sg~(&PmU<jvQ&7ogPVt2%ru2cs)^xmag5LE-FkPRwyi0Mk}x2H=67xY5ewA
zDhrj5@LNc(B0>DFQi?ZDnX-{?a75bYMf#!oywCf&_cp>S#J*!e{y|<rk1nd5iTaQA
zLC%iBo<g-tRQ(izT0k$L4;aOT=#ffp;8f~0y~jUz^eDR;)vEl0OjMS3f5vQ5Oyuu$
zBbRq?V%L0{oyY9@l%Dl&9|^x#<`XhPdGP4x+$Ut$j~Da5N-BRl^&g|!)0c61-VJp9
z0nQ|ou;&<nm4wk`qPmW7n7oQLfSJsE=6q%ab2+nvd6;>OdE+NAq1{vK%U;-2_$aJY
zM=p`3QW_O`MOaK>LLPp4Aj@T-z62#E=nZ4uAyHjfK~M2h*FG~nN(o{{)n~!`7;8ga
zg)Rt}Gf)}E$8^*UGZS?g8L1~AF(sXLq~f&46Buzj;MyyZf}>7o%iwtg`Q(0LModJ?
z88tiHM<44{sk)jzPoWdWcmvX8oSOZ^^M67_qPd>Ai69je2AM#a955sRRV6HWsQLud
zA#sm7g-T?gcS{9+l-ZHCIT9H5W1}|diF5)^Vi6DuXPA(NiDx2>beu?tVhRB!@ogs6
zgA3q8EhSz0rW-960u+TY^9`_pJr%z|Wdv_xNz93)V4>nfg7~E=R(jN200k1KPXQdl
zQBnM=?_tUZ-_jq2QKXA-Ko1Hk#_3+w_*9qS>0%BA1YW18ixaw-Ll^K-j6|x!X^#Mh
zC}S>BWbVw63OenMX?m)10?gn7R6vJB_#AftP%4wM*|8IWNf^L7vFKS&GU14dIy-g1
zhwR`{4V4Rwf{^fC267LsGc<n(oN?012r%&VgEb3hiY}ZZSrC9)L|FLInVK~2mcv&Y
z3Smbku<xtRP<6K49&7nOX?UFJhaZ%yvtKbXncv&g=uug&6q8pC9&6ZU^|-Aj9o%oi
z&5|S;2<PTy*lJkGcs<96I);-tLRe8^B`wbop3y?5N+KE_HgFOHn`@I`G%$;58d?~}
zz-!=+r<hH7Wu{&ZX#7rxDMZ3txy~T!okfmlU9r*k34E4bESVUsOo)Z!c$Vb^hGFrK
zY&3+`3M@w$qLCTSU@t-jC_5*xT2|mBfpA0vzn&t`>P>RUg!fp6<2eatUS5gU@){Ni
z8W{)2OVkqt&q{ud72?DL1x>piw(&a%YiC(LsFSor5R4kVQG!h`D{2X^W9>+d2+TzI
zIO17yB_j$v+{JMspoJNn1jkHfmWQ`=-mcY&R-$(ZdW`|sI#y$G!0j9&zUoa-D8Pt~
zXz;Pfayo|5iDm|VwnRxIanycWqXEEz%o1K8!WM>XU~p65JVwUkVl-Nw=NOLD6P*P{
z*hYiQnu$Zw6UoGC4fbM5XLD*qlR;~?ijvH8JmIw(lu?4Gi=oqM1v88zqY^E*VC3Wx
z^_hfLr)PLAXB#dNT6?mVNQ5VaK_i^~c_d5HB`X)R`DOWWRwprfk!8$YVgXWFNe8b9
zJOfK&coQpUv{sbhjjF+JdTlgX%^(cM;PvZ6T2jKx!3}1v%ufng&cRqDla|*Rn4dCr
zHkwQ_Z+4I9;p@y5%&zP_@=XHN73K+Q7XYD{s0UusO9IdgLep3UtwFER8Z?|ilz0Ph
zskNAOL?<wuC~B;PMYXY;BtZ}BQz8(N=Ovg7@kGb^I6UK6qIGDJ8V9E_J<aYWJjZG^
zASVts(k6s+1N!lbh;?a71U7M`7|<BZem^m=I+%!oJU|YDj@aD(A_8jAIVBW>FmQ9r
zh$cp~@gQG=06NrZc+RM|%VtBNvwu5lj9<hsdX^2t3pm^ou!4g_K{*C)$0+6U687X)
z!m#|iycTAy;P86ARTSY)i?h*YCm2=wX0(Kr1cBAq1hfEHG9p)#z@siDEob0}nKQy|
zmmbuhkqnI00FUlG>lP(J^C`og$#8l}E4W!n!)P@cJ6a3e>2kb|Gx0Jj87b`vqGXUH
z01uE@syV9xS^%kl4Ld+@KpQ}9=+JJIrya>sEz8R;CSR{{*A|^UAtbUIH!GNeKp~?Q
z(eOCNqy>gpY07}Mr$9?A8ZT->6kI@+q_ZGF(SRl@NM^=h7TL=*6fj;nGBm`XnadUj
zO!IU)qJfG4kfjf?#9+#2V3#e+cFsjuSuYw0FVlvJc29J+Jj|Z<l?`-=)36)<HSZwP
z$t*IDtRNdz?SX5^9%utpGPg2ES%%fIR<?jmv6I*-EJnC$?@xU(_V)VdpVd`mOvPeC
zBLaR;`!3w-?e@`gfHOPL>(Q|=oCK({06l<Nql==w1U7UH=zi2wCzSxGU-D`=>xonK
zXDSHLBNYW`|46$dRg<bm7(l0RLK>ibw`!m&qO(OelR$q>`<+Bi9)OcUoF<?chCcbY
zRFFXW=n@gek-9&Gw;QVT2}p9%0er`x+lwbm2yfCOBA`g=>U4(635^(bs^HUX!f{O3
z(Bg)vtrhJ|DKeZCPKpOeHLB!5&*}4C>4Azrv=4TW6EZ|O?Fy+70W6`5t$-wv5-FMi
z6mC&b0zF<5J|(Cqfwn<03k(C*w%j?c@lQo6L8O%efE*bo4BS+?!g)fj0QmH?bPBbg
zR%hR;Q6&sDTlFn97bKhRsX0~BaHLc%e_D|OK&77(NFr3`=&kV{u>(c#Eg=d?3yKgE
zDpJ+TrqTzrBLQmiCjtl+LI4I8`6yI^Nac{Ec!G$KEA_NM)2F(x$QlTsb$~m$y?TYJ
zKndX$3bG-UO;phYV52TGBCe^uOF087qqRy40*^u}ypT?iB@$M}l)i!rRXb2AlnPwb
zsVv1Yut4edgv8>fiBgdT`{N=DE|1GBDiTrZ<8lkgg5u_6!KLdg&fqOCYAPi0q6(AN
zlP@>P0=z&P8J%AAhyi1K7;~3h!<mdCrWIwl@MUx`jiB7X2o|R01S32u!#D`OQy9UD
ze%8Pme0sN={k=Zrw|7|en^<0B(pe&c*#ks%+Rbv9T@vbN>{nP7sV1%QijZ5!h>abI
zwngK-waNfNV2Eh(vepno;*tQ?%nA&6J$e%KRe}gPh!N4r^CBZi0)x~fSD_<HbVeJi
zXYw_S1SJ&*Zxm#V92u9S7X-b;8VFdO%Nw#afW@LO5m;i;Xane;DN}PxE{+pyRQeFT
zf^5_>ybeF~<>*TUbAyPkKx|{G%3`w%okm6j@6grCM+{#i2-^NmBM}UY9<0`6B^JRG
zu<AGi%OgjfO(<k}*2HUX<2a2@WRyRm3!&u$M;6eZaPS1kN-|@%+w(<p5FAnpNJ5E?
z=<^YI)m3b?%P!n;^7($hufVKf84*r(jS}y|3A`-{tgPjL9KpZ~R$zy4HbaQkj}@7q
zZ{TzyxWCS7<2VtVos)ES4f=ewgM+;bWWR2X<+Qwj-m1#W`5hk4$T1f5Sm@M6qmHqK
zJzn1H4M_o}SkP)9HU&gme$g1&R!}VJi~=GHc{IAXUlb*i9X+BBU6K_C^o{~$_{<7+
z`!5&itOf(LEKFWrFY!i$gS8kNic_6q28x9sNQh>vMH9cq#4;Mr25)odv(cYHHWS39
z#KVXVjaI;zEIO+^m~{(fXL?GSO`>Qrb0*2avmt{UAyH5f291N&ST#CUj~dlO{2If_
z1zI~N8hNs_sA<rE6zgCZ38Gq)MKnpQuYzN1>@7Ajo{?e=T>)Wo13MZf>UxMq4%rm2
zX&l7OQn_joAw!kNj();@-sNE5Xg7;yomlCCD52$8E2EPgvcY16+{l=9j8Q;Y9U6@+
znPf@tF-vZvsMTp?h;-IyP%`QBb%MrViNP^4WMd7dm~>zt2FNZt)R0zdmLaf^A`RR-
z*TZ)j?aKRGrpqOw>?cckqP)Rq;B6HP4uT$%IV+ir0Rv-zB*f@Ah;$G*AyokNHom|R
zVy*eZ%~dWtq-b7S!Z)~iIA`J*J%kJ@>#??YRecNt107n8fzg&g62tHV;uAq5V~Ej>
zmZB@rh#X`@!WfVT$XO8bt$+ao0@hv__Pa-wturJ-Hmw8!WfYNEHlG(-O%THbJ(?@w
zqauV?eSn8Z!U$S3l^~U8SPqiQU0S$zg+Q-mbXruVD}n|sg)RATVQVvsoDOvl9BEk_
zhfY|hmrNc((tug;f>Ceua$a84+JX?~w7g05K;-sIZZ~|6=`ntxBLc0_Ed@OQg$;9%
zVqKgd2pYH;Yd{Ge<^;*4ktDr7B^a%|U6!p5tz<G-1xQRbtp~$1y-_fGje4DE09qKQ
zPGi8>NiPb5&LCs70F6XFeA@yGs1ZUWElxaWj}}OiI*o}J00onMrKMoTL^If?1_oh1
zwv5whWuI10-2U2@d#@O)2}3Z1lVGCrH$h0Ygdy-tXp)4BLuQ3I$eLfe@E;mp7WBLr
z!T=H4cN%R4kE6+)ALfI^trr-pv79w)wOU5ti3P(*2{I(uM0R(5LCFBUq{F2)T245F
z-r-<uC2(>>*!*Umarw$QbH8vfl8_8>!r07CgPYZcv^tqE8oOlF7GS=7-!TF6R2O63
zygY9QJZQg|_cFPdY(~6=>&flp0C}7|NuGg*=Q!pi*3ZV-ayG*bXU|~Qu^ZW&Amv5S
zX+bukJ4iWI37PKFDJmP}c6Qn;$#j?ak0kgXNl+E|a&u1qkp%z0mIQ~K`N%aZt5;t0
z$eBah@psDQW8HJuOaCJs{zp3ek92q%>G0_BRznV)+=`S@^!i-ha`bQi5gGp@GXDQa
zWQ0E7hsPK(z^{jXQa@-B4}>SHc2yFj6Bs#J5bJBIG>D0h9(fRJFg+3>rp#2C(BXuU
zI+Y9Q456x%fg@Cx)J+WR_D>u-;Et8Ath{r;(24%t6HKPM2@`e)CJY>SCvM&`aNvXh
zZW`<R8H^JU8gzgw`ydy`LHUzQ`BaHHEbZ+UN9?KLPoI~roVogj8=oHjRNNuAx66)r
z&&{=S%PJQ=J)FGEn!CRyX2g)o%g!X{D_fZhvhX#Vg)<)ZBv`Rl4te)~2_@AGh+$$n
zp&{_E>x8Y!{|v&e_t@)O5m4#jfn>aL&p?=VwYMtw{7(RFf}^sT_tudslqGer{JOSI
zSwgO;Q|7386|X=)Jj1U<?ZQbg=58}k&ScYAf$mw07BfHY+(fQh$-Z54RN#-&?Z>|c
zxi?>WscW-qoQu8P)%9f08oa8X;fCF7nX2Vkg;iM9FANk#)cCL<1*+&6!^~SwD-XWZ
zdlbbb*AF{a*A6vn<*0ou*)Y%<HR_B`Qxo&RpsMaho53nqD_8cDeFnQAwf%VIXzr3V
z%>^wc4P2WRr}a{L(CXop1`JgzM|LH-F>P&KP~A}V0<?DMZ-iipi#o)-9~6SH>WG5T
z7&NprG`b}%9-TxBQLir0pu<~maflh)P`Hf2PBb#qehf4#Q#Us$tv#Y7e%M*=A84(O
zY4gjbk#!S`+_HZF^UyG_ogrJ!9oG2cgPF2?rC!LACmo7^Sa#^y#j$XmvUPwxKT_CG
zR20*j$^B)1&s_GHZcujzcgaYP#T!368akua7WFn88s$NDS9$kE?23|6Q`;TaI`ziw
z9!75}@A`-xG|3DTc<35*9GfLg;f>HW&_E-~idNZ-RyhP#$IAdM3&j-7C}5`{DF=%)
zhpO|G)9Zy+6jkrdX+Wtc!IUS(Os<j;3n&6zX*Poxei2iynow^P3kaJe$_}_~R#jRt
zHJi$v(LlhVYVntUJLJAd+4bDTVvBM<A*%$Na_v7ROUlmbe5GpWaOLv>qm%|mzgRe5
z(OcPkIdC)*%4a2S$y@C8B!9--Z%3SWU2<gB)%`=2-C+2u&h1JnR-e&Et|^X{m$p2f
zh*ngD<7BUoy)VnNe&yrrY~~lr%g`x5CM*Adtx$_u`OH=OUMBP2du3(s)!4bkh-2a5
zN7mm{<XyoE+3$#;Y+vxMb><D+ENB08IySVy(Y4E_zqiEWNEY9FZ@JIy@s-_6&AFii
z)p6_wOqBc?t%K^87v+@#vtlCcOkm1Qj`4|@Q%q!Hn3@tX;~2B^B+bUK`YV$d@5C_;
zryv)v7}C-GS=T(~EN<{6M{js2aAXSqSMsD%cC<0Z&m>tT)2(IPOxG{Ec4iNAW4qpF
zEZn$Y_F(pa@+<P{tL_TJ>ch(Y<RgZec-J!vuaj<FukHSX`Bqc4Ae$hU-nV6&a^Op%
zdu+T?t28jvh-=KV1)H*0v$0JTpbOd%UO*f8sXo7|iQUV8RUH)QZcrT*Xu_qe&}O3>
z`$G5UtRtCiXCBJ7lfNnNkb)Wb>p4~)JP38`Y?|4fot3R(_GD*rjR%#j$?X0Ym93TR
ziWxJq=@~PCN5oBmk}Gtadh}w{yiaJtU<U4a=Aq--F4+gT#vWCc>}IBw?COpq4fw_B
zNrS?2y!7;2t})pi=Nh}dW#3a@MK1e})d;J2LG{Gyq!!OHs72eMtd&jyLK%u#2)*31
zmxWb_4s|_$=#ZKY+ls{0-647hPmt`c?xzm*?vaIRchCnOS&b8|M#F^eOV8@p$r?UX
z6XqvyLMi{h;6)r8xjZ|Zd6;fLfgLNp$JKa%2UV|L&AV@%9>+&t&70mlb8rpr&7t?$
zi?Ne4pnla)#@z|+zkh+lQ}aCyPT8N7;<Q*kxmdk4bX>RU-_a1S^w3b(%a}slb#&GV
z8bTUBPeZ(Nw2I%YzDj9GIS(|XoS>o5zkvTV@E$tED~ArzRCgWiKGeIXIcRe9d>o!$
z8lt*lr@+>W+ukFs*WS84sone>J@wZ1Pw>Hga)PdM1O|HswT<=Qhx&D=x{uWU=d|?I
zw=AcjvlAuAVfSY;M%_Sn?i76Y(p@=hNAms^?oY)_Z<$V0CqJdZ-V&a!wtlX}oElI2
zQrLb_?c+4`kEw(qh=|8ZLs3F?A94;2uT)Kg$Ji6962B_=QjxgYo~CcXgI<t@e-khx
z>|pwXg-IL`bQIy_6S8Vqo~h<8jfi5!1<H5IKQE{d#Yk#1to<uDrz#I^n>B0OONTEw
zf60bJcPU>ef4he~MShtK7gRP(NH!P^{VFFkR2GD5SHAP^%3AJ7iBAx^TjmBQObE_p
ze<=vQl2wh~VZ*$QQab2#2CFk(i^ZGpk00;9vwJCflhM#U$-v&B({@i}?_^oJ*Xq<;
z24nZsiN1dQ!12(M{-7)u{elDiV;GTF^H3YqE>2yzKKT%$s?!klsk$sR@&T}?9wV~o
zKN_9-E$eU>jMn^D?(h-oq*p|qT9!Qe03TLfU?Yj4vT~4(7U1xjdU#1$ex~q7aVW94
zcRTaPDZ<hpA1^&qSn7yK;Tb1(KVD94E>12tl@R~$N{-J{vY3da<kbHf2#(9%^X6?s
ziM;jA{}DW7{5GcItkrw7(Bhzd1p0kx#wq>2+J>niC$+Z%3sEi7XfH3#pus*W(XU$-
zi((bF{;+QbKHiC*9)Cx(+?!oxJUe4X9%1s11%*7=*s<zpAtdB=1CbvQ<jD{`6Z5#6
za=ex5fl%o}%sYzWZ0O4Sh{uk@`}kvzznjyN1?KT;&lkB-p_r#^=-NOwa2qysZ(!(-
z1i`j9FnL*s0>|)Ea8zi%O91dP{#;l9hERvJ4LW%%)cwrxljMZH1ll1LQ8S4cn?U4r
zVOjIQ_2(*kLY;e*x7R&BZ&sFD_vrlDEd$q`OJ?FG^UkeXc1}5CDw#3zvTsT4f$t{%
z;(=`2cN3m`=#87V?VK{<Y~=<#P+kHYgv>g2lW+(35jZ8rh#FWHY7k`$0yo4%;f`mO
zpb~$Pyr=HSN6#v8^4?T>`7HT}y!Rr##7>C=Er+3SUdkmQS(qSe+9|(dA&DUZlbC?9
zD2`AG(h;%r<#|f;yu;+~x3cfF7bu6?t|vtYSof_6!nI&NaVnp2$?h*+nEL|rwelQ!
zR_VW(6f3{|`Sg))!U|)^o_us9M$^B(O*vH1{=@<0i^DXhmyr|m#{30J<IT4sS@Kra
zoXaJvrztO{dE~+J@~_G}!t4B<uz$NWkNPrsHt$u{Ysv56(-{k{7*bImCGhc=izo%u
zsf<#jJfIAoU~F*x0<{cSN>lojsd*bJjjDM3?4kD^YN7$x9;)FWUWROEPeC7pj^~gt
z?XD5>4C6Z=1}%a!MR}4Pk;$onjEHC8#0V}5<s+vW|BR%C$`IB4fOZDdIU;tvhKUNi
zsA`K=XCOY}6MT@Yq!y)kjEM}~K?Jpgoic77IyY4B6b~_wL>Ztel&)e_NTAP=Mj%pK
zB#8jiD)Z}mz|9zPqzU0;AOl|4!Xk#JPTYYi4~ngxQU*$OM${xJ%EAeU@VdaqN+d}%
z+!e*ZYLL?Mbj$ADX|E(0q0?#dYFIPf(z|!J1ln&YXsH=7GBYf(hdAy}49kohQPWcJ
zNL!Hna-b_5fP$*wB?qhHM=FDB3mSsIIvh?H)J~ZZFL8a#RE<@>P00pB*eo0BgVyL-
z>0kUX)nl;9>7af{OU0YMuC51y4F$Ee1?e!^T>fW0Nj(Pr)b=(lDQ2{DIFnwd_vkD^
zZmRx!B5Is=4KL<4t%EUts~j$2M#>#CvVW&v?b7ij{U4L~YqWgHpY_ZqCD4a0f0*H2
zC9y?Jw~$>gkn*&~>>Zu7zSU$imX;dG)BrJ=bm9RMqATq;nYF_6bT>RerWndnhV+P<
z%*g%-nmIC4Ga_wBm6_~KuUq-zv*Si?8WSm~X=+c`Drf&nV>5alU*dKvzX_P^@sbj$
z(P1t+_Tr4QibA32O1|FXj4H~Zv1iz-1a?S!Q%ylZZ903~X5;!Tgjc$r9?NQ@k?i9G
z{hS;txxb{DXj_W>T$mZc30m%YyJ+T~vP&lJUV~BQ7N*^9GJ3D^>g=L}Pw0I%<}7?Y
z_!l?G*OrZCHAA+ZYhQ(-mZbc^+%H*;#YKOK^41Mn%JZyw&kLWk7h%M|l=8e{0z#+6
zo-_TV%>r$K5=X=yR;f;<MQ9bNgah&uY3N|5+FG2L2<dh8qJ~SOB#bxWl=>;Tqp|dS
z4nCTrJP^I`d1i#)@6SwZaJgLBVb*-7(OYAWPHTCs5rWIBEz@E)V$phihWvaxyT=~r
z8a?|Q&_8Q1F~n@p8l1&zrkbEi?DMy}-K~Bf%i7IMqPBRncS$n2#5=k;ioXE^TV}l6
zKEP5~YWr$NOKPA?<VYkEDZ00PLbJ2k==N)Pf4-^0=1R?(QswfOHu1J(m7Q-Y^&`3!
zVq9%K_OZBvO@gaNu+rUtxslO%3laTpY2M1bwRs!i33yB1m3dbqj`$6EH~08nqCQu7
zG~0M2R!w!goT_I$YVgw2k;JN@@I`ru3G*dTFr$%^;VTj<>0lmw70y-s;R<m)cuXi&
z_r%VCH-9Ptsw@Pb<J=6-37A2kvk1^>%*1-nMZSsfh%JPa4A9+k^7K>nodn*irtev?
zC9na$dCGgE7q*cy*_ICbd1Xt!yC_>WvGe|^9sOEYvg^;N8$c!vOo)b0ibshblTwz2
z@utpT{UG6SDU*Jk&7Ype+=!WDE+Aa?K50JFIWl|RJ^mpN5mLx>GdnJ-ZMkqk9b7m*
z!v$`4>>hlL<C;N%14iY|L*<9hd&~F=f_WS4-zhg~r;$nJCARF{%6o;M3|6*l$k@c~
z(tW(KHF-EWr(OAVgRc3lkz<+~GVuoH_C22AMT>?^9l{mIYSvUGYwXHZrB|+fY;DJ6
zXdoAs#R^8VRUKswHi2bZgC*5cgRZow<yKZ}TXy#1enZOB1@~#a4;&ay$`Y>(HGE((
zX7Wo+);srKK4JFY=5v%8%wI~Zg&l?dk|njtbf-Ba&5CC{dlR2dIWqA25k`c0WOT_(
zGR@u>OUgqXMfui6ac|{|hGw1eLp<WGbTm;x%9wWz=0~UT2Gyqjge6ZYJhrAW51#Yo
zrOF(bC<JvtwuOib`&-%vK*XYMALx<V_s~dZ^jzI~?jP4h#QmJaOj}*gC?P0UK?Rn_
zBRVZ3PV*OyJo<;bYg0n%nn#Xmipy`{lG(p9R^{2Z-Xi_!*$2vDlKFt1WoKt!gNE*P
z^t?Oq_rK#gu36U^ldrpV$4%Dk=ZsyvY~{|6Zt(5;-Hz$YZrgb~aXugTRrk5dVDf}t
zDTF^T>(q&>n(Oc9n2lZMbARvl-jb|k-%3tSDi0==H<HgL$)A&1XOgw5H_o_z?xLx4
zuS;G&e)v-Fd3A#>yYc*4r1=GZFffij2P)xP;+$h22|Kt>$cMRzZN0WpxyWHD*vdBK
zq)Ljx42<R@uo*#z7!i-J6R;sWomNZaj5+Zd=BnkG6-G4#R^76&<LC!`v_M%ib>pp<
ztO@u?)1McW<SWzJI%Q3nvf^A)uDrD<Us=c2DAREuMH43c4M9+D2n4xJ%4XP3y?Exi
zS1if*c$D?GzF4R{3x#LcQ)S(xU3rK(a^K{sn5_BZS@TZ1oxV<a>__F#>xRCh>>=%L
z<yFASlW&yef=TdT?jV6kt&8(kQ7#P*0`3W(LL*7UMU}<$N)Upx_ZetHr2)!0sC#nt
zBXu-It!zXH6O=2_kX25^$fVqavK`FxQdQZw>isuEbxR@qT3DDUSgZ~<I=HH;d2m&#
zr8eOSX4>lNM-Qph+ak>H&V?g~buxLPRwMh91xm3qoIzwcjox2X5%xJdW-}qnJ_Nz>
z+Qw<DaU&Fpc5vm1s<H>8D{I@8%|ZJ^mawERnmgy(MrBBy=kUQ&es0x(fmNyIfwfJQ
z7CzBZH=@0+ZY1XpE^Hq$Yk?xb9)QnS--q@RAr<+$U?gZRsT0f+G0lyoT$Z)2=1o{v
z6g49&Jo#On!!Pb%J(QIkA$RDEFamOjfBHnZO*zKiA(Si2l&j;wHIw&U-i<J>c@W$_
z0W8CxTqp<$sRt{-5^$5(gGsvfpbBV7QJQ!z2GkEK?<m;?XD*zYIcH+ykOAgV7cCr0
zR^9N(A=ezYEnVxn;z;XdH(mNFbIUdJ6@^IW>~1L<+u{^Lb;`FPsEN5vGW71^ZEy<1
z<?RQr7{%YKj(>DCb`n;7h&7guLHRBt(s2ou7VRM_64HXuK}kKq<N)n0dSZ~#H=sF4
z)sEqCl3s~P<*=Pt&%k7GgTGe!t9?MXPh^7GvE1^Ds>=^P_ELhhRT*sdu)HxM&X01j
zggHKLg2r3NrImNBWUx|T3&oW)Q)IB^{c&|-P?HX=2?o{#UZ2>x?!1Sd+jYeiV1khr
zpQ$V&O8Q}5hnx2x9=69|ujBP-xhz?)d?0MZ(2vGgETnd$6cSZmTBSPz86L*4C@($B
z0j74F4q@Zm;&CQVRc@cXFNr_pnv~a6JZ?^vhwiU-9~ivVomBS<JZq5W@kV3PJ$UN@
z+{IqapWQ5M<PY@be`+rL@%%%lluX#D<}x?8@6CUXS|+;prr7WM<TWmrf1e^zzQyvb
z$KDX<ac`Y2f0^3$LL3hz>C{hO%!u=HkoD{V7zOYIaPB1gZ0baDlvNZzlPO|)imc|J
zx9iv&%u{{yKRFlc@%*V%{J!{SHulY{o?@03puTUZxV>sc<SHe5Axe;4+f!k*+GzWN
z!M(VLy8*S2cxExwJo3oxDG5hIG<rB7chW16G>AKjRWp^^og7?lfW8qiVb7FJmoB=@
zzxBE!H@>m`xfd`hyp6m=tXKY3`{s{=_sD$ZpGv{9i;mp={*^>S9{J_X%tZ?>8nkX*
zRsY4ocyjs$`wv|3#QRJ3Jbdj3sj7EeU>A$;T{r1tt8d!cecR?eSGb}TWjnR3>RbRV
zsah+EsM_Sz^1?X?8ejy$%+d04(i+MLKI%vXA+zmyZu=WI9=UF-|FT7wZkj@>w12%4
zy1DP5#Eus#-@p6FMaz@|<)8D9=w#u?nn5TibMr6BBSdp0^WgpqrYGaU#r><+89uo7
z;XO;<f8v4z`_@kLSwEh%?%u^PByzn|Rg`I6QTW_E$}^Z_{Y8Zzf;q$te4;L<y+p3}
zhdD`5#WF)fkg4n+>vy@DSMRG#gg)tc)@Oc^LIh~ASL>wucxb|0ot%I-2XnQk9N}7w
zOC4_I;G~fyBW6ueUeg@D`*$DQd9eFWXOFpT*`7I*tDcy#@e{K9oT=AMzv`{KpJhIO
z^tu<Hzwudq?fJ_BRWpVSuD`grc9C$n`%kkcY@M`h*~G19%q(yv3ob4xxh34bXUV7?
zljpNH9N8QbMh!Ae=HAo?h<l_ndSpfC%oW+X%g&irmvlclg?~bCTKUAzbEj7X&Ra*y
zAD=&Q+?)s8CU57Q6?Xadu#Rot6e-xGJbg*$xMGi|c-)Lj&lpr(9@jqJVtp~;Dw{Ny
zwih9<NO?khTi}4xG;q2oZ*$%~IlQK6UH=STX^>7#+ENn@+Qq`)M5P6Y{xP!}=$g_H
zsN)3N{+BrK!8%K81eOg**O40$2x4^x&NWX|$4`h)?X<+VU*h`f7TaA2Z$7NJed;9T
z1I;rxzw?`$p5C+X(z_-pj}%p}OpIlo+VWIldgseqcKScq^G5bY<<0YVPMe%MFy_+T
z6?Va0F?8<aoo8)%<(9{pU+=%_>0j=8OjtATJb&fcg9bY*svF8u3x#KQKDOl{jdPc>
zqOoiiiB&e)Q{lJkNN8n4_PQD4E*-z<xt;q9<eGwuii$6faniJPi-&HRFpHc2;zi{`
zd$ayb?y$~BjKgh#mzPYNc7E5(S9XrHea=?8>&97{#$G8eSoEubQ(irmcR{85;fb?L
zBTxlTPh7uk!P#ZL`724}fm!1_I`1<&eN(0{wafjh>tUGCwk}w(KHLBLF-=Y7%Im_e
zB2FX4i)OivuO^q*llLx|+EM79IQNl>O`e(p|FtcaE#^?vSu!3B3Vb@R4Do2+<X%IK
zuP5GIKSg;J+K9>nC?Dvv<#-sqL*D=crz2asRipFzR~uw2Y9|E=3taD{jdGQo^iJtV
zt^b@+8@-9T2La)XGM?VOdIu56bKgahctS-4@NxAFmPG0dRByXgc|$4;<7IW$$w_5D
z%nK!{`I$<ysjzy;k!PR#s?l1`iMUF})#96tmGv-WVi8plp)rg6zUJ1#RM}vEqOPQ%
zT$iYs?sBEe1Ab<nW%77?b4qLSOwgn~{UWaLgfsJ#%|o42D*HPcnp*RxM;l?H!*X_E
z3(K7oaV}%)YYHDOuZ)MH@zknVG^uZ~kGJV3q@%t>FvPlS6%#vPn-Gt$gtb6$^4V-U
z-42stYwaMDP9puBg}fxRy9UTYt*@ng5Fd*;YHWrAd8Q}sN!17)L(0Vgr3KA|mwYuD
z9SnZP7Z=&JuwoQAO=YA8>hQkZ1JnJ^3!Gu$v`Y%pe3jqn^i|q*>{f%hC>l+KZO*uT
zya##&I$f)$COWYrQItuw3G?-h`EAkCL?RV!w*+l*hTY1UCpGtXl}@XsdM2qsgCovy
zZrPwWduw!NwtvdNF)>@T(quG9ML~<VA{>b~y4{|kI;nbGA~Gm7yjXOJhN4L&75vz?
z`oRv?R#G9u_NXdijq97N-sB*5V@+9Wi@C1S)fP3?T7vycs#Zl3&6!DzuF)Fd*m%1)
zffbd$v`t`TpmH-xC6xMvUYb5})_VuX-Zy$^yO+l45z0B#Sgxl7!TIT^o~A+FX{m;q
zAYE#wshTsYlbbj@g?_0?By9RrqR-JUI3lHR+Sv*@f>t>nu6v~1lc+Z*Jocg9UaAId
zr_n<vDI<17=sav3HijxcrJ2z*A!xig*)osu2g=hf*Yui%uDqb6F5w?smMUy*_W6sV
zp3I{rE!&jJ)K@k>Tv$`jE^|iC;n*#L9VW&`TVr&3err>MqkrWT=g{V4{+ScPu1G&m
zS~J08(x#g2<I7|Gpz;=9tsoC@wF?qo=<G)%ooP_5)y|UkbecVTa!|*vjK^WQ(=ib<
zQ!Li`e9`m-ee1e(;Sw!pIU{ghzx2S}KG+@CL@Hs+&hxU?UQ|3DhH$z}jSrU5%>||5
zfLK1HL#RoC@Ml>H47M6a<j4J~cr+BROh#j?m^&s$YdozwT?L}{j<?61ws0aEEixOn
zvhe=vb2|N1<DHSggHpvcCT;b!Qdj@xNoH;<%UBA6miA~WktmI}<u~f*3vH=PQKF;7
z#ySSqw~gg1N+uN<K)J=kQ-dOjan+J;XxiO~>Z|Ztf<=<SXsV3bVoYoQ#)Nl7jO8NM
zMjbOL)0~K`sw(LpwA7lSZLZ2Xb4w&tR<n^El=NDg^l@vX3Z4n%>~^nNZ;;(Svkr94
z<T;OR7C+<n!beIys2VynVuJqo3{RJ9cq^ZAW}Gn=5g1{Vo53}GjB6{sA;$0!Kc0;x
z#LtwkiI|;#B=l+7hlR>rgOty%-A1?%Nr#@)?R{_KjpX8qB(UYd9itwYt0)td`!8Af
z@pa1Q8s*~`j;&kTJ&@FfKPvuH_%6ox8=_lHCJlgnnE%$Ruiba^;kI`JU+md}2stEq
z@3z~X{LM(^$AMoheDkH*k2Di=>m&Q_-g2$-xvVIcY<}GPdh7l@`}S<R@N?4IwC^YI
z#hjS9qd({hQG;Wi&B12{sDRIkYZX2#Ci|Q)1nY$_;iT|=Hb}Xv@WZlCLr1dniKu*i
z^^OO(kibN8@r@hb+e_;7q~k-vZEHUEg7UFO`TV+%S6-srKT%QUK5*G;qWcZwyDR*s
z;*Y|lc3}5XGAQtF+u@t{U3>Md${)zK0k6Ed@T-AD9Qm6kZ`*dSa>S~<yJgSzO9&iC
zIIi7t_r6D3m9Lv0nSFR)lk(K(7j6TD`&(c4J`VV_$DR`Z$u~nopb7PdLR)(v<gI`Y
zzZ`_L4gnIqp+X2KDTMT=)*xyT&%}Rzv*Yz~%8Q%sd*FdPFHv3`_xiT4zrOmnV@cg5
zcRu*Q-ItKMac^I}<K0b94?UK*`nCi6Z`;r{^yv%VeRtziL%TQLvj4zs>#{?i+{kRY
z_D@#j+lz1BxMRo0n=d8?%U`bA@qvrzFT8o<_U#*QzEJr`{<}LiK4<^ayz5qP+qPoY
zf<N1z+jPk*rcdVXTD@b(>RogHXvQQCn}baVU{$e2)gMG*PX`@=c~lR4Vva_C9zvGt
zfja*Uob}|^R}b_;`r(aAHgj57AI-vJ?$?ZC<i7!WC`l`~k3Io7G5liCX<=u6+kN#v
zlooc$TU4$hdABM@#j~)s$I}@NI2f^tXJvJ7WMK#T7Jui_Ysl7Y8J||}z`K0j1Z9@E
zpZ_v1iusRu@E>qK5`gqVf9Q><d`&~yBshc&bs)w)EZAdMAjCQDViAK1;&=-yUx^rf
z8R9yPbmeqFiBYDL;m!orv%?B6X5~xO4-=TI&roxJL}6y3d57gOS=_&B)s`uvuV8t-
zZSiyKzy4y$!aJ2=??2WtVS&NoOU+i^`;h$Qx$~~GTef{zK7@A{%ouLr&--Q)8CcmS
z4Tx(?rcGPj-|$NJo!#d#J5sYX)<?5j+4I<xazV(+w_c+By8AHEOuSOBQDXg>t1h#Q
zi&!Eaa!;uH-Dvl1?17q^*8Vj+iMV6QuvyH?&MEKyUistP_Ktm;jyvvwZ>79Xr(ZIk
zmpxOtz}`8RE#1T<YZIK|vCHH66YpUlNO4^+D>sv~nPt~YR=q2-TlohuG`O6c!PR_2
ze;EPJi?Isi7mNj#u%R`38xvN(&)&#PCz|Z<)%w~=hHzJNf9#nJ1Ku%>O0kd5k$NVA
zlnW6yCn8d(NVL=B5X!HlWzDb4UC(rm80|H!zc=B1`JB?L97S&~Ye=y2-lq!vkM1rd
z-%W5=|1K5$ZiDb&mErHkwa$I{NpI>{J(oY^t+Ei+GVJw%OZBVD`)CcR_5bh7k@Gd%
z2}Oa8v_NZrU7r8=g7(o~<A!?^zL(D}-|j4Ybxpsxq`&4@MgB+kl=6q*>lGm}$dzY!
zP895~Q(EW#_5dxI-rV|Mv|v4WiE|sdSEzm!UCcRcY2s9vpm^ano;7RY17)VW&scn}
zNxW#UCvw%z&h!2Gw{M=8F^hH6MwR=0w=k}!Zz-~W`6M|Mj^8wQ;>sJh#{<8;nHkmG
zztDR<@;w<RrG0Vo-zh^5BfGjfxz;JC6lUiw#|tCXO>3_V`0oThj&Rp^b&?BD6zb+V
z#|t&O{{Xd6ByT6t^KT15s%Zez;ygIJ5#c_AHqB}}v_V(=w(^JXkL4{csZWSOXPtl8
zu+a@2ol&xs8Nz@0G8~^is~q$tBC(OR+p9N8Z6A(eZXi=Ao>e_f;TxnaK_iH^eyZ4k
z@U?Ot40ve{Y93Y#bUuV{`VD|{;cExC{#{w}>p>gk)>O2qeZizrtG*-~x}M?xR@QKI
z4S%RIada6sUKyculy){<zce$=bH4H!OjU<<b>`(w&C64!%8f!LFfC!7hQ@y$gmu1=
zYOIx6;6WE)mG4T`lgV9qPeLo<A9-0g$T1QdVy6_t&)GP#l&n)do9rcbk<Z{_Ez3w;
zh>LS&T#_5Yjo~J6)3~|Z9_|+IZthj?E$(;RU$`H*Zgkfg-pt#0FCXFy`BF$N^?ZMR
z2tS&i!cP;Ii<`vD#ogj9;(qZZ@e8p_a!3VIn>1P)Cry;jmO7<*(s|Mf=^E)q=@#iu
z;3|?%IwRDn77Quiq6C!!-3VwD*ehUP0j7xYAY|^Ii3q%Ar_EaBkeC{RvRMKw7NJNY
zkdk4EL7j);GjLJW<8?fN)WaEv-C2cd!1NGYkx((7RtVC9gB1wgkiU==<<xLPk)+Bq
zlwBaw0y2VmubpbsAU*me-YSD*6WIIO=~@Gve2K^qxm0ItBDi*Snii#ZvXIK`C=2#9
z8+B4%W$c(uj>L1WLNMKpk|&Wr(x5)vP<;67pfJ*+P;{tl9tlH-1K0q?($P9?%(OfX
zgfqm%IXV%F6?{$0j?ScKOpVWJQY!u7wpt8(6;=bN)d~&#OJ8sT9q{R%MATcL2J3Is
zZ3<qX2{|b=s^1ZHB95-i(9|LcQ61c<${uQ1SDJdpK{J4%0X-laI!w=0S0Xn64`A>u
z1qzu|(4iPqR&roqalnzW(#HS=MN<o{LPxb&Fw~+H04$=UYW1n(EI^Kb<OHocbgP)!
zP-hWDI_-emfDsBcr6p8%BuVd4D;%`~)IPUoo#_Oo;Gzv*&}5uKLQO&imI4DSUU;@s
z%K%jtBn-Ymiz&i|56uQ;2l0SBR2b-Nh6)8<P}K=C$M59IsD7yyf_DDBNTuo0uBtk1
zqneYs3;0`sU%ld-+w9)TRMC;EX^M7~5U6N`nh{8d&iCO*F^}80MTroO`snbK))^%h
zbs+<kN#TIsm>!(td38#4EtgbbQ$e5@S94PHKw4>azK*s><R!xE9L^|?>1<MOVW^2o
zQYHFa(bPRs0VZ?rWN7Is)Qo8v)lH=uTJkV0eNU6YHHn}FK+J|~8d9A=J5i|<(^i$3
zdRG&rmF=K)5YM^DvC@N+HmwRIL*41n!h#d4p_d$RbJ7c+O20riMK)R~Eu3m8g91Ap
z@ZF8i9ZobmkhW9JR?S3h5GXdVNm)tG<cG>*5xhflqy{6@VP7@nEAa^RXN@LK>p5+s
ztp)AML6^y6w7!vpNPQN?fPXNt1n$#zoB(a(m`)~C{HN3h3Ci76{sUi$pnC8r_(rNq
zR8@j?g7z9I-qkXO!CwFbLRnx9_5{`86xB+nNNDXw;GmJx1MbqgQ0tI#xCCu($cOHs
z&a0w_X4`Wst+qn7ag>o1t$PXwf<dUQ2ksE*S<jDh8K4Hpf%y?7MVwGlqJD(HdU9pO
zo(9vS6C3IQPig5v25Losmg#44HBcaZx6ea3QKY5snLb4Grmv;|jY=EPYQyV2N!3%|
zL%<0oPP{;WJ)H?KLD^c*dq_ehXix+uNofM;ZlJ4&_YqN;&fd^=h^+8gHHCuy@K`N~
zN<);6XdYnC=zQ=U)%+FlwVEG%J;9kLFpu?YwHAQ3Tp~Snq1K2x!<2~U(3{JJP93Rb
zR9~Pus8!o@GhCgb0goNP7U%$|24T@+QFT6*0izra3b+b9YE`6MiS{4}Fn~sqs-}J<
z0f`fJNs*6c1ITSDi0^cu;-C(^G6c?~<FuwIjwm-p5)`4i#sDS&nn?(0HEBGjYzV(3
zt&Joa5-0~B;Reb<XN#-ts#_?u03bn)6%MfQm9>|EkQ6O9*nnC%+QzAhph~kSxtcm9
z4V<A|B9yzR5~Gs_(n1pUY7!Cc)lS;8K)DdGB~hy=K~=RAkCBv05tK6kOSxL3IBP_!
z5=1*1a8(379X>RlZ!oywsOCY2F>~3lKA+RVYZ3J^3HMj<s>iuPa@=5Mxwz8^FHM3U
z?w&r8xYZK;J+WlILE=4neMT}{;CaQ(9re3h+&9nw#L!1O2|lXyqO=HJhT!r}!y3#y
zaa-UGkJBFgE}`STD&|ZkkBKu1R;ARcl{x862JUn?a;;>w@}}$;)S(@G9}!uyNCqnj
z8X0);gA%0Ptby-5%rMU~TAV?_$w5@}fsy6wbuygMxJ~A{a7blTUbY+cmIUVr!5xrZ
z`AX|B!Gp^d(P(6Rdj+_S5qKNvB5cwLN1ypDd=pAPZcOL|t&J~%m(4kh3*IaR4X1~f
zK0O?=2yl-GPgVJjqOtJPM07e?W3an4lAdvBBLSTOZYlZY9@&&HI2(vf$C%+Qh}CJ~
z3<lm8nE=z|N_m2MsdAVpdzHmASu)htleY^K1y*PllyeNL<uszhA6y&sm<U%G2$&q2
z3KN`#ilW=8_ZZkh5wmTG9?Y8M;191^1-;8G`PrSE3@?$KjXCOtOBuoi&CB6;6AoyM
zF0D;~i%y{5Vq@L*e4Syaf%^62Oq`A*iHagglh9hJPfH;sm^h2k&+z$h|6}1?_MqM+
z>KV|29UdgvfX)_RwPr6T6OF;3a~88U9^SXS^)@%B0~v62LVuoz#X-J9PGMmHEzn}&
zB$rF@>9imu(c)+9c2;tyNJ1BstsHL*X)GR%)v9TNyQ^dhI2X;e<!n9~$tCoWNSRY>
zHrpLK*~T$iXGyF9zOy(pyhp(?m0!bXbUHYb;*A*Ygz%hq`!wajL?A9pvNmZ85S`h_
zu<&`wWvrEY(F}*K0p6su0Y3(Px&AD(UXq<!FFazw$CFbuSy+vk7!0luCwd(Y$w-LK
zWVE2#t2DB%SavYLB_kLznxMqNSCl5I$q$Ai8D4{!iYS-FTY=IL=O_pSyfykuB+xKG
z)QE-xJBO8vgjO5VIQ>?W;O)l>o-{FNt+U`J$ZV)KF5pUa<r))k6|U3>8C_$v9$s5@
z(fUEIpycRA%M>)(x6vNq!ALWS@hbm^w)X&xqq^3|_fFm3W_M?MFKVl{t5vglwJf<}
zTaqQYgAE4Us5Uk>B|yLl5Wt}u2oDIIglc#R5a1<&goN-*qnbcSCxs;79sb{))ylGs
z3wi(N^{!^ilzZp&bMANk%7?sOtKQ+Tb2dT0$sZNmf}>t%{@5y_xXuXFt%tIlD=J$<
zTBpO{6itq{pwaCr)%j(6w%p2kJ=L5IA(^PKT^AKAYfu>yX6FJ;3=#8u+F<96oHqZy
zeQCIp3*-7Y%yUE+Vhjk^3d9L)O#{S*`&x#t23{Kn9||mGU=6}2uVb|b;$;z*KflE4
z^jjEzsn(Ex)M!-37_;8Wc>%V><UhmhX8AY|me2_TYi6^oPF(EgiPNx^=gk0*(uy8V
z0&bH5kgkdq(60=Z4c3@_Ue0Q(&`JKF*I>6fGuCjJscT>iCcDSuN?7=$IcjAM5~}q~
zxQ9+lIS|^Us8L(SnMWKYT7bH7)xevjuyG-e!y&gbU~cOKM<l%^!o-ch$z!y7R;RO=
zhX8^rn*c3G^hPaUwhSzAV12VZu{4KV5#F@`Y_n4^2^O|n^ac|gbFIO5iqG0%O?9$*
zU^7Vo4;Dp15M0oI(WJE+H-^>nS|_V7RfS=oiK5quHUN|f4p!v#_Oup1!FOK5J1umq
zc3`rawPu~9M?wMw?*qnmoWkC+BrI_yEGVwgLJZm<aNu~%5}>>gSa)+CE2?n`Q_mPB
z7r4q9Tmpz)t1So|J;`K^N`P|XnKWRlOgagub&_NZ8(cF=bh4EVnmA7szBDg|c_S1-
zj#(jcZUbOdNi8G;FS<p>ZF0IxJz)n6q$}BIvl|5mb(;mJz|_PT!B`*C%X*ZlNt|BR
z>49WttFVPbqAvo7Q+K5;r5FBY0n?%$E~M}>Yc#*)G#Jc!13_Aye;dH1vho8C;K719
zXhiLZKzt5P2pAm}$rxvlu3)$XnulL!BcfMy%f=QIY5K#)m<O_o0U%k5+`;g%w7^2u
zVA8Z&>vIi)fs=vYYcbnO?Ix{HYfKwM4Nwn00diF9aIvf|n(uKt`bzA2bIx2*s!x}@
z*m}X8j+dC+g3jyJF*~(3i$~im2F-%0Nx)qGdq)ZS2m-9n;UJRMqUCNg8hF8Yxyfrb
zlt}>QGP+nnpU~<oz;ng@(YqbMi{<TP7AS!*7EIL|1Uuj5fcW|bXAq2Z-T~!n<aJ@2
z*=-RVpk=2vEg5uXB$b$OApb*N3yi>1c}_Xk$nhCd767=wnCAF3+E3mF*dP*K>?rYy
zVbQvh6*(K@v=FONkKyM9<EKq7yH+ooj1F=+?*I%QVM;%sP|ZrGR_6)W$?rLvsEr%M
zu(r%fv?Uar&?M?@77hs0AVs@fxxwLOWsJgM)M^Q9u^aUcR?2`-EPpfUL%fxE$eE%?
zh#8<M9h{xN-Xyy1ufuf6e=L|%oK~{hL@r_p3cE@q7z?)Wr%$>>(1>WZ>UF$qa1q9D
zu+$L|pu84<K|38`lv|54SREG&gH?<P@|az3fTjZ290yG%n1MqG?ol-MsA$zozBEhT
zmMvUR`Bz=Gw2Vkjvxha(`ePeV5Y2%TJXV8VjFOB==Iy}7L|C9CD>hpE9&auGCzqG|
z^nDg<qlnDs?LH3Jnn*-Pc`K(ECCq{mW9D2|QxiMO1g?W%FzP)9wh1WMl?JO-a+cyg
zIr$nVWAlj)EL*TjLBKeg1PN8&EHMHxlXpn0(Hcwfu#@d34>K6FSpa9pF|~Gcw7G_1
zT+V>xnVUif7@JM(aHP0E#)O8SQW+s8(d@~bIGCzP3O=omfDw2cr;}p=avbJGhXVq^
zJkJ!1)&>k+t}q~?ZT>I^^FeEHnZ2bJgI<zrT^0I--(g3e(U{f}l*}fpg#$=0r=x&(
zV!BbEGV+j_9-%a6iWuFd0MW~wU=IWR(5eq`?m$cr>_f&#<SM}mXlFa@GmG9Um}NUg
z46t&r8Z;hjiwa&N;eqAn(VE?QqZCdOE@-n^yeSs<&JRRw4t<>LYzmy=3!tAO&pLnz
z>R?S;fN9G*lSMGX*b~i|cr6d35f&Pz5M7KNKt~k!p9UyHvKJ_dP+Ke`pa50lp?0O#
zU^H>E!3!B9I4+g-Mu(`}Wf8;BUViaOKPE9r`gk*6WrTpXc=Ujt<jj1;*A)mu)Y<%C
zOAtE)OP6qfwD>ft1$H=do1ixW-+G4CXLd;}E?EzZPk{hR5`ffN+b7KwCUUJ{fY?Go
ztX|6kQ|J!U`Th#ARt%V}RmA+N?mdP=O}mi~7X4ZXD;_Lh#l1JOT|8@Q;{jc67&UrL
zF0IJ=xmMt50wSCIOM?BT&HqZ$GXU?5utvjt6Q^u<3~8age2EIUSNgbPHt;i@251bE
z+rycBQAY3zE{hSSDyG5EW#Aox(C^blb+&HXT6bfjUuzf5CcVz+Y<B>>l(hwYKDLyt
zFtO;pYOKfrx^&DSm~5PA^TGs@v-b7$wpj#&zRU=`b6`wsNx9BoH;6uc0Erp1i<JQ4
zs)yK)`pgm}p&3KOE!OeIpoFPr%^V~SY;0JR9B7RNQX}BBf#hwsLsJ?s04!JoaAZi7
z02dh`)-WL!q=1-G*w6qu2l6>4LJJ3kH^_P?e#seu60YTSdcDQyh|&<D&g?dLfxPXu
z0qv8Qb<v=f6?JeAtX2yky}c0I@F1)J9@QBTDlv%;m<0wljWr%QpEjTc@+;?$LyYQ;
zygi<1sDx$^svW?ruQ2F*qCTq!I=|P#!+arrgTt={t}X$Rr7Mii0PT|2N}y;>>?Iz6
zaf&c0xX@lZ3FxfK?^(tMGl#LTVJ5(u%@$Guuvb7sq6k`4&g24ilM9sKa+~dv3y9}h
znJj?`$%lcVJ_A6$oD}4pT38G=mIM5&5+XSZ*4Gd-0LbB~C1fD#VwsmgkPNjB#%8iA
zYpelV+!l7%*hMa0BADEb>?QDIfRo;5@POT#I02?LnjH85{rTy=3~TYb7nhd@y{xB{
zHwkrm?j8vA8iQ!$6b1P1+|_#4sgp$4THYA(Yk`5oGG#i*UY`>%|0c|85L3<R^Xq^k
z%R}$d+<`{v)oS=OP-LD(JUn76I<-@O)o=y;;({ZrzKUu}kvhq6vf+XkoY`U+0e!7i
z#~W_*qytW??-9f-_I#j+#*bB>cQOV5?^g{MQ14uI>*-%7T1_AtP@j^qTt__`y$rb9
zDpa!?3YY6>UK7c+6#mq>GIG6E^Dj-LE-^O#kRvj5bH!X!nJ(n94*B%KfIhZhU4Kn&
zuCZln)mZM4Ck6*c>LT-uO<L06ukcBwIpQp>S~c3D{B&=dHPrz7kJEW<4wKnmPe|G>
zSj(3u(BxN&u?}0f`oG#OdPAop*eDRKF0R#=gU~EMBNiEl<gF8#@`YA-se*QfDGa!M
zUylcEAWprk8jGy_=2PnHn(eL<PU&TzAU>(N;XG@6_?yZ3)-H4caB3T*P1p8ivkfH`
zi+uH8n>qKfnKKvlG@mSboO(vLD8psDi6v5T<|!GaJdp6$heBmOr_<NSaNboqTjyCi
z>r&Zfjdi-J<qqJ<%vkuA&~c}5I+=Z^t})r<4khhIZ%RMll*Z7=m}s>ry{~LTrIXW*
zeoL^d;CmdIGT%jBW5(>Tyl5xsvbo*eXpF$m9o7wIk#7P<i*h~p9{)S6$62Hq)l6tk
zp_!B-5g>zrhZ@$*$r8PP^odv@U3{sMi$rfD2%r#L!P?MbL>Z9|HKtT}#e%t<lmZ?O
zeIf)DMZ6bO)JnMbo*o%mwR7jHp^>M*x$MLiyGzf6LRb{%taQ68ogU8&miK!Zz02Nm
z;xc7-JY30fmEpLLG!UP~HQ~CEzk~mi)r$WnLH~Ebsa(G$*VB{R^345@{;5|hB<<@x
zJo&OE8nBuo4cvL_)}6;SL`>E|)Pi<d&h_@BpzZzBqxbW63zpDHuAoI|uC8ttEJ5fU
zHej*2InJ&8^t$WLOeB&BEOd#`ZJ0M1x%&IWyZC<tGT=q>WAaBxUkejt(#(m>h0JBl
zF6QgZO~ClSpZN~+0`n^K7HeVQ-C}Mj#nVSt%_x8s1T_*RsO5`lAg>Ua0uRt2U!kZ`
z<y0E{!v>9!;jXCML|fXanMWLi2Cir@J%uR08jw<XxG??LEmxPLd_{Brc!WqHK0mpK
zy01fx^Ww{THkOlA)=Z`fVK@q2<aE?XF^T}Cexw$nB`1T82wx_hS%hWj6#%&(;V=ZQ
zDYvWFfM3Px5d|wy6VMxIfS303q8Cda>JD@SYOHvY#_HfPBXBsG3#h?&G!#n35H7Kq
z&|Dls&zK~d`A`Rif#Ist2#T{jo+@cdkSPfkKP`+~M#7B>Cv^&wb&fWI1QM>gcph~K
z8RUv+`v4lsqmfk^!VdcYeXA~s5;>eJ6D1&GdfHqni_zi=FjX{qI63JEjjF+6`X#+L
z2mvCIHF=rzcQNdMOGBtpjg&ej0saA^MRNpns8PfYvF4e^`U_`(2Bkw*MJ-4Ja}#rB
zacwx9lO{yybmru2J)KC9+2na~K|q<B3V+jyQv3M=LJs>A8i6l#FQ9MHR|#1hN~0(z
z!B5fLi;heU?a~|qPKL`ts8bEVt2BU3Q4M4x><bE*qHp!a;?k)cm^?iV@nZ6`ledCi
zc@86_Bf>9aT*rZjIxh7Wh(n8aaU}-7GpKcFwdF=DbFz;EmNvp59MkMEXbrP$W=U)n
z4JLD{!er5sM#v}l*<M>19Z_^vBV?@w=+nA4ot2i^X1xPw^>(=Lc5`1ZFEwPX{w`fp
zshe?x5$1vC;6pbehOa8OSIq-%cC4N$msuNZ2oCNuqECXyj1ohe)8Ocn-F~ep?)3pr
zeyPLhHcFh+12B(t7k@?2W_&6z!(t8FW2{>gXTW)8-I+H1jSUq(ONdSRx&bAwH93Q5
zBU0v&nbrmi4B-k_Tt@;{*$yOko4Cm8MBJbPJ%5sLfQ$))b2u`gtKd6I1*_NRjnB_4
z)q33WnmAGZgw<4~ZxC-FS$e*iH^(n;^2tQ^dK<9a5kZvAVfgQW+~R!}-sF&^B(cX}
zSevYbpFgKp%Sc*JmBmUzg57M%Z<<5cDuXBO=160;D08}G4YSTKzzE^s0cW&v!7Au&
ze!z{p#NcUYo}**6Gt5DY)|g9bMbYIu&&fN{2xy5vr&WT+Y)>L*4|OH|UZK`@o>OuQ
z)`+=_7)G6Z4ws5x2CTdYYY7RaFdLRdyUCi8l4z{pCKmKOGFY^({13EReVKl6+!Bx~
ztzlhQSCMoYBWP_DF*(`!E>4*vkk_gwbey4V4y>_9&A92TBmZpFjFse}awpTFb6ITb
zP;A_6X5sdlo%yONt10Z|#$v&Ee2e+hTRZ{+rXE4ZxX44{ju{i73P9!~>=Mg~PQjQ&
z2M9DpV1z8%P-(M#*$MuvHDy@h$?=jtE!z@RoyOJm@L73--6R<hhUkT<XA`u{ovEC;
zwbG?E*hHdrM~BcZsZMW7I{itr?DAlMX`2K)UT5V@f*1Cu$zv$Dz}e6`_eU1qQ?p!<
zD-aVlSY}iPbYHr_&qy}7qO3*qpa-<WB*2SDIXBu67<p5=%oIUTG7_j{bSx`K5*h+<
z=$cT&ktL6`8S>xiN1)Z$Xt79e{jz3HWi+y&+l>y0=VwmaY;YwBT3YZV+b+1|D7)~i
zE`8G`bJ$ll9~~LYcHkDcc;n!N;lT?|n!BRw*5)(4b&ZuBA}@1NZ9KZ3V?o7pAE~~W
z&6y2)gB%Q7BM5R?T_!eccJ9%2^0LEe;;STmi8d)(nk1d6V%%;wtVzW~!QP7-&vB=N
z?3X(S`nb+I;`oKrOm-??VYFnKa=z91iSkl%i7XmLvtRE(R={m?$Po%wpSFaZuzpL>
z+)D2<hfD3~%XN*@u@mtJah6GF*NMrfJ)Ab^1RH;Wy~$>B`IUdf^im0992NXJBUmuV
zdlHhx&lx=SqysSjU(=?w{TwREbjA_EV$mDtc47UYiBV<>=Jm`kt>Ma`&Q&HF;-=fB
zm<jueK9|`Phl7Cb23oyN@7D?N&=`G0wi{a+Unnb>13D*CAxN(<VJqukWcX!s(YuS4
zIiG<E@-`$hJo{xkW8}z%c6<KAK#j?rBWRQ)*^GLL>GD;|=F&<%t5ll}R=aPh87)36
zW}%)r#mSpKeb5|rN?~@j1wl7NRkQVImc))Ky6UA1&WyC`Z04|DN|=a^M{^H!p$gcm
z%>rZbX8&NlWZ2gjsMT+a)JFAueOs(;*mBNUmXMT`D@_)^*OR<HkTY0BtOn9316qyH
zp`s)XYJRWzv*vHa32c&ir~n!z6Ka>Eb>wt%7THdA0u6r`xr$s%t|vE>+X$`BfoLzN
zN#yO2PIEv*I-y#i-e7#dn1M1#p^Sv)>s7Nr^&P0P!uow=JVg{LqaM~F(pB9F2f}%3
zDw?Wbltw^t;3&|ts=86FhJyYRlk`*M#Zgj$D}X+t)=ME5D#UPh?2!~xc&KIo)IT*a
z=-K3YHFu4}qJ{&P>vBTv;UZ~5lpeEg^80!eA7tur1bV@$#Y^jjEa+ZHiv+0VMs_`g
zq%dj@useRGYC~5&27vM%XlzyK#ZtIF`gJObi^T>efmSNuOtBQQrMMhCDO^IPz806_
zqGzB_^Z?4K8`uq(3V4HhY|u_RDI5*Iz|OSe6E^GWX~6=_6dCo>_=pw_qX+^BDJ;&#
z*CD^D)i~Pt4jW@LG*^0KWj5BEaaz&41)*(2iN`40oGj$17|@}?hTUC~^oLul4zqx6
zI5vk;Wi+<B&>V|MVa90?%5^^0Ae$`?txgQOta{`Gk%&UuIGc79aVrtA3xxY6;F_4V
z_LO^-(~?8a3PgOPjKyr0tq8^^%LRU=uOjN0$MDE`GPZWcSZ21;jxAb$ouf*wwCF5|
z;RIM2EiW95)~YufeSDR2x!?bql|>u4R=r&^`Uz*VBFM>kIft9mxlG1@)2xq}i86|A
zem}7VSUtMyaa<5FCp6Ar^kL3iW)n>uQlu`#8xYX9cy&61rQW7<AyHt_o~L8c@k}c+
z3tXZF83Fw~BWqm2^Hv?76od&*bU2~VW@;TsR+*7+;^*tM?M#cw<g_avT6x26i)d&>
zd~L|6|B;ngl<S;MewNE%DCOIPblmD99$qXp7{JU<gHAR_&2iqCvODCtoHJOiB_?ZA
z&WvS%6$Zc8X0_{2a<Iyf-7mV_%-M+<Zoz}*F*@U@=&ZCw&>e(#mjZoNYtWUMp@z_X
ztwA<v{Z73UbC@`{Ln0x&wj90w^d?dZM_9|FK@ej$S!_D*5b?P!CLN|XY<9=BQ9lvl
z$Y<!#7>zN9<W%`^RxH=MwEAQmU2Yf=DhUZBr2a(oS`z{%=08FsKoi%ZuR?@LC%N4Y
z2VztRz{y6hgeEPHOA$fR{m2sKvZY9kN?h2-82m1u*u^&@*opX|iLqF<l1XM`7S<$2
z6IvM&+AKQuF)rSdVIkQNuSRxUd%n@l+FX^K@d+bqMP5yJB5Tmu5mNK8rY@{-VhmY9
zG6jX(Sc&r>^NaRLg4l-F{d<wpiCR1s6V{Z@QAUM@LM{4XKc@Mi=Iz2tI1#}cF~UGp
z6qpt4ta?F=`l>dXFSsrR7N@Ubj)qxkP;5;%)RMt^7nq;Q7udm&3V0N}v%)Ktka*DV
zAgA!Z!1l5#k#I!R85iOu@E)doKJ4MdH>wW=SwrO%#8DXMhxVX;1CB#$Fz7Yl>7s|G
zz8ALfUp=%-SZFqRb@u$Mn%pnY`$%v(JgHb%^61PKi`hjCMsvF98xPkTV#z>hk5{tk
zEuJPz%8NvxHHmbS&tyt4?uPHxT_&|eWBHex&T4BLtYDHUOYBRrki%eLj5YeO$KdeA
zwdFPQh;K+RM0|dW?6kKEJxkMJgSmR(kJ3sQvhF@@nZ-k*NZ9V!cKTV$uth#W4sHs{
zmF`(ue^M(rX0vBsYxD($Zlr{*)n=2)9R6)<E268)J)25M*^M1!!-k7ST{Y=aL#bgF
zNzanUWNe|5A!n8bB@c}GuFlz|+2w1ISui>sXgCS+W3~yfb&bqibhL@JKhk#lSMhV-
zfWtY{8QjGD44t<S3()ialTP-vR#c$z4tgaSzvI96d`4f|SXpH^RmLq+gVrY+bNAgf
z>?!H*P8ps)>FfX03g>Ov`+en6UC8H?(=wM`&}A?p-){(^@gs0N<|}_fe)MMGT+rUj
zRhk^?Z`)A&-w%BWJhrgLroOV%wx{D@Aj(`&Xt=S&p@~H`b$ra3qfm(Iiz@~2B6Qf&
zD>vhzCm%yeuOJ_<QhJmZ@#sO9nnpaHQoc3b**Q+1`9Br6nDdmEe)TKmCHB!%=RbPu
z!Y6K>^}wk<rg!>r=yBEErw+%A6b@57$hb0sLy(4Ft$K0cZN#BGuGf=(<qu_Ny@-_!
zhm5}zYnVFK+T*#J6OKH77By-hYmhyyDy1yOANI-rW-flU$`h`y4|`Ts&sei&Ms@zo
zgWsc*^cSBNa(8#fqD39u8^<<m7~42)TlvLNrU%v7ls+y4eNYVUI?aG)HdbV>R#%3c
zjk@fwX|QS}L1`cbF`&we0zH8HlXV4}ft-ODp<;nXJkU9h%AHK@Bt_9eB{>4~fIf0l
zw3EOADK*i<iY_jL1#=)Nm6}qB2dGEL;VW1$^r+;p8*un75ijd19}k@M$P=&r^vQ3X
z<y@6+t*Mx?ut<^fuYH|A*XoSA?1pcgi-dzI-LSDpq)zkG0vF(;Wzks5?ou95$&oRf
zYw#<teeZeYXF=8%?_5om{qTomd47*drvG!A!Duv@J?R@e%~iQNSmTC+@8Y3%wWPfH
z^4rIkt(ds;su}5QZKdPE=P0940{`xPbD!+1ik6i(*uBcfjU9Y8+s@1`lKt?oacdwD
z@!0H6|HxpG$T#hKPT5a1-<{JusC($;SL%v1U$wL@7xifyzMeEBQkm`?(>;wArqcyo
zhkv+iXgM-h97`$yC=>$!e=Q33KN<V|HP`(9KNka6KKbOKV=M4I#Sfh(<)%x#FT(N1
zJ<j81^Wz-yu~}RlI@VYmd|&G{ec<Y0pd1}}{DmTG)gMY72dhm=KU88)awvb?v*KEN
za(TU0TUYVNL-^%|gWoe_1u4iq-DtD9n(CE*AMZ4svFVKJSrcC0(%Iq>Xul{Ex0Z~A
zL*=fHTR(?pLRg(u35j^bIU^!~gW&a<5RRm)CW{*3xMxCnz7C6IobJ%`%1z22LayhZ
zuO%|Gvnc$Jcesy_+_L1hSi{EZTe2maHZHkE**z)n>7Yc=!W`6BwqPAm0@(P?poIk*
zECV7A9{x%}|0m*gSrtf+6SE1b_&5l23W}WL={v}BVpUOPCigg^B%lgHwf9iu^${^n
z83hLAujC}<<Bt_`(kaT`pTGK(Un);1Zvn7HdONRdxZ~+3Z~wuwJDE=9y^lWl{hyTI
zOxX-ijCE6G-!-0pf4sAMYy#E;Q}M%(KmK9=<Ig_(IG4X_k)nKc%3N5VUv%|<jkdLo
z{?{4JsZ{eBCpO%=r|E>n3w`;mWZk}8-9F`-NsHtcg=39%bxx>f$iM#b%d_skANB&x
zRqYhfFHvK|isuT<SI+?osE30CYk=5X(`83-HefQ-v}4g=qP{frm|Eywn3E|Z>E~p0
z*Y4fB$mq`xH<KP((%m}(5P~-bFS;oI_mST2B^O;Z_=etA&6G|J900XNQ>*81<X_6)
zvsp~G_HPQcwVo;}HO%5Kx<^NQdn?TLcLpyDZR;H!?LI$r+2A{Nb4C8gg%Q*79<UEX
zDo*y1DPEu?k7du(ZNdZhd}@3}m3#Q;zUvGrzbDS@ca<APyE?~l1C}tEsc{`k=9BBI
zs&AXPdH9U#t|eogU1Q_<pH9DT2gX6={j~c=seJk!J1%MeMaFe3N&f|gcqB9K0EwzJ
zS{!QzBON-jWUsBK!=O(!LZcdJlq}T>e*j@ZeB(2${6D6>dknq)^T#ZvD>gSYy>Zp0
zu@!;S&V2mwGfxYwa5Vd~;#<lyWj#w~wsxI#uz)|*Ksx%}-^iR{`06F^Sof|!=bZI>
ztrwgeyR6(Nzj;Txb541dx#9?d{-C*%VdIt`O`@|?_guvkQn~i?`1gqP{nE(R?PHCd
z%f{OBS50j)XCFU-f7I4CKb@YhzUCjFByR2?9-RUI<;WaL^OR~<j4Eaka-9k+`h@L`
z*H)NlC}Eru)5pQGKUuzDJmBZLl8*XZFIp7z)(^R}%^8=)5nr^xDOV?|W^u<oKxX5}
zhUN9WRpLZlYghO1jElbBFfePD%UZXrN3QJ4&nvPsVk8ITl0#EVaVMwSZXo9*b<jjC
z453iW1q#QIDW$g%r2ACWcHlN1PQHIyd+Rs$?)}ECYx#+REA2hsS~|2?@0#7e{LaPZ
zs|Thu&?`qA+PtqV93EcyHD&1D>o1m~7gp8{k7g>rA{(!`{@#L?u@nb$u#Ba>8tD4w
zBUqvodz1o-g6^<(?eNP!T&CWmyi79rf6-T}9G`vs=!}G+J+W-rvi#3qJ{bz{;A^At
z0d#UW;<Zha`v>U&3VwPVr1S)o_!2b)@Zm^r@5o43&p6Y*{|a`~v96eD?;Kx3O@X%F
zv60@cvBmjWC?Prc+UdN;j&kkAc|Fc+eN=gtwB~<DUzx=IUF^nVT_d@F?b@~Zy@y>_
z86-4C-Z;YjW>w!>jr0NZUoDzar?wFMD||$0;yC8_qlw<_A;N!yEElXMcVGUut2(zv
ziEsy5Qj;zt&+h*wyYQHUc&m5GCCGWFji;c<FTJ>PDScOIK>bnvcNDy>;9D$5yugmN
z<2As<>p~>y1b7z|7mt~WCm}-s7aoa}N&mgTnaFBT#x2I2X#OBqFHNH=b@B2+AJCyM
zU&<&3<(4U<XBPp&<OTlutIpZ9p&=GtX49{1YFM)Nrag~MMV!*)+saE)-MjkM-!AR#
zoLJG`y)^&+K2LVv&<YrR6W#4A8JSK9YrLQjM>Z8jy7Ed%&t2(@Hm%?DR>zKX>Eldi
z+p2kcub8`F%Bs4V`Os7MuC+y}=~*(-*}iOyw7%=9`ar4a8lQlrx;+0Tou`9oliDLk
zrGd%m!IC(rW8`HblOnBd>XYN7fnOCuN|Ty4|I35kGID+=v+Y<k!2I^G7}8|iAWvvZ
zx<kfBWyaCGq-l3|y3EkQYa;(~;Lw?m@b%1Z?8h9-p~1rZ50yp2d~#3VuyIiN(Q#xx
zB}jGgc%p7iRXhcaL$_lE^{U=D8ZA5yPF0>9cyFfi(z`R?WzO7Kk`9MzEHyKSs?1fv
zSY>iU)0byg8Eb;^u+w5`UVHJe#z^)IzB`EH{U*O*Bs<rZt+Ons8+jpTUYLspgQp!f
zPI|v)A7z|JxL@FIXe5OE)x_z64RAS4G#t;MKPLiAmJW6_y29~f#O(?v;$eA4+pL~}
zV~zN*5b*wIU<S-27Q5uITS+gmNp`x?M<S`Zx@ZOF;NVzSNRtHy1(jJxkjh2ho{qX;
zPZcbw4DPSmq;DD&bfJ+Zofp6<6lMdG?>N-qb6L3m4!`eN^2GAt5ve?ts_4%ybdd7a
z>RJ0gSlZRSWNCZbO0w*G!xLj;Ms4XOJ%I5)*4&Wm$M=lxDNCQJoI1Sul=8Cqh$Yr%
z2m1Q@NTzFSNq75-mHF0r=>dB*W$lf)lg0s4d3SwOvO5pqYbvuwk32)i<wO0iY33M?
z6*=)gA)h10(ekawBBRflqXkEqqr;^5=g4&jlI4_kzBmCLRo0W2o*y1xvcxEseW}~+
zaUY9pjx6-|Z<?E)X^W*Spq3KDOjB7;ebf$WIh3cUT$yn+ue%s0p)53A6OdSOnqcjS
zu}KwpJPh=C0_Fbo1(mm+x#YFC3u%^Pjh+1Ckc?7(Z$Sf|a*FC!VyK76k0AO?)*oG4
z93Cj4rH9l#saJ<tOqU$bIG?UleupLa&nmZ%cff#d@0=hHoXpj<tX|d8D6D06{^Ipe
zJXI6%9&?~uM)!=~I(mk)V{EjmePS&C?#7ADn@>FXlv7d_ZT-WDm>f3F#Nocz^hk;-
zCus<@5CQ$qhxja&h0ffwh=l$z`|Pt>#0DSykA}Eg9pc8Co5xQ-WAvu{cMcgLjfWOv
zC$w)~3NgNhqk7cP`3D)Kc<(ys11Jbs0V<fq@yY$C=Da)f-dIo1*hE*?ME<>fv)^+z
zjCa%MT-P$DJeYXy@$Wp<KeYecGtWEYSa+0pdG@{`rMhRylAf;daninT_8V5EzkBIu
zZ}-?}eord-;Dh}WXEZk)k`tigE>|gd){&(bwRjF1=wa{Gaf6-N!VDaz?ep-=cl!{|
zE%03ajdy3hH(Y$jRH%X7emLDtLo+h9Ekol=mmYHtel)aiK&hJKVbZg2=<TU@`MVL;
zo%OQv!<lVuGnawB54Ouwn1iE6Q^2saYFiDS9TM6_X&C&MLL35K%yAC>sb%e5W7Rg@
zuRL{#?|!hnqjU6Y7xsOSNH8VQ@an#ajla05f7aG>wtaZ4QIlV_uUOjEQg5-pBh~E+
z?dVv(tn<8*OZ(rA=-B@JE9vl(c=ZGQ%Nqf@esDghc<;M_zjZ|WhZPeC-Fw<c_aIs*
z5WNaQ!cN;h4r%s5z4E)<6L6JQtZeU|$X}`auAa!3PkCkOc<kYq_U;X)U;g+Hwa(i1
z>dGFeVac+IW6cM%cjT6(%I%#K<6Ujb$Dg`o<QvNEMUQNCdHj(F+*LnPzVE5&>9I7x
zi#eDMS~YWzX6pcMM3vlX%qf+FmrkqefrV3a*E0A4Lj6TOHuX88Q$_#x*!JL0TH05v
zXlfu0x&MBm?-@ecx&kN8ER7a}riqH#cjZq#*q^()-~b<MZYo#x4s^7xwA|nK6Z`Os
zp_M0$6~d*<7OnREKgKlO-OG<mdcKG8N(d{yYK}}XswSvCpb93X;&HMC#Q*P!g@gRx
zqkNcs{`o8tVI^|qx1W3I!Tulo;}6FgAlW^7%Q*4^6?;aJ0o#+m#$Ws3gR^L#7X#$|
zBII+z@KHBtzODJECXbFaC{smUsfWM|R4sgJwNt1+6jBwppsDFir^sJen=rLCS@Tec
z+7#~hq*|vHP->AC9C#XLg?vCdT&>uG!9$U~AxWr%Kzmh99z99J^HjiKnw$;`NvhPM
zzQGoDqBT}(@K)WXu2<n0lYR^6Pp+py6cs6&9%0%R_QL`ooDw+ba$!fh1(5~v%@H=4
zl5!%OgzjQ-bc`KKMO2xOkP9GU>(!P<%=&dthKSoH_%bt0#AD-4TeolDYT|7kAYNvC
zg3V1rPp(^E44>RnSLzOiVl7LszRc~b3VIv-;Y`-fYMtJiaJV`wYum!Lv;Ae^!2Z7n
zLY2*aHa)AkpY!=j>V2UquU_!Rv(Y91aa2Y!l2+txbZvq?<FZ;p#N)G@+4;pd%=pNS
zJvwP-@9+S<hURotn6rC`x2&SP(nqf|lCGLTuY1<Qu5P2X=f;t7<-(=8hSk~Sr_E?;
zYC7%o&6|~X8gfgsS!VA$gZpMG|4lmbANIXB^Bpzh_tL)SpV>6Q^0IA#-&M!(vb{E$
zthEDHtIp+LV3T=vV$(Cv?<-Vrd>Sn6u(Xv`&a>LA<*Ax6uP$aep+zd`3#V(swg#)a
zC0Cg+1=A&4s#6tNX8u^SWkyL&No7!PU`e$v+v3r8=p&h=tv)GBjwT<9)Iz-IkNVk%
ziV3}E@4kJ_t6F>CVD?>l@^3p#=hKT>BWl;ui#y-wdX!%5dzo2%2Ft5!ZogZpC6R=z
zY;eTLgEp%&Cq|x?6Uv)G2lwZF1N-v(PkwCR?IHXDj~r|h#Z=p%?&$F<6?;n!@li@q
z<04Zwz=5KG<Io1J#cBZM?*s47R9=32=G)B1-funk(!DdE`{d8$>O$`SnEc;3mGW;N
zdUpUv+L!Mcc<{l2S8kll@MD-q(1Yzq^I49m2P2aVs*e6R#(Q+_M?T*F+sf4&zx1Vz
ztIt?{;f1S@HSVJ*z5UN#HnDc?MDo&04;r@*9e@kAAFTxVT>UTSG-$_!+<zsOVFAq|
z;);Z6C%c36{~_;>GV=Faq!M*gm9F=c2h_@*7<>BuH9x>AY4VMuSb|5c0{rfqFA=Nq
zmzUoBHVPcBTy-ON*^%u(beuh4@7quT83gWeHEJMR5VyWcvs-hA=9`)aHIHk)bMRd7
zw70WM?eJW9&1FRT5mKfQm<8FKOVEzc_!_T>`q4iW=pMaM@x#Ik3fY`7D(nH9NyU8O
z8@d-_X84SLg>UFS_^|L&hul^177+EI)6WTXvjaCpE!xS{s_m5^=MTRL%65-8I^W|3
z%#GLMUheVABuJeO)$#b5*W(}bdKmWrzT@Vms%3w*+gELiTAK$JwN^`#$6M|7NK$p{
zqJd^>)P{Cn)qc4;rQXmVkSf=EpRVzGY-G52M8<Z={q1eQzx=!O^-xMam5e%U%FB^%
zQfW3SKLAonw_dB<A;{!hfm4QE4;L<S;w^F)Cny)2Lu5>=SM~~|&WNstCgm$zH~)>S
zEH6<8$lv^){Le?rBj(Cx)4a0E$};j-fF9|Xe-c(P)A#dC&6Vaz`6yH3@gvgzXi2$p
z)8964Ri+4uIiF;(wBXM2b0^Q5zq>$M?Dh28@$Ykah~~;*UVmN;v3LUy<00^ks$22*
z@Y^+&+dDADhw;ok1N&yaho|zxw`RXL6VF3uc3Qpc)BuZ|vSr{6$o!$V2i}JcP%hm!
z@b;l{u^=BBAsa?CE02F{hnv2tv_P6xm5-lm8pH5Vt2~c251%hPi2EQ@_#bm>`OdnN
z1H+xY)lK_<bI^C}tj5$*U3J_w_(kUG_UUG^vZA`hWN=zWx@VBn4*sHH2{B^P(lj|!
zn8Qj)nJ+*aYP_geN_MO%QMvCh(s;5KrBm*@=an0jKSZTMHQDitQFh_jEfcqmomqKH
zCb{{{vD*%<ou;)D^=clg>qweIt+Sc31Nf;eWa}bPti?tHHYde9EVRHa{5{H0i%IyG
zn%c&ebvBM|-<p4DYLoeXa{r2ClD#=O>#9{d@wn<JH&?AgXWUbz74zHn|2vudc{2IP
zuE~Ft52#N#7rp|6{Cpq$!F8Goa0jVtN0A63VF++lVjp-%oj^5%Fc}l0_PCAK0y?qG
z3HEngik3^s6eELGH3Jj_<ol%Ch;`9m5Nd!^7XqN2waAyE<lGKBAKKu+4}lML@}u8V
zexkg3*U1|;oP3w^s`8WXJ$mw~MXP&CZp@o~nR?qtMtAHO9U*e<^Uq&4d)__Udsp?Y
zSTnPsvHv9HN{3lDQdLq?HKH>+aJ1j8=#`{Zz1vUfZ)}*khPmhMXZLQtN?yKg+la5i
z50s0MZQGX1S8d+=?Ayg^<)TUYty`}@nR%3w%0%XqZ1$53rJl|Cfs?Plb^p&}jx_sD
z<EQVJID%*=Vz83L&p0-0vxQmiXW`!l9VL~_-0OZ5ZrmSAJ7Q=xVzeIWlhb%I?KpCz
z49yYqR8XqWwV3|nO2T|z47qFj=;(I(JQhijHx7*)|E#d%c1lkN+tml+E=L~IAy$>@
zjZGWpbPMb__(nNOr0xH;r_=59d8{EaM~kj?7LL(gw5<=X3s|Od(EmYQz_e-kzo`!(
z9Xl5;+OcE7q6_~IY6O0@@PZ2$E!eqZl16$_Pcei}9A{$1#l^5oZ=RGpKvkf?=MWzh
zwVH|v3batL8zDt0yhlNTP?18>$FW`|OQQtT-N$Z|3pAXrlzInPDwFWL;sf!8!qM?l
zJ3;`*AU|S-xvGjhNUC15uDxkhX*?cn$^y#BuyEe0yY@c+;HtibPMcO|FPTvujmB3I
zyI4I_Z*mkRm1n!83@NWEKUHSgZ03Qe%M7%#p>Ca)x%Yqe{uig8Iiv@W*mYLr)qxKN
z-dWa-Bt>W2>im1}4Sg`Q6vaam9qr2r|MfU9SEZZ3PL|J~lRa-k)99MsxxGE}cHMAA
z&9cbEsOhtsp@og#PmQdtTG7xj=f*Fu?CcomJrUjPjs2C56Lx&Nx~V^AFN!m%<$O{~
zZcvshuQR>rHS2<jq3*hL=ZcZwkgK7y*KbP$4SUtldqYa1dwgko=kgU~{_lo9P-0;H
z?v7<E^EWAZoqbvFEJ&(Db!I_^(TeLON3y1<&OBmfY#NbE(;biL+sAYQrnEy*pDG`1
zU9x1$w&CIJ`F-1l$F^);JbFH{UATDB#TPAJeBtXb=f_98d&l$p#=CmPhI@J^$YafQ
zb<O!V8yjZS9ZO!2x0Y<#vSfH04!>>7lEvH4%Rjw%=LL%v@7zhQrq(s`61`m$$bKvt
z?adYbVcJlge!x#F=4EP;nW3w-1~v168MIQf2Av`{Yv`(^OEkMQS07n79O|`8YKaD1
z^@vL@ykemx<&cPrAh3<lS0oA8J^DKRR;Z<)<j{R-Ar6d!$^F5RQ~RpbhQ}e74~_wZ
z?<y@XzfRdIIY~xtQYu6(`L@AClpq}Bcgg;rs_}7liJ(^of#7_v&7=I-V^iLk3Yh0o
zWo4=S1D|&k@`L;h%xa~xcrfk32O$#O^;kEQ<)#PLmET%ccx}=t9=mJ40snMHBXb{u
z?fdU@Ii0QrGB8+~nZ>w!!fYllPW@i7tt9~0RQKtd`t<^{ncjajN1?x8D8Y(736=My
zh}TjdWHs(`q>iRconi)ck&{~qG2<+}nVyY2X#22WeB`iCrr&J+{mLuXT}Ntn?^ZTo
z>l#vxt<l}rDX-jc1Ie5<wUpsV>l=@rjPER}TkgS=Z$IVqo7SnXciu_=?hj5CwoR@F
zD_U5EYPO@K=FgqdzX#_tx)JL>?<o91<%+scgT|++Vo`(5s*Xuf!%4-br>a3s)zffw
z!J<O&SdD(DHEPgE>e@UNTx#;i(`WQJIAPE2mu;EXnj2nq`iYCXt8%TiOQHeWK*eBv
z&$ov+&Y5}2)*JGh=M0>@<JvneJ#S819e(#TeztKW=EtvQ)%Vud4vcIf)}o?57AZ6Q
zWp@sBWH+u_d}27!k!fpA04%4!{+i9hYg(Ib_#s}d-ErBSgB_WTtDeRWHco!uUmD+(
z|58z7)1JW7Wfhh2N4DsuN$}}4563Y#%9C`-%Sd0>SpK)zT8<LNV<y4Kn_c50-F>vi
z77JV2moCxhr(LU6<3;?d5a0d0*hL)zSS*uDMzC5!j<9G7gxFuEHepLyi+O?K-_N=J
zU;M(7{n1a9zbJoH#%uo0zFoC{2RpR?w~xO5dS3q;cRTXb`;_mHb~WEUM5FD8-!1mX
z%2RKU?-Svh_baz5AOAy{Pr8(+Pg(x~Y5s}wBj$TU@6OJDvWhI+H}q!yvsLQa-r`!F
zm?|%3LsKl)jA@n~xFgfo?4)c3m((Uqu6aI=bq~c=T}N5-JZ(A8&)>i5jytY;|K~+j
zdyM*}&t2(zl+``iH^_pAJ3Aj%?t26MoeHa~kF;Q<xW?^smqn|-?oKVRq_HNVOtTz)
zt+!&%RJkyj&q@`zzTSRd1|<~q(iU&XYax3yHJKvp(?XgG&TGM+1#%eFV)0FJ6*Zc~
zC8t*Xs>eYd3Tw@9!1|olb>2d~VcqwC^zp|(`u;kDe&KnSOV1S-N<AlCzDju_<7it@
z(RpR`fx;|55M6MAuDWR{mQYV7Nu^TuT~pP8#nnrjs&yBz^IQGO>o2~jyzXzEzx+WE
z<f9LMdWG^tXT^dx2T3p5L0;RwbLaNg$c{yqkC6DU4=kwqwestc%kQqbwQNTp>HPTN
z;@m&{vEO>y(9)@8)=gUyU!7WivUKP)tK!Yx@GMs6a?jq7eQe$O_3N0fs=F)tc9a$B
zYYxyX^>91Y&V`d+?t!^xtp_H!K&{hd>vUOCq|igx9Ug@&l_%6{dUY}WSSPJx?i^#z
zK4jtH7o$Ul?HMhWag6rBHdY>(whU2~nFq$*4?dlenMWTp3@o@Dcu?o(_}8->ZSY@c
zMavhQh2ve{LiP25`KU!L*|coT(Pw0mFORg^@Ss&AN1KMDt~7l1@h>*;qc1h2D@_XV
zodaX0_TBNy>BB6y&$Hzy=n(9gLM3G~RY!9y5Hbf;)lnwn=+@gS&wIVG(Zw;p`}rQX
z+x^96<|yXdrW4Bhb$Y8KEcaUz4y%a_R?cnlNs?T!hY!qEO3gITik&6L$2W(1KwrFm
z=O~kPu>W%06+B;X+P-)_&w=?GfDLfs@y*o#ueCi#nY91By620{+kaT=L;bG<^H-#|
zLCw75o5f?&+Y$2QN13prQ`w=J@-H??$Co!h*r%d)e&d1JP;(vAV$(;|&IOYbp40(B
zRE&ll9+~-^X!Nw2$ipq>Lp((+lPl_A_3!>as^yQ9viCsU>wh{HsGiC7{l_k6`&_`E
z1B>^+@L2MvfBt&P2v7}<c3-CEe|q$My8U!K_vMwTy3~h@6Fd#Z=*UU7LgHzMdKdP;
zcgWqLI`QBf0lhC2gJ;E&=}fIWo6K)aA4OrkD8P51_9iU^3N1`+brj?P0kP=9C#UKc
zj%VN(jg4JIpZQ-Gx5!`U8q*VMtpn-w!2E%ePaPaQHUDdd?<-3W45Xc|n&!b%>1W5h
z!Md^Y&mWui%wLWbspRFptj|x6G%v)g85mr%X3$_R>!9b-N7oGEy$122WuGk&_Vahc
zclna$I?XMbZ)hISd{^^=<|mq8YTncQMe_+-%ovCr$dM6J3c~}C(y9Te#;-9gD78S7
zR^;v?VPLLdF+8w0DQ#1G0ak+?LtOm;l=NiBNIG$_LFpq_pG3tSydE4igP1s?ACm!+
zf_H>4yXq0Cj!mJsj~*J;Avg$)wiK56Nrj+(4xvXZ&z1{TF80C6YohpN;dhAE=U@W^
zP8-)mbCJ|rqP-aD4+`jyG-v}{$l^VAp*bVYbLgj&@k|_|6+IIR(HpgK+<~{k{`NiF
zJJ0#jz4w0UoX+ig+Ml>G$|RX&^vWj&mkiDITiboUcu)OG??ax((?)V<Z=H9-CAWI5
zw`DvNvi!O`ln90TpE|8!7Eet6sNS2jGIQo`?AAuy{_1*X<%p%(Qt_c@(|Coo$$CPW
z+)x{+=aNRd^4{5-Klx<y+1s!9<u9+;{*mk}4To<~ZncIvlYTgzZgzUpizb>B;rqL?
zd+hF;zT9W_+UzyEZBe~zp&^v1s4%Cc%B1qkP%s&Gac;DK$&^IP=P!^uDl0qaQ@Ju)
zlF8z;1@oiD&&bS`H{7t2@iepUXzdOw{{7>?=0<Y*1+N9}TD^Y#>bnB3U7%b^PT&2H
z_{NP`K>6Xujq!i%?yrpo_ywY9bT&B?whl&anORx0f~#q2v^6{W%u*^6>A5%|wV2S|
zL<nVB$zRvPo2~AI4UM5}<3e@H&a+Ob&5Y({M&_x1Z8+_;4gcEr$V)FhqHs2^)2Um4
zre+q?D6okgkz|zUyBy87`Wbb8rz02T1e3>Zk|m2p=T3yb?sB;;QTBysX=$|W&BA~?
zHXQU$8NT2GvdPOeFtsBXXliOpt&jc8ivC2`YcAB>s<}t=ux793dCd<ruW8=Ud;t7a
zHUE7e3uT4hPe}{JEITJjkZw}aE6{5pw*)4_N0V77$|ztJun#_>Mmjpot8XaVP=25s
zVW%f?U=J%I4wRhL{ttx>7jLEXjt5;}Qg{St>sZPOY6YwMJ8?1<qC(iH{8#)05q^4Z
zK&vCFfu@TX17*TYj;EJh{0Oj!nVe|skmk#^qI^ZeIlGp}vzctYudF;9Z=W{;RBO|+
zP{iOYogr)=UcLL~zkGD#HLk$ArDNeHCu?+uPP7RId-npXqbz!sUi*}@^~_r@&#qYB
zAFEq=@-v%GTUZ&7&W**Z7M`~5zfU<)xmfvE$($0cUf&_uEQxS<>!M{}{>t;;yYh;g
zd~@gcEK6Ek7H(pEd_q~`8yfP7cDZ4der$MnjI1*Eb<TUdn&C`dz0DmOG8*)pEGXYZ
zyDm`@?bVBoMkDVQ$!(u(iL)O+B+a_Rv+P8YCGOMD{Yu<qmMZLayCZJ#1T26p^jZy0
zcZ^%Kb=Spz`{u*n`sP1+I~Q*{vBg#*xur5b;B<O*4!P0P8c95S!<Rn$+oj6)tb2dQ
zk6-a!B7Q_PdzM#3hlisT<KM{t^$Nm1>&*pSkw{I@BirqRXJ34Q?}gnr-S~Afd&&6L
zi0i81g^QSl^JmDxA1++DNO@qWI(^UEc9wOPIOZ7z+Mp7IRTAhoS^)43-DuRz|Lh{+
zTK@Z!Ie{+ZNEg9pyi{|S=5@^<h@es@6~4Irw5nRfHl(N8L6=exws7MkQ3}CJ@4rez
z_<5m+z$BG%XqriB5Cp^1EzkvEj|$Qihp?s?5jqry!|dW9pqB#LCZ$9AF-1@T7AB#(
zgbHjmJf_mGi<0N$$p}3+e(sW0f}__`N8jQn^cx(E?i-=+>QRP`3r`ie3YVLqr*_rT
z!f}dYoU6y)Xc1jk*qQdH<!8SmG_<u>D;qp+S8s2h@&oZVbz_4T&KUM&N0b%!S`1!a
z$#CzjeY;j9qb0seX0gHg8@Ar^%9rm%&no3QN3uHXsHo^wPV~`VD&N<a*T$rt3a;i&
z{_dFhoPf?;ThmhOnBzDt%g?A5gp!hsslMN0D4*$@AiL(&C?6<kr8erxv{#`i(@-r_
z8rBQtRl4A*4u9<O{GW}vE@QxD&KkoPIOaKOTWV|dhTyqLK{t_d%j;XRb516!)(GV@
zXL&2hJjQ&%GTvam><SkjX)|2JD&ODbG>8-dKOVAMnt6R|M@1H0$j;+;HGE{W&D^lP
zF>~rk_0OL%q<qKX{8K~K->W};b9H6h8DB4UT4aHkY?;c7F5NhEWw3nhxy{uJR{r-6
zcAIl`cVA<}7+Y<r_CNgkGno@s*{vfDpPo&Y?@<2w&@$c|i6(S8lS42XZ9zY;FZDLW
zfEIs~a#G2H`7_$*@^O+1MU$LG)SJTREBAWMc69qAExJTB;?k{PhtKH!X2a!YUvYl0
zG^$ImqL=iesSeld;zzaK*`iG<<%wR<jTmfL=8g7=r3~XOH;;hs5wrj7YEjQ;H1}zq
z)_h;{Bf?`joS&qSh(<*WwPp&WjP!pw`Za*&3WTYWpR+)tw6j9t;f!I0&a}SW>|{y7
zByD1S14ueX1vB`9O6EcjjXJf1iXdv#y{Gm;!U&aID(_HI!~?WGRaH>n6ci!=q&kam
zugi(LCzY8B1TIs<rNB3IjYI+`qcyXX1ym+bISSWp!7_U^aKW%Z@c7Xrf2hq#RIZ|X
z6+Tq20TpIZa83rO-Pi}!Kj@w;sX9ol1XA??_{t^f=jq-3^{1b4hWSRJoUd=_vGPWK
zmoI+GIr^}0V#wk2WQG>bD{Zby&&YV2gUzegZdrSEB#|*xwpan{+shfXe&6yZ&33=<
zG_Tm)66$cd9R3|{aiAXUa>d;0v1;Y@1?Yoj9Et>NOu${$(zZZ~>(B$U=8U!5zZD^^
z$-beCj8>BRQvFC<gD)*N>h2LOkyNSC=$cbqCFU=6S>2TkAJCD6l~?|h>#Lp3yu7)7
zG#0PXlZpYZvDxN~m)A0^dDdt$Hi5>X(Kz3*w4~KuUEz0J?hH5X+)>gvWB<zXp^{M0
zRq6Akm~RCPl>%Q;uKYV=^+pV3;x)lYNoGd6CYu>!Oo8aB#LOkm`t3!Re5G64<BrE`
z(&7TAwXt32DV0s4#XB@Gc<Re9TtMo=&GtlRaDlz7Nw54a>{vK(wQsN4qfM1wfW82w
zf>aVT2RwHD{IVQy*R^%k70Mr!lccuMZ+$az*_IqX)UM-JjVBiN4|+*D5Lnlo6J=en
zdTDus**h|Kyh`eo^t%R>f0uF0J*CccqC(rO6_+<Q#lPv&I!cMn68+igw)`nodj?BQ
zW{17f>O<2T-Wv|Gb#;8L^UT`q3EtP$;<WT~!U^7ai^yNPtNFo}MctLr&QPdIdBt05
zOnF6HL(rHJmG{faDm$v?ycrxo7Y2^{W57fGY`5?NpVi#1c}Mdh@aH*VA#M^w;dPd@
zl5R3cwT|Gdma5U_p3*HStWa_@WdOlgSJx5IuT?_>P6eYfXRJWwpiwcZDx`v!p{@<8
z&()~hM?b;=f&QLF^L5IP1wwbgo1=D>%AV7Td?*8|On|oS;CT8Lrw6td6pm`FQSPUO
zLQ_Y=A|R@6R1h%yw7^j6H5B5f^|{ofDFrNiw9RsWv1rE^j7Mck^%M#9CzSmur_otx
zCev9CW28__I6ith#l(!N_|Wkh{wQVz?hcx=&<5DT3s-)*Iuh#BnS>j1?o4YK?HnE9
zmS_!QGn+l0P%_AQdN!8FVuRtpQ2+c?*@)I+(T=TM(V@!@rc#v~?Xws@UJ(pPF{U)S
z(<qo4tEI(ccSBkEU|Cs1bDJn!81D>N-Jy<9ec!h7$0n{Ap6~NT+cKfm$`+T0C5}iv
zpqr|6ap%HNY5&Z)*&CC+0k+*A(29w3PG2!IcS6@ZrmH*UvUP3Ve$Kg1$~MqilDBL9
zVL{Gh5+`}HyX&&e%FCzhOoWDFjb$DFxVe0fKU~o|P?F7xRkZ=DzoK=YAs_^{p_OGs
z)OphR>lrpE=r2xNWOp<3^sL{vDf8C<+EM1Ms`=rf?v)kI{gTTl7^FpFjaXTt)#mEj
zL!2mgKDJy|{yo3*+==m}^U~>z(M0NM2b|wnz53jd`TuD4H+)#a&Tnj7icWN84!eFM
zx;Zx2cs48)Ef%ryxq-p|+OlQawg-FUQ#Xgb<rm#tULhqG1TyaOmgMceTzScbW~rf7
z@?_J|;DSglz6;I2EVI`Jm!#!7#$0M>?=Fe^=gx0wuzKpdW*O3k<TcJ3tUGJVB(|S-
zzOvNn;+k!|-&18n|C{O+9{+Q9T{z^I8<hu58R)rM<tLS;>8{d|KlptXQ=*FFnKulE
zk_uy#t<TLe$|X#9z@^V5H5xPcFe)g}fxF<{{|gOs3`B;u%aR$u_n1pY$T&fSmseFp
zlG^vsgR15eGQ}29P);dui)tViw&~B3bq-Lu$_oY7EwBZ?!J`~rJy;Z^3$nMWj0L4g
z?M2mAQwhJIRVOu_)8Pawsn#W~0O1$#Na29gL4oB+H6(aZg?A`?Gx-Zu9?-@T*dML`
zRQAIOaZQu_TsW(oi-EmycAN!&)D?y@%uSpL=b=uLhzrKSawr~F8I*1pBMn6_iH;P~
zN<C+eDoc76x^9Fv#lsdAJXE|Cxe`p8a)!{YiLz*IPEhP!R=0J&^0;SiQ`fAySMWK%
zzk^)u&9$AqZHKQ6Z6q&h_ZaIV5o3z0TxW7xB-5A8!WCchiz9xW=#I0Z@7?m%XS=@i
z`)%{wR@1z6sPngOGz!q!9RB9imW!+{R%xa*aYbpS#zD+FGkP<w>1ZO&?F;x4*X(bf
z#_7syU_0A6M&M6~)TFhX^5V#X(#)FCet*9?uyWgi#*AH%oGw;eILlDh)qn;j^&I-~
zX|0BIO{#MCq7W&y$#TkVH5%K8Vy0H*F2OT0nCLHYuKF<IMMH>s^qOY{q0OsYZIntH
zGS%tq0*?g3EA!8Am`oAos_i>=Y|sCGYh6iV`*w1UQSTB=SLdv9%utozm<XL;ZIc6r
z>R<4zm5lo~o={O+8Hw1Vfu4~c2RhJ|wEHr>O*>dwCC#aFKH)+~CcTBcUuwPeZih#2
zxXuvQ`&$gIq4z3ISoO7SYu;eXgEv)>ahD}o;q@eD%Ka?U=V)n6GmR<N#DY`xPN#nH
z$O`6#(;sGaeePUiTX!xd`R|@ltDD(b;`r+>uetWV^)pAuVi)^!kIbLBc-ahJsUgI2
zRhu@SLtHN1XtbA^5o(g{5_&v~PFq^&mmMknET$(mt~CY3H3Uszji&M3g|jMjg4xn+
zY;}i_`pWnQ(ZOfl;O1Gq&E>;07uvj%_hjWUDIC-X9nKhe>yk^ZxZ)B|hwIk09upb>
zv23>_>ua(bgoM!Rw(IIqECatz`A9&&AJiP|(p-yb*SisScv|y4*t)N3{vY&ip*tX$
zSD;FSDp;#T%~P<Gsv@T`E@f|(pXpC0Hw(OsS4OpUy#zbsLAgiu-6na7{!tY*<$Kiy
zL`PzLL`~KR-lOaIq;^z!4f_}432KA^YilPz!X*GibJE-dtE!jn!bj+MQY%B8fQKfP
z-c-CnV0%nuwVAE;b1(Y%f<|V2)Lu4zZC8cM-%u;Q7q7_~2i)QX*7R4fE^M*eTE3tR
zJuI7BOW)v|%+-%RY_m#+v#x11u(j3BkiXdyuDZXZBwd!Mxi1%!<#&us$EItRKC(sm
zbYk8)lJCM(CVq3l*$>L?*`U<ZZylUBI8S-T)!*nQb&>h<Kqxyn@BWZ4Hg931!4(aK
zN~+`TOU-tp)EC#9?H*+vi<VW|VKf#J?V?9gKAO=sNS1lx7d17ZIXs&4EIO%VA|CR3
z&`Kk)DeF#Y(MH{Wq0hBju<17h9r519qf2U5u3eRXSCNK8tH~IH-sArI7Wc;~9!7Yn
zOV<~z36IX#>uqI~es^OwV^?Os_Rt*i)(4B4JfA3=2CBNsqW9c*=j`SckIn9z=U&*s
z@X^MH7M6zQDZ3-Gqi?8WSFltf*O(;Gt}T43VD>N}(H=5Vn@&X4s6%+0*P-gg0F0VW
zRL4E0Q9xyUO3I*fUyQBK(BftYL6zXB9HnHZT2hmwLuD|1QX%Ye$^d^56Ky0@2r<wb
zUf3CN<+^%G7c#o|757m!hDv}~$_MX>DhOI)S7*bf({}h4!qEs>U^jIYy{a%Eo#|m<
z<5A&{BhZjONE}8UU7=q1&F37daClW)s9qUpT0I81iATkU<963qm3!CvPxd~^{PNe9
z7K^3TvU@J=pyKnF%&kuN{RWn`y0fKbM_r@c5uHPv;b<LW*x&C!--fTcNTkH?bGOgk
zjs39quMJFHH0&gEqUc9m=P;LM-By-0`2C6Mxh$tGNuj@;tE5DBmz8*2rKRY+C0O`h
z*NKVBXLPp4x>)3Nx$>+S|EAHsdH?@JVs(ucU#9T{ztvy&YaSh_d8V|~<tZt1%Oxc)
znIowZ?Pj;}O+I#3rF=S9{|`IawBcrD4Y|g>f0MFX6xT&^>B>xYwqu~WqN41+TYROC
z=2rP^S55RU=0@^A_J4#n<g<?1*-Y!^b)rbtSQ^cLiPpHzmRp-0rM_G4E32ree%;()
z{w$We)&OM?3MG`knI%#ijVLcz&BPvGXnQU-C&ufZ7xa&4myQI@-)TSJuhmzRvx6f`
z#X$Kw*7UrNFWJy{#lpDqC$p6_MWV_pl9`wiA>|#(qrWZ}`wVCJOSN9>KfnDulwRS3
zXpF*lc(;bdN~BU`w`k^{*212wS&#bXZCE3qNyKcKgo91l>#Q{8Q<RkTkXn++)L9cb
z;CFKbzbe`SRQXeTBqf4W4@(XlA!QH&Dbu!^PV}IpCIW1QgWuiX-cIb{_V6D=m+txO
zvptuF{)jhZ@NBY)Y&x3^e)7BacJ`%hXMFte8QZph<yXJ@%J!dm{IR&-9c*f{R))is
z^r_rD^_h(K=`=ngZsn$)Q`cQu%Ger5Xw|Ut_cF%TG-5QM?*f^z^nB$vB9YHyj2+|K
z{`up-{`JTI+&12k|ND8$ha&Nv&zzQg<BjB}|Ae*p>R(S;vEr1!zW?;=uRr~Dx8Lus
zc(8DW%2fxwQ+_&jpPemXm*HH#;s#<d%RbvRnQJQCix$*t4XLXmPc6h^RF{tGDTEmh
z&n&5T;B)Q*i^UcPr)&;>e;}~~Scu8{b>!@f@_u{!r$5J3|8jaNWlQq8<j&5@s-B*7
zRhKgOT=KaUJyn&RT~+BGa%#<)Teh58bK%W5`(cuomR9!8m~qUs2NEIklm`%@dt_S1
zf;`lEde`48J3A{Yx;u8B-nv=cuIlJkdUC5)<<5MqwzRaiQ<cMKf7T%Unr~9&unnsT
zThIaNtB}JY1aZBjf{Q1_1SW!5MGjL6v6@KI)pJD!u1Zu@5K>_X`CSLxeQNir%c27+
zJiGce6|eZ1p_&^aut51dmA4`+56UexY+SGkWZ2$?&x<S~+{i2U+y3m{<4|^xt@5Yc
zHsyYPxtkwvS6X~uPp7}`Q(D?zozSkgOI~M1-%x4kP+x`9E7_avNq%DgY-I;JpKfLT
zU7eCM$)G14mRo}^qfTcmmqo$_JSM3sUY@NeIYBwAN-}u@9E5#2{oWO9mBVRIQ1Y*-
zKB1%{TOQ}WAzx)90h0fhb+x?0T4B3NzL@N<QTBao-LuE~F$uJ`-bXe8M?Kut+uIdh
z(%JRg!0s)r<gL}#XRIp}{@w?!n0;SO%pKQvXBPDI%rr$kOeyh5`po{DXAF(3d}R*1
zBBPg-4@wzN)HJiFXF;Z0A9u$*apl4X?)}9pD@TT?Oky=P%30zof)m--O03I3^&XGV
z9E}&yxl6?<bS-E$!9>ETB+L`05SCZ-sT!V3pgCV*c7>Ca=U&{paLtC{3;zDXT7o9a
zKe+f>a?+pQP(IqP{6=}>wy!Szc187~GurDq$$2m?PEwv!#*`g(XYBmV8_X}2-`{^x
z`QZ4*vzn{6ZFq9!>7U;E!q{udkKTTfRN)~K_NkGkj&-BwUHFVL^ADezkq7?WGq?Tm
z)`yE@I9vP?#^5cE0oj3Yf>Ii^eLdCM8p$rn0*f1>YE(5&A~LiiaV88x(-2jJiZ~$_
zVZN&T`~M^DJpiMs(uU!jTc-D#WM-0?WJ-D_Q`37T34s(6NKa^?Cv*@HLPtQ5B7%Ta
zby2YZHn8_qQS4${+p4=_SIEraf6ko=M0elsfB)~#Wcr<Z&pA&$PsPD&7euH3J@gQa
z24w`h{xrsCk(QcwAHITh+)z;bf0-mD;}!t9|6^$ayFWS*UVtzhLUR~~17ZDU+7DPy
zm^;A3uOdnb%qfDVXopX2RVw@-3|K2nPscTMAdraQCH2mJ_Rq_Sj$T_iGLgS7Yv4m}
z{P)44K2KnlcYUn*OKK8<7#_s;;XT2hE`5aL0f23M2%0Z*&^v&RaCo!`@JKfdgK#w*
zvi=b^s|~yyDiB;crGi%37;xQyL(mr5By$rC3$qC1<G&Wh67HI}27mt3H8BIY^x~gK
ziRKX;f>EFq-iL<K<T})@gY-Ng769!!rlC`SLLmrVg8`w1Fdnh6(V#f*dKisZYiJIv
z3h05G10dBfbMcRy!wU}vzQa}LRxckvqcD5?<FMW2qYRYx{3rPQTfwvU;qRWE)%(c6
ziu9aC{T($)RLw&Nzu*5P`VO%t_gtc+XbKR>@?vknf^p82Q=K;-!XM!;1Nevc@iV*D
zzCzlU_dWm1>XtcuO-s?FF9+v&@haSU@H#Dwm;-_yb!dblp{7D;qqdTUn1EscnlOTa
zp`96SDXov-zZU!%?*Xu{8Zi#Aml^^{ad8n01HXvByf%y%P##tvyhz4^mb0V(53_F@
zy8TacUwa>V?qqoSA$~;g=sG{*v>I-a^?YlHU_n1pDHVjqX$Dx7&5DM}ob2(!w9LMF
zeQ@DrqxB=!^5S3D`Nz;Ik~z?4u7L)Ir-kvp`8W;&S9l%2`TQry`Boc&FFF&3@6aFn
zpTt@`1k?C442Ef00rVQ?s8H2O#qm^*mVp#FwrZn*yw$3ZoMW%^)WqvJ5*`RTO7Q7_
z98BP1cp%^Jr(XCggm$eRx;2bY!+^X5K)w~9<bX_}<>)8}!-xnfV$9Xw_$L_;)D#{E
zQUQ!q*CwEcIx@rW2yeZHT~KIi1j~i}3mnLOJA5>B7`?`=h|bAB`Ih+BZEq~S<5<sF
zq??mcP?TFM)sJbeN>85JvuJ#C#o3<zNv$Q-b>;0R?ryCuN3)-<$S&JRCpkO~o2R!_
zB6`=?&wh0!WlmeumTbh^VNXbXZSaOPXK@4mydb68mBzH^`l}Z-*7;K(Xv<Caw2b#V
z?=7q;L(|NT;(Cu->^7S^D#n#hp1ZE1KNsd1p7(tt<_%M_5v3$dB;m=D{M?a~4Qm|3
zOA$WW9v{c~@rHj(sEeETeK72uI8fCxZF7UikxXwa&#HI^Z!52Ezxzac`RMB6)=2~1
zJDsa$F7BS1oL<#DCQ?$HTU3xT7yo-q*YQJ3-q^NBeBnw;OZJwgHah;@b#o_IG*xt%
z%x<yDQ(xpTqiJQMitly$CbW3ca@)7qdh41NRQq$<m^AmOltTP@L$NdMhQU`;6KwcH
za}zXS_)mC~*%5=w2#CVyiQt6EA>!Q*y(5-QB4Sxsk-vO|VBO#waL*C_41UHxSzXdP
zslVrJMf3PYJ)xQDrQFQsAl=xWV|OflW81Cbx4wGz>s^ShY?)40CyCxzmR<2Qnq6Mo
zN>-<CdQ;n+@!4C@*Dap(+_nc&{dJ8nx!iUp%~hRJfJ~vuy_T9_-|-%-O!>Ib%BVf{
z#SSyxRaR4YuhTy-x8L$V!P^0N3O(#N<>4B8FF?ck#I=w74mfJ~-N=Q4n65w1`@Ycx
zgWIdi@wR6wvdTBo$pnL^wN&B2&aa;P>VkOBwl|g>I^Hz~|9dV+1(L`R6?8A2xyre-
zdtg#)arN{q*)6l%ny8WqKIgr~qss6uv!kfqqY7bhQw3o0yE|<Osjr4e0GSF?M!D0N
zwj3aVrn+9+miF8<PhOL`pPP3k(DzG#=Oq!ORw&^{!&It=obfQR!z`{LJWOzy&4x&u
zSgwi19jem}s~{Y5zckpp)w^Tx%(>qy1HG-jw5-_Vika1Y(<W~C3jbcbdQ#i!F}3|C
zUg{WdA>(^zpOUw)yy$-Mk@wGje)-!4p5ne-l)fV0S<rc3U;E-wI7rH!%Woa1UfWWS
zl%-jV+h$jkJXNyLgB+_@8O-Y13mKJ@mvqd?9t}ABpL2?H5Xyzwz%+muuTw1<vOmn9
z2<YG_qGiR$(F9RBg)6L9h353d+4moP-u>>{cE!_Y-@{+H20C9n(O)}euzk|%VkG=(
z{lw{g)w9ZzW3$q|t-XQD-_M<1y~Dd@;^5_PD{}jaJ=B#KmQJd4T^Ox0M?=t-!?O@3
zQ9iqENmeORHngm%>AzJG6X$Qj!BLCbr{33D=q&iBu`cUB=S0TJ4<jd;gFQrrV3Z8S
zT!A)nUF#(T2_FF1fMoxJ7++f527|}Hf3;!aw7%+@6(a_JW^jjhYwzIaXWxJ1Mfb&(
z?eeG2zK4vifsU8Rq_-A(7Qn2~*KLclO7W%ombKLbx5{JUd`*ak;rHFwS>ViH@#2!n
zl^GXm)n>!0)%bmG!WEmcXBbD!sTg8niPsh86e2lbB|uMZSHTELGE86&ikl394*VdD
ziij|n>-^=V+xt(v*g4?BU%YqrX+`_mciqoF`u^E31}ARu?pS>~gpl5JK*;i0)qT?^
zuKx-N0U_H5xAx^$0Pa!6vo{dj!tW0bMw?ZmFSsfvEq!4{fwQplzNvtXh;H)7#VBs=
zuUXU5fG?G1Eh(%s&LA?MiWmj-bQ<Vs6xV??q^XluyJ0R#hE2jb2vY%@G53wvZB`Q)
z5)vZ{0vsEjEJuo=y7QoG0y`m_U;gO>yFb``?7;fOy~}ESS=AL?%UXQvKHNNcHcD)^
zTWspGnjPqw`HdTA73XPk`SnE=-N$zwfBcs@)6S^BJAVIA9v`O_xn-_~ytS0`opmeA
zi|56!PIcCF7Us=PdScAD4VSHPDfW(x`}6TDH#dzQ$SG3C=!&}+R34n$cjfFu(<e#u
zH{S9sIvMGnXC4^k1<;M0cTHGN0GoR#VQ1vb$$b37!jS?4AV8Sx(qSRO8?@_c9)Ui$
z?PMJwen>NNEC2NU$NsH;c-ov_9zVAGczQ-<QIdm~tH~>#wSL@uoO?@kx!P{FH?JAp
zJZJLe57+rxmUmWEXZdOecP643l=H#vgF|^}O@4z*<}N}P(3O8~-<U6*H0{*c%Twna
zsLIN7Ig7Qis>0m<(M>nwSMu+7c3D&7<RvvLHjEqdWa8}n!j2ke>Y#P##&zfYRle$e
z^L*G*j(~Y}L=)gKFhUqGX|l&j&FgwKVUZ&wX$~SGXPg`z-e?oB^M{v0WpVQvwI0?7
z7Kwklrc7<K*qc$}?9kknb#ZfBwl{J8fn%FL*nQys<KL;zkhKA5r@JbO>iOK#Y;2s5
zp4ss+PUEAsd1UGkGnmm~Pl>Z$hG{*KG&`@b6Q;E~eqM3;%60F2eG6HW=?|T~(l_^D
zWp-|Nu`WhklrsQJg1iNhcuY2ce84<!<h(gtXJMNfMr^?F|Cp9e50Oh@Fq>JzjXC57
zvLJDDA?1;{YXHaHq2AO`mzCn5z6IybAGe-EW!~7L%8c~myN?lEepvnQWA`82{Q=5B
zF^M||YiCzibS@9k!JOvNYnlNO)aBJ5bBLb51_?yS3&`A`Td0cF7Wd?3RUMc&_43(M
z(+D<i|K~gFZXB`>w%2qN=Fd)i5@=vWO^G}%)!OB}AGzk6`>TCbehi@@R74ce_dhxM
z9vhaIW*gzJVT!#*+ytwE?BOe}ZA3@`3KRJCqY1T#>6@~Ux%2;d{LokUC;V>S=}DOl
zncj*CO|^qR?3yxrRO$2^yb8TOuHgK|Ime2}Z|bk9%$=Z{pIf_i<&NWvmYzFg3EX*h
z2$}J!%1q^rRN)tUc6{sHTAx|&OlvKAt-fXZ)T$z_=a{R~n9%FUKC+>uX`pLMqSvva
zDR)ax%gp|xhhG-=E?)mN+HCAJeZbK)nd{dh=L$5P4<2PQ-!SHmBxt~9H~@quA?p7m
zX#n{!MRVkA=6`+mc+h<4+zpG4?^wBYbnZOeguKd{{ta!#$L4%^K0i*cS9oujUOH;d
zl$}4Wsu?%F!kby2HRYjPWJBsN4;>#un^!0^E5VBN?a%8M_ljOQd~D9lmfkJ7jVm0U
zq%GY8jV<dBXFGZmjTNq=UQKaj-}aXJ*NP^jI?J=_Z+3pWbI%Wk_f1`f5dRv6YZcUr
z1{w}=9KgpBR7`+HXgFlI0Bsj2m?U8gZwlbck@O3Mn}b+0&5`dv3r0@ohr!yW2^BLN
zGAEtR!|&pszB+XL?41G2p>s>QrKruFubYqyOR;G@EXBq1_%*!By!l3DCjCZ&vC?(S
zqb;hM%1x%Vqdc>ItMl6(d%hrRAb$Dq(f*k&JzH{{Rye$gTe=3CS~eWXcC_NTh7U~8
zAU1@**I>#LlDxKoAyj*vEC~t!uV|K&N^X|Jb`}5Y^B)3wwrv3P%$uN_mpht6&l}Di
zG6#>JJ$~p*2z9jOJ~Sn(9&mg7xSCZz?wm5`8gA#~*8q7}Y&MG=*@xG+G!ArcN%A;W
zH0EyUZJ9ae*x^@1fT2HszGvsR&YSDA%AKhbILz*=EY^6Bx+;u`0z;SSeFFyW1jhS_
z2wV=O`^qDhMy!DN_YDzS0kZK5nt~*E22$1GMw?k4#HNI9Hi~5|Ug%S!2G?=~2wbaW
z_+XvZN>fU=B7%#%veI@h1D3?_p->oxoWW|-npuXNO$FUnffyn{3cxSy4mciaDCua1
zwyNRc5r{mf;d>txMsdCS7QT}aQv<1&4&Jlsuo7A%1cFT#N31iibis$Huoh}&|Blb0
zR4^VTPb^Go#*O%?Ce#X%YtoDF;bV*hwV&LAvwwa#13iG6c@%^1xOW>`@Z+!0Y6e9h
zcSl}I7ykK^KkSvGw}AQSAU=kF!+|j|Hv2>*djG1eq85L7+oo60S=7it8?F=EDCyVp
z|AC7ZqZ8W)aalHU2VPu-tMX97`{(i7+2@f1m!nQN6I16;dn`C5y=&^(f1{KS-ol4y
zM!0|Cte#V9T=dJsu9L5zjf@n(itm=A*S>!Mbs-`ACM9<Y{`vjDScvcuK>de9!EdT;
z@dEucB>3oZ5g0W7!0YdQ18rp``1r}~FK*nm^84tFkKV(71OFmwd=Ngl1z*j})ZwGS
zFG|w=GZ1?bp-w#NV;*=qTb2*4Lg!Xqz%SD;qcdyX!tVxu%g67$o=?(*c-QcO1|Qoh
z$St}FYH>v%3sk~@FmRhfuVQt2YXosfL;w__Pc99NilBj)fgBzl-{rT0r-EP!7zAw^
zI3D-|{2*STRsmvApwIzYC<zu=Bf>{&36e1IW4OV|{8o#Km=W~D2h$X*LiPv;nB3rD
z7%Bb$#F+ne@aJtOP`8-DCveFtn{Gpf+6vp%_wjEN?Y5XP0DlphfV=SJEu$;#e|&<Z
zT`74T_|>Zs_-)OvKjMws?nRwE9=;2Y&UpA|^!%2S_^^aQt?ypMKjQ#C+Jp+wiRPrj
ziTG_;^$Q5LFQ^kjtUp{(n&*slSek-xg<j?1Rregclp5S3W>Cvp@1DE~H!eocy@6lN
zMvn!SyoKM(Luc0I<M+>JqhvyDe?%bqV|2O`U%iNjX86-fC?jgsW#%Dt%f=VCKZs8V
z7#cOb_fbal_bYe7CnwQ(35)yRxECz~bfAkae}w;-78`G?qV%W(p9O3<JT~w?l1|A@
zse@7fjt@TYJ$A{_IOLWxc)=?tT@U|)o=~6anKg005Ki6k)(7~lf1jP&l}_z>EX_}T
za~a>kkHY24(VbUXe8_iUB{Y3QiEph5EI*Im&3_$1*#=nc3_P8)HwvILuo3*SX`Ek{
zbkYJW-~&b5v=qx@y?_B+KULr!;Oj>5931sJ+6v6X4G4sQQFzG<_>u#9yea~I%7>qV
zWb}hw8+(4~UDA%&Aj+SBuLPi0%2)3%?LD`0(Tm9}a-F^}5P8mq+wFYhfAAz2=}+Bf
zc*KSdI)IY)-oNiT3);u<Vgo;Y{qTb`*N>Y4w&L>XfBb?Uee0zc+Lp0x20S)_MM>u#
zR(ylsI(JI@xCI?gyxj1?6A#WAm_23aC+ZCP=AD`SbAGynADTM!BdWrx*LsKM-vow0
zbOpzMDbr1*c8ZrRej^2fALeMj$FHA$Q2WU0l~0q(O~d?@h8Q1hgc*F-F7WYHaMd1w
ziuhgzNCwy+5DUd>tw1f5!%ixS0GXiBOGXVbvQ|1Ch=2=gfR`FDczT%#np+;?3jnnl
ze(WR2MBwr?#zXB(dVfK$PF(UKHlU&a;<f7UKaF4GCBLv}W#EbElMmvTd3JOxK3!_V
zowi4e_nu<iyjWU*Cz_w%cRwBr?WlD#$8DJL&?8@UEpL0_rMFP|FMkkp{q_;X!{_ij
zYy!GZ%TL7PEstwYox8FKRsK9QW%j_F2cLYOi9j`%ews69*1I@zMbB&KdwlALp`n{P
zCX1rKKpzhQwS7cQdPIY_;lHQ6v3OY$KjG<>s~^!mcp7R`J0jlZKfxdlqb!i)pAWqh
z+aqQ|9l#|Kn;|mlV8n@t(-F|lo-73fH<1V?F4BZ-)~{*CdY;9rV?(kzd<5An`N=wk
z@^x*YeIsnGxI{-Am<GHSxPj7X1J#<ulMwY3E&-clFu##=a|)?V>*BuT+@)~7kS@ci
z@x=UL^EfO-0kV(~M-q_YfZ!4zT+KpscZ-gNVz2y%=cLybr?scc5{3Gvr#9BjP%NtN
zsmZzNGko?8+IvJNOq8X!rIpmCn!9`z6T9Xs`idvve?+_Fa#!?NT^frG2fo#i21uIE
z?nGbmoN8+I=)~Lu16E0*IBxQiHC>ZLtLrE3#Cg9VTbwviVx8Nf%7`{5)=fUuRoNw+
z(y=S}hZ^TXlcJZ^!Cx3jt=!+dyvV~xK^d+WvFI)tK5D0)F_<!1(`xE7Ozw=sNt!%$
zlzP0kj#)V0={C9QYtq}C#=0V{QJt^p@E4l$WNv$GZgNrujoQQ-sY=*^7$1^Ul_V`m
z9Sh%oRG^I4bt;|s1GBNvKQ>wJC`yXAqfrUqjaz4QXGBG2W$;8&Bv5BbQ=+ViQPCDV
zR7Z^foS23;(7Sk+2o2O~B0bm&!S2=$kstG*qSwt4J0V)`UZ_|8IN(IscHmWe{0_Gg
zZjivH9tJs-YX?FhVDLj86oDVS2CxE$0T_dS-7XFx6}K0o0pg&}aY0F3^pZ{uzvOgV
z0%x_7oK{I*L1|j@F#$Ni61YS-C>1P6K&cRo3b^Osu!%#eYmF~BOAR@NpOgTmX3>?2
zseT%@3)K>>q@7pjPtA?ByX1L=MqQx~)*nRxEIiJ6Mx(Pey$0{}@HI@1I!cqLW#>8F
z#*7e5?#og$ERu;tmaM4A4426;U13!vj6x6}lT_@Gq>l9!naovqTe>2)-K?`Jq^V1i
zN~;J^5NnH!wp*g35;GNO120vtaq`fY$3E8}9sXAH&B5T_Xo7?Iv!1G~_FpF#_bKM%
z^=)agB%$ueKx%C<x)Y!MtO$LM*~yusCe|-f%&6OlFCEoiLuclIr*K8HUt@NFAmXE!
zrF@*L##=h3h&n5~PE8+7G(~49CJe+&5+xQYDh<#4`<WXj)~^;#>RR*a!Q8~r94=FR
zP($x7R@7~`kKh;o4L3G}uCn(UZdkOSwX?(fX%=jlS_{j;hA8n4j>0)q0Al6P1b{`5
zgy4qR;RBZ|r}-0baarbJ&Onetud{`|BtRz20sw9yuQ`MObkN(#Hi+9Qa3PmI)*Hv_
zz)C~-12_OkyatDA;iDj+EmTdBjEr!MC-ArGZ|=YbHch8-vH+AX)JQiJ?E-+v{A8V<
z>dmR?X~4mnwEiR9g14s?qb~gTr-kSX-GZ)(6~4}2Cl&YM9VKaP9N#$#5MyJTeR7-L
z#PU5wcgqMc)Q?Z>TC;e?#D+n9OHN{49558?zyZ{mif6ov_~P~|0Mo7x{7r_cImB)1
z5{=RHZ@8X=Nrs)8s1dgz8ZzH~4C)Z7T1_D=cFT6;X_B(lQJdSGCd0f8w+XNnZ}Rfh
z$JIt{kyrChdQH8{<aW*n<UXrrC|W8KOVwGCQ5kNdA>#>UfkpRPBA_XpZ*1!0PGxL|
zRh=+ubCE-y4BW+NuCjwPwnlO2D<f=U1m7Uq$#q#W8{)-o06lgmWXTW963&haAh=GN
zVetT<rQ?0D58)&SCk=)>+7S41koKuL+~I68;274&LoPj}!+UAYxf7BlVNOC&1-6R-
zZ^ALS0Ch3p0%2AZvH+12!_PfxC13*-pab;bLVSrz0BnXcR&$@yfEo0zn)Ftu(KyfP
zfhD~fq0ZCz3U$Wmb&TFKXfUR?r`6VH7~Rez$=W<kl=>Z0p4<g|I@O<p+JVcch3$y;
zrzTd?$N-C5<QtnRaTF(2UX2))pt34v$0|BQ%UhPXq$6Kp)jg15Fu5`!qwK(7WQb+d
zSq#Ujqa$sZO7>`4ac$~Ah~n{0T?>>TxPEQRuEL)@jAnd__;XWgiqn8&49h*`qWZ~T
zCCYcnWUlDF*m&SO4Rk%yYW{I2`huUX(Wg>30uClftOMf}8NN$9XPoY;>=aIE{N+_#
zfbf77WLsQaVouFs5P8DY4ZQ(BdPS|qIf8{AJ}b9b)V}8BXN3$1G#TEMkN~k34_>tj
zb~86Y%|8$57GVoI&4=wPp+%Bw4b7~yu;#?5M!X*&D>y0!O%~t+pGBx`L}~zw0DWus
zr>kox-ucdw{bxUX@5vihzI-0>-n(JN*oQja7(YLMtt03*4vcTQaW595MSVL0=nhx#
z&cOqdYE{pzJjg^0zN!yA)J#o&tbf&v{&Pt9k8i$RT@pWfNxtKTGW?7zs|UYg)Cf0^
zEl2%Gvh?5!yC0K}oeXn02y^(Hc?h~skvPa<sYkPao&>0n|799vo-h%Z2dG2giNH(2
z=j)c;WA*RDFD%>h(f6O9>|gl7r^q(7yjsz}w&moUJ6n6_oGuJ}96zToHfhw$_k2UI
zne+88KcogvEm+==quM{PnjX4q`b0tChh}QQxuvVSCf$P)F8${A^-d{EDemYL-8C97
zSLex|o7iMg%~^N$v3L6KdVI|t)y+VsR7CsL57{g1zd<{8!fY&1=RF)EVk3+cCIN}{
zWW~Alw}1vkRzD04NF}*~k3YW`Up%{F5GCSWE1o{Q@7VE~6=R;6^8s}*_}T5}#7l}d
z*3>R~slS{0HmLg+|2TKSV<>UQ4X>Z+9OM66oj1Ghcuw5!y-4Vs^!Va24JUSxF^#$U
zAx{EhisNcof~M{b;|K9T{FhNdVhA@vZee*6{3Cwv`Cp&DaXlIstQ&W5@WoU2?BCN-
zRCB!PA~ies()@q)-a6QRU*81ky<oy4AJ3fk1aj>%jcLB|v5s2T^SLSR@f!-v7+00{
z-PW<?$Yy|fGK^<EjED44D1=oaD*!j(39(3P;RFeZ3mP68a0*tX=k%L&2x%u8E3BSR
zZKuQQ##^tev_)A<4@_`5`eHC!^Wgc5x8IL;uGzBWZ+EZQhxgre%gjpTR8UbtX34Vo
ztI#_S^iQ6)wVe6_(YC0%UF#Q`qxsa*@yq*HTtJDp-?#ZtTU}YxzVD{u-=A2sDvw4t
zpm}@OG(9;ruo9!B#+BRp=L4*ni1qlC@Cy4m^im>LL&)s~y^G|dUpJ`%gY$YI)<LIL
zz>bheWXJ&zX>Gv%z+6g^jUvI{5Os3I2$QpdH67LiB3fuhNf2Ck<@59Spa1yq<wGC-
za(eNNw@!cCi3G=HZ^yMU4fA%by^QjHNjuYbbLVf*e_XQ<&pi0dyBALnEI4q-?kk1c
z+q2!7$V!Rl<BbP8`p_uM{(T4j=hM4yAboc3*+0;CYTndY4?ecByM5`jV?(QF;qN!M
z-2cj`Vu5+n#N^GR7reNz3*U12!6|bmPk-=G$?gi;e4?(Rd)fmx4B>k=oyM1g=#EwR
z%I>E){2xV+qkjSYmelzr_z#6xv~hg*^;h&Sc>co|_9*WTenwv0s=AvVhYWAOCSCeG
zUJ!l(I6HhE5$rTMuE2-=bG(w&W`@*B?j`+8YsZ^=6nCLb!OzGm<=to#%f2<aPqOqm
zv<ZLl_N36O(75oE^e<==MEt_}IIZY^b-vmE^>l#4c@U)ZJg*dbjK)IGA#Q}=-HC;2
z#vVWI1$2fSXRsteVPl4rlm^9`_R-JplaEU4K?uLsRZ%Wi@zMGlmZAhS4KKs*p@izP
z@=eU%Epx@$*4q1Tmfze<&FeIo;^(W7IzcvNO3{^xztinYrw6|wGz4aAIvcJ}BJIrN
z`kZemRLTPcJow(cZn!jfAK=njxOVo@f~HvOb2i?M%Whct9D;sn&pr3Iwdy_0?ptro
z9-Un_b*67|J@vfObJQW}?Dk)2e2#u&VP-eJg#=g9qy`iHZ1{SyBd*8IH*~!}P4(HM
zB`q-y{GQG=slBfaCb=IkC6g@a(JWwg-@Lb=!B^f_Z^*8tUNxqC5i9F!&%V;|J3V7Y
z7M`*@0*$aWL<phGk02rdHwLV^#3=CR@8N69@b_d>4}aHx50xf33m<U3;bWKxs+^n)
zGJ^kKj>F~Ts6eRC;9dM3?ANdoQrNHcL`;vEA8{jCl#fR|6Y(0Hi0^RgLC@k!Nsv0I
z;T!1PVeUq9IY=P0*OQ@!#NBI*7wDhd{9rSNy*k{6e*h^WF~nOBH?Sf5wB)3KTpllH
zII%-%04N;5$v-%Rr2mm1X}|*Vj<YC`i(D5kp)(1IQHl=vXZ|z<;7vkc#9mMf;09A&
z>yfbk;>QT2LhBoA)*hP^?S06?GLm$bl0Y&wBZwOHOj?T~Ee73kyQVj3+sc8tF<F*|
z{DP?>6eVK1s#@oEck^X*op)MNQdWX8z5?>hQzx|qPfeSOYRhd1QJ+=s)n}+v>0iN&
zc^S{Ovf|a{HyLqX!cx=CvCOBiDM(zcLRw}?NpXHGV=nB7ElkPCPfPN|m9{SL!`}vP
zHD+Gwq59a)v17V@CL~ejj)EpAHzzopcsxF=5J1wtc_Mn7H|IM6dXp8z2JWvL({5oU
z>D@Amn5igOo|x!Xk9sDhRlO=ofDFPN`(t+>-nHK95u5aN`FT?y!Zo*MabF)_h@>JV
z!}6m%iUwP>chl)T<HolYA^dDcjEK*ZO8NBdb+<((N+a>{_t9)tD%b89eI%N0_f;!X
z)fYu$_uRM)X|K$jJ9qwCRrZ2(b5Xqkw&7}l)>@K9U7{vQBir#u!CTW7bhP)^r(`k$
zUXI(Hw>UP&hQXwHyb-~^Ak#XLt4$qoil=8~AZ?~{b|j#DPM8CrNqzzmHShr!l}b{!
z!6@J&+8|&~2)~phxsCk7%PAwo=g7iO95!z6?(@6BDXn*t?;xCl915k_K{OLZAIj^%
z2VrFe1hJN<pVzX%EfP*0D<1WV*=bh=9#t#lDX|a9L^fU8w4;AtT|9O|JdWfGAq7S*
z)5>GE-5p>4_&W57A~twJAWd{9By4UkqdyeK9-J_c+)|n|PITJ4EN*^LYhZ6oNp5CG
zOM9fnM!E1;bY9EM+fc4x93Ov{VOD3yL~G3%Q)D9EZGEesiG@5@iw&`IgOp-vo<fo)
zmYHY>qGwX9@#*XWzTmFeZKZA1IVnQX+~!SzgeZMgZCjcy27kG5ArLrJtL3d?8lW~?
z5#)Zfkn9^+Awp~x9`tc@_+d*6Zy;kAs<rsR!s&)wQa881hM+d+E#|jqAqkL!L};P^
z)B$}&9XH;pJ&6bE=COg71oDUED+SYeg6cTyw{(p-`CgT^_5dHYNLdOIeNlrxd*hAZ
z?Z7Df;7ax3D}KAp?S~$f_=?X4)vj#qk3BZ4POlLt&qV&4WwNIlqv9%fY0-QX9n+Q6
zh(B>UJsGAF<Y3~beiA(4$jP<aAvb9F*`Ax7V1qD!s80uuvNLoL<h2&|l_UoymGptN
z5y=h83RL(Y`1N0Ag~-lu#Em_3Wp8;5b9-dX?xK{Gin8RS^1$o)>8VAfDQS81)PGHW
zv-`uzpZ-KWYVvsWfyYvcic*p*tCG_5OHxxx%g{GShJPA)CpqHyIq<db2cFvr{UK&?
z9aNTZz8kXRy$$TAcLL`H5$7jL0pKWDLA(~u_sjvzY6BRN8>z4Z0nlKV_CXjr@!J9(
zLp*dSRnBK4dYKli`#hqJ!Hwu<aASd+TgdqVvhbDzIC;zd<qi?wfG6%au<nQTc|NdX
zlABJfrXhV5EGb{lpO2hEd!$xp_+thtNnYFHtzLd$FVdiC%YRAlTy)d>2l8*gE^wIb
zz(=br&Ms;!^?gs&p+Vicz`em<2y)KrUJ>&$TJc4vj<N<mS&M&t9?xHnEf#wuE6C1^
zrVdK?TBtny_x}FCm+|8dEo>e)KRXNkuy`?kwZ9*qpFbbJ5xVoik=Y_+?L8kUkS5A?
z^D^{QPK>2sc1DbPUKE~e_u72;x$&Rt?0h**PwMILX;smMW8xzhTv!p;5}R9@Tugl@
zQhM8Fy_c3^@}r_!QMR}Y&!i*@N}-Xkeg(x7>pQafd?D1I;)!(nXlfQ-I-YtmI-Vzz
zI}%)hr^gTfv1xK1qZrKxyB?n>OBoxGL^kz^RTJnwD#7G1M#upVp5=ec&ID|ggRYYZ
z(swdgOlN@=o%r$AMr?#U<J$le0BZ42FUi4`&;Wy_B`z#xxfK5#Wa9(h^8<hpAPKp_
z*BqkwLWlx9kK0OeUjjy0MhI`x)zMA1bJw6hlH7@k_gAa{t12K3*`mZC{v>Bocf7CX
z+4S$mdHB%i<20TjC}D*e$#%g8X-iUdaA^B&bo;%@CDSR<AFuIZ#L+sPzfEnDM3x|t
zwLGh9u0s$bP{`S3Roc9a@+PV=xLP+>o6u01H*P_c>xaCVk?a}hdHXuR`RzrEg68~`
z<buMa<N`MLk9qu?0(0T>Hv#tH`^o5Ztu4!9YGO(Y^qM>A2bUF5!G{v~l2~g|mXTM)
zm@Yh_d`-?14Yj!@sMT^sWSMSiQjRD0_&TX6D%M5|=)oGbU#=akQpNT6+68ifqB1-9
zye9Ys2UhBZWRDlhb7Tf{y1xno8huVl#U54SxJj<`L@(*3GY7ZxRO~tMkHo=VFdJg#
zCIDnfpCkx<hqVLxfjabIKBVNtn%%3^F;Eo&fTxakSorbC&9^w*G$*P!Q-BX-p2Kd9
zkK>9XFyO@?hH>z~!h5$1{7PuVv79LrKt$vlg440<p15^?i@5&azEeBKQg7F7zqK(~
z(6r}Xlvq_Wch<5uHf?PQn8vL_cP%VKZ<S9!l$V&0pPiIYi0+ON;by)*hDG=B^ud?)
zeB3OGf!b8}u`!fl_^80o`3Z@6g$YU7)ZKN#)iu<4eoO0-{T*#Ar5?L!W8Kj04eM@d
zq(stJ_CHZKUN!V$K><q2$Y75r7UU-+<>un%L9c}Ak)M>ysouep@*YOw9gOUy<iVcs
z5lIR81&Il{xxpWxsU`f0BV2enmyaU`%CQ3NWWg$rgH<NIsJ6g5kEn4Q?yo{LKtH#t
zdRS&|RY;!*@Pq!J;W2Vu|8HRc*(R^xDR^4&MJfyJLbp=hF~KW%1Kt$;ZOMX{ADy0$
zjuv!Xczxjw!H+6}&z4g2gFmiVw*f&3$HSsgH{W!4O%-)h#p;dK!L>CTZ%3lyvZ=ju
z9>>)_n>Ev8w`QRm4MMz<r!_EW4XeeJhKE-Q4O$khW(?@V;iH1ZnUJZJZMA!-3Oprv
zp7O#_c2WM|OOSiKkP-xc$2a|Y{-yb=Qc^a|edT=cYnQ9gPG6GY3tO5R81!+~vSk$k
z*{G$<YtTEAGh0qn)G4WETUMsk?(^Z53!Gx6MYdlirN%GVFKc1M&IQ`>lr(rWe1zSa
znPs#3NNC6$JcYfDR|HVhbKMzB0CGLR_d+^fSSIsF$Y+iNa=IUvAwv>OwCZ@;LdSyv
z5G)Tgkb;E}2E5@w1n)S)02_qG1x*Zz!WW{3k(5E-lN=M1Oz!7~Ur<dol}*7$DD(u+
z)CqVVch4KaH{ZAi2@MA7gu(Ec0e@;RAhQ99Qj-dTPZuPm!ZVd$&`g!3rInF;@W$a+
z?B$rGq?i%+E3Y&b<mDAK(qDz1FCRcY{4)4)c+4Ly21APhA3UCCwOFiq<f$z9Zn!XJ
zxFTo~!F>r?KS2k#elgGmBOfrIbPyqHI6q<~cwqmuj>J|6ksuZaD7F?oD0Glo{r_QU
zi8`bX-(hM0|1C3ffACN}?1~;+PDcgPN~tZCl~=a?ua}<o^pU?n<Np;1uG}7cklM%a
z2L|ek>xTYdehY);{{RvlVj#}q4g^^wxDCy~JLoU}mq20wMosKSUKa5G@=%Tu3$2s&
zd;$eXq4q*O1vL}~0r47gV1YtLb~vDs#siq3W(>GF2@*p`8z_GR&Icv<xJ*cG(F4;b
zJ}P1sCeQ4~b6ax{2dTrkThC=tT}kL}9AIKa#?(lvCNkA1iiIhlyOX-8O(xnJ_{~b2
zq-fD&QIU~R7@gJEjvieb_?0|rZj;2^?mLy8ead%xjN~>c6HMya5DU@vae7VchMuH=
znKm>v1-=vp?o_MMPiplK`0nR&LVtuG!ym7W-3Z#Pp3}E8uJv54hAIHVdbdr8*pTwg
z`BOl7By%HMI4GLvwQyzduF?PSH(<8a(omB`4bP+pD{;iKj|>TOB2fVU4DlR({0BrE
z<!;R{O^VKcyrd*4%IHAfUp~TX3v?wL3`t3b=#;Z%Wy#=Orzd@K?8u1|m!2K>^7wbI
zP?PoPpM%-z>gQ>ypueafI<=ypC@LlSOk;(?YBd;AQlkrsqLY)+BNs1HQJXh!#`7-1
zANBFaFkPrU4-a=Ur7(Lp*h)!%Su)oKVu$<F-U7-qX~QfC8o7l6;fcxyLLXeuobeO_
zNk;qz0l^ZYy?&3U`P+LdD%yL>N_$bHM}C-D-Q2WM7+A@y8rQy9D33|^FW0CoNqmDk
z`|{%*6{V9WmQ-}Jf5Sgb#KBJdb07Y>_p^Z`747X6Ws@eC%92K_npfV~WQbAN$E{k?
zsnJED`4lQ~dx~MVyRV|VtF&ZFCx{2APyE+A0X5mf+{6198wCFb=_XAq#htKo?*|UF
zCSn`xV)jPd0Xr~me*v46c)J!5-@}Ir)leIbSc`}Ol^{JS=SGvtkbvz(t5lNUi{YXT
zj_|4hntOqP!SRHNfvbTJCxfND=CS1tB;-IGvEZx&S#e!bfUgQ_-jVW;ZXJRXkkz%g
z;0_7)ynm%BRB=N22Zq2z!v{#Oijz5u<?V&cx$<UtaZ!9p$xya>vMi1lxqo_AUS8G?
zYgDAIC=1;ld{n1nsN&22r2KN7F8HW{{Wx~$YC=?2R?)3ic+C53Kl^zM@5*g#Y^vSF
zyk@ee2JcY4Ar*cgMYj*V!<-AwqoxXjO~HAFQf0Z2l`RwK9rV&0XgeLr-oVNP<#P5B
zSv5a7Sx_Y#n#8QuY8@tVv|?!4xq^b|!u*_^D4RVprzBn1ud~_UA&pIn9gMOSX2BPQ
zS+SsEor;a6XGLjLN=?+2y$ZY7EQ*xLncMEYH@J@S1W!_9f^UhU2_C~AznS>~;7BTV
zG(az^R&Hksdr-szTLKjoN|=Qa7xaD$G3yhN3P?<-72bduf#|NV1tnXCk+?j<N}%I}
z38=Oq{Ek;byI`8%{I9@H`YxF(QTPvL+1SQqe4Ncv3!9q<1oEVDG{mtQa-FG;LVEg8
zEFXeI+e=E?pr2+};Mn-mqVAsj(pLJ9%bTVJc21*~W887I^PL6EN&EwHNP{k6g1{;o
zyL3^5!N8Ymn^!DtaWu=bNW~Xxq|Cp3)>Nb@9J;5twY3<|lvmo;UYI|z6;&buFqGBM
z6YM7PihGAd__r|L-$A?B%fQ_#z@{=DI#4ZyINU*qy4(uA9Z6O9<DC5E3Z8?;37aLZ
zM>6crVD}B%W}?P$rAWC2^MdY40yF(yVnHQ*Fl3zyDJ!(n5zkj5FEwoN<bx(e$cc+L
zfJfjU#Q8>8D#sN8`-cStIfPUOCR9Pp^-#EQ1YLzbr(KV3;ip;^Dz!9vk~Asa;Lp^t
zMizGnV>N~H6p7Vjnk<c$S<Lxc9(`-yzPDUw)~!23?tfQ3sY0nOB6(JuoUe;=qk~44
zS0uh5DH20n9VK!p-8~T3v}YOAbe0_0gP<C%MAC}4zgHYjUb)BvvvT{}ayJr#FL=H*
zY95nw<hWFmfFx3@M5H;BHvr^C&y_@??aD~RxaDtezx~4xZ{KkC>;||8bI=(0-O1o7
zsJWps7^FpY`<S1#G7}?GL`Ev)Mwtf9QpjZ{s5Kt>?wK=lB@*%S&{J__WJzQsT%S~A
zA##h<Yrew&j^pDb%cmErdrXg*4RBovvDKS_oBfHO>w%d7#uJEe-NHhurQSYljT}J?
zA(9Bg2bc}m(f}>kP?Q<yqr_cv%?1^si4e~pHmv}?z(st3IHcx2C-w=1;m*%!FDvS4
zt1cV=XjUuVmouS$jx4B?yZyDD^96DFMKS7l9ixhzzs{hKw6aABm4)@qbWo8gkAuJ9
z#h`+ZsLxU0r&MS7G|VOZeLDWekN-_QnUtKI6!@j~#*OKTk%+v(3mgu|o#j(!7FAE|
z%P%s-j4LefuBmc*R<s+9h~*`#g$YWTSC(wDx6go5HAVc18O<h}T^{_AshAv7D4lPJ
zkqgDrn3!_6cV<ydZy%b0s`07eJ06>ql#D(=)f1PXNJTmKcHXpU4NmYile)sdpMGGT
zg8Ch0V8xsWk%kXK--K78Yr+qN)_|&rL4vHM!$KZ7^GC=4G7N&yGk79=K$ALBkXHqp
z22vQ5yw$n&Ad}#C78jpbjrmr09297=U)wbx2e|;yDQp`Fud{eP=?M1Xd?$D1P&8p2
zD0o1@gwTl|2X9F%0xAEdgSK*j2E-4-aY=9i!}-WY9vCJ>7LB+NQE}{iuN%BvP$&rm
zVrXL5`KylqgF#XeDKpBWlk2;410A`OCnRdMirDnnJcc*9&6}LVN@8!QxqsPRD`bl=
zc>9v0G;-}&Huj({xwKHJR6CO6lb9`88WW2zh@Qb)c<m@t6b(_+?>a3|Vkpj>9zbd1
zjRorB;&IHU$}4{t%ULL07$_@xzOyr-WYRL!ClldqtORyMa=z3mFbjk{Q<<6HUO9Rq
zORq<%&M~!+o37It1yPryXf2e8PNu*%l%E=JPEWJMrP1q~)+Q%5tZ5GXBvvUJ*EdO`
zY?(T*JythYigK%*+6)#6bym-mDFrqtK`oBT_*Z3Y+VVLmQEs`p-ecx5VgZF{S|rfN
zd}YT$^omXyr-T|wESs)IQC2@sq!tPyD-^uI-{QPpbDY~vUtnVu@tH=0JxG5k6w9Sk
z<{suLV^fuh<4;MYGJ!zM=ZiIsaWth!>b8vPTu?VQGdIgyCl<*S>04qlDV{`Z7E9<K
z;yqro#gjo5cDB>>*4FWi1B!7=L~2QlHn~XeQ%FUCvS4W@y5U@AGsuW0kP_`s1*;FV
zBhm*rl(n%QqMNpYb#FiDNk<{Z>1@Q4;Bk8adKkPO@nOU#P{a2Zs2^%XDNt7<3l*U<
zGz!7i36c$_qs3??T7$Nu+t6Wj0=N^;&7pnhfp|c|*rFlN9M-`m*iDd>SnYHm4}e1a
z7NUy*DiZ<kCUS@imIFEBA!P+QF2l(TPFnH!{&;YoIY`_j6bJOiJ3?<ceadUm@e#Zy
zZ$MEWCLCgW3LQm$%N4P(XdR$-!8w4&cn+<b=k*{5oLbB2_`ui5Gf1xC;1M_IeIUg`
z^a0u(Au3(G8%U7YtHYaz9Ha+o;v^<9i4iLFb5-ccg!E9d80G^CVkj06q^Cpg00QN{
z1jUrB0Uu800C5@%<~c&%v7yjYxF8R{flW~89Da8!tPFQLyVm0eA5-`|-0z{KiakDb
z89gZk4s{m2dN_dStu8+|Fj#uQTq}b=$s1Uf68OWvaB&6>2#iWwR3w;gOcST^1$=ab
zr{kf=O*G=E9bFB5d}=5cMMd*A#ChMGC)AEhEKavaYa?gQm@#9BrXALt*DVz(Q>Wyz
z^5{wXKWKTyQjt1k27`uvXN34ynhuUSZ>eAshkmb`K9zpVXNga*kM{&t!eJS`GYa6h
z3`J46FByL?5oc({37??g3sa`#Or&(ncAi4oMV_fjF^{KFu0gAUkD#xd@s^a@hAUr-
z)iM0f5VgZ*^NnxHOpOsB{;UK;W|COOm+&<Tby{vE)B<NH3C*%<T1pEPtjQg3j<ZM@
znFv~nD4JD_E{i7>@$}>4j4|d%g<?%1#n8YfXr4?2i71dj0(Ex53t8%Nd!1}o*DbL;
zM#`{8p-jpsXvDapfjD{5v!a9&kvQrm)e`uNU8uTbxUs2`R-<HEBIDU@Qbio!2vzB6
zx}aAaO&fWO8B2-<KWz|czwh!VR*g3qC)A{-j&-^2)yS1nl|6Nit%B+A*Jv(2bgR7_
zUg0G<Ik?=HB%x2*%Y&<yFQ=A(AL0dz$8D{5(XVjF%(0gT9+yH_c;5mP#D7Dn@sPCf
z96z^|dZE96&J1jS<{6YwQGwrk<{8;3YgAN`Or|)})%8TY%N^IaPn9KA3gXah%f^ju
zOU)IDdE%nz1h+$>;UfhTDNpsj0?bZKtC>j@Wn{8qV$9<sMHDNbEq0+Oi+l=QC>W;4
zY>w>|7D06#N-vm%C<zjQ3N_E0>DsF4knw0K6D7^n&;mw;3baClEWs!>LGlB)kL91I
zkHH?U9%8lkMI3{UDi23IJwmnu7Kfu}IoV2R1_;ORCj5kxXd(GZqJoG-<76x+SVONs
z=>hyF`il=5!h4;=5}JGV`rROj<3St}-U9Rqw-5t>S6~sh0Iz@>TnQSVIQ;2Q*j&$#
zMgGt!fuz7P9<Q}=t`C>r#qm2E2wVpY3=9nCJ%-JcRPSr+Ee!;6=1g<)ql_80QmG_f
zl1Ec&SMK~ZPH(lV8l-2ga+B3;ubt<KZ?1vxl01b)t4ziZl$Te=*nedD%1p^iqCD9X
zZWgHJbb@iM8JNA`*%j$|ngNx5oH55HQ`==0UJ)M&Y|=n~TwHBZQZ4t0cb1nYnqnQe
z#lX(TyJ?z{3DinaSAKp0o*0Qg68Z{yW*4QP*4RO{nbKOTr}6un^)|j-mgp2uW#uwa
zw^E~3N=)f-EKiZ(w^&3`j9A^)P4mP?O>wqX0H@@~Mh&LiHfq#ZH_}TzQi(tj*`SU!
zFg!%bRdk}*<~0dvDmJwxF^x})g~}9#SD&mB@@PJ!W3z@+rDbeE0b5qeD=3hRs)@<S
zK=ha~i!w5*Bq+h{UU+u~<4h*{n3%{mo`IJO(M&90j}l`3^$@Ky8oV4cBNhYJ@cqEk
z)eb*+j<_w27A#)0!>{LifngFiejFeV0V}*Bn;~HDBlkoEZp6eJ#+^THh&c2MmA&Qh
zxzLhf=|B*Hx%}>f8`ih~@#Bwp#WTgRrm{=xUFcoysUMja=2XYWmj})};$vg14!O-E
z7YZa!jV8_&y?nMGJySMsi#EZe(G*M=<?_^4`}}213WYjm-yh$fU#N*SA#}q-V&VP4
z7e~9vx853dQ`^>_r$5HKbSCG`G3idD;L#X-xy}8KDLYWyx8CB-j$3oH$q=QFGHqj%
z^o5_6Xib*s)3$-8rqV>lX04huNxiheU0v((l~<zJF?F3e4u^5+{8Y72h~1;Pk72Eq
zobLMt)YK$a-a6QwkQLq@aVymMzYlV3o{hK|@oB`*5kp*ESXj{TjR>x=G7N%<h%{JK
z$Z;W01;h{n5%9wc46kCKQXkoP!f~9+3&I*Uo<LR*1weWxLma}efrhNTPH)LaBaP}1
zip5<I6md7u99U-H!R_(-pcA*=;;{jFL#&(&+?B(+0fCk+9*j6{sOt^H3dQ<Ej04Q1
zWLp&)F(F_$k`T3;$oqJ3fx^JR8LEfe5#r5pa3(=7=<j^~7c`B43>4-h)Hv?o?v~(*
z`h$0uEfFa#?#yY?`YTNjL`KG~V0AZZ4%>_B{ZXm0QL4&xr8M5$45fl47IUzU75fx)
z(M~&EYlAHP8*}62lQv<KGHuIR{v}6TWGs80_HFMdD(dVh%<sI&nwfgRl}zD4_Kt=r
z3reY{nx;%?d;$gU4&JC&Qr>`yEpRzxDwVMg)wdTGw}N@06R%w<9m}v%ExunWjZ7Nb
zm^ubel(8bbK{^_OI?NJ<&?4lCMZDUUxVW^0sOU0bg2<c_pO)aTMd|H{PeB&ctZXQs
ze^nI|FRh8sPY2)J9fuAb5-1&8R!r&lN!uUL35eKz@hweMzNyB?2lu~Cx-G^a%a&<%
zIWm=<ipiRLBABGA%!@=X@%Wl-<9^Gw^+}Z4n1@q}CbSk7c6OuaXgR9R?B<QFudf%#
z6^(H{%~z$oHLRc-KVR57z8H>qY7FwVp#2FdnOgCgL9F3fP78!$iJ(3y(Whit6#RW~
zFfq|!7+hIY=x`Jy%$Oco2Layj$H^S_H+DC~K<FT2Xe?9}=>*Ik1n%+Q0S(9kwqFvm
z09@lQJOo$>k28dXrO<Wup#~<R1r2iq+5tL;vH2Rc@U%8xe4L&Ll#m+9G-qbk7AK_)
zC`#o1Q8_gw#RZ9uf-?MML1ytI^gOjbFE7<m5_rpIvBXzRlN$KinCJxU<hlYXbKDY(
zR3}SGhhU4qzqDHF>q?iiuFAKhPNj-<6&+UNL1{&LyCGd8;qg?c?<tAo#o#Lo-J`2A
z7c!53_+e>jTH1&2&X`_QG_B;J2NQ;#%#Sv2H9Nib^|!=E>+|DRpavA{Rm3SWwl6EN
zXcR^PL?M*pHziVqk=jsN8u-LjH`eJZLS19VEP<NRAna+i0*a~5X5|9GA1g<@GYf{-
zU%+EpAX2#)IQMGUi|mDZ=HdLT|AC7@+&$qT#BcE*+yf|_C<AW7ME=Se+@Ng3mV-ns
z{E3Ya2|zZ<ZablK!c@psnK;2A^5nm9jK8u9Ir<By5by{OV1WlDQ{!3=-!?vYsNu*x
z<u`~_miG;MTvxZK+Kc{{T;Ax9PBlj>N2M!eR&z^~B;I1Dp6V(t?&>Wn=>9^O!PGbM
zsli+b5SX+TYvrD;>jXb1#21zqlt}BTebcA!rKx;s*Ys)o(P*f=et8jF=uVKSRi-hh
zrL(A{y%Wwtuh!zbfy9%mJ5uX$n@o;ZN$c!(UyM*H^U20i0#&S4T4T%40Qx-we*%?b
z8;To{H8d_W>Y@uwwLSqyxI1E}=0ayaX{OAGdyCuJz*O0bY*IbdH8veqFUDxPBYyj)
zWX50MOXtsLGpFx^@$K6`O)t+ttPJAO1vU7oqW0Dj_#KsHSIIQee?$YV+D<Da5<x>s
zYMzjWh|y3CUIed^c^7JpS44DxH9u@y2?^@!BAZBTfTS*D=_36e;KsFm7)A?@>_*7#
z5i}RF)d0a|IQ3kPCbw_nHBxMm!(wtJRt648VoL0zjoxSmQBrlBNFaz3M5QloucB;i
ztI{DU-I);?sqd)qx*Kb9RyL^BalW!MB0SAMdsUJIxEWgc)QiDmD|`*Lxhv2jko9S3
zj|IxJCv3Z2qV*Kp)**#_if*5-NtdCC&T=LsPBb-CYL!vYFCc0(ep)J3#vJlCj&tXf
zqJ>ROt77?TnZjD?%2-S*1Yi!{(BR7{CF>;wyWv&-lgyEbQpkTLUXR@%l^=wD0Pn%d
z@%Us93j&nWar_o8{V)_nZztPtB9yO5xnaJ=ts}AKf^2p}h#E*YNGo#aK$d%b5K9{(
zpKE-J)M}SO*(kF41sM*45+FguFCiqNE&s`|1j;mI#e%LC;&DXoa$_T+77mA0T=E|N
z$p@gsgMAW`7s<uAkMb#KPQ`yxs4-}D%5~J}u`5^A)zWx1OH+yX-v)m}S~9JOjW=j0
zv5t}^2rW*VY+Xl^*5x$_>xA@xB0AY<oE~|LIIC8mm3s{;WwcG8O?F2IzOK#^jq$jt
zW2>aX{75NEbtlFNR21!$Nu@$z<Lyt6MYmXPX?<$!TnYXOVqdGPq3g<!yp^$<OHf;#
z$5Th{j8wTxq7Wz)_MT*c0{_NWN_q@^;NaqGzmLOv_)4*<^-xBk+Fn~QUV+||MpJcZ
ztD48RG!3#+u}Fe-mN7ML(7(;BZ{tVvjY<pSY?bTdB#c&;plKW*Bl1Lc<>l){`2C|t
z_p~c1q`aU+6rDZyrZUm;dJS|{i$;=|8Y3gDPmstnqt%*qFSg8iaq1J9wKaZ!O*Oj6
zwBg4?W38js3p7@3$~_txrA>HAAZ8@Cr&G1ditiNVH!RT60*iF2ttvwb`Em7EYXxyU
z7BbR(5J{8|+`4>(zkhPX3@%e{16YB;mI3=Hf@c6Qu<zJ(-mpv25BV?<IPda9L?`U0
zh#$?RSH>cm7+3ys4;f;ve?AgpY!=pMQ(7pma^$Dv7uWbO+58FO6!RraiF@zVxs_#9
z@Tz3@jOn+e;Ww0V(il->YsOr3pj^cG+2m-=;Ltyr$f0i;9rsLL|C5=MX}<oBo?h;B
zl@w<<EAitv4m~Oi-i=qkO(`m!&WftE^s3;4ZfZR478X~qsgVzhRhzW(9KD>bu9<S{
z*xLD3oz#q5c1<5wK+B?UlIsPihkj}PC)?9ghPqiDW1l|#mW2zq4-D*v#{~<52No<q
zug#siYr%pQy}kIVv#i9GQC9JMmUat$1REKgi-XRJ3TIk*8RE~Lje>Fky?U#tTLZiR
zvVOr(ok2eXkw_3_8-f8LZ_en(+4#Z8WeLFpyt)7d$b7blGWvxrg(Z!=z+Q2CK~b}K
zBQBUwm_K1O+GmEQ0Hb(~e>X%IHaC_;8ST=735`W&y{E8cLO$y0o{I~p(-7nP!PQ^*
zc9w#yEK=dUiSTRyKUlKEh(HFxF&mCISfEsq8@LOw3N^t3F#YLhC5bZtrU38%6e=^4
zeemr+-M!?s44f+$OsTA#qNCL^lQ}Z871bB88i!UcwiOz>c`@ikp>EN=c$;5Yg_P(`
zfsWeL-Mxw2hn9G3HV?U@oB#IX+S#h;=*lTmDpL{!CY>^8*P)p5m3mE8&J;95s}TlY
zTMS;fQHA(l4Bz0uQtlKRH?9huzysS)$fMZ8`-#2{yaUmoKgNL{8tPq;=w4uEWL|0#
z!yEFZz$<V`0+y2Cf#Exk9-=KVCZ<eZcInFK;BVyr3hyWU$cG(IPk3egTW6`=25|N0
z0>|+dG%$Q0PYFK?|G^mQua@xpm=_>(LJ3jEWE}Az77!VOKU6eQt40nX^76r|3cU!(
z10O8^THe5wsh%hYv&kzr8e)FGOh@yA_?e-JpUgi0b$9&%^bfp-dNj_ag5q8>r6xMC
z3)?!-r|8q6;@={F$o$oq{cGN@QNO8t-w`<k<A})N{lbVrmsZ10oMi66IEWvX#5hB+
zC~>xPi$afB0J0FgUoLm>4ju6-hic@${Agy2uB7$5whOKAwf=)X*&3Lqbo=Dg;;4*t
zE&l!A;XiKPoB48<hTT7jy-SElA(7QWPzsO^a%(|gungfq!zww1D}!FArNhf`Z58<P
z%WVQB?=HcpXq`e3{9Ew2QLm4ViOft(M`o(<Gl9<8{cX>i-S75P?_`eP+?ZVSQf#17
zW-&^52M;M!I%>Aj7NZhNM(@cn>+nA=6<jj@oPEi7$@jhKk~-yESR06ezdDtl&#nlM
zljJV4;QZ%&+SivxY3D;K%5bo(-o`nqIUg$^5kEhG(cS9YTy>zzn3ZQjM_DGYTL5ux
zUFRf_!Jj6CZeaM>H&edoxy%~g#7Q~o;C6LxiIEy@Dnbvl=-b%BBauEP!Rr3IW#~Q>
zaW#St25IsP@Tv#VbPRF^e<1e$hyWBef}{)-1sn1V<OR!r9%uWnf~rEjs1HUTuk{gY
zHx1@8KJo0j2`!WK1`=uktIplIS0qxK`z(~U7aw{<3@x0v=a>N4wjn5zxHBo3J?yUl
zPrP9zpQ!qrqQWT!oa#=r1M-5LgxLPz+HfxJnd}P4rU29sh!-a><6&GxttSVOOTcR~
zRJfK~3vM$qR?c(Bz2JrlTFkHk5A+|f1%mZ}xV49AmOOJ6CpCPxhY++4JO$wLBMFBf
z$iUwXAsyUBU|C=+;B$kP<9|89@X5g6N{)d9OtO41UKl0<&knIz0DE@wk9id_eC=C{
zpe&|Knc}X^GV^6B2qG3QOi$@+DAs6PqY{%vN%6EY*`!S!r>d%(X+=z8WK4Og8MFYg
zP=aFPr=+AnvjrN7Zp0t(tuCzqfkL}p9M2^4AK?r1k!qy@iIc^hHUyQ}!BB0;@Ji!^
z{7h7vFZ0XP1zNKn9P&!BoD%rtq6BTLOP454idPvJ6RS6CGI`K$&@U@?*eDM#c@yjb
z`MgT4NGC23i{;?|R*SSriP{pmSuQcG77CD6Dj%aWJKdAg`|v|m*8Ea*3F&S^)+I4X
z!EAxt6uE@@;{jS8_;FlnibZ0Jjupg2qGnlKM{wE$uAAL`>66?}a}-?|_;Jc?t!*vR
z$3nwamT#*`8jtFN2dPGZJh+?@Pzxx34y}`^9>VXR@?{`u+N=ysVuGoWMZLYfQBfHX
zitVLUa#2=NZ!euM*Z7?oVA;1)sk2NLs{q(mmIWOO$VJ)O$R3Hmn->LwQYbW~3dYj0
z(R_tc1-6@fp-@pULEfnG3n+~(gOZq}e7-cXMMDXaHGF5HJT<9EDjlU7<ZB$79102a
zdZUnK_)>ZYV#UscF_IpMq&_$Nhb}}$>Qa+&S#Iw1!u#~;eTCC=a~;8%DOEOUo?D#2
zOnc2yeeavYhm+@E9<{Iih%p!cu$M`Uja5O$&sToSfH)NbpMWPv^6zHFU@ff!+r~tQ
z{{C}RCdVfU71%@MMas|+Q5_~W&O1eDhscsJX@OQjXc*ErfPMKunFlMkiv%`V;%J~Y
z_ylkmLG=t$nuw!JJ@aOT-&Zlp?W&>PvzSc!mV)xa`{OM47a1CODJG9im2Es#yy(z=
zk0~ur_WD_|qPw-yANO{{p>dvsL|Ytc;U`wcl?GqO_wGUEa`cn}uZjFIk)OQ3w(bs_
z5l3LRXB+-LYD#};!tG;98ko)g@-m;hwkBXQiy%p&Fm3trSl|nhj=1G#A6c3$l2XPr
zUF?F{6*5|>Xtw1gB|8!sGY=0L&}seSc(YpYJ^q@vXc4j^Y1HUNgNs1c6I)RQ{{(#@
zq8q%Zb08|?NW|a3`~L>4C=V(*0DFTH&0NI=vO1vWdSMlTwUDle@pf*>V4dMV#Jb=S
z^1%FD<ujHLKX5=WcXBGS&m9LmVff|-2}-tL4iMQSe^E=a5$$erZWHqBAf64%1Co=H
zEm-&l#?0YuSh(*gDBr}70nSnGyc}Q%*M@-t$l$bO4B+;F*a97&f5MUJDrJ>XjvWRF
zORM%~XUBR{tdLLboFVC^eN?ehA)8zslM^{d>XuqG)G~ihdTuxMB+C~e`I6a;08LUy
zYt-({TPOwNsF6Ezig<-al~^oOCXeBDKZ<;I^|_U49)mtrs5J%e;m41o5|YKS4K2|!
zl%x=7Bdrcmyi}+Be>nRN@TRV8UGG!Xd+%McCEK!ON$v&riowQU(=o;L7D@sE0)Y@h
zF`=Z8LP9E}kY0e)NtsOgB$+$Oq?bvZlt}|io459noshZr-S2(RvZSNa&)#dVy~@AV
zGJ7hgh!`YR+i8^y(p)h-kMKNwo>@D<(Da$Bi|P_fFU%JQ#A1y`RQy4^BrKz8jkkFy
zx7%2-diegeV2O#+fOvE3EOgjI>CI-EZ7o75%r?3p%b(MywXiIQI;`~tof~Ps=k`v!
zC)hzt19rPq8$~EOYnjnwW9@#6#Uqi2*&i;zpS||=vE>|F#L8uQzm$5?T&H%6<MP5}
zgM{h3t<TwGaLZNhf?|VAOBoCfCTORCr*Z}}YnEs{S`mKg>)Os>Nj0R4qj<^?F@~Uw
zvZEr1esrmPM3#b_Uw99H7dso|$zss7x*?)qIYbof&$$tD)I1@0=l=?|{)mVE<D7ry
ze3kPpSl@pE`}<j;28I-zQ(CC_X+=)J&IN%43kg0IlDSr+I@E;P&{#0wO@u6m(_ucJ
z2fqBJP;qJvT8B2GE$9+-8QO#Pp)1fKbUpa?Z$U@VU6B0n6yY7fD~LEtUO;hzpN)`D
z{Pz!-!}u(u1sDaHYQgS4LYgqM0>wcd2BHom^<Glynum~E_?g{>U{PQXVS9Ef*!1CG
zAnQLKTLkMs)(}>bTDl{S8;}CBXeMwC!W|JSKG_CWBg_j3e^i+Ox+gQTfGmLWx<tqt
zeUGjazF|F?`bU?IWM5K_7v5yOunga1HYdlAehcRsIj<4w^$NdXdm-{V(K)|I_xtUd
zBgc$hWAyysV1U!Wb;)%`zDKVme8alY?_h!-y<Kv8826<0p*0NrUCFY(VP*27vW|Gs
z`o3wg?U%&IhK9CB$JSi1JvMDxWm#;3S+ibQa78lLkI(SIt>uAItwa&I@VuxJ-xXsO
z&DtU(iWE&67mq4)H{6epMPOA-pI_8dHK5=b_4TU@RQR4aFIijA#n}pD?BuIvxJ;pN
z!&SIk>zI4xgt{wmrOiEarb8=Ljw^^wkh1jZmWs-bL(zH+F^0T}V>l%z1^~h;ZVk_H
zE4lUX>r#FPycvEMyti`TTjAEiek)-w2`?4)7Qq%LZ(%sb25UcqOnC-)TY0gtmEl+N
z*|Ra+22KpeZW}q<W}c;aW*z)mA)IqL@Xzcy!KVplVt5Z{<H$LgL8(FGw>N0pjrELd
zN<-W5Qf6p)8M9Z@SU0YJ-$LQ9xnb7Iq^fG)@^EeG+A7N)bD%k}xWh88#W*jtdy>6N
z(UhFJD0qv?=}=8BtF12Uwrsby@c!#I<y8*^*5)Jm#FEPKm5$=6wzVzh`Oz(loRN7^
zR?n8_w;#Wx&^sf)DPHn-%kn_^>ctK7Kb+;uEAua^bVn*`qWVP@ovjt?nzq99>i1We
zd5c8^&|tm(+G*47QlB_<=pp!Ju{^zf`w5Gs@X!Z#*D?OV2S0E>{wVy>55XUE-+j!n
zW49hL9zCkux6gC&#RbL1)BS#9etytyryUNF#bVdrFn8{~YTJ<$27|#;zVltj%SVnd
zci;WF`{f58{KWtJxgNUj?z@j2F&sZ;yy6Pa&Ygj_wl11y6&2uh0X-38>Kpb5$RtY8
z5`%!;hHMXz<rR$RptFKa2uuO$bFsT5Hf=OU_S|Kfgyh4F6^~Kh=*5|<jYevU$`sB#
zL1``@Sa9*qIWza}8l1oNl6eD{?-`i0^OAXUhOQD-Xq4rQH4*<Brc!PJV=<n-k!v`8
zf=vwUxpd*29YdL&gO_fbKX2DiX7lWQ`{vHuwU?Qy4uus2P-TRBzmwn1eg(R=Mc~cV
zIqiT`zA@)G_$+=$PQ9J;Ud~53pXGd+^RJxmbABRxlL%JC`bGE<DKrV7*;EpW6B`8X
z1qu)0PQWln1TeB2;bd`g(0?95cv|)dXr(a9Hi^LJ2$(#(KpG76Z3t11Lzu^i0~}Dh
zafsoCHKQ<JxFW2Aixa+i?zPXc(DJ}Vz<2<WPH`yqDZEDwZ@@+Y9I8gJnkYi-Z@U1x
z9aPrcsv$-sqBv#;Yc}e)BUZ&Y*UB@Gs_okVc)NoYi{%?6M!D!RMvYnVQMriQEjJsT
z8%B40M9e$30X}w{l-sW5?sZo}W#jd{E&X3J9v7MJ<uwNW_!fFeZ)N$!`SWSt0=l4j
zN?G}&B^Tc%Hl1E8qK7D>Oth0xv8&6&k;=0C{Bm?RTD^PO=AX7Hw*9o*u<iRD8C(^P
zl+7-zV4Cm1?VJC#5r26%dT84Z+cew0-=<lER^GwBF69eFdWNI&@sIjau+lOy_N1;v
zBg?1Q+Y~GxhC<^^!MzeTCNd{}-{n3j>{293U%{KwcYu8yF($e%ebh~{M!H|mqpx`L
zG}@3qx2m_Ve0J10Z3?4T^+e11`^uO3jML5H_Z18k6;7QB*HlOH%gg@}jbiT?U!c8s
z>FAsKjBFb$J^fc&mHv+9VavPGX#406&kjFM)(bJdPw;QB5kMK6APPMW7>PN686Scy
zna6V8%=sK7h@X*KnBT!>k|-8tORY{YO%xNz9t~tgXhtAYf;WSNtO8Ln5bY~inuz##
z&I@FMQTf%7b$<#*AUK0tDE2E{Mi>ojLPrtlbreoP=6X<lf$HH5u))jmV9SC@3?ei1
zK;S~MMo>NIEaH}sJ4m)8^E@H-kwXo}tWPK&gK||6=`RT5ATR(F7G#p3fbSCo2xAg3
zhv$gTM5qwt6vA`(Z5%#pa5{bkTxO>Qzb4juP_eqx&Hmzaa%beKGrdmwY>q^wlLFpG
z!CX09W>(t6;4`8CHYT=lo+&Symz7$y!4KmsOh%m2U9KN)&`R-Z7CQ=gyqp-IcW#vo
zvv&F!HK(fRyshSN`Gl|%0C8#r92+pcUaPG_8!9k+sF`Yw0!&X{>iMyOE1icWY@tEv
zRfvoS)a{M_KBpMv>Kk*VjzYKF5z#vx;<7~%sQhklT9lIgPZ-p0PKn>Ij_DO)qtPHi
zPLVPQ=q(Y$C{(o3tn`FD6)Y=~JQ7yguCZZbz$y01RM_Ib#;OWlCsWem+#?bw0dBuZ
zccz^x*Xre*h@u(g-q$^sPt%uOA7WWv(F6u|_cfbwhO%f?RIbbx^5Vlvk@RM-Mk&4i
zulWqJ>^eGOX<o$@$)3i>kDH@~$z)*^IjcP7nRn5C+9@$A@EpizGYegp%i<w=|H7oT
zRW4?ge-SO4x6Zd;tksAYw)i<!S7~XuJy0m2@mJA2Z;egDy#zTZ^$}Zj>$H>ZEu~7E
zPNh=aq>*>C5&#uAo#PD+y&AV~eWPb8$=d}sFLr?AU_?N+A0pX;#ZV2V9zrPuwgtH{
zfev`TnjNSP=k3p2|H3@oMNdC-DKFb|GmXsDEKgYTOs0}~1uAn(e76nH)CPMJF;8I;
z%YEE>n@AxwJ&v~$9UR}x+|Q=LF3Q84r_V9N)gbIgnC0MmbfyD_57f=vKYSfCt1Dei
zi!ygo-I;g7c6+$F8NH6X@y-0iUr%!npKhjaqx#a%K+LGU>1&8}ZzVbd4K_v<_cnV2
zcx$YJ<yDshqr#P=h8SdFFlMWy!01vzv;r7O-L4$&ZT#Uk*I$Ki!#eam8u#22udQB-
z55ALm>fjyo7v9C3y>A%*4K#{ebT8G5@swF((7(|nsG9fF{1s3B3DqC%ops0Yr_bj6
z9sM0?pH9<vqr1rSo~`Fx5StPJi^HUxDLFHUFG3i>MEey6D6zkdG&7ldAXOn5?Rwe^
zktVQ@Ah8STg`gJ;(!W8_SOuA1SR%G{g2jP1n3y?NkKS66T%!eCc>$+i++!?(jD|g1
z?+TX~E(j?e?xyJ#?Tg2Dhwogxy0&SR%V03?I<Oq_rj#X*)bAE6@*eK#d8E7h<nXOb
z-y-TAts}6^uN75|(Nwf{4;lj{p~Dx)7OBn;OEY#fo+_?sSlC@AnKtM4jSE&f;t^Kf
zc53-GvSQ7u!W+-C$}{X+<WKO;;%oQ^*|X5^TIiJ;up5kGum5{&IFBGl5J$Sp1<9?7
z1zQ2(W~8yQBq=nKju#Ym(ptod`N!tUsyY8-gZ<uK!8nO><R8rZ6*6OO&b&aypeEf$
zDscqI@e}y{7n%0E@cYBZ??kVm8e~CqSzBl#(5c<7zeFGAY=)-p>L#<uEt+DHUQ|a@
z?bS_*QvH&;P8B!D%sJ>vow2V;5|ZTlm&Inwf)|yRUQ|<a$pshSw=##&eN-o2pLt!l
z<OV8{c^O{_7kTB*;rrgek1!pdLh}44aDwhe(#k5Qgt6Of@l`TKo+Cdt)*0p7TrB=v
ztyah*pi_iE=`NpVZn8{?ORQGsn5JH_S6bqmUT?>@+<o`mYuDU)7mN!BjKABtWspZs
z3jP`5of-?Mf>|RuE=V?nbMstW4l^P_!`~>NPw&dPSI8j!7~v0D+66*2Xh94@UM*>T
zAX0zUqQdI^(ColCfUZfO5QEO>EN0O15G5W2K)1UZ0SbX6;}bpwN+!E$L4o7p4R#**
z)(Z+INK{64WSNF#P#%q7cqhv0$g-fgf{L$?gMkRPK_WOn7Q%7DIzicleF3XxWOvSL
zY#kVEXqx#+k9I$P#khwu+Y9TlnZ96JSs}t}aEY-YD)nj;v}3trcGK0`>IsVSsKKIv
zYN9)1H{z8y6muO6wS(&XoE6I*=I&=!x)&D}!_MlM)aPD1Nj6^6C2OC0aEEB~s#Wc>
zCj9diauixTV_B1|_S-G;26?XvT`{Ts!X@%XS(g(1y;@%RR-f$YhLT}<n+DxfCQst$
zWDTmv>t$C(y{F_=%A2F|n5<0A#u{f2v^LCNkp4K`LCwzGM8B%gjA<J0i0sw{Z{M+r
z(f(S~k(|KrTHmEJHrX_c9b%QG2w%dbpP*~FfJCd6pgxg`QP35NK!0bQPgfWY;KzES
z6W@h*v=_;Hdmrj8g71kFFX`>YPxZp*wuuw73$R{6R!$^eupvtJxnv^z0c}A{(Aiq<
zS@xlk@g0Ob0>yw^nFx^<3xQ_HP!{;FE5{!Y7JuWsf1oEmWe5_=A*2MvB?aP2{V&u6
zRQDegRE4-_u^AtOmmPfs>H8<5Pw}m<;IE;|ZqEZO^T_ZouOb~PK*uwWS49e|>%#e!
zdynig%z8}g%Ed2GamDhaZ0eKB<`wvmGVI`uG7r)=X>0Ol$wCQHz^PEl6bfl2%}Lby
z!u2is2B#Y~i`{&LS`XK>pwG|*xaz0a_Syq@JY4kKSJ8(^|Jv{`kD|M&On!BBVYsdi
z2dUj1Z$DP1xAx09{AlKO$SkoLeY4_*+^9Q6Gcx1E%5fSgrBUk4Q2v6IKpGUk*i;(J
zGs+!cfzA5S7I5p>E1|tjFpd}ev5iMEY>-w58xsglFcitGE{KSba6pg;iLXWwU5WdR
zs87VG`rC`doq!}N916ZIubvpQN2VTb9Zup0@dG%C{sLhzt>}g2_&od>hD3{CF|#Ar
zGfzY9hwq#Umo+R8H?}9`E!W%+rVL}_t!lZnz=gJ1AP``PnJDKuN&SqTNk&=E!P;9>
zc1_(0WtlwQopkI>?xrq+YsAruV5Dn9FXCbdPqU&Syc90;5nlS2=dU}aaE9w-;iO_N
zq7>uQvHV`MLF)<^S`<lotSeGkL9u*AO<y5<(bC#ITkO%Ode2<?$jyKT66R(lx1XH>
z?UxI)Gs$uG2P&mOE)ZZph6Lz|=d>TBe{$u30O8^}h#&-jy;n$RMkez=HmEli)I(Ss
zX+c5cCOmPZ{j%~0Y1Al8WZZrn#rNR*a2`xEUGRFX_boiL`-GR1iSU;;gWVQU<~MeZ
zx%s<KU=BKr-+KCW{LjDs?eHndE$bpG5n6h?S|JTN&|!n;B2AyUoke9Al~<)?yr(mj
z@&x>w%MRlAy(L<g_wmRWA5{Y7SA*yur~{;zzu{bb50bu#n^(5VqE70)YmB*(F^Wj_
z{g0qK=$7rz{{?^k<vUM90T4NqT#>G>?zb4Uj>5RH15!rSnle8xE4xfAW^@y)szSHE
zgYH;lG^_Uw+67Gd+1L4_%zDV0M51tS2JPyeoJYVi@B;V=zJRtSw8#^SJS+%m3p5Uq
ze+XzM36Mk5peU=Az-p3ok|^b5E%AcF<O8G{*9toe<eSx1iiq%vh<_7yf{ns%<h0}}
zf~EBLsff_J&@+VQ$>|E=B9LX8bQH%r!0tfY3v|2~jIa=d7=*3JkV+b%%fZwFwp_BK
zv6$eoiOV3Hi*ZCu8BwuFfAdFau}Dpc{_FD9j|3$bnbgp&qGj@Yy;+qs;`_MbByW-{
zoX&!4x(>WCrGF2S%GA!PI;~_ytU#-@7FYm}XwhiUK9<YN4{_1lW_MYwMHli|SslxH
zN;<sJu10%xL!I9)Mk{9BHMb@Zs4($zD!6)2i;0@1>fWhvDe=4J8wWPtn|al$UzCr!
zMfhjt0A5T(DHfMpGRT-2kqsvnD}wpOn7z$e<H>VdPqbWKPzixB3Ps9M-ZA~YO-rvw
z>mXk;_&N6e^|IxZ#T8*hdOZZ>*{N_|C<?CTF^rh6Z7{Shsx;GedDU%i9oRE4!zdQ(
zRT>ovI$8{scBP`2g&1tHPFoWW<ELfwmrWHLbP5;4Afwu(Q!{O1B_ORdVr^Nnyr4i{
zaBFcq-T~fNlj*vKIVH{(OSRk}s++drIJ(25$1kqALnJBGsUAfMnGxRzfmz2OL${gf
zUAG{&(_de}S&>Gn`^r(1!k@|vjF^RDMY_S+c6;F9gpJ2H5?%_q>CWbJC)q>53zm-L
ze!CGU^*{MR0AM-L`GltQS#lCEgh4~xPbd<QR)i|E@iIV-@MDDVKmr<(^2y54U{tae
zj>`tP!54zyJRm`cq=D2LVw7dXa2-HL)11B-&P6UNm>P^J<EVH%LaxMAA+Tq1PJzw|
z>2W8q1K$Z%eVpiB&{ig)cNah<rw{)5@T<z%-dwRv5m#tbHkq_of*7X5FH@|8H9Do%
zSs<47*EI|rJmk@+&HZH+>n3(O7g0<wA~({;elJfYCwN;OPIp7K%YmM{DRajwhu?~_
z(Wz0kkWyd-=@}$knMZArP_ma*WB1RUclrK-&JvpmfBF`<P#lQD)k%#-5-Akt=5iX&
z?6im)5);<0?whohnhp1BM<1gexZn4&8$XI1FTb$!Zz{ITpq42tR#qty)w329Q7Kdk
zy-3EGImMjZg9C?JRBjQN^(U?iZ9(B&jnPXptTxhPpRH3n2D%3uasKz{=<SIFo#=yi
z<|FWc70@EK%%PS>kR~jlcNWjxyLaxumANej6#f)4&3uU4s2$z$6nNePxdrm_LT~WG
z36oZ@%-U|#Jk17yW{iL~?E&2m3Ui(-%lvT}SOt+(vb{)zWkIteBmiAM(y{P^P>=y6
z&2tYP_0*6a^^=(hxFT7mFYZc~wRe^jkEb_2e(@y_o!q?bROXOOJ+Zu8+&QK)=(9j5
zpEqBvA6Hg3*wMb$>@W8YZHd_cC#L>D%HzZ%muz|Lv8`K9(63%RecINo)23}5e)Hn#
zGq!A-I&CX+U9zL4tYloz@VqT29=T-m<EPM74z;N=H`lOux;;>4(C#QKsP*^_){;>0
zP`r3-rQel5d$L`nlH$iL>dZ@*JalTy){~EKp1yg@v}s#}_l&8Vx4?KKcJG%tAG;sg
zE^h?y-v7t8(`K!?*@np)Z%LX4Li_@j?DwJYhn5;O#*)@KcbWONvn1KpUQ*iHn9`h;
znkrp2RgUlQNtelx44{Li`fnfEvhk6JwrqYlee2_!wmkI2`c0>(UoM>5zjbT>lnv=y
zHcsx_dQsnu4Xn1Lvn!cuZO()=$+J1Ev8dRI1{|dixgG9cX_0aG+bxfr*tq573G~*c
zlP9*Uf9zx?JZ0U5{r#6*Ox-(W%eKD0i!LDcmSy;Q=4JLZc>ZO7eC|;QFim=yfQo=<
zey0?HjSwp!mxXhYsW5BV8~qZ<hs<k)(1fzJg1St|%?ngR!fCYzYQ@+@Vr*wJ)j>_6
zmeZ=L&ST(9p3LaRip`89Hb*9xNsXnn^TO#$U4aCDuRxG)&Ty@<NXjY14mbgyYqR=v
zp<UCbI~@@Ch5#*R;FL0pS|etpt&}k(VgFIgj!krqO(fgePS2$Is*8`KUVcCt!^cw-
zc!|`cmHU#B$cA5JW#0tc2O>?9m8e24<DGNm4!yK8w9H-w)1*|QC=ca=Y24ZI{di>|
z#hMNr(TOAsr<wbMQj_VsG0VHP+{*$j>7Zgo2y&~AA$FE?H4c#F2=7Ko2;t2d70#s}
zPzrhD2n36`NkIY;STiZBC3HZx6S5OKw0M>=8@QLT1*}E4LZPUS!F@axeYo(wxA8x|
ze3X9Y=5#vncQCMf5R0FIsH&2b&zC~Ba$7T#i+{0=3D0Y7!I$Y*wy7aW(qc7e{d+C(
zd-5bUg;8e_xoV*tpeE=7+*ggm<1kY_a2X@|67|7lKE`$sgFUalxO+JLJ${%Gzlr~e
z-^ESLJ-%4n>r16FUw^@0iS+p~pZ_Y_AN3o2_By#Xnz>ZvLI)x;m#esMjag<<*fy@t
zEvSga<HeQ5rPDiMSPJ&JW9(spE{&l1AI*8-KdEzsQNc_DjYDNcE&xmj>@2Hc=(CLn
zq^cj8nxI9EP#g$?M1lBVUm6HF5CmySLu@v%HQT;G%9LOQCxe%8LE%Lh<jCvX)dcEc
z09;#85X_Cj9sqk4ie!RUotZhQtZaNwdCA1giPq9Y$GGBTD}C`$iOQ_khbF{JI>$~>
zN@%&>qq2FXP*Pqev9^^;U51jpJUODBp^{}xtD}6sKDTC5%RsZnyGU+Xp^(Uwl(M#<
zK&K7`3vxpSt{$?uva)=cD&&{x^j6;Q&owHXZVi*-Y`S8xzs#ans~q;Qf)jC}3#xgs
zI3(6m5>aN*AaP063IkhLHeo_pd3P^<r=+>PxOm*y%!N)j{;|MaoEw^W%xBuQ>*mXt
zs@aFm(qgIY+ZzXC9dF3OcWFIJrBtf7Aju7KgZLGZ8qe1252En!3s9TtSs9N?tL$>h
z5v25aHk;Jq^F`Wj2}s%?9^Irgm$fNmGKE94YQ2-ILY6#juFsoDbXvr-MdDh?4E_a*
zmiZln;%dHK4q(bS&;{XF_t8rPx=8(zB7jd5nFKssWFe8Qy+Rg&SCf@w9q~dCrcG__
zNtO2YmX>#YQKm5z`zj2RdAU+lA`LhLzV^;B)eUH<Xbsz#>K<2GI=(C20da!{bj$EU
zeXxbPMl8-uloY`kneDi>xP+qX%S%@m3HNqC{k(8*4S&2h;+p}!2f{gUEa6^$yHVlp
z0x4}^R4azTO&BTMCs3V+Iyx~`I$=U-c{g$-b9E32UKe_pR$V_%od_3dY&Or3o;kwn
zDJoK>_f(fAeR=s26fB5_Rh!uc;r6@7rSGc_s)o4t>C6U+IrDuYS4~MWKdD1<m5EXq
z6x3!KJ^WW!z3s*4Cc6Fkp(wr>#@{l$R<wYV!@SS{5qJ{-S@j<h#sBXUohwd&MRhdc
z;Qv#<@omr=Jw2o~oXNcZxixO$4bU2udhZ`vW6K%qXqTg3$Bo0^|8M>N|J`sGQO}ID
z`LDn72Zo;%$mZtZ#rk0Lxny$*Zu^~Vz(+6}Kgld-o`JkklXI4nb|!pCP!x%zA%r9n
zfdg0_;BK?_&FmBaa=w7p;lN)^gnlS?BpgeG6#~A|W%mYIB`eK=Fvr6d;xi;G$gxC#
z(?ceMOGGxaPJwTc8mu%^IuvKj^R2s?19UXb$#smnexj@XJYQb!O*`cECWUl?%h)_l
z&hZwlr^~3-RfvrFs$@)Q!a4RTQEz+kc1u9sRX35AS(k2=_@@@@R8mFDgyx+w)|uOS
zvCKl3R%raGS|6|LT3sKii{?iPHv8@AYaBsaYd1LA4AN#a-D!52&28)$Mpj&C@Zvw&
zCU;f#6m1Z-$y?}Nt!*|f;Q#Or{wa1?$jvkea_=UHwK^qKClFd<WY&cF0Uj1|p%89B
zWEDXt7nX(JBkKg_EiimC_~L|z2#Dx-vJw&JKKNW=z93Fduum1ir(10lq6dV0LD>-u
zeMgcs!dW0r5kwy^DI^wW3BXDiGG4GWz^y<Rkvw(TsfB`L3}hdG00g5@IVu?(>BmCA
zDZ;DBz&~XZYosPd$=RrX?CmJ0hA(#-r4pM}tdr=TtWk><;0qYDFtU5qSE@X}eyUsP
zF&8pHgT$E+6|@bsr$9vQGlUSWlVu(eneAXSac4fh8I@(e$Xlr^zNq_`tHo35yp41U
zay2RTSVD%%v<FnIXYwq?s3U5TFvk@fr_IYBpRNV)fPK;U?vNtr6w%)`YE)6<LPO)2
zWZc@-tJ*X0r^4!mQg#z0Lg2o@g)8=`l}L_lTBd_p5HU(qB?_~-=|PdGd(ajGpoK1`
z6*)t?0=-zJ)I!2tg+ec-Lg-!Eyv)cO^Uc%jcCJz5)u>WhPp0fM>bu_F%r>v9$z@d|
zxk=?Ng6hBPCt0IXv4xiC&gbdx8IfDurM2l|2+mnt8Vcg4HMTMptt!=M#VHr6EHBF~
z45&nE4W%%as{EB4@zdcUpd$=^z?DElf=x)6E@Fb~Q5cWeFgk!_&=9%D6WKTWBC-eQ
z(#51pfjUNLsd#jt5`7z}$P3m~=t+VuF%suHAoUV(STYVskSuNa1tT*Zw<7q57^!*x
zj909kR$-2Gmv)I6Ufdn8s->^A=#YfAeJB!1LeA7UNuf!SU%}>5>8+5_qpDMEW}`Kh
zC_N{ihFszqMpg-7Ypma}T2rX=i=~{2qs4MFi#{}*`E136S<}a_?;SsD?949u1sBTO
z*g4fX$J177jzs-Mb<TUj+RUd@Z&KT8YsN;rzN9!WQK8^cim?_(BeIx`cBtjRRI9_~
zp4vJ{^yID6&Q!6qQEgD0#LMgP4fSi$PrRa%<0y}qZPdzf=5e$iFQRH8rSO&Hos*-1
zcK?d$V>=-(B?4CZ8X;5j3?Y-jX2@}V5M;kwa_)x_{i1;B9RWWO=0%1@H2`Tw48<`5
zb|ioZ(gCmtK4LQE1JeY=gs_sVBNH)fCqm;nYYEyX%Ml5>XLR`wyZm+_IU6~_xqFh0
z*>%}(NKbsuX-1C#S|@AC?Fr0Ru)H#TdFc+NH7G8Xa=sa}XUS(Ms=B+{-Mn1Ec0Uz!
z=u}>fO{;o1nusQTh}m`OxJ#?RGZI=)8A#D@71_j=xI=8fUl+s~ktdFalv;aKp>b*)
z)MIg*Mp@vJ88YuCwBC~V=kbEv5?rT;=u3shQG{O2FNw$SH_2$C=m!HUw?It?i`M&b
zNnx?pg+EqlZCbz%$*qud<lx+g9+^%z#=R<^h(goHj^p_kUu2cq_NH!xe~3pzUbVe2
zkXtuz3_cLe54aPBKBPb2rdj9894k^q$_w;~zqj>;rIyp4KtbH^EpVl`#iKz_kv@Qa
zm~Ypfk1wqqKjoLgs6OiR=4U2XFRJ|O;xY4-lJO#a+!=~G@Tv1#W;k?iSky|p#Ciw)
zU$@^*^aN2(30}ZI5BWy45XDm>RF^%G^LN0`5NSoI6)KEKh~gj<9Sc5f7?uLgDs|3^
zkx^StjJ(k8qXU~Kb!C8s0|*AlgM{mic54ctE2A$$IYRmjAh6#cGI5|yt|&`uMz|(W
zoDrxJ3}-y#>;(kwAMGkA0j1<2!G;lT0OoOGFd)Dh0rMiv5n154FmaIpcu1P1hr5K7
z4Ui%()7zLE4hF+BTP4j$@x50B!l9m76Pj+rC$9>5<n^gd9yQx^l$n~S6Kh&3i#1v!
zqM9NTXHGGuhm7^|MH3@U6f$Zx#g#1@aa|%DEW9va^j0hmqr60-%j0X0#r_={L(2{M
zvA9-iFtErbu{fk$Zf9XId?vD}t82xIuC7JQ9$%G~Dp#oTmMM@mX+FKeoGh-8>gubU
zA~Ul?rSiF*u1LAjU_Nt&N>NT}b4x{vWqAzMvBlZZv9Kl*j@EWwqUxVA?NIOW?gcd~
zTVwMZ`nDTq56-@4%8jjEZ8cLoWzm+MP1?!*)AnVGN-b`s^WT3lF`$G~Hcc=!ArJ}$
z>J@Y<sIgHRj$urH`L|Q)wv^_(9Ti&J!epYOJ(+Yi>_t&Syp3|H{2GT<;-ctNMz6z-
zwstLE+|{*Y$*`Q0x%>*T*=F`qKbkxqlin3jIX-;_{0^LA?aGx~+)z3((+u0i3cu3M
zfgHk)&>;t2#wj3$>;}FyBFBvq(|?jumZ*RgjM5SL7Pt^Vw?OcK;~<F`?@tlBF=kl?
zsdWQ{L$(SO1H1oDGFiFgT%s{}|2x@0XxIqd@XsfKZHFReyN8ej-8f1TQ)W(#G}443
zJa%&=<Py~-fhM@1Td5N3s+vSWGoEP9?T<%%bs??ASCs%Vz*nla`(sczzVdexu$u`D
znC<a$xu&7YMRN|o91=2cInO17yb?kNXo&P@>E6SowQAC%v{fC-_UMFENNuG_f2wOs
z5AQ7<=~4Qq(#eRorVbdxXTqj{e4koW;Y;^A+|+*^)}FqQlRNzYWgO{5jY_3~3Cp8*
zeDabCK~_q|`OuH9-}+I^`c*dQND{Ys0ec6`M-0qOZot7-Kz*DX1oJw8I0dc_5&Ga_
zaccprLF%rIbPS{*f$Vh<-zn^q?Mmo3157^vATsKi*YRva0s3HhNTu(e#kfngL3Hr#
zOa~>!Q`bLSIajRl7Z3l`_Y>-*^|-QVN@IQA(8VENo;mMVZ|Wu}SO4v+%q!s@d?YxH
zLQ5y}$Q(cO(=+pL`>uDrDCs|b?Jjf*)0q=!SNZxyOXtP%9p?PEk!=xLy7m{sC&_bt
z$eEc}K++-46@%w$B+o@2Yh+d;&lUgA=L!l>G`a`CuSUW~A+X3VsM`e1%Fe_$m7#;)
zg0YR`QJ}C`hT0#_JOp=i?HyAKdLeYI;0=69+d)@TzzmZhv+UoFqzR|=Wz^ivWs_~W
zLGuh|a2|fw8cKB6Nu@khGkoe;_ZJt8nafA*&Depural@T>&Y`XUED4d&y<)VMY;tn
zq&)w#B^v{D_G0iq&l2kS<N}V8<eI(!vMxYGBxfWkGgH9Sp<@7*3ta*M>1vQ362*eT
z1abm&QcCdW3D#ZENxcC1f=?ozk(v73I12bF>@RdXY!J2^0B2iFMl2*@PXG!SLJssP
zxLOtvY^0CnGEAM;-sz;o4zbF#W{o9*&u0EqkP`Rp2hE?S5#*;dWp=DL#iIH1nZ@7U
zk&)i<jfAE0)vb-{PEAv#v0K_%Wf*H1GY-kjCW~633)L9MQjDRZ#%u^>7H?~i7UX$l
z{(^3f<wekjA}MQ(6;0=<R&#onB%ha3n~E)&SEvn?EY-+Ka}7y`&Rke+Mt^Zvq_;v9
zA~|GBm+gVHUgJB+Uo(U96xw!LQr1XO|1Nh^;=CZf@}JC#)&G0|vdTyxIWELrovmTM
zX1jo<NUU!@%)jG=Y?eS*fTR;_FHw-az=#QQ4|x;*=7uIDapl=O0VMAm>?!mN!I}Y*
z6vSm=z7&jXFy{)W&(Z!NQ!NxX0TZ$vF<%eQWv<RYfAYqf{Dk;9rLJG9^!H1-Rx7oo
zc5BZD)$j+5+NlN$SwT>_BHV3O{|y_bP~&AqGHI?9N(Y(1RF?U8u`JIcwv4f%tJIIG
zP=c|Zd8&Wy`JfFK#0y$Esei|X;Bme_JriHAwuQq~TvbR-_nC~DpQvdv$ObWvrR~)U
zs1BF8rdW>NkVF|7D(6%x3D~E=CiL0a4|of^8lu2mfVd-LjRakTKba5~NvsvjvUA|u
zVDjNDr4^Hh7foIjrW~DHwscaC@STl#>GV{|biAzbI{Lcno|-bIe%qAJ7W&GqThoIr
zZ56Ai!-o%NW~?rU_<rb#m(Hpo@@x&*Z3wpQKWxuAg6SFXY<hrW#P~S&2<Q|KdJm8y
z6VQ8G2%_Qalk^L>;M3`{eP}Oo{)?)IeSX`690Bo5dv8uBpTr;0&z|@eJX1@7TfTHw
zGjd%c;2eYh{mP@5n{(|y(B1C;eiz&DazIslgqNWq@XtBWp3Ly<`uf@A?Zn?8t#C(P
za3c!$EZmU;z!=MfgO;N`)Sv45`|IF6d><_%eX#SamtM-whs^X%a9_XiJJJJLX)l<9
zO7KQ50R=FKC=VguWDNhdtP7^pJm`UBc7_3;1#VLFt<IvNDu+87b661vxtW49mgy~8
zZFLPN_h@TsIGHwo>CE5_^)&`43R3TI8T50R&*J`2XRIg~&hulbeW0dh-o8EfgUWUv
zdmUCMi_y0<y8imnrE5jG0Abm?ci!s->hl)cy@fvi5yH#id8m8fc{o6ok{UuakdHbC
z0jMAm0~a2Q7y*N5Bx8<nZt@vS2;LcjL<B*^0T~j7eLyOP{evDJcpaEW{$M&K4FMTV
z1KyE3)<Vk=b`LCcq-lWXsVS0^RH3sQv<an_(^*Y2skN-r3dy!3Dvy{EiL3lQX2i2W
z4Th*`Z3$BQIFm|&zT3|FRIOsrW2<T@THmAF%qk#9Z*p4oCk=fG2;+lH0lOJ1V{<7{
zfnTDtR@e=OAfSeo$jnMq#)!XUsy3iD(N#f_%84k4fu|WSlirE2Ms6uUA2SR#L+0o&
z!CyZf**Ffrl~;_)s=6jM;P)y+C<1FffFT1Tb2emI>|kF4j;05{4XG?$4l~Gxob7-Y
zIg)cH#Ebk2g(v061g%UW?9^T@v=$Fw!x2XSa;G3syBg8LDxMAq01=P^JV6=~@jxVo
zFxmx<2%SMpZa{^0NW%bNMbHNYQvvBIfy6*&01^W_(~!<$vpyg}mN2pbXmZMq;vhAW
z2?vT-0?d#kDASTmeQ-NKpZ<gnE(@EX(Dle}FzyA{h+v=~2WHu-Fakg)fg6H(5b{u0
z5r_~WbK!DevVw$N<V=vFS4e0s$dj-y)V2i~$N&{f05Ah!7`I;B@sz{=)b@w)bH^fw
zmwN1sim3-6(7pKPoqk8={k4x8t5ZwTHgjB@;5f5QY>wNwd+)_JJi0cuBvs9PwYWp9
z@$fQTD|IGGwdw#dq!D){O2$;Q-?I{(b=YhUbav%E?G<Crj6EDV7IcK_;R<#S^IWLO
zoI9npWGK|-iqbNE<umN|?W`@TXDkf->!VOdO&N7{g%+|csaW~+HeY$>8z{>Ne|kmc
zn{r><^zv9Lnpe$Rc}^8mM@=lnUI6~Rs5++NU}be)^i0*1Tys<CvJ$3*WrrVy>~;T^
z=t)Lby@V1Cua_B_Dv1M^%Hs?Zm*Y}qOXdrM9Q}w|(?|DTi}qS6mnq%ag|3$xaWy@J
zXP_@#POJwAw?-@m>ilYP<~DSAfeRmOpFuV2gSDQm?ujuyKyzgJ*hKeMPi;`&OcfTj
zx5NtYGocVFFNpp5+WieC7iI11QsU=C$}8S!)RerrnYN%uIy!JYi)1py(iVC%l4~0A
z?(rod|H{;mRSSRCq0~x$sHDPUr$g(yeV6--Tq@RRWL2&r|K+~!bs^gBF(^f-RN1xm
z3j9NDFj#BTXtf#}J|%W4ztp*8GMA2w8yc)LIox|p73BDI0Uye7Ln;+gLP$ND(42=%
z<$oygAkeu$xIlm0dvnih8=Q--K}R<ny?N_B;_|`a+j}a@dwa{vd+GYZpk>*n*-I`5
z*fvv@xpH4ivb1f_SxIFNYz7?YYXxejS(4|Dv;n{n=DNGjYQ;YGe$d3^Am5UVfrH@D
zCKVVqLpJS$IoHBSz8!LD-<R`H&IuUD0l*W+Nt|~WqP2mV6C;9$FeJeA8-)tIFr*<{
zbTS2_C@awm%oE5ztBx5{kVyjehp}t`Nl|Tp!IK?tkP{T-K^Wk1fNhcR7|7Neq)Dt6
z1htS|;PC-sBWU<A+`s`T*co6p0>2Qe1?Y_w5~b2)Qc4*iL!ld3gd0k@KouN5krI88
zQtY`sGvIOuUE#~*v?HD4|CYIQ&FX|l_Cwl-b287_oYo{lC}1wM+q}&c21uwy+dCLm
zS<~-m-yt%OpWX-&*M@|K`iC^Ix<3`eX1lv@u#j1!Pp@<0Q|BGr-22wWfEjlcsTScG
z5*bvF`8j{Ruaa`;=#)P*QT)yHTNTnPj@TX)Y4$yO<$kUlf50Gf5xxS=Pha%;=d{S_
z&}nu04mK_A=V>rbIYeu(T-3Nb{Tedj4!0As+$tb&oEaM*tf=fP>~UF(n)$jLDl3|9
zTB>ke)+$>_QR!!N=sUS2b+W#CY99KBVX9ku{+Z*I6zxubEvjKA9LHyo6Tfq5rw4+=
z{hN&F&o-&5*Jz92-mU4bBfL-UH>H1$NU6_;(_h~xUqk&llUmqHclD&JIO)tot*!J=
zfLqgN{(OAwmj9YZXj+Q=XYc2hGY^5(K=Rj0!G~W0^J@o0d(RY*t-Ka`21%)4iU<;J
zSC(Z9(R@TWAXvdHMP&7TFwsD-Lb_X^2O{eNiZ4L2zd;FF5PZQMP12qQ$$5l%!R;cR
z0iMtoyK&DvWO?c4%pSYp?4A()rsr??M!fYguZL~-cUl)rxGm5()qk{qg|*e!!FYz>
zdnrWSR9#k4i53UWn{k(@@BoKqHf*{5G0r4wp*Dsd0Z{DMtGR#{Jw;KOx36v-=dTv^
zwlY0GAPs)`$?s7E{wD&o@(-@zLqR@2Ulb@1_vHpefnxWS^+|=&QBdGeDv}LXKz;#r
zAg@nE)jb)#TPn5UC$6hbF!YkWM!+P_y^)@?6n|yXXq}8oq^Uxe$_rCFMT5=Npq;&T
zwv#Vp@^b7j$5sJScmik(ByR)BT?5sx5aa?*_~AnhDcVU}`U&{Km`Jg-+Rw9Unw0TX
zqLFM4(5}^pz?ev53I3O$pC!o`*hI<*)nfp;rlu4A1bpkYiJ%^?09liRM!qn&Fe9t1
z%A5>`LSbH_ccX`#ZJo`Y81;)dV+c^+HRH3nKDWKY`ONu7WleKY`{wSrscg6D=KQhV
z2LhI6NHf;&D4^=AD&^6lqUy~39`M6@*s@?%6}}igklQ4mi1+XH*bjcPRBc2Vu_#X=
z)`|wqZDNt)Ez#7>Wa{uVZf0f@+B}0}^{xg=T%E77GAf-bz+2^ZHNN%ACYM3IYk)6t
z2JYRfQ{!n5QauWlG;<i;;eGIOo)aC!M;1yqqn~veemT4ae!L7HWlwT3kaI22x}?IA
zplpC212BC0bMabWU?dqZvVw=ekclk8194`V5;QB(eT^C;$;k-f0SLWG_GEkI@UxZe
zgOJ~{YB2LoPes}I@nz)`kTL3d>TZuJmavCfA}*;#*BC2`EiqbcVZE<@Y!P=O$F_2k
zC39_cQFN2D=;g|`wo3ZUv_YyS^Tgn^+KTQ8<$yj&&vTWnis;>?C!X{aXe27Jh-2&5
z0dT--3HB_LBMyJ*kxUzK1&SIg$XJ!+%)qzshuP1B2ri`%!(|t2HsPE?(6yjMx*Fb4
zCx=i2dBfa9l>2jDyxKUrl|P*MAd{2%fO63}lxxPOnoTu>CetMHy{X1DICvX;KRdb^
zb`4R-H>JC3nCPZ6uhy`~2TyO}Hl6z(JkvFJ8ynp;{Avw-d{d?ibfg-5A3v9U15oll
z$jJt#3*@Gur9lAm5?fMscJ$L=gE?18`oj$B*0TIu{J_m99`sp<cQO^IMNx7^`m#-I
zXCb;BPlY;QGiNq8&rI)~(bP0Bv$<tD?H=y#rN3k6rMIwqm)flPiz!-hoTB*@^%jzx
z-qAFBR#WrL>8(w(W;Zp>n87@hNtXf+y#{Y!s<;GHop=RuT6`=-P5+p4280%p!@>c8
zq5#yNhyhZx0zgA8Lhg#mXeOEic`KF+Su02#ic8ThP$CbYtI)OR26QvJ9o<Qunv^hs
z7bHg*S%P156=cFl#7Qf_n+TzTAew?o)MTMJs7rzA4T81FFCk_d_5`8@saZHC3$jiT
zVV2lsz<n#6Mv%0DO_0@OU$8|8(ymcYwiuv(J@h~VKA{)vkUU=K58)R%fSij2VngX`
z5|J&uh;>I;B6B?9>Bf<7xJPmYI0)7O$_-8hK|XO<1bh(j1;>j)-6!BT7+b|bxFT^E
zrG(!+AirP}Z-7BZKwzMM!owMgVq|G#9a#OrBTBXgV3B0$F#f(OLCj82-a-h?HNs{2
zVo1@gH^N=Slc2hKVQ<(26bR4-SRgUue<XMO&t#9IznQ8u6|b<Dn^P%UrL{}cCYzB<
zL18u?s@XG0Lql~3Bw<w)#nB8B$yvxPua}o8Acv-0<mPBfY*&~lnsY-^G$<EUCfBP(
zGFC1^6w6UGWQqf{v53}yO%_4W2XaukGh}U|E^DPNl`@yxE8<v2YB4D-R;$Iwf~2Hn
zs;VL$k%UrdRR`If5w{9F;?9fFX0y0T916*$Y+)2qbweJ?Mu1z3+>n2IHr+)}o2yj0
zm9~pkECWC3dgfAub|WZodNp-3NZ_~9$0^9ALOsqr#k|43!G20HAJEiCZ?muRPovw1
zD6|8FsqN_Y=h3Q^9<SD?sQk?H9q2j-4p6$xz0_hT*!FaWql?m4(qq#vP^UBX)I0FI
zIDI*NV>%CS*pNuAtDN1`(A0*)$~LfDJEc4$4p9(?&vIf&N?b^ZC|*J_GPg{_vJr}d
zL>FpU?-Glol$eFeU5Wri-zX&-iv}|CLrg$SF$TW046KkSS;Pbs#YR0VrlcaV3(&x7
z$iczUVV0$AZqNlJJX`=3@DxNlv*fZN@F+{2V#e8~#Ba92oz1RXmrC#ssC?ytoDvF=
zI4@5uD%@moC=BK`iltJqX@C=nilh*7<TmQmT7}oE(5j(Ml|(YlVPVaNB@&54B3USw
zGJ_DLL3`k*h@wQW&H)wbfm%2RXy}~q8;FOez#TvX-pxVtVx(g@&PR!8-l<l1RaEHk
z`)#RIQ*m(vlvR&LVNF>eaQV7*DVHnZb`Oq)*$rf~iFg}*JMgFyux67Ai(Mf1lj?K?
z2LixomIui@7|;GEg7Jiar39`ZFa}+U<UkcvaU!Z20YXFm)$mV4EmR0OBIT6X>>`;K
zvp+!67+p_v<=@uB53-)VJ(A%fQzO%ICl^kQhzA<%P*X##W<<2TVL%+2S~xj(T4Xa`
z<VUUB?RKQcV7j>Xq+TS_qpHkfR!a7X$Ai{ndL2+Z{NGlk(u(d%|LUM##4pBTh8TVs
z#bT&5h8)qKldt<lZSfFOAqEhJlvZ?hD&R}x6jv~zc$>)odh+Ke{wRi@WB%@XqReV7
zbGd$~5$pBh8jA~mSMT%HJ6-ti<CJc<a-83VKc5|s&jy|DnzK#(Om-K<%oT!+M!cxN
z(s&r-0#AhHR1mm{;9*Ze@*={GK?MT7lrn&Hl@bgTz(#`*769w{nR^BU{_iR8+nFCf
zmF}MJ^*(muG0D)N*ZUQ|;|?_IXYua&KJR0XJ|;PnIp#h_bywHTt-(8jyT9EXLFcvi
z?PnB&d!*lIetMhoe&+Yj-y?zJz23n+;xEy_9r%u)J>L04!n#M`@Jcf|cF(uF!*Fa4
zg{sf?a!;~6pyI>uBr2#H<D)4dF9MNngg2NyM!2@Xxm89D>(eH=C+|E7NY~p=-dPnL
zvu|i<+O(meePg0kC7XBdx@=(JvRykjUwbE{ZK}TWTDleQ#y{eB#*IUMBtt9qZX2wc
z+}Ag`YH-`$cMi2TH@6>p2j7~;Uv+gM{V<VRL{#*wgngC06f!`#!CTP)HK67}ZOkpC
zwT1bN%y6Vp4O!m|s2C95MQ#_k+UOqt%NoIABOv_Y5a>Rlkw9T~ctDc#ft)7$YxERm
zApmOh7yIgq+cs?2_G0$)`Mqn_?0r7FynX-u_wV2S=b<%ghW`Bcz6}rU-M)R_0}t%m
zerVTia~EG34qv%s&WZDN?%lgRYp%xlYUDX|!HikwAM)Jv<4;Ehw;esYZSbxyzr1Vy
z<~#4)JfAt+7BHJ31r7Pc>hVQhZ_#+PExR)POigW5Q*8~pd|Uw(IvAI}bxw6rQ(YUn
zv8t-BuBwW@!>2Na!$y^lg6ta+#Elt)PsiP6vm0+j5<vI;Y>kf@6URMBHD?a~E|{pT
zO%Q&OgBwLTj18;>Bnv8u3oZC9cQWzvkyKG&!GJJ2kVi;L7JXa`7HU1@dV_bIl&2CS
zFBk?OWvn-4gi;e)@^*tY5N73+H^nbrQihw#*R3l@kCZLh_iGOG*i5u{=C`+I^mH^m
z-=3b!{g|nx9#21El;w740%M<!%)b)PANLd0{-?Z0)8l+p>j&_Mt}BMWGt=mYp?1TK
zGtqLqC#|EGrH5#I0=E@i--f?9n0X0Bs7H3~(#<3^m79Gw>hD6fS+kIBmgHWIg8o`6
zWQHd7X9<7ogE;Gfks5~Q)}}m^L#k6AgUTVqKJxTPwK0;-EQk2Ze1sec@xTHThd^s+
z2&l3FZ-{Ch`G8nwD82!2VG|$?!K;SiuwyD7gp>d&u#&oeTY!|*2~bPC2{G&l+klgj
z(}Q^9{J$&<#!o@EB4O3g;9@F4zJg%>gq%DvlK#sGxsA{L&5vw@(tMz}$06DtBD&An
zUj%toJJE&h3&w`~TKguUiSuhv+uT{{dG_=m{gVUSLV5bIuBXA?WW8!-a&;Wvo&Ygz
zv8t0AJhl0WjhPm)Lq>&q@M;ly3t#Y<_R78bJRLIO<1ksDwl~;NCbMY<dIC>Mt|X<1
zS9PN|@e^B4Zlu=GoS33{k(TyR6KRQzqNOq$Q%zsPYV-`FHN?5)EDA_Mf#QO0<r7kT
zA&4+=>}&|meVn?6k|Gfgq7^Up(f&_q`~{_;WD=T|OSM%@^%_PGSu*rGO37o2{{_!6
z-MWll`G&Y4D3uoG<vywS6K<p*ey2LrQFUNLdX+#}A!UbKKR4g{Ku;kuz;b5)%j>B|
zr84~<U7wLr;rvdwOpib6S)Z@5W<GlPjUIm?GNn&;Q9okc%j4Ih{R{(v!E^)5vQTYm
zl}IGkaNOHkxw%-WgxR0YETO(jpEgoe3^N^eW$8~i?t0jn6ZXX~!CnIyDCYSWI7qAY
zD}kmdsQ!_|e@Q(8{2M%3xnM;x7*p<Q3UW&b25cCjMxZtL_2p^RC#q#P)uZ!HD#w||
zLA*nLbP)<pS(QHe{TLMcNoLS4I7L1Du%jS9;-5K)CXa#hqnwxVUgmX<0@;Ch<_P#l
zkOTmp3Dn2~WqHXrVaDVI>IRtSinSVHk*w0Bge*FOnqbgsnAd~&2+wJJ`2{T}3`$>>
zUSH)?8cwtn<m=rW55D{BZ_~+9y_lk;)zwl&i|dhGciZ*nCHqjD%3)MFO6wbz$|pn;
zLqmzk1o_g2dRw{5=uqJY`jQ$j30g{grCJx%r5%T&r%vHln_5-Kr7iW9fNAF^c%Ip3
zHQWhy6U-)H-y{}GGB5!8N}h@&LJ07X)(7rh2bp&Y!2Bra{4jrKpH3LzDKc3Y1p!HT
zY_d{t5WqQLKT>Br`<-nmJ$GW<qhl`FQR7gs-uX+!D*TI5Czs$e$`2J#pDd&oEn9Wt
zCEFeCEj;VjgG73Hz^QzfGKfUlK#@|<O&?Rs^HP)V3Wnva4iHwEsXfT;8tX2}w~Fyn
zkFvF0>uzt>MVshmm1*tWNby+r4SKK5-U!vj<B?dQT2?tOXtym{=bLfJ2F|R)0~HmM
zcD*Q<<VyU_1qBdW>9}YKeAZ87BsC<{8R_?yvlaY9>^1?}0rM$&fgS=+q$hn2x@8jl
zCnQB5%)BF=PnswNnx>#xLYy>F?y@ibq2|*5w$^?4oftKLopQLldsw+{J{2?LnXPU8
zrOo{f4SAcMeNwG9*bWqx9C2DK&LbtU{npYapDkV9(9loc->jBX6cQ^kD_vDBy0Y`m
zE7P@9xu{*p011oa>gGy=Si;M7Ccry})H=6D<JPGIcbRmc4Txcgh;jlbAl5VE!A{u#
zQpBZDVfz{Z2?r?Fpg%w!59a>t!(=~&)TYpxMiy8uF|$EdMxl3&P*WM)^dqDJK{BAa
zLM~bI@Z`n%K>-um3r^_wz-}Z*DF+@Z5^5uC(8IY#4B~Kvk%glnk~wJ{HG9MPpeCg!
zXn;D1DFEb=I}>QmAl6S$4rdf&dYCcY-(6rfTXeQ-o;ZfCG6!k%)Irc}d|C!dEIh^7
zU3z3OZ3eBVqa0mgjFf#+!pW74x~nZ<eg9=7p*~I@yKtg2Bo%QSnuBjI=gN}Feh0*u
ziZdS|E-!pRKQE=3=^c69GPA)uZu}~J^~SR4+k2)-$ESky7tzy~;v0HnXiD|kfYV!(
z>$B8SGn*MjD4E-vRLZd#@;G}Vka-jxoJr*(tqCb7sZ=_L$*SvJAhRm=aZ1X$5|vTb
z5ENz$eu<R$hrB{XL4tEsma9>R+=3U@C%eo+b<pmR1(Ajl&l<Q|LZdRPBRZWcl7a8k
zWr13}P}^{Ffik3_j4BW=9b0(mGo|;rw5kFC5Wgwi%CZ+p_C&sND^xnWR1S3g-PvZ|
z&7Ke5OOPaUj9OyXfY>M+y2tCu8Q}vuo^&C>ze9gQ7iFzZLGTPil_U5KLc1G3kG9f&
zhhzGA#^PG14lm}#8cCaCzp-4ax?$m%eB_VryY7O0Th@LppJ<~M^b^MR?<bbA9fkN(
zE?r}woViX1_)BHUj#>C#xg=b=vQloGr2mD}c^r!pwYvP=qYqj_jXlZ8G+P6;P1^V#
zj7tjqu)pwMFqZ+6M2PJngnQ15FkiSkHh*Nn$O!JvtfUOcUpEnS0oCwDxMpbOdAIGD
zF@1SY!K&ly@MmmDr2-?>b@*B|*QVcq;tO5TrdaI9Rb{c7+R$lPD8&63VgiA1ZB0?M
zqcReSndA~BxHDLhDt^^{*U_B0+FZ$bO{Vz<`<drL**aB>aKH8J6QC)T=F~%_Bxv>Q
zKqG@qc&Q0D6&M98xPX7-8sIsCmtfi>)DN&IGVX*2gp-Us3OBrP>fZCtTlLJqtd$+X
zsTa+tHOWN=N5y5xbQ$mL@TkVs)%Vw`I_D#EZ0&?Kcw>RBp}|&=c`R(Rha<KoMix4~
z3?6PMgm!n96c&ct{r*UvzH?DO+HEt)s(O!=E<p>GHu>s-f%S2j%`eqOYWnWB<pRt4
zvn?F4+w#&62u~}^L1$<2XW1#BA@YEcFA(ZUklMBLAx?b*AhmN4SQJ_0PYFYs=CaR1
zY-}2WdLb+bcqxp2LU7QHMAacH3z3#3Oos3m*kXhl%UakZ><v~t01kj<h!qoC8^F^D
zYXSUgAxuJuCbJZ*1-1<}u)&K$(l8UsPO{&B{;!?%B%IFdy9ZB&oZ(NKd|`vmA$=BA
z47N-<v0>b|3AxOZx?#>76r9yG<><y%<NQnU2Rc>3iW~M$ZD%~kP|<n)_usU5obAn}
z52hWvAn37_^5fym8&Ixze#4mQwTZU2Whl5Nv`dq@^%=Qc3Ft(%@-^zw8#_Z(L(Qf8
z7gVuR@Vf>7K84$=pYJzwfI;w?^lqO{rNl?KRZp&oFDhPi`G7&nO_`c`u6fFs#6akN
z6sfH>^>$2cFBFT)p0)o4pBz{?b8JOV@7zMF<H@ba_ipAX17$%U_;Pi=@VHqxEP4qI
z>%hd?tyd_`h_y2c4ZbEbv&>!#3VwBKd{H&XPThDZe<$bv&8MXlva1pOrx5g?to@`K
zVpRvgZj#M~bunNcb_zL{jzZ6}p!27+`CzjN5`_nW50b#+;=~!5)tCfriKP4jt;tPx
z3&#E6A%mR(z^Y{vM709N3Q&|BPZTV8#Q|*x!xgY3r1w!!9S7gB*GST>k*t-7d<*s!
z;(dS!^K;CV1VRQ-Yxp4Pg3paf=MUg-&m6ep;;-==D1yOmyJM@m5BU!+s3<sygG*Mf
z#Aw9|01{k^!yrw=J2S^<cz^L?{PZ0mB-v`}e-wXhIfMVkE%jG@+bPccMcnzXsz9Jx
z!(64Uf?#3EncY`iRaCK<b!ARaZLi~^%n8OHve`o9-I#GwA7-3P@XUThS%X0<HG_Pn
zZ+RWHj_$+uUV7JsuYHa?!7F$uoyM`tGHZ5)=Afn8>%CrGZS9lg<xdvO@uFj7oA>Bz
z7TkQ9ep?8iHs+uCw(Ql-sG|dIezj~IQv~1>{qQSLpchQ+n>Bc7&UCaLug&Z`c#v95
zmeN0G?<$0>MMbls(Sc;r0e=Gr4_-U60eG$wc-Rm8zu7*}j+LMnn*jgfg1jg%=e(Zt
z7SvED8B_n6bDD5A7?LAn+E3EE3GX1$>_|U@86P@ch%1BI#-zG2j8}nq149Imaw3>A
z!oVa$98N+Oep>|QN2)=P7c6E2+&C``edu&zc^~<X>%lGRHnM_nB9w?AW1kbO_+aY*
z7C<fs>y(hLf)lc_83cGH5E+>6h;NHTV?nlcs66^VzCn`!wj?|QoY@NwGGTwdJ?0C>
zVm@yY*WGl}Q@7sw)TP=r{_5rHS25S0fBvr<sc%z_j1+R~Yf6`?8NK|%`Q^TpUp;`p
z6f2gyST&_nscST4J&h1Kt1fr8wyf7QX@*!4fSN^e1*8FC^t8kSl^uCACpCzvrIPd<
z*kgX{+>%Q39J5JfR3+7VxmZTAQlHdfVY%gMk2ES%mMUzmoioSinXe=g5vQo)8dG24
zH-X0ASiKs*wrUlA6TZpv8*A4x3nufOI@F(Pl&ou_cd855OBz$O*;kqf`ASNgu7<zB
zd5R@V7M__hsjy!;rBtV3AzLP+VWhK5^<Js9s6<Ua&xd=&E}M)u^YShB2&I&9tVedM
z9f}2V^?A*4H3PXOC0f5uu0#;VZvb<48&X%Vs^(C*%V~;+V)HB}t<5j4*$CX5HU`=#
zYDRTkTR{9I5^JF{LFp9bhm(H)W8YPuIR*FPv>rHMb;3sQYzj6UsCmT#j@bhCvk1t%
z9bi2>A0kvQh1kCXP^%CuIbiKI0uxF={9HT+&UUB`!V8iDC`M{9r$bUhKV<d-YX%Fn
z!MHs^BF%C<$VzZPcFHCi0GYE0nw7-o!UzcJv*hR`rzNDBN|3ci7l_CJ0(R?1eL_K?
ze`2c`{U+N8s|4Eg?nqr;*naBbhNGsuz6l`}9(sLmv$SeX5Blt(Q)o==>+A4!Z$ROC
z#XZkKTBLrkChWrZTT@Bv6+O%Qb5#@ck~{yp^|^obo*16192hr#EI0Aj9P~Fub5-s-
zOWv5$q-j&Iw^(%edhda2XZ0Sxc3|n_e}Y_1yA}M&%su!M^pQcYH%v9c-#jz?;b-uB
z2K?>Xg-kTGuLQrd`<e;L%Bd&XD3q_JAF;QjUn!r9>_7Dc(B=50e_Z6A08x0;2I}sH
z@*e$E_t&S<_~MOMhNto2+jg|{x?Vgphkh7;Rb6j%8XKmacRZNuwR@B3@u;8L(b<Xj
z2ZO;`d3oVwg@uL4+S%Eu*9M>`YtF9X9%knPa>oXJcs*F4ev_oKssZt-LBstY;@$%;
zs-x=zX71g)3!*3;m9}(5KzbKY1OyZiL`6DSP;4m0-cYeOj8T)=Ycy(#Pb^6+vBcyt
zmYA5PCNVKFYRZ$uD0|26KXZ3svE(h^_j^BacW;?FbLPy<nKS2{Ib&EVD6#`4em?B^
zdd1Tl8*3N~;DQ6BS@09qcs&WW_A7jg1;~O8k+moo1V3vK`2iGd-nz)OV`8PA88Hq7
z3n43*KVxmrq?ZW2<i_DLRYc1RJFzLoqDP2i8WiXq{HLF(Wa{P@5Z}{JrH-=CjZ-<h
zxQLcB+xKXnEtecHHR}wAMPIFJ?+#K2Yn-~+zN@sywu`yBi_p$jZ5!<Zi<!DZXJ>!U
zcB&&*-a;R<+F6lSp5!ABM0~Rio@(9K+RV*VZ8tV&a*#!+YdaepC?DjWp_QDP#R*y2
zl_LgtbPIHI4<yc=BUESlckF1|!8y~)F0+$=2M@KYn>JG0e6Wul*iUDbWailsCxu!4
zZeee#@=MOPBUjpWbX2>inwfVo?TE0*W-3Q@d(V!r9!cvubm(etYH9A(-hqVYNNxcF
z)tJFM!w#$O_B$;C;4?~We23a=I-Jj`8mkdS1kLp7D!B-r@mb@?3>Z*VYZc+vBh+1E
z>O25PF0s8c36BSx{w?{!LqrRiWS7YirTsx(OaM$8WX;OtX*P8jMkjZ%WTsX920uO<
zFf}<FVn`i?@#>1D4x%FSp=-$N9;|c-KIL#JUFl=Wm}l-fhNwt-eGs3A4AT|E$(2Q*
zWq+7-xc@Mp8I?YR$EK%jZL7P6_6xhVV`QAo85i5G4rPO<t>3oWS7p)uu=%Rd!<O2|
zhHtspUMikl&{#Y&NZZ%U!qO_%)6sUI9W9B@^y*MZ|LBJ>sAa`@1<}E=#3Cco(Jmp<
z#>YzA$vZ2=*0sH9h?lA8=;Yp|Q<PcPsEDlm4vtyY>DIHl_Ik%IVlWg31y*)$mW~#d
z(u7CV9irc_SrcWc>7ea9b8b30=QiEWCY!$M?cyL1C!6sjyVa*8j;mhLIk0QV=sC6J
zqM$X?`ln{jom-dX>#B0HGjkbjzF+M>I5E~5A+x>wJiFW4t(Xym<CJZB<Ya3@Or=id
zFaWjhVA;jP_2sqQm&|*?)KX;~IJMty4;%Z~fCOh85TZ7>cBt%Nmn+}2_j|9YrlPlv
zsLsuk(Eg&yvd89{Ea@uZ@1#LH4PBhl+^pSM%kySun>|?%=)}FRdE=oga0Z}3Ko7JA
z3^@p}fF~?BV-9FImIbZPm%c5gs;rqyKYskn*X{j7qqPYYq0>r&n`V1koU55m+MoR8
z#;0wcxBseP$>4d@FHT)HJZH(ODVJ{Cf44GSzWc$&>jy{ls~vl6deN}lswuWhr!SuS
zWqbd5FZL*&ADY?QBRSUF;?tYIAY9$FnzL=6x4-_&<B#9DfAiAR)r)dQESviAw1&Pa
z>FC(njNz|ezx2WMDPwX+6oW2^yzqF2=BO$idYyD0gQ0}`G)@DLT#8e^;WGuzipt#;
zAw_v@c@I>a)3F(uhp1z<Hw>OQ(u0pE>^eX%#aSc~8qqx%Fe2<Fdutr?zyff?8V@o;
z^kL*9UJ=TqDA|M7_MXtTD>_5GL-=mcn6t%DxCwjPK{LeuKx!+^Q8B1Y-cIk-(_g0(
zm2GVQeS_zHU>%J`xY&KX;|Ps;K+lxgn7ldZS4PacyZWX60p4&XmS)u77lb2X(%8%K
zX5?#?*~$PK*SYZ^%<}@BHBe<HUYMGf5M?<vtB<b?U9*MFNkN@J{R`CAA>ig@WM@;e
zSxeoAWtO~}e?j_0WfteyEuw=&U!EL%ws%(xt4VRDQA8(o(tcR_NH{uhjICDCsM@J*
zx=TKBUOgO~94!jUKASOm_E6h!_-6VJa_G@rqF=cslI{`kkk6fXiY)LBXy<9|6VW9^
zHh1b|E(N&?2ff;dV<T?6vP4by7`ot`yO){0w1%WeVyI=O4wiz(#iL6}sVw&!9{fUB
zmZNz9J;ZpPxk)%ZsyQ#6gr&v}F`2tzMIC`Pbq@MJ+r0#9rKDyXh&;Htl1s;}tj`{H
zb1{P8BZ=PDp7?NgQ$^n3@r5vMSf6LjV>oabdN=)Y3gg0)iRXOYYRRcNFVAnxx#K)p
z?lmy2Iv5J+%$FKBJU-CVy@N+*Pm(^fcylp5P@Ypp^K!~_>Cw%_o2BD@9Q{)IJc?LN
zU)wf!Wup6+OW%BZ;g`|APENkb$#j^nle15<lP@htG9Tw;`VmhqN_6R9>-NcH-GtJC
zK^;6C{3pbQ%?$|Y;%C;OzB$Z=eCsOj>O}suw4~;p$X~svvkSr+-AwK7nEtSA@ZH3|
zi_+6;Lfy2XlsfzQJEgff`T04g2PCKYJ39LlhrUP$o|6Aq(tN7g0ZOyoZm=G}j>l|y
z_(&SoQ87DM;?Qbsu!^r8?5sO!*?I!}1*)+KXuCC^%9X-eYEG_EAM&Sc<+OX$)Pjsu
z+F{j3qWzJyOUitChB<xv`uJiJtx8C%j9*`UL$!7#-MO4jq|2;>qo;Kg5c~b`d3yV!
zZO8K$!3Cmf|LQw*xsd7G5VvX;>j%IS6X3t45WY4yV|Ws4b3zc9So-&)rNWWdUw=cW
z`H)(ED22%5NFm)S-y=&YoEw<F%s4M{!jFXKAtz~18YhJ`7ckQfr^OYNp+OEc=2#Om
zf%*Sv;7ayyIYmxZP18;Nko?kzZg@k|Jo-oqT~4d#)2$5tV?#dhX_kw$<{+o^iFL~r
zTpnN1yn-^A&#Vdj+CXU-N|8nLihOH1xgvi@N6X2YBso$ym7G$6Gc40RL|Ht$f+NmC
zV6oVtxn#cNgypwYS$2}xX+wS>i7UMMG@raf&(Sh^MNXC`l3kSM7o@DVeF&E{e`>}c
z!yo58DO9ke+bJDHvKNGRqn_kTRtl%JrU%MU^dGzow$~3<N-g?=z8vhZhvq@k1LZt6
z*+MtcD+h%y$T{)}eVkvAy6Wu{#9tmy@1h+3!SN2Ol#(L4W1H0X6s9VD+o)DcU7>yP
z0zJ4!i^qFl>Q*jru(c{1qn^x23Vw@YK}Gw}z+U|W0>knKkA1m60yc#8$*&^QXxJ7S
zx`((0y4gpAvLDBLx!LEtVWVMC-psC9j@{h71HOLrP}1nm%xkLKA%>%T7258;GzaCg
zlU(94fAAH&sLYORLKO|Gd8RyL+}#krRAZ!cF>nkpk~Tr?q&W-9e)XSUR<^+Zm$C&5
z%F5;s`3&nPx6g*)dcpLb0Ri#x0RcUAyW{YUyEw8pp}T*4&j9~;RdCq?YL}A8vZcq7
zJ1oP3vf2b1X>Lx=CDgJzo`>aAKDsO26XN{?;uBB_-selvhB<nwhA~wG9PGjBLKu~?
zlJg1+0m5N8x)$`cW%oRi2ixfsg1yz4!`zu1$!1DhX5oW_K4e1gFm^AMMg>KuRnnEY
zX;zlbZejFvsJpYJRa!1xS(z5oBZ|Kz<8u32v$rHh|CWraOp6YRBDcfcoH|;i=h77;
z(~vYeI5KS{8K0YO)zL{CL89=slU3h5GQQIAwvw*M>uc4?$t@gmFdNUTZsxFjjzSdR
z*-EP!T8i(^;+;ncCGr1p)s0lpa6D0SxeFabmDoe;78n3cE&I)e!q)Zw4T*F|1KqSe
zur3KuezV2Z{5G(M{4Tr54jk~mr{P47WRF1k9R*v3rlKpSsV%(3Sai%bx-3IQ*)G(!
zy+`RMZMq5TWX6gxLuOFPPIL`)V`O6W0-3V2(WLY&uS(j$foWD9d&6-n%pL8|Z)s0Z
zvqujkWxs)-uDIGQkS*6Z@}L8~i4MgmJyM)gnbxZecWITn86(q#Ul^T`Ss@q-H1M1C
zm`5z&0b&Bi32iD@v_dgwCaTucpc5xHpEyB#2#9|}Ptj9k+m^%=Cla@a%XL39US<qK
zIeSA3e+l@&V9zxBvDDuw(AJXnIrMHKeUL`~PNRSIrgyW61$_a)!|8eYA^C!i?$d`X
zr!a8pzt@OEWH)k$+Hqe0yYvCtq#JyoxsMqaQPJZVYvf`M(<bsil&${*krf#q;}^r5
z?FC>$4iq>aj4W#Ude*G#O+_QC%9d@NME8?y_E|^<(AU^!!j2WCqnE`+<n64i*>GNN
ztlXIw(euL%#A!u#+R>wF*((-h^{u=&cK6tK-^JIx%G9i-IRV{v@87?>TR;vRmJRdt
zBjC(@YT$nEspaKsxVsRvpNi@;EJRTSfD<uJ%c61tYix*uQrw8GN{{GwjvtluNU@~f
zqEW^-%$hZ4!oZxWIkRRpjK3cI*I&V3>*~cu-H5T-xz*!xa>so)%f>15yYEVxI`5dc
zeemGj1IJIu-Ci(s%fua>n`X_T@019;2TT~3n>%)_0aw*9_{DbseHqi_xS|aeWZb#B
zlp)vBMf8eWD5wkzi8lDEh5_Gyf8<ENyB_k#U%}U}cTJhnF#g1eEe!XWiCwP~C(GoZ
zlF}Z@R>X<^Ys`S$>hU=_<0Q?jS;ezvJvK?u4&6L)cjuKQsKUz5yC-ffbd4*?bh1IE
zXz!fy<8pJxjpK6`_LJ2D@6P&2tgtD$M`#6iH&KhtmLWJOQ!fL9ml}FE>oNGCYHTgY
zKG+axL~9;PLlJeu)wM}Ac67J%-+w#N7wmCk`<vaE5lfei7-LH;>}cJIEys_qNJ~S2
z*oL&Ul_z%g^!HEf)!n~mT!4RKqJKb~6ioMxC2sWkSdufgF*7|at8r}eK~%~)dP8}y
z-osen+F`wWm2Zf4783ju68tf5(VGFWae$M+<*ECcgXlvs&{>+G1}##7YaB*wo4YVA
zM4qq+bR71v)fj$kwHlRui2fxmH3!!;)}KE;Yt2s5P43n>nO*K8zVZlRTFTFp8WDy1
z%qsb@@cvfe0{cC+g%s1M1*AN6E8Wf#$ieJ})JP|X=O;G}d@M?*hA9_g>l&7i-LP`j
zUiKNg-27ME<C~9#$3I9bBq#71wqF+fRKP0K#4^;1Ifq$kyi8zihL5?ONl37XwBmJo
z?jX)Qn0%0gz4bbYcztnadgc6idbO*{wfQDuC!hb2bQ9*hMK8Ps7i*h0NXT1<=ttu}
zAZGNz2XoKSzliC7qs&kfZ_98K1gn6V`x#|60@gXwPTu<g;F&#D+QIY0uPaA}9#Oe=
zp`V=pkbcI-J(Hshb!FBOmuJ-$3T5p-6~5G#>fR*(rXh!jAfI_Q2IJp^`w<PA3!4=p
zQvYa-gfR~6B>89H&{}(($_2VVP4pH5yh&v{hKn5>vY#Y+D;eNy^syb)y(RA_7Y;q<
zbHn5N;w7msR#P~_7~TbFV&*x-h9C2Pg5d^hO-NA@YzR6NV<}R+MCHS8Q+Zt3vSA~l
z8U|Yp>75WUqGEaJgr<E{r|#W5b?QE{`!J<Me0$>g*okj8RgLPCUC@}^d+30qQB_TE
zOo}^SJ#`<F?&G|et$Um_pGkID&9nn9o@OE<y$G7mbZe*u+n_^!7f0)?=t{bZj1@9$
z<zvD$VY+<Sp+DJ&^O_(yD*frc`W$TcL*Xrj<rE8Y4(@_I)J*3D?<me`Y`s_rD5h7z
zijk|C;8ll!#~wl$@9Zv2&CG0ChPfyVI#@+tWzbF8A%1!&qZaxlhJ&$?r9LO0a<Dw^
z7aSCc!>IjzySe+Cb_h0W=cF<9alrA~ngGwhAg7SoPA}8{Y*<Hsd--M3VZ-`HaYFkb
z&z^2x4mMuSetq3Tw4Sli1DzbUc)AJ;<t<cq>=<n(;=9L)iZ1Ssh)dmFUHzn4^7mf8
zQ#)Ciw;vW6+qJWq1}A$7-PKN>IKs=)%QfA!UDuAzd4r19(_hwYAQl_e6U%k|g)!z)
zet}*+yV^PUI=4#-^T1MLV02J`_ogl`<d|;TF$5KEKK3qJPIb(syPqq{0&OA3KEAJZ
zl479Cjeu`mCTOg$Hx}J)Y`eH3(b_Y<ZN$8>sRRelVgMMi@8?|`8-3MI4MiEXc5`;@
zoMTg$QP|K>*xmHiC9w^KMRQ}8>@o8%oF}hM4GK<82?<ISOmNjVH6%ENUO&5H#hEiJ
zR-TdFQiFo}rUnP6Tr6rB+;_x?)FJZ<3meqk{nz{vnlPlWVQ$gj#PHwOc!j7NME{`F
zl;DumzPepODapYhebdNr24%(BGh2gFQi6ih(pdlE>o3g+sT{JrD`bXfHfB(H{Y(Y5
z4Nh@r8ANPe_Vj*wv1KqVXhxLx?OQP{HMN2^elO6U3+UC4FVoNVEEziLtF^@HlxP;~
z>l+)>ty_$4@AY-#-|=_)di{p4REPRjRP;?9Hq43kJ#%~RE0=I;ShtJoXsq{^@4ZI*
z#>V<~!#U*z>%X2cqIc#?UwqB*W_pt!)YGJOSb?~)J>6#5@Wn<n+hc`Zj9=giXC$M_
z7!P&zG^+EXu_KmN&!T@FdvRLa+9N;hB&QG-`tfTsX6)TNW5#QfM)mJEs<MCoQPMiO
zh6K{8rZ>OX+_T~EF=AdcZp<dKJWba)W8c0R?9;z;RKNbCMk)N~u6SGO1?d)>&&>oa
z^B@S*bS2(gj6oDm@ivX3(PZ8C-@kh8i@mpQU6rv}P3)?>BnB2GG$fOB`c~@vgrZ7{
zS}E%SRid;8Et7~yNc|8$l+9y`P{itpr6E@8Y+SP-+{ysw%f?`Aqe9VMLRcpxV@dIW
z35g|f$D)BRDUl2FpQ3<MC4PPS`0>E{!sw792bZX5PZ#Ms$=NeD(xr1@NOWOc(8-gh
zuYXnL>rzqX;ydQ6Nus@TkD`w0#U&Y5`GGDDqNvh6G#@#7$M(^cs>t*7u1`(B>k|iM
zl*Ri;MFhqt282fi^epR_H}QJE8ZTmZo(vsTRW*wK9uwB*twV?2N)C%2wR6;%v7;3I
zhbmkWIS-FA^hg|T#oaNCP9J5mA&V69+>xjXADIzXX1R0g@#779ZfxFsW7mS6mSxx(
zO1I$5-PP<vI-)<uB1V5KvCbHg8UrcmgDzJaH{ZCidC|wtAH<|p3Lc}InpkSN86B~k
zZw%blFm50N&Q>R5-1x#XCDDMTBH>}&7zFD!vMXzah-VBS#WJU!Jv=3K_%I9wTKT<j
z*?0H+6DRbTzccBBlcIM_H@}!zHhMN1u$R_h+@xa6b)u<fUdt?Ac-ip-CcP?ESi8rw
zs9Q|5U$^LJYNM|N@1u09cmwq1Bga!~kDbgoZxy=jFfIHaESZ!IOfj6)8f<aaXpQAm
z@dn-49Q}9h-(e5nrdIMW`r^FZUvJq0%3g|YCZ+GMt{S~+^{CNJT^~mMO;3`Ze@8vc
zei(I$#CQ2*;g;(l>c6%0_?4)KqJ7osrqQFCR`aoZUzh=Tn$6j)z1?vL5I2u-#>>00
zF;34HoP`-*Wes0cR<>wZ_E%pGsL)@nKs3D!<BxEp*?QK1vPFx^a%NgL7dP9?$W?A^
zn#ni%q&hqO1?Q35%<`lKpqDpzWC&&n4dh7CT`<w=#YtBa>kumwPkXfqyu8_f!bSl|
zddBjWS)Nv;H)xLAq0V$3l?{?6cJ)o`{DuXYLu|U-qVIJSGA-pZ+Pz1=Zoc%iI2O2=
zOh+UEN_QDVPz2L|Ol-(%rv<k3*sZxY*6(O9yzqP(jq75?eC+MzZ4dUSa1v!?fjO|5
zjuV{i9A)ib%r(XQy>pc=nU}kJ-tpsGPn?*yXO5vS3U}sz+I2~BV`K4>E>)F{jh7sk
z7cW>)yu9n>#+JUvb({L~eX&Aiv(0~r0doOoe2T}7c_t2x){TYvt1QUx)WT|UVd3KE
zqcUV@P2G^<g6e8Mhv3Uh`V_s6MbbgP!$?rNo-t0m>tV|w_ON1aO@w_|h%E+1i2nR&
z16pSHPI_IbUEf&A$ufHWy1Gxij^Dj|-0PEJSG-Q%YwB2)k~YSIETEGu#-yc;Rqbz#
zSiQ#jjruWfbY8(|wxY{{arLj;tX&h)n6w~r&EdD3A{WRvl8X!aCiNX!$mTpIuNcet
zPH00m7d)}1VPhHHP~Y{QDP(g&f6kk<*-quGm-cCp9Z?BS3fg*UpL}dfo8L0X{N%!0
z6r#3Xuiq8ATV>Spsg`qT9K+BeZ(>?vEE@Ba4T0kwx)tZx#@$NlTA2}7YPokSRqach
zof4j(lv62fw0vj9>VXAx-cZtO>t4&!xb#t(jQ2r;h$GhNBl|{w_g&?-<Rvpp^Ll5O
z=d64)C1b^Xx^nQRpT?w(N;fcS-rrUKk|eHQ*2^}CCCC`Dooy!smttZun-Q6xAh6Ru
zg`MhOm_tfC(UF5*X-G++Y4?9CfBTh{QP3%DAuo0+#blBR2_-rjxT(@JMyAEkmv-c5
zH`0CA8V0`n*6yQ%Sh8?oOy9~3F8M@9bAI=|DqKZd_?>}rPjS6xQOj7;Wb<3kQp=r<
zJK5yMhvZJn(w+)Rn5(+Q(BBNhQ@ou~nI7|%^M%E1Zfm^k^i}cg+cAAdDtJM{+NDg0
zt65)THkI$i8<^h|KEdY*WAu!si;(Bc5trugzOiM?*LxZ+Mn9yRNcn>>%o==-0N-ED
z<_Oiahf$a5N!Lq_TdrT<vfyf05`T$L7k`s@dIB?t?#0oon?|uo0{@uI_q~`8y4fKz
zhX>~!ilq7k$9jTaFw*R4&~vLs>xBhFS9EOQ6l55q#)8X^*NboeRQQ$C<sm~S)eb2c
z3I@T;6K*2jmJj?-VXbHpCiUepme9fv80%=^nQbr-ZoWHj{yX!lPMmPL>h;@iURNuw
zu%9a~$B$RdpKUQFrSG^7j4yN;o0dA3c+Y$1*!*$(9IK1J9Je}R&u)bk?A{Zxdfb=A
z)lPdeQVNEq_DL-$Y(o#XHj?`j^e|ecU`HD8bbp$e<r`6H{_Yl@9<#92tt_C-t#o0_
zg`Q$pyR!aM{FTeaMt#4@DRD1tY%Fyz2`qDC)2UmTevPF{6bHj+lW7FJKuOS%>rvq&
zp$Mh_wP3nz<tJBGFEf@s?VN)QvS$xxgX~$g9kM5R^c{RlSAI_l6!|hbtk0W=4!xNi
zY9wDmN01NwmVWK<WV@mrpPc!;jn)w&r<H#GYuwpFt1aPPUg7LR#u|;VVm9LR6dJ9(
zM_1zWpc?1D!_H|1JYW^I#12IEU$hk2rbQ9n#adgn#iI;69F$XNi-T;6ZRecNfgjxa
z1J0`sG-tu07eqd0AKm-pTZF~jMF%51rZYYC!3T!%a$jR1=3_15#CBe4-9rWV7^ws-
z859+mWK=C<j;yg*be!&g?*u(?eBt+G+3nk8@sIK<CQh->D1$6@lJq}ulD>Z8Hd*?^
zEjrFzdA+F2AUUC_nVc-%5OZ*DJS+b>D;1`AhQ*t6W${K~XP3wrPiOUal8Z-7l#4@A
zv0p-cAblXbMIQv#Pl@Op7Z?>0kdP1%5#=AhY=GxPp|qq#-Z*hle9L;ND^|0LtOgx;
z%X&#K<v=OIwI-}MUL>=#|MRM7%gK{xzU~$|rOMZNSh=(Bm?@FnCW*#<(8XR^|5T3N
zzOAZKeCIs9=X0h1+O_?!coCZq7v<Np&RCxx8xxxJ##?W_krWy;ddDcZv7({)93>6l
zHdt@g6A)uW4gCW`d0@WOZz5r9TbN&shO#t(PAR6|J$iUOE}@fW5wFT)a~qD1B0e)|
z3e#$j%gGsEC-i97PQF-IC)5=!pZm_Sh82bKLa`!eJWpUKTQv*)kXf5em<K8QV_{Db
z;nY$!i@uK&S>IQA&Cy*aF?*pk|Bg6`cXVro+j3`i4H%41-dCqfe?rT}dK%W^Kp&DM
zGZahKh{0lS+_%)}x<L~cE<CkBT(JE=blgyyJ$6fn8Fe|iwY9l9*b=JiH|bR4(#7I7
zd2HZ#GMy$`Y#I}gQ(u>xTT`p_Cl#}AD7JUVI?O5#vjwyN!1e?Ev{v<K7ky<Z-MEWf
zpuyxEjod{_my)twG!i!<<OGc;@6kjdbp|5*C*m@WoRZ(0!RkRas0WCXpx5^_31a<*
z)x%rcq6mVQ_tWx$u{uOOU{TqCSyu9^wroYQxOBiQTVbHp?CjFTEn}wnreX953(6J^
z&tj{T(j_CZGDj{cZM#azP}=A5eU)1EE_kOOFw&r(I)S3CIvFm#aBT;=vhhMqrJmwG
zYU$R`sQmU}Dqq`zpaxUp&n-`kTlrx%Q)M!hrb_Y~wL8}S(ROG(iEwzEY#Y0Kl;7dn
zTHVjBicF<_OQ0iSF+35C*`OPY5WLl`miq7zd#eZ!h<+iigq<003-?27-~@j+Ag#A-
zv>{f>rU?@^&fIwFqt!EUwP|B@!p!gJMLM@vI7vmco_NwXtQVb2FMc!A$)kGXgo31`
zA^E+N3UrQz_%7_-yO2)UxN*XoT;jd|9eO)=4ZEw}q#@R~e;V151z_zs@~7|V&zeou
zNd*N-y@w7(7WP|USicVw++cg^j6L>zR$@kZuK2=k4`ZZpmZ?6fzPC|T)Wfz+&~;{L
zi?=6isV?fx3P>uX3!|guQ*p6j3`vw$NIEHaZJyA(h$YG|Pb)0!2enDc&fZ0ZNlE$8
zI&yidQu;wEg`E+KIl|2SAQ}AMz!u^9!31hWecK{ULv^FI<mhsX5`r0eGdvl^jj1gC
zu)v}zDq~~%A-S$to_rv4bHAvy<_p?yt)HISe`VHd<mdS#Gcqb0$lcd6SN2PpK6#tG
zOOa=NW5sdnlcHw7Gvw7Ox|q~d?I?b4Mr5D$^&4UnrYt*Du~|6k-Iy_QWJaU6+-FPq
zp=DDNV%MKm^n2jCyiRPMHRU@tz+3pds_<Yvj}i0fCBC4fmqnBD*z|bnbjg7OC8xzc
za)i)NenT1Wu(er0R#vQR+`tA`m<X8Kh$a643*dL!2yQrQw&5l-A%qTFZbc?rl@X_<
z)?~7E4RNTqCiRw6=m-HSqa4`Cn0-vxh8+l<g$Fe?atHDqz6)TS#Jq)ZHxhh?+l@eL
zhCEt=tJFZ~5WUx0m}+EI?I$NsVma_hZB^62(sz!P=1H0xFTd*aun6Z<PcMGxw0FbJ
z(~}o1p8P(Ci_Z5d;94*~$+?$)@*}EOX~8zSeyd<c$BOUM2}Bf1<&8p$d|1pRzRQ>E
z#*@h)t3ng$O~A0?FmT{EJBUROrYn)&q!0H0`R9K6VB@v#Fl*xW_UGamT{PK5OYr*@
znJnNOLU{_EB|?f;<{$M6)i}%nz>0aGK?-4WfHmd=^@@k*$yVX}>YIY&9Qo}d@)~+p
z@DS4Fw`d{!oPMMZ^oAaWSPq=n{v0mNfF1KcHkXLyx(D|sB~QFRM{X89A*?vFk6a+Q
z%U{Df!hC>Mt2~gG#bge|T08~SG?Gn>uZ?9E<N46|+IRq{EH>5EZQ4{<yP3?}R9CZw
z-Rb_?TwAw!Gp>k5QLo;`MQohTFUD1I?_R~aKQVTTa8)FBP*QD{=P(co82(FE_9{ZE
z;u0Fus~E$&xTF^w%>cmkMf9lI-vaY7^D;?bb@9Z}94z7}-%W_AJ<JY%KcP572_qIl
z2;=H(u>XS@ITQdwg3bQ^-nVMg7c`)E)Zo%ygEPwlXE;Y39hmKy6P8)FiDvzi*;rgS
z(cg7e;+y9M4_cSw=jmSJ8Qs-0tV>|VDvvy;umGP#IP5)THl{xhdAp^LtU>#BWYQ|p
zvc)r-c{y`}5nhYhxvJODl0;ZpO7%Wz1?m|2A$@oou4t<IyoGQ-laDhW4psefy685A
zNXYFE>h6*aY%dkq)mOvX9jgOZ%Mf@>FdsC|)DXxFJ1Vhd!jkQc;;RSf*w`PxQ&KYy
z$<kZ0Wd&c$gBP|<En=zf#3EWsjGicg`Iqts>h75X8tKIqn^wJ1)vdcjv(Li$%SN@2
zjw_Du-qFQ#;Mg7^nK=vS$166cd%J{s4LyFZI^yMW5*Ru1rx>L1>lAL4H8wEh@UW`x
z$;H$z+|I{?PN*1z8xpu^ND-O%_nD?)aRY}eDM=Xk(w?<M<?o9QW9jXv4T|rZIb~r!
zOOg<lJ-BCJ=s03Zyd&q&kNmnMG08H(w?klJ-%O$B__wVc{L02>%j|;j0k%f}RhkF6
zk@*XOZp<$wkif;5kwuZf;Eax52KJ?9`%TymBkVX)h{|ZwkqKvP%8-mEHfi3(pkU7d
zVHPv<9Zj>kdzv8*+K?F*VcpY%gC<Vw7PZ%6dOjjunq_C1Iu4y-u`k+ZA~iRR7-3#^
zJ575jf11VKpx}wg{vkaWr0GK>RYwH8G3%N?qhqMk(7@1%6N7^Gb(}u5t64Umlre5t
zeePqut-+{)Cv3}@S5~u(@hU1BwmLI>+Uh4;SK24=4^9&7U)B8SwOKh6t8)iTB0cnr
z>s@)#gQD|h&Eh}1oc4~(s-2jVTV12@eQ}@4g7baRTZ!Sx#wJ{<7!eI?hX`@s#tC6*
zgVqg5%^9@j@M`lp=e~J3Yu?StdH&)zbccVPd(H5TYfFdKZx~Kg-+sHS$*+{P8TXwN
zKSCY5Vn*|Z<_y|ot-B)cyEE6u2r-07P4?CyOtiv2FDy)4;OmZ9tMGbf=h4En07>to
zx{pG8_X;~-_j66{Pm|8~jEau?XyT7GHOpOHT(yZ`^cga=H@#Pw)a&!a#4g@0WU#$0
z-9r|au6?1LET%gh9LNw_GpuQCDLH3uHfGr1J{w-?J@n;-;(}hm<Hoh)y2kseZ&kGz
z?*`vYw1}}y84eUi_F{gDf?gUi=Fs}nF1bBH_3Z}w>x%{h@k^w``swt~qsQo<r2WyO
z#C&e=9)U?ofjxTDBE!|?q`<&FeF6iMgy5H8TV78(a)a*%`rCSBfaUHeGMkgY9!V@w
z?;iSJx|jjNN8g?+v1jLZ#)a7kfrgv$iFg8GE)aHcKZ2c8Fu=gzz`yxW;jtX!F{QB7
z*iC=~ZZL*yJF?g-3eUlC0>kkRjThJ{thm513S)y#8D0@#tRy`I#g@W)5h5Sr8_?i~
zz{_A#9V-K;Dj8DgG3f}cDUf7}R2&}`&kj^XN;X&-PqTF)7`^Pu1tT8JjOjBm@bQQ4
zVh2o7j<_<_1qaJGc?l9J$6<J4jA?rxKi95Swhr-~I(L;^yLD+7AxNUByO))@znx1L
z*VOK2wjns##LO%Kid#pm+BsGur~-Ogn+Mw2MEg0pM0s^_va}pzDoU#E9j!dv?6qCh
zfv%BV?fpH7)X^7b+^Nj^m?Pq%siz}@XYbg-+^1cLzaR-QE|S&}QQ<{@Y{?PK168(W
z-Me(Rw03eXvA1>h>C)3q<K59d#bvNVWT$pPjxKRlw*5MH(Rz54c1*Un^02f@w(AtB
zDRW7&?}T18%r?fRb6FQ>>rUMrtyG#h4gsAK?0xKgI;i?MTXj@*cftuRo$S0vX)Jvm
zI>dxah&=D$?(9}%XXWZ)oo8mIcCxhZ-#Nd19~--Pt4<#F4sq=>9Rf484#`$lshu5y
z)E0Tx8K|?prIXao!`;I=(#o#X1;zPwHt%2>k<r=5vLe{Q)+WK(Pu0=NxsN%*NhXGL
zv5K_S7Qo*LV;wRi(VC`<ncUOS9Wkg7X^NTHLhP~KJj68p)ZVFUU#j2raGSbd<J1+)
zCT~6^bo%ASjbDnsxpL(jo*y>u0QfIigK@Z;h{%gGactqUghei#mec{T1T}Qkofc!d
zz%C>(UnPu+Kbfym7aV;|<`P1NFpnDMp2Ww30uNdS4zI=V2gb?_e~KpeS!K}4`=iff
zpN-mo;>7-_v)N~&_mc(BF7vg>Gb}#ynaJ1X;u3+HZ{xBJ9&A1NyL1mckexlvqRZ+f
zJs$nnAoax%Eav}V^(fujQD3)f4*iY(K6iI*-L9SW?Z}|jWRQ9Njw!```V^NWC6(xQ
z7bYhc;jV~us^77*ZtW0Zfc)B!wY9r;*46J6uE{<->-!WJ_em-#NlGp%O2)N*UcHZV
zPE(-~&_Kf0s3yq&k^d6fkqY_}6xk(0SNV$IkI<S|$P_xC&O;v52{bK+oq^>+dod}R
zNxp`<Vc6P9#gCdLX-@NFVQxlPct(0ecsj!LPg4oaR1m^4(!(P%`T>?=TaH7!vo(LP
z;(3ax2S*%njgX~Yy~02~LmwgW;018z!OX$96<p%gaf`9Bp1#yT>l)~W?x9RIku}p+
z=w&-2yL8E@e&I^t^st?od=wEL6X<lNq(EfLbX8E<VjH@N&aA5=vq_1~;<D1k<^B4X
zEiT33@L}QoGBR9TT%BR)J%MA(Q2{6|6yNtLTvp_C2*YX*%UJ%ArszuOEHX=+A$K8r
zXr5>)9GF9{&Y}C}$d~ka#YxD^cV{r^61@^1aT0x}3IECOO{AJGBh}&>U9%{GT#&N!
zO(v`Fse(XzwyT512e4QC&pc5ojz}SJr{}9AYh1Dqc2z@owGC0<dpJhDdem6@;!YBH
z&SD3C2jgoOzSi#k*M9Qu4*KJu$>Q5LYh)*~fesVClbu>W^aV0XKDqr#9F#Q>!=Wql
zfnzxEo`B)Y)@Ytj{OWOdlqij)+sRP=@o2g7q}xaV`v42w>#S_@_IvW5?=5ZlQe+DC
zY;gwaKG38DQgl5C$vje(wQ__t>pai;=;ss0j?hye;VARV^Y0b)El=9&*Nph*=xPcC
z1Xr4!RBMMNcuk)gJJo&L5fjEFTlE~&*DWtf{~L+l!Lc5${c}bZS#-=TvgqONotZPD
zw7tbZevRiP?K=)Ewg^fX{m?cfG9(}@!Iu`=hD71YDZV2eY8w(A>>uV7*GZhAU&D`;
zO{eD+Bt|Nq9)3MXmk!VMIPYxR!`fj~=?KGR%hSR0L-YE@#SLB=I<Q~QxNtY+H_V-l
z<Hz?kkHl-x0Hz^gjKZ5Rm9yoDeu2U4!E73CS+?nSS+`APpsitT_uovUd9-u>rtH3}
zb|w3I^t7t1=$n#Mw0Ur4?|xa<b_bTp6+7o|&QjjS+YH~A+`E{+%(Qmcw_GmA%j{H^
z)id6DWZRd-Y5wj}#XJ5J8QiyTyk%y3eN<u3*mVWfd0o3W%^SU`<z;HTO}{x)THd+N
zX?Yitni_B2zwJBlI;=s|ox!VeO$Osc!4j<ED)nbWvx9rkFA#!5|G_>+HMYG(z=M&6
zXF(iF<pT+a3pM%-2z~LKCqxg)TmLJ$3mOl&VL&#H2v>KG9PQ_lnDt(#k8Q4X`pNn~
zo#>;oS58s+*SthK`*%`hi)PK=9skt)VsTf~sawQ^nr_3obm?X%b~@2rn>el}cuY4N
z4-YHrcOpY_$Jf%>LzZu7cU$iK`E}F1U0%_wAto=)(vhk$3v$1+-a9%^^{=o&ab9kp
zW`|~n<<OsYUbs0f$zvMv%?ZPk@R@PhlS0y?w0;HV<JL!wA09R++uo@tHg<WRakL6K
zj__PV=jLLw*47s~MlFLk0$<OOMD_csZ}s{}HiCJ`aEvZUjc_bszU5kPFW&j=IwDM^
zwb3Y7zn@rVN8<y{-Mo4)Y8OCzSl1=gF|(1Xe_DNgT7MNGQ|x?@rrE}>u6K=%>aLwC
zknSBD;^Bp5+Kz6nA!AAISjW+s=^0s-j$`RCx^K)F=*OT9Q}jDafm<MW4AYewmCJF!
zjt9nIAXV$JRALSCC42<*a_^(SW*gfYV5It)V?nnHngMBb^=Sh%0-bMHmk3;s19{J+
z#pZ$JV;hbe!$`rzaYRmfM(!|2hEa%@N3wtLb`P%*jvLd}Jus_K&0`*So`}&5$5%!8
zR+t*GH>>!O?$8l>^~})d-a)?wgw=ejdbK7yU)(2$Uh?uEls-%t)IH`EvDYwGR|fCC
z>I(Waw*hFBZppT8Lw*bQ7WIp1w1S>%hJ(W*6-0E_GO8;sqisF<^v|nTX(otL*xO0H
zO6I*96Q0#IGQC%LaQGW#9@VMW2StYWn=noFZgiNhgX{j2{*%+Yr#jQZ^?j>0^bhDZ
zx?NCUeDpN(qDRf&W~XOFXY28TjBx|&eS`;uT;WGBhw)`TN@a@@Vyq4}*o~wcLlRWf
zu8!KN5)kb-erN!hQ=A_kpI<=c__JTtoP;4dd-10s2|b7A$HxWf?hC(pjE>JA+H<(K
z+(ESRPwY9Asi-+!Zb(It93xoyoDQyR#~K^vAhrJBu@F~F8-Y&|Acy`HNT=TsFBLV+
zczOF;`s={tmtqI{RL2d;sU_|k>Q`;3&MaRQo*3#eU?~wAveU#%=ja37@)t<t{N|6-
z&-afR&?~OAZemJrdNhx^4}b4);~O_NT+fMc&vzJIy@CiMndqj-9%?(#2=-2BlF)W&
zE{&bFyA^iJV%xp9Cl8&E<+U}?i$E|A1Vphzj(XGNnX8X?684B4K5SYZQ{+mLwUvQm
zCv56iX0fh*WOPz(z`KhRW5vrB<GOAAsPPrYZ&{G*Z`)6se5T9z;_)so6_s`%l&b8f
zR&7p-s7rnM0K<pd_QY=>&zQl|0FAGe<nDpk&Tta5vWB9-<PdTBm42~lhq&O3e8pj<
z>YUt>-aoA)y-7Byn+j{l?~0C0RV3`@_B9(w6{wlw*N)xj8gCrhg&px)YwVI|Uf`-C
z`ooVu(c5<7HM{AmH9OV}EJEDp=DDfcUJy0;x#ZDL^lRdFr#vI0ybtxVA2;=Lx}cPN
z(dWfFOm~Vc(gZqtJ-%GE4DGVHU@e)*f3B4OT5;sk*h@!$xqA5%$@J0Rk|_-%=V>VU
zxBMo#OatXVlr~VUK%F5y8#IKf6*PPc4TsxHeRCu9f1nMQbEPVzW9ON+Q#9h(x~r8u
zA?dm!gt1hG9m=M3qWF%ymV_a4ZRL>9a2|I8cJyK!>7+YX>3P{txJtsC|1{8AGY&F%
zXJ&<Dc2o#`=E{CB7}g2eoLktTF|gK*qaN8mTwQqehivNcD+#7+vCRs%#AyRvLqdO*
z6V9JMUqW7>^C9DpDk%}%gt^p=Or`V419`f9U2sFh#trmkl*?s*M6%al--SE&im`qN
zQxcOfA-}?;&o^*lzmE#B2(ViQYT$@)Yei$K5f{{)LMv~pqFdLzM=HrkqW-LU<DbO!
z%82A8{YNzR%JZV9#!n+bWbD!6Tva~pK`u7$faxC^^ze*#e)TsCCdrcnT<8d|Ae!(k
z#ij?2kGdW3vBR!?WgMtcI#U+7Gearg!yDo%LI)~hb)aB{E6kzovIj09ZZ9@`N!^XM
z^8QA8?A$eQ&4il04h4Oy*KEJNs;pL|%ZtizG{CJ(qlUI_>7@@A)BGK@LuIHh^^avM
zsQkxw#Mh+upp7fjb%Ad&uE{i%e8OO&6yusOxUpG|nJ^jehPS<1<mniKuN5avFI#eH
z-8YlUD@xaH*bSpoN}oO{Ipb$mX|Ik9jL+U!K0`IEcaf&Ugp}Idi(dTqTkGz>@#g*!
zl?BQ8C;OGmT~l9|?vpr_HrI~bKY7DKj#meDjp|kK_*6vVS7tPWK3S2Lfrh7kHse}o
zU}>-Cv@pFz=+CTcvD6{d603?O(?N4(5h@9qDxzb!x`xfpHF4ucXY`+5J1DPydjAYW
z)sN*<F*(!_SGaz9-JtAg)7Os<nL}Q+qqqD5GAerv3K@}}pYId&cJ9DY-MbAB{A9?^
zkVw2K2y~jZso!Aq$$ewJ^T$k?kvk|OV^HplcV1;Ct(?S)ni;S5>-Xx6S(U*9#y0m0
z3D3+Nl`%Ne-FbX)aG&T1-J_yBpUEL5vAvS;E+(hw?nplNAO9hZlx}gIA8RShqlCv2
zRvHL$2$}?y3YSKHxqe8JTscfwQT65e^<U0eI(+!D6&1slsm87U(oJ`5faq4WVf~k1
zt{=W^+3<?x%Qz2nP>+-D12$XLVg_MH{TLSepe&A7cz$`ti&@nwT9kX^#SPa!f2lH;
z>=B}_y<C|~2NjSl18=Tf_r;uL!zxy+99F(e_sO#1!<MZWR=QGJO^1$dSo`G{8(#W6
znC#X$y!=H7%_|_=D(9{J>Wi0$tz?)lBjv-FEgv>)*(wZaWlg1D&$Czr?SVI6%WAY{
zgpX{5dQ{f)Ut`bIHbJCAkI*7<8y!lAVvSFS%2Z6JL&;X%(PFZl8f?7N)Mv3bAOsqF
z&Lx<WxTMy!T6bZ|WK@8C2pj#i?qSTe0f&tsYyg^oZ7XGQ<JdqwTR33kXnJkU%I_D&
z_6-Z@DgU&me@6J}Da&>eXL_@cgwU?SLHfb`e|08HC+`~&8M`RCcl`2Avm#V0h7BLm
z-DB?WhYGqjxqmRIcUT`UUDM1C*i=Uley)a$UO9`d(rj!HmYfX?&hIng&P%;HPoe$Q
z57qHFH@w(n49DIugdx!D*G7CcRiu74>#|;>40Bdb=0(9ryMDu<QZ;ND<Qtk4E&vl4
zTQUG1G~S$1FvzIx!*8=2ClqC-*%zkgM7VT`2puaeEMHMRVR=<zuBC58%E03OHPK^w
z&b(Ou`uvp5>Dx#DLi0!^T`QDhXJOI({Uvb)n!zQzUfEm_n<Os^_i?idkEGcyL-NP_
zr6k9A_({t?s>rUYZc0xn4%-{rJ!WWl2ThtoaN6hrZ#J$vcD{2?O8<({6_e*qzt{Bg
z;!`8vEFb$zf1;V1_Sj_N@8;t|6Cd4{UtaCoL#GOHOQo;mM;9#IGuS^NEPXKg5@F{L
zic_R>m|acKeZ(oUqi~D;@pr;4b&>K8=2Ugjqe!E7t@+UFlzg%y5-Tv(MF0VqW`ep%
zc4R==2k&~20HH)I;yRSpA!a9(Y@0M`8~X^!%I`MT*9DUvkB4Bs2tj)2EeVd?g;zWO
z7L7Fg>UK08AuZ0)bn+I7#NS&u+UwCHx|I|@dPE9^WaC#XDIOXU{O`*+M~{F1Jv~km
zzW<&iJY5DJ8WQ~P%Xmb;zIYKrk^9Aq#Qo_q@X(OppUN=aJ@+)N=qK2L#x}f3$FLji
z=|Yq(YCOSz(I&>c@EPT7`ElpYAKB;WGL+{(GWcSfHg|ub)s1=p=gOD~*;szMv<mEG
z_#J=q$W&M%EFd0DSzA@LmVKTsp1(IrucTWGUTfU{6#M^kd!e^p@@0DzjeT^C9W<ZD
zvrSKZ!MG(}cy0Rh*Vt!CLGRuL?DI6@MjiQ4OA`W!lJT|aN<MfMv2i(`d`lvQJ)p1&
zfm)qJo;ydr#fVkjWe62w0)Gcxpin{E<Mh=G@(23W_{Te>1F9eJ4pK9m_qoncI`HVY
zl<-3H-FzvbIZtKNjPM8loc5e9i=}N859qS~tF(`FZ?d#U#0=e=&rVCAdR1_spU4g@
z@m=9Z8P?}#;A@n2i#!c!b<RSAJng?q3$GuRHcN1oZ?b-AOb6(I4V1t-LaSg>fyz14
zSn@tY$Ac{=5PR}{;Q!pbOat4RcaQ8LeASZog76ixq7Sw$m+6pO$~I_l+rqh^`%3hv
zkhkIJ;J=A!3&1_1hnyf3$lLa?{osrjA0f%YW!~oS7bnS!7cUl)mn>Pr-_?-IqJ7J|
z%a<-)5|Z)7-kEF_YsH_~J2O$NrG;>}*^0i2Z?Y9ndpr(O=SxFz#dYOo8f!pT=j(pf
z{VduFjdHzQFEj!a0J0~dEy8ECK4o=&8ix6k`N?cL6Gzp|ei{aQN@hc@Yl{b@B(siB
zLD@o!Xc5^0dG}}fGqHUJG+ryzji&%^#Ke^xG5JBE8>`t5<>loH+4#E}l4?Y^)TX8;
z1KnIrwhH47bQ8wYYxElNF`}F6V-wYJX^9ctuo_eymk-DXge)vEyU}js({uO-ERTrE
zBEE%n@(2VfSVw<Ae9|r`AM-h%vs-Kw(CouXfmyhJh1_3wy+U|hcwK)X_h+>Jr#xff
z=_;(+Cae-x=`UoxUhDbgEW0Hy6RK|s)k3xYLSFW)a?taYKj8Kn{YrjKKzMIq05gLr
zSMqC5;bxrY0)lj35Q0gC5G({6uH*~<nCCt%knamt5Q?n?E5nt1|DW<u3+hO*eT&?}
z2b;K*D{5gvNV>^e(r(F`$udm0=WRw{CbTEg?i6^QIixTLG<=aCajR={#~*Q;kT8>t
z(tGd$VC`iL<Go2VkOod7m-rXCgj-_W_Le<k?MIwV8l_LAgr{J9x|#N&eKwP${EHmL
zE%9x8%bsx<rY6<WT`BJ=7<Vtw0$Ol^Y~x>K8*WKL+gtXG!7%yFWT;w{#ykl_E$W~v
znW$qy*YHJ_;+70*d&{127+;tqsk=xG42GGxx(oe`F2vtwq>e5mzBm)Jj`-qg%u`S5
zSW4jVzDa<(hqPXwzX#m|1K}pPmz2Odnnz0Tmxrr{r=FCsl)N8|SBFB3wLpa=-Xbg>
zKZcN}I#ixb7H82KT9ZW<%d?$@S!KdZas5U4W;B~2@O821qOeIWxd=GROiI<U&xR8#
zZzgs1tX}mvrfzefP}C$8iE~cNy1{~qf1O@-MwlVbIRiNJO>)#p&xVsEpCs_Cdzrqx
ziImAF<Au00LYz4ID7Bx&y51!6)6ru`grV~GBY-m#bWMLYoOJm+l6juKPG3JyGUf03
z2~K|tPGZgh8nTLfL_=4Re;>GeK!}ph9sry=lQ4D86L7303}jDr4poup-{~28=64cJ
zRfR-Hx)Gfivx8<GAO~sY0dimmaojH0$#<Axk|1h?gSxy07FMmE#8VHe99`9tzDw`p
z?_FH=nU1+?895@hUr86-A(Q#nN-||R8z9R8>n8Y~4PaRUFtp7uqO#!#g_b2oq}nD}
zK3^f94;I4tSA`Ic2jt~Ek}OXYmeM16B!#5p(IdiAc_K;9qlY<u7Xj1bxiCEj$d9(k
zj|K>8{<Td|;{iFmjQGiWggkl`7sPKFy(;9%d-w&1c^oiV|9Uo_q1Ck8E!wS`F?)R7
zBA?;`xq60llD`pL=&xr;N7C^O{Z(+0zagE@(BC*rsB?KA;V@b7f63dQpwpsJ>?L*5
zDw<EfqWP=H4*o?v$PPRrzv})&JCoc0(f#p<?my%<?Tjmc11&cJUalTTk;4=Hal{0J
zhhsByU#E-UY_RBcQp>+c1*yd&p*{WR8qFdHu947d>_ZOFtZR6tz+3^C70-oPahV<g
zpE+`wB=aw_jU?ld;6s~^(MD2#j8tK5Qgw{f)5c?Xroc4JL2PA+u!c&j^Bot4hG+BM
z8geLwrd80i6mm#jBaG%375t$vT6q20&-J<fC*^!gW=^8Bx6#>?$V~ZL!I@ud;|~RA
zVb!yr%Sx{QK{=QQ`fjHGx<&uBne@fYC4O;>KO~og>SsUK=Xy>#PzZZ7DV7ZwT-y`S
zjZPz07clz1qW3T0bn|K8nd}0+hdm|@!hq+z&}T$HYSTW<p-0QNW?J%{{93*>6Xl%$
zQuif&iG7_X;rJmH>?>Rde(DiV%HWcT(pvN-3GMDF5xAAFm1oH_g^tw|$i!cMA#Vs<
z<f7-NBj0S=L?#|SOfCou<jMb#?v?MpB@?Tv$REtv9qWqLa@p*_OUB82mLh_AgefR+
z(1CROq)C&QHoUbI`XcGyTX3L$z3HFx<{Qz5*&!rz;*VOOuWp<>7jE^XbLR@T3>U2E
z=cd1U_^^Cc@H>21xMjHTldnFJ-b@23yU|CqnQF-m%xY@kR_isnPTg4DFg}^ChkFPa
zFp@l3?X*&arL{M(Ybg!!=+aiLS|z_t4&kRw*@tnT+WHn9PBK}6Gl|9^Hnj$plny4H
z*!sm#f<{Cj0{cK9WvS7Ok>d~SkfVi@`*(Ox5l+Y>rhPG8{!TbKRVdd#7S76Xrh=0^
zy!+IKsZ)`3{dCZ#1ir@CrEbuLLUU`4|3pHcxGq2bllG(i{zS~Kw3-^xkA5ou!Zx!C
zmZV#{kR~5ubZVQ|6MMouSzfv+m*vf&o5>HKe~!GnsUy@px5%Jma+szl<EZ3unN)#t
zA*=YqaKqHDT``AA71Va^T58L-agd+at|dRyeV<ezu<7+GQcbGIkQ-DxhU#TvBN(1q
zbE35twOt7!*H+NnPd{ZJvX_58VU9)09}Y`pnFZi(C?7T@V+^ce-@(bfA~e?_5MR)G
z&%)__`uES|KXgtFj<;w}Oz+}rMr}>aGf<^Bi7Rm(_@R(M7k@}x=}mew_apf@ne-9x
zU^FaK`+yEuVKE|@6EpN@GxTWew)3GKNEbS!Vi;ze&P;lS2j0$#3bK>_AS74NAx}KK
z%|-0abjVY1tvx|u9H1jI8jFCtbUnpEGWamctRoZFuOrp#h2+*J)$8yC|9O%p;o)3k
z4K~|*M_6hj?6H-^=X3h+YuD(%KmVMBVEPIXl8tUY$4iCY`g(e^nzqHr9{d2V=b|-c
zN@gbXw6?SsiRk$}On;{r=*O5NFU&yn!K@i1Sbm8FlVHrCK{IE}AO~jBkDptabu7UQ
zdO;|sAH&qkfXtlP7D(_6G>uW)usKo!QfM6@i1q=pXdxiT+9-%r(exekT3R~&d^^n`
zqp>;h0*sAsZYSR9X~bs-d5dBhn?|qgq-p%^$FzwY+DUxU(uwzW@+Q)<4UMB|#&-Jo
zljY*j8B3VAL2~R#2hr^#>_K*o+UHIq{q;^`;~o0jf;)E>kdEw{bZQimpL%qMCk6K~
z^fl&1=LEZ*J3R7z5&6V$3R4UUe@=O#M#Q+#dP_l;8shC4L~Pk=EsR);orxBa*<lWi
zcrH$dKdcqH|BQn}=X^-})(Tr|X<zytNt8dS5&ov{)z->0J|zE=Klzy?()T`mZUxA8
z<YP%{YXL|$)dMAoAIe26YhS>aA<V&mRA4J@_yW17E)u_lCE5f#)x0Bc5@u0zz+Zo<
zE(>p*dGO#2qc`}s&;b6;((uh-5kkY6vNI1<mzx7rm;d5@!5EH)hXz#_{l#7jw;mv^
zlBN}orv?Xqhgb>?D5C5yR$Oy{KFtGlk?N9y4{YH~y`b}?*5sb}r7)Y;l6&MHt<~cW
zWBPbKURvfeNmS!$?HQIx{8HyBeo5{<36lYY)&i53HA{fW%9<=XLlznEGr&UxE1(B(
z)=GkV3I;k)Jw5n*#%ZR<Q87fohLHt@3TzxQ1m~yIGC2s7-2r+{pNd;Vo=C@V#2?ae
z;|4cxWI>se^<+BW*piGT;C2x9&Du<GLA&nOx2r$l?Yaz0(>ztR@J7?=(@ib-39iO%
zYc04ol{KAKRW~nFRg*kkrV%Vj-?nrQdoSENjl_DqTHwI<fVHhF3Ms>qn3vhCpOao7
z$I!m*^>~?aymV2RMu~V<Sbv@P5TEM?ct059MT8%&H{rc_Ru_e&gw?SXmKo9GB|qk`
zZ_#T=t?#>fIA#Jz>j$PAyWS)arBGdz(oSRu@EX^)-`$dPg}tI9`rS3M82d-`>kW(t
zac`S`C+?-!&agzHqwW?m?0phuOTUwId4gNChWMNzK88MGfT#33fP*Fg352~020F!N
zX3~Uy7up6#8rA$5E^cRqESe-_vG104mBL$aWc^MGr%9+fQjxPXikwvuh0ZN7Tl!t|
zWA>i)VR8%&f)x?x0S0&sN2~+GneLD!P!R<M8pYe>X*xEaLS+`K;)FNo4o=4%EjSwL
zt@z6jRD4GnOQecxKBbByi=RtJTEh}x{ML~CG6FAj1xEwCHgrUS#R>+^r+B(&v~>%P
z|NXZ9pWyi4XzPE#5t9iYzXm#HJz!*f@I;-#o52M^!w2*l5*VS^wq4j*0T%=hY@y);
z;sa<;z+>YDdsum2M1ubTelBMieqj2%-x%7Y1wU|TB>11;2M*1qkhbuQ@k4_DK7Qn0
z6T{EIx1PeUiCQ7S{{+7#a=(?I8sHh@hXif$+lxLp3H(NdO2Ig;RZlYXK<r=va;&c4
zBH~GmVWjaTm}kV3x;yM08yFN@MtPc6IDmrLa#Cxnigx-mt#HiXgD0M3+(ooAAf%`3
z196Ie-gRgFEkvC1fK7T2$i2VVr2Cfw>jhG+8n4RZJjfk^I@~em{za{jM5ug#v<#;g
zOj=-}ufZ2AOq@ckA3R{Q?O)_RAR$dF9MB2g9?D#c*J3d*wzWSBCtBtKu&5B>#9=0t
zA7;Wgn`zmCg~9t6^W7u;yn;C%^DJE^JMuJ*SdepHW8NPP@Bj?BSqdlUGPcN-9SP>M
zmUOM~z)M(28a^GfBw`{jU(w^Sxgb)(&r?sg$Om*FdG!ISFN7bC+iJ`$VMa7l7d_B<
zvG<EWvsV?GwZJjZERqgnFl5IE;up$TCoOOknkhKpwb)ZBQr|}U_4c#m6Jx6B%Qcc^
z*gRoGH@!gdM7oxFqE$XIP>$2r08g1GTIt5B!bKw{pX`Irca3TRcCMH}zlO*^2w|eG
zY0e=-E-_o*CAw3!PgqZPGP57usnqK<<UMoH8hLozkuW$to70_5N-{B*3~A0$?V~#{
zAy1)_$EX~{9Z*81sB389rIxhlL4{;U6Tz|&co~-=gmE1&ieOeqmW098Bgar>^)T6{
z`djr2uLnYKKo4cFRsCJ5J4l*@tS0I}I#i08)Pdb__-)c#Gu2oG(l-&^K|?xWV-xw2
z-S%$+{JkdER1YK%2H#Wb&9!Lust59cmNeIz#7tJ)j|TYHRDUb!!4D8BBf^rX{^swI
zN$jsWsyo;uWCJs7&@*a>4veOtkG?5Lh@MEgv8^p4t^#Qlav2(i)4)J827}RzwF?f2
zWo^R=*P6J6ejF6LLp!h{IBhVN)J#@u(<gp-^r5i+66-ma<l$17uwEX{JJE2ZeP4JC
zc~afJO`kxQ8{VWO69x(EAAKl=$-{v-1mh>mY3&m~$c~rVq!rdT3G0>gMrG*xgwm^d
z5?Eyn$T3tw(-%x8Nr{pRZ!>6)d7qFHD|G{!RQ9WN1HP^l_p@ue)os&4-KX>iDX~d6
zfG1k5vL|Lu;%mBW+^%NrWenTUAEd<QpH?f0UTd1PTHIf$%NAc#`h!vWmi{0mviGZ-
ze*$FHAzk)rl^qHc_bc#CG}bL`z-A`&BI`#oWZ<7zJ&C<MQxb*QP>Hft&P<-?aW9Pd
z_gdQka}@|Q^Nf;+yf4gtBuk<^li2GUf%6GNIlK%oY?K3j{Zre-!t67`Y*ufhGN5Dw
z-)2Ry1rkdjc(vlja5eOeU!;ku58JlG#3i~(r&ac+bv09$h>LYKXH<5lIeeqEhIW{E
zS~qElxI|Zj3~!xbsgVV}y={7_r5z?V|8yFuSf10CxI#{mi9v1Cx3<GX-6X(cnU<*H
zSt)jBSPnxwjCryh#x$2e!Y|}?-6|hYZ8BbMG8$o)lJ4r;0m^oz9a>hKWSEfET%y_p
zv3;x35K24f%i-;S2|x>FsUt0Hn-;4Ez5-S1(pnB{3zVd93!aEPY(<bEtgruG>8k2y
zLt7vd(Mne@>yFZE=;J=RqcbjxeRM~OugVU~ELNA+^k606lPo>GraP*n^HJGfrJu1Z
zxF<eOmLVZIvp5jxYV%L@T1&cIEFk-!RIv{~K;VgT7|EEC9pyCtq)+(?5VRw{EDQ1}
z<(Qag&OX^TXPZyLa(0<jT?mlBQT1eYG(JYY;WVQ^f=_jRvTeShwMr_Y5nP&2s(Rus
zz_@Mn<+QfVS#<i#ZPN-aWRc(k)EM22%4yp+JQ4Y*6+wouo^GSm5t2D?8%(UcZPXDM
z?}XN%aTduYv*;bsL^dIdRQ6o(WOQrIgMKD}-pEpeEI%1i{y}T`rJZP^$g@UySo=U0
zCF%$?kCMz@cuW?*fF-mEv6JDa!n8b3l*8HwUY`-P7R|F5>Fs5cKMgn{#~s<wKBn3y
z+Q(F@^CI`;WM2Iv)LQ%kdL(PsK9rdZK)0i4pJYx0-lO^0f%?ZvNwtgI(|L(s;O2-i
z4>Oe0(mtkIv`=!|#1NnFb5&H^a#;Oa$BvSSY-~l4A*^p7Z}ob~uWkFR$60eJ)C%o$
zPflsTwz9)=3b}{&v3fEOnpA0@_0$SkT2c}l)Q06M6b=*ar}DU^oR;=kkM=Q2^*OnZ
z#D#K-a9B^b);yqr(mv~{HQGm?5WY=%B#{LuGa8s&7fi*I(0ZGAni0X2iPP7a{ejab
zS)B6tZT1c$nEC!fVohdJd7FHw6Uzr~h&2Fzr}{*kg7)Kn!B}p<j-gIwfLXrBe+su%
zYncrPCIrN?(jb^IBKhry9CY_?lev&BWXlh?+`YdIq*HK^B29RD2#h#F9sAFT6saVU
z9}3wtndK9*+rkEDgh)o1QA-A!r$|N_nr-**Zb4Ke;357gMFK}=OA>H0kv$?S1MGg5
zh?TBp$vH}TJjf7f9gj~1T5uhJMp~z9WU36Y9&0US70VV%j5g(1cMgXg%mnLf=);*J
zpy|N_q=7E9@xcSJ9)l3+T46Fh0958-(mGnBq`+XPVR_oZW9wKb)fGhmUX%NJ3?Aqj
zdD-QHi|__?jm-B`3;)hHm`@pFN`QlR(8jjBW6E2`tXkeJHhKpI8z!07cRu=eSfvr4
z)2I0xW}AA!M8JN6LW~Dy6+%=9I5%;}QOKQP>a&${mr8ko@U56xt~<z3CC4g%tP~~-
z-_reDo6DBJXP$%uA1lPDz<6Z37HryApOqJklsi|7S-`nQcTmg}rpgN#pe&LtFMxUj
zS`5}sPvXNMAbg#@2ptQ@M|VJW5hjlmZdV%c$)Wp&Z-vPK_D}c#7sSng+m`_!XRHc@
zA1cW_JwCT&XOb;s0SqqM;4@l%qJ=)t31M~BN}m(DgXJL4<Z>hW0H4Xi<Tm8t^)iA3
zNf`)f*~TsfpA+%|)CWMA9)Z*67RUm8jL5@iV+4a~`JTXKUopd_Sj;)CJHWaIIrhKA
zrC7I5%qeF5OLsub0*`(cE{-@;CSBiez^q`O(OP?pT5pkftIz4~=x&k91~K!mrfs@|
z**^+_1Beg(LkMjWM$i-TfpRFJl&-^RGaY?!uL6s8zc7G8_*$GA0PE9P-S@gXe~MWR
zWaNY&vvmiyikSn1gYrkDJr;r_US6kfE=C_CI5<R81X669WCYIt)vC|_sXNd>UlhBF
zkkAhfkT3n1EoQ0O!+>x?7||qz(mx&;P~tcl)eq_-tq4UQd{^vooT$C}99`R>JNTDq
zCpuQkmj>t#ZWA-Jg}J~b9*a}bUj7KYLf@$clX7xQtcRYS`(?9HjqYqI)-#{lGN$$g
z=Y{2j&Cxuq@WzvA6)sSYHZ@9XW|Ba6YvxPe!LIF&cy~D_qv7>6*JQcL28`rRCR)P|
z3~#ob41X-Zf<|qLIB0A?jDDLLo+I*4Cl>X`@SKEoYE7=}wBxVs5u1oXFnYux8T<De
z9~1bz=bHKQH8}mxldlOraQdGr_#8>=;%5^Y*WNxkzVn4SehJgl2lmd(>pd`idV=4a
z3!USW?c2wN+W2)z(_J#YGo&!&Foq(`EKN=>ElEl(D@#o(Vb{8^*f+alPuVqGdgt+N
zm<$Ow`Ff~Lv9`NSw;(Tf+x>J;n7OTAV98Y7A)Bcsfqu5;VRX-a9C#Ac&8EAySTGAC
zd9AlL`ZOo>nQV+8iCM{|rO8R<CAy<2CFM!D5#DA`aHD${k5h2Nc%SAu?fL&(TN=mU
z`af>7*0%aTZX?zhtYy$1(lgrQ|FkXsZ)pC1G6q=xmP|_MDJfa{0Q`!@=nOK61D`V5
zTV~wfjGq&Qk=ZIgZKA{_4^2oI%0AT9a7At!uINF!fI0ZV3-x_=Ffxf<X?P_TDcKD7
zL**6v2l7C{icBCA1gl!=LqEhH4#d{KWBbin9lGi3U=-n5+1=!6R2%F6hqCVgjH5Ug
zzU|lh?e*S^r0b{NPW9BQC0UYXOYXgcI|dhw0b@)6Q)~zX45o!poH(Hb0tqDrLP-b&
zNC=R|%M0Xzt>yn_?<C|T<h@_3+uJfbJ2zkd=9_Q6zSW_b*K(CJM-VOhHBH5v3U7a-
z@O{qvpIQhmbks)TAAB287U~Q7`0HCmEcxHtGTUwcTN@zeiTfeBq0oj4T0mUTFXV=q
zw{HLE9+>^%=d1qZ2P1rfc&5Vd1YhYt;mAM!xiapDUsK0A?j`a8@V9|G6H`K}JWmD|
zcbv&lG?R`3rp=NMoco_l8Mf;~%rP<b(A{g6*mgRvxc2Qo9NbTwnWj1UM$6grSUI-x
z;bkkY*>~UA)y7+wzJJf7*IbF(Ir9#P%7Ay|Gi#P$Fw+&JFq)~3a%z6vTc>Xul9rp)
zBR4#fDLb@f0XklU2miGRPjVd>Db=Nh?UVC1S{mB-qT_woRk+|^8U*vM3cp!W$O1B(
z0EGHaJwWshR8|h44>tC-eQ{5|#6Z!1?vuG~D2HB|LpRWd|DPV3+p7OtUwzfY|9hWN
zf?n<bgHyLcJa{d?vhoCKHRwVxYzL`kXXd)jYF&^A3v!OaDj9_jShFadY~iDF>-3<2
zVJSb{XLNHDT+U^J48C^N8Sd529Cs@x#y-Oq!S>k{%oTYKwnprGSXozVP&suRHhy<}
zO6xw-Gr;W$mIr@0R^KpxtiFD1`orO-rs3giBTTP-@0ss!`f#&+rYcU%-HMf=X(#y_
z6<hnhy%POli7Eb%d#Sm3`K{laZv9K&v(NVZh1^m<Hou{MY^<hfbhs%yIuGK!dbwc+
zr*W8v;e`0EB0;NQF|6giUvP!sh~PTGaRCa7RSF=aOy#?<leB7m%BONF8C_cKb+URG
z7EB|(7<v`D&F6=O&7lCy_J(d_^`Ln9bu9HC?rHwhy%fp=k@V}*-q|C~>=7gndh_qo
z`~S|pInyz-ef*anzef6A`|)462hM-j)Q)d!Kg`kiy?4hZTSeK4Q>S8`jZ8z!-CXdW
zul(tsFQ`X9oIij17POy0JNzE*bFOm{3Z-6zJ&e%^vU9=l8}9JfZ6`4?_u0wY#;{H7
zs=i#VZ`y@lH@%XQY*JTO;?~v>eblyaqq4GsFtqsSqn3%UxqfcP*W4hRu8?L@CsL}z
z;^$|N&fhV6i1Om~a_v0cn*^nhw?7AK2NqTl<*~nzg9Cxd|L@5FvAO)>O~6e32<ss`
z2j=thSx`}84&Z`w@gIY8_JRwDH$eSFM#D1r*!&aDr6bi9-FWbZyS|nzF5kud?$HNZ
zI?iq1x?}TT)~wlisH^AZKJM4U3$U$B${VaY)%9M-??xLNM<MU_`1J4I@BE#vbgZFi
zWTYWGf!`Ch)lyHkJW+)=z5LiiTNB3BRr9*bB+{Cy83dUNDnyGV*mp$VY8l^LQ98fF
zpnPh@O(&<jx@qi(apCk+YPmOFPPsbY@8F`1^XE5a$HuVQ_d9<B%k4ER7-?!49XWTO
zEm$R!VZIXXO)<n?L&QGc=Ms=g4p^lqzq058psbZVH92Sa4fJT<szZbR=z|CdZB){a
zJPiDY*702F0v<bu-vWSie7*=@J_!Q>*^YE+1}IPm{f&O;+-|;Q@a&Txee~qn!Mm{c
zrr@9Z0A{6sK;B_^p0iDHw&x9qEAc#KZO~!~qR;d*Ge`JM4Y}Ko9=$!+(DL}xPd|Q7
zM^FFbJsmkv@#pY2PF(-<J(pg(=jR*Y4^s1*(3DB;1Ks#I%F~NJaFl0%Z{=SwQ+<$=
zH58xf?LAf8(02d*+#98Kra~mDVC<z10sM)eU%Me`Yo%aP@B<i|enap(!6$;xAkfy$
z^K!^9;YLf^0wVvL55wlu8Sr~RV;@?~6@4IO7o@*N`DajOmw*3>p?tfLc>|?l0~;E_
z%;%@`-~2h8GJaZt!5tlMUL$@r^FfCBzy0XbDXpJP`21;bx#+Ytm_~^jkJ|N>NSXuc
zxv~WkfTrRZP12uFuYrDy9C87}d(x1V=BwpO^w1=z8(kNPioxnl8|BitMI)`SYLza%
zN#}Gb6grh$9ewWtT%q4&gbuPos?Ol}Aj*7fRmY?*yG`OS6-m5KqpT>RlBsNR0~40Z
z%EjT5DvJm&Q3#1rQYLcS6*_B7D^j(pbe4>K5k>3OLWkLAVQU~!m0K*!I%AADs23~U
zVUf%hmKoLMDuuz|V`#sck(Hl+9dGs9{`(b^cOdor7c;_=N6USqqx;Zj`mLEG?2{Ki
zd;0PIxH4B%l<Uo{Sl!;fdipJ#Y7Q0Uaz#2eR?)s1U84d;YO~xWsg{Su0hLy**1@X9
z>d&}`=VI@*Vxit|j<GVQqezH%2r-pfEb^<38V#%VO6_!-sJ3b~L8&RDR7h*&GCkvJ
z3>Mk##Tsp~Mk!<Qun{fH%F<ekR;cmE6mlCjXw-Y`_MorYF=VyTLcE65_;uX(6ogoa
zVbiZ;C2uK{9@()ODUN*)7me=OGdkxpefXsn_hT<LC(Rc0n|kc{vK(4<Ln05=p<gX_
z!TKG`mLVU+SG-3B7Fq@9IwJybPt5fv0hT%#4~7E<!(<`A+L;V30xzIZI-f|6C47Do
z^3r&`pyqhs0mz`H7kJYQ3Ew>CgCB`uft6uU3}t@%7hW@ce9I2*!FRE(#C_`5<_-0A
z?Oir_yKbz(=Xe{d!gg5@>oy%M>7C@vTyC2d@>_X6!B22+KFxjj`&WKhRFCZ@ZXp=%
zzQ3H<n0@+8ZCYOZ!u4-sX^5sjJ#FTWbJt+me`Y<{iooaJp5BZ3Ueaj$I`^8)54yt*
z3*`TWk*;787<V?|r?JnPi}b(#){8H}x<gilW7&e2`<t<a^Br~0%JjC52UVnQ{-tkW
zTL{(G&so`>*8<-;3FGbGp#u;JkFwIE)mcU$$K^V~Ht5$pn+BKig=^A+Z+LE!4ixzX
z>|DnO5q=#-!*xiFi6}XpfaPcSg?vytEFkEwh!~RNI8l-;XPo}dzArx8w-4{j&fC^I
zuytM*@7p)MrYT<1+FBBC!mIb4yLI0_a?y&#t+~aEI$9S`zq+I)w_;^eZYlP+;R;S(
z5iTwcS73ju7&gIb2J?N%=~vT!Pg!Zeo5KE9%gJkN;R{Ri`6+f_$2(Q4ntLzWJkY#G
z*}*NrPsbaYOG=s>&X2!}9p{$3$`@0$E?Jc8m|EQ0x@4-YY1!2DtK}U&e|fpz*MZ&b
zOO6eJR7#{h{$z@4NF)*nU!&ZV<Y%Clw+OZi4hX(0_>tfjg15lg0G)vty32#sGr*k=
z0<evStd7t-{JK)8oATHSzD+pFYwlV;4Jb;Jgcx>#X(Q$f>E7Y_FqUCaDs^D@h><IR
z?V?QSU>z0~nm|R<b7=)KDKkh$qjY6_$&4PP3ow5^yCGun@C2+XkC=WU?m?A*y`Y9C
zc|jogS!bMHS;u`4uxekK=5FL}IRA>)8sI*tTS><|yXqe&>e422)9LlYGy2N#`qNEj
zQ`%)G9<T4}eq2$f%xyKq^rw|%mBxXqV<L;M{;dBdv+Y^4&}G2{VZExg(e{`|<(S^|
z6<^6q_Al1h%s2VZ*841?m>PFzsz~K&eax^mr>s*v?oeqSvo*G=^kGb3QJBq?aU@$m
zHkz%UKmD_rBfRp(&pvyRR{^%iJJs6lH)Z?-)v)FVUOnK?+_YV*?u^%kt*sMgl_b+G
zHr;7|`1u+A__^=c?=*>n{)|Lro@lj(>w_huw9~G(I}R_zg^E&#U2O8EpOS>azA{U=
z!+UkH#-KOMueIZ^@a%uqcKWq19Fjbh_L{_YN2x-HFFfpkTAcJ~Nl<04oevLbim&!+
zr!4p<u-a37c66-1@IC#?OD}<b0TGDnxO>QlX&J0&)d=4ANx^M``*}?Qakjz+FlRs{
z1H@-HM4u@liOha8pOOnWCS<dPJ?2A8H2|t;GLX9p4pC-)l-nxr!RK!wR+&Z_u2Akw
zCau#FpgZu&1W0nwwb2P6rysG~*$q&PXA6)s5KtG>!d*I*)Fb>SAJzwSA``9`S#*91
zGvLva-`v>&j9Z0wj(db6VGwKHy0*A0*xnuXhey1|oU>ux`B!u)SE355U5wi$>UueA
z#LYf^YvYp=6~V^K%=!gY*pDr#O1W7i!$#<8Q`jU@A9Uer4^B|Bj_z#L2u?8)d1+OZ
zOI|ke@NU)>ro%pqlbv2G7b;vCLPG|^N58zG^Coe7sLNU@q;Hn$+if*9xfs3c#zpMW
zOOkj}OyZYe%t`JOF4D0;xA7n*9OOQ|8Z#doqD9kBUdc@nU3(-_*_{U_T+>E<%_32K
zE%{6=vON4ZoGIaco84@$5`{zD?+Lrc9*zcMgQ_?QGsE12Q;X-%Pxc<G7~UL?O)Ov5
zc1qE*MCVR7s5WAnmtMG>tDqKJ+}$F{TB%Ia#`}rCNhPRP1X)3^;CrB1qKTczH-KOT
zFhEHY`3;VEuoUtZA_&v&I1e%&J9y3wxB%)TGMNbAc08xhBOU?i9uY#o2CK7x?wEfp
z!C!*+*x-S52Hr3ObvVthWrGT$n)wZZyr89`s(5sR+WC_Cq||^P@X{2Yd5}Qq9$k>$
z6gI>ZsYJD9u)5M8m}t>hNio|?q|LImV|B$|SNf{U90W{Nb1dDfbV-(O&?IU*Mk}s(
z;;QnEv6XF;-yIknmpkjKS{p6OJswYKRe5Ti>tI`XIVD$G&E`5<?sJRVe4-<S#K;nB
z+c!sxy$6R&<o4Q7$PwwUY|)67QkgP9W`bF3j0ouyYNw$n<{E2xcA>RQ>(5qKXSs9V
zY9_17Dl2QJ77QAs_1jG*Kj>%})p&Ki&21{yyAAs8;}`YFJo=(mr;svN3N5Fu4ism!
z_Fun92#p6cZi&??GOXTo?@Qi${W6o}&2tafghKs%O}r%)j~I#fnx<B3BpyleKywQk
z1|$e+#IHTJWs#DMRbhl>s<+gms7?Ota*JHMu&OFCpe#yvB&-sBQE^fi!h`Wzg-J}y
ztdkYZeaEjWSGc5R{aDl=s5me6Eb__AON#I}`}?}&v1K+}n1S#E<R{xrO;i6Phzek$
zAo!ON1{C-Su1abURP-7o@xL-XSbbEF&S8l^V%C?b0$G?+B>@)@7U>G77oN@BBxqOx
z2^B>ctVRfh@Gq05rUT0UW5=I9`_SM(chL?-tT<hvz~!+Oogv@ei9}uP#t<yq;cTV+
zp7}Lix2wjkbUGapx7qLTdV@}@J8PgL0lUa(_qjZTQz7jxaWSHSvE@e(9{<6S{Y}0<
zxNmiTXUU4uqS2vISnpwp5EEPNeq10iFGz2nNG~)izvm~(e)stg@h_ZKQ_QH~dh|y8
zRcVygm~4jWAy{1JWwS|NrC_FIRu}%DC_<}DR`0pLQ|;B5ExK4L!X6dB!rgZ8#%%S5
zm1m}qU5J54Pspq%UxWB#0p^6>af6PEh!!*@+D+?{g|wW|r8A_g)8^?7k(eCgZ6qM%
z6wi3`DlqCXezg@ILXadFZ6NJu`m#WedBQ@BLJQn`&Q^diG=Nv>3bc&q*qsMP#*=U|
z>!&}EsB{c>{cF13iX!d{Qbin+u*!rcRc>M!=|ZpERVkU&RlV!C>m4OTguo{ixGbO`
zScZ@j&UCd|BL~Cpn1A=hL(;M$uv#pkO5w1frntGSqI~J`<rles0TZH{zdKY^dTh=5
z{feRLaCO>hVML^y9O|CugY-PIzvjq$MI$T7Yrcs!oy3-q8*xHkslyC%F{NIQ_1;mv
z!4{4&B1$r}CBE>mRT^qtRpJ#9DS5rq*-40F4!r_n7#+@<%+i!pK0MA$bZ=f$L_36%
z5Gj$Wa5b&eyGOgb4jWaJNF~y0BseK?s=8mPt~C&PWsvntBt&^_zhhS*v`p5RaJ-;r
ztWM0Y^<N0zQ(y7rJbYa~H{a!aXQQRm{624zha%7JW>_f?vudz8;67}69%#VC5wit0
ziwqvxkIr;-0;+T|={(y;I8qIn{`seTRlKl=Je;6!rgcd_lq{(0J}<!74HF~c6fd$X
zFc;+MTrY#p_08)Zg099C7Hb;1en_$Zonxg%7sGsP>=*8fmLFeQUeVTEb(^p<WN|oU
zMf&2Qi+B5v$umj0#$26t0+1ON!xaG;u9(CD{v{5*-T!WtZc<Xo1icHT3}Y%!1ymM{
zl^h~eB=<#8MX&BP?s`V2l1zVqEjfubee)V}#fa!$GWS=a-H~XNEei#9Ir?kM2~6i_
zgGxPN*!4=cs+g2$z+e|qD&yg<?oqeRiL0a%G9(eoj74iUcTX_m!*T$x*~H>HhQSni
zM@&p~I-T|M6e04KtZEHOt%sGDZW)qLA|@8D$_(Lm^kVDPlvr-Sbd`EQT>vQNv@&|+
z%c&KJgdbB=f^oqH!EF$i!NP?87*>I0^DqX8BFOThl4gLG(J2pR*aL{rF&yL}1ABh8
zZT@~*0}50I6nX^LnLSV|t4CrS-~(<Pc+MS1$H+oJ<Tw*zk>{sS4mMuHN6)dkv^x$J
zqDs&M`gEZRUUnms1dya4+flpF)9_Tn1uftic_t0d6|k+qRWb;-KugFk=!8noi2Eum
z!#5n{I4BJHRxo~GO8mm3s9`CvH1blO;2S@uWEy@NFsTYm_;FF9(QXh5C2nOOLD<dR
zRmo~2Yf1P^=h5MTU>gP&R(*87wn>6ZA`Kd)Myj~Ys&5b}<6+fvTixA^0W%y(Jv*wb
zS1LBev!B+aTguDL3h<)c*sy(|EPJbiCc_8A-CmX4?{?htI@k(n%js?1K}%C(j>1Ty
zwlf;URJ8C?K+X`RGC63P-Lq2`?5%nI?e>7bfl1}oX;%b|wPCPBwZYyIw<l6seDi4y
zHdI_&682W4#KCH{tG+_dT85;?6=91`>_4FjhbtrAs9rX&n=sg4#T{nDwA|vI*Ip;q
zh;18vhJcOmsLGN--}D-tBJqx&R2KOZD{!izxU(VF_GfBSw^~Y=z!|Ui`MoBooapn~
z?d2XjmeQDX4!oj?X>uwRR(rXwD5losazT&o4Q#Kc##s8(hvbRL5UdX&m8zuDEBkM}
zqGiuF*09>^8}=MZg$=1#^8TmQI-H?GHjzHp*(kCZ<y8YM{ggR~vB!dON~v?jbIUw;
z$GfXnt|{)Jibpzj?IhA(uR}^jckQ}n!rDKY%voWzhPtpQC=#0zVwslO%*se_jgSn8
z$lL5<x+s!KdUZi|v|qvyZ^y#iccN>2r8R0=4Y~ad?kLsa!Q;sou|rP%k$c=<9<@9>
z{d#VoxUr*?DATH%U|I?2B;O>vXszH@!M8wWJ|cKg@GelDl0aG`jMEgf%{<>L;5BdN
z0^dY}kS8;rKN$n$<oPh;2K0pD{D>%g!!iGuK$pz3V4c?QMw)BBN;s&(c!hT69H~ES
zEDHO)fSzT{`Nz>7EqH`XF5bne)uY_N(AqRO%6;&zx%35%<VgpS3WGycaL&Jv?3$;R
z)nPKR(Sm2?Vt1s{W>m;EVUNk{V-#sejERrMEM82i$Kzs|TB_XZt`*|@h}BWE-(=$6
zvB;&)K@rwKQwBD))T@@2sFW(4w0SD*wPE!*O|lY`MWN{hMPKHjWTc@xQ^~zle$AHg
z{oEN@s7!~^J_!S~V0LC4hS)}x&Rt_5ErdbMy%BSHtqO^KO6YCfmXW}u<Wt;-<%DP%
zlMJYcT(|JUPdXPhmNsA1+S=4;3RG+T`-pEVH%2Nj0(^)RwkqO^RZ0wsO2zKOF1L{0
zn-q(?PmX{b<F4osUQ%1M{YGWv5}8mb_KP!>f!=p6vi6dP{AUh6(Fh^r6;jqyQ<6@~
zw#kEr&1IB2p0dT%?J_+jG!KlPKW;GD=+%KGp%U&kNwx!18y#0wWwLB?am!OCpWW9j
z+a_sG;Y+GQZoh2{xBFpTas9lju?MT)FGBL01bjP1|Adx+m3>Tbr{H10H3S=2NDuz=
z$OJB#Sys*?Akw<{H4p(O^vLK%7XUf<gz$w^20<Qh4xIU*S7{1Z$J^Bf%mgu>x2Tbz
z!1G?58I;Pie%=?v?@%&#5bIDS@}onkG+G%DVORc){>hWBT1)x;HBVVPx1{|;$D+6a
zv$`?bE>en2Mi1N9;HeHe76v_m!RAo6Ru}HbI4syWrs-L}a(z{)MVDzAA9?j|Z$%GF
zjAPYtmnkUJE8KGSj8^R3$XIO-F>O@qD^gay(;|~=TzK5h?m5$4Z*FTJik~p1n2zaI
zv$iaz6Df^4cK)Lw9d6Vq2TevpEB3%1P1u~dy<+H_Hd0ihQydqD5`=WMrOf~I6L0P-
z-ZO9=_vuCI$yV%@&B>+FP?<z@{x*?3UgA*gEY?>vY_ePxstT1=tIWiJh#tOf1NV=r
zt)*0V+_=DSEEg=vR^#1Wqb-p|O&c(Ko%@O({bF)zQ#;k02(#lYs+)bjl9KC8F*>#}
zmOLx$t2SRJPIuJSMw0vQlu1Nqs(Tt6y)YJ8%N-DYLVd>Pe(wUW^lHJyf_)J0n76iZ
zfzu%XuQShnkmN*!JR`$-sPRaE@}C3L0XujZ2<3TgAdd@(<XJv*IDkGciVLG>d^sMH
z>bb)xbB}ps%)sLr;V0{do)p4_y|-W+6Fxb#zNTTzrGKioH*WAdj0=qL-?JK)2l0G-
z>6V6?sp|$dtzPwk?}mo1>2KCCv4svP6fi9`QM$6yxJhn(=kdp|@3iN3KlrV0J-9mu
zSzj<PTCkPp-dMGI<KT5&4LA5mrZbc2>dIs~xh&eFGwhXnfBMsVo3H%VomUatpE<IA
zBljC_DRv{~-njnAGZ%La?)_oq{;b~V+`nl7e(5EHT^D~hQ&#>6_x8lXwHWcNYIUc{
z>5#eSwYQawZJz$!tyk<HXm20bf5oj|3LuHhN+MNWmig}WYZp#nu6OgVo@qiS$DTgj
zbQQn_q5^8UzX*?jf3_LmwH~q?9ueFkxL5F$;05rKyaSmiKgX~F{G!nJvoHjOY(|dE
z1taR*G+GOzpm>9gtFH!42reMSx}c!*u!7q18>~eLcme)kq~#S{EHJ{17{|<6-dn?b
zbsJrnjf(N|Cv(f@pXFc6w+Jmck*D+ga=;+hKp#U31Lu`MUK8W>PJ}_|H=y?;aYPlq
zg-6<SKDFK}hcu?AxVt!+RAv$?qyuV8it<{d3WeIt7#L|+mAXz%5}#mYe|^E-LW|i3
zxzt)_Fwt;VEtfHUT08e+)~*wYWQ*^4@Wq!OIz1(1q)Ks=!Ombw2#5aeA8e{@tgbv2
za+DR9M$S}*JdW^SPm$;Rdj?;dt3hth6lXmC6!uuQx}|gb&hE~wT&E{gdB#)JGZ=Q@
zA3b#2sS~HptWBTw`6C{~)Y*=UrArno*x*j?c)G-{)7ZF<#Y=VuSp|N#SN@ODh0|i&
z=Dk;6eC3|9SaGcQ{2yT#BWkX3i;Oy%7k;W6a$OG#HB!CWWC~AR<{}glnL%$+oU&st
zY&RuHyUMjfiK`4cR_wBsaJQ)J-aSV`_e?HXzWBb0g<I_!C-)N9gMAzSQe_EKj6r2k
zO7#}*=%<6N*{R&*{8mh*6f!E27c<KeHj_j-{Z?yfVs*BA=k}Ux>)@v&t@9^y9DCcg
zHS2a<zot~KP`YZd_|v~kM(c-DF`d)C=$B8QsgH7p%y-?REAJW_?!`VB866oK9T^4u
zM)46dWA$jQK0nW!`UEgxdhRFyF&h^In8<i92zc;Pe(weG4$KVt@_yV52oj!|p|Jvf
zfEWZ;BL1(VWwS9WGb8YymvC<vzdjq|a2NM>3FclobB^8Gvef8lZ1fnHwya#)vRPS_
z$rLF!x2zmYo9%XUI$mA<&x2zZ1`EM3<A;k6PI6ZlVj5mJxOo5U$@$+lE!(WuZ(i24
zYVF0VnzkO2$qsF8T6OVS#ehmR;Nbbf5#|K-IYcX>+|%<Rvf(1Z9>KNXLq8?>Snvr<
zQcOV~LNEvnF=imcQKmqW;Ez$x7;cC|11CU&9Ub!hmLKBbDH|~kkN`eBr39wo(6cHw
z0Ybi@3-Ed$^eI2g4&^jxX<Q^45XmAf5!eUlf%#e)+KLv#MU;y)2>zuRu;`QgvW0Nn
z3#up@5ak=gFHwiANPa6Qvv7*)L<%LU2elCXQM-|im<GWG6&D!A%u5;G{><yNe8XIM
zW~c*RnddDYUcjLsn{<X>rV74k@zUhPFLsA^aNkWfMDa7uqJ?6wm^ka}^0J}c;DeWU
zcU2O>==`QYPmEEBJYC#tU0WGVOIf)U1`d-;PCoU-vk(=bc<xE9ipbQg@9~<hQYd_p
zBA4BTNsK3Pf6``2PM-G(H4=jLI*1|yXYIuqi`L*sCrz4%ZVV9=CC@f-Klk@s?DNSt
zV6SWIeyt0R)wa4;b8k-VK2W19cDZi)?dIyTYZNZGsFv{b-TM7ozV+d@2Z>hqK(kqX
zeZNW;$QH8(?)z3kMhNwu@y5QAvRb543T5ri%6hZIA}n_|uOu~-^-G);Lzt_haxjwR
z{^}l#Vx<O?PUkPbl3KL8=+fW!XU0Fd-f-i2(}vE~jB%WM&nhRur8rMtNx0;uWS}iB
zl2ap{64tKGsHGBVz%NlxU=vSZ^4H&f@7LU4NO{-huHki^%Rgb99<Mi0dLY<!w&Q;8
zI6KJx{-X6CeS>%s!-N&ab2kqx=osBSzqYw=WaBMukQ&o{ldwj%W%DD{!;iP#bEtTP
zjwnm|G1dCDL9!%0R9f~}NxVVEkfizNt9O8RQfm)120OV|9{ls!=SIbvwI0>Rp(<H!
zleok=J%7asZ^=gPA4Wo~?61+X4zWb16Ok0f2t^Do)To@S&NtRZv4Mxo)FdWzm`vXB
zHsDbx?xl&3CsISyb-!SZU<**%VVEs*dqMIdB&25}M)HI<BOC$QHM86+o>Ao;lIZSN
z;;%qaAj$x7A)F74Dzr!=pm`cBG8NDhc%A`K_52tHqA!Biy%8guVST6$?B8Bx@Jn{S
zA}$Td_g*nK(t`V`TBBx_F!rQX>0g>VNV#vDxLJAl%u|aqVS7bRy?^H)FA>$0Q4YO2
zYnLlUcYdFH(eN1e*YRcV-L9xmlpEP9M$Hh-2EEd5Ds9~zjj*ESx7bkZWOY&M*6EK7
ziRuMIuI1~Ro6)tt>f+sa)2A>0WYzZO@XYusC;sANjoD^47|fkRL+VE2n{!7SBbZoG
zS>0dkuGE=GtDi8klO4$?tLmwLEW-w_b@nxA=P6>`iTYtoaj6j}rXP-#c&JNz<Kk5~
z_W*=j)(3QQtZG8$8252Y(YakKpNZA@Bj{E-h|NP$1>LZE=At}I5kv*EAVqV2klstW
z9Wa9I1a9>eNIe;!7Z?z7ctQWe?YRN=UY@bczz9IZ!ZL-xVwgW><7?E7E4b0mXJImd
z{g39gsTDok_j<TV{gfQbk{G0i&WDyFq4YCs$>eXiM*5w%G4Xd20WR57wp(?#db~cn
zXtFlDV7hg8Sx@)f4=l>ok1xp9PTsM!r)6RrcGH%K6Mq-tz6$ZLoRYiEd}CVqoOH8V
zH@BBxdra+|Qmfe@exSUYU1Z}PsUIJ&uUR<u4BK74&c<DjPP1bR&wm^qY*>=u?TJmo
zN?HUm$R=<Jegj^N-wQqx{5dao3S^LB5z|MG2H@U>NJb=<P+y@9IS#>?0KSjPAuKMi
z>zOMswvPf{^5z6Ef8@x>3kFmzFJ=(^!O$<NuV5{LMB|C6a1Q<tbeC@gk{?Lo!BEFc
zVcxRk;gZfz-9qG<u0YE-0+I6iG2b$H4sEFUXg!3P53#2xT15Ofmh6>)%U)dNbsKGo
zF=3qQsmn!t=hl@ZOQ=5>H#7u;RU2F1So8K1<tEk;9yKcTVtaL66?22hQQ9<|ylkw=
z7Sn_#m2p}7x`(!$Dp6)6rchl;Ntz8Qq6V3eO|-?bPO(^NmP%9#TqKkgo8>a8*II1R
zne@eCkwkBxHBO1r713LYLd~QwVien5J|US_1fYtD3nOx7HCF6M*~Pv$zP$L)UF*xE
zCAFVF=h^3BOg}N*OP{5`i{FD&=Z?#dpD*jLtR<pYytukFl3Gb-2eak)>&hFHU%VM^
zeEF`sKH1;D_#36%fB(M!So2C_bK8A;<e!H6TdLZxT78pf>Dcni=;b3Xyl`ck)W&N4
zEAL;{*wkCUXRC34t0r32kBKK1>`v)xo<6Beg-zx^UURh7dE(v6&2CJ;^re-~guW%@
zo%~T3_}(|WAJ{$kkjiz>`7I?Hz2E6l_hHUc(Y~S3!N=Tjn|+(u5p9exkFFiP?A7mm
z?}x-It`jcqnaJh{_i9`l=l&5V;{`qQBH<SBxuKbUy@Fv_L2C)DExaAZ1oLK2UNy{H
zJb)@+v2zvjID7n_uaHI0BLmuhrI&(2f>4Y%Nzz`%n}Rhi^XvelAQxx`QtbP1U=Df~
z#vo@cBjFZl#pZQ(mC$xy#wIfxRZ7NGqA9xlJF`py!kWEDk8*Dx;QsLA>&CP7S-;+8
zws~{eOU3mSKbXrM?!49=Z*CcX{avisz&(@VKEiaFXK+_r-#fw2&cDh1DfP@Vamaac
zdn(sf6tDMqxXraiMYZU2u!vS0>%9l{0aBC+1?45o;^&%Y*#!i!?%KBg>5m4!U6Z_I
zXn6U~-02RB$8n+}h1bqyAK8h{iHXaacl~heo#7MnZ=b*6{KMwA_cdONyHAX6+%W&d
z`A}s&rt?*$4_<Ls{=Ky`JQ&RjKy#YVe4q-jbV2HVo%Ro!8lv_*SINv}wa~$c!vF)h
z;3|v?{U3CF?lE^;bD%z5><Iaqa_&f5y0o<|oo?fHj(BSp9c;Pt%3TrA@0wfEWo_8u
z>6`Gy|EqGp4O1!1BPxXo<6ca+wU)x#>{w~2^Xi5NI9YkFxjd6=o<0Hb$h>~>l?{}E
z)!o(#HbHFL9`Mb4Z9foT%jCIO2{`j$sF*kRE5KuhCc_}R_&?uA+?nsm0@CK$FGx9>
z4_?miK^bBF5Jd5B;+X%%S~?=Vq7+vNg-4GHg$7aS6;l0uDM~J<Qjh4Thra$EzSLBD
z<l6i1zxGI}$!hF+;IDsupv!2zw87W^cxP|lW1YPn4>@wMTFqR7_~+npu%woWMT<|<
zq?%r_g0`GqEE22kP{IGdy~=6rop-NZw{G>_opzV2t<ANMm0a3?+v5u2HxkKj2<4f`
z#g~c<U4W5uZBw)+Rz8k=fR8?0^Pgbz6@|~Gc9>xSHw3A<fr)cN3pFr{!<lBBAPF%L
zPauLoU+~Tz{U6YH*S>`dFFP<kesKE9XAWKY^wXCgdj7p_J0E=v*4x<$(Vk-?4NYUy
zk6yQ8)v>Erue$!}>1`qzJ|Z9HYA5&X#_2_4nLwa)x@v4F>GP%jw?4;iTzJ`K3&#%}
zC_ePeQ&%2%?&;~b9@~2vMn8s0v*Y7g2+RM)if<fSwer{zZllv=*)xbQUa%lgTG}}>
z;!A;T%E!ts;pe^>VJ72J-W$0a=DieRe;A|(AR%6b`8^j-eNhUiyb=J5dm)Z%h4p3K
zdD*P@fXO*y-}>@8fFF<=Mwrp+(X17N-bIEZaBmH8j0@*Vco74+z`MZUOBS6Luj?$W
zs;(Slxcgz1ihr3$v>h|lwqwMHAMM)m@{3rTd&tzTfRzNUQb=5^SQN6!B~2v+hT&?V
z8ZyfY8<_HRqAXhC2&)`d=hi)ny=(5TtnTfvtn8nD>XG%itKJQE*VcA-SJm|6_q_4_
z$F^ME*A-@!Dnrphg$Da8HZT**H_LtB<N7_<q~wQ7##T}<-tS&nPsN#f`KI@|H+$7#
z0|XUW+1SwV6-q*LXmB8^*r~f>w|JvQ0UEp2k|NJ!w@+c*$;$rT>dOB9r?zKr!noUO
z`?_nZ`nmv20=1w8d^G*Qqcs4h7QqU^w*`+0o)G+8@TTAof`16U#AJ|R%?qp6#IQ1u
zrxfjU_$dM`^t_U+Wil{j1x4(Gz6LH77o*jop#=V%m#VzWAkWeZ5>=~*u;(PihXM!{
zINXOgJ}m==PYrNA6mEsa1}G?yDapGU6nOqfK_X8>4W>YDh8he-m%>Bj%r~?^0VxL3
zGIV*yzeu3B<VQA8VN3(#%cxy5231}&M5b0AArbZ<;|<PvfzPY51=%w*P?ljYGy|bD
zG?w9sIT804zL|dRk#n%d$bY@fJrXK%&!84n6ro948@7>@LIF!-RYk{!E=e`-%2k#d
z6$~*kBlf-2S%!OAdn8SXWQ6^YO0va?$!TWw4vJO~rAtMeUFs$=0;g0``09fXiNokC
zMh1lvFBu>SOyVZsBB2$*MgBgalVEU%l)4BAKgWJCExGa3C)1~U2YUyzI7yr6KjIig
zi8aKZu!qn^Qd;ct6gQ;Ok=mNJno6h3S6S(E<@aAUh3lfzC6RQhq1fXpF0F(TL}?)1
zRvbV7>D+>Pc=wZmNHF|qC=`eYt<$$yvG>TW+h-6xQABdBItWCwL@RYdLP!b4WYk^~
ztt#yv4_78DmY4e}8b*T(Q}MQL*c0bCIWFBTRqU7H5)spUB~B>m@f-nxGW$k^PCZ5}
zB;Y3#<U(fVfW*Y40VAde_?Z-o5zF!gmI~1ULoS2s61Y4?ViZ^3@`H8r*I`#ugqT}O
zkQj;6Bz7Zy30x$bht+PIZN%mBa;-Iqva&=Czvo2mXxyB@-yE^o-0ESg*LCi9!KR=)
ziEo`#YI@fcGxhy=Z)PyolL6X8^Cs`$eGjal0diAZ1KxjLC*Y$T5PJh;ED+i(=>Tg(
zil&~&QovM}fk-w!Zh{Y#20oZ@2q-{tV6X6aVc?F)pQ(A9DnHtrDV(5}@NqamQ@o-8
zlK^;aYlbo?aQznupr9+X=OVV=dAF=xrCK(F)w3!?CY+_#c*I)qQC(~vt5%g{iEvd#
zBmHD-!n<+pwU0ZU2$Ivgf~JEWzwjLH$CZDQs=~taE;-G8&ZwfI{|d?(?yw=%q!7K;
zKeX+J1(=A$emdda6%R(li&QO*1J6(2yGT3`-{qbtdw$@`yeyNs<o<12Z>_9;;#V`6
zHG?w84)%1@n{5)k{XSzm-B?W3h5}8Nj=t|3u3kE2`89!kZ)x~xpG1s>rL-I8K9EOb
zVk|=X818vtNGieXlwZg-E1bc~F0;WX|M2-83l^=%Dk%I#+ghuwMAw^4oY9q3thGI|
z6vqF1xhr{?dSSNb8o_25)!ENWJ>-Wi4C(WO9RLyFOtAMu6n<efSeT)NWRx%On}8q+
zq`)cjLpu2&7nmTJmyU1;fWpHJ2}f{H#9U|(7=b)Uz(RQ&r2se$1CDfmhQTje<jN$9
zN<<LJIo96!l2g7`70z%^yz%Q<K>o46th=oJhkxNG2IZ#X>73ezt-ADq>u>0ac-N3i
z+$MAOZ?8POc5t1??e@6S-cYxYYpN*<N+OcQmqs|{t?iq*;|=2riposQWe4t8a<{lJ
z-G}vf(?5RRW0MuhWL>g|%g(GCEpPPw*WY2ys+rlH+25MmD?5Cb^BnLqZgE9>s?`?n
z#{@>BQ5MqFYov}xrvDT%T3MZ3eqg-E7h9MNdA(KD!|9DnaANn!&W`WaUXHEE%~MWj
zIamKB<BNZu13E)KzC)mk=mfQby@G>+qcHRKl;8ou%Yt9c>Uq4*;N?5q4={l~hRFtb
z=KzuhZq%`Q)VT!*M&6brVPK7)NrE1k87VCs12t)(upE5a01@=)g?pr=z!lI`eBem(
z6rAet5|Ew9E0Tu5NfgP<yUi;wbQvNqDWvW2Mkena*R%P?f`Q79<joy%{Ys^zaP55T
z2`wwPD4ccik-ZBV82O=zbY0{2)@Y@WXfj{YZPu>5{*+Rvb+A!exm=E&n5PoI(N`u*
z%1m9&wsxr{m#ObDt2)AoZp>k;DXIvCDp|u=wqjJL$eGxz%GeRFbok|>j4MYIE3fBn
zt`%Z0aebw@#VFGnhg83liG!sC({$FD5$Y&K*yEx7x+MKaCdB0i7EpU9@1t51nH+u5
zwgW3MvOSq-rS6*)!g^_ONZ5O3`pr!}J)6)6dvC^CNPE=&wGN$}R><{^OGcV5kx~<v
z*v9RCb`5#M%KIB=9AgXtF$@g4m+M;aiL!p>w$SLV%Ju{!lQDj9=2SRC6_qPSJhs7b
zf+AYns_9>Lu_G6$v9_>`$&fl#DdU6?J7O_b((4(+um#(&?OQgCT3fno#YUwz(b}6~
zXlXpxnoz5Z#jq4gFLwVs`DShcyhFJSt|0}qxv&~JinjxDM+2$Adl6~#SO@Mi7=1;j
zb17ZNleSLF4~dWhxn=R8g`zE&UU}dd6(+GQTe{712P6Z~$*`6ssS3BP2Mb2s20M2y
zBw^)ZCZ4`?V?U-QaVHG<)aoiKdR7D)8%oHCRfnxAN$y@b*_-oGViBe3pFGvao#}PY
zTMwSTDEBP&AT0#zs2S#LfUcg$E`+=@HYML?Hm`dF#uqpmQo{8R83&|-2qb?ym4qM@
zU|!(z_T`HLzLSoJcJKc7BRh6{2Rky>e^F7>WnLmnmap%vud{eOCDk!gu1Uk}Sd}_V
zs27anhC0^Xv1r5DO%GvzxMKKKj@vajZ|BZ=gS*JrcR%#d?j4Uja_*svH!dyJt%!uk
z8f<iAzBl3Z9mZ6w1cr8<E*oth=q~ozA`8~sas{^P-JRTP&4atP&zrX!0>)u&Rl)s`
z8&(D@uM7)*fcbbnjec^TFC!)Zqge3k5#`T*kn~08Xu|ykg%LgLK?$8xmM>?;l2Ewd
zpG4FPy#=$S0PM&j2iRAGzKb?KUNN0QoP9P3J%0@E@vD$f=VQ~MQJ}&?HmSVChL^B;
z|0)=qFqnYmUTMF20G>s$?fk>}didjlG(r&M!vi3~8ew5EEcjPY-+4@hM$O2X8UB??
zGnxe}PHH+d>;QXhYpJ@r*k#AY!v;&X+NvwAuxc2BFz6P;l9`7yE!S#$wD5n^swqk`
zu5d7G{Z@NLty32nBaOx`lbRM1F$(vlRSFEJ)DZY6p@WxKh?REr{vj`mi^Xz=!Q)D|
z#qO4=y$sBAPbwW2dm<_cWVUL1wd$ODM^BxJIDeHS9>WN$QXE&fC1S5%rhy=OjmV>N
zvxG>d#YS$kD%Eb1lmwK!ZE{-U!wF2GO4&qA*U)9Uex15WeNkxuUvt;KV>Eqi;~k#E
zo|lU&4A)rNTa6*h+Kvv%wz@-iu02ZA`*)r=9b3hiE_u+{+HSeVkZ{lY9c6U3cOOXi
zDN|y~O?z7jrBGyhh?WgsE~iPc-7J+xrLv^_d_RQcpVG3}ewoRk<}QVa?VT}$lDk2f
zy|y>NJ*jS0Uon0uMJ*dRsB|bw6<AAg*)L5}Y)LUZcUq~z_Daom4YymV#0FH>mftfr
zMi!TW=#{5r*xLT6h><bMP_?l^BP1BL$*E={v@9VTi1|+*+IR^?9axCQ<!iZXsRw8b
zC_n_64Hts96zM4+0se#Mo7KbQXFK@fKodb!pF$(LF#5{7l)Nc47LrF+Bq#x6@}dxq
zVf{G%4jR5iD48MVM4uof1)(cMp@6-XA2G-yULuaty+FhfJce!n)fEUKUkWgk$Gp5p
z3~)C;3eA&NUK&Hae2F~k0S<)_9JLJ&*#xSt;NL|Y7>Q$OCea{$K-Jatcy3L2OQmCI
zIX+h23CmJ)m%F<f{&GF{0QRjLRxGL=-+3qLVXf^=YD3EHPAuK)It{meuJzTPy0P@R
z1Ck;s-lym&t}?kPMXSOnObThEg!`K=q72_u;tz+Fa<f;($}E~Q?ozrIocCC>SSB<|
z$^wB<vdOG&P#a@qN_krDs?GVeU0S`}=S-*jNvn0O%`Z6}YpV>3V1(CfvWknXqIm6f
z_EKSxR39}Yip!`c%I(dfKlX{AG&-AN7<XXo`WIm67B@O}bBjWaVQ+uP+O+hx*HaQn
zw5`!CX-g)XHe5ZL%~4A4ub!Pe^1b7rSEq|=yH?RkgTh#0QAw)mx23T^PbBCoul5_X
z200@VYNb~mmBE_MjLPDOarUUrf{R=ttyctlivlJfm=zkCQYDh<j4;+Hk*k$Lsf0BV
zB3Lk<tSPm|b%a)Dl8XFNHx=7-+mzI)P|+rj{=}jkH-e0002dF_`)D8d?u!IvFiY$t
zWTJl*Fwy69Fc6cFpWTn}3h~`MpPM-%v|$X491uIq97*M!y_%O<h}$AYEkKi93sM)c
zXg*eorc`h#j~;m}Lr6ONrZgI-Eeu6L!34xf0Fp%!_n+(h19t1oH-!50e{);7+>dSY
zB^B3YT^_x`Ri|=#Jmp?rOCn(p(E3u9O87h5tIpsL{Y5FSFP-#z)11)uD}(Px9^yWa
zFQqdp)1$XOc-diYebgW(HJ)vDPqkQ#>wbmpsB*l^-QutpscRW$KVyNRZ82Mtz3S%S
zscUw1kBXv_l-pV*-F))*9xMQJ;9bQ|%XuF-{6MJq6Ii#7`&?%}XC`(vPGM#84=yPU
zhfCL6%j@eGB>eupL0W2+Prv1Gd0zLHf@e6HI^wnkxQ}ZZ+x4`xZqvm}H)5(iHA#|D
zw;pRuR^gpDj$_u7+-FJ!yHIJoh#+#5x39EkXkxT`bj8hdX|!x%3Ns$?xAa(r`y0wc
zz7*)G@#OSpb~{Rt&wzgPSMqu4V;G}NgZHUX&;hYQivjjLyZ|aZ=<)_n-a`WyQ1%6+
zEzNE`ZXi4%7(XyAd)~d8i1V|!fDvJYAMy|}u!tR_Nx=LC0%Rj%P{fd?3I@TK;YuN`
zvSe|*<j;#vwyTV=Uh-nrN2on1Atp41#A-qqizXRI*Uqt`8?_7UwT8_$r^^8lcR6v%
z&PCJB%Z9MqO!oboj?wAW=ni$e)5v<2wzB%L&;{hcaUUEQlG_wkwgwZcS%b=DOsYL%
zwWYEyp`ACxmEBsa^B?cH-0gO792ixY^L)-eG-M|p-Qp{q&f;ff!_#9P4`kv%8J4)`
z=_{%C1Utc-`l{d^>~FXS--PeQpTJ+i-^V{AgoKS~Bsz(~yf(x4*o>A2!MD7(0GxOP
zVvZ0;2t1bOljt;^$-4sbv4D9lj9C5brUq@!1_Ka0@6D45a9%_b@S$~iwFnXt@mCmL
z=Kx?KH3jBP@;sR*HfR$NkRJFndUgKI=p{&80KGx&`8}$Sg)kq!IxvX%hJc7b$|fR9
zNYH`iBb9(c4PS5>p$t@q!ks~!<UinHM#6x{mwXctUI7k3VQ3gkP(%Cyp&H*dDC$r1
z4o$d^o&y$xRHNBPeF>!XqKD8PX;0|jpUpqMDftODP{fMy=|fN-6@D3dCjTV*acC0G
zS0#`ljebSGYv6bC{V}5+&UOy}U_tJo>Jmte<iU!X%?s!JFUvQB_Yv?aY5{`K5(HRH
z{#A$xLOb|J;gH9eLLb44pnfQgAO$Z(^YD3<6)xpf*L(wc_6!LvP?v#&pZCssVR8cB
zjr^Vm*X)bnT?qO3_wwC=T9l#@P86DkU<!k^h##N=aMeTbPeJbh52lgg%5#3GBZaU7
zilh@LBsKq2c$|i-I(P_8N<u#X8lQ&QO2ETGfA<wy7v?iA>7W$UTrm^PmY<Y{`UKhu
z;p*@f9UvZkrB`fK+hq-62_+=e^Om)~$yIR4=j;45<Us<bu2d~nz{->%SVh!mrX(^P
zrx}BlVPtyiTUayxiGIBhi>nM;J*D$XVOBM%3eY|wt`oUsLakP%)}1!Ug;pUA1IB~g
z{WSwLOEYG=*!;blPF9($^%2rW;qoN>M4wP4)*C4eMMYVWPXzx)rA=lCW2Dl9iC|u!
zkdR6-OeR}Bic@BLWA_=Ov4n&iGFp>Of>zEHtE8+_tzfk#Aw?=liCBVTq?FQ9a*0eU
z$7H0M)X{1uPD|t#3CuDU2_;fO0z3v+LKLkO<i1-ZR4FK2s<!DQHZiTIB?c2NHHnof
z)@*>K3B;6+BJHG5DyCE<X(MUYB*7V(LZnn`DcmpBd8D`q$1npZ7EzdPAvOqczZ#Ok
zkWx~&!xJR+LLpchVN2Y&s-x-2;@qyTBCktImqWc}1R;Y4>)uaO2XJkO$z@_;MKI!2
znxtM`L~6hWjLI6BFVzyELWC?MW2}s;s8($Eo26b>YIG-csRm-+XnSrk@wm_?Y;$gD
zt&p_|N1Qz}DJ68YiAh=>Q3aX_oWO<BqLPtHRw#GcH*+^QvXwb2Njp~dVs{c6X}5_n
zL0qFwBni9J5wlyO%<0GU8MTshSBjh-S*ZQmlY3aXOsR2Rl#9hISFJ5uycs49aBmHi
z)%@!8pKiDU+x0V{G?J{hi=b~svMFU!j(l`A=44TX5rYcIy%P6$giW=iY)!TSQ>)A|
zWtEcXz&dNa05w9X!eVYQEm1D13tj6X8B(k$O$d#c%KhnDkw~c(9mnhRRu^+AOB;<W
zsWuX)l@8WJi0CWS(qd`AKnkgPQS_n7HJu+}WdEV&AzGr5Dj|T5RoJ8&xzb2TSf-H>
zd4yuUoXAK4Cq)V^B{ONDa*ew@gjLg6P^Z$tgi5i3rOYr~?34o9HbZhFvrs7V%2?JR
zw@O8~NILXKaAlHaFmlQA(*{B*q4ZKZBrTFeNP|Je5TwRSN7Ygf?bRC;1k5?{kuF>!
zk)Hoh>U8)dEQB^)2jkFMT24|p#Zn4dYVZ>T!DvOKOsrQ*B}Q5&5fU^G;gB*F9dh9|
zLc!?7z=$ce5s+CbRS=ZMBT}nbMHCaNZD~=Awo6qSoFL_tM^CD)jM}AEkbs^Bg#{;F
z6hn&@Kq3Tg#*yOXlp1jG42u~dZdZ$Fzz|GCE3FhOA~hsT9T6L}L2K<Ii)YFRGy5>9
ztc8`-X*yP(d^r*>#@3b*En**-0usGc#eJ|R<qw+WSi%6h7eN6RF-Y`2iyR}wm{KRz
zI|&9GHm6lhss@!f)5T`Y?KSJ!VfGLi)-2b=mmAY2iJhU#9F{hQsjy0n1k)4H2B_5o
z9$Mz%q7sb~yh0ETi7RZhS*X&B)UI$TBc@n&g~e<m#h$t?lPehsCKO5W(aOW!+~Y@!
zk58<_zNt!<_x^I-kZ&2$AlDe&A}=F1%3PCDpU7;oX%tEeG2vh+lCWFlF1JpHSzOmd
zL`s@4TJ$g|Dy7A5rVONdT@59njZC{z2&#=JLyAbT?477gu9o6Eb#fBa8koyp`(>%H
zpIRi4f(^ir66cvQh!&*A1B1?Ue&EEA?5DurAutT_W@G~7r!n#TAL$k__n%tZJFsil
zU3b9;|9!|AYAL<QSC_B}ectlv?sBipX-m}k%D1$@t-japw^jFy#(q#y@q^fCkFEOt
z*ZRn!-6Nxq?%w_AqtmN=I`ucW*M^d^Ws}!Ve}J2=oeXp&hrWS@)H>fdw{86UpB_5&
z>4LM^ez2%(xnuNmV9&@wmt77y$5CDa)JPo?Ss)_)Aas0rSqmH-bd>xC7yZ0A<l~46
zx)py*qt_u`&&$C4H!lqfX37QeFrd|--T)yDFQT6-bH^Ntc9Eow5#Ky7c<`7>^_s>b
z)aZ*hsshfq5XbSRZMF)zS!Ue%c}R0=XH4mp4z0RG;Rs}_S8g+kyrf<!k>f%ZH?mg0
z-da24JvvxZGl)K%wbNyBxRsJYvAoz_-sGf(gK@Fq;$dg+P>rwMURkxxI{ECt1Cge2
ztu`iSDMl7uw1u*>c9oIBaGSHfcK<Gngmh(Vn-7W|EGyNp!uUdAV+}#JV4GX~p$aqi
zM*dxc+~S;ub%++SR0rUSRIuVp8}kk7F+Q%y4PLx*7`NU6p8e|}YWG3GS%g1G;`3Sp
zpwE9e=4Z7)XMGiu!4LQ%ot0&rNL}C+OWy35g%#30;F<h3w|X=^E)Rl25glklp!pO$
z7#Kg1dgcVwyRU8$bB^hO#&oK=HIZt<>Y7u@mX>6)WjcLPf6w-vJ^fqo8{1+U<KP1L
zabJA2{i1BDG)va3xH+w{Mw+qdtJKk`P^+*6t}b(@dP#-4C^B^Qb&L0}N;n)+oi5$~
z#oroJX{a*O=y$my#<0y?7E!qZG6(spzT6oLSPhV-qKAmu9PxnFXlK9pajD*s449o}
z>rdo$F1TnYQc_jvy82Y2x$)fV$=X_IUJHJz|Kc4zJv+CZtBLiB$Hbl`Dy5lxcGH$r
zW5c;MhZ={g+t(}zKI5~BQ&&ZD*U8I6W?%Xqb(Cxy-m}vlcUd;9T3O%iC~CwuB(wFY
zWK))tDwLW?ps1)uD8d#xU=+Nv$Qh_P$63QAjzA5uK&A`C9KM=qra9sY)Bs*kf(X#w
z$J8`rUNwS8>k`40JSPE&AR_|-ZSMF80(3Ekd{4adTF<5sWfoLMzZ(>CxPgp_IUCfG
z&ctK06bV&>EfURR0#cKcdY&#ZK86L>g#tW)px^>hWLWxRpEOz{>UNmz(=QKKRt?On
zsv5){tE#J8dgG+0VFhgyGmPS(Jy0ak9WH8HAfyxx>n9sDzQhvgA|fbulcQy2x!}+|
zNsVeDB@#<*@`}1qT%=~@tXN}GsMIQF)w$nr|3egWM?=_Avnf7k&^t6Pqkfm0I&0~$
zfSAoGHGi)ho>yHpF!1?3Wu2X)*S-&_xT?tLWM}83*gkOkBei<9`yyM*uc<^&I;ytU
zgnGrP`O6(?!lu<4BUAU9w77L>-ukpjfq7eYwnyaFaEl})HXN+lYOmTzRGyG2ngaNx
z`su4h+#l3xgTv}>BZ2@U5y0pm^DUYH+BHIcf+c*!{Vo_I{l-62E#GT=-vcjqtAIfA
z>GAvpfbn({%-sk0Am-^yKs4YC_~0>~2j&5T{C#j?#xXE6tqkR}<k6z=J#!t)^I<n2
z0E-L}^1;P*O%oH14U^bW*6212GY+v?FYm>s7UQHe%)R(5HSE7x(i97Z!|{35)dxfs
zEvB^xm5b%mf5mQAl_(tzy$XM^T>L&`c3DIOEfi}5N6y^wmoFN-J36|#KcW4>j_&S`
z!(W{f9WtR>uaL{+tK>Z*O?3q|zix7(sd3@d`D0$EH`ZPO5e`SOk8wKu8EL!1E$y$c
zI$e?C^2fGsPe};tQx~(rBop1>3Iv9W$DY2J4U}}z?238iwo0)vdRKGJxo`FKbacSy
zeR%tC`J;{=B1lPdv3T^}SXBjt`=BwB2zRsa9_p6`UVG+3C|y8LAf|yH_^t<{;$ec|
zQh*oCUo6np%pJ<lAY$Q5!cb>{3jYbL=z4yeONn#626;A*AWZ^s@~_W>9qoD3b>@^-
zEv%`VKfkVS0jHm+u7{)A1z23C_lPHGd$F;T==OCqOqpULt;ZXXhjR6G{ZV4uPXlgu
z!!@#^8Zj-$8Sb}7aY@M~zU2p$X%X2NQ4b94&<gv?D=v{%R8za!LSm!6N~jCxYN|ID
z)v#`yAapvNQP`r8tI6sKJn7Lnjm8)zDDS(&KC(z95BX%-Mv-1-gz&T?8e=pb1(m89
z8>_1uo9M3|AFZz&TX6o@UWdD+xm0w%M;BRm#M7#eWE(o`5=CC$)lcE2*pe0gpv_*h
zs=RxhPGyH=AcHuzLtC~@>l5G2EUJxW>z4$S#?t$?Y)(MFgELcPYdGU-DBHwFa?6M2
zRqePu&?htLN~5t#za%KJU2aV@OCDb$V!U-Wz23D}8XJ^5+&-6j>`QO6+LtMo#-#2A
zt4$i8r^$i*c&0DMh1XLLKz3dh<_au>5%wPle!}x!fHfkq3mNZRfeeVky9Va&0nz|E
z-nF6EA&BNTp84|L8Xh51kY=b*3Rvvi=kv#?7QT+T`>!oosA+E5xuKlQ(YkCKJ{oN2
zp4&X!zirFVysguJSlyCawk+4Wikv4;t=JTLv906TP~>di;15E+7duWIG!?l@Yio+1
z>FVkvbvnC2dfgFwxOv;M_{brDhr}c6t=mgl<k31`=$W3Am%BaVy8<t?LlvGMcecIg
zhbr#eYY4B}Q2c}bf$s+cPxtqoE%v|A_HRnQ(0<~OIZ}98_tQcDi*0Q$dfY$D-NtG9
z>T3rFYa4pVkHs745`*|ad1!e3rv9Pz>$s;{R;<Y7mam$oXw!*<2QRzq;B#6<O;O_V
z6h>t07ivWDC?k>%pH46OQLsuPgc-NEY=OoRxt!}%%Wgf0{+?55PFx0m2f4P{OFDUV
zQG&lqo~)lYQdc{F80E#-$!(y1L92K^;(>VEf^?>5^|T8e>IGhcT!OqCKTqZS2zoKj
zvlO0R6u5;JFr>h02%b+MztkKi!6%DD1yUJ(`U35(poAf~lS>DxE9Z|?RS$4$7B@9b
zO*J(w#;0LSM%PVS#Sv-l+z=LQEw6F46YslmM*Ro7*^EPeHYfFZoxG#8^kQkermDIz
z;M}QsX05XkatttvEDfp6U;v<elg6vmxY{>ty203Li7eg##%n#@%=ud5iRR`+qJ=zF
zJvdZRH9T*3{>6*Whn!YtB%8t*BBYiY*$%TSc7D?qA}$|o#G*c5%=OJawXy8>b!($C
zJaFeyk0+SC`bT!|gNmNpyg6w+_@D^#QB=4ZsK7;g?Tiv~rxcApDlU3M#7LZ88EHFu
zje!uyTVYtDxtX_HcF<|+*Pun875um0OQ2o=jURlJuty(=6o=SGFk^UP^tq!9f{h(R
z-JCaQbi7|U@2Ug1xPff>88=9m20o1Vd|m<|0K|O$D5$V7l<i}9Aq=HKSAq`$1(bmN
zxx9uAVe3dwL$BcT0Tz6ddC`of9{G_YG@n)iq&0d4WCsG5aK2F>Jopm412HcV;1ZhZ
z3R6;1VW<}xkWuqk0j<dZb3w{~noi4CscY4vn$d&N_Ja%h7DQ4^kHip(_ksmoQb*NU
zlyw*$RV1ocbT+`~Zm|i!EZJH6f>kAdL7@^YTi7RT$zI|h)b>c}kjf?wt7>$5*T#zv
zzuH`(l$XiDiy)*V`(%@Lt=6$b)|a&?tvXwyBrK7IeW9OdtNtHv?;Y4ic{h&xxqUi~
zlTN3-w`5DUBunz%D~^-cu``?<XYaj8NCF87dxjALA*>V#6v8SL!U&XEMk%`#3cRJI
z1qyTliH_grIoUw_d;k5u9FcE4_uO;OeV)%Ao4WS&b(^fzfQ?LLDk3_%))4I>m4~%~
zXW!eb_af4i&v7L3xLiJ+!7{tHqMb5a=wSW5+UDP{sEc`v{6YdUXKf;eiHoM{!4x;G
zArR}~hfgxoJNh(;42sT_5fYr}>v->ZTQ+EtY~g3qZae+-n>U89-Y^ZVxmgRGit*8L
zvkpfJ6MAayI~*kq`N6e+n5V7O4jTQG5Y$|-c!lzcO-CYchSF?bvu0DErZaYLwpYh<
zzjtqNH#SA451tdwb()$knb5%X5CNB+uIeeU{pj0-w)=%ooYN5<pi|?mv#kC$-`y8o
zblc|c6?;OLoZRy`D3hi|Ry6WntFaTUm{iz)`bhqHn{Uya+KP=%ECvEjX;E%u<Mf@7
z1-=6O_UEbGBxJV*Rh$pLtr0*qtZLHX+kzJnhAjXUL;+hsf(pS1ASYFa$G8IkQ5DQb
zE!ri#qyjs`QnHx_$4W@K#2PbDts!c(gz+!%FKoQ-;o{EXru%bs7o!i9`P)Kf{bE9H
zCYstMb7)wpCKBtd8(LO3WLi*h*HNu6%9jTtmF}r2omco~#aVh!db+2gr`%R)yx}*u
zDyLEAi4Vz)^7@@$99BLlUi-Ro_rl)hjHjyg)z_P<i05*hcZ3l)!D&u*D2LFVWQFXm
zQQj|qyTVbNf}Tx<ihr`ivcw}F1=n(*S=NW+30Jtmk=EbPI?IvnjJnJFwIok1=TqJ1
z?r)41uOR{f1`>LQSby>T^2vnDTBFoeXK|TZ)i!&S?q;lI)4^}<zOv`a-Y@&C>^l&&
zV1_Y%hV`q;#~88V4Ks1-S_da^P}`RlyShY27d~F%qiaxI?xm>*pYGAs$*L#<oTG4e
zB^^o0Fz~~|g=Aq?y!5f7z<)MTDFLPlpy>w(7{DE1MZt|q!-$TKxpZ9e=u<UI_(e#F
zL&!o}Ilv!qAIjm}Ik@Z_=Kit02@oHQP=aH++vd4q``qTU7^=~fC}=aWNix~hIpqpu
zX;U`TPPWww8OBkeso<Qh^@FP%5q;QE-M_#TGkJ31P<v-px~0~W-`kbS6>OQ>);^cP
zriB={_Ktecehg7s;wn+I1iUkJQ(9}AT)DVEOF$?gp|dntGg2SK{~`Olf%FP07&m!m
z?v|z-t>MhzV29rl$=LR=_IWlF`lZ1rnqza<%n^h-?^^nRk?|^iOX4rG*X(GWJ%sMB
zJky4b)7P}->mCo8EajoRdy~ar>R;(g))`u+9{X(Z;=MB)*Mm8gC7m1MlEa+dm<iwR
zTsHrX%e*U{DOZR!>E=9evqo}RG&LhPU$@Cu`{#xuG01eE^%&!icOtHH)(f9G1j!PT
zsxRH&Iey)&Y13wJDR*jO3|Gl9m&J5JvnYigyKe5!kI?l&pKYNtodQxybDUY!>+LRQ
zvU}5xpO-)XfOGD_ZO`7cdh6ZIJQOY0o_;1aIMe1u!iVD<9eUE~JexSnLeu1iX64)d
z?7u%MT8ndaPLe*L{Cho?U0RgAEJ^<jB+WYTXIq0gQuwl<r6I5Zlz`X(3>>Oa6K9<R
zldej=z(A(v5&&?8YnTcF9I)7c1OSdv3kaJK*GglDH$Wi}&Rq#cW-u+6QgQ*N@WXk$
zLEwR20;i=&F;U#IP!kEunniyktj|31#oxF6`@uVu_wKy^Us|?b(2rd5q{au*G_&`{
z-nvMHvP=urn%Ry}`U&M-<+l$t#?qv{`Z!u%%e=Mo;Wxe4Db#a^=;ZdujtoN@{Agr>
zfIR7CcTernaMV>q`}KcP(hHwejw8Z>PNI{ix6+GyZt=%&UA3(%o9W!{w(9%Jn{^;T
zCgAg$jqTTWIrQ49DzM3PfvP1OFE+jrqKSn*NV(IYAv@|f{wykpPC#KpfEP%x+aDo^
zLC+EdkJ=uU&xeU&8LMPTmxRDbK?3SNw)*g*SLe4hy%v_N!b&h`Kt@yxBDTI+;aiZy
zIcKO!Fw+5JEPKhT&@h{x%%^8AyXW|_nTuN{o^{s5<^}VZ?A~)wmXfq{TybT;+c|?W
z?3@%Uualy6%8cJ$-8}i(rXaD)T+_VVFlF^4m)v^m#jjqr>$>Z9UAA=f@+rl6hR5$T
z8i|_<5zER*4O+9{oE?*^_w0f9^22*AWS@X~S3Gzm*vs5-Cal)&NtfloH>I(x6?_!N
zftSKS*%a^?oDaSV%gWY*=5Ysbv-?5YbXnOoW!IJ6Qg$137R*KcP^`!3|EYoyLBUPQ
z$Qq%_t{*{35(N8LpAGdhW%y@Ba8x=EwSM3{isEyn>*_JS9?eF<4hc2K$J#(NAXq1J
z*s%($vml%%%CH3*f(PLQ0Y7TDaEK8nz6*A-eHK5RePZDsPF1}-!uBg0woVz^x^-x1
z8&ne6G6Ok3`K9tV<p46Fa^(}k{L2>Q6Q5G_DM$LLCBG~#P!uAp6p2P4Qs?(8i(eoH
z6~(7~OpYkU;{5yR1`SG9=2EBMQa&b{6@_#eDucST`>fhLnGv|g1exzbE}jSDWNS)l
zObVH-kUu?mKXsC6){2s)xCFY2Y6B*-`SkJotxueA(2sw+4i9h2)@}4#w<+JDjn^xu
z(0jKjPoF-m>_k_mpgat+D1Slu)2C6xZMU7e1YO>${F=B5F28^;C=a59@+SG{ZMPLK
z9&1?Kjn5J1A?hmS>QgUhl44_pp7`#^=1Rb=ZwnK#?Tzkujs09ZAJ@@f4N5Xcf~Ihm
zT2^aMX04EMES6T5o<4`A4J4s<S^Q@qrXy>kS}47pYgPdDs5TDeLiRx>RAvJx!d@;a
zeZs2*HcWX+8~<abrcny3lERWIQf&-ea{-i#D%AuU#XvMeuvzcd+Y8-`?D2u^l|!Dk
z_GVv`8{Mh=Y3g0^W}9E{4_gssrpU?}qO*qg3)AoF?3yPQpPWkl9EB@7MUglhonb3D
z(;7J!Ef|BHmjwsPCy$E?9!Jrj+_m+~x(O6ZN>Cko67MuN)4hI2D8YHdy$2f`XQmlR
zLVsF(TH@*PZ4;RiZ?>1YpH|eoKUu&N^I)amcZO}0&4P$Xb;DE^HVNXl17*4DvTUYI
z3KHPy4rfhcdB~zcwJj8(gD{3@X|qC!4ZIbsr46ou&OQruw^ig@4`s5M``fl{I&#mW
zH{A8hy_;*$evP&Fprdg-c**^4X|udo`R!jnRbEG_Pd`P;gNOQ+M;(PpOV2!2K@{89
zZ8@X5U_E539e?B)@!+{5M{2Iotn2IEroX)A)>RjuyYQx(tF>z<^lmm>TDW!9oywJ$
z?x>8>9w*hgjaL4C?C8kKnIpft=MVA0FK>3%c1lM-yJX{cNB*k(235kdDwW?-G3AE8
zn8P4FAoE#t@ss8qyVq@*KWEJqdoC=_>Dp+xs_xe1S6r~<HhAjB-f<g^2kLKKe&B*7
z$Lg<Pw;Y;*jNP=6kc`SofGf-g|My()_&=FzK-nNj0d$s<gJJd#bJ!qX{U6Qy9m>s`
zzw~Fbd_ER1hZ7U$H3<uz`hPzESH|q<wU!BuR3)SLI61@A3C(@FMgQw}IOqT3JCtZH
zh`pGkV!k=2?!pd^m@j!_{U3dh+Zw9JpVi)6(>an1S7~?+vv#m4+Ss<TGnJdN{Qvof
zk$U36d4<-tsMUnJ(4>Z%x*>nKZBopS?aRtd^yf?zsyf!gH&LYls5-^qG}G8$3^w2e
z!LuJQ5lkZH3$eE+PVx^tpK1|kgxES@?C8&p;`AvxLbPvDO#Aet+tyRazxawYvmu0#
zqv_zD-y!SKdp{CQt|sM+Yx?!>?TP!){CiU5zj~G~c<Rv=xxPT$))(unu73Tax2+F6
zZqq<E_wL)Scy0O23$FZbe=6T<Ned)nd1hxIpw>@#hV7(3fGjpWVADDXnpLnUV;mY`
zu`U#kABYEhbtb4HRvE-zz?x&5DsX|sYc)w02u?4_OsY@?O&~3;%A`RLrF9ER7Ys3@
z7#VimfU(V`Ovt0Yvnnl8(KztYj10CfXl;ZxIQ|-x3aS?wh+(6OeH_Gu2_4qY;WjXX
zY^O2zJAJLzSF>$pud=;i&jH9r51}ZOrDtTPNgo_!8ZW(L+-26vP=n)=y7kC^J}XbK
z(8Yxfxh)&>b)E6m+x<gCsyRaGxX9M$WB%@U?>P1=*WB5j%J>_k4w3aC@LM6{{e$J&
z(^qcKP7Z4`7mjZd43w$K25utSnaMWD=H4cfvoheq5YSAS;c<sDQ>(}ER)Ph6Ucp~8
zEjWB{A=0-ii^2zQWFK@1=q-y;Z<M5$IEJ)6MWT7q4d}9)wb5DSf`bF^2HIG2Dc7rf
zraaoCC5~-OmnYNf*DPsTeRjqA(^sIsLkRV`CO7XIPPVP=Z@c(|+ix=sObmYXTZ*<2
zsO=nk@ePCF7&>+K!0ufO+FJrC*1+X|sXXg#_;BvsS_68;freS}p3FVPyV058IK!jy
zy^{;wEhijla(H-YoxL#fFfA$jG&-%ypM&tOr<#Fx%|TtlG6Z(9suDnC{aEt_k-UJp
z$AlY|u&Qu^6Bzj;a?V@;+FSzt5`0ClD8&5x+XDoSE~t~7<TBb(oDrzZgouw*HlxnO
zXsnbT%}Cbgy$LHxf4iRJn2QO<8VpYfg-*?(Dt4uL0-|r15_y6aJhd&Xjt(v{RtG|v
zup`}~_cR#&M93d2C=U``kbh1Wh3Zt#GP&BMqzi9lG~gwI>D)<nCH*GIa&sYH=7kV1
z`!l?jRel1m1-ukg(8P;Yg+UC~@P0pL3@SA$t#(rw)<EgS0bHTcs2T!GD{4nM9J;42
z5!{d36fX@(W(ytQvRxzuq(jQ6(%j<SV1<FM5|0DJI$QuBRdpnw#$1_+EuNg_Skmm6
zJ+G41yfLzQ9A`1OK_6q6Ov#3x!RcqL?jjiQY#Ux97;W0t)KpY<+2!Y*IM2cv&pP{x
zW^mXS<a|7tTmwPov1ja-U%oKz94Akc;R_37q$a0~Gnjpbpz_dXUv94JLgVJw7(BcK
z0%&s%NAW|GO!H5AXKslNMxAr6&D?%$_Nv6@9gqU>nK=_1vm{FfLWIuQ&^vs>mt_QZ
ztvJ3WtT9(jUmnS})O92B8*6gLu(R-o14w>qO{&}>dQ45-vvdaVebW$nXV={26RN)r
z)VKF(q@(EV)*+97>t^vGRBqh9!QVM+hmN`ai1O-{8|F;V#wM6^kM$XJ&8KhRT6=60
z3C8pLea%x`%A4hn)w{|YTe0l^{ma}5>eVtIWbT?>s_j@p#8|t-WK}7=q}su=k8w2?
zF-!PO{rms|pp5$Av*M4TDwoqBpQ~RiDq`HJVtPo$f!UZbhC0uk`1~W~@zj@dmoz4x
zS*KGT-{LTvZt8w@<5#~s<MHQ_`R>OTS-bDN?6zh7`wo|XFy*GF8qbMK$eNCXGH={?
z1!#7`G5#F>mz&PovEp;3r`VdlX8)sSzM|ZinlpDKlPpj7brIJqPrv-DawDnd&hxf5
zq;8s*=&!i@aQ&={4xX41KdZCe7F+7NrKxp7ptr?h0$&}zf_IzraW6Qsl~?Xu^|*4n
zBRlPZmGfVj=bJV>JMM8_0=x$J#<VEM*%#@5LJhUwmwi!o3TcrG#UQ4;9Sxv)NY#P-
zWO}e(zJ#%{y8}!C26T1tsOnHv=Yf~ik277!r(wQF=Mr{)xHQ%z>ytbPz6HYq9>Lfq
zqS6GQ0Hd@){V@0;KpNDC0WAaa1v>oF4p1kxNofHEu|WWygRKp)2OR=2QFlk}J7cHe
z<HN8(&o>4HDvry5SxLqtfTNNr30?=<!ML!SR1_3KrS|G|3j_%OwZg~|YQ&9orCw6=
zyhU?hSb|HV(YmFE7*paGzzR_npN!czOVh-@$muE)P1Yd6w7QJ`lmu#*j7+<OHDrgi
z!m<lBIW-A^8Q6E*$&0QrNgdurf>-ZNTawXKBo1qfs7RBrG(!!oWU7ZUxX=6&wb!BK
z3|`x!w_TidC7T9hnrO98oY9rFS{)pM;37$~@|-EqtB3oYW{$l~PvJ-s%}7`Ox!bNg
zux*+^SJE!<wB#WONK4tOL^MwTKjK=hu^c=^8Hn#;=vlp!zZdj+$iuF;kWz!YPWhhF
z3k92Fay2sf-S%<~mGnY9o#_8PtA%0+QrN||yAsN)kw{eIX!A%>r$KL!wUx4V{N(Pm
z%Uhm~X$74_nay%RADxh^f+;y8wCcdS(%^R3+aIrV>3xkfO|cp`6-t+PP8vVSk_AD~
z$vWy;-d5quTk0v)sn-rh2n|1#<eXia^6qupPLvN!9geS%Ap^XicbF%&YZ58K&L<_P
zA-RMOq$CeziQl4pKusUgradhbogT^@N{app2;c1-YMVxql${JZ>Z36P4wo^}->*wq
z#7*G2$}{6up0V<(*+V_mX0X!;tJo@=V4=29DbB-c$LE-!S*vB3!Lu(LFc@`O$V5yC
zva4zdrGr>!ZKSLCq}6P4Q=-<(3znKRCsRg~RKe@J%XeushPc7$F8GuVtHxxq%Mc%^
zT<xrMX*H2_6`Fv2biwHiH71oSsq&mCTSeX15Kg7jxWK8^1Zy4Q*_Frm@91`j-Ma|<
zXYPdhTCbIT0)^IFAgcaGNNW5h`YQpx*+h!yB<2wth}|mZ8&MZHfGY;tvHj?ed+K_?
zsB~=Et1Aqa7Bu;h#HxF+05Fi30NpzFx5P!47AgFKXVp(AEA$GszX+^+3(!RD5r<6%
zSj%1-N?NTcQ0f!%Q(>F|2tn<d{&B$g=2Dx|xbVGdjKb(>RED_JAq-l5mmjguPj6Ni
zY>7(1gp5(`v949DQ{oE%dEmhWtoRr5%Rrx{vEirubS_m32p%(>#dG+R=K?2C>UnfV
z|9=N~vec}(crw(8kRM;Oq&tDL>TAJ}F@D50EWF_i9Y5S-{jZa7A#DkQ7Zf0`Qoshd
zd%+DB`18}L`N^D?xFVdo_lNOgp|bQatdmg@Hc=YNkLQ0J2)ydpX*}RjkSOH&@7{@a
zOWvShsV=`ZL03{X2=&cg{MrTKm}qpGG}dgoEksp>qds3eQGdB}!Mxh&-Ek3=n6Y@;
z-@W!a$OID$3DL$~mpP=o$E|Z|`&Mo~dw~$KSO-67T(CLDGtGNw!Mn?)X)|9C;Ee;h
z>U96~^EH+b>o$9ZrXKU9gpGl6K4;iCi`h%$t)kxJjnD?dC{B?m*0t7YC}(0(bfI1o
zUB<E2R((vEZx$U^iV!Rb`;3^_mv#Hil7VLuX^qBbzZ4P)tk$qLbHHTs7_F|_#MEk+
zw~~NBgP=d$r#D1>T1vxdP4zW3RaH8t2QoR169HGp{e?iVDjF&05b(xfK_m&2xp;$Q
zH1K3^s#25;R%+ssO(|wpr$}qY(VE}}uYG|?LK1K@qhk~GUZ2agY}f~W_&VEcDCeb<
z=UAfAx=z8g;LN@`3AbL<X{7Sb=w;!gMXQw|ZZ+IJ@zhd-wlH~;2?V>EDt#ejOlcZ)
zpx4`ShZ#PoKV%{Zt47acjYf;U+iLL;3`Z-3<jN!@gNJbYG_sd93-JuPLGCK&+~5~q
zWi=6gLyD_}=wp(#TZ<`L2NC!Jx+0ONF;`X9cJw-C)#!pyqs}MGKHlbQNjvNH{<?OT
z(qT5*rNOB}(kiowunhuKSfc~IoY6QZ>&?;06a)E<W6=U=E*ZT)9+9QuM^bF4Ujwz1
zEafC5$0Wt>X0#-H_KdjAC_oI0c_kT}?LZo4`596;50N#?Z!Sz<5ZRT_Pv&V?NP_}y
zm(gT*b^W!Xs&b+x)d^(~{gpIv&O99@TWv;1`TpLRB_US#cB5&z+!2ct`h2=TSPVP;
zh_cgi#A>k(4Cl4Hj&hqJgL;$9So9RAvj0E})`THI?yb=wSKb+S<{7_-*J}Oei~|GP
z3Vm(<1#T!3Z<rv}<;(Mxw(z)-7E7m2*EA`$sfQHn!c_%pdB6SHwu!M&yPS$f>t%aJ
z^at~V9H>~oEF;aIm@ox3mTWla=RJN618FThP<^PTX1v4V7GwvjONbB;!P3fkE_tRd
zy>oZD@wGI)P491@GFh|HW4FsmaNdG=e2XDqmE|@aP;OKId{4clGK`ik*&AifYD+FV
zGi30N%XQ`RGiL6rZGMdF?Wzg1a&w_L+UDlXQh_rI$}UG3k}6y5ftsvGXQw<+e-OEh
zqE*W281zg&848c1(j@O7J<Z`BS0bZa9%3U9r*T_9+qT`{;>C!`ZqP0_cqC&b!)T=H
zT;4HzL)9$p)Vlh-)^CpW+7sE+I!Wx>W8B-0gyE(pZ>zy+R{9J9v%j?}nAZku^>Z8!
zzs}p)X5<NW{_JG6CF<5r1<|y-N$Jp~zR_zf(Hh<<PE++LFLO2Y?W(81I`B6=qS8W)
zGk@6ro1~3lyKDv&D8SJYU>^jvMlkaOPGlKy0RVHM4_Cb{s6t}tCQ#9os16|5F$oh0
z1NckI7~|%#wRvm<&Qcu%aGh{710*#&dX1}bS5IC4On$`M^v=V+mKj|yt+;&Af|av>
z9h=nOKWk>FX*#GeMuwk44bz7g#I9F{T5Fvt#=@>$y5r0Vd-u2I=I!X6^Tg#)ML-G~
zXd%M)^vnre6!s}^L)`<Nk<OYcDh!%fl98iUPw{-Zb+-M8CPg$v!Wli{$nw~rOD9Hy
z_G;3E2qZEZQVSMTlAAX2^SNivG^G4>cl$LaTSdcl2XFlA{RfYDn#T1`ju-%sX-x93
z?!I^TxFzT+ldZsHh70FkR280fh4SYIhu6(OlM+csE)w(ky`Ds1|1B5x@_Ius1(8?n
z6`=&Axse*|GeqE_CT8><5(8=_D-ktTrHZ`<Gp}#1g$S2vY`l5;Qxc;CV==-RpRwMf
zMY)f?lCgob_$O4Seqa1a;9nGG7``t2!-Na(sZ{zuK0Qo64k8(oY~VA&m%#o`@Gq|t
zZ1}bQxTj_>z^Bw_fW`p6A6AA#_o_}D44^<`p&OMnmlP90%<sTcK`RC_4jzok-N5L8
zU%;G@>iY!#O9jXsgvSWS^$7eNRbR#e9D>{e?g&__ie{`COk$&;bWl4j^@3?_37$Zi
zS2|GrpRL$+B3}SN#xH5H0wVy2c>J)3$@ADhb&tK$XU_9oMx=9zQn%mc<ss-#cDl{c
z{`)?ti%tBWgO~2~MlL%x>!oX&&)S@;2RVabUG74H@@joDWSyfrY@%&yxjO;@T8u@b
zr;I^b)HRa<$}^I+ruYz#On@yQQk3O^@JkXnvqQ2qmJ<b;W+1MTMI=LNNM4I%tzd}w
zGj$M*2$6)Es!&oxPjNvL0BN1eE<;QW51E+s5RR$Q&>kLDNXqmLX}>AD#5zG3cJX>h
za-6K3?rqTrI~ZoN3F7I-r-UUGp%;S?(B(Ee1TA4M*J>R01Qhl4H5+NI&O=ju%^FSG
zVrO}wo_f(1_eyTRS8haA$jZ;EB_T}`Imy^oxAov-&B2~G+nf1aA8bXA-%LC*Qo(W1
zK{k+#YwV_O$hu7~vCgcbMH@KkOY}mM5z=wx?A3^hQq?A}%_zA+vuO8PtuV<DI;yb*
z;xvy)Ed<?BjF2V}p=Bc}Kk2Z7w^oftSJ}g5HKZ_e4n$?@ki%dH>zme?Ldv=4*`(0G
z1h*5Js?(G<GO@d>dSxXvYoPg94sz_3o0bTUEEI~QqG?VPH4_<QFi>lDE;q0mf0U5D
z`*gNoa}Uc)Eh^5unEfr|fvEFvSqd_ww%|1dk#1$G0<mC%9SG3IE|fGw0`H&#Y$1fO
zhfpL8u!TKr2vuB%ozfZhx5Y1&r<BFY$B+GE#RKRldLOl%_<H*t`%WnD761L$;h|&u
zuXzDdxAmfZ%3kMH%D<`#yI)s6a{lJEM9Z!>ln-pzC|}p5cf3Wd`%bw>c~bdKx%11%
z4!ww`p)=62FCX6jz-tdGpDU*xyld;Z_wRTDtwRr--;(&^A=~T9d<X&Xob7_0WaAsJ
zIN!lI18OBIZ*$ui3bGUTfE;xjR7pPx^>_YI_AR`t2ruYEW!RByY%4Lfc-05NM+Dvw
zV+1u08KZMG!iUBFLU?IgK#{IqM^Kdm&X(3YXs=34ysEE&epM8~{2(j<+YdzC?<?f3
zqe2nQWJ_0J(c=vx3wW5S$AYTp;AX<8O(2n6)MUlChSadIXxKu-h*WI`<Y3BS;uQ&+
z*(eLuFf4#tu&9AMgCXQ0Zz^~}VI%<37Pn3LK>1h+VvD}=L8BZ*5EkrPI<i>SIy3Vx
zm_04VAk&oDt8Q@Ct+7?NZRIt#SXXhLdtYyBb%fNdDb%0QH!Ip(bHFnHv2yg~>&@fW
zi-tzS_J#^OB^moKwQ>e`Eie1}ho)HDI;U_xj<S1w>BeOH%%v!I0u2$<Z|Ym-gk&o9
z_bctw<bMsHbl0D`bVo|Z)4XUBqSv8wZn*QSH<0z5w8qr-ccs2vr_5A7o_6=TkyC#}
z6)5^CB4-_5_uLFZ7dpLA*%7S1c+ocUFg0E86ygCcnRO>BXLT$)J(x&0FS4|Vo|J<%
z`#8PXMEqU}E1xQ#BQvt0_YW?%<p^NGW;NHdp7g|^sHxn#Jk0Vt+6^IR%{Fv?$1J}s
zWSSny52ueR$54ke&J8r43)QzZXHRnEAc(YMa9poARH$X_5c%d!+`dTp*P^E9=FFJU
z*|f=*zturI8LhpsXFe>=@PzUkf|kg^yrrUcbA_$qgWCgig{x*z`RAp3_g+q(x$fHE
zJ(=iG9`fu=FS_suMBoOE4gwq`lg$mBY0~r=p_xrlZ#@fPl?KMfFgnp2K~?%P5n%jz
z_C5M5$mAabJ5npy;y09CTz0(dMA=JFY3lco+5hvhf0msdrI;ePM~(XYVhX4hh*1e2
zr7m?yIBA9C=+THD6yU(|sh|o<w9@JaZ<kT3irJYc81XR~#2PmcJ%32zp+Y;PLBlHu
zhux@PT~a1k3eZt=DPaOYu?p(Ag$1kS3f2O2^}~;fV4yEddSO32+AUt4cvB^5fODJ<
z6O&f!fBlV)9)phzTxH+8z3|pY%IxnR>Y24^_nrg6(_f=CcOE(CoXv<>d~#rJ*Ysx+
zYxlhSn(`~<ncuwq)+<o*w&~S(PHFC&HsRzzfP6%*Ds*kv4%&@~FzP7-!7g`Mla3{+
zxg#bEX$)vW$qaje#%RwLKZEjyyhf6|d5c{XD9VLI<3sOP1br!<Mcz%!BJC8~HJ$Bb
zLIau>n=RgnwoNV+CJ*IuL&{y&d?KEV3E_lbgXHJ69=q&|#H`AdX812-v6yX)9oTXR
zx-^^rN;*NjrY_&H?b_>=>Hko^pIx_M^Tx9lUUwZ@{?R)%hySv%|L2RM4-IuIDOB^+
zqbHtHo>!hd`N%I%D)HT)HMaNPMeT2{3&tENCX%6fC!}VDP-`%Kt(evxtyd&DTB#dY
zFX;&0h&mbJytGjiDT)i)b+k+pdYVH5XEoA3v_AQwY>)dSADI)*zs2o#Y3jm!4cFsk
z>NEp^!s*}UTU+zhU0rpRc6Tf%TS?NSi3yx`p2=hk0wdIJvze#C{x2wj7Rw;Yq(!-y
zJ;)f!GLTPw5qMo4R4XGLFMAkjr;XZnA!~$+EL8}`X-$4qRAY>(GClw^Dxj2s+czL+
z{7(g5jM4#YN{uYoj~yC<u@rb<Ac`e(&!`5tgwjj50jOed1#zI{hCZqrw^ok@mW>6R
zjb#cR3rHI~2BQwJjsS@V?>Y3hn;ughQT8Qg7*lnVq0sZzPKa;MWx%;bbTY!UPZQOX
z_ny6$tO<lsQ}OF<`KdE=H4lwgy$!XE#932GM3Mz^&dSPw37IT4H8bbr&{5^i`N{>#
z#o!IK5VhTM;Mt3BIDK=-J-!fWB1NjcH;~GtYh2|#l$IEXRxGI-7{7#CGVd&+EgA~M
z8-lS=^de9i#gtq$8cL8*G$Fbz6bVL&$iF{(<-FObH9nbv;?-Nnd7U*a9UCa8)oHD6
zt#@fa7$7Y_<8Qf<t_vlUE71Pj_QTv!iZ?d5*Uceo$?*oxC`FrB7RRAZGy+)^FHkO7
zsT?0#d-5&fmztohgRJpIEV3)w*lBL=9<Z5XL)8<;E$nI6*o-@SJNb#%!hr4%CHx}%
zE%ry^p}WJefCvKw`i^VFZ)Mg(Z3qeKj{!vo1qYapN;Yy__6p~d!;t{^+e2FEQFO+v
zec>(TM&;-`FBPU<`wWth>6vS%*6fb9p82zXd~x*5j`CZMLt@JKJx3tN<+WdauY8H-
zUGgj{JYD?PlgdlaA6S0}a^CydpMS1=_VY89XJ2~%<5w`RfosFgge=QJ@GXpjWwsaM
z9~Y_cN`NUH<6I1}1Ww@+&coO!HljMDR$K8Ac0k4O33v_jAXXsZ5EUN?s|Zp(h4}zK
zU`p^*E^z@E&P@QQ*zV3abb$nG?I?c!^^TV+cw@C&gIou|E8cr8((j(7urFNumFWY3
zjD;VV7JT~ViP`(ksoi?b?KdCpy63j7D}OoT8ReV(8{0Nsbmy|mmifgemEt>JJ{1T`
z%h3|lzt$@tjs0{n-%*k5H&MT<dZ+l5a<p^5@>!(mp5S)0hM50K{*CT%`S`nDiZx!u
z%{p{w?vWJ+OP9C8=hI)fqT6a-zqGQYpfTF~(_NSE-hIXt<)m_#>xQ#Kz0_tDRU96o
z8abbZITT<HZ(_fszbT8T`J$!)En5y174|{x#6wX3R9*dGF&N$OoB{^G6EU`7Dg;6h
z*#1TvQKNjTsvaF}g{??%A2^eP@>t!0#-%+_Tn7U<GYs&yCCXE<u(;XilQIR6%4Ajf
zn=fP`kVKU?BY;9I(a}D#7WT^*XDTl(tr!Rrjgin{<+J109CFz0-G@4k9PC}NW83`9
z!wt9Z*|l4F;^4HpS&5l*zgJGr+VbX=18=3gQv-`$SigR6^W-<ut*z-1T~6<7HTZU+
zRF%Iua6x6p=x>sWA7^Yazu5YBxT@81qCw<MMqYb~*B<jCZ@=LzeT~7-p-Pi2vQzI*
zbCxtu#Xos;%HyrU)(&dlVCJ3kFS;i+V`}p3RaJwN3gg~*wJlJ0<t4|^r0(>go(s?3
zv1{Yi2d{i%Wn1#)$_vly>7F*U>Q-x&FB<h#eJkQWa_lTA<+H)l?yx5lQJ+-&RZGk!
zdvv~jQKR8yS%l1omKS_YvRjwiK(nTF#Tk~kV2MYJWo__{|H@9JUx7GoH|T3{)sR83
zXRd{uSNJ<$2Q@Muh4{j^AY<V_p+2t(`GCu<1DnSnRD@lQwxGS}GO&N#gC0Y_M(>~x
z(Pxm|SRpt<By5DAh!bg|9xNi0h-t(Kv5MGA>?Y17E+wuZju5vI_Y#i~PZO^Y?-Kt*
zd`5hOaR!zGph$uG2mKf0GwLM~h+;6q$=_j7j-|B1hpOHIIH4?<8cX}QSxJ|#wgiX+
zfW!_-WA;OQF+FNagglHTnt)rV00_WiW-+S3x8cgo&;WxTK7vM!tR9b@fxdod3sC<<
zTfhjQHGv{YkP<IfZN>Mh@ciR_rCyr|+^>u&lnUQi)WHw=@tJCvm<s&rct#tJj_s!-
z`|%c-iPCZb`vSZxT*%><f%huyt1~h>A?oztE2a5?FfF)y^q>H`5wP&%V|8lOwm-cL
zovMw?N27r7mw~WutozAA$@d_TYgNhuDToDG4Ogni=d4+rd^vzmsdwO0_}YK`RWmza
zDN1b$f3XP*H!RtcWqbzIJn*bSRi1?aM7*n>3#ivX6NJyyBd9z&b}?U)AMthUNfN}}
z17NBBVuk}>_~CJ*=S$-P!wVj<MQx$lZ1A&6cj8wC%8ds%y348)0OF+@HrIr(pa~4J
z+D<(MUa9Ov<qIf^yHq)*bimTeqkZ5~cct?7gC~?%l~*7A#eI(e@kl=Y@X3Mpib^xf
z{?=nOOg$-?sexvDT(28$X}9RnMvsA=l&g_-M7CfRk=K+KJBN(rl+FA?NXsZY^Pu;W
zoemSa!E*f^&si(Hc0uFZci_tH;o?`2%D}8Ow;Fi525~HCu8A(tgUFF3JN@1VA)?{}
zlI0AsfKj7&q?5#SUYC8@Ebuz}y7{8Ff)?Tr$_Dw@B2~NxN+Zy==Gi9E6f<Yq2|;HH
z+-vgPZ7MzmOo;0!D4l560k3Gt-0cxvtLDi_p^Un~MuVrPz4#&JkYn!2BNl7(M54wZ
zI_H5pvlde7IK7K@`h&+^R<uyEdkm7Ki_A7_X-a@%=6?gqy>v@BvTb8Pw|uhKsW&>$
z&IUhmc&uU?tRiA{!Rw-R;s%ppd2e$tYZTY6&_NVYpR312HCKBrI^!8Ly7LvHWzQM1
zb@H4ZcaRae4=p<M4Q1e6lqoRJ;ME2$=5(x|;Eb%dlha4w|FyI+$g>{3@*O4EIB%x_
zMu$F=U=q+qS!?5sqG`YiMrPTnS2T7`)}pVF#l#wH7ESR(HwjrusX>#Ovw?$qLWH;^
zi>`Pf3hG!d<S?&*;_3knO&32Ue2^N;CDJ^>cm+x_XcxFRmm)gN2GF8OM!SizK{1T`
z?5usf2{MK$t0AUDBxOyoz=;k6V+<gxD0718RaVdVSRp={GLt@1pE%43Uid#Mz?0Wf
z0=%Z4w-bL?&QP8M$NeYJ5V{(LkgO~%zJQ`9UwGz8<#pwqr(SyDX=0wCp~~T8HJ+WO
z8u@7iGRi=U91NM~jfloOEo_}}=YCn<zDIe?VB;J<q^C^mGyzSme&3l2th+#QOFqeL
zb6D7IM!U<5cCSgg_M8!s{}!j&ix0AAE>U{G&)(q><CKi1fK0>Ano#4@n|5wgTspKw
zBTDInMp~u4P!z=rtO7wp6KeMP;Q4?u_Hhe}SLywCn+#7#M38bEvePu8uJdbhhI1iH
z6&l}aE8a%4sPZPexON%gmjo_Ut_LkavEAJ8T9tgsm4ug-taekJH57jxxNlhFZFy|u
zY$rp<*4*+IXa>zXv$@`G5e0*m4ZQB#b9KP~y-p(-_fM$SNI*JzO@&IyX|VKk!oGcJ
z<rGR|oi{P!9FpQbqh4>#RSnAX$Jsp`ZGRtq3WFp398{FCRv26+12WzNK*4a9Ch)Uh
zDbBT7uyY9Xw8$ZWGfAIbtMM5)x!1;XRzG1>CTdwp=(cEO^hdA2X`C`ud|wbWIwvZI
zIYx*OTCLuz;aDb8{ChwfAawcwOVd%Z__m;R3*hueq35|EC%CBM2Rg4D0W_`WSeHaN
zT%xVlWH2c@$h4(rBkXK&Zm|ZD0qqnZjTc+cQWimZMPg(-B^v*SX59?Mnrmo?c7POi
z7l9$e3ouIr#|gAcGDsJ(kQSX|DAEu7Bv-ck`z7pVx)HL^j)(f6vw+LE4EV_VG2N%J
zW*?Iz)yp=dssXE2HQ6Xj39e4y^r|ZAv6o;_<<0Yeqv1x3Zs8dBAm>$$Jl46x4xDd7
zKv%HLQQ|!@M-O^D2~OarVJSe}e&Adw9B7JBe-xw_veYpsAh9HB#qtb316n_z<m_gs
zikD4P4q9&6rTnq=>f&dhPbM29%SM*J`!%up$sFT;>+}1*a=T-`z}`SImYS8FC}t5c
zw_R+kts;nl`L>Qdbl2A6QOIp33(6m9yN8B!fl#E={MQXf>z=8d;M7CLLb1ECv1!ge
z-r<nU%8Gy9f9mb8NancmRq?^Y{=(4}Cz@Df&8*w%e?<9v@zqz{8;Etta6dw~Dj%II
zhs#~o=?TY7biKc_56Z8AuIh~XgY$=nLgSUSt4HR8`<!PTI_o#fCdJ};m(7(3FSa=B
zF<q>IH<*~YeW}JeYh*&j&mNu8KsQGn*AoHVxt!QQ>SgUYyfM#fmEUZd<u`imjuww>
zakn=|@~m7Hi_THLczbEzb>VTXsM4A2+tnNgzD8c0|Cia(_;sbhWG=~Q-`6rH>Am1x
z6EACqN^KuO6(opT!8`-zB~+zt$@2`@snXg1?c9I1EcvLy_f~m4_)hr(n1>1gOe(K~
zL1yfq#fxzKJARt_j|JL{pNdUB;4r7|0icwI0t3M?V^(V}Vc1daOV|K}n~eU&KB}cN
z04Mk{rB_kiWy1L&m?E(zISO5u`c)Y{lOJGPraoOWr!t!7^ih9o?s?pA*3LaotBVAp
zb1u}rvu18(EUyuw{^;EE8S<VF8;=y%jwol&|8T%L00m{z4T9jl%#*2Kzb6r_Zb@Zm
z0&>80Oe8LM4vhGC+2G2X%syIgO_{4JphOX8tKyrh02UAmNLrR`&-FSqMlqDDo-GQZ
zO^o`>3wkFlyX7UU+rZHTv0)q3Y^l4Rd6l^y)oHX_U+W7jSbP8dYZnB1X#X0t7%g7o
zqjPn2j*XD)v)m^7_1;j>zBW73DbUGo`^Mz57BQfObMof&ibi|B(CFBl!YyT&!K1dE
z-^G1*-Z7)I;@GOnd}Z@IWT!b`N8%CU0^OWNX2{%6Qp4>!z47w#&g8<hM`JWa5*-0g
z0CK81;}ywfN@u0CHfL1}Me#hvku=Kp)Id36U$&n%BmfbVgPImHZmqI|rXEsIasst@
z5%P(m4_&BvWW}~^D;{A<u6!XHRPGu{1AId4<@ei|=jkkH5E`K}_^7rEph4Y&SWW>A
zl~sjRd`cB)n~{Z$;-e_Q0yr`kSO7sR5o1Xipau+|jfjmv<skL$lB}GoW}e>-w3>th
z)=QROe&|84+AKhaQM2b^hhGX-(d?}=Ze6`tAG@V{s+>-gCn}QbgPH7<{PM7J)m^`?
zr}(xr({6g3sQgvA83Z%S8H-zVMprd?qU$kB+?8q5-*V+O-Q&>_P^31a!w!kx`?KCX
z3pM8DsUiC4Lg9(X`nIV(J&D5N6W1O%`{;r+=QyYDVC|&7t1CL6Mu9sdhNhLvA+GOJ
z<?^sqYZ$!t{aeAFv-W$6*-gI#)~W`msx$#Kgi9fM{X&o%@mvw5d1C#fIx!`KFT5{a
zAYdlNe}343MF9xh>bJ0f*wq-3a+t@UYI_aBgkl>k{LSWRY-o){OI_m0BjJL&R15eI
zO!e3i)DBfIL3k$eOMYgzH)%=MTZcM3PS3uZ94g4#4ygR<(2b9-6xkumoyPMyLl03w
zoJ=he*~wOBZDo~g3L;(2E&H?@|3l`GUYa+Xt}jn9*Y$EWp$zfpEc#)Jcxq3*(5`o`
z4u>mDHXY9!uGBjZMf!DGTk5&0giToMpUNAosqV*7E}jw14x`CT_MTGCC;mzPOgy1{
zx%$l;8e6hiQX%W30W&N}e^}D6vr=A5AhWE~=+6-0;M|1Q5~?I(6WcdWFco~(Ba@a{
z4%BId34_+PbFA*>Y1HKn&KFm|Dptn_i-RtAAW%8j(J_dwtRF6vTRaADT#gG2m8~>{
z4c-I)(6*gv8mg;<A_u4M130J3YL%a{&(hyReF87o9vjuKhh<GXooXrv_?rK53>GfH
zc^FfJehh)*{eK)Xce}sy%5GP}Odt2g<1NS*`F4$LbH#1UQcoz}R6G<gOX8_ToSo;W
zrwm{E%tpg^Z}K*lr~4%O>WJstuK;N67N$PXto*FP``vZMa+gP@uXMD8%zoo{|KK?r
zNB!BL6wQ9!sofm!V5wmdbbgDJpR<SP8$gqhff(We&{r*0-v#pq;O_<WoB+lm1cuZg
zkaJ89N)}ZNs3l4df*gja>L|o3<$)Z~m`7+vIR2p20NV;d{3{(}-67}`D8DZZIGjCn
zR*S{<+MkuU68ZD1w*b%d!FgZkxtfmb<lb2quIQ;4ym#~FRW7@}%5Fk?8}d!A-ZlHR
zO<Oi7-wgHk^%HwHDit^864K<C(RkGKx2?*~3l0_k`BFy{vOR^k$&-mSK;XYAo>o2^
zAs!$erXCpH*H>LPOK~gzR^EkDB3ksxiEYmXTKZ!x7fng_zIyQ`Yed0pqK#-uuD(MV
zTG~Eu<lJ#>YkJ?SZ|=GJzWSa<zacz(Ni{L-_(SjP;f~iwI(Q}i=RX$<kanW%Y2{v~
ziQWXbuL^9@gAjeK;=d?p5r9^LVU<)v`(a&@DuRQFP-hg}cR&`#s#7brdHPh>N=RLU
zCml0YDiSQ<3z&_{|G-m0`%-jAH6)E@nm}??9yV|vg1$OH3FV4cSujthAJ1CWqmMQn
zh8(OlS~Q>2DxY8OYquo5I_1=LGnCh_3P7Tl{b<?53(0@g&eRHGO*J20KCE1|XeXMC
z66YGD4=67v58hzlA<Yleu=(54dX6_6Y1V9WQ>`)I@D0M`dmmHw=2t53e(XI!MkX?u
z_*=FCb9EQZDp$?#Snbt0Bfj_LrMB@9&ZN6W|BEhrqTFZRt-E;REMe-JHBRE-yvGlp
zJT_FBBKsbC2$mPDuYTogfbFLsPpMCxP2hJ+YA#GZ;Jwwb7g$0hw(&vYcL}@J!}?RX
z1I$HW#W`MLDiC6oG|Ma1VAtQO<j{NQ7jt%fck3Pf*Io1R>VbbP8+YUVh*hrNKWpvI
zyT7>hym7NneDsTZ`w!jl<kj7|4SQa^aLEi}I^0@~PNMzjLG)T?<d1(*zWLjmugt7a
z{`RN>6^_4D{*KDt`}e~?fBFy4e*5yd$6kEqk5B*n{;SsA@#gX8@480Stsi1!`sK2z
zKowspdjnC(Rf3KjW_R$wv6dZY3JUtcCQbm5{Kp1p1z-lirL+hO5HN*b(ps|es|CO?
zKL(z(08D_-!DSh@ALYQX9SEL*f5BFdi3m&!er{=nV(uNUZ1`2<8DM{mLStnz15Tjo
zJ$QOy!zuKE`^tjy9xL|nZ7R!|2X!8RFkn9XK0iDgQ=-v_V*XMEdFTN)^`YQ&RvH-|
zmD)gkF$*K}l77!jvG4vS3q>IZr@XGUGUJVe!6e#~c1ASVy^ghW?GtKEL9Hd(0y^Zr
zZ5_3uk@7Wnx9-+}TmH-)5^s=V#do+UXtD=_Gg?4`V^>a$ETrh=Ro%OYCPyz}3e68L
zoei0j{GJf0Cxz*)A@I2Gb~N;8=h3Mdyv%bEUK^t%n$g&;dTk;RVYzCNIz=LL%FV2-
zYMU#1imYUS!k5I^8a=2WO*Q4_3ffLF;j`U62G+=lp21*;wQ;LNX%N9UnYP)*$1FTO
zzdb%6QhHYQ?wtx6C|`)YBIN5ZP<e6YK3O@Xyt!h6w~=>iz!B-IKULFV@WbV8oQ|M4
zL;LPc?KPREZDvTJF8N9G6rV;g1-q#;XXb-OldV=srTIC8rEMj}b_H8zGUJ+BS2csr
zPQ?=U1Wq%fcLgXAD7T9oh&%fd8h+qrDImCCrD@|7w<nrOPDLQYdLCC^p0p9&jgFKH
zo=GF^P^pKUqAV6D+0CQhxjivY+*w|0lBMW|lmkA3C%90s^g&P;L9%mq^77K^up=Y+
zr=IE71|nb=U8@{rZ(`_C*<~8klzgo0ld`{+eTO)_7D^zAVXOqWs;%*dv;W(<|Gni;
z&tkPPhO5#>GeI91264JBys5BQT2UpWf>8#mUQ#6(V2;MthYGGGpoL$IP6}hy1@KbD
zwyn`XB^8KE{g3`a3@Y9*>IOQgYM`S9s$_L-Mp?jR>hM(A3wS*GU_y>Kjryb<sQ*<$
z4%Z}Xp$5F;5w&oo_E#0=pvwrmVV6-yO_zeC-tPu?tGx2XBi}0jctrV2j5MYgi5GqK
zDSLwOjeqdhsO;+#?~dHLE*T23V&5xwy|!}qRXeZnZmo)hUEt0pb=1_Dtqz^HYrwHR
z<*%-@S4>az@}|(rfWYJz4Arjk)>$*5mVV2<`mS<kVf=1;J~f<6QH-Pw==`^UCFAes
zK{czlYhp{fx?+%#V?%d0@(#GrbF{vtWnQH2KzanxgWmaeC?*sx5BPkWeA<{cROepk
zgfo#f{uMT{z{T$NtnuiRTsRpBIp;bcg?ymKw*=o4N(O_jr7lCx5K4tk&#y9vXxq&f
zw7K%PkI&W&J!N0~N~DPsLsgZNcp&Qa=S`hAWx-SWi~J(g2nZgXI?mx4Ua|+(_#7sa
zq&G>GT9&0HE2D?>?H<uca%>GQk6e{>*i%nUF$gBN0X*LQ;1rMSW)EpLS5Ue|y_d#3
zS3e@RE+ZWE<8!&T^G<Y+W4TkOcvQv->2ybZWv3M~XHsQHzL(ib+73FK0&s>nmj>u+
zRHe%(0tJ6475%E89NeO?v;%%1DrOudTt2Xhh9Cd}L?jZh=O{0gXDgL^_jfRHN6^BX
z8diU!d}ShAI!uak-Ld6Mc0Z5UJ;$%Ra__i?-JVFN^6qbcbr^Y-)#u+ZKK|w_r?2g8
z>%8R5*DA>ilqcW3_fCW02*u>s-ix=3dp3zJV)MGg=Za@v`rWR%vv2-l<=hL`T{hIe
zT-kN;@q0c$xaQc461wA>n!0h%ubiX#C(yGaWf|sE>ftg6@Qpo?fonn8R`oqG_?Il$
z`2vnO9VJtisLJn_)}gAy$DB*3M74jU+hgrVNr*ZzxCaRcLnTsa9gb{)Rf>DEhDwwI
zYF>P*JT&cBAAO;mntk8S$~2n8P6-`-^!Vyo+rwh-u}#;nO&r`bW7#VUm&~~Ub>8z3
z+O;p5n>Mg)@6Bt5m$W$^VGrbo)((%HUN<;?#-!TT32j{g-yOGx*G^qep>}U*AMwNl
zo6Dim`Hx?EDTUI9JuY2MT1OI(EBg*7g0aR;$nxt|F}?`}^efNEb-zBdf79(*X+fXK
zQ0cw4p?+XXpc}~pP0JR{4p!8*E?u29&myP$+Ip0)r`Bb`?%V`9OBrRlf1E|fyu2#k
zxPwDGS4|!?Eu=}ag!v)1tmpd{_94h~TUj;&{=*x=*7yL9wO1#KE|KLD7==eC4Z~Ey
z0=d~STVN@uC<w?l_&)*qDk=Wh08NdW^;K*Les=g~6vlK}g;$LJu=_56Yc|6}dZ0)&
z=T{TJs0b1wjYnyBiGq)UH*`~iSe2^)+=qQmpi6jg>6ccogV@U6t~1zAH3=i<u21&s
zHF^uNwJKZHO;E9j$lqyZcS;Y=y}rCpHne2;l!-BGA>u^Yu29NT9+PJAy3eIx?FeBI
zqUa0idQwk86s%V7KmARsJ>1kvB$PSI=UO>lJdEa&&)fTZWKX__Cv-M}srXq%)xCb_
zLTCKi_}<RmRU6ygIVZR|8P-9nzk)??Fib7?UlHp0MZEr@ma1d*J*QurTp$bQRA?lk
z+yw@Y>1QktPcl_IU16fSuB$vs(&r(AmbO?lR~L2!<0R7T?cC&QvM9B=*&<EpTAZ#R
zqG&xgvf*vPQJA)T0vC1xX;j)RL^S9E-3nm{k(akb?G4Iol)aZ0Zd6__ZfBCQaE3bI
zwxNnDs26Wrzs)1KrGQ7;CMA=}Se<p!wq?Uv*2qJ^odM*JgY<j!*Fayx;J-1J4{BoB
zWY99qE!$akK3Jwfdd2ziu$PINfpBbn%KyzS+YxSrHM>CXfOL`7exGaxu`L&sA(_+Y
zzpAkv;0h63%|R<{b1qSF04M;Y5)J@J%x7WEs+@Zey29N87jLo3xHX1SfE%@JEJPWo
zmx0QTRl}m+D?d+3C{33%2HM^^_~5gLKdEOnym$V6cVF_m-(7V4-V5HlUAa^_bpNtR
zb9e4V)6Q!B3)BaG9~><!i+UZ)a!}kx!{CgAzfe{wtHAtzWyPA2tFBzQ{!is8epRa$
zAWI|ZM&?8_#7Bl}<}6f>9-O@xP0!ueTkbKAZ$;&V!$>p?+HBm)<8uc$Y??f0@ORHY
z{fE9(?fr+_yJ=S>x3nq{DO_Wq-0Ra`e|GiSjNg|&{VnmU_3Mj$ef1Sa%krGEcgvPb
zt2eM4$&J)TY7@PM+M+pw*+HL4@1~f&bniLm>^yz)(*CaQ{!8AG{8qoMiDeyBqsJ5m
zXU~r-ExO4mSzEm9Mq@NeFi9gnwT2&G?N8BskMYLUP5E3CSsC<)fd0%=6!tCZ-yp5L
zie5)=Lq-mmVOVmdUlz0Puq0)eZoG}1XRv)hMGU|NfgWh=66}oSH~pa#jOB56DjHUi
zx(wdA)!6%SG!LD61!EJncsC{lV}dN~L%m>?h023YYYZ<Guvr+oEDZ|(VvbK85*`-#
z0KhFUEUZHQp&9f)ita`!2lSz4?Jk+!F&N=uUO&_zFM%RF5`YqZK;K*dfhA{-TGa6X
zcC%RVnJhTSFlwl$iusxm%vlL3!W~#f!t*qS&G4gPQ)g^+^s2)^0p?NN;C->ErfvY{
zAmaTnk*pPCMYy{Z_=uMQJaKed;R+bwA%zs&33>rA^uQ8Qu_&7hLeaRO%)WJ<$uZ)f
zbTr!p;&O9yZH*N2+3aZ|=w=`j7}+dqVj7~t&7~?yI%Y5#UEuggGgb#vSmzHD3}n>s
zvOGlpMl}s4#vWYh<fxP$qU}Nmsy3zd&b--5WaXGt5eh{m)IjzS=_Rz5&`60n6L<8;
z<;H4(?+iMOt`x!9Wu0e>M-vD0o8UXs*F31TO$>ut*(?fL8<ZBTx0Lge6xeB^V&e!0
zO+n?Qh|e3gS&W=eyN=mx@ItwPs!%WZnbt5NTYW5c9^pFMo)#c|O9CR<0&Y-2>w<3Z
z;?#m;4T}s;q!+9#q%Nl$op}u_wEJkAgEY7-qQl5)A)kktahoB08f-8^hC&>rrx+I_
zhcz^VjNW#!!X<{x^KI2r61-r1o}5Lj_xm}c%dnw(rwc|qJma#Ib$gEDDBXNNRFs6c
zi7M@lQ?*b^mZUX4R*p^V4#&z#n(MZ<a~r@w8R-<1R@Vhmg$@e$nkSg$DdQT8wUv+A
zt-P1@Xe(k-CzK>NXl%%3rSl{au*iD~6={2UmE^UCf;GI(Kyao4tuyKM?IcPQaz&dC
z>YHRzj)e1k@Pl$D4FN_nx($#@gJt7T+Lj|JTbP$148$NgIW5T=1t=X0l~ySb4K;p^
zRFl*>1)JoCiat`<nrKb3CI&~d&>q4^$&w^jr&D@ch_d;AK9_FL%Kj(^o&r#5OJ}y|
zbk(ypn$X2GR1{(;kZ^-c$c;R_MuyDs9IvsEP$kR53t)Jab&%>q7t`_@onCM8;A%!X
zgjlzZg`6Qio{&Y}t0Ap^WKCH($>+>Dn?%{zZPRp<sVK5Rk`9xUk)yO&x&7G**;$q2
zsctB?tH~JM-guH=1HO<YloMP{1p`1jFZl=<qQFdGEdtc=F^}iqKky)*r(DbYiGB_=
z?Ka5uo`-5ZQ^1e$8IUvojjYHAZjlXW26zQtjgFxQKyG;vqR>A;pAcn)o~Qz^t69W6
z;Hm(N;3RE;B7$nH1V%U(IE=E8dlfKFGXhr_b#24a^g;xbnydz*>Pib9?gP1#kw*_B
z&=<5rk#dap@Q!*bl$x~y62>SKV~-rTW?>u&zDM|Ru%rH{xm^K^K~oqNSO9QoX27&6
z)@31!MYXkre@ee9k^zL_L0(is`#2&y%2)#>-yw^2G#MJ)1s6(~2$Er|ctw?!!Gla?
z1Mx`l%VE<V9zP(_FgzST2K>74M2wnm03rIpWej%(n63(59K7mbtT=r(L=VFTN~e-P
z7`!`l5df~h0$2~bRN<FWM}$w{M?rg>$x20YnSxveuQ<jHU|Bu_SvxX7YSe!7Q9z6;
zHL#@N<G_Te6OHF60J+qm7l^4bvltP};4TS|gCW67MWG)^sjI#&p2yNdRg)9`Q1}Z0
zWhwOqd`iiQ&Wc-=PGbxWq-Av8VXUfMMjfV_uLEKda5pL*2aA>klUkr=jga*n<_<nP
zy?B=KP~{{OUH&Fy$E=%Rn`xWlC>-!D`Vj5cbB3!(^r?1xw&#*tl6Jiv6i+S=8U6X8
z)9;DkD-^VJnr!Joa+{I2_E*eU>xs#ZKNi-X&R!gt*_=yMRZxP--hRf~wHl6RC5IqO
z6{KJa+rZhu%h*MYuGVg9XGMXxLO3|#K{Qo>y0}o53}VJ1{WMSMZ?4(cZ3xnGcKnLU
zYtHVsCub5Ia8Dhdn?fJIWMYb+Xjw`}304_GYk{lP5ju&G<DM8zva+&|YRxznJ1k2L
z;*z<63t}3wjp5c`?QvIyAT`uTce|dT{?5q<$l<)wAGf7+4s!*eTyGuU)<*ySN^lWQ
zvk4!Gj4kMdx6{}mnz$9p#}$?cEpSA}W+Z7nvQQ8MC%fEs<P^<<)nSC3APyZVIvRS%
zHSjW*CUWJ3J{Zb|y}Bx$Hk%9>f`Mu}l=YdkC^QjK41)^N>hV1PuwoE9jGf+&6<i@@
zi!+3|Lf7K33g8r^b3m`?#(6}!)pPcdc~z1@zb2Diq->1UtR7e2uHp0qqxEfCzd_&_
z2JrbpJyf|vlu;7iij4%Pvs#UD_N<D-9>=>ht+CEDrgEajGXzO4qq{k%Bp9^GC$y~4
zC7B63Q{}R8v~HyXZGu2Xx?-Gm$icj-#hhQyasG@&y0qh57X#j2ZAL?|a>UH(L4VA;
zldl@97+qi5*X>T9CLIgy^qN%-ol`(B7p>V^y@I%9Tp<}N)|&jot=TNa(}a=W1skci
zBf46ja55&B+~05X*@QYh#p-N`w?gzBlzc<rx&{U1I=wAZ%wZRUHgqh^+cM?VVt&;k
z5+dZEpTOxGU$~rnOUFVwV-kWeaSicgJ7?b;YT|WJB1n%$v<{O;ySMw)2Q<0uKIDEn
z;4ko8BdXcHVGAjUpZ&s<*i82CmtM_7>VYst{5oF|5h(w{`kF>yXEeq6{j`K8hIaZE
zHB*$CW(3+n(JY@g3WA_C8Eg#8_PgZfW+JH3h?*>Gi145gmSr0xXg0e<(JodoNr6?a
zK0KSEnJRV<OXc>bjt3{82kxNzYlJ*}DHqiR1^if+QLIO2K78{f6QHi%yTf-Tp3Oby
zp4!)Udwbn)I*EyaP-3`c+M)rvI!!a{>8jmBZSADlV2GdkruO>8<k|Aj&`2k$4G?dO
z6{|Xqy~N3$8xEYiJhMIQ<gJhWM$lSQ8@E^!>6*J~{{N%vJ>VlL&%<F&pV{esceeMY
zmA0?ys!OMKI^F4Xy>|{cItRzmdo^IHF*e2+8!%wvxM7Hm3+}`=$v+NmN$k&w9Vd32
zxN%y(=be=f=l}h_+tcopci#7%ndg0a3G{vIlgWOD7ece64Q%@9s%YFnj!X!r_q>k*
zaN9mJAyy<0Gxc&Dzmz37&>)GeSDD{YpMWT-2+00};A^}Y^2lEfy3_Y`JP9#UUxAz|
zZ$X6A??8(RPAym*&{`8)a6OGL1*gadun%BQW1qxc!M=`t4}uy04f_M`!3{hKUdFxn
zJiZgC9TaN-?A=Cg2<t<tX!qlK?E>0|Xs5qC-A3@pywIj|NQ<?$)y9!^K#6Y6>ot_w
zK8;X0d=L^x*cJM56<|%!4j@zvW2|D`6c7by>7I3wxJzEzovn3+X7uiq0c9h_DxxH7
zQ*r0F>I4t-ff3MczzAqOAl2@$?X*tru>T(ek_{zB(FLfX-d5YX6MuIGfYZ?_w_|r~
z*advr4xn7U6yy;^jgWZc4(r|(A{p&FZc}4)S(_TUGX%m?K_nLKpl8$mMOU=xFARg!
zVD9jU@S;sLE8yna*SLK_E0={yxyRg16#eEtG;~jGEsgu!+wun-LL|$j@C~$uJ}!|%
z&##?<%Y9VsQR<a;7^e#>NP>a^L3;_aZ6~Th5|%~3C2NyfXQ|;>{?vH?hxI}#RSr^%
z-HzSedenC)KUy2Wz3S-BE!g`PD$2GJ6}@Do*9jOR@4>4&%S4(&SX3A4yByHh_SQNR
zMtov=<&!=v-|UW(w6i$39lzv|W5}M}yt;DZhH8qU#)b>zGhtz{5R2z(BP2;zK0V^a
zHwN`UFxi+0CbrDCem&M7^x0%0Qb;?R7_8K>uWRX)T{IItwG~y7{APk^O6GvB_qH6B
zyPi+!?43-wwQn8PDN5MgwB}i_I$qrv|JRX5G%WWOv#D^ol!;uZChW`9%(fati7SdI
zYqD*uoJmF^;+$9dh(Is#hRoFG{ET-N^ErWpl&l8=osZbWw|AOZ4|7ANb#vI~E6k|z
zN3xNC&68cpn57yGJg6J<8{%T7ySrIj(NpzuD0f8{X7*3+N<0xt^w0s)n=ru0dA|dR
zt@SQ!ad9w_Z<eE*W_|(=)tWxB@?dr7N+V6lnJwWDW*#jK&NYi8a|vlSDys61fbj@L
zLdKIo!ZJi9A~}4lr+EEU{TKIKuJ07&y>h6wc~?H$KkpqI^EIF}?)3WYmXX}~*q`zt
zA*0?OvE*Er_MXCyb$f3PUK}VS^E(SmFW3CLwq-EfpDU6d!OTcJ>r<pgck7`5yk6s&
zrjI70cc!o}5L1cFkf;!$;K~OE-xF<whi))CX%qWGyuPtBxv~st!g>Tr%$}ODd!yVy
z4+-9#xlTeEOXFQ*Cl(-9oEbcH)9IlzH~X&~fU1xU{KfMxoTi2Hg~t=(OYGF>=+qFS
zVy~aMk)&COWDgXw7^(nV=bCliG!#Z29A0_cn5mzjea8>tU$SG8edaPLZ>UAQ0ih`)
zW41&$-i*>>w)LoyRLVBgEEPHrJGPO$lZkqb#rY4}c6vrL)2$B;lJwNLYIp++;2RUN
z4c@B1)1g2<0F}MP<CL_IJVZhkdBtn_BZFk8%!j1PTb3jw2Espp^jR`>Ck;V`{<~Ty
z*-*4x5%_32-HG2wXOj88){UiD`Juu3@E&%^626GpK1&O<-U6pW%b=;&QN#3_o%oA7
z<mf60(GOt<vgx3AqrO2|2Cvyj*gw1h3(2z1V?5X3g6A~+oD=V%GgzONVFaVvt0yLR
zS_6@lJ-)6a6nY6x1)mw0)FhU-Vune0<<L~O==I;PZXYpyKHTym-E_5MuJts1iuyC;
zyL_tSC5V0bO2>C0_T?QY;G6(4sSfT_+aPl5ICd#^4R$}sU0=e!iTw*iywG?U&*4pc
zGkz4m48I1y5C1U!BK|r2YxsBYpWy$A{{cTkOcJ|^JBW`Fe?$D3_;=#JK!CTA*4y={
za8VaRe<mO*q%l0JIYD?Dj=?Dqqd@v{x7}kkAUsIS0ILg9SRo^In~F4mJwLmN8X@du
zyVwuyt?j#(aX5#@f}gYBXdiff^o@%9Ao60vZ+lA6kbs@Idr>=Um}R;l6mBPW6}e=!
z=L?gCE!5C8E7~YB0&b&y6nV!Xqz-9p(LtD%E7U=2aGXOZ-2!TX95P*BUUvgc5MBbf
zhJj(e3a+?t4i!O%Ms5iNL}}aC!rfNgGa$IS8Y^go?j{9I;0EkENRDV+xZVxTa3^4*
z&<!`_8bl^U2+*TKSHRu4cL9212x@`L&}`vpL#5nyZ>#f!pblt`?gqUT_d<A#Kuh4f
zdjyQIh)@Mxr>gd2fm7|<fD7Ps4QbP0IGCjSfE)F+d&HeIx>Yo%wJD)@3PaXtI10XQ
zWp|P=)%J++P+Y3$k}|jqMnYY}O{3=sjtuadHqi#UKlGg8Is`%x@Q5C%J9X$6iJlnB
zVqn9=g?=E-s{1hE<)N{Ws0?os{H$RI-Vc1O_J@W+!=gKK!3lh-+-bN|boB!OUg#_W
zareofE790>G*J{fgEWXBt;1OE8)=-KR0U>*UJu+lx<M!n0v*BS@bH0R!{zOkFdwKh
z<+}g64+EWnR%n5_A9TY=JA!@yV%kt~R)e2*J3*jdDMOeJY_$8POC}5n6DU_8d<hP^
zQ-z^{!9+qnc%8e;3D%^$4h?AHjtKw=HwUW*t<!GIou@k^m;!($oCEnB%>>MVrv_33
zU#ad_0^V(73-un-6O&a!fP9T!f-OWMMauFQ1yj#~dATb*q}OUito7ERfbA)fSTa$G
zd57qz&nrueG`KU^xt-utoM$|cgvFQY>2Y{+u)IL^M3Y54=`8S$Z$Y`Jn2p36Bdu3z
z9#8zXJSk|HqN%^vz@@^tN(dW5K*7^7oyW;8l6{ji6vYxSI>d^NplQ#G@#sZ@%7a;i
zG}Gcv&Tra*?%aO|nGgdKB4Y^NB?@P@v5Wy8X$?J4&|*X~ubEkr+|YW8h;bTFG3<?m
zCi{hzPqQiynN4Lo;IIR<1F48CjAY^zl(y&YV}gRR^0g%Ab7(y1QC`JtmKJfSnfLcP
zlcQlU&J(agf%Rk!dyuxR7_RFM<dLzGMPA0YbFsJR7^4d$6wT&DVXG3!cPE3`2A`S^
z#<cG{0t4zhIuGs=aVp4UlDN2e<=ZUgF@zAsb4sqRI9W{b;Ky=MXiRT)2^y6o35B&G
z1E%1Kl?f&2{XW>h6q6!ixJ+cBMrAHVmStan$8%A^CS%jIw_Ax~yhV)@qKS=?+QiBo
zBCv+6+)ab&Z;&=EiGVzOK2X&Y>#vW{(f-ajBjZK@vSXJ$i4bnSpY7zXEDAQ!spxSw
zq=>D59z0dsL=r*cy_TkFaXRjY0w^?x@jBmg<~szRwDE6579aypLycWdrpKmMx|+r6
zP)*VjI9Jc(f7XJ7Jyz)Lf8->EBknvWql^>#eS4Q`(F+1rT~;k0W`ske-?VO>BW<rY
zL=Xq;nc*eR;W<v;uWm>ctKGXXa9q;at>fOU80)8_Ma`dNY)D+X%=Fdg&%6yuKgE<E
zQkRGNXeiM}uo%Rta6&Rq*Kw6ypyXcp+*whZpBsvEM;C{i<^{Wi9m0KFcaDreaEVUK
zAppX2R2`!tbdB>!p+V3PDd+ll#*tV4Vbnv&mS0Z$uwMx(#mZ?2q{1`A1`8fzFc{B^
z45*VHNu(VJk%^=i=w#+Vaz8ngm%BM8H?0_!6il)iK{I0!S)sZkNyne}$GCb|R9VLx
zb+4|O>o|Jz_xtM2%N8KsKNDq*zQNv@rST*$(|W?^!!TUmWObdVr+kopP+n*x8l75f
zcE6CxHd7wXI^T*gI|3>1EO_?XPP#v(<4a!EPLws`iMXF;AX}IhCo#&asvgs)QP=B1
zsL_M3v>;KNg=LU(h9D$S$E0#fj0Tldsp7$VYWGQyrmiWb<Nl!OKo|#>_Y+t=BTj}P
z#Wh5EkaW(|`ZuUS6N7lQ<gBfM-(%3Lm9Pm<1glD|S>5YN@SN<$Z_f}!B)SgX3S<-@
z@sOYrVx{#SpP+Jaj(o0*lT@z<zs48Av&JV`3o@#Z@3mMWPGD7B<Er?EKv(Mo!(%uB
z-q4ch6=cXCiw)^M9&1t>Y2p~|w>YWXr<C%o)0QYhh;9781uxG=O_2^4y1|oc6#Ffy
z`1qbtr$nVAQ^RI0KvM#{^1+az#XNcf?_qf&uI2=gE~u%vhZV!|hZ#Q}lF$4<VM>uy
z*?>ycRN5<f{rm&82gfKSEDAQms@^zJ?!iyXX*(A+m#InHHqX4u2MNXy1v3cYiMNIv
zPAHN!elp`@m>zE+07+>)kb)MU4zp4{nRnQ%4w)}8p-T-58CE0dn78$5P2jj}M8j!?
zC{bCJZsLD{3?U_^g;h-qqa_n(wgPnG#R~pXY13fL@b^-KRePj%<`FXH(*ndZn#6ir
zC&<iYeu4~%VaHDBfi58$%2BzpD2bj<-bi@(saeRd5D904<d~32)Q+$XQEiw74@-4J
z@Mr}DTd*hf2n;0G(m<2>O4`Xp!6k_F2?;Ep7_{^3rkdZd#YkTEdw3`>s9K&V6J)&o
zXZ}DATg_-Zt}&Y?moK|yd*14u)`d@K0}5?OLQJ;@J(yI*jM6?#98?x?N|3u_Izj9W
zKs0m}0>h8=Xzyny$il7W(ZOu%5<*cpRhRv8mmy$bb~|LUq*7Tn7EN$!%%Cnw!)oS3
z9Y)7zT9b4aJqfjJKh*K@jxTroEyRI)u^tG8oyGRxemsI7#xKCHz;DOz$DhDo0INTc
zc|`7k;;!i@fWo#vt}3P5^%zBL1+qmVQVZLNRYJO&R5!3O=|*@p7aP#u3NYQ3GWf3{
zHrX|>y6g|)5YQ2;ZPrI@41;orBDTQ&plPh`x_q2V<t<>Bfo*H&!9k27VgXh^uAv28
z3j`jn07nBI_F&i)uwkjTS1hRT5tARnU{u7>weR&T&w}m&u0Z?}q}8@;*oW_Go5#Z7
z-rTWJBNzs4Ll+v1=Vn2~(lpp-(ru?D8_kS4J3DA+7c0O7uJUMY1s2TT1P&4Lv<;Ur
z1h)n>K@?j77tru57&r;cA$-GD7ls5B_?YN9!m(9W>#T(VI4zjB`;>8L1`h(Ia)H6y
zErF4QX9k@C69lgeonC!-?g4c7&|)>{rrkHZKxhgr8Kn9__k_5<)hFJ**p;W?5z%X!
zAou;kg=we{={^AlIE63>7KqoZ4}kyzJtp1zMseN*tSc9MKw3lm8hRWMN&wS#vnMeK
zBwV)AGTZH#D%=}P7G?pQJlzH9s;4w<TvJ|Bl0t8>kt0TihnEr?BQ)rFZEt`U<&4O%
ztR_JeYHDZ{2m69n*+NH71v#zokmd{-X(g!XWH+aBSTSmtT}gjHbY^q2V}Udv*`R+1
z&;Ji@r={il_Hh9)YsMjB^IAFHf2=3Fu%bbhq`JQdIn6Qgw9y1L9|8Hd68?amDvE)+
z&(^bwMI}<#1$O1sl})D(m3O9QId9@#-d1^{9+vH*WcWAoB5#viEgeo5F-4Xrj03{$
z^wdQUxEVn~Z8>74<VO`-Fo4^9-UFudqs42tD22hE-saU$Sf2a+s!TQ`CwIO5JBWrB
zr8u9KO~S<XX|zc6^*5BOqhk#C0LMHh)n<9+3M}0x<+>T1rCEPtMvO#5V`f-l038w(
z56^zW(`iTbtWeRrGV|#q(WTBSxZ?N3S=l$=!-3Bu&Vnx!<Q~T)u>gT@9xOBNfyj2!
z;-Cy_w8HMt5;V>Wo~$GV<eW{Zz+Hn{9`J2Fpg3Vd^6KChnq0>jz`|kD%D0Iap%A;g
zK?90Kf?>g%q7@9g6<nG95eU}A9d?l!?59OOQuUBvQN}Ra#u(3l@Mk@FFHA#}SN_C=
zua4IB<?}Q!YS9$-PhwDFIU$`VR=$l1tU&VT<AMhQ)C7yeQI<l2r(#cfOhL#la2peO
zo?$#j;adBPkcwC_MbNUFJ-{3BO)1Pk&YNwU1A*99y1IEgKau87_x@*^`l%<>vk;^t
z9~mJf2x?6++MKrtmW9A<vuUJzLVm^SR6H7S<dDhmeYe<YqN*(EJ;0x-iNFp@6M3(J
zSN)Ql1r3m)-Mn1k%tCJEh(#$Lf#$uU<L$~1a@XA7>oKrb%zyoxEqLpl178KLvk&hK
zOQAl0&fvf(mrQ!O5syW&GoeUje>A9R3fR)Ypzfs#7-Z5n1x|82iu`#$nB?g*|6vu_
zJ&Vbyl2_)UkaV(H9uYgE`PTKOM`C!6tgDO?*h7t}fq2;yYCQyn-_JZfY0_Rn@le&d
z2*HBm$U2Mb9TY@gXIW>JV??(v=})Kqc)%K)@TwRO@%;|#Ym7OV4B7X6aYz=nE}c@6
zdX|x7e8Ag7@rq(H{_$qS?yYG?XV#MXO%Ja$d`|1fa-bLTNpehyFX-SAB7h{K8z~Z`
zJ(?_Vks_~A@~$mG@VD^9JisB8ysE~UUdp)i$s(W8^O=%eljZ_?7(W1M6-ARhbM9O-
z7_T<H312uoc3Ww$v9X!{7fF}|l_8t;>2$E~*6UeL;hWd6T|QGurY5Ho;6qELZ%jeX
zWmfF|E*61S*xxzlcqwp&<y%_tk|2K`PTh@lawV=LV&`&s#gL>2t$&0SD*#(ZaGr!m
z;z>&ZwBh$COdND!C|~1uJ)eWPmA9~c5G(R!JdKaxTk(DP5!b6A%>ac#0y+}d|MG)S
zp?eAuX=s56L;J@~(gC|rs|LQ%g@D}G{t#*hY~3d7t2loZi6boxI)cbf`xky1uH7B&
zA`c}%((RLA3%6`=-f9y(mrSE1uRy(4KQL8r1Xz`~(Yz6%T>C}yX51lQW-uJ085Lw`
zarJHp@xwN<9;|+l761r>>zj&h+XMs2s&j+;Y!KN4-5I*Kwzq=IVl-^D3v*aI1H%H@
z0aXhMOly-p@RtTnPZ`Kb!<`%&(4F@XOdh!apof7p7OPJsZqqeas{xc0ssO+PM$fzm
zS#p3%w#R{6YEQ)d1@eznKgcfR9$tMuh(4nadMb#r!xo}=@EG2GPQaMJy@F#I0~3ZP
zfXK1Cg_^8>kUN~q`&e*4F00@^1MBS5u-cj@R2{SJo!~wb&<e)U-B}F8&trAZ=QP4^
z!X1!K1NRt9l11^dlU`V+(#_PYu6Zpk%Elcg3n2@F52}J`(d%i9<4QOIE=Ovbz`Pj}
z3wy0Tpuaj;3-t|upNG0G-Ob6-M7cbrvUFbf2tf;7OPn}2zc=2KCbH{1kU%r#)ay;K
zzsQ?pGOOq6!cpxv-|!59G9#%Ue*G&CUKbi58TE<$QhNNR@$l%#1(*zlzWaK|s~NC&
z;Z9c^-?1-h78-J(IvycC)K!6eHtRjof1k3u$BrotQA+t8e?#27p5|DiOPly~s2L0-
zc@Ws_;BY2|i@8)xfTF-6oeC2<idR_=U{^XCfSl?YR2eZbn&KpVC>+kEcYli^^IR$F
zFWFMyOw8&Ot(dX}SNoI@k3n4u4&xFKZGcN4Jqk$r!_TAFbK&Md|5QjNNd=eq04*?4
zjt>#%(aLUIl^M9f7`Rofe0CwM2UIp}DKx`_qMPTex%VCX_<3H=gre-3D{rbiQjJ7Y
zlxJ?3v$9R9bU+F_zO5f->HF95f%5|bSM}oHu*K^KJ~ZYX91-*pa9t*Wb1Fmr`_wsM
z49aft4md-|#y#Q)>(Cxmg%o@S3wbwMe+XGbR?>By_yLbc!s!T9FVkX`LpLNr){h(6
zb@4RKN1bXQn6eylo2}Di!WmO6V#<55BF2RzR^e14DOea(AyEps<oXHU<20ca&k-$(
zW{X`77|JxT08V-I3Y7Sjz1<#>wuXWBrjlJ5j&$%qvM8QV<=cAjWl>`6!oj&+-U0!>
zXC7Z^bM?@+6czO<7%*}gL*cSNLmF1blyy#w*6W<c;GvYM=^8W5rF$4sQnW%C#Bz3W
zB*1rjFR-_4kwGdZ40s2Y<fR+_5G^HCrK*uuUn$`~=3gF={E#=$1A*<V1n($ROeQ2Y
zAyQoA+^sdxHSv_XE|o6)csE5)4K(J*_>W<fnt;l7QN>JeQ$my~dag-lN|Gc}36Y_p
zBs(jtEa<a3!NGM^Vp;CmC)Bba*e7@a(v=828)hRrc&SfHN?Sbr6`mo?5LfA9X`IF`
zq>fqXhP`p9D=m4fP_LMXXq;9)T-oN;I7ms8>!SCn3b?e<bi}V{9t8&yD{~B^Futvf
z4hb%@Bq!M?iQUc!0D{b$QM|TtUn!BhRczcenHSk!uUH~%)kCVJ0y$%x&t$C;AvNN&
zxO&`iVsuZDk*4w6GPaCI%BoHISdWP8H)2P!^*Hk*$XPcF^?{%2c&6h;$T9qljyF4g
z2wrpl4w+Y1fOY})0>p-JKKvjo+DIc^vOR<(0l-oSbFC2~w2ed(gtuKhh(tFR#~}<@
zw!sGN_5xUMjRGN>!9c%mParEHDFBY4@~KwCMy_V?L81#>;8s|NDb$cmhauT2g}Q}7
z0XahmG7MrPM33kw8VBvec><at*$BiJ=-HK$0OPxc^Y(0@i!_==-AyM34#H4%3t?dp
zl73YD@6Z42=z4YVvQzg2@1|0rVzy__0>i_ViC@0(wGDw=bw75>&fJ%|ED+r=ldL?H
zo7s8U!gRp)(%1H0_4w4cKe{(nN)9PZYU|JyuYdk;lVkfX8UN)ii}yV>eaGeH@!npa
z&l3Y|;Fp_yvj;BbtfslRGv!ZWvnS2jU;pHd>g|#4zNsf4?(DMntUL1OJFCprD~z;O
zca|o5@ha<&?+FcPN$nev02#feen}&-S!OeZ-yUWcD;`DaS`?Ikl#^1SwB8NrzO-Q4
zv<1l<vrb{X0V;Va0f@uGaf~%_jlv3ly>m)7ZeH3-bjF80a)o4LM&DTNeV_QzxqD)l
zD{-Q$e!Hfs-q<st+L1k13~!y8p$jL<pL(D;9CUgxe4zQYbboDVNB13%RS!6}T?3b*
z`gX`V9vYLTtED^j(XIX<77Q?jk)z(_eP8>lr~P@A1!Zs0*Gr1ozQf?$n-6;Nw`Xal
z>J>shoD57vtf;?wAl(&E0R!!GqJ&9{o}ixC2wn#JGK$O;Lq3q%t*b1kM(;W41!o~2
z%EfxH^?T2w)QOG{fR^MHfN7LX`1jx`V`BNX9dQ+|N&pK07i}j81R(Bl#0~%e!5@Nq
zfX=$<rsH&h6CHNxzRP~K*8qZB^nsSEPT!`1x8c_1C)(T#tN{STHq63eLF^C^ZY0n{
zflI{9;3&r?z@0k}(rznZh!k=HN1ee3nnCLF_6}SPS{Br418N4MQgNmMqqjHUFdRU$
zZ(j>MQ(JujOc!)zB0dlGySi+kUoe?9R-Hs?VwE$o>z+r`8u$}uu`Iz8<|kBI2(kep
zdCx=J51C8nb~TQV>?G~0D@i+i$>*GP8z2)l&p8~)a9ehS34zFi;0JzB3P^@N;j!ml
zcyl>3Y=`=3o08}E9y}bjmXWnWv@3o2^&;(+>L6=i>wfmf`5U%wx%s`lSm!5kM)H5O
z^=1#tagT-$RyMPZH}ASj(s22@$B6SNQ#G=;VnTZ5<6ZSCpKN`vyQi7`QV*bH!1aCE
zq~px5NQ>tlJP>4d>aqvlb}1B!X4NNNdZy<+8%}j^p|EX-@Q3eECHeek^uPxf&Y4Ng
zd#SWPtE;;=rau5RI_bBX;k3H6?crxSnWD6ATTc(M94~88OrF573zc|=r)4^lJADJ)
zO~#qo3A3=cACkmLX{ob3c)YZGy!GetiTada%o+aUe$d*_JPQtkj8o_=O=%O_A+ao`
zsx&s!7@5ZW(=Y89x<4GxU3glZGscpTnD&}$z2GkRrQB^-T*6PigZZA+jKTmjy7%$N
z%)fh#%P(W0%j9f64~b41q5VOI2|^K`Jdy0S6ov9p6OAwQ&xe?qji>5gc<J%_h3wmR
zdLDd3eemJ&{Tnx4+xoIcnCzdwdhQ{pR6#-Rf{VE%xfQZaz1Z=YjvsXVGenS}b&yJ<
zFh<*gD06@(0GhH(4FKE`__%C7A_8kGpy7gc8&&}d-Al<zu>l)xM%RUV(6oV(5C9(G
ze6aLEKd1-zS?vi9F^Sde5uj_r5e;%_0c53WcZ+a8RF8nkp(`6n7~rhW6l#ndieYW6
z{h@UN;!c|l2fJb(L#Y(GWVZL=;(Y5<#6$NRpn}kor&?Ei5UQWf3@_e5SMnU$`;)oC
zVaN*_8Bi0%)O|hL_8Y!5b>h)LaQESKRwrbLEWkE}HnWCxUF^hVS&ue+;py`A$4RdL
zGlN|8TFAK;VUwSES@uINh}!z0Z0k?AweHWEcLq~z_FAh@sQ5fIuwE%no8BxBPA+dw
z<K%7Ffs2}(t~>vH3j1~Ly379*@rT3yJ7#D1CTR%*)<8Wkf{uU&4@rSj!4d%#8komP
z5<(sb?A6A{Y8xhqZObW6#H8~IvKqu>(ONDnF7YBIC+#kxe0WzA;wKD`gm*1&uW{>Z
z`^00_U@=xc?^1;<CI3*VwtipnNLXO7_dhKU8UM-%=v@HI_v*1z7jyFZk>OxMGbXn~
zyv4wzFBZ$>RE8lgH+=+HC(;MQWZy`mK^^klbpt*Z3WZ<fI4#R^J+uU|gi!m56loq*
zQ?vkjv71F;sevD1L59AAdXD;6$UuA<WK?~i<AshdLCypyhyVqF!8;yFj0`{sgSdri
z4J_#{=7baI06GyzIZFUl130uD<6OSM1xJ@30RVCHN5BzC{|-<LPzM2V6@*+NpM(zZ
ziCp#puAn94C`K}08|GXnqQDmIG9xwuySnSghyWI0{Z)u;r)6N;mU=+Hpshu{A%WFZ
zPP;9k-p<-Z)N|k4WTc(&9<8Vrj$j3hIB4WX_lH@{8(IF|=4u9aHZj}J|LDxFZ``A9
z+r(}PLe8ns&Y@6ZSJv@*sS#iIOFwV@^vNT#clVPYu)%H4c=pZjKP!l~{;Ae;YM?JZ
zj-~ZZt2@!UXXhS6l$0@?s%P-X3s)W9yl~>G7hgC%Sfo=i0_*NyI`#a}?fZ{y+<a`$
z-FNS~Y~A!l`|kKi-XF;2{r-IG+KFH$=bylzUHNe9^SNVMy0&$O&+&!f1p-ys07Dxw
zFsmnP>zBIokZxxhVpuNu!~6Gg_%uB<c4aIl&=E2exN_5g-EDO~)cVDTj$eCTxY^r)
zGLu4QZ({K3O)s{-uma^Bau~62%}X!!_3y&4T<f!etmySv9=ht72`w^YRmHNeU<ATU
zxi>`q^;I7q9sT%Kr=NpJAtRW0{;C6a?%sXRo;`Q(+I7c1e`hw}&t-xWxu8GOhOe(P
ze+xRAr?HdRb>JcU0@Nb>3icfoCkLz|fB|9{?Nply0MKwTQF|}$>JR{ATulN1n~Pgq
zq7R{CfP5fetL+hDH&XDv+w}e~Fk!_-KENF#Y=n>^;xpmP1sniQh%;-n*#Km4fO#OW
zfdh4P)CBNDZ2<aReLs{2N3%n7aY4P&-a_6kXIW@i4QNTgYWe^DhCI72LN(hVfG)r6
zVp;SU&;VdkhYj%5fTKw7gC>jO>X1(cj1GINd=FX=?%ja<C^)g9*{iFH9FP@A*B8dU
z7EQ<mz5}u0pm=IWg+Oay^x+O+NNC{NGoUqEB{0tFkw)D$KA?3CSRNX=OB@_*+*^R^
z=yh10$j$=n)8B3>Mw<^viXD~%)X~8gAE{M)dS;5<#&_mF_<>NbCtxdK%Mxu!K(#nC
zSZaFhh?$1Ea7JO0Rq2$%X3yV-M;OSH20rmBIO0VYPhH}0J_-7_Lp)@i(qKmy1R2tW
zX8jkPTC9}fG=!b;4Ms4Dt(zlWPb5V7($n#jfo<w741_}kmhO)2#)m^o+K64KIMp5y
z)_fkF8w@FiFd!SrgI62`eK`sFC`~Z^nv%u^Xt2VDc#@!GD<qJjrbOO*cS4scl1~hF
zLAD1X5U1?1xnU;KNjkIfCJ*&W3te=R3H2{_>dC}J!Hny_|JKCu#=QjD-1tui<{L&T
z#uBNU_VOge10)K|PZL;{d-y$6>&F{69vKDIHF@*UvGErmC^}|dWXO&9N?*ZH^-$U$
z#x4c}K!4PW`wYsuVZ<-5d>bl23p~e(p?)`VEaa^YT#tDsVu`Us$6f`65l0K;%6BP`
zsCga)C(2DW?UzG_KIg>KP^RJL)I1IPK{aAo5U8|Wq??ssFl!VHfl~}}U^3<LmPWn1
zGWexYf}Yw1wU>l0Ve4pTb>#XhwpiKS^148k9u=IrXFh7%@g8<+>&fdc-E<vS1T!+f
zd7Q$r*d<taCqsE9OI_yTO=lyeC@eEO)fFm)^)d#&1#&i##WLpTv_%CVi45de>5B38
zqdlWLU%c<?+_cXZ5XEzdO5Bs^_Ie{s#t(HYr0C3mTC_47u&q0X`yTL<jA_RRixqV*
zH8rydGwmpulqDZnd;P4Qmb@jwuR_B6kpF1+Xj+fq<Uu=J1Jk!iaFNM6pXPn_s<V4+
z6J~?gG{ih?JIWIKN6c_2N#jJoN)31K_2?NDFPg0r1OcTeJZ99pkj5Q5K76_Q(I|wj
z^Sn9&ksJ`BBMW@sbSo4a9864L?^9LMBxnsVG{t5q$btd1mWMjlJ0Y^?0*I4a-?6RZ
z1VoA7(eV)I06q=1D!zpzBv`2K%1g<}^$O9+w)PWpeWIm@)V&BrxEKhLTfk&)xj9(4
zmhC2Ma;c!ZAi;6YrG>EO!G~})zbG_ANE2`ud=Ob)#YTV)+KzB-JObunL`_|~+cpFz
z)`TH+brUn8Lxcn1I>;OdIKxE@78F=sBeE>%M90&5{v0;T>;L`Aqpe?@WVF6sk!CJ#
z{p_*N{)U#h6n7*6j^^DyZ?G@9527X@53bzkl|hARV4vHQ>U%KbBu9r+WB*hO^^~Gc
z_^F4lYyEahGskSW;nDE6a89Dd!A-Ay=+&a^Sw8gIq1)cx*B7dW{gJSWf2Eo9WfPI)
z0KR!@x%FSCABo4T=v}_kAM@=U`qGnMz5U=94sFHXJDwcqNv=B+>QDM}Gl>TI>)Pg%
zzqu_iLSWdH|MuuBKj_+3EO!6s<;UK-4I^r);jJ&s&+Qss_G_)<Ag^Z&UD$nE@Ioik
zo2+)SwMHne>aQQacK_sX6><afiWSq653OXLKejb)^?viZ2d^XRq25{u7B-Vj_GWz$
zmDE}sp5J}?SmNlxWUq{IKe=T2*e4EN_t5nx2ZmGCJ~}y`@W=aIy-}of3AY_;SDfm&
z1vE!bcKimzK&}pANvr`rzmwQ{fFBonK&p+JMhCnH^onHHr4&Jo3pyQxSOkcr3qe2&
z;q9UAhGrvy0D&BO|A<1mv=2cGdcmM~0$4+I3C^@t^{8PTf&>6wQ4<L7LvZOrq|4$l
z&@b96!Pz<lfB;;qQW12<<>;blOqa22Z@3q@WmAxSWc7Lk*+7NiKH6gg(MQ?c+#XPv
z2_m&n{tnFnQva+z0dR1HJE%8Yp8y?h94LC70+2<7sx6SiMTp$OJ%ur1^$bLnpaUoe
z2WrS|-}}Yqo_+ni?Dw!&T0h@6`Hig5m-7fc^?DCD#P<o=Z%poM{TzGsyV>(zfA+aA
z?xn<!K9>zGEw0DJ&2Ku)7%R^_bhsomycc78HWUn_uwf5&v9}?V4)=UaX2%%k&CMdV
zesL+3eeR>;nV0$`+aC^CS%J-Z2XRxAoeC+|R^IX3QeW2U$M;jBpg}gOl^&K9qSO(Z
z4{=J`OAHKEhbUdQikWgbQ?#IZ9vm1TylI7#{PdBPpJ*mN=*_ZXO(ZLhOnhw1z7ywf
z9Ewf{<;|C0@Omdd?J0P}>;Grsq6=?pRTZ#!whl~3hc=#nV&9g~m3-&x7hJwso`IM}
z?fOl>IoN;Og?Mut{3EAc&3S!|A4Oi%_qBeyJ9_ztDZiik@a56nSY)66TI5F!pEvia
z@RT<5&DX9VThHFLes^i8a>&|d6@ro8!ZGh>vVn(R7LGlwX-^*$UVb=`{fzfmL7NH|
zpvj@iP-*x2yRgmV6|a4BMtkba-<CXJoz;{R5#!V%-3g8yl_ibs1-p1D6<fJA6eNuh
zE;1GbLo=c;91JxckI{mbrY18R_bMKyci%BAD?&)QQ2=X=ABY_Uw`Z|q`+6CVvUg)<
zlG4%w9eW&GV$z-T;wh;Ar7cxR2J+jKyB4yStL*a-E*4)BdRm#ePF~P{p{gntzdXAD
zm2$eT9=tOyPRu;dw%&omZ&b$@G+||LsnqStS5MNr=}xFAw+wlEPIcS}^|_xwnLz+}
zEy&Z+UbBGe!7ClXynzB}L1J+M7`}n?Ldy_+05FT7okdI8U8Znob;VX77l^yuK%oR)
z-|lI&aM1#B5dnOoUR^yHbm_(tp<OqC2yGyscbPh1tkFK=f<YtO9_s87dUu1SeV^<+
zv~hX=MXevcS=rG9bB2^Ek80V)#*V`WUizzV?CjrQgw^P}*8lu&=clEqySjg?m`{Zn
zj6XDcE*1i>z|_gsqnSTMhf2j_X$a#+`qw8PNW%a5zM)4mFK05ZWFGtFQoOit^8XZ*
z8z=T->vv=moqo$S2M3+8*3r&nX3JP;aL|~*-#OBky%+C#?XAJ{C!;AW)V$%?%{g3p
zMKJ2yM~9TkfoHZq)M%V|c<;vtrfD(S`ty%@3m5F4X2-TH$TlIW6WZ=V<aupE4f{21
z-OAS;Cv8EgWBfm6yRx>O?V7zK5^3>?eUrD{F}^>!4)c!acG85z<%YM>06+>QY<;A`
zvgt+xk^}&r#vt$7-OLmy7}IO?yiKnm>d$>=$nhFp0Ajn(zDAb^ci%pGvG7je5=aM)
z{H*{#wm<N$-3!~_|LbxD1?@oqfDlbayMqu)Zoocr7)M>S8z79lCjG!6m_hrUBUnM0
zy*->O3!qYM&}0>6;1u|kp`BG=gyw0`BO%j+J98Iy;WW(81;tf$Q@djqoZS03OJ0!C
zVy!b~YTJgQmg4l?{YiTx^v8te%my1yG7+|S!3&l0bfBj~x>NNfasgTv@%$DJ3WT!B
zM8fZ+94I)-7kEz$%wcRq?CHwsoGL;@4I>JvoG3e;Q3}}@x6=}*reAoYxAx@zBbavX
zh8s6-JlKePuj<`g%P*dMHXbRAP94tm5*%k_7vjzVt-GwvXf>xR9Fd?Zshtx8>3J-$
zB@uqIPB3~*ijXlgYsJ8rSPbz}z$RHLSV&1hMfO5b<-~NUZlwK(68@;)DV4{_yE1z=
zLw0-5TycvX7|7;GK}lzokhd%ds+s1%yCRj#*&!uwVp)G*Bcg=Ohd(84J8$ovNH~YH
zQmoq>60=DU;Sm(5P-?2_9ATPrQA(B}pjj9#fX6QD6rWd0m!5js&wu5DjmfTcvC^gI
zZ`=3a#w%F9XD|~mQ($iJWbBmRABq$hBdS4Ks+_GTd_d7eqp%B0U3`3Y^ux*bvVz|L
z6DDV8Hzj;~z1g_6*{b@fY#_s=jEt%}oEA^vl1Xue(O@}XS>bTW&As_D9i}<RvwS;f
zlOBcKWgmT)GhtFlu7z(G7yy@5+Fk(gO@XPY?c4@n0rD#%+35-rz|Xb^Xa$HxaJwp%
zwn2Fn;#^eOkDT++2Vk|)W@Ml*bYM+Mxr+KwYaI*_bpq+M?6vZLbok!M#YJVpVn2MD
z_s$w#DAFY85cigP!76G!^P%?@v1`|lF0n)@0&xSjHIkq3e|3I0wgHdl%}C6D-sWeZ
z=6WS;!`YsF9RJqx7d<}5Oy76UQp6JsLrU|kvZxs%CEl$c0e5n3Bz-P+w9tRU%CEZN
z-$l)EH5!bT|GDV%%v^_Zba~((^)~~fJ9b>yk8e<Cx|Z<`nBh&_H`IN-4<kCGN2@1a
zysYy&AzC4+_*6D^`$c#C1C<Pu!aPSld*k6t{RU4iHq=8sSD%Jp38CPX$4o^xN%p*4
z>Do$e`=$1dy$R3k)^eybby=*d{^vieTeq$i4Ru3KXPwG~b{B`wJP;QQs2-)rknaf9
zE#v7JNH3=$BKork%Mmon^I#W)SRCOHgjHP91n(K`yZ)-HIK@5bVnP?2{V&voURnF)
zo&82g$VGrqMFn&p@Bw)T3MIUYwZIM11qp<l;5>q?IsnZYB7~+$htk%mAePmoqkta~
zDx>*djJIA-PcKpvRH;^z%F|9Tra1h0Sa_E1?hS+jOTBWokmKY0!GYR2eUDtd;qJ*`
zfXc_O3QhG~eDyz&KfQmXGZy*bc~2+4cm7=KH%~~!NB`}MU;M`pVp8j!)_>gpXyJ0x
zN$>m9cUt${B=^YkOKQrqVa)Op*nkohgow|phxMcaVI>M(Rc+%#*qJW)M`b_X`qO;t
zALQJ~Txd`fdM0MrVy=7R=p5&pu`jK7cl+WG#Erv7xLm&_E_binAnjZ@=ZcBm(v}ll
z7Z}!KOOqF;#xgTA6If3&7uYo4_r`_3r?zx|ET)_BXYRfC{*{kz=;?PRw|6%te*Ws)
zrxq@ke%bArtVruGI9G^@69b$9LNiGHx&-C9x*dN7S(B2M#9*Z%@fc}#b{2rvp&EA6
z>>j!V+zhf|zt!=xj$Z*hK!IC$3uu|P$qSGK_st<&bo+xEyvxDB%Ub)mFBY1^x`*rC
zciI+s-IrVJ$H1`%y-SzQASYaOC5*C0OW;z})v7_Q4Mr6g{@jsWd3B9ba;X`lMROry
zZLY8bSGhW97z7ChFyoF@Iky4P`*3Hb-Gp$%I0JQ~*gc=U;;}1FeRdxxWgS(zw!E-&
zdGkd#?~bXD-H@N%*txjv6MMVI>EgDuF%KStET0h;Z-!(I+QE!5b}+VkY@jdwK=kN_
z-Tq+8SJ6}5mM{Tg@z8*W*)(3Q4U9NJ_Nadm+%b{^p{x`xlJT*9TedD(J&Eq{C?=OS
zy|yLLbF_aw^~$Zc9{jO)mlr$dj=5~Gbz%99>Md15w^N4?U5;IA?R@+}<8c4_!Dm8u
ztUUF($)RuFc`nv?`%zV?)wJ-A>#Ex-+llL2uU~k_?O%}MfnfQf>rS4$uIww`R@iei
zHSxO9-_=R#iMfnEwO%gtNJfY&Zg@D@?8`sUC`XrfZ{9zAU!>f(Kbz|&tD=7*OOtpB
zTbf_LBsl9vo6S+%vSMWT#=?=U6BCnGy*PAAUoiI%9Y59ZHzxXz)q#HR`1Hxk@4xs}
zYCiYtXR(hM{gPI%4_i~~7FNFd{R=+x>v{a1sh!HvR`ao`FT8R0jo4LZeveE3t`Utq
zc3*jGHHY#xKGS-DS%&-#2RmK{Fa2+K{1R%yA*M`0U}sj5>-Z`Jw&Boai&k?Bt$`rO
zg_Sl-gJ7=BqMYSvY*gZ<f>Pq3Q!ewp2HXsS6$$@~j?eZ8Dqnyg1ZRMmkX{$y*4;&i
z+7dQeAnpg91J(#J;b^~2wO}m7sJpxvBqnefJg}s-`7=c7kdT1Z0HjBN4&3Yqu3v?F
z%4C*rC@&t0*ojFpq4nXGx-bj%n;3oR``PNiwWh?d1e=Y<7T9zwMK3`h*WvSfw}{&C
z4Tt;Y`ki3loG!oj<T7PWof8O$dZzo2-Zy_<q_>&6vHuWRszLRD#O$897;~Hu8`4LA
zzd3U1)=av)G=7YZ4CgD>L{5b)>tbMkGCMmopb#7l+)&k1%M3%2<s-G?!J8`wS6;0S
z^g6*G4^)Fr?`sTM;XC;h{DBA-p|%Ucb}FLTzEG^c_KjG`XV?14mDV3m<b4s3a*fa#
zl7f48OkRG`K&>{E{VNZDaerobo01<Ym9PDV5Q!)G^W<oJ-SO{^nZddIfw@xZq13)a
zwD@>`?*|!k+rH!z(cJ9*{Ot9KTIBuRQuFvF)$PfFUCmR2gEKYAGJ~axcRUj3JX)H3
zggG)EF|XR&A8O?H?%khP8uc0F+?lTV^~+n$Sh&6me}FFe;@OQW7tiFK#$tY^+<1g9
zc<f$|>$N=vK9wbiZ0oDh&T>h={Pt40GdgfNfT-Hh(fT~wLH!77ljfnC<!O)+zuEDN
zj<-R-vy7d_Zo@tX`Lo`{{uO5cp4WgF>QAfzPTI}g)aLU+dIS(?gT-oo3;@ejh-zO@
zDTm+n5p_dU;%%f^S_4G)7vKs&7A+q8>~UA;vo-_xUB%OD=RqK-ysL*f+YUkR+FaLu
z5!50HwM4r~nNi(79d(1;nZVBB_JYJ28f+!5`V$t*+P#~=b+r3Lsz_L2f6+YzbHloY
zo>#e%HmQLdY4Z|jPHkoag`u~f6IzF8@j&<t3dVtkrd31xsRpFYg_XQ2`ha!}7)bY~
zVT|@AXdVW-CztmrgMl3_MGK)02D*sHz#$gdJ6F4KlXj%x9ijN_RjC{>12jbs!0lvh
zxc233>bQ1)t7r#JnEXFj2qOIAsk~rY87Ld)4VKMyLBYT&$d+-TEy=qv+{}P~ySF$v
zp?a-2Z-x6koNPIpK1DjUXety+&!^+QkS(zFXr5K=6fKvll0$|aj;;01O+(S>K+@w>
z0$J-Z+EeIGr-GI4i77_|^9Y0>jOB}6`>ZZ30Ds&h_THHstH~2JLx~S!>6n}^nS##%
zb&CX|w9{v%KxQ$0<7DeUvW=%-)w3C%37#|h98}}!^<W;BKJ@kzbUqQo2$DOG4%a5h
zpO*p~KI`T9y@KM)uj7*!DsnNKrIpm)xw(8ypf;ST8(1`%8t}56$zX0#ZN|scOO{6I
z)Wf0ev$Z@s7B1u@Z<M6`LWE|)i7`xS9^keTV!3NzyisK>>3@28!^jo08;sszj`ygx
zOkyhE8QH=-0u@Q^U3Mmr+pid22n3*KBji^vx_L0j5c^V)-LQUGbAoo`rt$5aJP2i7
zg{ez6s?0tiwLIVOMFTO+=Xa9jFdZAd*RlfS4=`_}N4ojmse#Cqm-X=e=nzJ0gL`+s
zkLazL$-jq~xDqKO@0SHhjZMGjr6)Y)`BHRUdi{A9`JH(GC6HFkuIBQflb)&myudBe
z;>ePjuU`=CyMNGQlcijU;S$Bi`ZUt+>=UhSX9<6bCbeQd=c^B0c51BaQ(R}#9QyjT
z3v)+&U69Oi$Zoc-^Tc^mu4Pi83%`t?oC-IF<V3Sr9KLDfn!|e%J*>snyH9|sS@Opp
zX}ub`|4t!ROJcdt{k0Y(?F81G02dLj!7IHQ1eU()rAS?~R`w^olm8M-b{^|#{W#GX
zxba7V)cQbp%c+Bh%<SkniyKEOBe>DyC+P0QUFSD@jcgoD%L3KwH00Y4S!Cbi;VTYh
zqwJ7Aqd%WbMS9OXp7Kb>+*R+VHCB7vzF<akNF56w*%OB)=I^OZkdN-cVjSd-tWJen
ze;=LQY{V4YVHRugMZeDSY>D<r<_m?TquL8)g$aitUPb!CMvjvE<Y5uQ#1(ey{)$5j
zz=kLU)Ms+60pF6~TeLjcK!x=Ai}m`T;z`C%@s$i1t2!X};qW_GF^^Dl9Vf9I<T)IH
zTpLeeABW<E-^G58{SoJ(wrm|=hi}7A;5XtA;?LrrhdQ!9$5#lMND@87dg1_a95A^{
z%n?C%{{UCCam^}g`!05Mc?m!P9Vn%Ni%5}_eD)8x*0bBL>dw`;pksgp<LJoR5P&w&
zo=Xi}wB}06aWpcrWWz6DGRaNFgm@(vue!etz=`hkfY3mr_SArjcaN>^0lsYWAut4L
z+}?3Vgt=IiRbqlV1>dDr_JwXsXDH8N3Y~#Tx7z`4jwaVOKGXs6w|R4v?GVO88hS)5
z5Zi?eWr&S)(I?yl<DyKs0Ok<_T-;{X;ClD7s&uv7>(OYaf%}kLI{|1tQI{om45*Td
z#DTU!z_ozG(|7L{y#<uR3GNdeYR6!_djMPp*6Q}QE$8lAYd41L?A7bQM&TX<t6E!E
z`@g$~3A=(&4FN=ZME4$6uSV|)9@}5eW3AcRT;VydUW%Ii-^0R70g~#zEHv=i#gMqX
zz1fC{_B&Z^wif#cDr2|R>b~2%1wI{XSHep$T~J+Xh@dv*LfF|GSsVB)eLXvsI(q#7
z_jC}Hwy$kJ7PP(k{My66dwZ+nptrlG_+cKI_H7%yl{tQ7o06?FL1`hiXVzo*HqXx{
z%eD0{JoR@4O2$4$<F+lRs^a)VPPUZs`3HtAW-t~L2LoBIH=bigk{Kau2Yt~ESY6v1
z+tKgS)q#PXqkUdGu<1A$0$IrH7o*fMHGwH1b)y(@gwCWMwDGPKmja)kB-G9%h)Pz-
zl9m<s81ZyiH5Hj=1lvfE29DDnZVAGxz?=f%aNtf~iAM%a9z@J+IvQq$@ElHfGJK4)
zthAL}hI|XfXxDgyjCPSnet?NT9NbEGru=VTFNQr71~GGf35XhAvl%|*{gI!VIp?FT
zcb?j{O(pIaXR3ybTU_nPD^`@6;ld#gAFiY?IZ;X^3c8XsW0p6+-<x6BNdIdy`)2TP
zcLnd;yz9(uxWpKap+ndN-&<XIOxHA>`uVgIEkK$HAyvvcQ@2f8q4Y*MG+f99pPy30
zib;%wy3+wIhZRTkxJMSNbfh~G>N`2-^J_tjOL-!rv5A$xf^=kIKjpVPp+;9&*NC6)
zhd7Q(REz~Io$Hk)wSJBsh1xQlq9g<U<zF4}2O3Q_IM$O$V~g8@K3|d`)nq*A^{V*n
zEjyrY4S;iii8ke`Ag}BVhK-<=5yHLIVB~lE>{!4sJ>U%*KIn_(TjxTB)v(G$#PA+F
zf_-zl6D&BvIE1ean5M7wLoAUB1x?85)JaGBsv!ltb+0$%&tMSr5M&YopXN_@U0f@M
zLQ{?tsYTPJl@m_D3J3-nw1jZI6pj6KZ#Xs)Py|3SLA|TzFe-%xAr78g#4)X8ZttD|
zxN0~Q=w71ZzI<f`#Ijfv`yFTp<jz#Tl*-D|^0s9NoRyP4FQpUYNM|OQiPtJ!J1#vX
z;ox*=TtmvFcheR@jqEC2(zP=lof#Qhtn_M5q9EI%mp)&}`=fZLKO=O8`)OL&ef6wA
z?sM`K&3T<MHsxtjmbXWZCui_<l&eu;e@I=xI}_*hb>$)CuLfzGYZD`IySkoAHJXV@
zIp|@n-iANljSuHAA)l#@Bq_$!{n3EPMwJwU^C1Y>An4=aN)o3uFBy)dI4-97sO*-`
zkXpmis;=_bJ+djYP$2otM_Eb7LZIKa)O~*4Ki_%PQC$c-^}YzEPL%b{cR!Tq?Wu63
zCKHP#0=X;$2|S|om=<OoPk(Aya!e&wh$lT{Z&Sl)-4R4Zr${Ri#U9r*6??&%kBE>{
z1pM|?X@hrf7^0m50h#CYy%AXjZ<(O2t5)kdb8A!-SY3)hf!=3)Tf@lblMJS?fAkhB
z0myr*h+&_p%j}=*Suql$!jR<^0&YE@(vL*tD(3N9BLCO^BO#^R2?V@GYd*L&XhQfd
z#z*|%G|Ig0oezOVRwQCk9TFm+^i~=nHXVxjLQd;b_V%c(i{N#i^N3h3Qt6L*ok+|Y
zU-`3td)@2T5|F%_7k?S;>5mGQtUyGwjK!UR(`woqBAV)j;zbEX<Q4sW{*XTumI$2k
zhb0~F@m1<!NpT1V#MMZ!^}En?K#OxwW|Q+h@1Khp5~L*!LpY9VeA}6F6rF_3Bq_*e
zk^v`VR4Z(`wVs`&)8Nf=1?0uN1Mx6`mJ#U%VuCTaTQZ~zS)E8kq5(rAy5k1qK|5dx
z+|OUqWZhEZpfx`GaWVheo{QrVop1NEdU?B(RT_uJU8T_EEhEM5;gRm*F!5#VuUk8I
zouG{HEi<27T)F3;uKfE$-wf%Nr58^A=CLd3?fH57y1OS&E89nlY-)G*;h*mu0foGi
z**SjKsR4@Qg0@^3J?Po_spk^+{?qd>L~??bU7Fv#Ytz;gty-bJ!%x2F>0a_rM-$$G
z0dE375sgHmRHisI(%n5WvU2^GupfR0*re>p{HO2w(wyV*Q{FJtzzG>_r-}i%hdU#g
zbhdB(rLCWSyY;!^#G5Bxyll%@-!fz-VL*Jtc_(ybZr`n^_Cz5CPk17oC=@rykom`G
zY`N*tdp+1XZ>l+%#Q1152KobE$Klon_6>TVg9m0EGK6D3EC5-lW1v5P5<w7!S%Tv7
z4Xh6eYz|{%;4d<b%|YhUjo9Y@{RSy;96|5X<*M30h}T-vQk{Ko9SkV_VK32+R7DKm
z8h_P(Id;1^rd!VdQZ6Aj5jZ)>%52%`hMh{++$dPsLw=m_g`fnIULe<xTEj+~e00Qp
z??|qO4@{%&UI}a+bO!?h&j&UnceXMPF-UD^5SRT!jxXu<R{Nqhf7k{im^gT|qv^X)
zg}GJH5SIf%NUN-#%WWn>%UhFS5Zq>J43@T6|1)+sWPf#c&u+jj^B4cAPft~gqZ6gd
zIN@!5{rkZSg6X?c%JF~yB!qcBbj9r>=^MWCwdrHe5{akZdgd}be@*NA!+Tf$r#@W0
z3HwKEFuzApv!6S@^_uZGVf)}_wHS%x8>32XT`_X~`0S&tdrwcTTaQIlRf|Q<^^yYx
z!mu>gnHBwPwv)G@vV4=ybM_=rRrk@12q|MAxqG1pj~;g*#*`o&NC#jrs!-uD)(E0B
z!aO&G;}pEaE=awjvx3FjKHcK<0B=jcKNz&^qj-<zleFQ&{QK{D0et3e#4eAd?n#-E
zEFVbx8VmjLrzvM-$jJ~NOu#>^<E|&B)h(^Z#RI`U!tAXSj^wegI#6*wX<&cXn_2ly
zF*IGW@y!{1<#bSNKt;D_Qr?xKPryH!fdbficf>Aatb&)LHdiLr70Z(oZ(%WCwdWMo
zXkM{y#PlYDMT{NqPD?kpUi-+OTR-j{{S~&MaZpN!{^tC3$$b?fC;`6^>fN<|ed6mO
zK<!)mXR*fNA60tBjWQT6rO>R}^p(wU0$Ym4vraV;OnXaWFS!di4PuYRjSwt&5hl2;
zCx~k1L(3+C5mb;<q!iB8WNDPlr<k-x9Ow67*K(c9i7Aqej&$#4hsI*#WO}aDC5uZ|
z&R5BX)vbIswt4A2a}(^Rsw`wEYrXxblNuUH{VX0!v}QZW<?~NWn*9m9mZTMFFuH|k
zF)EaHqsLoxp&wr&_a5MuR=yuA;rDx*lSF)FTOfn~M69gjk|ihB6$~d0f8OT{11bO<
zU3%xQm^Y{=AS3^B$Aul2y1v$E0sh6uT{Q@sg0B=h1>Pq}_2jNMSO>a`Xy0YW!TA^`
z8gN)20^<m5YN!Piw}G{Y!%756WL2dGlmM+<3L*!XH!wb^g_FFM_xc=B*ClEGyzDcb
zq0Z)MNWb*&j!j%JeDzH1in;RLk4-p*kMlvMC->)XjjlU%Q$B#1Gq+Xpn=`{9ob5hZ
zIloMK9>x+|opYc{vhg*;SUSq6zQKHPBKHXXiJ_xgYy4IUib8<v9%Y92OpNEb#Ur#3
z9-_QZ{*m`y`oLmul$gEfbb2K_vR~p@><h>C9Q)d-ksM|(LQ#R+<P)u5Uh_@|i&I^Y
zO!FgbYftN00yA&Aa~{-it^edSmPzc@Vsy57iF3^}RqeokemD%;+Ua+G$UIF=K=m<H
zVfbRu+r9vCJg-5f=%0Z7;g1-Oc`yy|a2MnY8UtMG+9E)<iAG#X38rjUq6cK;s{U$*
zs{(cLlA9J_HSC6QeKU|Y6eRjJa<}TC1JB>3nFwivNgKVGwn6~5P`p0M3hBmb{4W?l
zSiLQ3L)e8yk(ILR59n3_LZWnAq(ZrvUCih@_`!=^lNaA@l0?|J%>Y1!0N817yUNkE
z9k^=MFbqZtxD~`2xSok{->YZNQknLCo8}~u8>(x5YuE5~FJzuxAo4-_Bj0cRv^Cwj
zKD!hOCNb6nOiO&|I$#|uxm^7VFBZi-MGZN)Qh4dk8@i)epV%Xc<o;IX?&bTP2KJGA
zZ@*&WuYOn7G)U@^;j<t6(p0YY?0;dqmUbj|+}Pc`@+wjb`M1#YiO=RYjaG)~<y*e&
z{I>sNS1VL4nLfn`kxv6%)qa$mo=*JRZSgDa{oKW#{#s^s{|z&h#jarQnb@}`Dw__(
z3r+lIBZE6HTs*XX-Ju<uwyykfYhT|)cVw)8eC5%;RI|$)ZM+o?CWfXm-b{0pbk1Ea
zO;v8cVedo=4+v+>Kxd_<M%EL7>G6rhp200+TPM59E3INaUF|O?k}DrbDq2!9-rVIt
z%CF63{Fc^J_fsSJX#S||V`$O;6H22sk;=!`5iu)??FsQT%}oyLW#g`^F8#!nAG~`$
zwm7x1`G;n-{tWhu;oi~MXD+?$f`MilLUW9P2}odKLTO{Ae+w=cvy&^k`u?>qyU%79
zec?U@qU|llOk8-d8VQ7}ms39zu(5mwi*%DxZ%B}nv9KL}`>W-RgTutdW62qhxKi0(
zFLySM9BB5AO@3=R6tBjnVwqb9%1Jv}UwI>DY70Z&cxM+;1Qx#PoZ%r1k4h2ub6#R)
z?^vUnFD}fdL-90rG!b%o!jAP@*{_Pu%AdW%oWN{CHtCJ6|6p+Haj4K$fEvrQPyzM`
zT6Iv*Hf_e$6e?;S=^)&1sJEq}OiF<7TzfM(9;q6fg%t@*kPCHni~+2Pm?76>fWRLT
zVA5@XUtJ+IVs08}0XG=D<!L?M`rPjhzKs1I+Yg`LA8buPd92r46I;v$=7lS+e(9yF
z4}Ksd{R^0Nda;+!eCOoS(n<7(_bi%Sl~AbCWiBShrW%c@vGGW%*-S;+-?wI4-~Nbh
zcnt2wGf{jJM)CaM2iWK@q3#xpf`&!?p}}5$3OkwUJNeX0S6}_oWjj4BrL}^+jD4^@
z%t`F<Kp+&2h5`e{Og^7!z54$$_Z@(3RoCCX?`iKX+uE|0hh)pLBrnObyk|V(y;tHm
zapLSr_TGDtFv18lkOXKM1xg5eQ=o;GPD<&7wm@l15<R|i-;<p{p^T3IhjA=DJ-v6|
zy=UEXe&?K$U?dVOq5p->!@nYii3e5#ZgGM-&h@k3hZ&p?h+~Z6d616s(-I7rlb!>}
z-l6|G8Jis>81O#UG9W&}084g2a}HXiFfBj9;DU(;mz)8C=7AqtsxfK_qjAkn0;Zc5
z1o%_NK7))|TEIB*o#1y;GGWv?Hu>no_}|G7CPfw#48>!iZ9R}(${fbJo3!${{ujk&
zT_lw3WTEu4m-bFfUneyu`oab?+pae(VsRQgEaHGEPhpxsq5F^3)V5TmHkNn|LAE>1
z$>)yy)zi}ovIghQwXMnPpq{?z#6u~9%rsA9c=t`eeCy`j;Ra7C^==YR3E3LE_X_nq
zZAn4bK&UwOftCx^580;qdxadKmY=Nf+|Zj}eC@n>1J?wKecnueagD4{CM}d!-JRxe
zq{S$Q)9E0r)Q81=g?kHiP@dqnU>ejg<m$3cs9V)ZpjfB9U^jYNIP6vhGA)%kbZI+s
z4SIu8UAWoey^uST#Y#{0q<CBP%e|-C%8Dy18y2enLT$gPw82)@R$M9n{r=l-JMaf-
zWn`{9(`dNu+LH9Ptn{2<ojoEmjou<kin?u?OEa>lt-)Li^=Byaqe^yqMbPvqJv}oM
zezD!br)g#h&`f#49Ke4aPq>B7X?--|X}rh4I*N<emR>LmZH~l~TH`@4hH#1i(!&r<
z5O*(U=m3+AM*YPEgDazHSUxkOJiigafD0D9<qSPJoR-hh3bHV|XUS5zkC2(HhT>Mo
z1?pEX9N>m>Noi4Xc9F@VX9<&&^R3>4(Bi8*rATg`hbq2%eO+B!O?qQVb}Q@p*<n*l
zddNFGF=1a9?4ce#b;Ei1!u9NA+cf03fOg%X$gFWYsn;QY1!!jf0il7XEiLRBDk_Qn
zM$6S>npwObs(&d2Iz{Hq{RPnjGly#e)gLHqeQo2rdIrVBJ*;%6Gd=cKm(%G&tEmz6
z;>(2R2er`E%Rk~?(`7K;-O9>vDS3wMJ2kU4=^~LaP`C0?1N)51d$tS;lX`aN8w`4-
zI=sz#_HmBke0$=J+287@h*noMFINAJT7PTa8bi-X4|`?f-51cd=rUeqQN-gl8t=HS
z%-!M5@aIi)L}li&+YCmJ$C0_h?W0cT<(luaX7&5Mbq(9m9d37KCj3$*98Lqy55#gN
z05s!<zKKH#YZG=uF3hulC7PlbENid)0BtbjVWELLm^^TyZd|J;eik&k=YV9V#ZC~L
zOF%hsNdhNp1CtptSYVU1P=S^lT#yd<Lo6u**nWji*^I>!R|N156R?BM$bnnYwicK-
z^if=Mk)~~Y2ly&OzgR+H;q%Xeh#SZX&ZxNUf%j*w92)4%)1|UCDZWJmnf>QaLm#iD
z6Z}MlwJB7{?f>3lyGy8$*@mbWsps#yKO;DA?V93^1Xo|7CkML6ysC^rOXHaJt=_8g
z-rkC`f!=~0?-y1_xyd3yQ&EM|tcBuP0=DB(L7IR=nKLsgDm>oq@`^rkA&;xkNpfdM
zx3mmzW*e0%BX8YE+j_Z3kJyGaY94euYYOjS#8{)p6<aoMVrW$$k_}d3@ifS%2RPd_
z!n&w!(DK*gr_)n9nua`mCa+vy^Zm_*J4Y7&VYKHqIpim}=8X1k<%T`?ou6fq5qw?t
ziW_dFUb?pCTu)bL;Ub+_Xj)myvN%fZm47O^apBVL%BK3Vih&+vUc6B$S0kINn!_Q8
zz3i9E!OfXoUfw+*)F+t=%lVn3&7&)ZxZIIt{nLFTBq1$c!f|Oju86X#;_I=jdN&PZ
zRZ?oENJRI<KF&P^v}R0jCDbN#CiFvZmxBo>Ku+BW^oA{S*vnw^0M-{LHNy|s14<1x
zsX<k#w2)>=PNhvTgo$kfY^!2|qiKj<{;O?R2p|!DI0v#|AUl+%$Vp8G-=Oo7fqbx3
z#D+8IPg({s4mGUH@O3{cjkt$?O~@*5x}JKE`Vn=1ILUkb9uZe&zY%?mKDxD%El%3A
zB#Lz1uetK(tLJW<80Zo-=h+tp9f9iWGJ106jr%)1T(qw)kD9@gJ-xO(ClK(JU*4-L
zW^)x1p`EZgsy3-i?8JqGL#txH&<df0vvy6H3!)bau3DJ5a-@IJ!<)9C<fSWqLW`UC
z((FzbVW*z7aPz2(OBR3!%EFdLk>JO|gITki(J*!R`kxS-j3*Z*@ii);ntD46Ne^v!
zFbR5MsihCBIriO6_i;lip-34*kL;z|AzM8yU8|65A+YK$(Jp-8&lZt;dJ?ZTGk8y@
zduYYluFTZr<a=|n%AxT*B2p5o(ni*;q!tHDHK-~x)05@S^u+bi8dz`K7rHxP0pz#u
zgUl(qFDql$;Z!B23JD`U@M2=$6kdC5!vvHHP(mPS=>4z)gbB^yYMetv8-=hmu+)SF
zz6WAxlKJC($7w}(#V(-@md_kxY!$3}CVSNUD|2Pd5;R(^BU6)n;j@{IBP-{R%uq+%
z0(<QYzNIxkP?ap;NR#)ULGw}cwj+5GHjAa!vEhvD*i(fqLmh2Ht@-PoeHzdj?bOa6
ztl1~Dt=)3wm0g>rD}}Hh<}RJBRSD#IzRDVZE>*AKY1CuOd1fdH<g2gt<*sOJ_ePy6
zFqYHZ>FK^oVLFaTRqr;L%_geT2>V&;QNe<eEGUU&+@y6@mY0ha;{5s^lB=$*t*~U2
zCcUr&()u<&`s-6is0W%?jLxL4Q5V`+VrOAl3423xL1{@rQ+@3GwGo86M_(wd^`Bj`
z^3?UH!wHd&tt+$5W$8|LR=zoV<<?e5oyQGjI$ri=CQHcgrRfrr49*NL7aatzlhxq>
zhbR|%6E5T4#*rpy6P(}&i9*)R>3G%+7UNLckLER;Z$mFBFehWZ!pdWbk5NAH1NiM#
ziH-4iDMK)r4Cp8<5CqT*$$`=+c!>c_6&D~tA($+*0Wb5Hz8if6UV-Lfb{-)FIeXZM
z1rI468MHXmfD{7S1i8Y!%^?eAiCKv&JkVap>9kSv&f90$oDswR_v=0R%R{2=6gjJ^
zdUUk9Y8Dx?7#s>oVfB2$^xiN}P|TBwbIW%Y4m4MV%wn-B%eZ+yuWXsNP-}t^86R4D
zrX*z$98Y%vWM`*0YExO1x4@@Wcw*IjWm>Y^<I<C746Yt)`mE=&{utUq);8s+vz@6D
zn<l^LjUwZ)j+HFs2XhN=xnonbJNn1snu;28B)8=W>O$@TM|ZFJp=o_JF7M1c-mHT0
zRgaEc%(ST$n(m{&gH&$bFjULa35<q4NEqc)cbRfXwpWS9Md=sH*;<#kWUQkD_g+iP
z;Rsn`VSX?;aKSqwLZZy%-)M{$`5)e4$*uO}UmBhIj11Ik&(|F8$?OG(7sjb?;8-CK
zfeSvGPUy&-fC!N8ew*@B@d|peVC@*0i~q%o0Pm5-Z;|8l1P6gtIK5zY3<ki`7-V>Y
zTCM>Dg82lc$bo9C!8O-Ek2?0ou5T&~wzmiKTF_Iu4x?42&?E^Djb%$R{j-yU3U9jE
zzyXKQ5Ov*O2%}E@z@S`X%`D@f%(F#n3?YTXoK4-sBDtsag=%?P8nrlIp331<@4ZjG
z(dU1gSVY}b*xVirwzXV(+F78JO&h9amHXH$|5h~5<g~hpQ@P00qLHIib$z0(c7nHX
z=8IWfT94UAvG~-(td>m2$y;Nmh(1Uqh5zt8J<ZKxzX|ai9q7Zk*zUq)$fzIsH4Uf6
zPmTA!^yI{g(J+P>qp+qBb<7M+5;*+j;_1adxK02*Zf7Je<`;lnu#PRBK7H|`ww49N
zk-AKkLeSF5=exKw4xHPyO}2Uw2hI8O6X#YgT)5I9NevzuPfyR2iR9MgoM}sr-Y_u}
zD#po^HQw~JvFRyACYeaaCLQ?Xi$5eAMJk1-erAa%kuAr2-`0hTE|q7t2sm9_(MkzY
zQ1x3<*`D;Yo=p?w1qID}i$@D*G*|3Mv1aLgHT#Oz8Zt6c?=LHB^}uGpydzDUo}=>=
ziEG++wG@Ub-V(NP1Z|mhT1fhm!W{1AzQKMGysg6tD-yOP9Dx1uS*W5CgD8O;`Jqnu
zG}MM?7RZaSNbyuKgf>ZV4qBh!V^g~!m>@r%Ihp{2pou0e3<e;B+st6+1)QScfN_E)
zi-QI$f-#Xz8yYlydSRZO99+5$?hfa`WuWOCehsfc+F+W8Jvo5r!N!H*;W1#^2LB{b
zH5Z=>cK}B*{-tZO(BptY64+G11B9W&I^*xrEA68LG4P0ZSEjJUtzjoaJ9PaRd@B56
z3iz}IgbQfUq=(^{jP;B+W%$bfVjKTPXVqN8EVW&fr1zz3_$qVhlACYb#7>2pK2il+
znUZGKi3oR5iq=3Fav!|D`x=(_+T_8dhd0bxdFaMAbDk;bCu)o9OxlSj#7RiaXDOh%
z3No+NrEz&~E~hEYSpp>`jV#T3QWqf*@C=G%k|*ZLi_-XHW(EgJ3{&IvJSZOMF=rr_
z6`9tjY-~*Alt&v@P)p<~P;uAJS1Cja2Tv$ZQCOkUfKkpTaLgqW@C}uz#ynQaaW~1z
zS2?+rj*(hjzPY%8$C_9IDR66qGS@z&x^KgLf5d71r4o?15D6;G8Pz}qYrnUqZYI^L
z;6jUK;ljl{p;{uDSy$uruj=gR=yV6t9rg@=NaPhkW6sb{lgVhNhRhbLiFkXYHf(ZK
zo+;+3`1MDEYA%~+2)6W*b}QuGv(#B9LrOxWYs;G!%0MJv({g-gItT68ph@!?Q)(J&
z^#zqCdD(P%%8!K#sIkc-puquGXb!WJ1;t@eK9^e{)f)9)@e!0JRVai)o>8Q+@ubx2
zDx)Y>lqF5(qUq{l(k10+H~}-NzkgdGyR>O9k+IM$P$}&ku{^~l;|UcGp#nEA7V!0n
zgifn0;KiCt630xOr$-DhlN^yz0x5T*58A||N#VU7mT!=HbL-;s{7|sX>C5A=*-&w|
ze09)TmF^tKw<bzut9K+tMY_6vXFBy_rbqWPvl@~;O{oF_I%Tt^*sVCi&Fo1}aPDQ_
z3o@}WVGwe5x4|CaHpY4YQe+4eDofLh6K5FALtp}8N)@6M+KeZebAfFgP8+rcrnU#L
zi^9Bz-_vOWlYEJR&rp;B><u-r9E1kq5)*GJ=|XbYeHG_msKEk}Q#b)WgZ@EqIVOs!
zf|v0<1+W+JJImHq5Nc`+g9mrt$Htrj&F^<EY|4X3mLpkWb!F&u8wjG(*S>H^G(4K@
zqwcY5x_5v3^mJ&UW;93*(m6Mr{Z@xc+MYjg^U=CtJ1<k)HEp|G^WY7lMG`$r#D#2b
zC@Y>-Up*XaYu|OlqTHso=QQT@?wmsBH1UnY)rBRHT&N}rf`%%Au_-0iS))%jrG&C2
zY)e5)ODNpfYNkd;p^-Ir`A-&X)|0~Izn>bHLRsv&u{}JSKqNsQ={GN&+tZ%K;z!V1
z&1%v3%xgpl9qgZFP8^K(cMK%viMNt!#rA2lV(9o>m8M;-$(yf9XN_iLHFVikF6R*O
z*o>CGl9xy4LWX&WYA9>?Gf#eS{6y7|EmD`^E_hgPi4gTtVU;-~QzYBVh@@If2aG?f
zk=`$s!~S70pz_xP;^9ETDUjv#>Q72MEcdW5qqmE&K(u3%`4D8IV@kANwVrszzOidl
zD}!z6RZ*aL(AolbrkxM?U-}id@s-Nc4}CPY;?*4iDO+RDUb2@Z8zlybm!+&|ntfiX
z$em~L*c$HGxOB;eI~!~sbFN41O7}Du?Y-sgU!U4n)R>t@{Wh6)N9{czG;uVgh24YU
zXzUM(!bIp=lDwR8M<pvVZ|W~7J~4k{aLrrPS?Vkz&ZIe=vgFv`X;0K%s)&#&6+*38
z9LNlY9BP?HNqDKhl>XzoGwIdu^<<l}0q67TeM!-cM0QNV<`(C7R@z5a-4$FlGO{Z7
z+^P|GQG2vX{@%fFoj&*{X;pNd2Vhp;I#HI<o}KOwPIDB?%%i8U)5)H>-0h{-2lFha
zsOLfVzLb%XX_CP|lqIETTA|%85Nw`Sj@K94KCiOgW`7KPt_9sa_*vTr>m3@|AI~~q
zv=Cl4uz9%5E-_3nTn#FjOY`d${Z1z`;4LE^I>Yn<%R`)PFAO&~6&1E4jWO9+Eikm$
zkg2z?qhoa1<EwYt!7rLqxLhg|B}VV5i)3xhvKn>E0vvB3Qcw`N)>f4Le$L2=%X{ne
zI+HD&EoILvY-<e{HML$Y&?{t7R4)<L#zMTrL~T<4*!LzD_Vz5U$)9~$V^ojK_Kh~>
z3QgtS6T5mfA92U>((lfm(@|PdUA9j=FWc3ZW}Uu>MO21m%4An5k<=LX&FusF&x9Dt
zs)Rit1<xkjm+%P86Nl>u5~MfFwCquWzl0WQw7*0f0Q|9x3mI4N#Q29!q|3T0O`SHl
zvB-=c!%g!zYMEB0Rm4e{W)BE3W0wg`JYyJKF&D6)#mmDKfn#iiV7v_Imm3WGTn(3h
z7yHAlGq{5BdiPGL>ap^`bR?J!of5yZPOfOrDLoHvC$_4zY~@2zeRUC3Z(<qej*KjH
z+K0Nk$1@FSUM|Vv)C<MD-)VY&I9Pga<3ursvoYUEJp#_z6ts9|GFK)Q1#{|}W>Qs3
zp+YgSjA!9$#u{pU!L{8zDA5_RXxN?rl-y1aM#Nq*{9m-!Vl-N)HjMeBZXuyHR?3?C
zKEzv5@2<TC<=3LS7Y(r7=sjwYzh__tRUZ}cH*|Hab2^=^tR<$6Nyme!uJM4=<)1a=
zv!!^ZdD{Y2!JvFXDW)P^6rwIovt2XiUKx*ldO?;(;;O!7tujR>t8u3d7h3Z+?CNqh
z45emJk9o34wnE5#)d~&N)Rt7C5Z!0DyIgi#DwFehg#9x6BbsMQ6B@u{`&kSaJ^g-2
z!U<}e3{QaLgpG~KxMhna<v(-K)m#F-b-|-T8=L?Q1CX~fZU6!?;fe#;7Myg(U{MEG
z$B;9u99j2w78W%(7ZrA*L=(+mtv2WKAlr8@wO+*TQs+0<)-@|F{t(S%rFT!;I$UAR
zj?Jsn>rJ*uwxsQ`-OvJ!C(l5{uephKwyNO%QWFH>cww{3=~QW)Y3Z3oV;)KDS%MHZ
zOI3M3_CR5KTTxMS`(+>IL14j}<=TI678R_ao*4XdF(j8r)50Y=nVBUsBgGS@yxEl2
zs2Q1)Gpi{#$G+hL^#*1+M+In|SWg7H!;u*rzEUU_*|?<C-BqNLD@=J@1*Ea1K!KA~
zmtCea3QWQj=y#@pRlxpp?9((Scz{bcf_6HY@STM7kUjPq?M26WDhqQO3&Lxlrm!JW
zgeKiu&<Pnros0()YYyzUbQ16z7i0K~nA0FZ%fam4v{;Z`skaLo0{RClBRJDB`7e$A
z0~G{BfC1q6D)bkzw4@CcMqz^Wk9n8*8m&PA76w=WW-ak1Wa=fOEb+=u`qjCIRvUeG
zj<SO~`4Sa-^zp#!CTAr(<IH!_1e){kxzy=}m$NdfUiG`&sg75oiDZXHSE(!Nd5zN<
zm~FN$Gt~90>#Wry){;B*MO~YVOClAYu+4dL)spOiqcesR&&0CRIVuihpK-MKf5;<D
z5~{^Awh($KTptY$46ew{ADvlL82k0Iq5g1jVbP3P6Z<pxHh{MB-4+K2N{E<H{@x>=
z^l(8->@WKdxl=<$E;o8T-Q`M;y^9qikwRS#a+0AN+kLMbz4o#Z6*Yyb#B8+qu7}Tm
zo7!z3A=!0VHm=QLy0PH$`D#lViBvmYtdfhHtYWiJQ!BB}IYRwf%pni`R=sD|(NOvP
z94OB$mTU5NHVTYITQ=TGQn#D<@SimxS1SoM@!P(DZ(?9pq_ncEe{h~J*gINQwSltw
z<Z^FHUP+S2U4$AUg@txYX<;~AV6#BSMVylk|4r)5<DBP#-crGX9@m*bBnhCm=&dKL
zA*?ga=u>|%h2T7EaG?VMGSy{iGX<*&APtNZ#Zn*M(g9(dryJmc!@wF(_U1faQanb@
zk6pZ&1X!9xsZzt^Z@ovM%I`b>?GMqk$IstAHoT*yjoPx;b;di?*Sn%TOV2F@zqluo
z|I_@-1*m49D>pOM{+>8bBS}qDLi-<*yy@;c*HMX!><!47s4@t}HhENT&?eS-pV5e0
z`mzqLe|_HQD=$2>W96a@-5Z5f`>j@MYPOzF2y^D->ea<zKG(|Hn(P0^?g^EscZ)0`
zL6Oiv?c(0WehNG(jZojMCt)CAR>C-qz`7=36L=sGB^-mky(bgC1(g$~;#(wUx48WX
zvqZ-{xiSDN_<<{6a)1-*oid&}n2;1d9o=H&AMCFKkP}49LoJQmq4@*w;0S&v`GkzW
z$H%ag#pitC-+yr~_pX83!>d=ncK!9QtzLb&c3|cDcTmDhFQJ5Y*01b;CX!dYV}A2&
zM}EFzcJurl#d(ou?v<tF+u11l!NI`?Q8wG2pCY^WY(D%)-4ltRoJfTF4Sts#iNuaF
z2T(me5Ic(hMLAc!hI8;2==11vm`}<3Za%g4*zy%GQ<o6?<rT}1tvz+~@Ae*j>#d`E
ze}_^=#y82T0;?si{Ct;Wb)ZVNX?%qG*;79@!dnjY%7X_EJcu$m@Uij7s041d=yL3q
z%lM{L#${B9-^6yqJ4E3_GbUffrsGfW=lDbVIM_-J)U|>LM+|Yy0K~t06J~(Lv;k`A
zPOWoXl)^HCok&Ynf4~l17wokBj9ZZk1{8(Ufn+pUB*?*l#Qb2Fk&Kk2se*v3!B<%9
z0Ahh`hK&bP){LeY;3Hf+n*J6(n-RcR$j3LUV2J^HIsBMSL9jFW82_QGuR-{e<5y{M
z>=f@;pni%*5K-K@#Ox%~d!9aj$Ci!iA5=fZ${sp?|Dx8#s3+y-?;z9Io@AMMVouuW
zTdte^o6EzHfFXyDoXKR{!nOl@UPVdfHQKTB94g`VIW~wKNc@tV(>veJ_RC6k{uE6|
z6Q;|@sXMQ+aD1gfcIu0lUV7;t=Qhs`9c(PQgo<xXSu*d&Z=Je0-)Y{vRemk&-6WaZ
zB)2Ifb0j{2HNz^;^Cww2fi!-SEa+9S_Bd_}NZO1}Bx(w_N}wA=(dOQcO3|L|Awprz
zcBfzS2k6=d?wv*HDi&+e68S*iF6#TlCYzIW=~~qG-nW-7%B1e5$Q!<^Z_0fa%|R&-
zaRgm8)Vs${?yX+Xa-JN%KvgXciFpKZd4Z!S5~&Ru=g5DxNEL0Jew-5`X9%@YnPU#b
zM-}$X1yHVt6q$$9_3kA#i2;$z-yzBtWoRJ()RKB_)<%KJcvq=Gc+{sXJlV_2#`VA_
zs56{5VNWuYuny$KE!gY8RzV6hUPvJj4*rEO11unY03c1Eav_lzzg4D?PPqdd5Dq7t
zf?uT2&_5+CwBG?gSTF-7$6^MmqD$Ul@e6CL1Ph({6bg-lS<g@kmdZ34*#NQ!RE8t%
zAjPwQu%H&S9qt5ljG;Ub6b>L2hIC+3qN7=yH<3xmbBIK`fJkTxh@dvTTAnJB4sf}~
z#fFP)1zTa@cga}hVyK&$ClV$>Ew^@p$V6y?1Hh<cvXHNEBoP2rzs}*H-g@u{)b1B1
z9FEoP^G-hdlkXsd1qC5*R=_7iotx36KW?2z$Ymd}d2BwPY=~XHdBe}nES>+e@s($O
zDm54+&}~6PeaMC)Qq<o7BdSt#3U7jAGU{V8iXcoDv!X<j`aRUKQBm*W(~Q4?wrn!$
zud=92n?%%$WdfCo->}-c&|q3*MlIC0d{#}GPCrBMtcBh<;>-KR<R#Nm6a2p=k~)&x
zU|wd1{~L?aRR(7`_I>Ct`evR}TqpIdTM#vHBv5#~N0OeiY9hjSLwy1ApvK--?nu_z
z6Eq18pBQ<su~&mN*8??nwj|sHXoxqUvdRZghd>AwA5%~PT@hdh)KWfyPNVzLlUT-J
zfxs*qet~zY%wo{i856?5az^3HW?=(tvef{sey2{S)ixdR2nGOmN(Vhbn1CY~Qx_I9
zAQeC$V7xwd3Nyd>{p2q#Pn`5exPCHCJ@``$yP!{}Kf)vjFX+oMM5bj<4Jd%j@Td4Y
zKuk2g%Yb}vCcN?EZ6K5{bp+v2u7qIe+rz*R{#1*t5c)4Tz40yMujwy*{+MxraW4E1
zf8fsa)o9rX+X^r~;R5g}Gc#9C`_wKK!v*N?!b8A=GWTa*;Q`?TDa>PnC}z?k=pN^A
zIcyPOQyWeT26(TnXfkD+pvyvXOW|#29l0fHJqsE2#vk_0YD6qT9RB@6#CCWu-S|VJ
zp08o))g`%(v$qwtBufc}Ngioh;dLPP!rzC*1VJ{=>SI}yi<a%%Q<=ocagQIab!K#E
z6H%tS!!a#qxFoGpYAQ4~_lDh#McIkg?DWRU;El;mrUGv=JDA1QuXfdW2C}${?6fA%
zvXfD(Bm$A#Ok)~1rNG}d!euE1#itk4C1pMLH*u1V#YSSC&>cl;aUIZerCG1fPSOOx
zSQGLt7jTj)_v~A?2r8&$bU14dkGsi3rM6;AiLXhWAsaL~Z3a!1E>UaD;ArGVsm>Ie
zkanh(_(mMl+#Q)nnVDVG=nnTfY77x$p{3@=U}b7^HWvyHm|9osxmiJWGHUb}q;S)W
znQAVX<hMpox?16s=dzOO7MwO^aOB*Pw&Dz<Hc@BNN!e+d{6QHvU!yVDoYRVJr3#-Y
zJzK9gLn&$n3TPJLhSz4OE@#wn%*jHr4zXEe>n7@kS<dOz8|7gcA&|<|(-j&1WR(h<
z5L6VGpjQGzw-#?morXrgGiUn)0V=ZuO2l*YDpj&SLor<~hZY#JuzX{6TH`D<uxa)7
zIp3j<PD}M1zP0hdqGjic9d5z;`u<E~zVObLpt&SxL?0?CO(_+*?E@}XV9@CjuI4xE
z3o9ENlIF;rcB6t_5t^Po)0kbVYT-8O3pocG8-mb-%M-292O=GUtQ_5gZz?UhazmZc
zhHj*wYUo``X_AqTB)-h*I(9>jb%xNWlUB@8akuV}v~_T8I`SPy@%d$o4kQbW`I-Io
z>jjq`+7sg<)g3$dl4bKvGG}w?Y>5~mUlx&C?nsPOkTMuziLt;p!x9a)=v*%6V8G?d
z=+s<eS2!|T8yYJO1<g=Nuhigk&zT;oU@PY3WC=PV0ewx>W0L8E4UPU`Ljg3Sr21{j
zI<du+uYB{t7_wA^3dIt6MI@1zsdmj@MyN|lo1HTI_zCUII|$j1tz4B%XXAFX&9LS)
zu$NXybw**k@-D>gsm}C4S79S`qDg?5?^0?jcN_ZxAbhrf9z6rmxHl4h2VmJ;*c?8D
zE}$3DE6^%T0Eu^Y!V4J^cps7#XLl?}4cHQ+#SSfyXc-Byc}B8g1&mLc6rYUlyh`F?
zS&M%_Q)0DC`>n1>IuH|a;|jLAkeC#IgB^xY^wH|H!Z_d*tY;lioh}YAz|sk%F_siq
z_<=ygVY#^MVJ<OwA+Y#hr1*R%Z2;h}G8d$ScJL6`I0Rc@5`c*Zi!T`8v&H9uz8w8s
ztofk^JtG&Hq<i=fZ~oc%1~4ip!mGuZAM|DL_vtyLEl#*OuEB+mU{Qx}jfFFFv(Nks
zu@YKlGp8GHjv0PtJpFhe@z?kj2<rGFu`?m*fs366_^$Z!$e#ij9r|IgUkH{KzBsv9
zP8c@aBYrhJUR?SnKCzilM%>ATcF{1e%q+lp^b_L8#qt`=EqD;vs&328jFdTZ(o*ep
zNFdCC0*-<$$j}X4;>2w8nKeGS*hPvoH5u)7Uhgz14|*!;?QPH;EG#pMTXMp3Bl3o}
zzqOwjQhUQWz5*ju-eq&MVvi+5W!dq>EVVH50sub6BCa<LN>W&oc9?mjq)VMD7br|E
zx<qlB#+yiVAvW7&bQS0YO5<GEk;?h1TB9=7B2?$_^mQv0bxt{S5);V?0=nvUN$O3z
zoGHmXZhl(5$vc+WXy)k&R!^3LC(&xP4Uljy4+v9CMGCI7EUMQ1BoxYKCwA(qV&}^x
zLNmKLNd{?8YIU;3<S(jDHfR!g&~3<Nl_+%_<+IT8Q>$b($@)veVRK!*Mr*Y~dp1sb
zWuwY0k^7URJ6kiSNkvNNyFPEgnGs+iB}c)L5tr9hq+9f<VS5UBKpWF1D+>+M^mGwa
zsO%8SGcvQB7NcY^H!sUn-BwyJ;uA(CU%)Y>5YV<gRU;*0FJx(Qqxzg6pA{5uSja0J
zFeS+)`5r;X_JXt&zRP6Ru*E8MtGb@77xg9E4Jx5(d$Lg{-_H(eqOc)$E|wNZMcI-f
z8KJdRdLeP2ZKw~{&F$_wdTT*J7+TPAa?ET2S0rZl+daj@B94xyNHZ9$nTD}GZ`S#&
zE%U4_pQs!v53|jEd0=)c_)FT-#E{YsrXE+BtP*JCf()@z+oBfRd`XvXmfFn9zjTGx
zn}a7Z8%kR8?ECHJwPtO*R#~qs%Sk5>*-XMD4&k2dHt8*)++bp|i7mYBS4>MXq`P)Y
zb2QK_USTYkdz?E2JovK7BxCt=tm>u;p_4!SLn3%Ce<8nN5to&dZTH%<p{TRLDBx=v
zoCme4thQ6U<!yqO_`b#wFz^iP^dIZSbi!PY!s>9Cpsysr&cgv|qM0SN1I`oD6?Gj3
zS*}!GEYEr*%e^vDrgzU00~TjtdD3u_x=B6A<`V_%W`}7=s#3Pv8-?oB0+~W4sQ7p;
z<QO-SAGQ_bWKPe@xGV+3{>YtNC{m|fqiRkZ6z+4|vm7q_9ByH0Y5B}3cpeff!bu!A
zOUZVZOuzj7PGTsWN~WSBZIq`<OwtO(y#jIK{Bp5I45`h~Uy!H9vL0iI_j3*dpd}5g
z=In$5$iwOdU+4lX)v+*v9}pin0hIPmPKjwbgR?Rq09&cKev4WOzsS#q3WFe^lyVE~
zlJK`tkOT=1p;>?g;UhH29DkW)0<<7)u|fc8RDg0ghdUkJe{Y`N*TJr+`>udsgXi$@
z+_B2Q!ok6SifBp(;iL?8#GXA9dyagRdN!@7He8Bg&$Q*`scb0mlhw)M*?m8aJvUKa
zet-GA2l!z{CiPZdL-T}<TJ^?^c}-4H?yDI$=t?$adA(fT{dFwP%B4q_c9xXp<q|(u
zdHqR`dlfw;B}i3Pc4^7J)ynxhP33hcLfB*XC;Cj#OPJChMy)z2*W)5*B**Snm87Op
zk5(1U;t;=6xId1eUv$r1(A9?yqUDXN+D{oIAw0)KLhC0#AWxG&0z4H!UJ%|w!Y?`b
z_cYZ?wZd-X^hxUP)ZZZGjgMZBQ3U)KqtK5i7X`gw5RM#?t#FORgaivT6kz)?%-S#K
zr1(K*gMgMpCpEH_dP*Xuo)P$E=N24!sjEt)KRCwWgosh%F<U6xm2vr_VSKH2xYi-K
z7QQfP0SO(%jufoJKx~7ap?zkwGYx_d94?JQArA#EUm}uF>&AlquExdB6xUSMNor8)
zopZNRug(7%`cWiFBEfsWWR$G<pr?5D{E0~J23~nplOyHf$g~?@xGry{Lt6v$fglgQ
zoV=a<1!Vof{+!uyVI@Mxv*LP*84S=KHURKXyqqbmi<qOJbu?-j_STTMZ(MWsh80^!
zXY|Mv&f(6PYm0LNC0hmQf~E}rjApm}$Bi|OcAm7qw|~Xh)?IT}QLi5!8cV%%@kIN;
zvGEyWWLr+=!k!)by5<pD1)ES?#@c7TYj;M8{@&qr4HXqlo2YkMbc17fEpw^a<dfuw
z;HNagO3-@~A2=8Q#fldKu!w#{FNe<}N92>QX$=PoBh(MVg-3Mi*qg*+xz_L+bu-2O
zTS%@hWU&g>vhd$R<aJ5emsb&Q#poPV1o`OY<Pq}c2@%G&qTT=T>0wIpOf448o&cA`
zo`0;ou_gv(OItm1{7yq2S-tMz<3H){?uNQ7ca1NqiYPg~xn<qu?hG3*Ngj;W5A58i
zCJ7|h6<p{T8ydOw?7R`pBU^U-^2Bg=7iVl&OZ9T+$fe%gG+j<wHZkr|YPGongj6DP
zS*MwrHgE67DH^|>J)V#PK0MlQ2V#RpZqS2@6O|7W7$-ikIK5$GB0hTZ_JzwItc_B?
z$_g#rc6Pj?vAuOxVC%Y}-OU%ivuO4m-lBDzDhjgXuA-Lp(I7hgy={99s|ow9yT3hu
zeNO%?C?DE7eu5hR$-d3h<^8+5ms~Tt=f|TCS7dG%(A<2O(_fN*OGpNA0^-OSB3A%q
zVf-;SMM=+~h5RM;%E9)QiO$jcDE)4wF3D5u;aRfJqQ8?HsQMpJ#>M@!Pou2|@4PHl
z+=*^V5i5a}X#U2}Zb--g2|D@oz*l(p&xlN#SfL9Ij^{Gg5q@mwjtuT0T=@sT!wX2>
zzJAr6x3AcYd~SDc^0bNBNA`{_ran29)4#i|dBN<ao`_KU$qzkisrTlU)eQG<zNUXR
z>N-7tPVbDHKiX|HIZZvw4-NJ;wC}io-&k-4Q8&M)BDZJ;1h191EsO12H~l-l?%{<S
z+nUSkuw07sA+u%>?Mi`K__VQSO`%5vbOtOq^#m+Dc4qXnJBu0c4F_MQe%0PmCe-9!
zx2C&MFK>P1p2c&Pta_xn6sgXMwB@0?brsOGXx-}S2(nNQz52wDJ6lT>4fBU@p84QU
z_iwrX!j_$;)ztRGRU1kR#=5s&x3hck@=+`&e4l*6Y9p_QT*L$mrX1{a1s@*F746ak
zhErl|p6kbh1wS8nAg~mRzvYtP;@1ROZDZ$}BmKX9LDUm%_ug?V@+a!AiGF2e@6HX8
z{zp#=yDG*M_gou(2Kke76jdyCh^1qpAo#C@ULwS1g{FhkXv_i^3$fT?Qpdmex<r^o
zgy9p^M8&9HE0o5Ax%2@cjFHbK$YB2jx)THfNG`1HVC9hp3|w+dA4|{;{e`QLno~q*
zlnsT7sgG4E73UvBx7uYiU0%xVC632NfSrJ*e4o6{GLsL1#xOxu%d2RL;U|c4FuWvV
z=*F1>`WLJKwZ-panRo5~(d!3x?L6?tj}Gj-<9tbVW%SX<N-B!Wo~X>DX6NOhLwV?h
zC-xjZy!Y`Z_Fa2y|2@bulwuvGenCAq+h&{bxX1Gvgsfl;FpyK^@dOcQ9S4j7@B~=W
z0lNe(5Ez-dp^|HHGW-J+93*eZ1Aty6_Gnbi4vNW|Yw{>_ZZ7&|-ahf=Q=(iX5tkCB
zQ8AxOJdl;omk+)jd$P3j@6jlA?fdWhivboehhBTQ_e*eZ5Q*{o;<i3qus7fqJ`zta
zG(f<c4-5HHP+MDiA9WsD5=tq^;JmNASrJUXd_VNtM%~o@RI-BTxzXpLP6?n!A+^*K
zxSslUl2F7(+tFPjGoEjT*39G?MtWhIk8>%cLurC>0S_(D0w8RePw46y%=T0Xu0e>N
zn=M){o0T}Wq9B7Mxw9lp{W)9`oh4;u6s&OAJUl|Ew*(71-l?c~yR#rj{K%|PD2vzi
zZK6&nxXJ7=n+>IFxiU1esei3hY2kUzO+}^DTgX&e1XF=|fxJlG2)q!69!NAj0RH{T
z*y0;Z*k;FVG%Q{*XTXH1ttm9Iz?P7XB+3J9IdBVkao2*ISi*DB0_y$3s5DV6?3eJb
zpTBMU#Puw}UC}}$Er6pM0UW()!LHjbUZj@2k6vEiSS-s;6eP0f5rfyt?2(l;ty$ev
zD$CdMHHbc}l9)ZxlE!tf>nUBL2EA?k!E4MMlQ+PcLcw8rO>r4supqUVuF}!fGmRw+
zJ=0)X0zD}`!E3)~lcVYs{BnIh9<-bKt*tnkDbup}JIDypd&rwFHQe*bY*!}bk_ogV
z9tVeSBA${8G-Q}rW5Pkc$fiI_!~9)YV>!)3z^YJe6idIWMIPohHTj}N&*3MxT&S&m
z^WF03jMF9w2N8+-Ki%-NYY!i}_NV(-SBj*`tQ|UotNweIKI#?f=`P*8R;Qn@vFv%_
z;NEAR+IMJfpA;w!=!}SxH?V&WxS%U@pqA6m>!WM=e3gk<(r?h_=4$l=Oa6H#SSRV3
zpuU@;@1b_}=&jVlpF16xrcjiX2J>M_$bmecDH#JU*DEp~GadMW@c^Ny_Z6vwJp@4Y
z;Gv~A_23&%bL9;7Wg6ur#cv#p%bxni?HMg|<t&x%o=3~8%F7>rgI^z*S9tP=x^9c7
zK1@V<Dmt6|^Av~oJV6VhCw47gU9ezYB3Q#2qjuX&>Q(AOH*^}T*s^fn;tWGMma~L|
z)d2HX2$9065&H{45KK)RkQER<uHG<7LfBHoj$--;KMH;ry4wpRoxso=T<ImN%8I{x
zlEvQ@&G~Uov{>3M0LQ@&^pl+ncl}{TDwKHQtMfe?zJ#UGQ#br|hFx*|Z^VU=+neWK
z0H}p;Q{RK`=%5vVi2-*@JSoQvl3%v;NYqtlugc3GbSVnd1oyiVBX$2IEfR0Q+|%=p
zCmgEoz#nYO0SVIcjX4;8u!jXtHBE~0DY~Ui25=4$Z``^5%%IG~63UYF=F@wc0{#qF
zV{}93+_S6JkGW+My-CGoiwmBwAKM*SJ!=(Ny5#mYbp}UfKvrWx*N$LLb+ON_6j}`1
zS|^ToM73t>7Y2<!@Ni%0GN;&}KLo>N=$6&Sehcej>>vAI=whPe8*1ap@vegL=D-^(
zmliHyr_-d7tpyM<CJuOzGzjeD$yU=YKZK)w%mLP_ExFX&9O2et*ZZl(BB(LgE@V;9
zo9ehW$*gm&#rhgh>F-He)&!~>*f%#(gA}C_Drf>wa^;|zp2)xkgO($rHlcR4I1S!0
z<0>J2K)<k$gS{6v5@-}riqe9eY><+GHK<P?D@qX&{@0JJ;pfYVb2f48g}3f14hYBx
zs2#9-Bn=C9qp(S$xcp8{(P>y8BEf~S$VS!+pfABA%d8MhL?Iei9p~1dPmZ_RL2}ae
zo-{lIWaE}#;YJ59TdZhZd|-6=2S;{R=lYaZP4-29Ze3|Ege1KA12t>mE+A}q0{c5{
z!-Jc)KDBu9<sX}suvbMlJX4+@_NGU2ONN>T!F-F$x+U<ec6h_cc<g1oTFy@`1+A<s
z<dQr^nt%UE8&Aj<o-IzH-b#yz<Wg=MFr#2Qsb!tqpB3hCO|cwk;lgm6il-u;Q1X>1
zzSs5<CFB@K#MogV<-ejGMznpdAqFxM<c%5l^uJ_>v7}#WhcP<iU3ex)&Wo=sUcaj?
zVNDRLE-*Cl;=cP}b93aHjG}8^=PW#E47V&cA*0A-6eAZ)ET4(FDvV6L6?dYJ*f}{b
zpD4r!S|L9v<?^#4je>x+!_Qqpo`SXeFWG*qOaIFDBciMV_Ah81$!x8$s{<TJSIixJ
z0OkN2p^VQzPFJjgqGakFb)>ABY6oEsZ+@eJHza>2iw707xh(={MY)rRf}qYIK8gvY
zkb{AlHiLLh%2$S=J0n*X3*e(P{g#j~!5sW&Y*5yXUuuKGbDP<J`JdUKY~9ziLBV#p
z$bS3(+6HAQ{v8_>=GXwwFb#MKnjr#kn*Av=niiUVmET53rfFlENioK@117o8*wkuy
zfGL~-W`se>t)}i~i_S)KsJC*WGLK+b#HC(=?x*}@xgyaPZ8bybeM8z98_eq*WXg$(
zRdU`U5&JtL7GLSrmqytJ@INV*QK!;s#Bm#z(1;VIwJubUkscCp*nC-HNow2L(jfy;
zEuA#CwR}nJJ~!etrj#j!z`j7cUf|ykL2hAfz{L(T#iY!KM)qnzVbVJ`00d0!?iovu
zQ9vK&P|l+@jT<*M)*N+GIk^(C!o5keZqDJY=gw_8GQLi;IYTLuke)x<XQIU;%bVKU
zo0bn#+h^MUI9;JDKYL)&wS%3VL&p{!I9H}qOsDk|;UgD-e$oNTYtnARX3tfc33yuN
z^sy($c||uZu(_hchQSq6dMO*W=F~f%QcT3N1*z`gS#hNl`$Kq?Q>FT>N`iUu5I$lB
z>xcBbO!*!$UILp}*i57mwKx<8@2`4C?+u6*x|ZAKw~e3NIIDJcLwSE?N=xOg9kQ^j
zrdAe`U4QT4eCTavBL1G3wmvOqV3F57(UE4<81uqQmoAiMW=dD@-o?f3Y+)QuWG2>e
zEKvI_J{#Ec0>lRf2$)ykiIL0bQDImay(aW<z!V1vBR&mICe}sE=Fg968r7+}L7TQa
zk$U}^_50OL4IGZAso&?BnBMv3z`Uf9<k}g8a3oq<ny)Ibo1ki;7qMUE4Y%4-&F&JE
z;mu1a@Hr*-Qa>4JX7@2;0~is^kqzEJPN6&pd+pTn6#N31g>IdJZGV^`C^aWnk&gA2
z@$Q1)MlU!<V67IYrX6_)IfizlzaNZ-rc;XuX?T<!?t~RucFj)(E&)~DP2UIB!oYfw
zwuR`m!1n@+*P7xF%IT+e!U+yf%ji6<NXyIl>qrH3vnwR1`n=M)Jt*HR;-H9}^6c$)
z&StJxLYBbwEO^|AiwDeH%T7-okQ=sK!RrRR>?2Dar~c8kEW*yaj6_SrEq-%Sn#_EH
zAfC6I4I!cgRhLtj(O*jlxWkh#ch?%zohv!4PuvnQy?z!L`$bLw`xEhAG82(0n3v%C
zFg-9iN?4>IoU(F7S@la>kXdGRwq*-EtCpADW9!W3dx(#p`o+6c88Ig?d&z9o)4z;8
zwuF8L8}g7A*7v}VdNr4TX$bwn<Y2yGT8O{E+(KGxuHpr%h9iM=(+1Oeyb2pIchKyx
ze6`rPe{gjdaUT^rSOT7`4Y7|gUodm!Bi@HK#=1=fs5oFnka!UB^@Dpwqs1}}<K5s<
zG{pNw7bU7>$vG)sVXZBjZgQIs<_yV`+DsWNNd2XTv{v*jn=A#25$Dy^Q-_;wHt7;O
z5^Esm0n@pOc#@+7#Pj6yFdPrl6Q^`$uZcMj|I%(edbu#I1GT|xdiRD$Nbh;##Q$V*
z`7DPc!=+W#tH*sQ`U(Ak?m6G7FPeR%zWG>R`i%O<y2gcDpeA)gZcahn{gM1$^9D=v
zEJE5>Q7u=S)E3o<$;-<tS$AehZgo+yzP^={%1`xkmpb$8da^XXC@oJUQQA}z!Q#zz
zsSX|_A!9k_gmwQB%$pP>*;P-(NDnSHN$6AxUpDchz8S|4^>_CTA2~GCw>ztF$+xq^
zi|!`(?i!gr(!Y7z@K}HE!z(%${BC*gQkW+@;U^=o?ljL~jYLO7prk<xUK=c)pcyad
zD=z&SoL-S<8srrrv-W7dI9klB$=Z;U&*QMP-kb(v25ZLPU)JiyfsNgRf2RC1e0<Gw
z2)2AIq&6}2ricWfGvYOP4)s-(hTFDaGK<SX=4t5a9I#r%YyBf925XRUqp7O-#9{nM
zp~bZsj@6CKGle_Iy*;bD(3U-I1I&}<dMn>4?S^M_Aq#N;?v;gSjA6p7R+4tO&|6%%
z3*LW$^t+PqKpdz@FRx2aTb|}EgYate$ez)KE|nSzzJ;2^IpV`F49`4P+cb++3w=UD
zPnVa~vpQ;fw?~z><Zx;;_o*%0hDXh*ux@tHKL(gz8NF@{hKx}^uyhu1Y)`HmX?Sd?
zd+_j{o{sK;z37hLkBy(rDx7zkHKS|G*1?&B-Rm|C%%l!H(e%*b&IR<k`G_-cU51b7
zk;^}|P*6E<Qk0#sXEY6uUo*8(=+%#UOO-sLfcSfDAUf8G=1s0q8?}3TyK@HS9~ifj
z^$JZFSVo$Y;u#*3QkZG0g}D`10M?Ms#_sE=-+H|ymc$h<+ja8`Ja=(7)Rd4%_6|=V
zE=ml~V$rfVGp+c&U(Ib@{94c{9&E$+LSFJHtP|}Y1NH*}YWuv~VN1vdWg8|X1bMWo
z`&2Xa+?AUq+ZQ&EMhhc_vsmb+^|!F0j2^(k03&+Uy??(nBTNv@v9ql1rV-B>Pc@?#
z;d#FgW5B|L(a$iaahIl=BbR~vqooq|=lHVaGVu1pLw`S1xn_Gs`SvxHp}yfqKibt3
z@z&LQBi*|{dUUvtoV}!dY}2N(_9eIV4iP>sl>Pa~;hvG>$47b&BOY>beZ){N-tz>3
zx8LMo3Q1w?gDbb5l0q;o@S4fWgBgJEjf2*Xz_Gw1Z$7#E*$z*B`R2iqP`dx2O(zZ9
zp?zB)J6UmG-{S5aN>Bcr7Plj-aQ3a__}T|gx39i=*KKuqNygkIp$wwDZswinjOP(n
zk~8*?@rI$2-09=ZGZ~rVCl_;~;5P-BGwrzq(a6k7igijI10lfdkhV!vMyqi`Zzn86
z$;BGIlND(_@krR=%|->7Fr1c~&XUyKso5<j8uHj3@340Ttp@1HD!6^~ca~K@99n2C
zOwGtlix{XsqF1_qIIXDe@oi`1Ip}CXcK*#USD04jv!ftC^z{B7)(X>0+?)(TBm&k2
zP(KbQ?QNz-xrUrSGW*V^JLZgxjGu10ea`4!jz4nE&#CV(D#{C$kh|9o&XR!6B?TjW
z*Q_3xC7wH1*xz&ethQP5*h_K=;T6=E&zRE!rUS#ztQUdrj5taGy~lwb@RUrh*r!+!
zxZ47T{-;TY_2SI~m}<%^wy&-V4Q`#{O7g?+_fna?ySpRa`Z{l<XBTTm!!1j@#y4#m
z?^=3G!z7DRkDm($&ryFo+}*T$cT@La;2$hg?}9Nwc@Sj5YQUn#sE0|BY9a2TE__dl
zOw`-P4OoaGKdWOwO5PClAuT!Q?QVlS+BnaPfd{Z11M-r@Plnawq;a9d+6EpN!VVA$
z5pUlhd7ayrzf0bc!!OveQS_>`HMC3K1#iH}Kn>fTuHG?xaklCy>Y>f&TV~ItF3rYz
z3>j!Wrl-B}%;dp}(LdN%!(_W*-8-oUuu_Vvwd)47)j30XbDHH|Z~qqc-+G6S#&uku
z$1$bl=B)<7LTU^%QW3!lqKi{1uQt?&l^(s0KI#Kjn0Od+@UX>$AJMM?Q3mU!!f|!%
zXq@zI_^d&IakIj+?rbSuF^#&ubmFMNvtY9s<%o?YF^VV~q~+A;v7^+7w1-3b_|3}v
z5DUlY$V7|f@)KDIDhY3=mcV_%zd?OSzE120>UAaf<2VG1U*pB7LuQ+Y3n*eKgG091
zaY(z08HR^d1-uH>z<YgSXkF~?yl#?^Y$aT)h8Dj#60Lh-wDD29;s@Pp?K#0#>RpBX
zv7R;Z1y#i%B84R&9#?SmoN!)re1AxjSB&~9hrlQN!c6LDLtY_u$|#01GMEN@)a&Gn
z#M%E+tO6B$d8`6_?J$!WFh?3JjWNnI1!m|oesxS8*sIF;Utm&#0anKPEziV$6k^p%
z*lfur!u8yiwYS&y-hRT)gL)SB>u&98eDL1QJ41w=t0A6Ma}`8r|Mmwi^ex4ny?}|!
z9v_&TgAd7{!~J0oYbP!Ksqh;Fg_KwM6KRw9O7H})40fXaJbL*^Hg@BK=di_{r_9d3
z?kO8zxN6Xln4h1dA6%ufy>zD7YwD(sgpdln_uxiUv%=KlhrM}ho{4(i0s)lWJq8P8
z0g5VvXC}w=0eJ(A>Ax1gL5*KAenZm;%MUb?5A);j;VNoZNk9-0OvnHyiDG`nx_}9F
z(Y^cdveB+@mOq~#(CAAVp8EN<M<JSZXjK)25|BmD<w3}+uJrA9${V{vWgN+PUP1qk
zeK`naePFB|JFxfJcvy=%1H@GKh;fK|je2d^WJ{}RN#tpv4+KNUAFv9DeF-fzcUyp;
zr+mJja_CJRrRfO<c2(R`4Zgq6J&YZK;PEq4@9QFBxr{p<T=ea1!Hyye^#Of^(;|fR
z?{OEIpxZ+cv@7GZK}`7e_#u%Q4#_z!A{JY)o%#R=Z=n4->ZDG|!J!=Y<tvHjmE5>v
zpQpfe5#;=-w=sC5MDgb&MDUy#Qx%5;O@<l1VCdOCLKLx5zcogLN*T9P#Ni10vx=-p
zXDkva<(yolrJU%T9F>xIS{c7Bhi{JMrLh<p0lm@U_r&#tVJ}W=!T1)7v61k85rzPA
z6*C6$a5|ALmUp#G^j0?Jq&of6{hehlD_eA5S@`zgY@&(a@=USA!zD%Dz;wGe%T~?H
zFY=cY!*ad`qaG&Lv>onSK|gC;Vx!N5qvJ6a=FXp9O@xhAChWrDvgzG8t9|TXbEI8E
zT|CJaZZEP^m(1Y#mvPz!B=B#M9U*%WUg35=3tdPo3pek~UfltSi%mw0t|Tt-g?iMr
z?LDbL!7QDcryyRG@~*t2#?We&+)RH;)ck@fa|!uzS^FWm1fB;=Igm3~lOhfVeTou+
z<l^#WNyg>hi{uh6BVr<{$edCvQ7X9;Vh#W-*Pkf%DQMB6<fwpzcygMaRD4A&VC1nI
zA}6Ng3EK(sgpRAx;VD|2$?32SlB+QG05c7}hT!hb*7CvC4_<F3q|ZcC*v_csvc9Cm
zBTJ-CiM3i8b;q&WWRh<k1-~~Ex};Fvx<CvKfM5nWFoToS&fyz~*Dn9cm_kZo{Vf1+
z0kjKoGeAQ_)>tO-Lt_YOc#2pqIL3j*X?pt*czG|41+l`NvD@Ry5H(kZh`>|C$d-a*
zM!Aq3yY<*9x$L&10>gYH)XUJNW4EYOHxp3NU2BqZNL6f<xjSkh?vo>SNFAF+7^cH`
z@El=1^g7E7at_B}7(Eo<5zywzm6$Y`C!l@482xhoi(@VE`+Pv&1#4lM+yVXTkTO)m
zoiq!`yB5z{{Q*n3BjWkUUR*3`1+gRCMyNN9Ek847$xgfC@n50c^J~kf*FeWy30ys{
zgjA$(arNTSE-(Uaq3x2`2dp%B*8i)RJoT4v5R-@XX@Gg7WAamo&i|8`{GM+dl8?*N
zH(>4|l*rUs_+Q23MPD~0j}o%MZWh3tW2+hZ4}<sO>hRbV5eD8AKsQ=gf;?H@;{lH7
zsVYBpufGcVfCx4U*`e?C$Z`$j^{DZldTT68Dq?UmP{>U|ykcoQhoh>Doq=^Ylre}~
zdRWUa&f2(If%tjc1Z2e56#uVNvbzVbz3x{m(bnSd^97~BW+8ir+qY_3)v;UE8jt}#
zsg4To92tLVH~K`uQL~Cb4J-I63S9`R+M5=j7u(}<fEmXKjKd7$0BAXk!3jQBtbgF9
zYS?grXq?n6tdTV-)V&h3K}y}OtY&-f7;G(G0nJG`oY~jp)HD#ysOj=YrWDfcMno9)
z3wmX22{9(&2M8Rfr|$)g*!R(L*~%qo2Ps5cnOjam4)GpON4tHeh5(*Z3?g9E8;7;T
z*zvR=Q78P<A4K{j5%mU3B%67mw59kO^4Cua^y=A<mbFG!k?+*(A=j@dD5)o!o2kFY
zKGK+o?XhJR6PY1WD`?=Mk;jScCiH1VNf=dN<ndyApGJE*?0kB-^mspDL6x%qB|ZbI
z-EV}JWN7LG)+!k9{{o*uG=B|z2J8!cz*m6J09ycWyT1-TWAyXk8KA>l)Z1hu@izEN
z07(hC71&be(g6xC1Us;?er2PLIT^DN+4%a=b&VEvAR_Qx>|B0e#?Z0!&~S02R23PR
z8}VdqdtxA%Om>wJI0{ldZDer6x^TNQEr<GvF1fkA2y`0wUa7Z<>(M5BS4J{pCp&#R
z1_Dic72@7l1{XzK&#Qfu_N#VRbu~{f%<W1`U%u9zJ}uptCRdp{MT%Q#x2oOUSX+}T
zvuO&Sc`~H2Cf0y*#?SdH`Z<$m4<2_CKaB5)qcQklvDNOxCMhj5=x2pT{iJ2tftf>Z
z9GTY?5&A9_34Nc)!ZYVaGBZL$B^#)}DjFL`1^{qUjr8>MUOohW&;pdMP&c(lHmr@b
zK~@9(ydMxH#0T{L3=EXG+XVJTKJ1940R;4Rm9bC2GzQQtgRjyMC5_WeVsX@Ie)xfi
ztfo9`M{-7?(k%8!RjXGY8qah4iH()zHVs+iFF78i0xmXzirEAaL0o|uJrg}Pv`q(d
zKqk0iFO!LAC-@bLnK&~&4nWaOI;rB}#i_UkUX#gRJX7!+PoQRkf65#Sjk1fAMPgnq
zFB~jvnKrAfT)9S)E4ja6V#nyJWwUl{&U06^G|cL)nbvI&P_M18uxZzqrzD-FKG~C9
z)mPuuQP+bC{g7VAO3Q8RjfBz?4IM;k-h$zP)9D`^c6;iJ`~@AokwR~=`+K+gZFRTi
z*s0ukrRh<p#R6L!Sl`$$$wssaEV2J8&Is=E)p15Z<E%|+E*(qdFtIE~R6|6I)(%-<
zMNf)qtSzjQ@24a+YtxAJVTn#JK7LH1)5)Hb`+2U#so(7-4z3X<D;tM%(6{@!N49c%
zSJ`~ED1&UG+!hPEhT3R#pueXPD9YhPk%3K8yHUuPE@$5B*-C0BYL*LfiDIbp!_X(t
zMh%P=$3h&84uh4a-FX_!^VoB7MW?~2bysv6Su@u~{bt&h!p!X2X<n^9;z@Lhlm4tM
z<fRQ4Yi{be`<S41o5(i}3c|I-PJYX350;mCl!83N^yC0RPL48J27|0o^RnZE!ZPAR
z;s6@Qu}nth6)~l)0Ok#DMk!)YX~Y3z?8gq+KA*X6MLoArMQEHtHq~;|Cbvx}r+#G=
zi=pmY-NK6octH`q^mX*}f`1S8R=fXm7%<fM<rpxK;bY)aq_Ox=$>%F#zyOT@1z7y6
z_8)-7r#)f+Vh8edvH1UDTM~!jGy0u;7oO=qf&q(fn7<SQ2J?6d*6zQA0Yi8ED-0Oe
zw*|zW{~iX6_N;sb3>eJ8OE3o@*l7%7isj$QLqH8*iUEV?HWN4g&oE%<`LBrq1Ae|p
z9GJv_VP5!*<A)Yw|Lr`4$G$NHEN&|s;2Hk^#DJj}|6>?1pxqB)KMR_g{olfXS-&a-
zEN%lY0Na7afW`d;*boK<h^-!sPX4zrU|YTv0tRs}u!nCU-U90s@)WO@<WM~Un_ze#
zH1=ZBa>QXT+BU~UpBMv-xMgU@?rn{=?bA0^S2uQ7Hg{KbHn)UwI}6gXcc03fv+l_F
zqO_c$9&f5=?a*j@)2ij|(;;7@qP@ap1gp8OHdmIS)TTvy=X%C&Uv@~gZFsP3dVMji
zFFi266=1L9HJftg(#GM`$iQxn8<5`&pVslO;c0*ah<%?}N4)Ys!lqFVeJyNS>~+!s
z^JAmsF}NHV$HUjdro~?W5^Ng8w_zQgC*A>{V<L{jUQH>OLb&mO3YTpG>cEB@@q9(k
z*)u(rW!-n*)l;^UbOdJ34A@y{C$)%W$FChfKeP9dNA}%$&;G|B-@kS5f}3w%xF@=A
z(Wz65;8E!N8PGL&-^r}|7h~Zx;wxCVrq6}K(bxNsEP?C6*#BKD9QEOsVc}q|E)u`N
z_9L#F__eWcZJ!5)gJ-bCeok7zE(IS~oENaPfKAlb!@^;)@WoKL_}sq_G=+7%>KkL>
zP~=OoaIu$(CyD3(zrn&$=l@MC9IX3~VBTmf+&^&$y}@Th<`-b$BA*9^gY~de?~oB#
zcbdoX75*J89MXIV77q45u~%UKvkC9XAamDxwO;}@;{OqR+U0)<PXpa(2mg=(p81>N
z(~#y1@M*9{XW+U(+f#DoQ{b4df=}!C0(ct3JERk>!)rxTz&FRIRs3ss8opQTE%GR=
z6X4VEz5XNkw7b6!JT3mb--j_wA|kFpjsk#P{YLmS-B*IAVSE~_<(tH#llU~oi%1(S
zlV%G{%6|r*X86kRG@xB4@atmmxzYGE%t6lo5<czKuLw`W_%xuE`RId5eA*<v#Eraf
zf=>&7b$A-X&#V`L@BRn)G^F{e__Wy1iMwD-Umc%@_@9eU16d^o9st_{>-%qxPiy-E
zcp9du*o(Aoq48<7WP#2~|1o?T);wPZPh%xSs0wZ;dw{OjUjg;{p>|J##hmb|KG^gT
zHVuKoF(8Qi#CJ3}ogAobGCoFUsevw2Vsp_BQ^piR>x{ieZKgKG{zNFyO0<Gdc2ZXA
z4*0R6pQ9G|`8ib?lzm$nFpz2PO<P<1d2Ug~gKCYiI!E?|G>0P+a~#~qB_?i|dTwHU
zW4V7G`T?~$_8xt?m4pIcp1#V|RkK;FFiK=?__I5!xu8nb_i>?sjl%e#im!@2m&zla
zM`h>6J94719}y%(Vu$%BIAsZPu)_R+_~?L+KF6UZ;Q54Suw^-E2B*Y#PWFE~^3Ugd
zr6XT=M!&*+KWA){>%d!{MCJz~#r^^^F|V+#tuQwh{p=C)?av<hxc{?9*lRv}B=-JS
zTfR&4KKspozTZEOiO6FXofQn@W}@NF@|v3RXRmsF>4~e}5F=N;x#+s;4a)ygs(A0J
z(?509t8WKsGoPZJN`5=1A7pSU#MGOiruQ+RoC{D*@|W1srY$XC1KPlf@4aaV8yH}~
zL{qzQrjuU$Ee@f;cczYE&p8}ml0wkeq#ArT@I73~IiUC04DKBJ0_Y5wtBzq00p9(^
z??&&>=@c0{nT5$=KvOj3(?PlJK8Md}^Oh7$n~Ur+xi&LTW(-)pZl`xvo8r>5*;Wtq
zs7aEjQYse2)@J`d_Ra&osdD|}=Xp;?7tkFVN|VwJEro7ITPUN90;ND%El`%SL{>l$
zM8LtQWr<r+P~52Co`_x-A}+3ay;uJ@xQcq+SK1`^|Ge+XNl((uCT#-EM`_cLoFwNQ
z`hL&vd7j@dr6MamDLObkq&T{JPyQj-&Kx*kehS-wVTfsiY~%WQ!fQ3ZHU!gm)BN6u
z&U6laB)&4+jQ${fQ>Hh_9}(ZPX*<T_!iO?#rs*@M=Z~>c@|r^i7=Okc(EO&d()ex7
zyCTOhUAiZ7;EU$div3QS7M!OT%YH8>p+Y=>TZCSvn=xhQW<0NyY09+1v_e&(N|_?L
zExq6FZ8y&!d)v3T-+Vqq^qV<T{NJ!&yoGnk21|Z8|B~bf`9CE;7_W8hglH;~Jjr6)
z7OzT9nvQ#(<l(PLZa2Lw`GL%m{Lq*r`2mWY9{cYl54YH=^ySFl=7UVv-U5Y8zMSif
zem7$<Ed$pYW;ldOA#2Qb|DQT`FQe30jD=wINHYH`Rmk=?ZF^LmEgz84Da3e-YkL?j
zQD-;4j!)Px(>-dKW7?0`?%sV*dXL!f%%&`-d&KYud*rRVcayy4kBya<L588hvlMgD
z&Av10DO#kCYRpfYhv}j#F&}d??uSGS)x_i%Wnuw-M^kgOeWEq&+?ZTIufBppcVR?$
z7JkKv9^7~_<P|0=K!H{Av<UPSU@wOx6A`O2@3i0w<E>#TSQZ`+#sfSLwV<zfX!b++
zKfgaH+}NNBGtPBwPd4qr$KDzgE<eyeBdegP!FT`wYI%NsS6NS4*S>xApBo#(gJ6Cb
z>7CKPAPcm@z9x@l74$cLOCJ%(^GhCjXwE|qHI>pwJmhrOlj{qzGWs{xvdyZ<tHLWa
zEfZcCe#1ASuMY}`WvVc8v*g&wEqJgucDv!kl0711#LBwmQKH0tbtWn+W6`;nbsu0m
z0!oHa^e5Vsz&c8mF0kO#*^?F-L(8CaBYb?xq<MF~d~{0b-SM*Ehll6)PnbINOt38e
zo)LLP&KU6ic_jtKXx==zhoYoUznQwi+%HSU5P6&tlc7HzT4OvDCnG&^P8)y2w&cId
zG0AT)=J*}uUZwvk+l&C|>e_M-%3HjkOK-u!es4SWGZO2=)ik43ly}1BQT7!2NOX(S
zpwtz}<G0v6S?IZ9$$JaAjd-TqkKUyxxX<uhX$#`BeU`Kd*f~0fJY~J7t<My=$up|s
zWwy^54<Ju}w8i;iNNzpU@miaw5&NAZ<-7jq^i{>p;1+T^%xK$<=aGc!EJ#aozueAw
zA$f>&Gxly<Y~IoFca7}~I_tx%A0a^_3)-{bK>HNO&#`@+U4pttS{zWaUh;k{FwX)2
z?Lr*C$>u?&Yp2L_DcJK_#?%xmqO)_zuvbzFZVrxuCCfc%y|1BKN^O7I-fw1z(<@u-
z9Q|7&wDGHKeoU@Y3w|raE8ihl@tMR;$4s-On1jnXB{)0qfQW{8hhLq8nuDF>0=u<1
zOPj8CkJ4;YiG66xZn3MO#$`z3Kec@<cne+|i2L1+ddC1lnB+hf!`48GXckjI2ym{@
z*|2`$Nxjxw*R3-jbYo%nrlbO8M3<o9N|{W#irnpt$>7BL^qioshC?Cf>(BJK&Ox0?
z75!3-dCDz0Yy-Cw6ONAJ=W2mOHk7Uwk7@ZVJNG!-Gj^Uv>+(wbvS8a$m*FQzhoR}_
z))1JdsKpoAKe)y?SD=e#YFqQw8tw)>1D-;<Y8$qq=Zw>%-v$y|kf$_tz|k21?|Vj8
zG7k{S@QMBNpy|rivlL#cvGYU9O(VF8+$?S}w+5-nC1zs3HJlx93nFrXrlgM#a*>i|
zJ34&&O%g(B4Kc}FLZj9857ft!H_!@1qQ{D^O(GBFA`P`rw_N+DXF*1m^s~>=K7^eT
z5|Wvb$I#3Ehi*y~*@wP=daY-vQw`%rV{+>>%wAl8l*2h?9JXpWJK5we6ORj2<M6C%
zdfqL<v5zt^!Tvt1aG7c7KDMksj>Ib<`vil(sBxSIr|T7%{XnCoXc$FdBpb33Ei&1F
zAo5MLGCC$YMV!A;5`0cfG<u>H7P!JVXX~^{Nj--f`xhj}YElcw^$!mk8=I84R})@I
zJ_+d>8#Xj3I5~PCVC!kf;zgk{2w4%)V^Q5Zp~M*g8GjDXC@d_Bk1iaR(z*A<jAcQc
z`vVWDU1g*gZLkdQrG|Ev5eSNj3c3BiWPGS1I!2jf{Qb-B{pC2KKvXi^XSV8<+c7uz
zFjk#T(|=`crB(?^5AGa+mhYwIJvKPb)^Te)mNM>i@o+cwXbo18!`3H>r=V5i`Z)y0
zUEwac#m=e5&NWNDYXMfq4`Xier`%6?uC<BUWvgD<igS-%YSY=c)>Sxdo`W7Tn|!P#
zl^Or*;+bc>)6H_{*%s%V2SC?&sRgtRbN%!)&U2>#ns56oq`&W^%tvdXOSmgAF?|;*
z^e$1KJ?V?CDDJH(_O>KNKy-!>=02tCj*DDqp@><K-={8~D~;bt(9MCSHoV0t;u14j
zNMsgdIL-C*0$!24N4q*3++_2Fkk(BH;e5+ny5?EbO?meZtCav}>j+w~=Laqx4M>(y
zD2_#1@j^3~HjZ<B_Zi<2ITg0q+(kBOtW}tZMpN%DM}_%H{FlQyr&ss)qRS|2^Ph+d
zeEY47yS-_STc`_HSRWYs@M~P{`hntSxJ<+FlkFoZTt_wc=#9oBXHVlpUmpwWvStG@
zp%#ln(MkBLNm7q3bOncJ3^1s3Wy6DbUa2Fe)B1<^%HDWiygYc$cvWQo0g<ue=LE~T
zKXOBUPqj1rg&^Y_#h9obL8`(PUC@W@hpRKPczIW2ylSlR<#DmyjbC?_lm5N;(rW`-
zdSE?w7xy^QM;lTuCRVt;7h6}bZ9}A0x_ro*_Ou3SJw;fu(!~>@i!1zUOE<g@uZSM!
zUg!RS=So{pYAeo?wkX(oEF-?)@|glBEa}zV9z2gU#b_7L7sEsgR&}cb&-6P-%9@i=
z>siXJ!;J7fcpgclKnvcJ+%Ip<c_Dee^fm0=mcF)&SZP@2@?q9XtD_bKYQd)V$<j6L
zag2)xlsqCqMGM}vAW^#zDXgEO4q1l!oi#1C<`+I~&6N~vEzr<-*yVi<+a+|^%!2w$
zT--VO^CAf1x!Y2&oQPWGEYvEOqdvX?Kew~4IyA;`d+7t0na>5hbNwuBdde-pvyXEP
zF79gB;WEnMv9PSmPQZO{huKV1A5^KJsc3ZggLci~hy|l>)37$SXA8!s^lFtFa<M59
z7ue14*W_^<S5}ootKwsVwY>&jHZi~WnajEi&m3DbZq1zGy<^k~DkaayJ#>6*+T5Kb
zW1RuqbL)qeR8%BFXKmuTg3-ynDp#j>mBl0vs$E{3+qbXwbdQv7-F9smo*WS!KY)6j
z+hVvIxkKEu+&lE&A^SKEOQ<a$<I+7$`=L`R?(bE9V>!d!?j6FWmwf_ssqUN^sjg9-
zEv{?e?!~j`UG6J9f7*iUJUDawlJBbBJA2?S-$9=KZ|<B!hGGv$kN#ega^6hybj59W
zUP*XN%39L<S?^ts*8PT&ZpW3|()Zvh@5Q)x*!2%cD68$D?>2W1Fxe-0Ppu+9OZFRu
zbA2t?&!d0t4j6Exd;1@rwhe-D?(8uA88Z#GWWgG4Hg_qv4CgC0a@XR1aLR(7>=|z|
zp_^xN(-|*;;b3=mJ*;w_4lUVmC>{$tY$*JWLEu9#5cFtZgSWH*j!=kxofMm*gg{j~
zdEo*K8hZ>ZnOSsy>H=+MuY*N*XRpaf$~5*%35Rnp?a0nl7Q~S8DdEPhFmy=4AZH-B
zde-of)26;Ybwx(k=!DL(<i@<-4bUsTQ>@{#M6}_w#eLV}<l2MW3-sS$TXCO2(=P6@
zmT#lwJuQpVZ713p-f{i#G~MV6$os?5L5IFBLLEIftZT~q@XUCL`v}jCHeouO6=n7d
z&c$<uXAf>|G1*g*u0`EA$MrMiKkikIJrU`w>cszYbha2ibfYpX{63NL8m$3eiqnD{
zxgB`UxWH@D$4GCx_Zvg<LKYj5-0vcwS!ih%z-656`oV3gksy+%ikyX>X2Dy(IXaTi
zTk;+p$Z!_@fCJcEp=H%p7)f{WAEZM8ZiVZ65bAA$SL44OePm-lGice=-Nv8~z*OX|
zMaWwi0p*mn+*;_tn{ZX?`krcf#!F!Jv!h*0PPh(IEp)b8+}HM4N;2?}AAya4(g_F@
ziBMM)vSWm(?U)D*xUsy0j!n1%Sx58LKgZ?=MRW-sYaFAl%kTPoH2xGGG!Cn$dFubf
z<%Pt=;B@QbT`m=Vip8H~K{{u^#Vkz{L2vj@Avl?IBQrZGI<X;&L?ch4gN2)hLt)q+
ziMz%og9+8sk8wY>8H1UI)>%43>-Tg^@N(rHw;h}rYg>0%n|NP<nqYO}^4a2&?Fl=d
zEV=C#)(QA`?ngYI+Jf7>@^983RXJH?>&_+^=sR^zus?D6obtp9r6unz;8t;0bM@%0
zb1$B265Nt%W77M*^IOPbi;`Ehcfa)AxCnxV_gi-=H2o;SE(?IPKub@d(0B#)nsE83
z^HLqrf*~#F(h(+FaN<O)zguf|yjOlLL^-J7HnsAQ*hEReD8=PH*le0Y*YK7)-h7;P
zT8<qFTexjF8_79mORwxL@FsM&_KZ*U5`Z%M6qgT(8&)c46=*S!n~YQ74)i_d?}ct#
zDDE-yZF=d0HeW&on3fhK*Fr9#XWftYA3AsLf%{jl+@C${>g&pSW)0iCtt_o`#-jAA
z;|gLjyRS}NAD`>IOK;Kxzx;atL;u^f;kF0IEL%0|fk(!!-c<4LUB$)Q2H+SMJtwXG
z^5$cQ!8Y!8?%}r8_bm2UOCW4{j}45ZsPAAuw;@7?m=8}=b!(`Q{M*q{^|&SPn0VBU
zjjkwp<dlt*gPt3fj5rJXjkj@k;tcm|ZKv<ie=DYcM{R+7;Ow07a4v*@*?eX|gJ*=t
zYaN~=9!!B4>csOyU)%c1D_LygtPy^vNcFuw=sYFP_Fn0##+Qgodh>bU0<K9hPKs_$
zkGG36z8lPkRX@l>TH~*BcwAi?-4Kr-JSBNEt$;Lg(&jOg`k!<|pXB~FH9qMfvP3Xv
zd)>0h?g{h0g|QOuGDbSwPv$XT{ZVmm=!q!ikz+PLS4+Q>EG`$bVanJv@MN5+a7E)|
zM%LmlsT7xS%GpkFp{cI<ENr^MErNnmj`pSfmb%ZyU3;U;S{|QbbJt_nt=2eS`K2Ni
zCxwG>swEtKox5V5y%xRLGteWw4-!^Cbe}0h|D;jeSoBb;#-7KSsJ+g^zQ-k~zplbb
zu?^_vb`5&^)}yo1KD>s!o!ieHM9;2=xyNu_dWL%*oqms_*Y64LJ?;aXq5TK<1@;%6
z<<4>c;eO@*<Qky|q+#G#Z^(fH=nthZ1j=DFjDv|V1!`ax%z;Z_G3<q#;dZzS4!|LJ
z2oA#$cm`g8m*G|T8@vPW!G~}fK10vrGw>~Z4?n@L@CW<_dIBVaWRbokj}(z&GMEe_
zBgq&to=hZ@$#gP{%q5qS#pH6bl3YR7lTGAWvW?V}-DDrRmE1}0A@`97$)n^6@-)3R
z&M(YOQYN7>XntWD`<_&YGsJis{{sJXfuzEG{28MH3+1N!=wovM@5Dd(^b7k#pT#z3
z^(?%PZixO79x8sv=hElkhNVx-ZNAUW(_DC#<Q<w{&H8DK{?d}DJA4w2n9HXfl)1E1
zGME0COaCGUf240(@}}4aQQ>{UUZEcV|A?O;m+p}y(;hJWh43-(enyurzM{o*#m^vq
zx7c&$&C^5W_-T?|V1AaXZz`(!lhWrp*~8||OWu^lDbRfW(6>zgMA7raYVV0>A>H5f
zw(uPvr2JC1pi@enx~^2Gn~dL<m8<Jw)Y;FcgjP&0eo?FLU!|@K4GMy&jPTLZ%kp$9
ziE%wX4DMK})EP(9TkjRCCx@z23}@3iRZJ~?+58kzLGtp{74s_$<@hjS(CPH&@CKhf
zH&U0Qu28G>*9p(4RM!P3sEZT|{;9B%lH`iZtDC;S2g;`FbWQd2M*TGP%5-&Ecz9Dr
zMwg1|gO80>*D2%G1u~gDQ8jX8cDb%Drm+qmDSuX{Ys{uM&Q-=ONQf(x%g?{lE25%y
zi2Uw{WO-TL__&@~vO5)1CnY8i9xcCDmY$;GRXtK=w<yLAPfV_?K7V%wK3T2KBSf)1
zQCTseU-4@7t_Rf5gbq{Bj8bR)wInO5V&<?7&xAhEb=PX>r=FlxCn^@R4_YU$Fnr|F
ztH8V=>e>i(uk-iH3kwrQFQ}C3@jW*V)#>C1=?(lix@`4Gl}g@OR!|UMQKuYxQg}vF
zcz9V^dd13VvfcQ=rh_`2Y$&~Px>|jCvbrQJjDJ*ohH<P*@8!F}>giq78Tz&Aii(_}
zy19{jSKOe1=yc>;dLyqwJ)i9lQmH5^N~ov{t~^z$p4v&BX84AkBk&tO%s5N8R0-G9
zTf0{hU0K}p@VJa$gBI6?R(0*K-7lOWk7vhJ)Rk|?2bJk`J@H%kf=)U`Y=dT_PB*4O
z+mNNxZJn&EQTIEPrR}s(J8E27dH1<GUC8e_ny96k%J`ky9WYC$GnQYcYJgkuM#!iI
zHJ!3ZRJJC3v1W|;aKpodlxnnBYHP?VI-NnaQ`<n^#*^=}wIMrei)(AO{6^skF?G7}
zDMN=U_2as9snBL_)h>`}@sxY8L9<g<fH#&bsjul<Ss5k!F-IG@R69;JQ#Y|kS(&`?
zm-zT8ntqA~jZThly|EadAU}XNpl)ML@{l1)#ne1a%rZ^Y`I{5wPRU4}Hb<-3u_aZO
zHD^UaeC0@OkMgkz-IraO%=g;7Ly=jltJap5lJk4hHNo>V!^iD<EaBvrJ0`BEQ57n;
z7HU;1G!ws!Jo%Vr*R8|n)dZ)Xzl?o4U0m%MryDo^y=qxaOr9cBsT`t7-l(Z-jKx#z
zMcg5c$#`R<PSH@)Z_1ST#?R#PGHnl?YGyKfg6u?8RHdeGy>>~H4$rVkd_vPMyb-lv
zYi(vlMHhX!_;?rI!$;$m)<)*=mua=N+TxI%+O_)Acy4`#`%I6&63BfuSJu$aZ#b${
z4%MXSV(K!+EUpR9CJ}fNEYOTH;*o$O4VvrN4c(6Toi&w9Yoc<DUx$R~BIlNC(=tab
ztnHL_q@PBu(@b8d(+$T{X+EAd8^aqoqz?b!7_5AP8oHyPn*teTo+&Z&OchkabhsQ=
z!WxWfxC%DIb+8>87}?wgcfvg;vUviYg6H5RMmBH5Nq8SVf=}R|jA{Oa^I#zOn~Q{y
z&Lon=k~k7iv}naEP)<JSM@mQ;DJP@JI8wzJXC|3LE+LD^QnG@qCRZZi>?F5$aGEK|
zPl{G0(NU0GMNBUJiZdYIgBPLQB8|QT+F_^VFcp$+-Z64W8P66J2=|F#BYqdQDv+W1
zSrCmQRP^)F*T&3)SpPy2$U~hlHU|4HQ_Qzi^cIz9OQE2nAj|08vTx;kl*&Ddf6I3(
z&!6`UP429%Tpbai*sWBiAIPW~I2`u12ZW3>9xu`<m1+CaKV4Y=m5*72Ke;)jyF6U+
zpyBO#c?oh=$gZTjyQ^f;UApeOxG`kY&br5+xaF>$+b>&l^~SBEcgde?HFc1qD@qDr
z*rD5Zly9i#Q+w;*Z)?VY1F!K1?mxJl-?=bZZFs_mI6*F-C7-+)uBepfEQDvLk@&Ll
zG5`gw7v6Y5amHds8mlFwu@gz-Cb$(zL(otj1xwO+7fvB*d<uU;BN$OPk((JqO%g~V
zNhaw`Nui8Em6YLR6f(vHWQ=LVk}=kitH>5|1GzOo8Es1$R%?8_5{96Kq_R*ofuyJ$
zl*%)d@>kmEh>Wq?k}=-(j4@u2uJ*8|Jpg0aCdK-ZA-!XRF)8NiprBi1%hpE8!!|2_
z_cd!A4<JS>g$>IE|H-!Ii!+)h7etf~oL>Kd>b`sL+p0PIQs2Fhv0k@EXPn_n*w|=|
z8GHSNF@m8pL_!S2F+C#{dYbf%0jB!QC>RS9U^40%GhjB%hlOw%EC)&(8{lfV2DUlT
zGS0#|_z%`-{)8s@AK{6Tgpw|(XT+eMkwAKoRMM05COM>#3?PHZP%;Abj7qH8Od&Or
zn$0S*sbdocEy|m(^1WDmkrX2AXbv`|3U`ozZkO^3Ed~kSZR!{)0$O0}mKEIixTXSm
zsZ_y;LIneTk2^?#WxxwJj<{N>)NbqX$lZ;^BaS%XHaHmP*};I1+^(A#x>3nRNfLYv
z5c1EK&572KAa%mbyqt?!o@hL`@3?|p;2)M<-D+Jzs9d;F>Ts~^*ST8-Idt&g_UjKF
zGEVRzFTj82ER$_FelIWXhkAs+^lvC26uKZS(CSA5B(ZLeY{-Qo7zl%4DC_2^gn6(4
zmYAv^SHecv0$ZUTcETRiByNZOaM0Y>@iaV-eI3WKuj4Iv7d}8v_znKcGzpOtqKJy9
zNq5vFL{2Cm{Yfbqf}Bu+oG`(P6IPNngytsUQqxiUH!%5$Rw8nv`5d~CdZ$MNaI08i
zNK~dK#m3~|*dG>E*yh`<%;64k_?Q?v3M4F$881;Nc8A^GIL;$NFr1MaXDF4hQ*res
z*}}yu=E!b_58S4PRy0*yX@@gj^f4`5)PNAWV(Xq6Tdq88yhnbf)qnuiD=B2GR1T<?
zFO`q2G1hlbVF6Q9{i7$M6XOCwMMyEL2+dudW1)(v2s6zp!VYADy>JWMflNT_6c58=
za1=x)c*ET5`6+fpoFN>MksziWM3b(p6M|MLdYQEY$^^6*f@%j-NiC_ve$NGD30X!~
zv3}31$u(pvRw|eSZO5ep99YNRPS)9p&729~%|=dpS^{lQD8$QW!HzSZ8gwE@m<%{2
zs(?+U!QMt4iwUeL!oh0_3Ix736(@X*3z(R$P<9k%Sa|??ejF2fn`}g%zFoV$Or~TG
zK7Ya^da$W47^{sx&8+G+e(cp_w{#l&%dBD1BStP7w<c~}(@);*%S^TNIuPb#hLAs_
z=@UHSVkU|6H>YhcS(*9ly0yh~di=TWX@#cMIAKd~fZfMby7&QoQU`|=)f|n`sf#j_
z3!?h*?|8A}(#~rb&iYb%_^|3w#;K0N6{t7Rx&-aBq;(0ZH*_N!tV_^7OInwpdV|<!
zDbyt_XGzvzpXEkmi)|fSb?7Ku;erklzzH@w(k_D_7aLB5wNygx3xGtMPj+1RAYrYC
zZ1X)q_)p!UE9-4YhIGh;K9CRnpcn?jFrd8+bXH?3)S@aur!}sWOl#~h&7s}{_nGEU
zEvGd;fRAxn<8$~wHhs#m-i9y|PDFhoiPbE!NiOSc5Nj6W$t2V#YEYk;XQfY2Kj{u!
zw{W5oc(0O?nnXuHOamJ|l&mMA9m^Ot2U7g2i?XAL5trGyct8K1M~Z~OD4RYN<hvAP
z>>?ST*&daQWfq;EZ~7P+E@suCafD4-KwjEv@qw>duACWk-?CkMHeD4vPq|#bvCV54
z)*~dw**?St|KWrX>~4rMbvFoJ6|}pd(A3>9!sJyU^gu3yRd5BYH}yc?0K2f3aWmF3
z?uL8eep4-j`c}LGufZEYr#nA1yH%XWsf*^x&KOqDNR&)=QpG{2W{hQ17t<}KF4lBx
zPEf>zV=E-p_F2G}H+vicWMJ~j=<o&;k&53lvx1Wo$8?WYHa_bS4H)}KXn-`f2Mt_f
zK?6qvG|*<I5c<e{r;J~Ou8hb{sX9~7e;j~-)|xx`OOIn)YXx-TlHkN;u*ubdPF&Jz
zLpsSs?<#TPau`lrifjK23s(m^ak-gX-?15>V`v3v7tCz9r~{YDgNs^l6<8}4J}x)}
z)B=zAzz1r<MpE9lZ){ux>6w)^m>d9g#(=OMIr2`OU`T)!+Kd%02IYXS>HGBBwFBm)
zUa@xVlR3%LSN%AA!L3o5Q}ye8DIoZZUxRD2lrx#nr7%aSgS9wEN&TU=;f%yC*vDKO
zsD|(WJOYoylkhCOh#JCi)DTW!rQsX+4t{{2(eaYHLs933U=qgq7Mgn^1&$E976gu{
zBGu^JFoVn{^T|SVheBtl4$cp4G)+mzB&5R^?N(N>X+z~-MFopF%4RR9jzSM}B@>nB
zKlO|lHi&~4q;Gr338Ssdrq22r5_rilWz%ye8>oxA=-`#9N|<CGy=eP+i5AvUCw)i=
zl5xsUnd=khH~o!~pn`5VP1yse_kvJwpxz5ZVFXk_CG%dWflJXB`*K*pd=~^iNjg2T
zhw*~ol>H!Bx;(vwyl@IT6hwz?4{Ht`-G2eA4mibt&hykp(iAR(KX|kH5I_go{lexk
ztZc2DJtR8{EfmX*f8JD*E8nY(Oqf{RJwnk~A3z2VjH%(p4nPU|$me$$U#J~(SN)Su
zT|YOwVszG}ci!beO`_xSg2@|_dO`Y0U4r``@SuPY=GH`sfjUoTL0^`nQ37Sy%{Wrh
z%~)r0VOS12>{6gE4A(g6P53+fgJo(6eofSep~;3fWD-fkIz=DM*eE0eO@2+(he7ab
zsw0a!w5~vB6&?C5Sb7|>Zcn!6S>-#J<`Q#h?t}CBN1J1l%r2n|YjZ?Q5v`$B*5=SI
zdNWzQ2_F|6Ivfrhcd+&wUJ@LRMmi6)usJE|FsQ<~_Lc$h$%9j5JC(}R+tbdhA5awj
zqaZoB5ngf9$9e%Du`08>ELpbuVwMQv?6n?zBl;P2bCyA2YYNg~z{Hs&+H?Y&S24e*
z+t>7sS<%C|*iE~oG#|<WL^n-7a2@fNH6Fqs0-YGULOf_8*|fgXX$88z565YRF)$vd
z6<R;1AowrRJPC2mk*?=Gnb)&8=O}tT3;v69%$ZrjoZ}X9J*n@|YdlK)wC@lt0SgOQ
z-hww>mYnuAv|~ZRk!gc}RTesmC=ecMygu~gm1)_beJW4Bzp(LX2Uy^o1`IdbnSOxV
z+oPy3+s><>@-Zx2%#6?&vV6g=rxyjy3w!DKE%LAJ5rfmPDtopC-?#PPg1r~^rC);o
zXaqR9&<!-EN<wcoxgfYW3zdY4%ztSX_8V-1YndnGF1V5TFVP9d2iVMl*l+L}yvgbZ
zG>__Y_=06^p2J>)P9%cOH&RDNF^P(50it)apaoF>C85_~30Y2bWG&fX%G<mF^EPkl
z*!&QUO?_#}NDzf=fT0;A62ObqgaApHGPt4w`I#;AGdtBU-izYU>9CSMLzn0G4N0H>
z(!$a)jeP<@5y-@JClj-A)~1n#!8MWfi>E}y^&K8ExAWGyX`O21<pH$tPU5Bi^eMPD
z7eTujH({-TIz9_@LDMdUiAbTFQJ9EqrVFv^;H@mGT^*b*99_11kuQ|AgA&^zPy=CR
zj!Nu`z>!S)3hk&-ShR8amndP;?$}WjiW)l?_2>W3GqN}xGJ4Ry8M9yC*MC4{|DtJq
zdoP<&3ir2%OtD1Lw)wh`r3v`Er0?;f)+xO1u>iBKh^(5t_r@2yToE;(pk~He<L<WB
zDoDOL3B!=#!y<>I_mTE9_={h(6005I=(a$688le!5WJc4%-&2?vl!2kB$k;f9yCef
zdd3wr-SRe;ByqpVnW@<|`fW^-cppx))T!TC!ew*nR1{0m?k-84DnR9;l%-BpV8W$!
z>eNbfj^5m{d4h#9DbosR*P|El!9hD^JK_U_7|{tzi0<|`h@jC^G(5Y55QOaK9SVL_
z!lOgvja8l@!>`sIl<;1A@Pfb1N_2?E$MZLTK68APw(y$gw``K{Yqj>k*VyQvY<o8*
zznYXVcRu<HC%D!VK{F|7r=#G<MAe7gI2&;b%bOBrDQUKZ=*L9WhxagV>NNH|{tUmP
ze<SsPruh=0e`7c1%8-Wn5~6=2&88el#*p#md<m(4<A#pz$k3Ku5dm08!Y)y<2h*-M
zQ-^DdlrOSsh^Pr5Luke1V)(629hjAnZ`A1;iyJgM<p=Nv)NQOu9x_C!n3|`FS*EG-
zRx3n+8NwUP%-|=p64*i69TLr&g7^KN1AUY+LYy-lAFvvFpm#Z$4`4%n&J&s(PEwdu
z0=6kOCm~%TrSlVjQBywjdv^RW{Y!1=AR2=_(@vG5F~T!`I4m)G<kz)_+A!SCC;7q0
zm5M-dLNk2auE!Eiez{}f3a9Oq?QZ}b=%eJ`<W6w!aUXD}xqon9a9?p}xpUlqxL>(H
zxkjAApb6KMA?TE4Z^$uCSq@<d*W*}b#B`uOPJ$OS)gEp@#er5O?qm+of*XU-O?eDn
zXZhCe!$&};EWZroMHG60AFwikA=IosfyIejYRrJK4&JL#h}YX@n8;_oi*#rc9CSb6
z8?ZT$>2PzDri8``VaHI2VpQYkl_Z4{C%|Rioa9Xi5QeWxKTs}x`Q~?yKSTxECR?^m
zmRtBLpEr1f3wEb5Wr?=B9p1%j`bJ${j4oR}Ql*l2mK7AlSJWxTwj%br)YkTk1IW;3
z&X4DBwhmm7KiBFih21I5rY+Vz4o_j$=|-KRp{C!IDe;Y;$>n9*9y--bVGFVoQBjqe
zzV+HAO*)-UR*A8eO}p?$)Pk+GnH3dX^yT8?TQ*NL_^_V=dl+{6N9MJ}lY!<*(Fsi<
zPfB2eOMrSj3Z6~E%*8gBDB-`*$h;jDgidNkkQgF(M5p4UW^eR}&Lc&nm<%SvO!Wxr
z?KqQpL{o3a6=XFLJfg27+eri2+oAgxti%bn=<yb|$`(K5#;Rgfg2%G?CS4ly@sA)!
zuys<fDRL+~NLE^5^_9|tbgg9zu&o8!&eMeU%A`DWgf^Q)<Bgc4yi$nFH^1xL=%`q9
zqcFouODBl{GqguSWee+u2~g52Gb(l)Xw+&=NGN^{4c!jKJ$pr|4nRzD-w;h)Tv*s%
zP$d^A^RfVXtXA)OK>bYUF!fC5Go5ysLVnOAeBeX&1&2U%Ww-7tN&d(f2n*R3rb>DZ
za*BdO1{J~a6ovl3VPX8EW+(~3M4Q2cwb29lwdjepYx6JZGkZ)$&7cwUtE-bo7UDg5
z3o<6G_^$kt>gtS1Y13AGUw-JOsrr{)7A5RrMq_g8sY3t5)O#Kqwcw*6t5Wx#SX%Mu
zfhpm&&w{FW+^&Nq10K9-_+`eK<>a6QJ$&g7!EyfLE8PhqQIUu<DH1)+ibN?0iUg&O
z$;=^gC9H;Z<_yc7m`QaLbCf;+hp<!9(jk&|N}fVZ;#2QsV0UoZfVND*wrTM!$_D0j
z-m92lEk?LARO(~A0E$N)&t=;CdDw<qtlXdBw)UuO#M-HBK)jF9LjH`VPw)ui;~l_H
z^8C$S%f)Wd<M@7Ck6-v>i32{YI+Sth4wD0Q$Ki{g;8&c)potaDsh6=Nj>HqK*+qgT
zUzLzDQcgzWBt{jPOe|9`S7U0$)nt2zRx>VkzQFVhG^<R+j*ZxuoWht?tnXM)lm@UO
zQkSEyP^<OVrFE*9TKaN(h#2yV1}n63;|!$|b}FvkBwM(6#T?nqusZ-08?!axi#20n
z>U85%h7MJ>nRIbs14Z>p>T|hLIiOm;R6e%GxXp(}5KEHqmst(h`Yvg=#9GOuhLC!7
z2b<><Qm-s0HBMo2_G$PGU8sb_D>|h?t0HkkaG^?PQyR1?B05sjDGed<s*WXIU1s4z
zwVmA7u_?moWxSU<FVX2rFo~c}nX1@;R$({ZA}tl?Jk7Zx9i<O*nw@L>^Iv(?SYi03
zdV2k}lO{~2U#nn9d&m_Lc0LLu`j{?cT{HSrjmb*ynO#-UJ3Y{s=}uoJ>De&nk{Q#l
zYnXHC%;|<+9a6FQy}G1)MCo|;)o*;VWe^OV&^;oWd1VV-nk}<1gx<_$u*y6aO8YN%
zVNK-b7FigSFaCutm*2p@F<<i+manNN9Lv|Fo|lw1;)#YNv7Bz2e?e)3_F&MQ?kX}#
zlCLS!##J4gGQ`eIFSca5*bPZLCn#(Pt(x?^`z@JH8A+rWs~U+_--nOoiVi{&vJ)%=
zqj8N#++fVI)fYM5d-y=^v_}c|VRuH;>1y@m$?B3oA4PkK5vE`a`9rPl#cbIb={;L1
zL((yoE`C6t)WIP|HAf?K>Y|L~f~bDR&Nh2AecCADFLR%+aRE)zbiGd^zy-omDjiQ?
zZIo86m2}Z{vf2qF2W`OxPFHKmtb{k{fWd`h2h0E$;F?AZI-UL;-r%$6`k-#%B`)Y}
zZ`n@u9vjGp;$AW?vOyq*Cj(qiTdU>UuSnqqF4%2z?KXHfAfp9+khfaQZupc7{BKS}
zNZZyx5~M*U^s&g*ng%mK%*~{#0rj%J+T=O;5FCah@Dw};FTtzuH+UOPqJPxKEFI(j
zP&N1tRfC_IY9Q1og0V)?1yi=VvL1(IrW*7m`J_MVaS&Alp++GjWi0K`YJn9@Fj7$A
zD(iUg!Ub=KmU9oTuK$jm8^p_h`;C`uP$NJAzNdf|BN)XFMk?g1B_<B~4gJ&;l<Gvq
zVv?7quBek&xIbWFc*7n&EE4G90t(W+n9B#&V-@!88}yOOl{16xTefS@rmJG-DVOsT
zhtI1CPCtJcA*C9vF0R(?(FuFKiUKaUKB(!_#omv+rG-^K!IXrRZBD`(3PKXr1e}(r
zVe5PAvMOjc_WxKfV<=nYRiqo%270hw#@-}{h*_Gnmr=;Zo=#?wxmH=4*N_`K^qTKT
z&G%LZg0nP?w$KHnN(qGx!N|d?8N$Dup8&^6J7NdITpQQhjY%F=5ezTcTkmyVRtszu
z42*}Qy${=c+<ZX7J52LItd;kI{A}xs3hg2u*zkF<>~~1_WqYGV+kwCI9Z38htaXHH
z5Y+?f`LJBlbFh_pKHP{s2e&h4C?RL_sL2uPW1PPHCptoX1!tLp@H?Hw#J+=OFKQKY
zf1o+tq8ByoaumEDDzWc?W^LAyW-scsWJ`ypidHHKt{EzzB4I%ctydSU`UIFLAs~Wf
z9)(bR5&IczqJ`C_oD^ZqL?U^bP?#}wOnB%8)!|&I-IEtSb7rK_nCiLaVC@M-&RWlK
zK7_JN(?P5x)3SptkT~gUbQsnF1}t6I9M0eD+&Dr0pr<;7wK0^j=Zca77<TCP9pxM9
z`PAO}KO7rH`BHxnO{o3Fv%xhDLg-Gs5`=849k7!na^DVj!2!6RC2}8u=4`8XSZW1j
zhJSghN0DqLH*{!TXb%;_M$VM;`hgc+BvV@YQuv$xAm&`jsc%CEX<L*}wIx6F_Dp{G
z)Ox9(-X5~ULkFPe$1$<D$wu_)+qK)vWJ>1XZ9XOlS+I#943AUChKsp&(db3>q5Yj2
z&RDuk7~k-r@L-~dJnGZHaW}Q0&*YQbv)qf^G46HlEp(zj#eKwm%Kel3k~vZT!2Qhq
z&i%#dfdd|t5Xxp9grv-YFbIahNEn0Zn3I_5FdJQ{*RkB~>tH)Hu;i;-(TDmTxR0e{
zJ^|E+TIgGNi=|_J48NH?pLn7m!K4$3#AHl0o2L|9CWRVCF)9sW>Xo20&|ZZ_%w<w%
z;WD|0+(d38`^kgkDe}sN!V|P>kQxrq<j0t3B^ywb%nV2h`0N7NN?D*6(oU|mZ9Pr6
z*2V>y{zvU5g?>nSE0s4}SUc`}FkiacQVgP~bF-=HV1A%@pC}}V-`yLGaMEUJ-l$~H
z*?TKa_MEM!wT()l%0u*siB`pyLIF>2`)}N)@hRi+BArs1wm<#Th4qFEymXgM*Xf$-
z>5ckn>Xqs0vheVxjEpW7(+3|LtFBYVs|#c@d7^6M$n0|Tj&7{ON6MeYIHYWP<6LFj
zf`qt2x%~V)y&@`VhqO>K^s$>1>qmz4jt%B{xH>547TL13QSz|ON?C6QEfgRK81ieZ
zNaSqmn<%UW4cTsd|F}DTnpxFt{Mf6<Zs|1kms!K2M~qxFZcW@c{ZD=@Y{>i0%S(`}
zLUtwH-CZS%?$UMNB!5&oVCHK)wL9Q<E=*RFVm!+p#3(IU0p3`$q`szaWo4A?#~f|s
zQtdd^Ox?sDWo7clU*hAZX!<D{G}Lw4LH3rl?7`2_Jh>pEeBku@4^;Qvd*4>g;g|aE
zg^cyOHM*wfoETO%ePAh37>2dF3&UFdptjghX0wr#JZj%9+m|AUe14@oXCXX0jl`FY
zmjNh@T}87g-+M&-Mzb|IBTj8nCrhm<pQ|s3`COuZ_9U2!otTtr7Qhl%hMC_~7ukzx
zp420PI$1spG|kge7oi>zw3c$lR6U`c8PSsd%U<Z6okI#)-uDpZGDSNxgzCv$vVbfh
z%g8Fs`(BSOQ`d9=RU|P#(SB_~SZWmn*F}aWscB|oY5FAZbZ6Lt6MQv0p&k-2^P)21
zR+FcXndM?pMGVLEFY#si{SH|~zK*=F*dw1gi@%%X7X<|s<v`;^kCYMX)=k+0i!=|o
z72i+eQ1mwT%qm+tzG?Wc9YTQtJ{CtVY&C=r-3I3z5r#f8*?4Tw!X<N84!`ZL9z7N<
z%gk6dzbF53t9vq9v~>Puo#<iQil@$thy|YbV_T$d*l7bf>qB`2dpz&(vL<o|cMo?T
z_W<`W_ZWASdxm>~dxd)q)4ATkbgmD%Pq@!9o$CzhAi`{C1jI<_ArJaNG3p_-uX7?y
zfm-wYhTt(JWPsm+O30(8$qg}yOQ@kV`#l(#3KC%^hD?c@)M)1LFc}jzgmjIyWCPhu
zgmew6d)!LyAa|4dQ2Th4Jc0VhbL3@moV-a+kW=JC@(KBzd`Z40|0X|>pULm!FJkaF
zeFQLI8;zO@V{>x~sUDJIxx@?C;^M`<_+8qHU`yu!tMN$D-3U<vZ_?G=$#N<%NHlIH
zH9rp(8Ya(JlLuJ+y>s2fQN0J>m05VO*s|nRtO_Ue@m3sV6Hn}Ijt;q4w3L`OCwWDS
zr<z|*y8msyX_aIXR<Gh@&zm<VAvAA_FTMvEQmyzsGb=bbaZLAUrQr(CJTwjOtsJ+n
zcJ|x1j2#qFIiPlaLBAS}n(w?vMmD%4yYOeT6BD!PpQdVS!Z8+$e@8eck_(w*qnczm
zYcal}A86iO5AoJ%x9dZOAo01xyp<qZ!z_lA;sar)cuPOrfjDElRD9TO@kUX{B_-ou
z`%W3Z2wfSGn^JYA{x=WYIZ2m<@zr~8exb{iG0SJnC>bmpwRg;zBEue+<eH{yg|jnT
zHpq&f;7-%u7=Cpm(->A;HOG=6(s3Dnwz!oSO*f3|-1XWbr>wW}8{35C><kGKUtpZ+
z2LH5uAqNJT9(2U?{ZC(#*FG<E*KTefcMEqrx1T%6-EXF^=ed_L5%n{ci25z}9rvS<
zh>EHW0R?m2l4hfpVdmLr7zcEoW;)D*xo|0_kccz0yResqcD?S0gRGb3ajZi<1JA?D
z@EW`cC$N|0Lzah1eZhe_ZAoWlX~%0O5uLUMks)L_dTos(6U@%wmy*RM&4xOIQ_ZHH
z>>@XkTTDE50ac<*t(O8wNLO}b3#=1KT{LN-ih60bI(VHf>MbxTP>;eLYU+FyflhiH
z+8T+h2XOqn64mqtiY0bxPy9zWb<^~iX*S@zYf7(f`g-paq?-P+SCFc3LPv-}fr8ZI
z*)bJ$<=gStmFaXn@mu(UPCEHE^aiC4p?$`qL+EyYEJn$+cI!_~hZUPNNrFk|jGF7-
zofS5`H-9!zm9oxo^<`B`_L*QJI;j+`L=86y6{)u7nd96WOhcjx@2>I;Wf`g?)i9P3
zs!yw68`Ps~=suRCb~oG$f=Bt2Oi?<<Sms@L-{b}IC44Q(IEi8Pr$javOj(9zoQTP-
z6^v!3kQ(!3Fs(mPZD|v-%r<fZ*-iGLwsa@ChiOZPQB``&-;^UOmJn7+as8x(Vh3KB
zC#R%K#Fl_WH|9jBu=O-SsBn3l$GKp{)R{n|jY-u)QjKya8va5Bn?Gzo%uN(}+N95B
zg0rb0{#<}>mMY<TJOakuD~YZwZhClJ#;-w(>q4u#_Sfz&R!<I9r`YD3C!~CH#IO0L
zn=P1Wo0c2r^F;b=N1_foo&<Vtbi*684fA!nkd5IDHYuk)GTz?h-se7Mm9j6nZ&0)O
zf%^~lo2h$P20;)8T_6fn5RW}K)c33xtC)!$#A2__LQIX_1lO_-;yotXp&i5znw-y`
zg%?fEX9Dersj)m!Vop8vNT(gd353!P&8Zh%PzGZM@d!c_S;Sf8`9#dAUrVmCsHELS
z?ji@tqZb(EFxAGHfI=xkFaxs%EgrFsz0|Y-+O+I~7U<9<w{@gRXL8n#asrRELE~`K
z+bwd|WWNOnrj-OE`=4J!3vCM4Z?N0KYpnKqzwif^No-Bu20*2za%oLej`8b|5MAWl
za&21XsD-tivX1oAsCAmj3w2UZAzHB~xIJg3zvF(wTGAhkO914iT2c&4aM3~vWH3M0
zJSf7Bp24OGrz)t1MX(fBU=J{zY@*36!fZ56v!{-%&%g^<Poj>jbT(SZiNhQhiGxZM
z;}V+OlE%0sSJDGKigAgB3oBVc)?m`?M&y#~$qurU>?Jpo+i|k#Ai1ABLY}@5*@U8p
zC4PX*`iP`b<O!s>;^pcn{57Dzv|4}h>yai$g(Mte;uks-Mw(80Va~~sAuPG31<Dv2
z0~1aT1eXf{S6a+4={GpnL-=w}2b~;v%KmDJG-Ms~atSCbHo?W)wWA}f@AzfzRqk)x
z+uTV`s2Tl>`#+|qIO3Kp$bkaZg-n@c6pRJREYn~n%z;agT{gmIxDMx+T6(#hfaY9V
z>i+gU`~<(kpXLtaWD8y?A!Tf4N$h`_!93p<5;1E|=tvfL<t8()JWL)VN69nf1#*nM
z<8S2BY6hVkV%2hM%{MmcQm&Me<k37)rRC>EMW(4@t-7F@a^M_e%q_Fdhz0Ng%CzMC
zyre?bb&bn3jmgFKo&=zuj+LFne&iM(*k+Hh`L(T{b}^1^`#}%!E6&(Nzsa-4V%Mg&
z$&>HC6?WOlH^Y{I{(9^FVMk=+bWXdecm3kMT_E~&SV^Cu%k%q&q|bk8Vd)r|!tIXX
zi)en^ALzy<S{dm<zpzVv!KVfrUo^f}+$CrX420Z4o%tuM+Jo)m&aF=9Mz(X)$im>7
z$oj=oBI5cE51HF}>)f<XHBDje_61)AGu_Q{jo1BX+MavvV4k-E{TyX#%`tc#yML)#
z^AStW`GR@ho-@r~S?BChwTAlL(i&0)dg)IfRIQnbvsjmyd}ydzBXs}nkaYjvOCCVA
z=5gvqL;e;ZA4jdN3~bt!e3Zh7cT!qjWMQr%CMSS9v`|I6ostUE%-_+Pr`byv6iTGT
z0Q87fHEjqz#i137ZL&W?|KM*>q{-3(tP`$yP@i6KY3UT152wa2e&qRi<;3eRyKGi4
zjEcJT#l~McF6r=RN8Lnr;i!3lcUr|eZwGkCzj%iZVyC6%ho`6%N^y`qAn!Ql9qPmv
zP5lT0%+n6cQ@XzHvH|(9Fyyp4qiWKn{2u}8q13Zxao@z*nQ^KB_q3tZv#)OBxbkJN
zEn=GL`QA$!f9|;8L+)Lh{I?`6$NA2y?^lyYA2D_4L_#c3x4uN|(CG=iS+%P_l)@0x
zloYLUEr!csC9Fmd;;UG-Yddr6yNS(99RRBLyoJ-=r%ZYePDsJO;T)@Wc`HY;!QY6-
zM*Yd-s#R)IY)npJOezykigB)n&VUPbuonG2R<CbX7aX?)(~=aDO3MHu3s`A==8;=w
zdye-P{aco+XjSuaQsuMtG`4fZdSXXv33h#yi5!+)d%dD`_qC&C4N9f#ZkG*&9hINt
zTde$n8`pWBd}Mgep5xvcTLv|L9f9Nzm8KZ)6p@U7tyGSms#q%DwEn=>(k<JYhM}3T
z`~aRuP`9xrdB_l@VrrfyW|^kS+8fw@4XJ6NrSmU;ucz@x7efrQ7=y&MXK(K(m|XCG
z+}GS$?wlmKK*o{_uzrj^zTH5>W{)zV56~Xpfvm@uW+u*tdFb;?GZS@i1*}K+m}_7w
zPFxG#ebhbXUN{bKV8!Spe1IOmpJDdV8Tc0aWqyR8;dc<+V`yF?ok61YqwY9^M7w8t
zN!(+E6oV>OJ*p)%#X#CSvkBe&c9GjI4vMh5inm`YZ-67b#t~8e9ZBG%f0u+?t?`EJ
zHg4AqP=%9mXjzPDnCN@IA1Z3mrE9FTT=Jo;?K*M;cwuXHNM6lmhYXv=5u$eB40nB8
za-k3gm|TG?pb}G(rb_sN&NvH>E;q77fxFp^^CK)#;92HJ_l1csSU)Z_f)U;6n)#wD
ziDxs;86=DJMMsw+mM9?hr%WVMSRS*$7t4sw<mhs(+0o@Ta_@!68A*1H`KdVI{mEwZ
zy-QMb2T_Z_=2*cpIH@q8VYHM!I;@64zO*#)KkDsaW_`76`c#nbQjoEWWbz*-^b1HD
zb;en`i+Pf{g|q)OuMRNFKUuDv8Fb&WU3)fN6+2J4yfJ;AW_Up6*b%?eof+oKMF8<#
ztwcyOvgM1LVXl;vV5Owo<R?exfoP><jigc{%rxJ|(i#u3O3Axcm69LeKXfh#n&5wg
zrZt9Ou2B?Gk#2;}G^Y~EA)?nx8G7W7MqfEfAvM?~JC{(8+{?*I(@gUg^vK<FA<~Cw
z9>!J7um>xFdI?(c3B@8))Ip$LqE_p#OY2lIwe)504eOB4EU1Kh8z`8dahoBpLOoxt
z&O?LDN<~poLPcG0<*8Ej)K2O&!#63R6_bnMH|p<pG1Em0NyAQfqJD!lg&2AUN+!f`
zRH+=QNzujBWsF%|6P`^Xvb3ERXhs>)f(DK>Xs%;7bggBH_N<xw%KevXLSKFAg%Sdt
zfp%J`A%S&T2>f83i&%{w`!kUrwy;FR2H0bA*Qbeyf*Z=y=!WtNR!jZ{Z{vK;kMIlp
z0e^vB;)W89<Un28s2fVlM8vVorEMCSVXly@Agh@h$`-7USi7M-jPo_mUmP@n;}!Hj
zlZl(f59Z**f<p66tI=TERp4YHWf$mP?aD|jEWrOz7fDnSWy=woK$iv^r4bH|-LV?q
zH<!9k9sC1O(knA6b{lBaYE4Keehm%X4#hotMX3%zOmg24O<Y`9*j`X27bx?xK%d^;
zB^UkgGUKSA(g_PXE!#)nUgbA&^NoE1y&Y21{R^?T!}wRx6KmJzU(#pxn2MS~Bj#6E
zCyy+|d-4`!Ojz+<`6boW8I#hct@ytD&`nc+X}`h@<gZycVdFhHp(_^|U!7|*PC0*B
zt7D)qsxFZB?Imq3(=0W0j&6e+kZNuMK@XwcvyZ|PEa&+p)<^m_>j4q;5L%ZZOb_Xd
zeIGRGnf868kaSE9qIDV3X@7)75t+pl5t{TY)Mc(F&2<^kY5$=B(Fpb-ZAdgqD|oTW
zpKLJ?+<KT1<&G4`{=BBxM^PUVzY9`{pgP%V9d!ZxY(34J)tUgoG-jh{AU{_bw;&;|
zP%aM39CybFg{)}-Ec_jkgvh2u&*{Zvfnq#n$A?#69bQ(JUa@kTY&U)$ziv$R;W&)D
z{iuGzEc!pCjAHz|G}n<o=xN`oU~=-2T?bx%W>i$Arf<D=Ns|u4H!JN&9{MsR2<LtG
zv|GmEarB~Xo&G}IXjj8p*kGD<xq)@6-fF7gJcRj%QdXfk)BlA3gKywFrpNpaIP+rC
zV?wc#L%AiMXt7^4-G&}hiItqGte<2qSwJYatRh#C^(McQ8v>-#?xbRE%;pA}fHmdN
z5Txe3X^~XS_lXc9eh<Kix?+BXp&VC7VnE07b9jT#o*SvlQCE0S#PK^h#RiPDRz2Z=
zkwA?84wXvYSyoUGUs0zVYtxY}Kpo_5JhMJq8?v*uxVBcyZ_L(&FV>8?D5#@#%821X
zDXV}nzVS1;yiD6er<!TYTg`vr!t>hBmE1;d3%8Z4=XT<R?#<jC+})U+e29C9JIo#7
zp5|zF@^O=c?1$XnF?Enm#eB<s&z$dRw}^pNdwQ`M7}}#s=V(U&?NOzvgSAk{W?|?&
z?J714v(Z%R*@@2gx4<1Z3qxx?4_oCYn;g_|qL$Ws8qJzW46F3?z#b8r$J3YOVXvx~
zK1lO;nw`|dJf3xuJf6MePT%lFT47Q|QbcYVYxp$Hw@U3!ZIx1lt88(l6u(PXOnc9A
zMdfIfQ!RTzH~eDVLILUiFe?m9<G^t%RZ>BIURsV|CW~3oQP$8R?jP~HbU&H51{f<u
zr;Kx>dF$$ulYM61gam2W-nejwY?D_dmfVy5en}#X^&WW~bH6Sl-|EbB_WYCX2p=X3
zSjA$Jm#40%lUJN@+xWw{=#~NT$%9j5JC(}R+tbdhA5avocYD^>@S4nci9)eE>~{EW
zuzGqIb%uVex}qXysBUf~-xW#EKy*6tExpm!T_nV?Dzm#RS+={aWe(#nD-s77z9FOg
zCmNo>YjW?fhn<F!#$tQzBj;~+Zhf!l<)*c(2lbaTN3`h#Hm^Ex|H1A2?Q8nRtmt7}
z%uGRKCtTGrVA6`MduD98^04t9<F;{2Ya?^`%e2~BZE?s>?OOe5Je9t}-J!?J2y$P|
zl{MPZ(l%->(M^*NTt}#vndkhmio1f_;6whP$;S_yQ+H^e37yKNsXKp%e*m4Dp(@8u
z7dn5KSH=87Ig*G<nTE|BY@X9``zc-a#1+njEnc#v_ecI{fd}4DGwcxz-JKE-l8(n8
z7J7&Aw?6ljB(6dv`2ae3CVpI?2*ST1(t`eIwtA#zx`r{UCBQ&`A43StY$pgYsHEgE
zfOH#>xMF2uf5RS6^p6XVL7JX20|WnizbR8ZkU4De%YuuGK{j#MFb>(x?c;9YZs+!+
z4st*DF!vaD6q9rW9pp{!1os|G()kDX1@{&62BEpc!qg0p-XKEPD@`P}bOoWw#8eTP
z$`p~gaH+{*Yz=b<*@AgG)M4xqcpRQ&j`FXV^bqPW_IKtFLi2Q_4r4T<IF!&n5lc;^
z*<HSzxyuW4GeVchVyw2TBiH#x0})9A%L~rOYdryv#Qa3}m_@jdr-?FBk%4Z*@m#J%
z3$UdR2=|E}Tl{YE@y$<j(#v6i3Xb=Ud6QP}&TjxiMcqGQqE)e_;0H#i?)R$N;tRtu
z{Y!kAem`Ez%b#_5Fvj?*@pzF=sZ86S{^`PcSm!)U*b`C1@SL444Y<l}Y2&1iQ9`br
zmzN+{h3rbYySqvj-KFckwiY%lnZlz=iVc$BL$|>>Ja6m@8rBwK(C;;#i3vLwCaVp<
zJIM<6M7glrfnlt3Q^4?LBL>-6DbHC5&rT!pW#eT43a@Dw?sLOAjxvMLsX-@gyMY#x
zkr;YGHsmrNu|Y5tYbax2JoEXefmy7EvcxoLdnG3DQJ;@H;U4r6qd7E`8lGiyGOu9{
zjp$4I59TU%mdIHSO*r;t2tHydY`(S+X(k0Bhh`G?We8I;3nUqQn@s(rd&nIZIXB>X
zZ>a#7muzcbam9|Tt!gDU5{2dLo!bTrD++Lt9UQxwS`}aXhAb|`zEN8=(O8EZK^_qG
z0DikYqLBBuvLb8b+on<?D`^oJ47703sH=<7d9GFrwPSGlldm!3|1LZ~F&lIt--rdi
zU(8~Fp~_y_q)Bb*MJCgEzeLj1(=rwKe>xq$KSe{0X9@+B9aHJz2lPoD98y$sG(x8?
z%1ADV>SrwUrAnbS8G3j-+t-;!Vc)kj88RTt!mpGn6XRLFuRY&V${BPT_ff_f&tWg<
zt0q^E_d)Ch{hFy0KcgNINn#mih&>wA$D<$1yBkJE65697a)yw0w;ZQ&r9B#Z2+jJv
zk34pf(S}WCNHJF!oGhXyiNcPTxx@uEfE^~|Hd{J~uooFEq2HLPpk<Py@ZKoeuYwqr
zgjFw*n`m|&-ISvoy9?URR0I(6tQAWb%4ITnqRO?v-T;ZTtqlloFp&s+eW4<Waf>Bf
zd?j!EB|hGzRNerWc-0(4G(64qz2BHvLtz;$;K*0Kxq`Bcb&^sQL~sq+$<&bB;V$eX
z6;gSRu=(1T&D|UyFi!aw`m0m_(?8H(y?M?y66+_{{-^y(2^m7lamscqrqxX*)2-5Z
zH(g|G(mW075{6(GB{pLwqMNBXy@j<?dIv*XY?!d2WJn83ww8b4K2g;XzXv)+4QB<j
zFs-_OmAWo8C<qIOw0E)%CR0S(a0e|$x6mFMmwP007@oAz9dXp{E>ZW#O^iK7O$Rpn
zSlZwp^hq;@w+km!+OS_WX$-T}8sukMt!LQkfDk%36`4xq5KZz%O<iLwY8fwL?@42_
zmqZOeYx(q@FKKHyfo8BsYbIM*2Fp(7#z8Y!4oW=6o(D<`f5TKaI@cQD1Y8uEG{LTY
z>9w$AZ5J+w%@@$N)=|@icAIj7Wv#|phlJ;BV4q7`dY8Mfi);Z(+vpP)RawM-dxhNl
zobZWxx&C`w(t+{+Z1Bi7(@d+6IRV}daDpQ%^INTqE~HZ$_1=hmwLN`m3rBVeBdk7c
zv+(|Gi2MB&maNc;xsck<do732Fczv{GR%jCn5QBr3qoES_3he)GpaY^jOyK{K8wfT
zsJT1y4fG>DiE|?Vh95Aq?Kkwmkb06vVHHHp+{~#bX*Tv+6k!cyFrhV&3R4ZFmei4X
zCJzi9*-Yv?xT+wL6O!1NCKc!<++o(?-S5f-7FREJcgE5UOJ*<VQY;h$#P8nirLa-8
z@wXO=RP4!&jf$n=^eGobIl~=+VX`y{wrRa*+QKg{+&JQDrBb`C$0K*ckha7Ilk0_X
zv{m8etdEgF7Po9pw1xz!6K3Y+7!F>j^@=jr>l6A&%P3g><5ueoB!Ay=1?%iQY{+ao
zeh^TB9JMUT=ui5vTLS(&XPIof@q2l3zfVnt32)7pddd(XSeb}2d71YxcWM@5;;Yc9
zIU2?>w~HF|GN<YBi)>`Z3mp_sz*8V}P*6W}As6LSlap3+@~hafNi$JIC#_6Oex(ke
zC4?rTjKs=>ko+q3HSh2YA%wK1=I0fnQ-q4G^WFgnu^qt5$;y!?VA)<^ZuDRs26i@w
zTQ`Bo1y__vqXeO#V;vonAvRY}ufKNEgvs=4)%oW<VhEdt6~^@~MS><h>dXhd*M}Kq
z);sR@F+(U4Gx}7G$x82;T~*OL-7vW$h!9^k%(-O7^y?btTsm{QY-6hlLa?y1tV-CB
z3uI$1!a@c7UR_c?qI5j_`k~i-D%yu5W&xcKT?B$F=Q{Ker+p6FQIFWoe8lg<eoWCv
zT%d_#Y+Cf)07qC4YP7a;(PkXc-bD*@mBAjV_?r+B;0W(=gkiV1o|EqFAw;ZdNhrVi
z6-P8}4{(IbqoVCp$q<wX8-QZ;rNM-4khs~)Ufy?d2heNtLGBUmaqda(S?)#d8238&
z7P?HF;y&U&MX${-najiv5Dc9l0%CyHG3c~tI!<x)g*?-==r9nbI3~d~pi><4F^zQt
zY(iIwgRCR+Ff?~W()rN$-~%|#{H?x%Z-s6LLgzyT-)@?~+LP5R3Q2P(<T%y|IZcuT
zznmqGT!od3>sgN49&$5IZtN!q$^GPE@)$Wvo*^%iH^_(NpZ-?aVDpV)IUpulX{{6p
z%cgiSE`FC@lsj&WaGcB`bXJ)30Vl}fZqY*^7cpX<8fH?n%w|h&aQ4=`SQnv=8il9_
zV6$jy8j3RbUa)7h2NemZHe+kInt8=aA#u`|YU^oi&xvInuMK-h-7CP4DkbE!)JsCY
z$Sc9GhW?ur>qmz4jt%B{xH>547TL13QSz|ON<(iH9qhMaxD`}l^6QjeV_n7&{X3hM
z*?AZI+uorX<5PC#PxU`xw8T*Ss7<G<)t4u$OTxnVN6l{IzDApHYYz<L3E$UR45bod
z3X)!@8=o?Cs8T<!OP305=2q<jnO3K3dJqRtWf*VjN^&e1?K)79?;JIMT3cq=kE0iQ
zIGR4NEQT0{iE(TEn|9wq(>ia|XzUEHl1EXZY1)P7VAO)GwV4$aUG(LmQMoU>JmmAO
z%ruN$g@TQ@>orHvdFusqAb-{5K>h)D8Xd_0g%0H3aNjWp@;|u0I6ZS97YV5=#3Lc4
z;GC=Iz*P)`K_H|m%&8aVMs5Mx0ZQFJ9|37s$6Kr>L)||=hc7{xYW)xV#$2`p_l#tg
zGTVnaj}IWFWGE5bGpNtjbmpHS%(c>#*>z+iq51UnWEa^>ZXtJ&yUD%e0rCi@%sxq;
zB`=XT{f>;1=wfXSj>Q`>NqMCZnQsn?&5e%oHZGYaGQCDbu9}NBk9pdh&XsbL6^~Hh
z5ZS`?w%zJ5y%^ER_kE`1fHNy`{as!GBj(WI4gTTfPT%p@yH-0zB%2kZ#-Z+3hb~MI
z@`v16{RZcT<NQd^X~^-si;KwP(wm*}m}ZwVFtSx@a(e*g0)ro7GWFQ)Wi7~=r$<ZQ
zQ8qKn{SSEb5DNh{B!FwZDYULcIp``>h_1!Dl0!!i_#OU&CiowbksuOgQi-~e1k!_X
z5bbO&Bm>AG<RHP_LrixQJ6mbG+XjE592<2Z8!NgKX@)+-i7sJFB`O5#&@{H4b~GCW
zigya7NeQy}!AyAth31=9B_hW=ivF#w78fTw%GT4oDd6~?O}t|?>K1qye~?6_!A}$V
z6}PR!sPW%W(knA6b{lBaYE4Keehm%X4#hotMX3%zOmg24O<Y`9*j`X27bx?x;B!H~
zX$lXd#9pbbA+P9kZR;}X20V~or4ea{&hy-vfpHrP_?n_8)~?OJq|fY%F*Som%&)Fa
z9$AR@<SodUu;RP&ORB3gCZ$bV@qPKBo2KeFUO={^?VSHA^(Pk`MkyVLuH-6o8l{Yo
z3O$+AsF2o1okp8GPF9-8U^8<h7qU=3f={qk^e@app$_DMq<Y5-psgjJK7%cQX;_}2
z(;&1#H6q+p6Jf=WHmC_fbW#tY@KRVn`(d%prHBX@x?(M=JUH!QPu`$&GqjzSb$2T1
zHhKY1=yvn-aFemLc19aM3!~_V8UXYrdofk496xkxq><*QN%+eaADH*5l@R0PX#uQI
z*D2%G1=0zbGXn;#>=xEN>amBqb`Mjp96X?Di1!LSvh~6?n_r`8lS|q2hBKKOO|L9f
z_fg4FQG1h<4qQI+^}?)NdS^y#Oi6O**o|wGdW_YEM5(%^6t5bPm9L-euH+Gjhi$Wn
zwjb}>b?3C0?qN|!(PFavXk1wL=&Ad6@xObgXmfrH+uU8|7cm|&K6^Ay(aCBc*Cvd-
zqRGtE<V1zswqiwclHn!e*6uy>=v}>|gXW|zCpRV~D?*oDH*j7;j{#onlJ#ZHhTG+5
zdPQfP%cVr3vGP5qGr2-`>~!-q%~GITBKEXwhXzSLz0e8!IGfCU5sslVDeZ7+b|(D>
zCv+*bP#r^@(Cviv96FzyKoU(!vec!N_PWs7n$ZEZg5rV10K`V*YcQk*Lt!wef@vd%
zd3lyvXX0O&@3+Sn&5ONT<&);8Ia%xjj8HMP)CbZ-g|*mVte9;qFc!>)x7inX8-Hv%
zmlahpbJ&JwLLcaAE^>GhapJxsm#>3NF6`J6Hv|PM0Rg_SI1||Ez<*h&RjtrW{4(;S
zx%S{ea*43;yPmJ=)76>t<MmmZW=8YfsbWxp6R#7{H$zyXU7t{)>+&bqTR~m6zJniG
zx_is|LU;4J+*h(Lk21}?P7kcl&evxztjQ*=0<ZKjsjILcUyuUus-H;+f%Q5geDw6P
zJl#rST#pyaaK}=m&N!OhdaqbLIaHnE-?o~q>Ctp`Z8lz+->)Vlv`cqocueGmjG`e^
zr<G0Vlit+mjkJ)!lI=-5W$Tx0<<?d&&m{edD>e^S#&-z`3Xh83dYg9Ykg}=chmc0k
zb3c5#Y6q^V1J~3}3fs2I0qnk(*VKs-NfDS`8j%};`K4Z1ziE_3Gbp%mDel6voP26q
zFBZ_<Tk7s^mGfI(Q*SkVzRmDCN!~`1&wm}bmX2-EpdIv>25m!@PPcWku14MOP?omS
zLhYz=Y31GL>U1H$=V+pqYAWM*YIndaoz7T(ovHzD#Ty}`7SwdgB2n3z@Wq-j;=>IO
zvk?G)E6!V8OY?J0=YZjJ{<c=H(Fg_}hj96HF~(ZEzxY$j*t}*qL<5~hNMzFpbY8On
z`a=nnv1x>{Zg@^Mr-6TnbDN*R7eLd%sY^BWouu7)Gz~n2H0#<z`j+TBISA7%nx_<M
zh>!-pgskq+SJIF~CqQ%2w1^gvz2g&Q&t`$Xf<?_;tc{D`-CU~^nL%c5G>^d>=1utj
zy6sOBlkK94%bwVyRPIqW?)JzK%Gjr+vjX(<((q$}XcA$-aXP=9c9f-b0PBYHHy=89
zaQpR#4#^*Cwf&PVCk3wrRY?3Gc<|4`L}Id^zOXnz@N5v$Dg*~=>fLY+dOqzy2kIMf
zLQ$x0zW@OaaHmbqh1#!hP1*(=;3c0YM>t_FuZ!!y_+224=1ea?Y{w6908wmDRJORH
z|7(fEt9WCcxK_iuR;~WVWi~+KwFq^u3#bR5^be50mpdk|s8JO<mgFT1wy`x)6lafU
z(+O-|#oVZGU(+{cMGs?kOx}f2Q5R8w+v6X7Z{V6Huoy1KUbofQ>vokB59xQ!J#Jqz
zHGrm2{7%&X!bxWJRIJM_NiwT95NGv-B<@O<#4SysSVh(b6ag<Q0?ca4feVs%bph)P
zjqD3b9_S!bdfpKQ4By&uErPMFVuKbGVC*B!#rVUI#es{ti_ROG0PH@d(!~$xlR7x0
zsOD&dPF<9dToBdI@Vz(8i})JL@QdI5QyakY0OxIgqE^oAyT}5yPzUqS30hzRI<bE>
zQw3=MJI$pM60d2l#9`+Dd;(5k9+fxi18d2a01tSb2e6MWP4u3Obv|70b`jr}1*B;Z
z??R{$&{4yV8bu}hSSS}P^{iY_Bgvrp#5*uR=j6yiD~m?h@2B2~vMtgGs#|?;ix|_^
z)<53Bgtp0^G7hu!Rn$|G^e;n08_`of)D6Dle&l}P{@~7|vmxh@6{bK9&hFF1Dc5xa
z+I>%*4e3<ePw=a$e}E7L2_;<!O`Ph6xs^Rg3dtb7N%LG>IT=kViQsZ5^bag1my?xb
z4Y?9s4zK9|oFFL^*pk{=Ey2oIh~3w+)6crQ&rOZM!MuKRGk{yzaPim?UQ`kS>A`S-
zzY|BMv*|$oxyrZ&32}vT`T2KxMO4%dajS`6ey1J5ps~)Sar{>J3Epn!6%9cFH9@D-
zf3`McXKit9t(M;?G#+{h6Z9KQeFTPX=(H?9fTs`CZLCQiGDNAEnx~0brm1q#Di8<p
z&i`doJdk&GWzhabH^=8MFf%}(_8bcSe?}l6XZ?nem{4gu=bGvW3m7A;f-7J>Y-EX2
zJ76d32)AIq^?o=2hu~r6g#0u-4==-U$%LM?sz4b*%!x=Q>6mRz8G$+gmST^g$Ouze
zO2k}Kwl#GCTu-hh*Ps*f4P;M8AcfSlB=px~Ryc*Z31BbnAb<?aA;8DO1VH_+FDh=}
z<p-eW$1$<D$wu_)+qK)vWJ=~>@^k<q>I?)`jBk;o40#pm`D%3@A*51KRFqIr7hHL&
zR6VtmI?eD+N@&I8V)zXoW}Ky4s)Xz5t=%h$t}JePcwEM>L5u4`tGf2r?ic1fAJ2}d
zs4L%&4=U5?dg8b61)X&KBbq+JBQE^HgnmQX_L7yE&#qfrJg3K>>z+0=1c;*M${KBH
zDKQ*XDu-%PbTM@qV;0whXOjpVHd&w<WyE9)IMSfGj@{7hh~HULxwIxK$M|(fh%Rz&
zxi&3x)WX_MSx5S5)H==Ng*x4E99fx<<0%`%8)VN`9m+W6(^`eK{vfyt_l6uczfcN8
zfO_<ZiPxh3AoMG2V=0yU;8wVkF~x(ddr?fOd>v@Mg6Pd7_AQ9h3!TmC1MOGnNwSFL
z^gm6YnnLLG!W?obk*W_{FoCL`?CuC;(LAzXSA%e_CU|Go0Wi!dHYTSqCN)XSoAUOU
zgRReKo-L%!kye;Rr54GUMF1>1dDs5OsURUAZ|92t{0|<LGz_Pty$GbqdqoYq6A#9h
zT0+!nA7?(nyB7;pI29=D$qo&zo{ZqbEE^T{r@YbrAgi?B@37mFoxU5lv^Fw_zf7yG
z)fR{B)UMT^MjZVLfl6<{8~3#(SHNZySM2jyKcux@(F^)uf~DX>JcM})3BG?q--D=E
z&?$(Wu*Z~qE$S3UfHDQuDc*p$;Uvqm{ET@Ne~Z3Cv={OZQ(ghBXv7mOp=w1Y>4SL%
z)ag%DD@3NKBQ&pIF<C~WY6Z=0+DC39`#S<zv{+1Sw+=GRB7hiZZR|JNMMoDf0?^S8
zQik!Biv>L_7iIf`Mu0%tK-tj0-A)|xGIyMNgL{WN$<frve{f%LXUwUQe{zjn%esl+
z%^+wS)Z38uR?tbzYhf$Yn;eJlfV)kpk&iP1d6CUzzQsHZ1wDg$4U4V}gvd!S=}aQg
zZJ4G<3a$)7S4BV4Jc%)$O=8R-vx$%$xtwK3(q!%H$ac~|_K=$}S^IAC=mo|hHm=ZH
zHX_<8g19=mY29w&B;A^(FgVLua*j3<fx*^jC4KM0rxd^2_I3c8t<c;E>RdXx0Gc;x
zB?a;%9i0AMRx#e$@)BSFD=PT1`f2Kw>FToZ@TQE6E)~-U9~<kTd6RyIy%6g^tgVtQ
zhd||r?I<dZm7aHP7`sS1MIlL0RW6`eP}%<|lo;1ax;_1~<Z{#!I`}Hr!mr(MYvgCx
z4XM@#TRBEq&W+mR9FH43;G2EN6>NI+u;I!JD78tb!RUXQvrM+#_`STiAC_adw$)8&
z&h;zYYuuYiEbnn2a-VRYGh+FcJIDQp6SJHMOM2`AQP}B0^B$Ysn5l9y6>3d$qu0VV
zoDrd#39ZB2142f^5qKIk6Pl6mH*{hC6#i-I0~IDm(a8~gq?-FcX+DC6G*6Bekbb0?
z<s+DVn8{2smsMhxn)^U$C1wZN$<nSLAWvOLydsQE(6A$u#j$z$mMpy9gcSw~rVvKV
zfKmzlrSw)RpR4GO?qLB~p&pi!><B@8!rel(saz9FnmS$a-YBZc;4`Et6ltbrTS|WP
zw(uPv1Q>LVqb6worD73Q7YMiTU8|?pUpr~SWcsxVhTuX{-zLO@<`nwwcA!O;<{(Kj
zKr9aWLgZ^Q`c#d{O7EFnRna@$Q0LF&V)$FboJ(d*zpi1<r8B1+YOzis!`6nTB}?jS
z`c_s($$reyMlRKkQ_a*(>`_)GZ~P@beu}1_qCul`gIf?y9H2|nbGsf(IBC=FB7iN{
zts|dRmz0kv9nZcR5+w9;mzQfkw{UlI_i*=e_j3<(k8wvikzT0Y@*Zj}KMT_<ESowA
z!XVs~I@udNF!Q0GDd9;-j}Yftsm8Jk_L<d{qwox}3hfu6SrPwcH60<t2~brD!f6#+
z(aACq$rvJND59IiVzQL1z}XZ*JGqtINe+-h<RNmH93fAW=g5oX82KA{o17#ckkjNd
z@&);d{G0qhekQ+>zlfgaco`qWhw<TjG~bo)&ZqG?e4)S546c7B8%QPEKw4N>Qns)m
zL|BuI)fQNDiL|T3)@Ci6DscIv$&YMEHa7=vm=@)huaugk$j7x-c*{MMOe3*wL=p5G
z3lzdFJ4K-uQi=sM2>XJr_@*>V<hxk<Hm&3-N?z=KQ)$P>{*w;XIC!sg-_zH_<3o2%
zi#=+gAc>eMeiu4etn9l|a7(PqM%dN4bcdUEi)3S#hXy|({gm|Yt+v)?L`6q;DNRv-
zFFZ47GH8^4bl1XD<WruXq!?#-vr=6boS-gJDEOzsN=lL|F0XF-f)dnpdnkp<?I-lP
zV_^#aPnql^e%L_LXTac|WRkwbkuIbk$8X<8s$~NQ^2S_zg%;yG{3g<;C-9SaNGT-x
zSFJl_nu;s<(%3YRjgiTwkfP`mkdKwgW%kfZzPoNruR$_d^oZ~&lNzgSBx>pZRWowf
zl$w#lCzEQ_dW`qZfXF$KFrB2vW(31x60K5cpcail&fhC9EKC@^pi-{K_icOd$I#Wr
zyW@Kl#8=cQ#~Qx1+EcLEZE?xidlI>Xua?QG`Ag|OQu?_0M!tM*Xb{N4LTU^r$0enY
zONxm)5gJW2K2)3x_YNOgnLVOp%A;hYn-j*(Pc<eDuN^n0a=0upo*&A0>n%%j0Ccj^
zm-oB>!5JejEncv2VkJzmF<PX5bC|3sWI~_GBS(}5XUm518mpEaS!v{S&7iVv6Q)iX
z7G0fCTzYMJ(ZIr{Znjacaom{sJbi;?x_p_9U@(5gs7q%JAGM%PpH#K%r-T9hwB2SE
zERKunI-sOvl5tl|o+4AJ9HL3ysHtm=#duiTBT3{fTklE#Wtp~zPBjy<Eq9UeF*oI`
z?@C7{&znDdbk&f4`Q?QZQl}ap^JO#8ytz=eg^;0_l%`#hm|z^JDOF5Cjq6S?bK-s6
zL)>BR3GPYmS?)#d8238&7WXdqKKBvRw*+nLSH_C88mE8|lT$kF3o3$Q7!1`+)v9Av
zIO=;M^a1UMgK$62D;<U-NQv*Dl4Xw(>9kS?>m<%2MXcgB)Z~OdfmD-es9-H8I<l6{
zCtXXn;e66=?D)Br+(Gt}gX9772zi`5NuEVsd=+`|9r7Oe5P9(*j2F+6bL2nBi~l7}
z$cv$TEZ>b!<@@>_B{GT04pT`0%vEGW60zx;PM_ZrK(NLoM1`x6f_lV6Q>i7@Y^l=B
zCYHjQZE`ZnKKME*Nzqto!V#<9kfw-9q5)<3xs>1N$W<;1Iuv~J@sIHN@CFl%7!)Iz
zN%bK!>@h&36}e(mhH?sXSYUcAr94TKv562R%;kg<g}v%s7-YfjR&SF+p71ek9|zOl
zw-*TZ0wlp0JlLu{dK0-Hp^%bb3j5jmuY6x71icNKF^qJd6(cCH$P77-z>p1dlP60u
z#>`zXE<H80Z(L1&uP{u~ttNbty%Fyn0#Ox=CWCrqm5?EZ7g4MiOk|DkP7V(1)~U;I
zC<qB2uLzC245AVU=@AQ;MG{zU4;XEQt~L!g7(RyQqkHy@S&`A7%&LW`*&!j*_~h80
z!LSHoQ{Yv%d#?>okbm<0M|?qr>8-<C?!#cD@V<Iw(DwyeAG09bkQJ#6Cc!WyVrU3-
zA;{-_!lL=^#;(@)`;ZRxCnBdO3>v&`!j!4Qq9!Ml47#?w-@pR$rkkXwKQU|cxN&1E
z$B>sDfFYeS*MA&7dCa)F;L)9CXAOj;F=?5JdV|fubHm8twPVLt4(AiQ;oNYy-e@9n
zes8*l7Ak+1{XMf>J1F+XwBubmXV?Bed)EOUMfG*(mFW}GJ0aO5n`KGw2_Yl|NPvWd
zUPJG_hc3N0=?X{_K}7`>6-7}|P((pR5V0Zl0`>yQ4&Qw<8xjJ7{67@XkRQp+?9R-6
zW!^h;-o59p_N!B`SQ5KtMdTdv&{tm>BVGX((n<YsZg#8WdZ;kY$E$2}VEv$aL0wY@
z`+0d~b#r`sy{_MAV{UGrp7kyotY=>*0z@xVw#V_|O@x2+cqsCTMm=rF%_GvWF}S|g
zvPGpM9Jlrc<G`!w<XwHO(~9b#a@MdD8iqze9{5Sl_;tn?u7vpYbr8RPAFOS%xb=Oo
zwps2E{yyZ%Ic?;bJ!|C0QJtPxEbqJNi4_h0;7PEqSzsvJw8x#DnQ_e6vax^*@2KK~
zwGrQEpu(L_RQMv^j}PKE@LTv8u!x`GukkPV!mWk?t9VJ7kffY$D*s!VC^D(T3jZVq
zh73qm1uk9=_b!1M=4CFfaGJo8p)>{no$OVmD;i(_E6DE3q}u-g_o}g-0UAB8Z`t%B
z$#*N`x$DpFgP-WxyiPVDp4Kq;4sFZkUlYJxM(5$@3TR}lS{jf<1(dc2#x4T!%}Lpe
zs>I$^@mksYRnQVWbv*#ivG!JjY$lYv>5z?{>8;9$imqMs)3+Q{yI$cR$HeA+2m>TQ
z-o{)5m0hO&Q}()NgUCn^H(=l{BE#hTdIk7o6{7BHPz;~A6cClZ^p~L->QoKJDgyqO
z^+pY6BF8<K!!T~m4aQ+Nj*shu2BM*8Bq~7@E@moN3_kL!ft9Nql~=Accn1A=F*^bC
zh7W)>6^o%U$fEp{0fW^uV)D!^g{^UWBhKISE*lOjxs0Q$><@pJ;SbNS*h3c?x(Y0I
z9DjnpyVX$GRn`m3c`AdZ`m6BlR^Z{T?M`25snIOhpHgA4j$D;{yOh*o=U<w$k&$|g
z>4X23S7s~S=t_&um3T7alEwutUg#R@rR<Drz}}0uuT*vu3On!g|8`uv61!GSq5Z!o
zw9M<mSbtQ3XpV)ISu=933PnbCwT1O#g7g1$F*U`xZ2A%oPcasR6YUt6TsKR0_?Dx^
zs_CyQ=`LP{{wn(GFly7K2n>H*nPDmouR?K^j%d=WXT7?;`{>>NbQRQG?ZjIelT>2?
zH!oX?C5;_v*U5F=%skMSkXx{(x%viUs2js&6{1!UVb~dUtEApM&hXx!X(%#oa;|Wi
z%1Qe`<=_yg95CgilTJ^#ioDOJZgb@b!>Y<j%?*CbRApp32Sbci&xr=2ntd_Ca4p{8
z^pe|&pSji0)9u7zU3v8qCjb9|qWY^YWS5}9|0*sjXQpmG7P_VBr_!xe;LCL~OjXej
zn)P4BI~APLO~g63CU-=Bx)hyU4?k1|*yvgRQ7B_lLmap624k2T#{*U7f6B8`m8(fV
z?^Jp$=YR}VCUnk-GbG@_Z|X=_jxkIHg~#^bmBqaH`{IFksG-NiR^g^&(>rS^L>Ar!
z-dUTR>u`_aC&8QldHfQ71-$v0ch<X?cxU~Bbs`h5TMf<p8@V9nO&=jL2Y>JnO8_5x
zZ!hr%`e9u$(BSG+&Yy5Xmj+E-{Spu}0JPMfr0-<Z)1Nz3-4aX@Lqy&_Vc?Ko%^8_F
zG;XBZ)g7IJHMdCIh7jKto?}zO(9hSyB2{s<>Toew0R2)0PhG_eznnNaSstRW^4g>k
zPFNBj;}#Q9H!9UV^p1GDX1B&RDRLYR52&wc<Pqw;=FKLP_`oFh8rT&zEE`qrRQ3OK
zs`{>L4G)}CH@9z(dbmy9KwrJ?U#6KZb)<59S=s;Jky!<qUB$!R=}Et?JYqp_cr8}R
zF|Dslo|~VKmw%0#(cP6iS06Wv6`hJIC~z&y<9YLfH<N3^9yS~rgYXZRcu#TM-8UGo
z-6+nfB2!r9s7o^o2+JaBs%q|adQlxQvWYUCh|@-<u-^c?IWUX9l(7qTcY4*c+#lJP
zdDZ9RA|pQ-Q|M+ZcY^@GU8-bd>OwH|cByZ@xpH?HpTMVYHKca?^G-JqmQ`c0|Bt_v
zCj>>BXsnu_x~hBBW&9Me{J(&fV|g{Sf|bWg*-0vRs~9K7s^+h%_&!zTugdiQ9YWy^
z)u8Dzho{dC?8I%n!C2|~xvgMiDt|UcO;K}Lmum-cF7pi4ah7GhLh<u4L-BJj=x6N*
zAM+2vqv==1W?>Ffr`EVPsC?EmRI_S3V+~nGG^R1me9OB*-VzpRI2F%?OlVA7yqwE=
z%wVzhLX6>l{3?Fk@Fsr`e+XVopW|=vSu@5Em@Gm>h%<C0p2Qbo4TDJ-sZA0|8fi$H
zllHe7a=N)3*A>^zZe%dxRd^u?KdcBi{2yJUuHX%InYX$b=6H1i>&hG$#7$m_sk{26
z%m726_pT&FQOR`;e6cEdK3z(KfykPzTmyu0gw_fVu4_16{Y@TJMo^;3j+sG<7eSiU
z+=9@Dn-ACi`RGKxV-*1h$MXMQxFT^|k`Ut_W6g+4a|@di2c%PYoOfho^!bM`hB023
z4^|cS?AVp0EF!L(N7HQ`Yt;fqk5b>3o?}zPP}a5SG@#9J-Akk@90#w>qv<u1W3s_1
zjQF+j8l!*lPvxbn2wcQZF!2h<I%oVM8j<W~ux*Y#^=h~fM2l`BB>cxC7tgo4RNw*6
z{$C>*9mP)4D!|1_TDfRG-nHmA7Xuvsx`)@L)LYs5s^S(suA6;p*Tn)fprNMGCcUPw
zqx4!FT$iW<NB64Y71-;V1YG0nkebBaykYzBLQoC;M^fB4J--~DOw9r>Fryp4GEk<y
z4o(W=xO;9e*1S$$&QL=0LcS;vG0e#_>GeRpQGdwHI}ObO%~s|?&vNH&FmmT@M~|S#
zAg=KcGMTvY{5Ibh3iBo#hYer)T2*}MGl7R=>!@7;aWX~uavsi9W@Wzf8}Mel^`aiy
z9#}zr8IY$L$9TetJio?g@Q?Ucd=5JZ1}!vqz?{}w4Q2kL{M_Y%hYZ~@)MPFL{^fwj
ztF0<tf*x<AD_J#ubOsCD0O{CrPcy<|AZ@oKX8b2y(5iyOgH^;Ut`!l<x4tGQyo?OI
zK4&%Etr{5qrG&*5l;DF57yf(;p~1h^!L17LE36_{agA8X^P8@P_NwxT*W(A*t{U)N
zHCM7Tbn<Qn_zEfkz2$#1&U?+7Rp>qLL+%sq3+@~43~1i|!kyzB2q7NH$OSZSy^tU1
z-KGH2V@hU>U1VPW?NBGw)$sZs1bP-Mf^wn}LCG}x%kkefh@#x-T#c<9O?e!=|38A&
z*o!$1jTKqOKbkADjDHM*T!&1xpXE9%*F0;Co8m&;3KY*e0w(O~^sO_M&p_egcEfaD
zmOpjLGAS{`G3!!Pb_JYxjW9kF%rTWQ&=~{QHu$+HF_w~Qh09mfuK3@mzA9W9<I9-+
z<v#pO`8CNV+ENo?^%Xw2BB6JUYg}3%><(8-Ty%~4xYB7il9apoEZfx(liv1E((pLa
zU}^0}<O_nVq<Qi2KK@H^o#^NW_+AuX&(J~>co!GPimCz<*Ts~*epMDsZ@f?-&1yZ;
zkS|N=;aw6N(A3wLuW``_>@U$@*JisM_@5%UZX#=S6`X>4zvx?1Gb1jdfs$6d%e^EZ
z%^sfOnT|)^2t9rMkNBr1OvvaJF@C~?ClbOtk2#Y&V2x)~$M35wY5sNMscP)tC2n2I
zKIqo6RY>ZrJu|1%<Pu>?ae9XiHP4?ccgQl&rLTK>wg`@26f&f=q@?6(Ns@1-0~f>x
z-riV&sh~cJo&Xh8rhfG@dKJBHuto18rhfG)`VxH$zFTai@;uTZyH7<vLQ@6HYGg$=
z6&Nyc1Kb$1>^|mtWjTAql=R19Gg@$NHC8B}o-ZeUZZcM|qyka^VuIx_0^j=t-arx6
zfWg!5mftxisbn<PC&OHg?inVQ=qwZ;9WfKNIKH&G6m-mbJ|v)StAHM=B!M7YQc^%c
z-vUP-d<{c#_OfqbgT(gsC`kw?2nZ;fW1evpdC-3&V4zW|K36?F$rh`|wK)9NK#ZYQ
z&X-ifh5^Mc(bzLK*llod^CDYbQ16lw#qkivS-~NbLW=PVB_$5uJ42S>*PthzoS@v<
zC9_MH5Hi&~;XeQyN^6fCu=J@xQXg&aOLxQL1o?rgal;sHJa-2-otwqY;}&sM*OLBj
zj^RnCUgmztv2z%`jgA``0hx~a*NCY#{fhoTrH~QO^lfs*p4bn3n?j7NJ5e|mC*TzD
z{LTXPR@29+4ensX?eziA?;%Fq-grY*eU{<tw5%F8+_Ja<xCU^`5pCgs9#SD=OJxvI
z3sqAN5~@ZJSI<$5t}hd@{>Y-iD_oJ+ajkw_qmjw+O6|UT2WB-deYF}$R0E0NkP`nc
zSLGj2r|C^o<zkOTgFCqU$LA`&Ys~9yb15cY-1eAa#cjTB!TeUXq6Z+$@Lu$iQ?rO6
zi}F>AZva{R06LIn92r9vERM`vwXguPu;Iu`s}_x5)uOqvYQYo%s;*j0$8+$aYE*G6
zql!xxD~M?N4Tss1JlJ9e<QBa0Is{v2sJsGlTdZCnK?LYjy@qj9)-W!iAl_CBg!%MW
z^;fc3u%R?lSn=>}w~j#ur}WS2K&zKC{_f?BOSuU2%;+|AhYsy7qh_9Kp40QqAoJU4
zO#}CDwi++J&DS;7Kr}kb0K5l~#6AN_95FbG3M9c+HCR4iGa_BWS|udGRy87lqbT=(
zVA1I;Lomzu*7c&cP`UpD(-vA#jU>t^-CJ&5qnw{$eh?Ah4Pk*ya)LLlCMK$h39;bD
z5)=1M@3+wHT<65WK`4iInyVn+(xcU+L^Ub#7f6X7Q<~HjJ9*A-73lhTx6w+2R7^VD
z?u5kc%|~oQ+rf)+7evtfQ+&kIY7}v+q6j0ISwym%)mIR~Kf(|u{5K;A#5_T~AlYs;
zC-IN_RnjJtdkoD;Mgx`O0rpmH`=jE2jhh5{ZE(D$XOzEhH81gZ@)D&pdrU3L8-eD#
zck<m6GemE8`@2k_hza2b!a{C)UgCcAFnC-tRIvxWV0c`b@wpWqmu!{eNA#QFamm#3
zluCI=*(yhELphJ-ykZ`gx!`eWD#WmC^k%$ng~#R0YD96XA`0eR>4m**Nsw|rB^BH*
z|IKisdST<HENtix{kULyf^Q-}<Z<HYUd=>QGZEKjB8WCwuiaeDKGi;|XM{WkkG|bm
z2##BMTl+<rDjsYl!&HuA-j>Izcw7F0AfJ;{Nsi@nGIJxC-j<O#2D~kq&ThH4Wed>v
zFta)JHnKU5z+-TQx8-8I3a_um4Yw+80AEW;DG-sIl*;}C7vbwuo+;tqj35{x0Sap=
zo=G+cWW5zc)&6VYo-{u%yKCqAjc0VrN-b=bRIk@e)bZa#Ogvqf-=$uSkwv|_R#Ovy
zD>X5+b837{Vuz`z>0R?9ZDF>&0g;XMtlOWUz&#4G8b*ic=Q|_?ck9pH-fJIg{_(Ys
z>IjdEZi}~~2ZbANOG&NJzh&zm|5_ypW9<V#hEFxhxLKkS&*@9tPWwd_wCy*s$IyDo
zrBDAGxC^qsPaQv>^n|2pgz<MGjPv236@v86Zk=4tMh|b-V^aG9qTSvk20HX&Sa4Kg
z6VRKu-MEZ7XaQQ{)FoYyHbZ;|%M|n&XihwB_+}n}_|eJ{9%s={M(k*rGgFX;-7ZFW
zSg{>+sbX;=PIKzxH-S+5mbk6qm)R5dF>*du_RE})m*CaaT*l4hGFWhESg5-}Rd~Xp
z$JIsRuLUX)IB-^yvtkh-<%KK%TNyrGNpy-GyUAKrCYezUFa9=op-+s>nDl;Zy-6pZ
zzN&iFC6OQHc?&PbdXVUHZ7WAWPVIuxo#-+kJW98KAW<W>alBo?@LMeDA>Gjx{#65v
z8vroSiMbs|p?Y&Wk1pGPy+Y{~0Uu>jh1?a%y7eWk(9&Oz`~o=RcH=MR8X0$%qt$4w
zQ~$iO2IlMNP4o_`@Ui&z5)E_#d@NWbsSh?)ts-z8@UdX}m!^*e)4wz$NzE)geL)kw
z!pC9;M3OGRcUGf}D^0-vlnQ25nalqLW?bhrDhapWqA;V{>*8<nx^Vnj4h&GE>&6$3
z$rn$4<|5R{xlQmzHL|z?$fA-0roQxgp~dAV-!@vAw;QHdgqEU}ki%~s+K9HGt7&C^
zg}yVCDVXLJ)5#Pu^TO}|L=kA@^JB^sO!JC)ZPv#*hSw%j)Mk18%Cj90$D{E$JjuxK
zHy5*9D=Vup#m&SNNUSP}39BCe3$XYTdF?8A<4Q%X1{VJ<=}dk2r3#s-@Veo}6{RZl
zymHLp=y?mX7uD$E2A~T>D~V<5A73xNsGu$?$cjpsgYY0kTDlZEk>`MUkln4|nyK7A
z{YSF50cCO9aTX?5!PZ0`G;+25xu)h%&Ug@}z+ItL!SpoQnn*M@6}ame9-eGXgn4*&
zz{Q|dQNAWJ266}Aftgmte7qPh10T;dctbV5xYDHiPjMDklg<49uaub3!7N`j(y&&G
zbhj1*EW%(znY;&Ipm)8Zi01KXyb&GZGBBiBxeWI&3BjJjf?L$QGh`v^UQ(jx&GB7=
z*1(3+tU8*+h$i_HJxx95KZ87OH=m4!=uWhv(n`sn>s+w>AK#;&A-d$ep_Ii|N@^HN
zSrscKF@QdpQkI$jgRPX9N?B$!>cGoZN|xXicuh6(xT(mas+MLo+(@-CkJf4#PWOT?
z4gWs3j7gQnHNUz+SR?Zyw=wt@<~C^GYC+B$m0zri%BJl<f;61coVOj%!O+HC7yUAr
z|L31+bC#nGwu(}reZdsIYvEAL{4!W9YqH`0$+C@^Xv6gXEYDS6k!_6mWh}wV@m<wu
z<EEkwBRxnJ`ORv?VIq!dAC14sM?;@@nHcB)#}~AcgGTjY%6}&%8M<7T)3NJ60yl2E
zSd*L2YgFrITnxvk9ES1Ft*DsV7#C$at5JrN*Ql2BJa;Ja@8vcYUaH!8{|#a{ZV%55
z`f|0f=Z(vsj=Eo}-x={AK^)~GpZ`Fd>rQSLx0~C;J<q+w9p~QXKITqypL1VxXStua
z-?;Ofjxgepj9ich@<IM62w6}hibY8%4b?;0s1a(4nxmGeE$V=ZQ4iDy4M2m@a5Nf?
zLz5ulb-Cd;y5VBP>*MH2Lq~icI)Gj?GNv9wC(sAT%$Ul&M}KwZHDfu}HSiw2G-E3B
z@ThC}j+!~vTRF3ln0d{Hf$!+}+l}Qg^NUvsqcCAYScEN15W|=%W=d*eE#zy6Z6~t0
zQE$-96qEl#0H<*!=5|@>H0RYB50MD!4$PM`8UCB!Fl;fSNfX&ZKp5bd%iK2M_+`h+
zi52*Jx#9oz6zV9#CWwUny0vMH(nS!iNf&hr7+pIc$IY$OZg(x{+yH-gFRF9Q+h;9p
z5*P0m_&n|q)u60TVL%VDW<Uz1yv4U^)7U&nPkz1!oX$U8QgS|)ZG79pe?Tq&RGxQ2
zikAxDU_d|;#=-&%ODR&?WVt9V7irnpfTa%v>{c5Gbn^^|{$ohAXF<2dckEUl@LM|e
zujf3at1dSaxq~5B4_>WASlrqXt5bsG<R%I1*RARPNmEKnN{0+tR2<);g(p3e5aKZ`
zq^Rr;+k*O|qn@5PA+uNLZxf#)8Qn_Sgy!V%=YOnOvqNyYuq2peDK9yn3Eq$Vy|96L
zOf3#?*iaNYCIx$s2yW%yrKDX*Ru(?DqIR&{CpedM-L_@Rg1OtamF`%&v)18L3)_q;
z_DvP%rH1&93T|`C<M7VlrE7Bg6w9^G4K*^uUp3F^lb4#e@AlW%qEENlW`DEnHTL@-
z@b&zA@xfHI9&(*-1HVtE25uq)rtWzVy@B3xs(YS7pQ10FaU~V%o=gwJ3;P<8s$oXP
zQ>KTJYUp8@>me;b55rXV>~m4wa{``HjSemXh?{~A7{c(fgxXR;R*GdJV-lVq-U-Rb
zn69OdfpV^;eo@({lchgp7^XZXr2-on0Hz91x!Hmj)fnM##R&WszytbI`q^%+0$UbN
zE1c<4_+$6RUQL<~DjMfsRQmkCK|YHbK%p8V+%Sv)I$0>^Mc<N|8F3K}l(gbq?j-?f
z_V5(Xbn?;dt(RqDg}>cT;_t->i$OJuMTo3No6vpE2oa{5^_-ytZXyL!)8Z8R41HyI
zYO;)`Wfyh8Yd{35Z>0#-3PlSuH#$?!sz3@u@u+HyaFa0tWF`$lUcO-|nJCF-<^=gy
z=LIncglg{K@8b^o(as$azf{15gD6S-myrh5Sl~us0Y}_Ov75AY#M0%{r}*>{N0$Ba
zZy^j=Tqxn1TsTU0^Mg58&Yuf|S<cN&qTudkCQyL9(4nH>?e67kbx*P(ctcA~A-fAp
ze)(ZcYxDQ(8IL}c8LD7S(Y-Qu!X{p$AKLiSSNEaDD4G3TcKDrfU+HC23ri85TvT@O
zjd#Ww_l+dG1y{IdG?#kuzU=0ZyTKFQ0i6~wGa!otf!DwaThOJpEEzad@v+efL4M4p
zI|mGAd*gzAT7Q+Z7!2}5x}TnDY?`)pKI0QE$w;)uI*si76+56iY*F{UH^;E{iGHw(
zL3i~lOPmena)=W+jxVG-7t3)LRwv2qWfjc0SU*0g-j$9!(@#LX`K0oNlS9KNN8=_N
z<~{zz-1Xt^InMp3HXS>*=_%N!v>`ZbKKnr5_U(IbcQi`V1k%tvw(roy!Gk9ra@1$X
zs@Q?xe$X<`tQX7{!z#lL)?!9u88({7`9iSa;yovYg-?z_6*jSbx(7FP)HiR5_f?qT
zXk?m(pLHH%eFt+7>bd+Pejn$_rGsf+kbDEN%p1sTG8y@}dxcrN;dmypK(i)VlAV9x
z^&VD@pk3i(O9H>hE(xW>0t4w%L9+Xm?xi_?R>uc+yW?Y<4O`6Lb~_HY!cq8*^6doI
zcJcFb!L^A!Ky~O2U3J`L?`O01v)fPF?E|dV0kCl;8$~1-Jxpen0?F{#Z44|O#;l_`
zrF;FrUb-~!YBrLQelCs^%sS9K!D@h=I8L~fj=Hjq(H8>w<pPCztb65p^kjabU^wGO
z*z@RoOzI<+<HT%d*5R&Hk%AiCyWgl4gW9$ku%u7Z=-3DsPc{0`s1+kRv>!OFZ?ota
ztBV&}bcG7lH@F54X_`NG%9OcjVYz8FVQ&T7Ne|6UH`;zQzqP{V%j=cd92RPr3xeUS
z7cgE2tTel2l3D*g{G!V%*1u!%nzWD8*0*b9b@%a$e{pl_iPUw4jcgu1{&8g26)M(o
zVqK5kAp=_XjGLx<M|U22?@NK*TJ=htA$rGjg0aTvr$R25!PVy)aGcdkL}st#!9vzy
z-JQLGPc}O+>l#7GYW8FJ)HL7f4eOomJhHlj(T=0gKhLrrf#V%VSdYLSj<*8?aSZfS
zcXr(ICXQpr9pB^VKu2Fao4lnrSmo!UpMzDFch0lE0jsD#A({1#^PeD*^=KqIY_{XZ
zhx#A7rvG7nsGoDeW6;*4WgCy`os4n2N|}tO&uW&+S%%9CXOxN+2FhQlaK!3P+<Bw(
zIDUXqy#=L+b(}HEmf$#Sl+6=L6%`ohcn7-~WqS+9`ptttMm<X(W+&&MGR`B(D1h`y
z>7_+0eb;7lKmnk1`ngl**oV%d@k8F$i_6xd``=;X2{PM>E`)Ysqlv}r<yp?LBh{JP
zCneDwIM}oVV_XLEG@FT-hebA?SRH%A+ym=KemaE_B%npuAG`PN-TenH1WR_G*nI!}
zn@?oi=N?c;T8o~v+4QI)Y_;kRd$-sKSD%J3a%|oH>#y6l+U*OMA3L^uAvzFab@kEP
znM2Ao?KH=@a;w;c$w<vG^RStdNQeXl9cE|QVW*wH*legy3w<{Hxy!VyqiLsOH<X~z
zw109D@xH`PyS>~t(^9+Lw44on7w4?=ob}?I6$W#b#h8?wlNCDv19O5gU%*Uthb44M
zUA0MBvv9YD&TSj5VTC<oKBBcsPp4@-cJAd{t))+}{mS>#+5J#NBAc67sVh%R?4YIM
z0AC3AvX=g2Gwv342ken2o!e|KDt+8$qs=RBSo#qSb?!0j((J-0{w(j$shlsHmysK1
z3E|w0-=y+3m;t7MC1x8yfuX!m|7Z1%`f>Pa59<w4;KQ)Bl|B!;=5P8uG#*LtGq$Z&
z53}3#aA+2okI;u!oNIjl0aORh*rs>TkHIrM4o>?GPMpI|v+H42EBX+={Q-2X@Tzti
zSm(-iifoLOt4vUG#ccW)?EN;<Rnd3oI~2D%3Tg>|>$s}miqTSWjfCUy_geP%id0Z5
zcAguYk6I}1byR&PoM&G55d|8WR;qVTE{Kb`wB|))j-n!;WV5g*)RH1voO9IW1(@D+
z{k{7S=+8BwZ+ey1_VT93z2i!|H{E#e{{5RbRJAqjvBASXc<kp^MMbUP|E5QW3?DuO
z?5P;vJvj@P4A!uEGzUR*XfTn8dCWQIUp`;)i)?~iIuuaIGC{QamwrwI{n?Sh{&rEI
zEBpgXhsuJ@p9YqGZX8(_NJ63snkv_-C8Md>9xUnG^lg$}00*Z@!FH@qft^~iK9xk*
zlu$?1(Kt9&X3xqMY`)wgfOgK#!1@5|!BtDeCeNx?`Iinh>|6n*xV%L4o-0_S=Y#Q6
z3^S+U(neP(6|)&}-+|#?bSmcpJLa<uLkD}Bh!^y9==G1<?X+X*n|Amk+AcfC>KqQt
zr;m79;kkmx<WVd8ew@u#dJb^KQoV#<BnX_%oCPW%1WV>-P61FEKIOxz0pff-uTVGi
zv2xtt>BWG<6HZ9s>A^6?`<Fvb-pvUcvKunoFl^m^15xB;F-URFas`OQFz^<=L{Ru{
z@Dv!>?Jwapa<O46V5p#&K&>(^Gk{uU<Tm+otVC;EglP<!1(m}zhS|#2T>&c@*sVXm
zh^~S+K4>Ipl}r1T6PO#wxY9FI1zeVS6Bysh!pXM`AC&g@vTKyy<q>>oHR;g6x=qzP
zz~M;Q-;N!}B-St3yF(=#K<}lzr<+5x6OS<)E`9>dei1B^Z_8jzCLfe}v%3Qp_bTlV
zxWt3rMKwFlEiX2D5Bk@8PV}vJ@|PXQh&@mO$w9Eei8uJ&TvKDrsERjCOa40SfbMB=
zqK{S1Sv?Bojh|XL_QDk2y{P}?AY|$w210tE5inDXY=KSz3L!0U^D1+ERX7r1z>(jK
zR~?w?|Fj$o+h(9tXF1G2e*u<Ml%s5!S&lbtwzDnteNdR<BE2pAIcVBl`*Mhq-vWPT
zwU%9IL0VQV1vG`z@+x4(iK{R-?!s4OHF=(k0-O$`xQNZ?J=GHsR9GlXCI(uEeqbba
zByfNY1MJO*B-t3OWruv(E2w7*S&awieOmXb@vyId^JlFQ6UL5(J(oxPy;pWp{9Jr&
zU(Td8AC{+)T8~Jmt|01r;?lZ=M4*#d>Culgw_3*x>K~WhH8@PSHp;N?2}%z@Yg$=6
zymAZlhyafwi>q6cmgs$7)|bhJVR|0%0lVY5EUuYhIdQ(OnJ+vn3#DPHSr9fxIN#t5
z<9&U^a`VL$FrDQ<U<H8>i4VUkWYePi+c)XhB|A2!K@FvSqjc{bHDX$}EsU)Z<l=23
zNh3-YjO;Wxf05|6qh{-qVY`T<UxXz-P7JGszx41e+qa@ab8Addc5!BGVI*mr*NsHw
z*mBd7n$}G93m2u??TZsK2NYWaEV0eX-kH{^(FRiAwXB{c&SLTRtmSV!C(-c0+R6RE
z5pfpwMkj<NC%Pwz$yWD7Y`1Nz6ZJ@)C3Dfp8G<kn&&xmq-OKi|^DYe3yQA;nyg=Yi
z%4rJY4Y0gI02{(p(D$PUFCJLft$A8{QJf{HiN$X{n$vfF=eAMFJ<|%Cr{~zj4p|*Y
zOLk?$9@bApsP8zVt}j-#v!7H{?-hHBh(nun7}cRs(;6Fm{p-cqJa|_%JmvL49UC@v
z+2|KIG(~V#qoPp~7N>L=oS4?uQU{%E99z3VV&j_8-oZmYNla^JvFX;l*xJtoMSB|M
zg!ad4jrM1~wxaD>&t%=QYU4*D_SWfad%Tu^G-$@er3D!ct+g}k33c5`erBxaLz=B+
zrp*>2XZYgC;sKL-HEoH%4}j*J*Qs6Y=q8zQN%iclqe<tyjwC8QtZ9?z4o!kYVOpoY
z$@Ppn;x7DzyW)ea?ooM-uov(w5ORQoWmb+oJf5kzt7}qH!}#V!*|vx&Lxw+CbH_R)
z>WlsQ9j}4vdFJG_jHnkA*`V{uXZwBb{^fEP$Ic>m6za)gJzvkobMUiVEjEY1HJyFh
zNWTgtbKV6L*k;-h(4V0e@SGv}V<&Z=HFtTcJ^t}gs}+>KWnti*ZzJx^oS}oV`Z;C}
z?YlJ6e+o)p)S$oXq2Z(aY9@9Wl9%p<yN=)Ieq?EoK34zCt7qMr`W;El2ITsOKv7}*
zD+5s49)HW#G%azC8XoZ41q}f8Up`RK_H*uh_u&r7iEb$Y9jxg|J}t(-JbO5v_1%_V
zGtxR*3J`7;8RXNV`Hy`gx_!RxX?E=kf}V?x!?kO{4zw+153W&2vqVrj_E57Mq2s<q
zNgd}rl$My)hct|vnBy6n9^v09v@TwoI7T0;pBuW>Hz*;cvAY~!@Jz~g$ns)VR81dd
zf98ch&~M}jYb&cDLL-6cjABel1>o%KZPXr&ALzG{-3GX1ht`?WCfP4Gp|_x9g*2a&
z)uQvvRw%bs_rS2C_SwEst{&R7V+SWjvg_(kqP^r8=f~=Wz2SMYhZmaP-$>+UTp#W2
z-6Wz`)+1rkyhLl=S%uw-NTTcAj%IVL7Nrvov!h_VWSTXsb?dPKP#+lBS`K5f7T&ll
z26ix}74{Oz#%A+HGBF`6BH2C62kt0h9HtKs4b8|14MhoI8DYzP*82Kdt=5RaIBtL~
zJk*gpI=&%Z8e7-#W<7YEf#THr<I`~cKrWn%VdI7n7E*Z>HB2|}M4b0Xu_m!{u@MuW
zKDAGOp-pO9`y>zFr!&IB;HLR&eVZND)9M8H)y{52Up%@mwO!k^dT}ahj8B(<31u@#
zn}kM=TCWYritwvr_pe_w3+m4G!V#QDwnI5ND<6ZPfN&4dX7%x{fuLZ}96mTtKOH-=
zrc2E*cjUfkIO&%a8i}@@a9I(F?Jj}go^Q^xi(Ub`6dS}|o1iak*XQB{xMm1z4|q>9
zo|#C*sAM1sSQQ#KU`^$N6J+<)I4TEB9#*{C&%Z%@-AFGx+^4~_13T(xCBFv6u0aLq
z2{mc3HIv*MQq%Lz#w8J<4tvzS#=W?;aE}zIN2pOtn0q2hS-TeY(1kbj&1eT~d0ZTm
zlM|iy4@<V79R)?JirY%9(np2|y?}~+?rPiFZ-pf%c@h3{1}g)%5Pt14uWLu{7PL!0
zfoj7(9KP_Tz6A%uHjL7&-9l}ZFO37ATeGf%Z@qe5EIvEXyKZY9^LfXsVaz~0`5?RQ
zfD31F5}fM>_3fM-JrkW%JWi@Pu-*4HmaLuPy(G8U;@JUjCT8Lxj`zC6jb)GJg;0Gn
z4lvI}1T#-Evq-6)VW~LaWP$!+*OnntZvEj2p_YeV3?ggGiuB!ni-Pmwm*O*%&H8E&
z_g`9Zf9P|mo|f|aFO3;AQ~%U;DY8%S9Z|pT;R6A$MrY%3jvso}>HvcdvmpS=KBwFU
zXjmvcvjT<(uwl-zh#|wbt!^LZn^tdyecg^&FrojJ;%-m_=yAN|Ae4UxbpChYd>9bS
z_ayde<$R_9?zjWSdAFrwLdy<_{Lrx#N@=9=pLA%@pg|5^nbRP`J;ae^mct*$<pXdX
zsF=&19oETA7|0M5KJf0t`n&1&h;*8hJSrni|E66B)H26KjC=UQd+l}WMQEDbvS0{l
zoZT?YJ&cv{u?yeHZTS^kFW4~{Y0;QPU<~wiLN%0vs5u#!qa=WtOZLlWL}N%RC$3Xd
zJdL>!MrzC^Pcg+4`fg%^+%_zuNt;CdzMzzeow8~=W)wt4AkSGSPhX(hI_3w}&y0Y!
z{(LwJ(m&ScH_mO@@XYrUT6RiEE{e;~jZdi8Cac-DB^^gEY&Q1Xkr`otme#+}EGjUz
z{#y`$(szh0ke}=o-+J=0fsQ);f@gN`<gV{1%xU=>nzS1Y{N52ecTi-D#?eW=enurv
zqLSZrxl7l9P4tY0V_Md0&>%KDT+>|R>s$OL6)t|L+gcR$c{hJw)mJ~GyX+gEe|I*j
zkB6Y3_GX(fywV-;fpe84nGGe*u4N!wHhEU!$W3Ix<}K$`19jo+L%REVHI3Ufso&Vu
zLyPk>>nGF-lD$2M9B$9e%w9Zd=Jq9pc^kK%$xTcpb=<vTGxXB;-gy6ueGe_~-h9%i
zKHjapT~uq^J7%nIk$Z5@p|87jSoZTP@7U_FzRT@|`O}9?D#ug6+Lyx<W`t>-*;vVL
zm6jh2v#8I4yS`kruTS^op`KoKYSzq)i%hOJXjPx~Q@b_cU2Q2fa;87nKRp2tKl}8-
z7uIZ8xv0>?-8I<LD}Bk7fy46KJhWmH;x@Ylr74ykFSG^l%<O4&;TYY^4>jJX!{Gj5
zA?9+R1**X}(c6-o=v)W!1`~W>@bqP0GS(VAoSh2BGP<`-{)AcU^$Xipt=xw2J+sE=
zx6_x8tdrkq<SV_Jy>@rpa*Hj(KfYm6-K6#QW&=Hs<Tq)YKPY1W8iFELb?o`|QKTZ5
z<KOq}xGE!KTtVlvkA6M7by#3x?bvpW^}_iH33>Nrz<k)~!U^8aXTke_BFEWLGIL>#
zWsg94+ogghM+BJTZFsXHMuowJ;R^;LN=@PIj#J$mN<}4&XD^!HxogYt@hB)F#CI+Z
z>z*T_{=VtjNZt3{_X{nd(+3Xfl~FIw!}qfnny+Zne%|Os^|zquqdZ*dv4f?bH*&$K
z1efUV3~JYL$iR66vMbjmSck4zm%d^cbWQQvm1u9?X~dzPdHbJ#yi5KD`^51JykGy5
z+UvA3BV%my&cE#ZZpXs$Yv$|4bIqDFY|~SvXg-_k!D<fB3B)!<*pgF{Ey)SK3C=l@
z)twLEid64VTPW*%jJbum@(Rbj7#Ve?<Irmo5~b*}@L63FQWCn%D$A6;y_8HpYmQ65
zJa^Q`KTq=ZRI~hS=ui)K$PIN4cOHu9jSiWI`j&qyLU3s=^&U`c?>c#MS9|e*`bc$8
zq7m6HBvTMFVJEqCLD8lACyVHq%AcPMtPuhW%9Y!Pu}84>4g(qld9mK&<V-!GL5#j+
zxJR=`junxu0U8ei8#qIJedyj*+w=?TXHCd&gN6*q7?j_*N&XSffz9melj;^VjQ5YQ
zS(eA${aUkLuZ--JUuUGgyj}kIS@$5kZ6#i(|9bRmqm$p4myj?YJ=VBgZ0*Fru-3D`
ze)MeTf^iuc@GyLToMFFY7{?fPh+-@&9|5m1Vsb(l3}LaT{8c^0Si6TN%RsEj0F!yL
zf>?>Ozmpw}gSSUCOh*=)xOro*%$#J`)~9^^z1rr~e6?0iclitVP_2o+ZvN&T?Q-TJ
zp0Cdbd#ele_mfh4G-~fR3`I3`QR~Cu+FF2PXo5n2M|Yl_F}OiXs7uVAKyn=H3uCJR
zu*xTdS(1I?6H=3m{sKVD;t3s$*=_V9_TCLU0Jgx`6moocuW61)(~AkOcCSrbqtiX@
z$;&r|c_C%uu({hN6kqVL?&~t8Y-H00nK+Cp_<*PEk)gk|EUvywu>N{x{`d|<^sTjA
zhMMil>MDRdYcgyVqk+j?K!X}>2-Rct<&BnxmL&m=yAC|CV9w+jyP`v^QMCfbS~F`~
zG}O^u-(oH3IyZH^RI|t<JpS$#2cNogwNF4~FfbGaO>%SFX0=<{WmIFMKP6tcKp!US
zxmK)&VEKhD{lgoW=?;*Xk_fK=#z6yc8a*kr`~ibr1?!t;_o{r5;ZZiM!rAoU>_Gje
zknFa6Yz@cPyxLlHb9c!O(0>Tdp0Dz}+D?G|tPrFHXGOKEQ4{?})eeH2n@g4jsc@*P
zLaEx8eTOwIA_89OSne)+BG#nHQ+CIPJS20^HO#RZ4=dmE5Ir5qo}wo*%cxHjGRQiv
z__A@MF06<{V~e5U#R7z~A<a2xT;aGeXk6(ylvv1cxb|%wXb)`D&k?Fwg;s5NPdArr
z4Y_z`X`XIkTht<}Erml_8sY=9T|C^RHaV!M%D37OWnrJj;aTIxWrgSV&WysZ#UPYP
zX(ozxD3|P|MB(2mK1*?vyqtYWf0pEu7q}D{BQBx>){|JP09t?oLXWyQKp2ywIU}-p
z+yD=`!)F}bKPWKB%@S$NE?!-jCbiD6%&y&Yuzzr^fKd_CHj||MyKCj!EeT;U<N9_!
zI%@<<KmFWChZ6mKvRhiS4=p{MP``gbV7=m3RvnA&(mW=tWk%wsFTz}%?6fVO;ms@b
zb6X5DMk{89IlGiw4M#|B;Gq3SXAB=P>uBe`<6^=REcX0bcjqUOXC_bYnLWndvuJ^o
zR=B!2+Zt(c3ySeeJoM3Xr$2r1)5MIHVKL3S#2#Dq%EB2PrVTl~^ia07Wi~wi3_FOa
zfF0Pn6k8Ky54;WD+S$NrfXgt?L=Ur4JQFS097_pran5;SYP`EWdKTWk^8$Ba=YwQU
zbZz&z@G|fF9{KU-hqro{>Y3`PmhIaWomPpp?0xyG7Ok7N`Wl5DZ<Jp{|Ln-|<3~`S
zYeB<zAfVZ0?|}o)=|7?MixU%;=sg?g8EcZ0RzQOiF6qKo{Ca55ny^v|@3>aOMki#j
z)qt=SPk3aFcJocN7_AAzJ#TS(^ziG`U25CL;n9<JKRIy}o>1tL7WA{{(DB<J96!wS
zXT1xG%bhx_Q6xg&>0WV-r_XIzXaC07D7t6i%2f-Wp~V|e=3`SAE}Hu2lkKL>YWsNR
z%UxzK@67s{fn~(U`5YKKy8Q{3@q~p`@Mv-lB9&)p<2BZprj3ye+<Q`)<$sQQ#K)`R
zo{t=%lE>qDQTiHdp6uzNjQ0>l_n9%dbx_afT-hp5^puF=c^%j&s%&JCTR1YN<?tH8
zw03Zf(E5T<ABVdIbq%;0aDur6+K7##9l4%=I@f_~!nLczKvdwn?5vMJn;7|rFP|9K
zJI?dUf-H;v6AUiyZbDm?Ql(3DRxna6SuSpFLVK0RiQa#G`aJ4*p<=WZJ@Fw=(Zd{i
zC6A(@Kc8CRId2HHunKT)8+fLYfa8Q$Q!ki9*lYpwi6Aof3+HhdbJ%eP58ycCW#Ex#
z<URW;J25FWG%*1tCHA#A=Q}RHiq_`6eI(u^_Er7e7<Wx=f;L4{JMZnyO9d&jv+Zsk
z%2r8G`*x4_$n(%ox@Ec5s!em#>@|=g#WzljBfIUqordZUMESThwI?;P_H@@`^iw{>
z!VW1RNm)~)f)$tAj{YHH4VY?>PZ*^>7QR**wTFm7yf3WPBQ8R3%Ok)Lj7wzem7?J4
zTo5zL46FcqG{JcQ^>!RiOsubFqo;Fw>v`L1X4DnF4eC2=C~lNX2IYDC*Kx$<Ife{R
zbMYe^NA?@;tiwJ~hq-WVb~VN$UaTspz#upZ6BksF^C<B#`AY*Xm^BB(LaL{6CK%zv
z_YNh=p^~f6D0SXifA>~sR$wR&Aqjy(-NZ@t=SNIVmem^RU!=!97Z>QQ#W#)kafVBv
zg?y~I^S*k23lVF<i{Xq|E7hlj3VQ!QKFX)9&-m!tj&a29=H({{wrEx0>0m0?sviVn
z1mb#t&mZGy;LXvPi&zaY<_#beds%cgdJP!#*-NCevV8cYpx_u?>(Q}qW_srFBrl(k
z6I~)a{0o&fF}4PHQ=NG$_Ms0$>X6295%$#V&N=BmnU;W{hQZ_Xl~E1TZQe5e<G`F{
zfI7KgG=U9P#=pVk8(>!ru6z%}_EzU7q|$L(X`AN)K;^>xCsaBv!aL_+xSIJdg*)ur
zMx2PKa~s39#kox?9jBGHdCmpZc78{wbX??u;5vjul(_*gi_LA*eskNj-`qCsH@8ju
z&27_ubKA7v+&1kuw<S(O$<FJ`P~KeUw!&>ena*vMtB*c$Zfjf&4t8$4aIg&N+^%7K
zr!6;>8vxADFs?V(hYNwL4TB@2xlyp)7q&;j-v)4`7ksOa@kt2R8umuQ{&3@a8Ssrf
z_>6tGpK*;wussI$hQU?XrwPD7#B*tI-gs^ZjJw02hI+v90mfa1!v1L3V@HO-`6J=#
z{b6q?Sj4{32j<dN@Vg&elbtt`YiE3G6nx5T4S{RN!FLk4q_#r`^cvQ?Pe|^tp`%BI
z^c^-bq`}Z$1Nsad9n!kj$N|GgkID$i>oaU*zdj+2hK(6H40aRZ;?r7>AJTK!;2t3Z
zMuiL=Haet7$dEoGd-d-zwD*8fePUYm={II@kCE;Aj2ty!*wB#pxR`__sHBl#LLaUG
z%oz=4424%GRte_OLB?J~C@ia_!SKT>n0=!m7|bfIe7^-0log?m^BAiHR%}+q6;%}i
zRW=yD*NYouRM;?Rm=GAS`@?x5T-63_4c9WS!m6q_d}}oP42K6G7JkMU6*>}r$H37(
zhJEaNF;KlD;qyD-Z#)oM$?&^3><@u!u`-N?``5kXv+OIJU%B(JS_y&g^oR3VXJXC8
z?#Rl>>WOtPv%V@i8nb&md}3M&5Xx{s<2c8gY;3*!U&L}ahTvNSyq9?J<rX=KlQ{)E
z$29O}sR1jSZopc5fCsJ@=M5aJFRYpP!!r{I^FR=AsljkF3l|D+mf?WeBH*pAHfM)1
zFcO+88Y(5$=(!2-2ATv_k^&y>X;3+Jp;y=AGGR44i_3<mBL^C`5!V=O%;TDX*FiHb
zAG$_!u8=F@T5v6)_qK-SY770gJ=Xz{M<=c`yyJA?x&j{S4%P7xcP}@So5elHt>V7o
zW^;?V1>8N{1Moa!ZayO13~o7S^!&^%f-z<;;<=BwAG!71gWRv&FQDABnR}Q!$i2cn
z0^Ot+cPBL4A*kM0x!1TO-0R#MFxGtyReh9ulY0x;=ziP}+)~j0d51d&P4g{xhMUI?
zgr*q;O+6T@e<L*X2<R@Xi;RH=E8)g+-*Dr&3D7VTxyjrl&=A_hO@WRwm74~hLua{X
zkbp#Rs*{m|RL%i9LhvGmY9Lqc0s`&>+-yA%LY~MAF+W>h<cIuG018AkL1CyC_Xl?l
z1)~sTL7^xNg(EA9KsHnx*})Sp5`6KZQ4DAky$d=-aVQ=ophVCkN(MSQ6;z4RQC*Y)
z+C-V4Wb`SjkFroUYJhT3L(nQ}jB-&PY69N=%}_on050@VP%kP(MW_Whz_miHQ5#S)
zYR8qrD&uF|=cqlX8g)dSP-oCK>VmqWZm2tG9Q8!KP;XE=>WliJ{-Ad>5Dh|uxjjH7
z4n@PzaPAB4OEdzFM5EAXGzOKRv7m)C9!)?KK@n*(x&uu?Q_(au9nIjjqM2wGnvLe5
zxo94mj}}1o?nP)Z=qB9>IX9PqdeREWytxYEAMZkUqcso(xena}k&qi86Xzz-RJs@P
zaoz`cv$jE2&IceiayxnmloTETW$B%ur|=kh92BOX09}Qr&~AvBd<N}7&qCbfUi3VA
z0iq}Op_kChptf)Ty@Fl^&4t&{A@n*ZFC0ckAW!&P=xuZqvV|W*$01|*3G^O1iQWgL
zrVr6a=woyW6q`<iGQ(%+bMyuJ65=kuM&Cf}<#*@|It#fnen3BhxAV{F7tnM14f1CE
z0jf^tAuDJZav&XDz#QmWV@xoGOkM)y36((YNr7yk8e|}^0jf`KkX^$Aw4c1NH)Id>
z#eSfD9RM+$HE|GVU<X6SFAEOEVK^Kze?@@)Lv6_aRR>&sq96-c4CEM%gKQiLpa_u!
zdQmB$3y}sHN9*DY(1*wb^{6bIjT_(`+z>Yc_3T`nhnql1Ml+lbIm4RcLR<uy!&*XK
z($<hatSu-^wTCQX9dRefQd*3=z)E{J+#Pa?^~Ak!Z^$gx7x%;cL1SVd<U=2fhv1=*
z>ti?`fk)y|phq<Zm*BCG(R4gy9-9bxO(#SCu_=(<bQ)wKn}KKIS&)lt4xWqWK}NC#
zkneO6<Rx1ISx=WjcCzJ=BV;AyC|iy1!goWavbA^}z6Y<z8}LTF32(;t;w|_-ycKW5
z_u~ifgLpfB2tSM;!8`Cy{3w15KaO|dC-9Tp3GNg86n7Hu#!usC@E-gueh%-&&*K;H
zi+CS?3BQc@gZ9@4+=tvL?mg~fd;q_KU&ROUYxod;9lwDO<0JS@{1$#2AI0zBWB53J
z7oWiI;gk4%`~m(De}q5Ar|>8EH2xHShCjz&;4kr4_-p(P{uY0S&)~E8d;A0b5&wjL
z#=qcS@o)Hd{0BaV&*M^Dh8<YP7YIjSIgb!R2~Pwf5{bw}Au7>`3#ma|i5qbz9>kM)
z5pVFn@g;u5A2_!_Qj-LcS|pf+5DN(<VI-VbNd&PGh!!DrNF<3O(Ike%k~k7i5=bIR
zBFQ9$q>?m}PU?~jQjcVk`Xq~FlLjP*G$f5kW8h!%NE6bOG$Z+>fHWtCq=<l%6KO?S
zlQyI+X-C?V4x}ULL^_jV(uH&--AH%RgY+c5NN>`I^d<dBe=>j!B!kFcGK35z!^m(l
zf{Y}ixckXyGKQ3pv1A+>PbQFwWD=Q7?jTdhR5FcBCo{-QGK<XSHjp`FE}2K>lLcfU
zSwt3-CFD-Blq@65$qKTPtOD<;ySUZlZn6dt`dYG%+(Xur4P+zPL^hLq$rf@S*-EyN
z`^f|3L9(4ZL>?xO0HeE;JW3uTkCR>G3GyU)itHv&lV`{t@+^6d>?O~W7s!ibA9;zq
zO!kul<Q4KNIY?e3hsf*X4RV+qA#akm$lK&7d50VW{`FmQg1kpglK066<U{fi`Iwv{
zpODk!Q}P-4oP0sPBwvxQ$v5O%@*O!t&XVuR59CMk6Zx6^LVhK`k>AN5<QzFqN=X@U
z5S?7097PmULMi2`Kt(E1nJQGJ8g-#Hs4I1&?$m>NQZMRFeW)+>qy9922GW`|h}NRP
zG=y4cC=H|G)Jh|$jn<}iT8Bo`C>l*;Xe^DR@ic)Z(j=NpQ)ntpqv^CR&7k#YCaq7i
zXf|y?b7(`_h&HCVG><l+O=&ZlPYY;sT1bm%3)+&lqOEBg+LpGX?P&+vk#?e;X)*0W
zyV7p7JMBSx(q6PT?L+(0ezZRwKnK!6@LDy54yD8Ba5{pHq@(C)I);|ev2+|APbbic
zbP}CR@1RrYR631Lr!(kGI*ZPxbLd<;kIttH=t8=PE~ZQ9opdQ(MwinSbR}IySA!Ge
z-E<9IOV`nR=z6+=Zls&&W_mB(Lhqwn={9;leSkhlx6_B{!}JllgYKk{(#PoIbQgVs
zK1rXVyXn*P8M=o)OP`~A>GSjj`Xb#&U!pJ5{qz8Rg}zD;(%0xA`Z|4s9;Qd=oAfRE
zHa$w;p~vWP`Yt^|-=in#`}70)A^nJcOi$5I=xO>X{fvH2zo1{zujtqG8~QE%j-H`s
z>G$*p`Xl{`{!D+NztZ36@AMCPj-IEbw2V5aPA~8rk9f=zp7J~|@FFkqGOzF|ukkK?
z4c?V^<K1}=-jny@y?Gzrm-plS`2aqUugM4TwfJB@gtzdad>9|jTlomy#@B`wyE=R%
zAH_%WF?=i^$H(&td?KI3C-W(MDxb!u^L6<Qz8;?m3lLd+Hs65H;T!Ue_{MxLpT{@h
zoAS;0e7=Bh&KL4Ud<(uM-->U|x8d9J?fCY52ficUiSNu8^IiC^d^f&3--GYT_u_l=
zefYk7KfXUdfFH;Y;s^6X_@VqTemFmZAIXp6NAqL&5`HW{jvvoY;3x8v_{sbo{1kpF
zKaHQx&){eBv-sKk9DXi8kDt#k;1@#l-C}+Te<#0`U&b%zSMV!=qgl=0#ox`Z;n(u(
z_<Q*E{04p_zlq<>-^*{|@8h@f+xYwW2lxm1?fgUh!~7%s4t^*9DE}D$IKPX3f`5{K
zir>vY%|FBM;h*K7<M;B<^Dpo(^85Ig_?P+p`~m(I{#E`U{~CXYf1Q7WKg=KD-{jxo
z-{z0<@9@X?<NUk)3I09)B>z7D0skTY5&toNivNT^&40>&#(&O#!GFnr#edCz!+*<v
z$De`tjqmv%_#gS7_@DV-_+R<o_}}?I_;dVuzLYQH9lXw85I6w|SReuwctHT3R1#!C
z5mZ4FT!b2etKcTM3m$@};3aqqK7y~{C-@5iLZDDn2oh=u!9s{&5kiG9AzZKu5rR#q
zE!c%RLZlESL<=!OtPm%}3kgD^kR&7vDMG4{CZr2>g$$vdkSWv`vV?4*fsi9K6dDPQ
zg<K&|Xd*NfnhE(rfzVti6pDlvLQA2Q&{}9Cv=!P3?S&3PN1>C@Stu5|2wjD4LU*Bu
z&{OCo^cMOEeT9BPe_?<yP#7c(7KR8zg<-;QVT3SJ7$uAr#t0?CSYeznUYH<E6ebCi
zg*${P!c<|JFkP4-%oJt`vxParTw$ItUsxb46c!1Kg(bqB!ct+Guv}OntQ1xWtA)FS
zyM;BvT49}VkFZ|YAZ!#i37ds`g)PE;!d79MaKG??@Sw0=cu06yctqGC>=Ygq9upoH
zb_q`iPYO>7yM?EPXM{b%v%+)2Ug3G+1>r?upYW3Kvanw`AiN^HDjXDE6AlTl3vURA
zg(Je7!dt@I!cpNJ;h1n-cvm<fyeFI#-WNU)J`_F@J{C?1p9rUgPleBf&xJ39FNLp!
zuZ3@fZ-wuKGs0Qnd*KJ+N8u;oXW<v&SK&9|ci|7=oN!(!70LvMpbHm7PDCOWiAY5r
z7)4Q(L|IfsRn$Zmv4-d>x{2<hhv+GKiQb}*=qvh({$hX_DAp8%#9Cso7$RE4P%%sl
z7p-E1XcKFTcCn5aDMpFWVvHCo#)<J_f|w{KiOFJ$m@1};>0(_mL#!ueiuJ`TF<WdP
z=7<f&Mq*<zSIiTeh)u<2V!l`)HWv%UBC&<oQfwu*7Tbtz#dczQv4hxA>?C#;i^VQt
zSFxMeUF;$D6nlxi#Xe$Rv7gvq93T!92Z@8lA>vSRm^fS<A&wMBiKE3aVu?6b94C$!
zCx{cpN#bPj4snV&Rh%YH7iWkw#aZHPagI1woF~o~7l;eRMdD&{iFl{DR9ptKiYvsG
z;wo{qc$av$xJFznt`qMO*NYp(jp8P8vv{w#MZ8bkDsB_+7atHG6t{~Hi4Tj9h&#lc
z;-lhY;^X2j@d@!s@hNe)__X+pxJP_ed`{deJ}<r?z9{Y!UlLyy_lpO_SHxGvgW_xA
zA@Ozb4e_veM0`_xOMF{AD!wBg6OW7UiYLVP#FOIt;s@e~;z#1g;wkYH@wE7<_?h^*
z_=WhT_?7sz_>K6j_?>u0JS%=L{viG+{v`e^{v!S={wDq|{vn<d&x@sEndlI8@d6{V
zBrFk$O1vaUq9jSOq)4iyNiI?i$yIWb+$C5kl)NNw$w%^){3L%VKnj#<N<mUBDOd`T
zEK;ZxCWT8@DMGSwk8zJnwI#b$hkKHHihEg#1TOFiZod@8P3QJ;bEIe~MvCROOL0=X
zlprNaNm8<uBBe@c+yN<Fsw-tk^`uOxzLX_pb9=exr3O-t)KF?9HI{OvJgJG)lzUcc
zCgn>7Qgf+LDw0}AEu~gcYpIRYR%$1;mpVutrA|_3saWbFb(OkF-K8E<PpOyGTk0eA
zmHJ8jr2*1FX^=En8X^sqhDpPv5z<I$lr&lzBb7*FrE$`DX@WFSnj}q@?vSQPQ>AIr
zbZLe(Q<^2smgY!vrFqhPX@Rs*S|lx&mPmI>OQmJfa%qLMQd%XgmhO`7mexpXrFGIh
z(t2rww2}K=+9Yk3?v=Jk_eoo&ZPNYH1JZ-icIhGMVd)WRhqP0ARC-K$T-qf)Aw4NQ
zCGD1;mY$LJNY6^oNqeQ|r5B_ZrG3&%(#z6*>45Z#^s01FdQCbcy)L~W9hQzrZ%S`T
zZ%ap|ccf#|ap_&@g!G<tQhHzdK>ASnNcvbhC4C~DmOhm}lRlTekiL|@lD?L{k-n9_
zlg>zIrSGL5q#vc9q@Sf<q+g}qq~E1Kq;t}FsZ=VH9Fi_w;1<f9jASemnaaE@$f7LC
zvaHCetjR8N4cS$8lig(x*;DqCy=5QSSN4<r<p4QQt|<q}wd7zqM7GGGa+n-0TjdDZ
zCfAnjaveERj*_G07&%ssljG$CIZ;lMljRgSRZf%B<+^f)Tu;uF>&sbkw%kC@ksHd5
z<i>KYoF_Mto661Pe7QhwE*Hv0atpbo+)8dOw~^b*?d0}y2f3r%N$xBc%U$HIayPlV
z+(Ygu_mX?dedNA!Ke@j=KprR$k_XE}<e~B~dAK}69x0EKN6Ta65_zmVP985$kSEHM
z<jL|K@)UWhJWZZ1&yZ)zv*g+G9C@xhPo6I?kQd5}<i+w5`A&JMyi8s$uaH;DtK`-4
zUGm-X8hNd}PQFK8FK>`H%A4fP^1bpF`9688yiLAeen5Uu-Y!2RKP*2Y?~r%OkIIk9
zkITE{C*&vPr{vx8)ABR&9{E}MIeD-Ay!?XvqP$OjNq$-0FCUO!kzbV$%CE_X<k#gl
z<iqk2`AzvP`EB{A{EmD~J}$p2pOD{^PjYw3@5>*^AIcxeAIqoYPvq0`r}Ag==kgca
z8u?4^Zti>eEBR~r8~I!LJNXRgQQs$@mA{vN;Fifh%0J0J%fHCK%D>6K%YVq{<nwZ=
zT*j@F9kMQ8P&frCSRo2kctub|MN(u%QB*}!T$CD$tKz1(D;|oc;-z>iK8mm6$8A&m
zl>jABsi_1hwUl5bM6oELN|+L^Sd|FHrqovKN*yIqiBh7K7$uflqQoijN&;wUtyB_~
zBqdo%QBsvOC0(hjWGMBNOr^e(rDQ7&lpLj@(nx8n<SKbe6Q!xrOvzUYl;%pIQlzv{
zS}LuS)=C?tt<p|uuXIp4DxH+hO0m*K>8f;7x+^`Do=PvJx6()HtMpU)D+82)${=O1
zGDI1w3{!?HBb1TKC}p%VMk!IoD&v&#$^>PiGD(@N+@VZSrYh5v>B<acrZP*Jt;|v8
zD)W^2$^vDfvPfC1EK%-MmMY7X<;n_WrLsy{t=y&Dt*lYjD(jScl=aF6Wuvl5*{s~F
zY*Fr0wkq3{`;`Zj2bJy0L(0R-BgzhCr}C)snDV%?OL;<hQh7?*tvszfqwG<hRi0D!
zD$gq~C@(7el$Vs3mHo;A<rU>s<)HGKa!7eyc|$p@98um>-csIHjw<gc$CTsByUGdW
zJ>{hGzVd<cq4JUPv2sfJL^-W|s(hw=u6&_<seGk;t$d?=t9+-NQO+vgD?cbdDnBVd
zE59heD!(beD}N~Gl=DidQl>Z*UAdrgDpIjZRI2i-po*%b%BrHOs;0WAHB?vCO?6j2
zR8Q4Q^;UgUU)4|bR|C{QwWb=R)>4Dj5Y?iFs$pulYE>gtn_647t98^!HA;<EW7JqR
zPK{R+)I>E&O;%IXR5eXaSL>=7YCSbmt*>UO*=hqdM{TG!QX8weYM$CeZK^g?^VI^i
zxmu_esV&r&YAdz1+D2`wwo}`y9n_9$C$+O$taeems@>G?Y7e!i+Dq-N_EGz){nY;I
z0Ck``NFA&WQHQF-)Zyv~b)-5<9j%U0OVqLIICZ=_L7k{hQYWi-s8iIb>NIt_IzyeQ
z&QfQqbJV%&JaxXhKwYRVQWvXB)H~Is>N0h?x<Xy4u2NU4cd2))Yt*&sI`tlPy}Ci&
zsBTg>tM{r~)ce$}>NfR$^#S!kb-VhI`mp+lx<lQmKB_*ZKCbRkpHQDvpHg?LPpi+U
zd(>yu=hVIG^Xd!gi|Ri0CG}->zj{D@MSWF0sJ^BiQeRi!P!Fp|)Hl_))VI~6>O1N&
z^|<=3dP03qJ*mF0exQD+ex!b^o>D(iPphA*pQ)d#U#MTIU#VZK->BcJ->GNRv+DQi
z59*KVPwLO=FY2%AZ|d*rAL=>vyjrT3sSZ_FFKC>GG^`PgYP=?Bq9$pwrf90BX)am~
z%~f;L+%*r)Q}fciH6P7a^V9sb04-3fsRe1Zv|uenvuL4Om=>;CwFu3o)z<7<9W7Fe
z(xSB(Emn)u;<W@VQA^U2wG=H?OViS|x>|--Ps`NmYgt;h)<DbA8fuNS##*kHr!~=<
zYR$BKtw3w86>3FV3$3NrN^7mP(b{V5wDwvDt)tdS>#P-PU9_%RH?6zYL+h#a(t2xs
zw7yzDt-m%v8>kJ^25UpKq1rHQxHdu?sg2S`Yh$z$ZLBs<8?Q~!CTf$k$=V&-6m6<D
zO`ERG&}M40wAtDmZLT&?o3Aa<7HW&M#o7|>PHm~SOk1w4&{k@zwAI>O+TGe3ZLPLW
zyGL8EZO}Gqo3zc^z1kM-KJEX=`U<Evny%p%m#n*co_c{&cXxMhfD}?FP^9ke?(XjH
z?(XjH?)vX;Ano`5=fK>1XXfhoY_eJGSmIdfSms#nSm9XdSmjvlSmRjhSm#*p*x=ac
z*yPyk*y7mg*yh;o*x}ge*yY&m*yGsi*yq^qIN&(wIOI6&IN~_!IOaI+IN><yIORC)
zIO90$IOjO;xZt?xxa7F(xZ=3#xaPR-xZ$|zxaGL*xZ}9%xaYX<c;I;Gc;tBOc;a~K
zc;<NSc;R^Ic;$HQc;k5Mc;|TU_~7{H_~iKP_~Q8L_~!WT_~H2J_~rQR_ygnsasqyU
zKM()}0zp795CVh(VL&+G00004AOHps00l4r2MB-!D1ZhSfCV^!2LwO_BtQlfKm{~F
z2MoXo{0HO$aszpQyg)u6KTrTD2t)vpKon32hz1G+MS!9}F`zh50w@WT0!jmAfU-b2
zpgd3ks0dU7Dg#x3sz5cMI#2_s3Dg2=19gD9Ks}&7&;V!%Gy)m}O@O9AGoU%p0%!@e
z0$KxYfVMz8zy-tru|OQ)2HFGhKthgffCuORBmzl5M<5wU0aAfZKpKz^WB{2!XP^tv
z73c<Z2YLWKfnGpwpbyX&=m+!%1^@$rLBL>O2rv{F1`G#A03(4>z-V9$FcugGj0YwF
z6M;#<WMB#~6_^H02W9{>fmy(8U=A=Bm<P-U761!@MZjWU39uAc1}q0w04sr2z-nL(
zuohSctOqs#8-Y#0W?&1j71#!B2X+8EfnC6EU=Oet*az$f4gd#%L%?C+2yhfQ1{?=Y
z04IS{z-izNa27ZRoChud7lBK_W#9^M6}Sdm2W|j2fm^_B;0|yXxCh(^9sm!4N5Es?
z3Gftn20RB|055@8z-!<Q@D_Lnyazr2AAwK6XW$F)75D~x2YvuQfnUIH;18Gs%nAB|
z{$KzY2nK<{U<eorhJoRr0|Y=2gg_WXKorD493(&zq(B;EKo;ac9uz<klt39&Ko!(L
z9W+2E_#c=H%njxN^Md)n{9pmFAQ%Bgf>B^0Fd8fj76FTb#lYfV39uws3M>tl0n38r
z!17=Pup(FqtPEBGtAf?Q>R=79CRhus4b}ncg7v`qU<0rr*a&P4HUXQ0&A{eh3$P{F
z3TzFw0o#J@Ko=MT#)5I68*C58g9)Gq>;NW$Nnl4X8B76F!A@Wrm=0!unP6wI3)mIx
z26hK~fIY!pU~jMw*ca>v_6G-m1HnPyU~mXH6dVQ)2S<P-!BOC7a11yW90!gECx8>d
zN#JB~3OE&<22KZOfHT2a;B0UXI2W7;&IcEO3&BO;VsHt#6kG-_2UmbA!ByaDa1FQ?
zTnDZPH-H<#P2gs53%C{B25tv;fIGom;BIgaxEI_9?gtNm2f;(&Vekle6g&nV2Ty<}
z!BgOA@C<ksJO`c!FMt=pOW<Yj3V0Q~23`kmfH%Qg;BD{@co)0}-UlCm55Y&^WAF+1
z6nq9g2Va0M!B^mG@D2DDd<VV<KY$;>PvB?p3-}fM27U*BfIq=s;BW8`lmp5M`9c0r
z02BxXLBUW66bgkw;gACYAP|Be7(yTv!XO+XAQGY=8e$+8;vgOpAQ6%v8B!n>(jXl&
zASd)6lncrY<$>}-`Jntz0jMAp0YySlP$4K9Dhw5YibBPp;!p{wBvcA24V8h)Lgk?H
zPz9(WR0*mKRe`EP)u8H74X7qm3#tv(f$Bo_p!!e)s3Ft{Y78}jnnKN>=1>c$CDaOP
z4Yh&VLhT?I6a&RVagZBo55+?XkO%4jB|=G1M<^Lefl{GPP#TmDWk8uwXQ&I*73v0c
zhk8Igp<YmLs1MW^>Ie0Q20#O$LC|1m2s9KL1`UTsKqH}1&}e83G!_~MjfW;c6QN1a
zWM~RB6`BT3hh{)Cp;^#uXbv<Nng`8?7C;N3MbKhs3A7Yi1}%qHKr5kD&}wK6v=&+i
zt%o*18=+0mW@rnv71{=Ehju_ap<U2!Xb-d(+6V224nPN?L(pO92y_%W1|5e^KqsM7
z&}rxlbQU@Xorf+!7okhgW#|fY6}kpphi*VOp<B>x=nixjx(D5d9zYMFN6=&F3G@_t
z20e#fKrf+J&}--o^cH#ty@x(PAE8gsXXp#`75WB!hkigmp<mE%=ntF&&I$X${%`;s
z2nWHza0na<hr!{n0|sCahF};*U=+q+9425AreGRoU>4?J9u{B`mS7oHU=`M29X4Pm
z{2!bP&JE{*^TPSy{BQxdARGZl!clM`I2tYt7lDhy#o*#_3AiL&3N8(oF+ZhN4lWN@
zfGfh4;L30nxGG!?t`66LYr?hQ+Hf7XE?f_;4>y1t!j0g@a1*#G+zf6Gw}4y1t>D&h
z8@Mgp4tBvYa4Z}LyW#e5Je&Y~;0|yioCJ4-li?IN748J5!Rc@YoC$Y^yTD!HZg6+F
z2iz0x1^0&gz<uF<aDR9JJP;lP4~B=pL*ZfYaCihf5*`JQhR48T;c@VIcmg~To&-;Z
zr@&L;Y4CJ-20Rm<1<!`(z;oew@O*dyybxXlFNT-EOW|eka(D&25?%$bhS$Jr;dStO
zcmuo<-UM%kx4>KBZSZz@2fP#B1@DIUz<c3+@P7CJd=NeaABK;>N8w}eargv$5<Uf=
zhR?uf;dAhL_yT+pz64)}ufSK~Yw&gW27D8~1>c76z<1$$@O}6J{1AQwKZc*cPvK|q
zbNB`P5`G20hTp(%;dk(R_yhbA{se!9zrbJNZ}4~c2mBNM1^<TsAUVu$P5PN{xC%f5
zksu@(2|+@UFeDstAOHd)5CS6zf+84#BLqSs6hb2m!Xg~PBLX5K5+WlCq9PiiBL?C`
z{zGyhxsg0bUL+rqA1QzoL?Vz#BnmOV5RVi_iXcUiVn}hM1X2<yg_K6hAZ3wqNO`0J
zQW2?yR7R>GRgr2)b)*JT6RCyNM(QASk$Omdqyf?pX@oRJnjlS)W=M0S1=12}g|tT6
zAZ?L$hzp59Vv#t+jkHJNkp#qpbU+f3B%~vfjHDo`NGBu>Nk=k}Or$f?1?h@(L%Jh9
zke)~{q&LzB>5KG3`Xd97fyf|aFfs%giVQ=BBO{QJ$S7nqG6oroj6=pF6Of6>BxEu&
z1(}LWL#87$keSFVWHvGfnTyOr<|7M`g~%dgF|q_%iY!BxBP)=V$SPztvIbd;tV7l#
z8<362CS)_R1=)&hL$)J3ke$dbWH+)0*^BH$_9F+7gUBJ|FmePriX20ZBPWoP$SLGB
zat1kzoI}nd7m$m{CFC-41-Xh`L#`t?kekRY<Ti2#xr^LG?jsM7hsY!3G4cd?iabM}
zBQKDb$SdSE@&<W}yhGk2ACQm8C*(8o1^J46L%t(Fke|pe<TvsM&4K1b{ZM~201ZTg
z&|owK4MoGyaMXbUD2PHRj3OwCVknLhD2Y-ijWQ^Uawv}qsEA6aj4G&#YN(DHs1yAU
z&4uPh^PqXrd}w~O09p`@KqJv8v=C~3Ya1<s7DbDp#nBRINwgGN8ZCpCMa!Y((F$lq
zv=Ukwtzv$3wHjI-t%24=YoWE#I%r+A9$Fu5fHp)Mp^ecdXj8Nq+8k|xwnST@t<g4U
zTeKbOLSxWaG!Av6?a_EN0rj9A&_px|?T99$DQGI%2~9)O(F`;b?TmIoyQ1CD?r0CR
zC)x|`jrKwNqW#eR=m2yeItU$%4nc>a!_eXA2y`Sm3LTA(LC2!w(DCR5bRs$los3RF
zr=ru)>F5k}COQk9jm|;mqVv%C=mK;hx(Hp2E<u-~%h2WM3Unp93SEt^LD!<|(DmpB
zbR)V6-HdKQx1!t7?dT44C%OyWjqXABqWjSO=mGQ~dI&v?9zl<y$I#>G3G^g-3O$XU
zLC>P+(DUd8^dfo*y^LN#ucFt`>*x*iCVC6Kjov};qW94I=mYd2`UriDK0%+N&(P=S
z3-l%W3Vn^fLEob9(D&#E^dtHS{fvG=zoOsJ@8}QoC;AKhjsC%MU^y{A%pVKD0<j?T
zJ0u}kC>Dl=V-5_!Kn%iQ48c$g!*GniNQ}a0jKNrp!+1=<L`=eDOu<x4!*tBRoY;R@
zE-W{e2g{4)!}4PVu!2|w7Kue+g|KL>FjfRBiWS3(V<oVXSShSDRt77JmBY$o6|jm}
zC9E=51*?ix!>VI7u$ovctTt8$tBcjc>SGPChFBx4G1dfYiZ#QUV=b_jSSzeG)&^^f
zwZmLk3>J&UVQ#EF7LO%h9;^eFh$Ueiv1BX-OT{{2X;?azfn{Qyu`XCwtQ*!H>w)#e
zdSSh>K3HF@AJ!imfDOb3VS}+D*idX3HXIv)jl@P_qp>mASZo|N9-Dwo#3o^ru_@S8
zY#KHln}N;5W?{3jIoMom9yT9afGxxpVT-XP*ivj6wj5i5t;AMgtFblMT5KJ*9@~Iz
z#5Q4@u`SqEY#X*6+kx%Gc451*J=k7sAGRMmfE~mRVTZ9J*iq~lb{so_oy1OIr?E5G
zS?nBk9=m{D#4cf%u`AeB>>73*yMf)rZeh2vJJ?<99(EslfIY+>VUMvV*i-Bo_8fbG
zy~JK&udz4STkIY79{YfO#6Dr4u`k$H>>KtS`+@z$eqq0{KX?v2C+>&);{kXe9)t(u
zA$TYrhKJ)09Kb;w!eJc2Q5?f@oWMz(!fBkrS)9XpT);(K!ev~+Rb0b$+`ygqe|RoD
zH=YO2i|51h;|1`7cmy7aN8yF=XuL391TTsg!;9l3@RE2byfj`0FN>GM%i|UBig+cw
zGF}C*idVy{<2CS_crCm(UI(v>*Td`M4e*9|BfK%*1aFEr!<*wR@RoQhyfxkiZ;Q9X
zU3d&0i^t(^ygeR|C*U5u1D=Q{;T`d0JOxk1JK<?~I-Y@N;+^p>cvrj|-W~6O_r!bQ
zz41PHU%VgQA0L1Z#0TMn@gew7d>B3)AAyg=N8zLKG5A<~96lbOfKS9H;gj(x_*8rv
zJ{_Nd&%|fpv++6jTznorA76kk#24X<@g?|Dd>OtRUxBa0SK+JiHTYV59ljplfN#V%
z;hXU-_*Q%yz8&9z@5FcEyYW5vUVI<EA3uN}#1G+z@gw+A{1|>5KY^dbPvNKWGx%Bj
z9DW|ZfM3Kf;g|6%_*MKGejUGo-^6d>xA8mpUHl$?AAf*9#2?|0@hA9G{2Bfne}TWm
zU*WIuH~3rp9sVBwfPch4;h*s@_*eWJ{vH2;|HOaczwtjr4k9PvNB9!~L?97F1QQ`d
zC=o`46Al6(KmsCQ0wGWWBXEKsNP;40f+1LfBX~j}L_#8DLLpQ_BXq(boWy@bE+RLP
zhsaChBk~gkh=N1}5lKW5g@|aPFj0gkN)#iC6D5d}L@A;)QHCf>lq1R$6^M#NC89D>
zg{VqYBdQZMh?+z#qBc>7s7ur%>JtsjkKs2W8WT;3rbIKMInjb>Nwgwb6K#mLL_5Mo
z#1OGW9N{L~6Y)d>;UPK@i9{07kw_*|h*Y8zkw&Bw8AK-0ndm}vCAtyai5^5xq8HJd
z=tJ}+`Vsw!0mMLJ5HXk-LJTE_5yOcQ#7JTkF`5`dj3veq<B18xL}C&#nV3RMC8iP6
zi5bL9Viqx*m_y7Z<`MIW1;j#P5wVz9LM$bg5zC1c#7bfnv6@&ztR>bF>xm7-Mq(4O
znb<;XCAJaUi5<jFVi&QS*hB0k_7VGu1H?h%5OJ6|LL4QI5yy!W#7W{5ahf<ooF&c?
z=ZOo%MdA{1nYcn+C9V<Ii5tXC;udk6xI^3}?h*Hi2gF0-5%HLKLOdm&5zmPi#7p8;
zj=eed5wD3i#9QJW@t*iVd?Y>*pNTKTSK=G-o%ligBz_UUi9cixGAHRr`jY`<AQ?mk
zlObd%8AgVa4iX?i5+Y#|AyE<|agrcO^V=#k$&f6`kvu7oA}NtFsgNqEkveIRPVzr8
z7nz&PL*^y(k@?92WI-~5j3lGTLS!^qm@GmTC5w^8$r5BqvJ_dGEJKzh%aP^D3S>pH
z5?Pt7LRKZKk=4l>WKFUbS(~gw)+Ota^~nZgL$Z<i^@}ECQ?eP^oNPh1BwLZK$u?wL
zvK{FnW5`%Cj&zgl$#^n>^pG9ML^6r&NG6jhWGdN-Oe53D3^J4KOm-o=lHJJeWDl|@
z*^BH=_96R{{mB000CFHXh#X7~A%~K~$l>G&awIv598HcP$CBg7@#F+@A~}hiOim%E
zlGDiP<P35qIg6Z4&LQWL^T_$+0&*d_h+IrAA(xWN$mQe;awWNnTurVa*OKeV_2dR}
zBe{v(Ol~2!lH17b<PLHtxr^LQ?jiS*`^f#|0rDVuh&)UlA&-*B$m8S*@+5hRJWZY<
z&ywfJ^W+8cB6*3tOkN?clGn)V<PGvBd5gSF-XZUj_sIL?1M(sHh<r>wA)k`Z$miq>
z@+J9-d`-R~-;(dh_v8oiBl(H^OnxE1lHbVh<PY*E`HTEb{-JVEIVnHNp9-J?sURwt
z3ZX)&F!Oy44ho<^3Zh^Np->8=aEdU$tVB^X#ZWB8Q9LD3A|+8WrBEuRQ95N%PU=4@
z7nPgJL*=FNQTeF?R6#0&ilm~bLR2(Wm?}aQrHWC-sS;F4suWe4Dnpf}%2DO13RFd^
z5>=V1LRF=zQPrs$R86WDRhz0q)urlD^{EC_L#h$gm}){brJ7OAsTNdAsuk6mYD2Z9
z+EFelhKi-)C^yxfil-7N57mK6q>`wPR5F!9rBa=!G%B6Spfah>R2Ql%)s5;-^`LrE
zy{O()AF40akLphipaxQdsKL|_YA7{~8cvO%MpC1w(bO1fEH#cAPfegEQj@63)D&te
zHI151&7fvdv#8nB9BM8#kD5;{pcYb#sKwM0YALmhT28H?R#K~|)zlhlEwzqXPi>$!
zQk$sF)D~(hwT;?N?Vxs2yQtmN9%?VOkJ?Wipbk=psKe9|>L_)LI!>LSPEx0+)6^O2
zEOm}LPhFrcQkSU9)D`L~b&a}C-Jot#x2W6H9qKN1kGfAipdM0>sK?Y3>M8Y%dQQEd
zUQ(~9*VG&8E%lCiPko?1QlF^L)EDY2^^N*Y{h)qQzo_5TA36t}llG(i=>R&A4x)qU
z5IU3&qr+(j4bUJB(J+nBD2>rLP0%Dw(KOA_EX~n8Ezlw@(K4;jDy`8vZO~5oKROqk
zo6bY$rSsAG=>l{?I)aX*qv%3(G+mf3LKmfr(Z%T!bV<4tU79XKm!-?m<>?A^MY<AQ
znXW=trK{1^=^AuRx)xoVu0z+Q>(TY;26RKZ5#5+>LN}$G(aq@=bW6Gw-I{Jgx24<B
zE;@#erQ>Kf-JXu86KD_Jflj28=#F$UokFM5o#-?=oz9>$>CSW)x+~p{?oRihd(yq=
z-gF<jFWrysPY<96(u3&1^bmR|J&YbskDy1=qv+A}7<w!{jvh}>peNFk=*jdHdMZ7Q
zo=(r8XVSCi+4LNGE<KN)PcNVs(u?TD^b&e0y^LN?ub@}btLWAA8hS0gj$Ti1pf}Q+
z=*{#NdMmw+-cIkJchbA)-Si%MFTIc6PamKU(ue57^bz_feT+U%pP*0Dr|8r48Tu@J
zjy_LcpfA#w=*#pK`YL^mzE0nuZ_>Bu+w>j!E`5)_Pd}g^(vRrJ^b`6i{fvH2zo1{z
zujtqG8~QE%j($&npg+=|=+E>Q`YZj7{!ag(f6~9`-}E0Q2a}WWWBi!_CXfkYf|(E|
zlnG<P83zL}AOkTlgD@zAF*rjoBttPY!!RtvF+3wMA|o*}qcAF?F*;)~PUb%*7n7UG
z!{lZ1G5MJSOhG1siDaUfLQFJMm?^>(Wr{JynG#G%rW8|}DZ`Xy$}#1c3QR?&5>uI}
z!c=9dG1ZwGOiiX1Q=6&7)Me^1^_d1tL#7eam}$Z^WtuU~nHEe-rWMngX~VQ-+A%IB
zhKXh37&p_NiDwcR57U83WRjSUOfr+gq%xhDG$x(NU^1D`Oc$mr(~arQ^k8~2y_nui
zAEqzUkLk}0U<NXSn8C~tW+*d^8P1GgMlz$A(aacTEHjQ7&rDz@GLx9e%oJuSGmV+f
z%wT3RvzXb;9A+*vkD1RbU=}iqn8nNzW+}6bS<b9rRx+!Y)yx`ZEwheU&um~eGMkvq
z%ob)VvyIu#>|k~>yO`a~9%e7IkJ-;0U=A{en8VBw<|uQFInJD5PBN#M)65y>EOU-I
z&s<<GGMAXk%oXM;bB(#q++c1px0u_^9p)}`kGao0U>-7$n8(Z$<|*@xdCt6GUNWzk
z*UTH{E%T0f&wOA$GM|{w%opY>^Nsn={9t}EznI_5A2tV@lQmxv#Rjl}Y!DmFhOnV*
z7#q$ySbzmth=o~%MOlo+S%M{5ilteGWm%5pS%DQ<iIrJ}RauSIS%Y=5|FOB)+-x2;
zFPo3e&lX?{vJq?~8^so4quIi25w<8>j4jTVU`w*4*wSnnwk%tYEzee9E3%c?%4`+3
zDqD@M&emXSvbEUSY#p{PTaT^JHeegFjo8L)6SgVajBU=gU|X`S*w$<twk_L^b+IvQ
zEE~tV+4gKao4|V54s0Tu#CBwp*%UUF?Zl?B>1+m@$#!PDuwB`1Y<IQ?+mr3Z_GbIA
zec66&e|7*nkR8MhW{0pt*<tK(b_6?;9mS4j$FO7BaqM_@0y~kN#7<_Xuv6J->~wYp
zJCmKo&SvMZbJ=<9e0Bl5kX^(sW|y!_*=6i<b_KhVUB#|u*RX5Zb?ka}1G|yk#BOG{
zuv^(}>~?ksyOZ6;?q>I}d)a;Le)a%+kUhj6W{<E(*<<W+_5^#9J;k18&#-6NbL@Hc
z0(+6Y#9n5vuvgh@>~;1Ady~Dz-e&KxciDUFef9zSkbT5HW}mQ6*=Ou?_67TreZ{_J
z->`4lckFxi1N)Kv#C~SKuwU74?05DD`;+~}{$~GhIk=phALq{naDiM97tDolp<Eaj
z&N(=M138F;IfO$wjKevCBRPtrIfi37j^jCj6FG^KIfYX>jng@Ub8`Q2xwzb19xgAJ
zkIT;$;0kgPTqGC872=|~!dwxqC|8Ut&XwRwa;3P^Tp6w`SB@*sRp2UemAJ}W6|O2*
zjjPVp;A(QUxY}GDt}a)PtIsvy8gh-e##|GwDc6i^&b8oLa;>=5TpO+}*N$^>F<dMc
z$GN%oTs)V+dAJT-BA3K<<dV4*E|u%VrE%$82A9co=DKiQxo%u{t_RnX>&5lv`fz=@
zeq4WU05^~u#0}<#a6`Fa+;DCLH<BC0jpoL1W4UqMcy0nWk(<O#=B98{xoO;VZU#4#
zo5juM=5TYldE9(%0k@D_#4YBQa7(#m+;VOOw~|}Mt>)HnYq@pYdTs-^k=w*==C*KK
zxozBbZU?uM+r{nX_HcW-ecXQT0C$i(#2x02a7Vdg+;Q#%cal5Bo#xJPXSs9SdF}#t
zk-NlQ=B{v8xog~Y?gn?0yT#q+?r?Xxd)$5Q0r!x5#69Moa8J2s+;i>)_mX?Xz2@F<
zZ@G8ed+r1Gk^97b=Du)Wxo_Ne?g#gi`^Ej{{_r{YoV*|J&j;{<d=MYZhw!0%7$43%
z%(wS}JjBC1!lOLK<2=EWJjK&I!?Qfc^Sr=|yu{1A!mGT->%74``TzJ_d~QAupO??a
z=jRLX1^Ea*l8@pG@zH!?z6f8GFUA+=OYkN6QhaH?3}2Qn$Cu|T@D=$=d}Y20UzM-M
zSLbW+HThb6ZN3g)m#@dy=Ns@1`9^$Wz6sxyZ^k$0TktLUR(xx|4d0e;$Gi9#K9-N;
z-F$mKo=@OCd<Q;}PvSfB$$Sc*%6H<^_;fyl&*VGvUHGniH@-XHgYU`r;(POb_`ZBU
zzCS;JAIJ~l2lGStq5Lp@I6s0P$&cbk^JDn2{5XC*KY^dfPvR%@Q~0U;G=4figP+OI
z;%D=7___Q%em=i|U&t@w7xPQ_rTj8}IlqEm$*<y9^K1CE{5pO;zk%P#Z{j!eTllT~
zHhw$5gWt*T;&=0V_`Uo-em{SJKgb{A5A#R(qx>=cIDdja$)Dm+^Jn<8{5k$Se}TWq
zU*a$GSNN;^HU2t(gTKk&;&1bJ_`Cc){yzVJf5<=LAM;Q6r~EViIsbxx$-m-X^KbaK
z{5$?V|AGI=f8sy$U-+;5H~u^Sga66@;(zmhgd9Rn!B6lP0)#*zNC*}}gis+&2p1dz
zAb<iSzyczm0w&-BA&>$k&;lc{0w?f-Ac%q_$burMf+pyKAvlHqgj_;yA&-z($S33%
z3J3*-2q9945(){?LSdnZP*f-;6c<VeC52K#X`zfzRwyTw7b*x9g-SwYp^8vds3uew
zY6vxjT0(81j!;*qC)5`j2n~fsLSvzc&{Sw9G#6S3ErnJ>YoU$MR%j=<gcu=Kh!fmG
zdm&y(5IjN$AyG&YIts}`ijXRF64HcpAw$R%ItyKdu0l7VyU;`EDfAM03w?yXLO-Fu
zFhCe63=#$lLxiEiFk!ebLKrEG5=IMSgt5XnVZ1Owm?%sVCJR%9slqg2x-dhSDa;aP
z3v-0I!aQNVus~QSED{zAON6DuGGV!}LRcxR5>^XqgtfvtVZE?H*eGlgHVa#Xt->~8
zyRbvpDeMw<3wwmU!aiZYa6mXH91;!-M}(uoG2ysyLO3a$5>5+egtNjq;k<A`xF}o_
zE(=$LtHL$mx^P3dDclln3wMOO!ad=>@IZJdJQ5xYPlTt!GvT@LLU<{>5?%{$gtx*w
z;l1!d_$Yi5J_}!jufjLsyYNH!Df|+C3xC8MVouRd^cMrfKru)R7DL2PF-!~>9U>rt
zA|%2hBBCND;vylEA|=uyBeEhV@}eM$q9n?qBC4V$>Y^b!#s9=yVs0^ym{-gv<`)Zy
z1;q$4Qj8J{iP2(Vv4~hyEG8BgONb@KQetVbj96AICzcm0h!w?3Vr8+4SXHbhRu^lC
zHN{$DZLyA6SF9)27aNET#YSRdv5DAJY$i4rTZk>iR$^<hjo4OfC%VKKF;<Kd-C}z&
zUQ7@@Vh1r%OcFba$zqC_Ds~dn#B?!3%oIC|UBs?pH?h0eL+mN`5_^k%#J*xbvA;M#
z94HPF2a7|*q2e%cxHv)_DUK3Hi(|yG;y7`<I6<5!P7)`JQ^cv_G;z8(L!2qj5@(BZ
z#JS=;alW`fTqrIQ7mG{8rQ$Mixwt}HDXtP%i)+NS;yQ7?xIx?~ZW1?(Tg0v6HgUVS
zL)<Cu5_gMx#J%D^ald##JSZL#4~s{{qvA2~xOhT5DV`Efi)X~M;yLlWctN}<UJ@^h
zSH!F0HSxN5L%b>85^sxl#Jl1>@xJ&#d?-E=AB#`Kr{Xj5x%fhSDZUb4i*LlY;ydxZ
z_(A+AeiA>6U&OECH}SjpL;NZJ5`T+-q#ROC$xrf^0;E7GND7uhq);hL3YQ!bAb}Dj
z!4e{&5+>miA(0X#(GnxE5-0JJAc>MB$&w<ek|ybrAvvZ0q+C*NDUXy_$|vQQ3P=T|
z2q{vEk_t)DQemlxR8%S^6_-j#C8bhQX{n4<Rw^fzmnujVrAks|sftupswP#JYDhJu
zT2gJPj#O8wC)Jl4NDZY%Qe&x!)KqFFHJ4gQEu~gcYpIRYR%$1?q!=kyij&+@dnsN@
zkUUZcDN#z2I!eh>ij*pKlG3DfDMQMXI!j%ou2MItyVOJKDfN<iOMRriQa`D`G(Z|C
z4Uz^+L!_b7Flo3nLK-QJl158oq_NUCX}mN+nkY?@CQDPKsnRrQx->(YDb12*OLL^T
z(mZLtv_M)YEs_>XOQfaJGHJQALRu-Ul2%J=q_xsIX}z>T+9++3HcMNit<pAWyR<{v
zDeaPWOM9ff(mrXwbU->N9g+@9N2H_DG3mH;LOLm(l1@u!q_fgF>AZA7x+q<eE=yOW
ztI{>;x^zRjDczE8OLwHZ(mm<E^gwzjJ(3<vPo$^PGwHeXLV78^l3q)1q_@&L>Amzp
z`Y3&pK1*MuuhKW^yYxf)DgBauOMm1Xa!%QNFNz!>2g*TmupA<X%3*T2?2rK&lpz_G
z5gC;+8J7u}lqs2(8JU$inU@7wlqFe~6<L)vS(gpjDgP(ul5@*><h*h|Ilo*$E+|LH
zk#dw=NRE~Z%SGg(axuBMTtY4>my%1%W#qDQIk~)CL9QrQk}Jzq<f?Ktxw>3Kt|`}&
zYs+=yx^g|azT7}=C^wQD%T45_ax=NP+(K?Cw~|}SZRECcJM(Q5F><UNC%fhLa=e@%
zd*lvsqMRgml#}HYIaTf?r^)GZhMXyPmb=JZ<!*9!xrf|S?j`q@`^bIeesX_#fILth
zBoCH{$V25}@^E>CJW?JdkCw;CW94!3czJ?6QJy4EmZ!*5<!SPCd4@bwo+Zzg=g4#A
zdGdUDfxJ*&Brlei$V=sA@^X2Fyi#5zua?)yYvpzFdU=DqQQjnPmbb`T<!$nId564H
z-X-sr_sDzYee!<!fP7FsBp;TK$VcU4@^Sfud{RCopO(+aXXSJ9dHI5TQNAQ!maoWH
z<!kbF`G$N`z9rw5@5p!Md-8qxf&5T@BtMp)$WP^G@^krx{8D};zn0&~Z{>ILd-;R>
zQT`-<mcPhf<!|zL`G@>d{w4pG|0p?>oQj{~uLLN8N|5<04IxUX5~hSJ4h2v^1yW!I
zQBVa_aP#-*NQF{pg;7|AQ+P#CL`70$MNw2mQ*^~poXUSnE+w~;N6D+?Q}QbXl!8ix
z5~)Nfg_LNeuu?=RsuWX-D<zbYN-3qZQbsAOlvBzp6_kofC8e@bMX9P(Q>rU9l$uH{
zrM6N>sjJje>MISDhDsx)vC>3osx(uYD=n0kN-L$c(ne{kv{PJ4j1sHFDQ=~`60amE
z9;Jhls3a*Jm1HGFNmV*2X-c}1p=2tZl`cwGrJK@S>7n#gdMUk?K1yGupVD6$pbS(7
zDT9?E%1~vPGF%y<j8sM`qm?nrSY@0tUYVdwR3<5tl_|<pWtuWwnW4;7W+}6kIm%pR
zo-$uqpe$4tDT|dQ%2H*SvRqlAtW;JhtCcm%T4kNGUfG~*R5mG_l`YCvWt*~H*`e%I
zb}74+J<48XpR!*$pd3^VDTkFK%2DN*a$Gr~oK#LJr<F6xS>>E^Ub&!LR4yr(l`G0s
z<(hI`xuM)tZYj5wJIY<<o^oG#pgdF_DUX#W%2VZ;@?3eLyi{H(ua!5-TjibdUiqMW
zR6Z%6l`qOy<(u+d`Jwz&eks3|KWYv&r|PHrs{v}D8f3m4FhmVi!_;uqp#mzXLMp5x
zDym{Ct`aJ#QYx)7DywoTuL`QDN~)|Xs%pNONmmWkX}*XwmzrD6qvlofsrl6cYC$zZ
zjZ~x5LTa>HSS_L!Rg0;`)e>q+wUk;~Eu)rI%c<qn3Tj2Ql3H1<qE=O_snyjQYE8A4
zT3fB7)>Z4N_0<MyL$#6GSZ$&<Rhy~J)fQ??wUydhZKJkT+o>)!MvYbDRJYn*jaL&?
zkJ>>^RFl+>YO<Q5rmCIPG&Nn#P&3ueY8SPu+D+}Q_E3AOz0}@nAGNRAPwlS`PzS1m
z)WPZyb*MT_9j=a0N2;UL(drm=tU68|uTD@Ws*}{o>J)XVI!&Ff&QNEnv((w@9CfZb
zPo1wWP#3C;)Wzx&b*Z{cU9PTBSE{Sj)#@5`t-4NKuWnE`s+-i!>K1jYx=r1#?ofBC
zyVTw49(Av}Pu;H`P!Fny)Whl#^{9GGJ+7WmPpYTX)9M-Zta?s8uU=3us+ZKu>J{~>
zdQH8q-cWC<x76F}9rdnyPra``P#>y~)W_-*^{M(yeXhPxU#hRv*XkSft@=)VuYOQJ
zs-M))>KFB^`c3_={!o9aztrFAA1#NLQ}fgOwE!(p3(|tM5G_;-)50}}256uLX|VZ*
zYgEHDTq876qcmD$G*;s@UK2D?lQdaVG*#0yT{ASN_MetZ%dO?n@@o0C{8|C6pcbJ;
zYEfDtEm|wA714@n#kAsD39Y17N-M3E(aLJ&wDMX7t)f;*tE^Sgs%q7=>RJu0rdCU<
zt<}-$YW1}GS_7@2)<|otHPM=C&9vrP3$3NrN^7mP(b{V5G?x~m#cFYyTWhbyYYCc1
z>!2lSNm@rOSxeDUwN6@^mab)JnObM9i`G@^rghhPXg#%FT5qk7)>rGN_16Yy1GPcg
zU~PytR2!xZ*G6a~wNct=ZHzWn8>fxeCTJ72N!ny>iZ)f7rcKvoXfw50+H7r(HdmXc
z&DR!a3$;bsVr_}GR9mJk*H&mNwN=_`ZH=~8Tc@qpHfS5QP1<H{i?&tUrft`DXgjrC
z+HP%+wpZJy?bi-y2em`mVeN=^R6C{}*G_0BwNu(@?TmI-JExu3E@&6EOWI}aigs1I
zrd`)=Xg9T6+HLKQc2~Qn-Payy54A_yW9^CdRC}g9*IsBZwO86}?Tz+Ud#AnEK4>4c
zPugegi}qFfrhV6bXg{@I+HdWTo<q;6`|19AfF7s^>A`x49;%1w;krWybWn$MSVweJ
z$8=mLbW*2uT4!`t=X72dbWxXdSyyyb*K}Psbf^BGo=eZI=h5@(`SkpH0llCep-1Xb
zdLcbpFRT~Qi|WPn;(7_aq+Uudt(Vcu>gDwEdIi0rUP-U4SJA8L)%5Cm4ZWsbORufh
z(d+8<^!j=Oy`kPnZ>%@bo9fN<=6VagrQS+!t+&zJ>g{xw9;3(Vak^V?ugB{Nx<~Jz
zC+bOhM?G0j(NpzKdYYcDXXu%FXT6KwRqv*E*L&za^<H{!y^r2k@2B_I2j~O!LHb~Q
zh(1&wrVrOg=p*$}`e=QOK2{&6kJl&Y6ZJ{@WPOT0RiCC$*JtQ6^;!CCeU3g?pQq2)
z7w8N1MfzfWiM~`{rZ3l5=qvSA`f7cRzE)qSuh%!|8}&{4W_^pkRo|v>*LUbU^<DaI
zeUH9Z->2`_59kN=L;7L;h<;Q*rXSZ&=qL44`f2@)epWxHpVu$w7xhc}W&MhNRllZR
z*Kg=I^;`OF{f>TDzo*~VALtMDNBU#^iT+f7ra#wT=r8qG`fL4-{#Jjdzt=zLAN5cA
zXZ?%*RsW`c*MI0g^<VmL{g08u$Z7Z){ziZiXapI-Mu-t=gc;$6!vGA>fDG6`4Aj63
z+#n3npbXkz4A$Tb-VhAYkPO*S4AsyK-7pNN@t={)$Zg~?@*4S!{6+zzpb=q28c{|e
zBiblz6fue##f;)c38SP@$|!A=G0Ga{jPgbWqoPsCsBBa*sv6ad>P8KtrcukNZPYR9
z8ug6&Mgyav(a30QG%=bQ&5Y(o3!|mc%4lu0G1?mK43`mO#2Rsi+h}jZ8wrNT=wKuo
zNk&H_*+?-`jZQ|Ik#1xdnMP-$i_z8SW^^}t7(I<%MsK5!(bwo_^fv|=1C2q(U}K0e
z)EH(AH%1sEjZwyEV~jD@7-x((CKwZqNycPjiZRugW=uC`7&DDo#%yDbG1r)9%r_Po
z3ynp_Vq=N1)L3RLH&z%cja9~KV~w%aSZAy^HW(X?O~z(pi?P+%W^6Zh7(0z!#%^Pe
zvDesV>^BY=2aQ9<VdIE#)Hr4wH%=HQjZ?;H<BW0EIA@$UE*KY$OU7m6igDGrW?VOJ
z7&nbu#%<${ao4zK+&3N=4~<90W8;bO)Ocn*H(nSojaSBN<BjpwcxSvfJ{TX3PsV5C
zi}BU?W_&k(7(b0)#&6?~Glw&$)6ePe3~&ZIgPg(65ND_}%o*-<H~}Z<gq*MwaiUJl
zi8~1=>7<;rlX0?6&dECkr|6WNvQu%YPR*%14X4w5uW2r4Zf726US~dMerEw^L1%<B
z(i!C}<cxL}b{26Kbry3Lcb0ILbe3|Kc9wCLb(V9McUEv#bXIa!c2;p#byjm$ch+#$
zbk=g#cGhv$b=Gs%cQ$Y~bT)D}b~bS~bvAQ0ceZf0bhdJ~cD8Z0b+&W5oH5Q=XPndR
zZ10SBCOAFL4$eeplCz^T*_q-@b#`*5In$jP&P-=#XBTHzXE$eeXAfsjXD?@OXCG%@
zXFq3u=K$wG=OE``=Md*m=P>7R=LqLW=P2iB=NRW$=Q!th=Y-Jo_8AG?QWM<Cp(&ls
zH`&Feq`Cb&W<~~e^u)!bWCWM*=!#8CNe*^-VNm&)G<Rorkjn<a<x}EQlHG~HE-wtP
z80$%k&Ft7d$=x+P_Aee#(G(RBYbHUJVqK=Vpg1q6l%C{DPYAA@rNo`3q_S6u+XexZ
zEoQf6Oyw+fZZ8a~?3LoSL3q`_3d7_7;sI4H{&+J9sT%8!^CTs?LgKTK@M?eSg(v*Q
z1FFTi(gG69B&d3ZCn?Sy<gr0;^(;$0S(aA!TI%tJqk5Ko9xwE(Uc=ARA-u+4x#1oD
z;vqG&tx3#69EtI1Zg+B$^?t$Fpjxij%nWx>k_|#?WmithLV{{}olmksKrPG3Br^%B
z<K;{C^3}=aOU~x2<K;{C1})i@nv$N8mSXk*|H{en{_f=X;JR5(rerx;*Xv}84MOY2
z#dvKBP07ZB8hCZ4d383()|r;Avw>G<nin+m)=sxUc*DOT2~YovhcwETl94T?k(WKg
z1_6z%Cd#mysIj++GQCaIILrFXEbAM4t<SVUVB<7Ta(rN>m4-IXwm&p88w+ln)r6T|
z7~b@+Md4lk!JGescl(P6web4Z-39?ItXAo6CV@#Q$?@p{F{ZhJ6%tZX5`!ybq@<cu
za7-3#WDcZsPuJiKFAS`klIl(ltZ3B@jJ48$N)~e^o4HaJQ=Auu#<`O+Tp5{Z$$^#a
zv|(&Q7nh@QYP!eNo8-#yBnMWpB~`W3u&S<(9bI;|Uqa{5>M0psBA~jZp{89i(Mki7
z%#6?^SI3w*mx+aRjCG~j^6S{8$w}_`fVvh>-GmfVcZ!wz)vfNA;t8y0OG&j-zvc~s
zE$=eAq}bk>(7$qeLYO-}At@y#)tpZp8L5^9t|XhOk)38(X>g-78wNJE6=Yheqwzm(
zg*1uHG+)2j*&W#2=IUmp0WD0M0=k=tf9388!Oc_R6HFz+-Mlcwf*CGPQjlqg<&|Yy
zds9S+6?zLn;*(M`Ol#7;(e)&E4(QS?IXNKJlj;t(60^62WkFLwxVvkt86!KM!IfGh
zxMIy2u~K(0jPpXjS~dJ?b?{5-;8&-HU!4wq$sK~q+ZBRbUQpc&JYG=O3sStGu@_|8
z0BRiPai^JGCEeS<q0IkFgT8XR3xd94FX=0_h5aq{lD^XTG*@T$-%^_lbX#o?mH)r`
zAlLt;!^)f8-D_Hy%ZG-P&zj>yTv?NRKvk=e;>{$es@K1GFR1ASi8ctXn>8L&yb#Eu
zy$XP=TrU-BHMGqYYBjM}Oa~hTW=2F-iL}!wJ1u0V(RNzcPK(%SQ9CVWr^Um{ThoLc
zw=kCv4K82V&I)$9Z5UqHUc|h3%3s`+5fu?(r<UfZ2upKRgrzwu!qOZSVQG$vurx<S
zSem0EEX`37#qG4bomQ~ZigsGbPAl7K6)TOj<wx4`BW?MSw){w2exxlw(v}}t)X^|D
z#T@po*jV$ew+?fm|4TIbm&o{s2(UsLU`5l`W^0bLHAmT+qayw4Hug)&3~XVKzV3Ev
z+7)H%jIw=-vVDrOeTuSuin4u*vVDrOeTuRrN7<4K*^&#{KAFG&YDz0)`&7vGsgUhc
zp&}t>*Gh7yr+4s+i}CA}YFD#`7pf2(Yb|JrZadEwU&t0;s7hG(^e*Op!y5cnVYICy
z+SU<m>xi~>MB6%|Z6Bg-AEIp^qHQ0dZ8g!h57D*{(YBIkTS;`4Kzkx~xYF(S3fr?n
zcot#LoiTQhVr@LuoV}8Q<FY2XID7Ik2Y2VdbZY_+wNoq8;r?gNgZ?GV%Gm$V76b7=
zd9g_;>F&7j4p~t%M_pjNRnOcBdFRj2s^)x>WNs!>!{U9bLuiaErkhO$CfN2S*gWQD
z(Pj?tm~uir*~>?0^=uKLN#^d+UX25jV$7u}I4R4+B)cnhv}8H#G|ruFcE`BDj+Wr?
z<fQf)=AVTJCwo~!>tqWJuqNxUx|Or(@RW{jb8y;@g`_5U>_`WuS+c|J)C{^Q+KYRI
zg`{Qa3r@?Dp4Q%zZad}hVP-@_8)PeS_%L%72u}BM`I{?Ocn8Z$b0IK|3ODI=b7{)3
zRv8nw8Z|J(G9);|%Mp-iR&!+j(}<4F|MZW*&USRW*l9N_4Q-xnL2!4kh`{caSbul-
z1bYFqi12^bsejij(+tyE@SjqX46#OqJ0mtBAkmYa9$Fz=K9JQ@ynzIK-N14$v|4tp
zuny)aAU)k4If=G`wX%x>J6To#)n@wouQ?`ZTI3hkJuuE{{-8M96Tgh~fDAKOK^gWS
z2ybt8syL6i(4;1WCZ+qZ?pYWbV>WP%$CZ?7zJWV4-CFX^tT=Nj`!@@)yJ>ctBL9c7
zm;8kEOjAIZ-Q+eJ)WHkVyajg0u~FDYy|MR}HL(2l*6!j3-E0t&n&#=~?wAr6ZX;%&
zuyCugJI<a<!~X8EfxoC36VzH%(mdvNB*B%`-WG;fSxIhl5M<{BXSHKk7PLB9d-DvH
z;f@Q6am6N@AkAgIk323oDW!`!dBlYzd6LaDT3QBRuSupcp7!RJ0k9YGY$`mvQhH`g
zsCWG|u@JkCh1jen5|m`NOGZMNWsVoc{*TetV&YDN{>SRj4AZd8RC5*xx3IXBF3Bby
zoSKxGZW<8M(UWW=VQC2|86JCg8*cY6@8aa0fxID3@`7|P=xPJ#ZzOCQur_Y)t{G{r
z1T&WQHqJuq&8DT+DmG)|@KrO3ux_5@ICrX*72eHdc0Dg1+&RS)YqmgmX0j_i)syBj
zqx?^snQaT3%$7f9r%vgT;C97<W=3YJkF?6I_VZ;RW`^Cyz8tHetbm1^#>JU?XnU{a
z#Z3kOL)r}yVshB?X}GtkV^hq1JrLuL_as}M+FqD*T{iBpODrDKy)d&N3k^(9a3{47
zwN4f`<}mYpwuah@lT*@DLv5WF2L3(S*afx?78d61G8PK>?hWiJ_A$%Cg3YzYf{yI{
zp+$sSbA{Px79L{7z^-BIGhMfcP<z8>XJ>a&i-59;tZEM1+AIQ!HIK|`=Jb#pmuYj_
zMwpYHMZoqL%o@8^2J&|dW?2#%=Sugu>@vHunQgb2Ez4G9js%;?9u^h>SzX%-UsfS(
z(Kes2wl$Qqy|vCR7MneO{*G{4F5n$6S$wu&tB+;T;nujxmT8ZjECTjMGsZqWS+cV;
z%!%HdA<T?0vk|f?114(5D_f=&{A`(7PTQu0XPvffZttesLVfYimKKxdiHkR#vzb7b
z`LhUrg*)sv%qm0v_MvQjcJpKrP<C5o7utO+ivWBxlVt;#X%1QM6_rIIf644lVe^_J
z$+p;BcTCh?m~Cz^Z5_mI(%z~2N&%b9F2t?q{4+7zPQqT7&2E)#U3#ZXmw6P+ib1;D
zW&R*Uc7Q{yxyn)m+eTUQadw7pz+{>2otdpJVH;-mF<<|K%=OBXo@#D(l08;&sI`f(
zF(l4h4!dP|5?v`>y}dWw+KXkG6KrnftojbOX=Juh=s%+<s~&1k09HpecWP#zvsldE
zy6}y3Fd?O5N=Aa)oTsfa$Yri>=^3_Ai>7LsW;d|rpz_v)SRq>mm^CG42dApFu)90D
zYowTqQyOTyXHSTh5IB1{WX}lZZXm6rc_CmGT7k6VkC;EUku~RL=cN5_4wm-MRP3u|
znP)9v+2S4MQ1}~Qm+6ifVsl!u)nIWcnK4ObPIA02B2afve0Nv8E5>X(I||-9zPT=o
z$EK~;wVm?T`8!b(|7QFZ?alSY8}-s=FY`$!&3^JXU_Q<;v#HI_Vd*mOQhccAFPicf
z&HRhT{zc>dqTZd6Ev)0;T<^BX&b7L4mNs($WTV~{*{Tpw&7I*2FguFN(a_Z~)niQw
zE>El@{U0Jc&TV$pM7Oz$xy(7kV@KXgB9%P$Nh8&)p3p7H?9gWa{-2!Sto|M9O3v`4
zd*VB~a64^ljS+WxhM8kFPcrQ*{-1(ycbd81FgunfF~z^Rc`IkGk16Ru_5x*7Vdaxj
z6I?cGs!7RkC%HYot28@1q_TO}W-;0~XEx@j+tFiPlY5D*3o4rkt81N7Y!tDq|3A6{
zZCwEs%$NmMwN72ZmAyxVfEH$!zo{p%krmK@>LzDkO;>8F%e)r0ZsYuFXZqF2^lRoZ
zFKcbhe)T;54H8lU8(LBEZ{*4h&a%S4UV_KJqWNDh-Q%$2WLp4bRmi5p%#C!G<Jree
z+w2h202{GSdNzh<on*3E?aV-%KOn}e9_T$Y+P9LyS?7y@?q-3%RcK8nt^g|-fr++D
z-U~**<V?S=p5PR(KmO*{FvxD)$UqzTXP7=^>Gd~{d;YQJzZtDS`xxl>H@49KnCHln
zX`7jS3bTnYo7qPFYq~sPmhslf$~-FDR(j89;aQQgR$KTV+~&jn$;ggJsA-><)pW;f
z{#1{DqRZo`nPN6z_OM9&hX`tDbzN7G-Gg1hStB7htN#bue1SGYpgpt#?J*V5Fv0B!
zFgJ1@|0?Exdy}YX<s@23wUjhZfVt)H1XVS6w;oqeybS^yCYb%-+y|Pee<hPE&g}`e
zTfu8@sI?<EuSd)P*ilb1_rV!%|86N6;dW0<w|@{R`^@Mq_1!htb<N|6xkkI={2L~u
z_?ydXxZNYO<TP|8`=`5-Lrg8HuFgrW(DJ^4Y*+iA@k;xO|ED0hx_8$c>T2)tL`Ilb
zMA=y3NFNsE!~T{=`|=9=up&OJs1GaV!-{8PMIwAyWO()1ZfPFxR^6AItuHd#Cp*$7
zG14b7(kC&>Co#%rbyT(#^Li><a+FVAl+V^EpX4Z?<S3uyLO#ibe3H#ySI>%8AzwTS
z`E(TW=_usWQOKvGkWWV;pN?psj%c5bXrGQ~pN?psj=yn<_UVZB>4^5}i1z6y;<KuV
zkE4i>qlk~Ah>xSF&#Iz6TZ;N@DeAMOs84cHpX8!G$whsVi~1xN^GPn|^S78!M=_s{
zVm=+kd^(ExbQJUHDCW~q%%`KcPe*Z|j^aKY#eF)8`*ald=_u~gQM_od=l_n6qJO1j
z>oP}8R)2_$$S#eH$kr7Zk*zB-B3oBvM7FNTh-_Vv5!wDkMr8XF8Bsjk^Z$*H$Vi{Q
z;)T4cqFu*31>2~9b619cH&=$Wu3A?Xac*nL$--)RGRzC#Zkg$!N!b{ZUGHyBc70z?
zQ1i_67*BkV$!G#Fo5RG-95B1Om-MfhZcfzco)B}Xv<(U|*B2WJsNyk~toCLST)lgO
zCnMbz?D0Y<i_SidLRtCQbf`I*TU+1E#87iO_hMe}(^Aayi`RQE>fI@LGLllVmL&`I
ztJ}ygB_qsU0=)6E*8v*^%$w3ob2^PnH|Of)&<v}-d6bJmv!14Tx|=(llw>Olu}`?E
z$!_zhsJX;hIi_z(o_}-9EAi-JMd<|7Eb|uW|H!r&;Ev{_b5oqH%*qI^?rCeS6~P`a
zbTo8#^rWYl=V8+tNBTcRP~|l9_>dT6o`Fn|Jq;Dk?hp~hiv?D7o5!=jcq<L6>b6$e
zpm-aEv`8@7%zN9A?pa7^3wPETHMDy+7F^S1R|-z_!qA%L^Q$!L>2PRbHfC<1EFFnf
z8eG+Fa+o)1@otmDgq6+vW>ZP9+Y19KCs%a`m{(u!pn6_wQf**8=`<h6nol~-+tJGA
z1+)Emf>7%g+s1+$d5sM=j}(@?z{cjSYerzEm4?{3sXW9cEyR4*<@L>c+U2d^$lWO2
z9hl+HNOy-+%=SDs3kfrGvfK(Y^Rm#OYIbi3O7Mc}UVA+@aCj;2Io{#T%X*^bUBV)*
z_}V88E50@oRMTb0KhXxkm6N=!?DoQ-%E@-A+XiObvP!+svd}urnXX$FW})T>JhEze
zq1DqWRtYa}8*J+gcm2gdZ+`Y>3iK9bli{_@Q-OJ#<92!6<|U>NH@5_~By;MsVVM04
z+?E<<KS!}qz|PH<1=t1IRJa)lA8rOC8xL#o7wzstflA%oZCx>D!=;;N6(H_k%JKgg
zd(-B&awKguVr;G4v{;KR`~HLqbC*Brh(}X>yQaFQUH#TO^Myf)M-odE$>w5N{`L2H
zo&<1kC{@Q*gbsmBAdy%TOCn)qYfHbf4I$>K8pe~Z8ZLPMCMJV-TJUZqSnWa&W(zHc
zzcuIg!D|lg{nfM(y_yxg<$ucScw9xEs$l{d!+Gz%!)lSNt%`jYAcvID3Viqynt^wt
z*I6&Sv)}UnWb<%7U4D){Y#~=XXlq^ZpsjVqgSOTc587H+JZNiOU2XNU{sX4=TSNQZ
z?mali@DJzsU+?(g96P<>8hY3EFFw@RJAU<!iFbVUj)iyp<{eAt09S1t$hLJL+tz_>
zTL-dj9muwIAlue~Y`e~b#de(si|slO7Ta~^w_Rs`+jZu*U1xsVb>_FNW7oEhUE2*F
zT(%oLxNJ9gaM^C~;IiG|!DU;AuWcQ^wsrX0*5PYghp%lNzP5Gv+ScJ~TZgah#?{sj
zERTO0j5e`p%pa&n;AeXY<q7(?Zt*axesT6fJhWAaUtk=X(2;SQg#oZp#Q+<t`bC1n
zTztVVzTg*M@QW|_#TWeIi-T5tQ6BiBJn%(%;EVFW7v+I3$^&1N2fiqe`sFz(U!Ifl
z<vA%|o|E$BIVoSBlk(*`DPNwG^5r=x_jn+WFJtw1AdfF&^>`qUFJtw1AdfF&^>`qU
zFZt<xCO^H;<fr$U{PaGPpWbKk)BB9W>w1s%kFV&n{^1sV)<4{$&-#a3^jZIKi$3cg
zZqaA`!!7!(f4D`T^<VF?{_z!k)<4{$&-#a3^jZIKi$3cgZqaA`!!7!(f4D`Thwt?s
z58v?>eICBUE&4oshg<ZUqTdw#rsy|CzbX1n(Qk@=Q}lWIj<}-V5`7-L*Lys8$5-@u
z@D8`=<KX@JC+sk74E4?QC06u#@DBIo#$AA?8xL|ndPrOJ+oInV{kG`0+Z!{5Sz5>t
zUi`N&HogVO<u>;M=-ts~hFsdvplb^YeEnh*g1;O5UT@6xUFl0w*Ph6AAacEhwJ%YQ
z1Re<ziEHMnqr7!gb{&;nM`hPh*>zQRUFEH-ymghguJYDZ*>zPnUDZujb<<Vex+=S_
z=yyfGEBam0?~1;9R8KvsrykW)kLsyM_0*$!>QO!QsGjwxbJ0H+{d3Vj7yWb5KNtOT
z(f=a;zli@Y;{S{I|04dsi2pC*|BLv?tPo}LMfAUj{+DFq24y!BT=c(){+FwbTMxew
z{R`2*5d90$zYzTk(Z3M=3(>z2{R`2*5dRnA|3dUHME^qkYb@(&EbD13>uD_OX)Nn$
zEbD13>uD_OX)Nn$EbCz``{6m%Sk}{6)=SbIZ8Q;A!>%-r8?|!ahN|;R#?sGRUn*ah
z%Gagxb*X$^Dqok%*QN4xseD~t*!fDn3tcm(=1766@_MPfUMjCW)m2Yr*;AT5rP))O
zJ*C-Gnmwi2Q<^=c*;85eRF*xJWl!{bqTdt!RP<BPPenf!{Z#Z*(N9G`75!B7Q_)XF
zKNbB{^i$DKML!k&E77OQSG{*7`d6ZVCHhzG8de3*nE6v=u@tK2=X{mk5~{+x-#tOi
zVEyPvbj1N@CP+gZaApEGIY=dGQc0Rrk|vd;NhN7gNt#rWCY7W~C23MgnpBb|m83}}
zX;Mj=RFWo@q)8=dQc0Rrk|vd;NhN7gNt#rWCY7W~C23MgnpBb|m83}}X;Mj=RFWo@
zq)8=dQc0Rrk|vd;NhN7gNt#rWCY7W~C23MgnpBb|m83}}X;Mj=RFWo@q)8=dQc0Rr
zk|vd;NhN7gNt#rWCY7W~C23MgnpBb|m83}}X;Mj=RFWo@q)8=dQc0Rrk|vd;NhN7g
zNt%=@UiFkJUih+wrBw04mn|%nq)Dmb1vl$ArHU86s^2zSSSm@AO46ilwy;!^CWWM-
zTlCwa-xmG0=tI&F%l4DDMZYcjZP9Owen<2>Y{6-VEjaCneuphM?TCIy^gE*85&e$n
zcSK*(B$YHtB~4OElT^|ql{85uO;SmdRMI4sG)W~*Qc06k(j=8MNhM8ENt0C4B$YHt
zB~4OEleBxa`MU<O%_sZ$T|?OBlYVx7_p5=OC+~XuJNnyOs8uYPH_4Us{L9<_OXzoe
zcK)vqx%1t--u@4<&n}K+ODfrtO17kuEvaNnD%p}swxp6Rsbotk*^)}Oq>wF0`-^Jh
zOK<CIe}N_WOfc2Qh3Z4nC6#nZC0$ZUmsHXvm2^oZT~bMxRMI7tbV(&$Qc0Io(j}F2
zNhMuUNtaa8C6#nZC0$ZUmsHXvm2^oZT~bMxRMI8YOgYs|IhAxtC0$a@l+#4~UyA=r
zwI@lDR8l0B6iFpTQc00iQY4iWNhL+nOSPv<mC&V1=u+)f5+jwwNF^~+NsLqyBbCHR
zB{5P-j8qaMmBdITF;Yp4R1zbV#7HGEQb~+d5+jwwNF^~+NsLqyBbCHRB{5P-j8qaM
zmBdITF;Yp4R1zbV#7HGEQb~+d5+jwwNF_1StNP~uSfhQ`59?ntBfV0OyHbz4>Tdpz
z4s17Z{Epip3Z*jQY85e5Mv@7sWI}p%WyfpUbTg-R<ZzshLpMRcK^hIrFO>Y%9M403
z^9oJxQI6#asM8WKr~*Y$JJ+=IFPNyMFK3i~j<WP~ywcCnN<YU&DIMj3BB(!8R9fC6
z9`@Y{Va|nz2rWML;xJ6w0~CY+f7`+6yK_{d?>rIx7;W_9Frps^A%MrAqCkh}Ry;%$
z=*#&ndz@JFD0&V(CMp}k6gPtLl-bgQ!_xB*OV5MlD|?*M^C+d~F%j)UA0UG1bXN(=
zr4+e89yLyR^E_4pmg&eRBz^A!E=oc`1&M$<M7MPR!qaJPr*WG;PB$Pd=K-s915)V*
zT$IGS5F`TnLt!QDJxYDw9Ty9u6g@;}LH6P>OxObygaEG+VD$fHr`kr}c_R8T+UUn&
zL_ZE9`tFe1=sS<mk1@u7j5hjl7}1Y|5O5NQh|0~wl~e@x*K&-7f0C`~L>@~phKPO)
zi0IhahjL|3(Wu!uI*%+w&ipy~YK|vy^9oJxQI3sLGN=MYP&=Hl^mQU*>B}jorJtkZ
zujY8ApQDw2j*U_}$^%7E6AmJ}GvGK)0)D&{xRhDp62ZYpz%4ikQ0En7dxTD;$Wv>4
z7TI}(a8+yw=OMxhUf`W66&MKI7dI+`=h^fQ2aE<$`8ddN9!9YXU<Hi9k@#W)E^s8i
zBIw7Qa#UC@iXqo)(jgBnf{2|#hn<WY$ih3&Nghfp`k)5SS@-bcJUqE9f)zXlf67Bg
z-1|s|U1#58YpB_{)ah4Pm%n!&9~UiwInyp=5Is@32GJA2K6r`|uZ{#!>x??oUh4St
zj1ypCT^S$w5QP#ZG-uUEe&@r+#Ymun#=tWlGUC=#A#R;rkHer&)f^5fE(Zotcn3Mo
z!^EX);GAg}IvQr8(u{_g2>LOn9P#Z48FHO*hdlUO;M-@#Ko;J&=R8!Qv`+-jS@$H4
z^YC%u8d$+&@TWX<#J#6w*md?jwlrXW{D!;2_s{0G9Vr`4;$ki<q|5f6JW&Z6AWHs3
zAtHc_S-OZ4l-m-t8L<-F5tzg)a(Q029;VRh8!f6H03|)>;clqal%k~G1zp?-$etSK
zXBU3QQx(oAFZ4zckBVLw$Ioy@vgGEcB*LkpfLm}7P{Ob0cvrkyF6Cr^J-MP3cPT8a
zPUN%_Iv_OUOf;MlW2AUoW1xuCX(3XC*!@eM2A!6M=6@o+O(413&6}rb=8NU^_EhoG
zOD)O!jOdZW6?xCq79;khi^f5K4yAG6B1f#Bt<#Hem4C7@rxPnZ?=wF9q)7SmYJ|+q
z_CH)=)gp_~MU8mdup*zb!^`Pgf*{U=nWvM`1wh2%i9$pGPsYtDjXUR21^g|fxFaWl
z6}fz~dP~rT%4;*5K*fBxnLY9c8Wf8eu0U^PkNU0Y{1Aydf0f6GxwnE-#N1c99o^w*
zUlI3as|jvNN`*xL?39m;HtvXw<_6=LrChsoO{RZ9zkHicI!fHbT|x;GySycRms5gD
zX7NH-DJtfk(7M6kVb>TyzV4-_0@cFL=Uenb2fI?Za8UWz3fjS5-LWJe6}7W(RVbH3
z+Y%b}xDJplcX6JIZK^Tu3hm-d)j4-8UHB?g%3ox-LIgeAIh1$i1MEG_?gQuzh`xbR
z>YLf{7VatB(*wJJ<k(gTR8fvgT*q=sL9pO4p#h0Sc7uty-Aw~yvvFn@*1%}EutuhJ
zdCdaAy8$B$*>Y>1-98TH4?A|n9oZ|5c;9P|yO@)^ZK}GHd7qc-@tY;IG87e61$MTb
za{Xi3vTG&sft6sFC$7<ZA7C0_w7mb<3JOMNs;1X*PBs2tE2?@=CuHozdyGLf7QrLG
z4?=i#IpTmmm{3P4TOJ~((pH^~#?aq>BJ>^2Tj*ZT(_lVa7{^Bfinj<_!i5Qcdtl#_
zqT-Y8XKm?9<!bf`mF`0=22fc+bD-+Z=mr;VpKDO1dc>VZ^n10(oyF4%*U`}8_HYM)
zHHte;xc0(=y+wN2yw8m6SsPp7PDEd+RoVG)`(d1^A~}#eqTUTzL)lK2M4JB)EcMa!
z`cWTy$BwxU<V^{1(AVv}ZKSER4m|sPA7^p$2rZ8lRM>HxMFo50&AR2&bUtKX%;tx;
z?9iw<D1DC+fX*uN2u*(6w}4)Lwm1mh(D*l2xFL@{Z+x-$hA(!z@x^X8zF$sx0qz<K
zdCw?BvWE-avl*^#ydNN`Z_r(Sf$>q$&8|l`x6}C}c6tj@USJNP1WmrjP~k&b2o6>!
zSV<K@WerBW8ZnyUUNnyM<SMg}au2j8yazhgc7FolE7GIzn2MAsysu1+ir}%^U`D&5
zHsethch|>o`xr@JO@>{~al)|$3T_+@J!og*UE+Q;!Oa_RQ^J@P+-NM`4V6P^gLt2E
zmV1yh?_tio+j16s%9-~mXTigqc~8{_4DYq9d0(D24~eqoLA)PxZEEejALE_46yu$|
zS!4mK(gX`$HZC3-;HyT*Lj$<g=y+%VH@186#da^gm*s3VpW@;GO84fuqCVn%+c)#o
zj|`)Z$&>Rht@>MPQf^Ej!v>pZNto<ypyOuQo2ThyXOcZZrT<^q7#0q2Ll2|H+Z4pN
z9!8jE+)Z|uD_l&2lIq<Ab^|bnejL=GP4zgK;8N%0nec7UoYGOc!}YWQrmu7lsC0-<
zN%#Hy`5Oj71*YO69gsrbFyf=BPNt&;v&C};e9yPUTz|wX&A2;$KL+2zDDymTK&amK
zFWA5SO6ti7CL~4^y4}UD`D}{b!^=~+-i*e_lNAp+;hj4_o=})bs0^M@bv5r5#0hWr
zU}(L0c*3n`T>um5!&hKcw*EW_t|=q+++U_JgRC9X4$Z;M69gp-08rjp9A}3&FJV>n
z01S%@rCMR<4!#=d9|j39{uqJWZxU@U;N9?i8UPl77rJ#5@sOOau^UmlK`)%-{)g-t
z*Zs}{vDIvb8i3iKI};P*?8u3y#dJIxt`@G4&+M|9FJ-h4*v)Xb%3v~Cjh4@L<%4q?
zh!2S(WVe<dimMn@(JELM+uevO+^Q^8zOJ#w?L&aP!sLxAOnx@CE2s_M+(3DHIlZk8
zhR{`B@N(=Q+0F9J<@NR65H*@XFBsWJ)ef`&xco(3uTyWd&T%VpIKVxXjdX=8ep~4L
z6pA&AbIZ{YmuHq+cQz_){cOMGpWU1QvT*+9=j-du8H{w@JXGw5S#HcmTYs_8+kd&8
z4`?J|>lXv~<e@4vrUj@szg}NEShL+I%`rin4^`Ktrwljs*-;mZH-Epre)Heg*IWN^
zWd8xOG#m2fAJ^Ca@sID@oF_vaJ1b$L^=)(mu{(cwgZpaRU<Z2Zm@oeC_4Nh{>Lz>h
zxBJI8u(478-zX#6AOyWh*|PtTjbS%p8xuRWgU7AJW&SdX15IaLpo6sm=scrIz$lyh
zy|UkpE0Wy$F9)64FSatX8OEyRJyoLQ*tvtm9}|T29^}7(`xv|-ktJ>y=vg<}9&dG{
zA#;q9-f!i0aI+X;2!#!#yUE6E)W3$^0^XjZL)Ylw*!a8P7=#4h{ZDd*iOgcL`%7?^
zfANzxz{~&R=Ueb>^+2PKmN0a`nfoPG!vC<}GS)+owo6=CoMcraj0=nzwem3z&->)D
zjMjkbiP?Ao-E%bII`s(fz2eG1Vjsl<C#1YNG>az$E1vmq2l7{r1wpqX*oGiTjs@<i
zp|zWPmt&DR84@BGWlMuraxHcMlkmMSE0VbvSaW@I@CCH?q0H$JWrUxsFgNA0WczQJ
z!NDNhWcxSF=;+w}jVa5ybA^PR3&bqk*U@(i_mwownR5KKfWM-^EZ}brTS~_vWa+mj
zv_=cCdxb1ND{Kv1xcdq6?_D9e0ssO00?4Q%6XrmX$+4@<%elh>bFRQQ3d_Q&EX=7A
zv4EV4$+eAIlA{DQcb~)3GUA(6;rIp@1vXjc1popR_&$gLH$$bf&q#$pd(m=FK~8*o
zUQ3V7jcR=Oa#mBP8XvwC@O7$N;QOWen|cWDtBjVY<Gt9+n%>dyPO-El*J=i%SXeV@
z;4&m_7MSZAE!JGC*>HlZz6dyhg`E2*3?Pv=!@|hC=<QfK6uk^w4$0y&ZY57K_?~dT
zgIpOI`oz&57OM(P8y&*OfYoe2_P&h4tXOKi;*!&+Poa%3jON5yNx-w3StP3Bv#p0v
zq-P!$$n_$#aJ)*96Q@tn49QtZj+CuD(ljJ9%2M95^1&pEK9ovH0K2emZi={D$BMIT
zVKm58o&bGH-AYnU!cO=RQLfS<tIz=$>p(Cpck>CEtIF)r=3=;j`k0lM11#^{WTvJ#
zc?4t7Lc5$GDD3X>x_%B|)&QuwiKEX%@RI(%NQ-M1KY};{doD)EYAphg$cf^Mk|r_$
z$y4>M1+~W_Vb~BVk5l%+h~M=dGz#xj&=88GJWGrrtOv+LsFfKg(1Qv-RKoP<m2O1^
zm|`K2wKW&XnkPKIdHR4MlsH+ZYvo58E}?IM(Bvt1X2H3LoKMEKO&iI%v1opAY2-06
z9^GNDj6qzBau5aDoDJ@>)ohzTWYRTUY>zO4H6L!4tY+5s=vKr$Afs7ET}w0+JW)W}
z#K|er=PA;?7LXLTG2vct6=J!c@aEbsXyR%$n#Oe~S++b}NPohuLE4Q}8NXliPqBEz
zjVYM2`lyt&#iSSt4r@=3PgtZJhY?iZB`*81FCK@XvjE<+rkay^FWL&jj%@b3w9fg+
z3?Wer(kz4NE%@W!mmo(bFFEq$z{ME@23i<%ZOcas2+PEuAsI2}q!?2hgNlfvDxz#-
z@K10>nl7%bW=@F{<E%&ugKQ`&RvfQk6h$nqMcG+RI8DGN-Y$0SFskA(XbJP5v}1wg
z#$a4U&x^d<+2afgsBF12nqbAo&{+1P5p1Ek)3?j;<}ABkRm%qIBb#pnE61+B!o10*
zvz;4QO`Q%`H_IJu|8U!c)|U9YqZJot)s?W8q!0E8v37x#6M1Od1bMTW-OcJ6Ga6hn
z<!lI*4X38H5ZBuD+NIp)rNO~?L)+SwN62Yx(+}mVE@0RNJ8!Vy$~|vbE%*k7>BT0P
zXP1~^3j!n8csboM2x@0{JiW6B!yV_G&b1ha<p6CFZlI*66KytgeU3O`t-hSk#$~S5
z{o=h0UT(do^bHGKx2iAQjGw%_26r53?`92v(*<niWATw~UBjUC3b!y(JfrC@XZThW
zv^l8)-^A`RR-M(m46PubcXLZQTUwwX_n414=k|E;1KTr`Z*TF*Do;3VSl+v8WHazF
zlz_AfVKwp@?MHihY*>*OCdm->JD8<$pQ`x~Bo8Zm?#+$%RLp>ni;7Fb&|hScZnKt1
zt%fglPL(#TvniJbg8?{5wb3p12(i_GDGXD=9@H4ivE>d+Llh2-AGvY(@`$1PK;J2j
zHORLx=t7Vy=G0ey9MiyDg@JeI7OI4i&X&8wMOcC^O2F};g`40z7(J~tc6Cd~=nk<m
zGFm0qW|>2r+;AD|5*L+kSb-u(>c7gqy!#kJMmH=~6o?>Y+8jk|6!{u98nDAW4}Kz1
z3*LX=@DXU6K^|8(_a%p;8x0Q2hHQc@WtUbc{4IbOg)PLzpmipKjD;L7zxWfs<H^$V
z7yNn5(Kq0ko+IjmR7iO`cTgCnQU<4(@1eQ7=nhD)a}tX~C0@qH73$k5CJaxDiU$~D
z4k{1MniQ7hN<MR({3TFUh-|2gJG5JCbCWh(@<bj3m^QEBttpB@h~AI<43;g+=-e<%
z?_zt8;TYRPd~ENx5LJtZaLT}*PuBysA6H|TB+8b1a?Hlh9<ZyCOumwB0;(%i&CRn(
zo+4C?{^DOEU-RUhzsga}4~>g|ZHeUKU%R$v$YH-^P7NM1+6SRRj=)ISP&O>@I1fg9
zbFquL2wp-sTH>T)p(u(um>bhd(43Z_bGrn0%!|RY!VMAhG@IRNdqh6T)?FBE#qfeH
z=UD}X4B-r`_v*^n{Nj89o8ikjdn)?a)&gVk;`Vt11N03nbz_^9gBBL>@Y3|-9%`bH
zn#NR%L^-N}>^dO^Bo7YLus{B=OS_5Ytf0e7jETjv_i+wU^PXGR2F$O3DywZ@nH#EM
zYZ8wG80EwMJom&We?a)oN8h(qoe-FBFoM6GV5{g2W_A@(QsS@?WImr{73;6(TxeDz
z?-W@FGHxL|1egGI+sqXDoFPc~bENdbf6tl)4pUv_ZC=yTWLA}*d)b<p*K)78tjG@{
zwtNgeA*&F2k*wOJL8a+@i$BQfj<s}*ktN^C;jYE}!@n)|;dqPsda%PEKa<$vaD&Y3
zy3q&DG8!m)93&A?HSclwJpxrj9^ifjBXTFW%vzqqyJX$CW+*on?fLP^4*-4)^M1C+
zLZ9Yf>oe@S_5R{tPAvLZ2aA7MBf`Yq4K+0~XdWB19dj`#V#ZA)4ji9RC=PPIJ+VEj
z$HcAu-C6(@%25Q&n>x!I6Ia*|fgO4n27%@3`RIoS(EipKjl=u*xx6Sq&fH{|3rj`C
zbdL7+dHise+JxARIq3Y8;q=zwT)fwCM-Df=<?05FLI)G?3Q(@;F^;|0RQfeck%&$^
z5Z<$kEyQ(h7auvR96;OQwY+@1bja5j4l!Rt9(uCOjAQ%MmTZn>ggE|zTGF2R^#CUD
z9x<QCGIX}h-k(8o?5hZIsxVo=Ldyap>jsrXvQlI$5#~YNE)Um8ob~cV1<RcpCEzTd
zfNf*vN!#796biK|&iS#q<lJf^JJ3_$lmS~HatT<&LU=iSlpERvv#R+Sie4D!h28?z
znDmt3@rVjW6F2f9lNFOK<LM9DW_g2wa%+*%>fe%jF4(8u=XwgyPGI?@V-;i`51ioj
z7HEA?z;G|S`fZdw4Pghzh;c24J**)P(Il`km=Bc=n~kRd>}BtusOEQgr)B{=!^W1D
z-PORcyn9i81lW%=EXXbgIWA|Gv*5g5V#T(CDgx?QE}e62BSYC748c|}S%>Qo(^}N!
z659#3!3o$l4ta3s0|)-Er&zM@Nq#t`8W!Px3{U|dM1&XuQA^j^1O*DZle_W_D;LL6
zH#qx)jwR;SG*pE4a0@xUjhQJGEuK+D=&^H{+g&YdL!9J5qXz0%NMSVL>Ws@fsReGR
z<6{Dk13Pp+tUJ6L>!642i@*Oey3PiV6*y2GI9{e6OBp`?Y6v2V9urm7;FEsKuJitZ
zw&9#MWnnmTY05#0=0(U7JX$BCZ`a@sD`oh7(!%cn$)rO7h9-c6GPWcq2hQ&XWr7%o
z<*J>9Z-Ys;4}eNOK#l?x7fc%x#}1l@6_`mF=YfkufY@DSHJHjl;G4PE%17Dtj5Czf
zv3#}^gk|I7qd4ewJ3i!>)S1V46NvOyGp6UpA{HTNDKTFqtC^DWRRT0qwP;9&G??m(
zVhBLx*I0-2^P{ig@qrr;V2QYijR%nhB;ma*aw{_rF;1XUkRg~Ah6&gq3(hx`y!uVg
z2`FP9$zec&uww&2#)6;BaY7XU41gqpKd-(3@&!R|LT$0h1OWNh$~?q50VHZ<0nU2R
z_=P6m>O>LQv3_uE&+I7?f#1>R71Vs$_(qLkPaV$t{W6){goY$C4B={9{w?^a_PdE+
zsL?WU>;>Enn9~8ZuYFQ14R?LTgGh^Uy`OOu*#k&TL^yqiHK7~qVa*@hCL_hq(3+I9
z(aT-T_Z$x~R9#QUm_No!k}&ZJ6V1YuBo$3>4f9X8<}loQieKnYLQ0Aa42jev1HF$>
zm-$m<6&rpu2(_@V``jgT(#IgDCUU5qprbnNnvyt};Sx_tyu;85OS=&0-!f#xfV;4!
z^=Qu0jN4PrEwxp1mvJOd)ie>ox^p-+=N=RRVY8XXFb;74%-uk?X9FB_D$h;;g%1qq
zGaSV&pJ&-i@R;DE8H6Etn?b#m?ZRTbkD#lW!HoKc;RwQbX&O;f)w61O#B>UK*BSyd
zuN!DswkHlj?}yn9rpV)<4H$|8n*n&`0@cHVf$a&FfOPC*4l!9m<p8@WMrmInGKQe^
zuzSVsww&c|JXjat*Vz9IigL?Y<jKBAp6g{L612-%?90B#zUyVxh1A%-#N@}+Uggcc
z7rfWY60wl><ggsvm}TdP>*baZU`W4?t`fEB0fI-U>t&d6Ad1FWo3elZWT%6eui+?{
z^DivZp0DRvUvokQEP=w3p&}MLub4S;f`YjaHZ7dTCO*4>kvC}fRt(~NAK*hbP#Tmb
z2<N?rP}t$j!RpRpNfU~}h`649XK#6@{H_5Hqq#XA1Yo%OE3oD(u<k3cFCX~22)6cp
zGMFOzDc`4;C}UQ9q16^5a;9z)=A*+5x#-W?Eg~@~e~CPMg{EK4d2ZIII<&{Gk#*SP
zHM&TeC(D6RbngN;MEZhRqe#@L&)|AIpUzsG^`b&rC}XxX&p}lBR>VZQji_55RX}Nx
zyG$BYN*Na|&aGC?=-KxjnY-y@=8D%iaP$G_0>!@+L@t7eBIKYDW+9LQncAESwI{7+
zdtX3dN+?pu){NmRn5jdF%lk08VzuFXCCu5E_jj6BzrDps&Xt4)98B#oB)f$}1i_Og
z>PlJ3ia=fd1VD7mCA2m1j1Ht))V;9KdJR?8VIUZrWj~;-eH2am^EO(>QhUIa7$n|e
z`xd)&bWrC``mM`jj7&GkDtcqQX#*vaCT%X@O9j~`Z7$$T9nmIjF5nBB5%^N~sY#m)
zjV5g_;0v1+_`=2szOZqEFI82Vw77sTRaKf-R8?tSiT;)7(>fp^qECAZaEty`y8k!q
z;m%Q?>2vl~&0_0j_R|Eys)}Du)^NhfMQ+)9(L%5vI{OI|0y<01$@Q{<u`roGGd6~^
z$rOjA!@G<`Ihi08&CGf0g;CY7A#LgAAat8$Ly}=rbYM(M9tqwD7;|Rq!a#>t?U<2t
zgbV@7NOF%R49FEL=slQ}Cvup5!&Ic6I~%#PnLAsIJ;8J=XMUTcpC>o>dvGw@%<DCe
zvv&Z%=n475i~(g6qzWTo=N(37ajArXj19);!Z1i^rp2~B3y=dqY%v}{jD;OOh#0hT
zF3D>E=)M39_u^P`%mgsa#)6kFoS04?u0t43Rv-wNL1;^}h)K_avt%)^cn3hvt^;mO
zZ!kH<qi6W#+XQn0fP1Ln*DL?gUx6Q0yS!fUBFGMX+7&&c3ng`fmtiLldVLDkiR~uC
z9&lKZN-b5BR1&8)!YO|7Vime1GG>aa(5k~0%>e_*Xl7X0p&7Sm_y=EhiWUw3;LA?Y
z(j|x%4gbK+PSMg;h?cHGv}pJT5O#_d4gcWFPSK*_AAH&AS~UFAXmv%OhJWA|{jTWK
z@DCuOPs2ZOv(vR`_y=Fnr{N#CMW2R$;1+!v{()QcX+{p3wxUlna&U{j^v_z-KWj<<
z4913q6@8kKLrBr589BH`pJwFX7JZtLYqV(U2Vc>rsUNsSpQe7`7XQ-PZ%J#vC9VCI
zwDw!l+HXl~zeQ6&2rv3HBL}zW)6h?&MMFRMiarhfz%BYT^aHobhlYOO7XLK#1Go66
zp&z(KpN4+m7JVA}X|!nQ2Vc>rp&z(KpN4+m7JVA}fm`%x=m&1mr=cIXMPG{dEgJd(
zMD%Isr_rLJAACihhJN4{eH!|KTl8t@2X4`)p&z(KpN4+m7JVA}fm`%x=m&1mr=g!l
zi-vyi6@41|fm`%x=m&1mr=cIXMW2R#;1+!v`hi>YY3K)T(WjxGMvI1i@D+U;`hi>Y
zY3K)T(WjvwxJ6$=rzN4&lF(^M=(HqsS`s=f37wXNPD?_kC85)j&}m8Nv?O#|5;`pj
zotA`7OG2k5p(B&D4Vk3HSNu!p$RsTwSKD8&U{@V~rTcFZ0~~n>6m<9g8)X1thvOy3
z28dDYRbuO0u={T>U<Y|PAN3#)=0T1cS4`{F3NS~FFdx-Xi$UP`v-m9!Cu2Tf_>J7b
zbN_9=9E*MAWC%mqE_a`s%yN~XIXScN@ZNu;*J6|zgI*s8Z=-(xT*l%fPhmAHq=2PI
z2;EW&3>~Gw@P!m?DdST(R~%+EPXo^qF%7cHU}6#v{eiB$44m_z91-hsWXv*O42&Ex
zc+TS&OAo2#JVFV}c=Rdm`C{>D?pd07J`lnv_;f+T06yiarOYTkuN|h1gD#eSo;|!_
zSWLY}+G-+}2l!n>bp>E$<r5M?7M=%GSc{>Fv7vMe35QJiggpR9LdArcIT5mi!RcD2
ztw8e9N79Jn`wEk8GwB1LXRBwH$AM2g2ko0P%K1JSaCtEn_L)hSgo9YsL~JTG#>~qY
zsS!Xnd>tzkspTyTp$K3oUnEFx%&5$g)dqM%cenC22%=fB7$?e|FPI!uv-S`Q$8~d@
zp5`EA7UN9}+P9$vAW|af{Se4QP|PiLZa5n1gK)seHU8*OABLl;rq3`Qf|rRcOhdKA
zzyvTB1h_ex>Y$7j9BNI3s6E5c3=WTK`6TL|jsT?G@T_8v<I?h!Tb`em=LhpF7lyye
zPRL-OBS-~X&+{8U-qoCs)xbhCKWfhTEwmrIa4bCMemC}Or9ijGsa^~~bdS>=+bZr*
zMrTt;T6eBT!hQ<2L9j&Ac0<|wxEDtc);2hy13$ao1HE7G3{ez{QQrIbjKak}qbu04
z$JnZ!a33M0fe1M(j3A662+jz2w@GV@%Fx{{kq^Tw#159{b9oPjxc!2SJG*@%&=xf1
zxh6qZ$uFr0a_9oD5s0p@DA<O+2Y6dGzt>{%`OGj9i{tN)Z`V@U8sB;X>#SABw{hIc
z7|$=ELhcoQ3)(W|duz<g!mtmh@7C}^zc5u1g{`0f@|Z9qfWsxOFma~p+^ULQdaRY5
z<<7nf%3lRLEaC+F5W$@0ypI=?icpFsRvgfg72L=DXk-hpz{d{Ogjgk`Ic)xnL804Z
zQ`C+}Hr#;|TMAHzR-@GT$AeZjT@7mV5Ty=*C&{o%g^xwTt|9<VkH2F`^<He5Sm*%R
z{25nWT21}5>$n9)cDM_@!;cO{s|I9}gjKvl$U{SNd5V}gfX3pkQt;tzXCx2RbpG-f
zVo%5O-nSSJD+R#5$Ed`Bt_M32g4B-+!F{NMmrzT2zT}1zOhsTHDC0}ha1SSfksGXM
z4+~KNK%zw^0ds}~Oht=a1r;b3c>P_020;k3{{m>qk8h179J+udzE4RL1Xy!FUhCc|
zo`TIG2eHT6!xmp|&YrVP+YogsY7|^GgM{X>O|uLO24y`rn@&&7@#hrUd=a|Hws!{h
z%SH_429MKr0|Nmuc@q0NCzF1B$Tm;T90bpKj)&0e{$>Uu=rR<JlD_3pVb;6gA5L~A
zPwY7mDLYb4l}q|b=JME0@W(*LHe8`%u-}Kq<(t#uiJWr-2em$-C!mz6U2T`h5{cKI
zuv&B~h`yAZcA_Xaw-VaJ<~&YASoGJ}YP_*#r*k*l1NL0FA_}c3P=)@$9S(7Lo%+Nm
z;c~KFAYw6q?WKcb3@gIjVVU5f=OZ|T2o(?~me9)-T&=xGA%YhOokoNT2+YwO_de$b
zIU63tC!Z}V0ivB(+e))i*vF<8PBLXR!yw0T7#w<y9XJk{gRx0X^+k#fpGa9}T~Aaj
z$8+CM-dhcyoo^dEPIGKl4z{36_5^L04IEA4UV><IOLRwx%O$Z5ZJ9e<6V>4-_O7ss
z#X%@GBcZxJz+*?ck~^6Wvnn)xBQJD2CVx0HA82^~@UyCPf@+T2hsOS%G<9~aky+dp
zn0`M9F6~G2thZVKeLuqG3)pa>Rw$pTdcw&b-laeA*?Yp)HQ?ykcxifh%~p%8)tY4v
zml#H~5j2l$mhIr*hFpGx0f&bVYUg;p5buOS@oWh7C5-==(ae{}io<5^uht`>?E8tp
zs)hpGD)U9~cj5#sW{SOY6tU3|@Xu&)0#yipx_CfuM)sBUYp6Qm9ylJ}n!xbRiidH$
zb6n#|8g%n{hD?9udNjQs{NSw~_;7g%*GIC|;w|<u?<>0CF?1qy6Aw~g$gYX{lqJA2
z#TF|IdV2c@Ug<#{WREpA7IC2#u-wP>`Nhc2UZ5)k)DBoc$>Q=euG!JZ4MO8$I<{0{
zIt`oU7Iq7|t9*f-LkFcSX3U&IW)q4>2N>hc*vJd&8O5o?x@H;$z_pJdhb9*QdR*9U
z&HdV@MW&)4I+Lm3L3had+aYcRJ`VO(Ex3I3#Lj?Q=TOk%wR5`49Mrw%4Z6l2cv>tu
zQX;8G7`LcFV=VS>(a6tg{=9jM3zOq)LkYg6bL)@QjJw{O&~e5|)+V&UCb-Zu!He{(
zNwxuP>*aI<#x-!K23is*eY}hYz3b7Yw&~|@#@Te^+h~3_-58IsJG~9{g!ya)o$$o~
zS9wuMaPL4d07o{^h1edDNq{zIP-Ms!))%p3y;wXTo7Pq2h5837L4_bcE(Sg9<z5H_
zyy6)F9wr=&q6o9W)5LmyPF~$5BA@$3KKDBEIlz(60VKbHLjyb$s2)l=S8|gIy5HW6
zSJyiVK<|bE;d+v$AW)rKT@#F3JIe*t2JRNTci>k9rAL^e!4VfhP=*d}ESL9qogPJ_
z+qS&Z_m+obTe41oD^h6j^I45omls$?VaK2SrpBAik^dB@9~hg^kuddqzQGyBo%M!~
z<~I+z0`)EGFf)OJmz%|F$i}}zHvb*6_3x1Fe~0Y+J7o7&<ek(DZ=fvz^#mO7e^5QH
zm4f9OM!8rd*>Hw)N~aR@5mO;vup2+Wf~+AJL>g+OuPC@dD^*WOY8ZULaEGTC)oc6p
z;A#X{Gq_s8)ef%Cp|yBTV4zftG39=F5W#TR1n}b2+NFXC>%*FWu;~QCdfcMSF^`Hl
z9HUAY1HF6Ssd*8vCnK@NfX)d8cMNJ8(XcHie+aPWqxcXe&Cx9Hc5XP$pljd8;6BQx
zk0Bn4{hK_=f;y~PD2s}=x)%GmTG*f7_6Hc&A)ql*yn|X1lI;Hh(>UlVE1dDez8_@(
z3~22^LSQ1&$21kDh7j=W9fmdvhud3{;pK;HQNkhLW8dnxjC(k=G?w+pIPAtbCr|K(
zDj13s?Cf`R9@F`9Rl-&Y2VY4v-qOJBz9j@Y{kvf48Y{2S;_-mPXrI^b7TI@P@Pg)Q
ziE~xwu8;>9)I-KF&SKEVStr^f^d^z%`kKFSgxhUcsV@4o6xUy@sJ@0{NZewBpv9^A
zq0QO)Vz_S=>tSjH4z`0^U6@AT^*cPdV@JHM0IJYr<-HZ>Jy_9{9me+|n(rK^?eoRv
z%@lhPlM=L|cpBQLSiswz=sO#i)Z5zpJG#PP@%I0P{_V#9;bds@5>gvdCt-E}7v#?`
z(9OoBkFPk-hRiB`g~&jG(7pZNFa~$CntZQ(&2R(3Ce_P~<*w7Dj!u(0I!)^6G^wN0
zq>fILIyz12=rpOL)1;10lRB3?jp^t#siV`Rj!u(0I!)^6G^wN0q>fILIyz12=rpOL
z)1;10lR7$0>gY77qtm30PLn!1P3q`0siV`Rj!u(0I!)^6G^wN0q>fILIyz12=rpOL
z)1;10lR7$0>gY77qtm30PLn!1P3q`0siV`Rj!u(0I!)^6G^wN0q>fILIyz12=rpOL
z)1;10lR7$0>gY77qtm30PLn!1P3q`0siV`Rj#L;rQeo)mG^wN0qz<2qXmt3DPy-v8
zw!T2i;!GO~d(-)%qITwewh|}?u-@c?i%$C}Ouw-;C8aG5ja1Txw)eMe8wcVTx+fWw
z&tXvmvQhDPV%Pnglwe^9%YbJNttIR=aq>#{UcL;0FufU#VbP2~IJCg1tkKc{+hS=l
z!kcJpqHyeB8eqDdRZjSxgV$~w1sj3i-wCZtMmZ3#U~<v$y)2~j9Qe@$17h}Il2`c1
zPoZ!6m%<zIH6ZV%@ya$NH+EnLn1YM@92yeJL1hd=FgKVfR*54SCXxf(h5n#>)fg1D
zE}7wq3wAUp1{V+Si4yOawHGiS#P$m`$sQBR=}R$&*{vi_s|DPhL|9vItN~f0jq?-e
z`9O~N60;VAD0?=f<pc6zUO3k7NLMZ^#t<`%<ssOya^aH*;4;iDYN|~ZYf%BykI@>9
z!I#iMp121cYQMCY`6Izx#zQ)%F*HsSmqs)cV!ekI66Mceey-R`oNT;A1+vFx<YzrK
zT|vHvsmJB<^3~ctGoC|^LMSA6ri25e&=yWH;he!rAh$3R^ts=;D9d1r%*KJ>Q$={+
zdtd73KB~ujunG=rWR`Pf+Bo!V#6`BljRVXh9<oyyR@0^f?wE}r8Ux};c|bS*21yj4
zTbO~*vF5Xm>O61%z!>n+QacaHVcm{B3dlbc$TrqO*V9|<RG_uCF88BWV*Cr9ey~lF
zd=yeAQ<rt9d?3nE$Lq0-x&!Ai49t|;)IsR-aW8z^HmP$<3EhEJ*?$+dyQdu#ZkTaC
z1jYP)n=(WY+zCY^j{w%+X*m!|PZ0OnkOqY{Oux4_DU?+G1I8km4$-TT3{{LI9wl2k
zpHHwN{l<|3dh1xsV=4->!<btcdyx%Yt6DHZZAwfjP3yNN&eSi2vhMEoPI55q*7|J}
z^lr?%1|uF&4Q`LDV6;s_jcd%7u!V4JP!k?G_`QL-*jkJ5A;+voa<mu$(`A@sHjQLw
zu2!LA_@QzXLd&SLNr*hCfL0(Opd;%Ffc+z;dZY%yz_Fs{v7n+`0Ow`mw5`!qvSrM1
z3@=f!kGnkB2MTU1G%6mhldH1#Q557JL<?~+$b>jLE(<=5q9GFI<9Q@p&UBmYuog4H
z9#j^4!G@P6#EKKQ8L!}Err-xZaeS~8#}`*IK#au%$XiSR?A3hE9e)Ks7~GHX;&3m9
zki{YZJQiqx$pQ^=S%8Sm0ul0AAOc3MnbEE$+MqX5!_F#|wysp#x?j3(7)4LS#uP4v
zP*&1ua0)Vb4zRC&%PE><lt9*Cbp!{q0GRU$dWZ$BT56Q$sffOUc+ZoV47#E(qI^`8
z7#-2u)kvV^-m8G6;>|wdm|)mbJLXWA$cD|Hf)imINWp7^p$%Ky8MSW7JfDaM!?<Hh
z#j0_v$9XJzk^HCFqQ1fYq7&bWCB%{IiY$B$=YqboZd(L?;E6mY4#+_ymlXaO8-^1Y
zHpp=T+fbd0DT@}N)`gCtbmQsOSZo=|=MM_-YFrzO;>nyy+J45Z9TK<-Fze<4=B(--
zs>}jZvDZSn=4P2I26sfPF%?l!u8Rmq?$A#NAUdxdi&pO*fzpE>v^C+qCu(EUE}zeh
zs&pN?&-sp@6Nv+r;MKO8f4|wYsj_d}FoeFseW_zCVi3<+rs(4cMIyOGV%Qs?v5<;$
zbFV5}s=4&P_Hhv#I~+2Mlg+JVtwU>24Y8Z*xO|3g|H&ObI1{}y%uR7Rgv}2nbLx!;
z<Zw*CV9NJ|vj~)wbbWX?9G5bAkDl4n+PkZ@cUNoguGZe&%c~=`a5sbDJRW9jU{V3I
zOUDzfTJl~sje%|RrWc$1)@+4M-xZ!LfGoprHs>XXsya^aR&EhG_)0nev|E%Fx!G-b
zlk~`>r&+$`^u_K%7N7`LCP0fn?BP^+HABgfLYY3I>CuVDV5}>5+zTw>@ClaXxefBX
zG2uxNZmuunC_O<PK(6a-2f)GjY4E%#6Kc-u%*=+-Xq!zHoq+E@I<sM~V5IgHi~auN
zp$$*b#H0Tx%GSDyfsOKOm=BNrU;4lIe{;7zzVfz5ViOsl{_!U$HUMo^bki#=$F<Kx
z4H7keyruA@XFFiB(t+N=+BF_Tf@rWoL*Wizfmw4F+6^zX2&1YIkTp_e)yStJ$dMT5
z@3Cp%kk~zEXx++DXaE$U5TqCfZM_%=0L3|s$+}SQ)?f;l1MSYJfN!to{m=Z=`Dtv>
z)u6K}r@oEmroc_YTY~G`Xc=6drg`kA(QM(S9w;?ijMG*eeH(3yBTv&j_S0y#T^!+B
zhO?hW%i+x1bYAz1RNC7vxi-`5C_Q}}9ZOH1rg`kA(d@YNgliejesF8RaOQ0~ulq%M
z9iN`!wk@vxG}<n%d7IAbevwNb*YGWecfZJ~!#e=-W&rPCZacWzrP6J8nBT7Qt8b%g
z`IV<>9{XuDyDq=NwG3xJxW(Y|D`?Ys-7iw?`ur+x+v3_!qwV6Fx9Pm@7y0#Z4c~Hj
z_lx{GyaOP22JjB%w;S@S^gEWm{WLl*ee*V**ZrcFefoyS{Sjr={i3FQ`i4N=`t;4g
z+79U(jkcrVeo^C&h6A9E9S!GTt$P|S3@XvWcn53Vh4CQPw1I+4wcp(h)!$|PpR4}$
zZJb;E%hNQE{WO~AuKtB<8P0xi*TmJopiSp>zew}k*T3SnEw24E+Agkno6hTgk#ir{
z@GXaTzsR-2I{<QO0PkRq&qMty{f?z?KaGw{-@Hxdb-$>8pT6O7bI8@deo_BEeM6wO
zefs8L{fG38M%&SFzo>sl!vRp+j)rrv{yhyB232ceyo2@c!gvsC-9W*m`ajR>U**xY
z^01#q*OiBPo6hTgF$y?d;b2q2O(!c4`^8A$@D72#@ABdt;GpaC0vBnt9S!%35y8=L
z0E_{ShI4RK@HAW)baD&h9UK`#c^D3*;6TB}^62K}Vf=I)KkgSJgyY8nFeW&DoP(o;
z=f{OXr+57LFoak;^f-<T1_~~=mYg3rS-9xMM$0=mVmMkJ#1X>L@-B@UK5sr8nuH4%
zTpBrCxBz5}ag5|nwVv)dZqz&J(LI09o9+#+IW-gco%3p&N`G9#V3Lv}WeXaR^++d-
z^a@;-bN>W)R7{A5e=(2I4R}w<!(s{!_JMOcV`F_Wa0-QNE|Py=M?e`FOCCQ3tZ8nZ
z`*G3?rQ7Q<SN4j(=aLNo@n#fq7z3@rPD9St5buaE-mn1Sf*PBVxECbQ67P)7t07zR
zs+ueU7k%s16k))4UQLIAfjmT^UVmSs_9>2F$eiGVRzSuhn5cwIkccm}fcB*p09pf>
zk7kvya&;>)71L{oPpk<cTxDZnhKMejc>PnX8RCaxr?cUYbL^+XqAh8(i|K>GsHq}S
z1}hquj$qVq$-|xg`nx<>K#Fppa{6oP5k*p`UyF!9@APYtR6u;fkr~#*$n%{J+2Fp#
zp@;*0irgNZNBHDY^Oz!&pB$4OTjcb^E0kS?h$Y%b_VHa}pNgq?tSc(RhTH|L70VgT
zDX8SMQH4zAroTQKTpEOIdDu3`fj%CAfi2wGzd;TsF_Kp(LOeFFKSeSPbvtfTKoi;Q
z^+TUPe5h$UOm5lVV^2+u`6c4acKkr@CGLYoDyH+h4q86_8NJ`R2z`&eGIA>gY#fq`
zg5%O|Rd`HDRM-!}ix|-Vj8?$MqVWQJqIgig#}FfRc=^Z6kD;T=rkn2Xgwf$74#}8~
zhz2LQl?&N`)5y98+Ygkmkvd)7-G5hdF?6LQjDI{^n#(he8xc;mhSBvJd!;Bax;W0d
z_YeY>FptM&HG8-VR$&;PaN_A^u8UYgJeDCHR^qRi?!TiO#mspM9K{?PPjRXdPZH9O
zgWoN62@?tF*WiICg(ep!e4-TBFi~p4Fk~*U;xq#0q?igRyq-#qSx;p(bMip_GfpMP
z6jNbdTpT?A6>2=>#^csgVpxxhY9-{=^HEHVRD7)U)FPbf_Gi(8=%+D6A`LK{puL$B
zx3;cvLO8^W5C$M45`Klagoe1o$y!_wP~1Ejmu?;xFL&lx*w!IeITl>yo)<hLZjN<v
zV`A@fkB^HjG0vbO3~s+c59f(HSi<BK*W=`vwKy+Ju8@20d9_?M7xB~1-*s}7@p9ns
zR951!xr!ILe4%KdI>WKY5Dye!T!XIA8jd+uD8UOM&&dD(Kb%>w7X!=bF%=<cb5SHi
z0@3WsMoAy+z0;EnQ9`=!Y?HmnGRQlY-Dqopj{Q!2F;(qT^8yp6fMrtlo?UcB4_7a8
zo)0z^<{Z^23WO5_n!3|T15_kr%v>HS1IsX>w$8PKA0GuDYajCkSVt0qVp8qT*liDY
z9eV1MWzJ=r*zJ42_Xs5sV|W53<`~7j)#f6dd6Xg*aq3!yt#zI|c$0q`mVtGIe)n)m
zy9kbQgVH)?1k`NTZ2kojvkW20-k%~_TQ87~tVBn=Q|}H)PL-=y5U$xkdDa@I%ftr@
zKfj3@p+kK{FSEAx3i1PxKI$4tH3J=?6%+`pxOw0igG;u&x~2A8c)-{8zo`IqT6olh
zXIhv|k}3D_3O#x#e4@viQCetBP|2{DK=QJ1rDKL@>A{qpBlhm#2Ioa8uJ^?kL!z`!
zUd60n5LhZPicN#SJZiJoN6fx$+;-j<@G<6SdOe1^t1;nHUCmBjfwGsLJYF!*7xTvp
zuAH$>#!XeUljE0g7SsD8m=s)u)7LPJvW9SFh+DpENvmm00RK>=<RdVxwd7qCV)lG_
z_{V4ty@O>#nTGk$#~2pP5;eq~#Yjt(B_iC17^hSN%3a1|D*3Jh(mHU5M$x$EbvUSm
zgq|=yazTnGqVF8Ea3*_ZK$il@_t9@j8qSCVjoBkw<IINNT^zI^3?RIy4V5KY7p4j0
zcaW{jf*bOUx@TGArCs=RH%^D<^BM3R)JKT=`bQ(xk4iUM(HXMgvSHg!ym!YI=M>p+
zQ0kYzTx-fe@tO6*VYEUGI4M5xl^&;T3ghzZv%`o1cOi6Wm_4Y&IHPt7xp)Twr9Q_x
z#PFdSF97|(jQ5@=J}|{vh=qF#qgz~Tvc;YzMIIf*rw2$Tc#qBVqBe3SH)_=|Dj6SG
zJ1(}7VwSq>so5A(jy<?hfoZ8WUi9wxo~T6tyTueNf7c9^`x*a<@0LAlJhk`{z)XN#
z<Ncu!#?FE<m`AV!C>iS^DcAsji33<fd#>U21$IjBKl2W0CE<=hR3z?^U0!7v`V(^3
zSXg5;Qw#MayqjisEbyEXETh5>;bO3;;>omIT*QD~Z$2dTF`ClhlHM3SgZFQ&H%3Td
zJX~|QGmP!*MtuHhJz@#t=ji61`$P|TIh+^chR>4$E>WLi^TD-}KFgA?`$>?!j}WSq
zfH|=`a64Ym&v1L46@xpI@Q2ostiiev?=8eDm}6e`;P{6^Qs1_Ya1wzn?n}6W`(3*i
z;T_@yedFOJeS??gc$FA)z`=7iJT8uXeo}qlv_qIdH+Fl0=P(*VYyjE49^E<UKAc60
zyQXQtU6WnZ1-5|c)a1pKsMLqu48`6>d<lOGC9`L|XFhp8=A$E)jUk2#&+kbDCVdY-
zjo|8n1%zJz@DMlnyl0FT2-5sWjMY$Vk<#Le0YerdA7QY|UsUmFz009^E!Hh$_DR3M
zWEl;4h1&;DcufBBC>Xvar{n;7wBz?d-@-#YxdU}{T0TVKS>RLeu)I?9$Z9Ykuo=jk
z%*1QpS3AdRIlS-dZ6}`wdB&H~9Z3fGzzN=8a6OLd?lW8ucQ*Z}<1C=GFUIR@#P??r
z3bS|&9OD&rk<f{Wdgu8yLIZ74(#{Apg7|QoNBb<Fcz`;)<SVXgO&^XtocU4-b5R*G
z?aR|YeT3Jct-Od(Z63xD*B=6N7Rt=yzolS%Fa0BqH-7N(42Jd10_y9J11S;Ns}Xz^
z#a3d%%y5Hzau?P~7TiCUF`ay5dt@G%b|h#e>kd6qH^f$te2?nb!x%vWstMT`jP9h3
zfR|wfK8?e2iK=(G(KbKC2ph+IzE8B5>KT=SxY9i;z<t7}1*o5E;MQZ2jGLeEHl$B^
zB%5y>!)<7IpCiKPZkTu9&^FQM=Gq5$V(F}S>4*Gc;J10mYdAk0Ib&-!tK*_%vk%+D
zEu&f%{^h+-#RS&aeSzgVF=XbG7%vha$SU?@5rLbTQYf^{Iw_?mEja09#t!nL@wIdq
z${o$ziOV&*jF}^0YlIhzaR1xHx~)-pPiqZ<vj=O{UZc?|&RLs3fqwrOPpYfkqelF5
zlj?20GqS;=E^vDh8K5UHyB9#NN2>eB@f`evxS~xFM<O4PbFvOLoga&=nrR&GIQ9su
zaA$dF$alg2!op!{XTc@7$1BDseQl13a<lm`vnTk+5Hm*v(2+GT1!N4H`+hX&$S3Zy
zYRFS-6)%Ms-b|7d&_rAmKSb0y)rwm2ab9k&R+O)!P;@bL&nV|naOlgVLg4opI&yBY
z1`dyPp1zL36=FW}!u<jodx16I*b81y0&P}&L@#%eLv&d_tb+63JVFuvu^1s=R&syz
zETqCnuj9asl?8L`TH#vh`7vZIEh{9CG_y$GG6`f4{7_)PBDge)ycKDMzBrsd!YBoW
zIPIJ8<w>-akD;exK8CG}0`fSYwp+GLP#lFhxr3@XU|ohup2`I+9t#oFg;#JWpybJs
z?+bgiF~#D3FEP0YICL+OxlsYOG6wS_tVr(gq@Qge`GNevGQsG6sd`q}<|QT{SkLSY
zQS3qDLhG~Qy2nhH)04bBlx07po_L3#d7x-zBTONuuA}77l(J(W2N*$MW(9SRzB!h#
zUz{Q58MbC$!@XCy26DSl8gfZ+p8;bJi)u@aS4~1F>|xvPq0c-mdT}4^EZS07$KmW?
zu^`aD+`@-al<298^#Xw{L`%n&p(g!99~?D;BWz{B5J~|zkhMT${=u;E_0gs9DiZHH
z>*BJlD@D)OzR%BEJaLT;fjpW^O$f~${v<_vJ^(9xM)mK_j{RG#5eOUh41)fZ{cG&s
zO7(t~%k_%yt$P~CtuL1s2prbBcVThW&6UKV`$bPf0``U~_Tm@VigJC!743-&xDMCx
zMgXp6F4*yUaB6Tb_#!t+2PBf^v|oko3)w>AVekm2LPjd~rmZ6o{GUWGcs&6ZdM|GX
zmcPRo;8=Md!&FY8&BPcNIy9(*m`S64R0O#gCk`4DV=~-0X9>h`7o`#^fB|99MZ;65
zxg!Vgxm6i1a1B?%qB1tbI~&iD5;jdpklp4a2D)Sk$6M=^J;lI5g1CSZlW2F^f;W2c
z*_F*sd`h7U+XUhIS<7_aRGDT0p}tsvgxa;rhMgkmKsZ7HThe+4G6NKGK^~G`P7{UZ
z4g>LFjt{Wt*pOq?_3Cl<tln&oX~MjLiW9f!@fz+8o^>6%H;(Pb3oaD9hgUt;1KwGH
zjC;IcOvZ_x(TIU~AIKglMpU#8bjy7oEI^K3a<GNM5PpO{@d4N2Id_HdxUXaBd%~U&
z)Y;eoJSWcUL%WB7SwQFs;UQq>2NS$<M4y*vk|gi7z5OQ`#wadEO#1jZui!wBv8FIU
zq!L}y#*OOg%*T2K=N?J6Vi>?q5{e%4Z7XSvo*z6_Q7XvVk3KAJeDg@TfGox<ObyoK
z6_BV~<$^=J)%IaXCWpPZ$v1Zeup7XKCH$s<+e($NSwq3p9#0Z1fvWddcHJ_-C+-UH
zq!=g^ELb9w%C+Y%u<4)-;4%|Iu<v9E7UH7a8`K5~qkiCloF^OTeYoGntYM(xhUydT
z!yUpJ+08ww{(<cbmab4PCo-CYIU(*!<!giK1dn~sX*LY6El-@YB9$j?vfu>Le5B1g
zS|#D^GS~swM9S`J9g|vUiyw1S%zYu!RPNzk7)N=|Nr4t^e_!l_16r>tpw3*Bkxh4t
zIImSfs6Ckqa~+n%skrn!lQTDqKZ)2UI1Jkn9K$81*wTDrj$QZm#LC8|m4Ms6x1Bz;
zQLg3B{Ary9EZ{I9rLhGaRpIFu7>!`wx%EylM}};7LG9sBaO(PyO;#Uy9Krb{aM;|R
zA_2VVW=8-FSm={yR!6Szakh^wQoon*sesEDVwRah!)jXXd)gt62yn@ruM&i3oR8OF
zPBgwpCFN3G;@0&gouUVMKlGy1Mli>(+YK-Bdn{p<GwqZyj$9SkHA~NGbvXLt0XZ4K
zbQWGOKVZg-pj?esX9U{qG#GU~BUsQfU5BlOV-r<ph{6%3-l|g*r2*5VYY;Rr*QfJP
zId|(YrW(Nlck8gVaDlr#9Bvyj<s4wgapDq}&xxxkLmsl4?U9W4GC(y3tY$|xO7n2H
z&mFkFh&w~DG(JZAVmadfaXbDn?1wEoY7FyOlz7E+Xew7B*%#<jcYMQE&j2Cb`v@V*
z0do>zz+-^p?L*lcBq`%Epzz`{_1*i%DsF2gbv}%e)cLSTQs=`cNu8#klKK@aQ{pNr
zhD%sKn@-B|-DltBQI4GFIPYySm_!=1U6M5TeoE5d`zc9-7Q2!L-)Bi0e4iz0(Arbd
z5E~7#(GVLAvC+87HLIAPXn*^i7QiekH9=M6LW)On+PF02oF%`c>2yyJM>=o0rfRIx
zPm&SFjnFodVB#AiotmL|R21vc6nSDIXXke-dG0hRX`$Ek|8qs&b>)9tu9k9c#20nG
z6v4yRsp)LHh|Kfyu+N-`3#WGQ{ln|(-wYScqczfpxW(<5HCzZKcwwGo7mwrQ{nEmY
z{bGzw9@t7+YDq1%q?TGzOD(CTmef*9YN;i))RJ0iNiDUc7VXa@ZNBuAwE5Cc(&kG)
ziLC4-va*x3MZYcjZP9Owep~e0qTd$%w&=G-zb*Q0(br2_iC)r5^paMhm$VYSq?PC;
ztwb+rC3;CK(Mwv1UeZeRl2)RZv=Y6fmFOj{L@#M2dPytMOInFu(n|D_R??-FphT}{
zC0+5X*RvA6o|WkJtVFM8C3-z8(d$`>Ue8MOdRC&>vl6|YmFV@XM6YKhdOa)A>sg6j
z&r0-qR&uT~(d$`>Ue8MOdRC&>vl6|YmFV@XM6YKhdOa)A>sg6j&r0-qR-)Ilk}oQA
zy_l8g#jHdxW+i$tE76NtiC)Y~WT7$9i&=?Y%u4iPR-zZP61|v}=*6r=FJ>irF)PuF
zS&3fEO7vn@q8GCgy_l8g#jHdxW+i$tE76NtiC)Y~^kP<`7qb$*n3d?otVAznC3-O{
z(TiD$Ud&4LVpbxHhKVd1CbDRl$f99#sa7Y8hKVd1CbDRl$f98)i-w6T8YZ%6n8=o4
zB6|vn>?tI&r;x~=LLys+iEJ4rz51@+zx#=sZ%4nN!~WF#`KJr&6#eGTa1Q@DdjUK8
z2L#m%=wWa20){4bsiu9YrhTcVeW|8>siu9YrhTcVeW|8>siu9YrhTcVeW|8>siu9Y
zrhTcVeW|8>siu9YrhTcVeW|8>sYl{2^+?>Mn)#)g`K6lqrJDJrn)xM~`5%0OkKC%6
zU!s}+FUQHvi}CHCf3pc;%%A@=8uAB*^6<0upD+~7Uz|Saw}&l8`iJ(rk&d$d%|@p0
z*Xasw%u^8kfAKgXety``&)6G=kA^$@H`~A6XE?Wp17A6|{xVpJ>d1aK|2mj4_Je-5
zei`6k9chm3_w9d;`Zv&Vz~@(fCirapb;0igzi<AA|0xiECw9iqKj@v~v-uVK)cC>H
z5q>s)8<1mIaR&OI0K8rCbHymP_-y?3p5F(3|E?6URS3x6l+!7{)eDT|eatHO3TJ;-
z#c$*-UyLUG=@=GX@i=H1rwPHcqmr9H&z3tXJ-VvOcTP+B58g6zn|qM!;Mrz5kia&}
zf{rpd4C#_l@7ek~cx0JuE$nv})+-nZ#yNJOp6Z+xL46!78iDY>a=N(BJ$UOhcq)Ho
zxWNNXj-XRid5C@0pP@XLvs~rGDEC%`^(j<@^uE&1gOEb$K63xk|9Vernf;#!rEwp#
z3cBwH<)33_3!I}J22y3T#^9;_C-&1vIqlkA(O>TUkt55)$W#4#&$i^5g&tSz-7@TC
z%fOS3U++f!$p+HG_t$5+_5B@faI*2l@9x83<W2LUm801@JH4p3;HhFYwnC*jT!n2o
zAW`yBP?+i?OKS2)spRS$4P}Zg0988O6;}#sLeq*X1M_X6Y2nrK+3sM0jRJFG+jO*$
z(`r6}N&6Ab$*ktR4_0%>s2;8qCdZ}((D&yaeGbZfYM8u^s9^=V$k0wO95L0yTP*Z=
z4A-AdU}2aGkDG}8&A}ti+MzL$N4dd(*OS%RUP>9$lhxUttj_jib+#v~vprdz?aAtF
zPgZApvO3$7)!Ck`&h}(=wkNBzJ(+Up$?9xRR%d&%I@^=g*`BP<_GERoC#$nPS)J|4
z>TFL|XM3_b+mqGVo~+LHWOcSDtFt{>o$Xy+*)0N?iH7nXO&qDnGT6i9O6moe>KIzP
zDX7yHv*lh4krF+_YQY1dE~F_ayn@(=jX-R$^|9IH7&vthM<hpJl`FE^qH=+yf7v&P
zOUm>wi?E8LX-hCz5K@{L=d@geA@XniHP}8(GEprTMwuU=t%CN*cjL`+;&gGqJuq+`
zfvCsVe+m8oOXbgVuYuOTf1bfOHI6@_T;<n=Q|`$ubS0aMDil2~G7NBGJMtY4xl`6h
z55e;Qu*(UHO_|$Pa%%0Mj9Z@2+~8IX?MXogVvcLo*t45q6@bEl5%5C`#YG*spoM8z
zVO%_|?BWr@G?1^AgO*oVI5UedsSRyXSH8B2cnxz@poH2Ip%+kXL7~T_4Xz8)M*RR?
zn9CNen9bbLAwc=U+h9kwu3ig?r^vV`upU^8K%S%0;?qAJ>(27qI+PS`4+xp{7iX+{
zya0=1u1Qj@o>Q%!Q>~s;t)9~c*Cc6Ed24cHNSj>qq)o0F(k55uX_NEsw8=G3+T{8n
zZE}8}Ho4|Wo1)+3nkQ{?&675{=1H4e^Q2ADZ;5_O^jo6eYQF2~#Nq1-BPq_1r<4D}
zAXxs(<l8UPr@z8};KSfF_WWe93+}`3gdpYM>OtwpQM6sV%PHn+rC+B%!36mLgZN-y
z=lpoh!t@h=x*6@zE^@YntBO*l&HLH?Pc4-X9)bnW_=0DA!85)n6MRu7_@YekMVa7>
zGQk&Rf-lMhUz7>HC=+~9CitRE@I{&6i!y2TI4{Rn^l4)pZqcWWakxdFHpbx=ecBj@
zTl8sT9B$F4jd8d|pEkzf7JZKPc*0inIoiW5`W)@y7JZKPaEm@id$>iPqdnZB&(R)k
z(dTFnx9D@UZ)vp0SM)jB!!7z8?co-Ej`nbiK1X}FMW3TR+@jCX9&XX6jq!^P+YG+o
zA79YN7xeK3eSAS5U(m-F^zj9Kd_f;y(8m|_@dbT+K_6ex$5-^*qR(~yMThHrd_|w@
ze7HrQ>wLIHpX+?MMW5?@xJ94qe7HrQ>wLIHpNpZ34i`iCiar-ZaEm?{LvV{e7ejE1
zJ{Lo9i#``aaEm?{LvV{e7ef~vE{5<GeJ+OJ7JV*;;1+!@hTs-`E{5P1eJ+OJ7JaVy
z;TC<a`Qa9QuK6!IT=U~A`dstFE&5#Z!!7z;^TRFrT=T;%`dstFE&5#Z!!7z;^Ivqh
z=Eqm`x#ovk^ttATTl8sO6mHSy`X6r5=lUOR(dYUfZqeuZA8yj`a=ga3zN@84c896m
zu9hWo?r=$BF0M!9Qh27=<sKxyOtH&7NPL-Mm!l}YOtH&R6kn#;#VC69)8g@F<Ey@a
za1_OtIqGs0#g{qiaumf^^f`*cE&3cq;TC<4qHv2oM^U(yBlU=`dPG+}qN^U!RgdVZ
zM|9OAy6O>K^@y%|L{~kcs~!Qn)ugE&(N&M=sz-FyBf9DlUG)grm%fmFX?(@MdPG+}
zqN^U!RgdVZM|9OAy6O>K^@y%|L{~kcs~*u+kLapLbk!re>JeS_h^~4>S3RPu9??~g
z=&DC_)g!v<5nc6&u6jgQJ))}~(N&M=sz-FyBf9DlUG<2rdPG+}qN^U!RgdVZM|9OA
zy6O>K^@y%|L{~kcs~*u+kLapLbk!re>JeS_h^~4>S3RPu9??~g=&DC_)g!v<5nc6&
zu6jgQJ))}~(N&M=sz-FyBf9DlGPrvogS+^u{isKD)g!v<5nc6&u6jgQJ))}~(X}4I
z9kGipcf{~j`{a%o+-jfP5rbRplRIK?t9^1u3~seg?ufyy_QM@9xYLdQ_HCX!Vi#TR
zh~X>x+!2FY^tmGjx9D?6?4nD#fUi=aT!34tP%gl&R45nVRxglTNH|xyNH|x)m#HM`
zWr=!OqF$D$mnG_DiF#S0UY4krCF*5~dRd}gmZ+B{>Sc*~S)yK+sFx+`Wr=#3_Lnab
z^|D00EKx5@)XNg}vP8WsQ7=o>%M$gnM7>P=%NN>T##j7H?r47*5SCJ+UY4krCF*5~
zdRd}gmZ+B{>Sc*~S)yK+sFx+`W!hi9(Ec*MtOe{Z@BHl%R=HVQ|8aZ!22Z)*f4s>f
z=f(0r7RxvP=W8AR4g5Fp-@<<z{~i2y@qdp0FK-d%Ge32H8vHc*Y4OwMr$amQd@@Y7
z5;#fT_kb|#b!!0~-TDc#Q&$o!1l+@=2P|iFKSS%>eFsnogJ4!it!JzRu*zcSjn!4k
z0UTd6Equ|m@I}+Y7flOaG%b94`@fBr<LNJ$Q2z`*xvoDD<R4sAdXVmY%yGConBX8<
z%IEe%5$?cY)lxt#cz=dg20p&TAuO~`iQJ!F|AB3?Ij%P0(Ked1Ek*9li!Yz+Kh^p3
z*?yWoHFgIX)oi)m_fDvNmK{{bTqWnB!e($oA=HP5MQ|Tp#=yNtcEEiE6l3-VX1_O=
zPhjhL6E}zO*w+SDiu{gl@dcgbGoGrzTX+bd*w34chv$v79Rd9VTwE)Gzdm&l;KnUG
zD582_nH=UGu;@Lwule1(D@q~wl#ch6nOyKNQ7A*;{l5ub97U?$Q?+Ehx1w}&9~1Vz
zGE?@RswEw~mbUj+l(_emQCJ~j%}OoutN4Pys&b6HEYRGmk`3NHSHuBOv$D?pR_MY1
zHmTRo`RVf0;it_{i=PHRO@8Y9eBK)@p`*d}1l=^g4p<2Q_Su^G>V24Ozqx-LY?;5k
z?S4P+c*p16;QEaBv`AEsnL7&YK1@HOr7T>6_0Ma7b^z>KY`lr?gE$E2dB{NsvkqdS
zK2%5>+k?njly(t-v>hNyy9i<04icyBK!-UyA((@y5PVcuxXAqDWUx5Eozp?KdhFNx
z*hxSmolbUf0<f6jf^xqO>-iWc*r@AeJajh11}A%dBM;Izyn$BBWPqY>_zGGa#bE;!
zFYr#YAK0J-g*M(43m&jCSo2@&MKYu;Ha?f}K-$7$)<2hW{vvntb4&uISs)32fn+<1
z+4_uUTz!r|M;<(KUyX8tQp5wAfopj4c<@wic*hb?@F91fKkrTk-<^~9dR=*<UF1H5
z`i#e6@p>BDscK`7YBP?60Oh*{`vto}e-L}F>A?WQL2<a)qbGW;eX#>Tz5fjJV<ow)
z;WJL?MiyjxJss}?-00J_ptG4fTe-7sPLjj3xY()47B#pZo^crxo8H&h=GulIw#4TH
zlAf+64<ot0Q|nh8p>q#lPaIg@inMUp=)m5HGBAIJ^$AE=(%M3xAK4sR-YNh$Ffeu8
zqsJxL(QtEB|6D)s*-v`#4_pnI^!b<@-qGlPg`(J=f&MwU!7%~>hd#_B-rsewC?1cr
z80>=u>*2%%TYVzwQ9d+Grh}uHXb*jWZ-xr?&M5E|xg2=pQ%7k)C#@K?x0>M{a1X3l
z(2D}KON?AAZL5+=R+LT{?x!W_(u}Y#y6AtdNA5=CZbt4_<ZegqPUP-J?(@j~C3mAA
zhIH#uy7egCdX#QGO1B=RTaVJMN9oq1bn8*NjVRqllx`zRw-Ke=h|+CD={BNt8&SHA
zDBVVsZZk@^8Kv8d(rrfRHluW#QM%12-DZ?-GfKA^rQ3?qZAIy}qI6qPx~(YPR+Mh5
zb9jjp&(Y0qZhErd9%sd1y%FBQ?bi#wM#0xC_*w;DyWr~-eBFZYyx{v%v($gZ+tfHp
zs(&u}8*6@y@P+WLHGg}}-&yl_*Zk*e{x6^R3iKiTi-5*D00N>IqO}gd7+(z0SqI?#
z!eWT?bpYnxJ2>PXkNVfoKX#$4m0?tZv&J(GSii!gU8w!(cVe=KTZql&=mF1N8-yny
zqXQ_buA$2gB>eUR267A|*oc0{TcC(P(z(q8Ms&D$aQyPXyK9SDaN!UTgts5&xDSqq
z`#9}gOyl%x+4q8flMgIHC_G>&!vW}Wu#0=~)Kt5jVqO%SMt5uRj0Y$l2OD5(IjBL$
z6h}@F95)#4@Qmjj?xIBgO_tCU&vxStS2{MnAv@0%KKdQv?74IU;2<y(K-&w*ZL+qF
z)e|gpOec`Z13cFTnS}$W3_`u8QpKsdV`a~ZF$bU^5E6wLf@}kVS-|69^8t^NB2PH-
zdK}a+$$}?@+QLP#!QJDai~|B_=J5$y#6Wf9XAh-8TnPNm10aoYlq?=s2h(SqRxx}C
zhvGxJ8+fW@I(jpFp1uX;!4?EEuGgX_INe}&E3WcTVUuiH!;unB(gKkk$U+0*QSs>`
z+g8BU&~OId1~@h}#5P{2<1yWYjTTnj;Mzv`C3C#b*L3L!vA1x}L4MzHvHF1NdCa>3
ztpVmSP%wBleexEI;K3H3?n9J{PoWQ0?`g&JB43%4s=GU;vcwz;Gh8-w)v=lf^1JI=
z7o0oRXW%m0OEmE53i)7tF|p+|_^tGUzwC3)BHYj07JN9GoYs8vbN<a|_3CQW@PRoE
zUaB0xZp{L3_LATh`W?<CM>UtKd2zu2#SO*I$(A+!Q3=%pZ=ZSFbv+!>cU@zHvl1$X
zbT=_^LWjY_Ht6Sg00;}L@v};+raE!OkC5hfbp-zbCV@;Ts=BR*XFOSqqVm+7pL2g}
zHi);IQ9T@ww_}9ztr*}94Ls%0L;%``LN6{+Jq~uQ7m(lbcRf379cj<e4LPcLm&*fZ
z>`d5s@x;Bn5zB`@Mg;S*9Cv}J^H(+az=OVpOjK~wYZ`p-T&Wa*mAqpj3pMr0B?<~v
zi!rn4|32lqf_-F$M}j7M@L-+|4HO$h7CYAAP|7>F9D=bEH%oSCWeI_n(`~uX+_v1f
zwQD8C76{FJ4A`M3?YZ6`0ObHcCn|Xl%N$ADhz8GF@HN^HsZA*mkG7Xs5fEB(C;k*q
zPyilLLk&%8f#<Z*P^K#=9SDYT$blv}ZWaiX(3C9P1j-Nw#4v@WLV)AGr{EZl7FkZ#
z>SMyz!EAnVvH=z9kNiOb!#QW(gAcD_HL`Ex^>B%mPv&6DHVQtriumK7Vv)E*TDORj
zR{}f8rKPaJ<}ul|H3pqqSZnaN2F(iSBEg0XE9!1kH9v9SezY6Bqp~@<8XG~9DjL?w
zqmnt9&d5<ynvA|@I8j%CBdGf<pFyAxgBV;xQ06T@1SoIL6i_DtHO!vb|6P=i0j?-T
zWS$Cm4XGT2D1dU(GJv@h&kmXtoSyopH8^%*@uHc>9tZ57fU&uGH}auRMvDQKrhQCC
z^oTj+EQG;yfot<_GBSFBJHj)o%qx_u)YgsLcR7@A(;M(02M%4X-Ua?J9zVMRdmn%*
z`3RF|*7I$JVRdtedZQ%>%3!o=jS=q(Fm_E09LHReeh0@KJDfoOHeGE~mUGNt;}du~
z`LrhQ@h}_fcBK?ohYpJtiqQ^}LG+8G7ch$BeFvQkd||(gI~;v*p%$21vU3|<IbH_G
zO@bFm{g|G<fME{I;qT-%1jhsihpZbs*x-Y)$yZPTt3l|opV#Qw?LBtNG0AfLa*#sg
zZv!-kkB;sdj)LNLRB=c=wgwhTj5p~2c!scml%t!IYg|?_4<7!-#Kf~Q>SG{x?F}7a
z1T{JgkY|n}s}>BhO;ggU<sJA4e0$u29}J=N#5S9Q-g%JvmkWpMJPOA#ywAaTh~b`M
z1_PlGEDY_`Ai-9^VyqJu;~{r(fXlwWKq76AJrBrJ$Lq@k9pX<CblBGu%=7;;!O9(0
zNocvovG-XFsEA3gj1m_4=lp4eVk*FJST!C&embC}-(K)iL_;3!QKJ+3L)?rLfEVHm
z0HhDlboKrP0>vcE*-H$Ct8le|8$bthx;R<$d+K?z7LN5V0w2~RXfPA1<jQo=zq>1=
zUo5A0Xs6i5+r`q33lA<nv17o6CHjBKJ29dJ@EydE3o(SGa?S@F`#9&1X>d+P(dvtW
z8=`9(R%jlu7KS~%5Qcz~o8ZvxmxYW^e-*oh)Y9agSe(<iyQba?!-%-^=6y$4nMk*_
z0Il+N6ciR61-q^5eWurmsVp7~#m3~_#OZZL5FV!y3#Gor4s`VUi|h`QGb-0Z-fYPC
z_GUU9>{~!2bvwGlK6}6Z0@8Q^X>Q$edW`j(`|V3d5Rdlo`BJHRZru!U?|(kPyI(lr
z!xKZiN4l(XQ=dh`rQ_{wm1kAC7jsS?lI4J!&Z}ZSPpoo3%K3ZbeMc|m_&f-`#a{9C
z6zZ8rqOlI$yz9db^zDKD^r4c-#UxA|3=WGR><TXin>Px*2_<7jvY$evB1n-+!#NH(
z7@=Q}+>JwbuOG*rveC@Bp1Xcb-Sznl2BB$)pw9=jxA^I=W;^=j{Yz}|V?!1-x|)@}
zlkjcD1r*x*AcC5InjE+dY~0RdkrTdO0Fi2mR^}iEF?wg)u%IJHDJqe&b1PSfPaW+W
zjKJufEHESzK@@0LS%g)?#d7!Q9;&l)?&v&0+4W4&Q_`W{y@Iepml^hH%zFUIgn1$w
zFOIl}3bAiTgsfB-=$LtP$Bq%H-S1FHU+T@~3hy@t-@aXX?B{rYht-Gg>l)_^s4i{>
zBf5beirgZ+j#8|TXq2Y79nwI%SX#V4Ln<ckY_G+%lYjB}r`SJBm964WQx!6fX?Ywn
zhf$)A-xo;5JbavThUiM(l3IfmQqc1Sp470&8!j^7^gKc;CbwtULNo{P301z~Y$haI
z^<cY=T$%9VfrsJUm=%{~0boqN1S_=)#x#sMkE;c5pS#vfQr4R3D*M(<k8jO%N3EIO
zwbo2fu{9I&N^2G=bW&W7=g0=$AI~B$4VK*B!FI629p*S}cRWIsy<dL?h9lHK(uZr(
z1S)nuAPqdI{u0!932J`Gi49iNb~iN<%AdU)h2iF|Utb3_)&b3RKx-Y)-o4K5ptN|M
z4Ia0#9U;e#!C<F(iy-{EP>b<uu26K8EtILq?=qk{qa+3}5HndG<a|R|-P~{zkb|J~
zu)@4Q2e>dJ7#@3^?&ol<w-_}lAP1oc6xH{6U`sh*YB>f=t9e$z0G?q_5%ka}Ymtv#
zx0;6@PDjg1?uFTo2zfgm%_7PR$f0?JzDAiu`EtSt669``MR1HuIJ&1~0lY-B*wgtB
z=$}kCaW@6)i;W-bG#fn8pKd&6KYmQ5LzC@5-+Y1c9ZpL_>Ykf>4|C_6OkJ`MyHJaJ
z80iXt32r_S_8-gnTiP9|_)8Og`gZxT09$gdX8W)fHee&<Yyh{yF{xRHG+scOFCeWK
zkoF5m=LMwu0&@NW^5tNipZe#QpgL~3!6FG}!jF$xX_BF4%w1u#o!%mM#FU3HY>au6
z$|!2JHk?nNqE?H69Cp~FFqjf>L3eYSH<ra@Fze4oKYn1qTVewjhU&+f(pAg}8fd`}
zHA(XvTfV~<EESO0G^@FXT<r0t3MQBwTcETtUc4RR(&08g+$-OF)al0t_3#FGtuuqg
zf9U=^j?8J}a}3bPya`=0%t6ZbV<Wu+Ie-LY3{b4yTWCocMRN*j#t(R1=N4*d1I;vG
zr4#J*@isvW<s296DMT&eQ8O8rGTp*O{!@(FC{~c-z7{8Sj_ijQh>+sh3zXsyN6?$G
zXclyh;zva*q5{oN>qwVDEaE`*-(nm87Ter_=Hci&I&y|>Au6HRq&WiEBzfCe47uL;
zHk#kzECs8O<!Z5cGv-SVI}1EJN83Y-Z2+Lo2nV)7ZdMT5J3NX&{j3&y!G&3J_8ou_
z%>i&n$s)0)RxsGMT2ygR$h&Vd=wV<Nyz<u(Z1qfjy8P)9bFqErODDs>-Tr+9Yh-&4
za>do!uMo{g4)Blc21kRmH2GiX2R;~HU>s)*R&&9AhV~5oADsWcP0Ng+uc(9``o-z%
zsDIAhJ48w~%=<XX$*Y)u&U~s@Xj;_N*t+`$g_O^A_uFv4P50Y!zis#1alc*nd+vU}
z*l+!_`*rl{j$Yl-t2=siN3ZVa)g8UMqgQwI8jfDW(Q7z*4M(rx=(SzAwhPyG;o2@-
z8{uH)Qu)*`@cQ*|@FPF?&@cGlZyogX>%uc1^1FECTYeuNeA7?<^y|Vk9Q_9JE4Yi-
zaN(QapYWzj2M@ZN--W}2*XDQOTP}Rdg>Sj^@S42B;nj2db@5s*9?Oa8u$=Vk;<KFO
zZ~cGmU1@Y2)s?<g)g@K8EDKwbQJ33vgY`OqWP=vV*aqT7-ep;~<wZ7NyCpBr)@HT5
zvKiulF@zWhOMoN}n+aRY;6T_3A%rCmvzU-TW`JanLzv)&%{W2x-S=L#C1U2xIdkUB
zkFkC3_uZ~~uWr?Q-@Emyy1Eou*0Qi3_hWF?*@s<qcgK9F<LMf&31dx-`mO`dH&x>~
z15IU`$~9GJs?;=0Q<bLSnoiR+Lem&cV>OM_#7|Hm!gx&+6qV_CWjbD&j#sARmFak8
zI$oKMSEl2Y>3C&2UYU+prsI|Acx5_XnT}Vc<CW`p<vL!uj#sYZmFsxrI$pVshd*7<
zdyT(fu1Lo#*YV1AymB3{T*oWd@yd0)3LURP$E(osDs;RG9j`*itI+W(bUgfZbdFb{
z<5lQ*6*^vpj#r`MRp@vXI$ouYSE=Jw>UfnpUZsv#spD1Zc$GRH{^B~vtJLu-b-YR)
zuTsaW)bT2Hyh<H!n2tA0#~Y^O4b$<4>3G9*ykR<Cm99{wD^%$URk}izu27{bRGA8T
z2k|$~c?YZX4p!+MtkOGJrFXDO?_ibQ!79Cj!*#sjWuY+(Q%#|<4C5H88OAeAV3^1-
ziD5Fs6o#n`H4M`jY8j?8)G^Fpn8`4Up`Kwj!yJaW4D%Qo80ItJ)@D-(zqf7*H8S85
zrYVFwhD{;7LaQmXjA1zg9<pf)tzcNmfcu6`p%w;Q{WOKz7%-`83aw)3V8COMO`%SP
z)eLJG)-tSPSkJJ5Va!6=i8cU?W2j~r&oF^uBEuwx$qZ8%rZUtpOk=2Jn9fkgFoR(x
z!z_k+hS>~r80Ip}V`yNQ&w$xgC)xne$bes!ccKjdOBt3iNQM;*D;b&@S{U%CK_?C$
z(9W=mp@RWmbamqJ0r(=R6Ne92%dn1NJ;MeDNI<d#BuhZD1SCs9vIHbcK(YiROF*&&
zBuhZD1SCs9vIHbcK(YiROF*&&BuhZD1SCs9vIHbcK(YiROF*&&BuhZD1SCs9vIHbc
zK(YiROF*&&BuhZD1SCs9vIHbcK(YiROF*&&BuhZD1SCs9vIHbcK(YiROF*&&BuhZD
z1Z4IY{WmGH#~H3RJkjtJ!&42{8lG;r&hQMwvkcc8o^5!J;kkzA8E!B<U$cjw=BPiC
zk!}81Ms}n5++=vE;pK*<;T48g8g4e+Vz||CyWv%aI}E1{cN$);*;^Cr&|0%%o#FL{
zH<*HB7Q(@(^2P?vxWK6nobiD(A#f%J&ZNMZ95_<~XKLWo1kSX;sSTXzfm0VaGXiI3
z;LHk~`oNhTICBDLZs5!doQA-eA2|3%QXgq5a2f*#@66Mya51VKT%&3S_pP+EJaF)!
zkzTSQa8?EmzOK-#S^@_b_<9L$1!$)|a8?CQN8n(Vugl>2UpuP<XHDR&4IF%9pv&Mk
zvvxKZ2N_~%2QmbpnqfS{1cr$WQy8W))G$nAsAZVWP{%NXVHQI@!)%5*409RgF*GnN
zW=JtKGT^(I4kQA=QU?Aq1Bn2DFVs7b2mmV?ni*OcS{d3H+8I_cbTFhDIvG|o;Efj@
zNCbd&4C@&-0Gu(Ylrt7q4I2-e0GkM#44VR*3af!lgH4Ccg4M%j!{)%|!sfvmV2fcX
zSR<?nwgk2mwhXo$CSfaJD`CyB7Fa8+4b~1@1?zyNVV$tmur;u?uywHYunnnHHg^w3
zTsHR*^EkuYS^Sy%i<!HOnR|_SlHtjQxg&Ww_a!rTCo}gbGj}R8_bW4ZEi?Bn^Gw6s
z(fpbFnwh(snR}d>JDr*Pote9ydA?y*0e@y8FtZkzSq{vs2xb-qGwXtxrNPYVU}k|Z
zvqqR%Cd{l9W)=%G>xG#m!_2B-X5lcic9>Z{%&Z`077;V+h?%9t%xYq0L4h%R(rFAI
z08(KZV+ep0n8p|aAoZnjf(0Pur7@ZSNOft9CIC`g8lwq-)Rx9*0wATOae@UPm8CJH
z07zkJ3@HFoR~kbKfRvTS2^N4<mBzRNAVuM(69ZCH8siFpl$6G}0w5KoF|GheL1~OD
z08&pH;|hS3lg79LAl0NXt^i0eX^blXQcD`+3V@W7#<&6?m83DQ(rIWk&C@YxR5P~(
zf9A$u=JsIbCSm4QVdjQm=C)zx=3(X*V&+C-=5}J{refySV&(>8<~C#IW@F}-W9G(V
z=JsReCS>MTWafrs=C)+!=49p;W#&d@=5}S~re)^VW#$HE<~C;LW@hG=X6D9b=Jsah
zCTHeWXXb`y=C)_%=4a*}VCGI>=6+!2u3+ZgVCD{C=00KOZeix0Vdl<ZR{bM8b^m}>
z|A1BhfK~s1RsVoh|A1BhfK~s1RsVoh|A1BhfK~s1RsVoh|A1BhfK~s1RsVoh|A1Bh
zfK~s1RsVoh|A1BhfK~s1RsVoh|A1BhfK~s1RsVoh|A1BhfK~s1RsVoh|A1BhfK~s1
zRsVoh|A1BhfK~s1RsVoh|A1BhfK~s1RsVoh|A1BhfK~s1RsVoh|A1Bhfc5y1X8cIq
zKbW}c@gvRnk!JizGk&BQKhlgJX~vH<<42nDBhC1cX8cGqexw;c(u^Nz#*Z}PN1E{?
z&G?aK{75r?q!~Zbj2~&nk2K>)n(-se_>pG(NHcz<89&mDA8E#qG~-8_@gvRnk!Jiz
zGk&BQKhlgJX~vH<<42nDBhC1cX8cGqexw;c(u^Nz#*Z}PN1E{?k>gw1kmCX47^)e@
zGfZHZ$S{dvGQ$*xsSGs?(->+QrZdzr%wU+wFpHs{VK&1YhPe#$7#bMnGc0Dn%h1}8
z;{i<!_`bFcIUayt#J3^G1Mq}Z8*)5gB?G?FXhV(%v@+m9pf==qz$%6g2K?j@zgu8f
z&9H`HEyFs7^$hrq3twZkb>asEcps$f41B&|^~T^gmVA|;Jr)nWfj#{WO*qv{@Z1EJ
zM8@MOaD2_ch34x*S>tutdOYK;Do@5Q?zu8v35j=M!l_x@(!`ECjW6%rT7~oYHbG=M
z-nPh(HexZ}d6{a;nz@{B5cE|W)35x)M-TUh`N^uLta`jG5Y=X9_9CkeFAT(rahmFI
zP$;inn!rx$VtiY|&f?(EQs&U~YeBIFzbw^<wj{IB><#A7Oj&$&uMbU{L&NJW^`SKf
zht{GFs#W1Sb!d2gJ~%YI{t&y^p$<(yOND2k)B$;clf^$$#F62p|E7Jj@OxLThR1H1
zupH#!S4{YdC)G3n&lKPXu+4Y^4No-Tb|}9`F4c65IfzWt^;P?R_@mnM%*Q^6argsv
zF!Lb?zcyLlf}gr_P^}9jH>C>*Me72N)`jfM=mLe5E@Y?D1&U~0V7bx-7HD0-(YlbG
ztP3D?0fa8Fxj+|K09{~XtP9!MOBdLJ)&*9xE>JDd1(vWbK&%V?q{MD?fr?reaI`M4
zcS;vnpmhO9>jE1Mbb&%j7uX!j0Y$Vfuw3Z^3$!laXkB3Mp$i~%0fa8Fxj+|K09{~X
ztP6bkt)8aSa=-=xN9h8!0$rdy>jK2O;7|I<v@T@l5p^LuzoHAYWKUh-V^3Yk&K|nJ
zhr_x+zR2hTJ8AL-PIhX1$RJ<HAYaIgE^r3a`9kV^A&oAuT;~fJ<O><(3#syjRQW=(
zE>be1i<DIPLh5`Wd+8!2gM1-%zK|JRq@>OlQs)bN;!!1od?AB;A%lE@^PV|0lP_eD
zFJwj+I0T(9q|ya8r*(nlI$z+IQ955pqYLak=L^ZY0CK*N8C_rj=L@Ox1)h!OZ}Uu=
zkU_qXI$y|)E>K?O3#s!3KItPf`9dC17b*D_U8H0$UEpI+U8H0WUEsrEU8L|E$V|SF
zIa(KLz8X=|P;QRS8rs*1L;1PEIYn1cGEr`LJcgMru9Ju^p!A{_PgU)zeVt8|?;)XR
z2RTJMkdJb5gUq5ABe^Ii%=txm{ZuHE`_z&gon>@6PBhBP4RVcM&gn*boN>%Dbb<16
z^!Z5pI`wE@XCLL`$)C*8YOU!aIt?j5H^@Y~f)br_!-uPC>FEMWeag+z0@S|FP0IHm
zL+wC`+JP9AlN;nIy%>^IPMEWm@{Z{tOtk=Sg5i^zF2<)b<>4)(`i!QRvq-ha`O7TJ
zw3Ak=TFQSg=ATY*YE6FcbDUb%PaSv9UhCIWxvESaV)rbOcUZq_ecz0P)yEzxmWNd=
zd#G6E99FUHrD7S$s90uHEOQR4SVl4`mN|!2EOQR4SOzMVo>8&%jEZG16-&>kSY}i#
z|4GHNhl*u5P_gW#Vi^upEW?3{vCQ<2?4e?rb6Car9hI6}aiht@Dwa8iRV?w~6i>2L
zkzOj6k&KFEM#YlfToM$IWK@h_&1HtW%sH%L8K@ZPTZ>M5M#Zw1ilt{%EHf&WUsbW}
zp<)>hR4jX`ScU@?%W$A#EX%ahVHL}-Rk1vRise74SpJiW<yTZJzoKH<Tg5U`jW>Jo
z&kHfP#4i_&ixU=Jxs6#RKZy+Dr`j>k(@(QwYOkI^XXdBZv7R4O$9nyaB{=G-Wh}v~
zwbcg9_ELI#DZRZ^u)UPo9$0NJrMH&~wwDUFmonQ+>FuS{YI`8wzce1JQBT|BCY63d
z9?aXrdi5B6+H4O6_5Put+CRJ>ULCI*)?xKvIp0bN>#f3r-qho0yfk9Atz5l%E~_JO
zS=|UaMFerUun7fM?|ln?F^t9mah#Smv-d4+dheNe^H|T@#(KSBIC`rnpf=gkMo0f0
zZGodLaI^)Ew!qOAINAb7Ti|F5{8uetVP(WBa`uv2J)x$a>hR{pW=h~O@0GM14;#1A
z75F9Saun-N*0@<U35pPPcaudzaUTj%4%Q8zfs{=rQYoE^Emlw!mg65vW>X)^r(-Eb
z9-Tx(GRt$xrCchYA{s<tO3=wPl*+K(N*Ye(<c_JGn4lA?$JAoYgqdR!l&Tq1pP&`B
zHPs24Z}uT+_!!0gD2w`1A@!pu9f$pl)A3Y7r(kO~oj}9rG#X*b4>nw^*d~X*k=ZYs
z^2n!=jpgY^>l}qm3RmC<Vx3ldBOax-)+xL|;iksMmUe54!mAbDsPLA?HK&$YcPZSV
z@Ii%-DSWyKub#4=Q}}WdUXWwGq3~^m?<w5V)Y+W2{-*F_g<mk*q%e#BMvmP_;Q)mR
zg(ok^mhDPB!`^I<R5+U7Pi#+8SgWwUxvjC;p099`!lkXNTRQA!g&hjlDZHQ!WN%Wq
zMd4P3*Wo40?e@(IZ&7$Bp1n`o_bJ?|@DV(jpSGV;_^iU;q}SqiKCeO;7F5w2ZD{CN
zwXEPPXybDZ?CaPf^gp)vb=X(cby&G5#fm=?_EXD`j1E*9g(?V2`L8?+O6IK(0@@f6
z%ocRdn5!^PVSk1B3JVqTv03T}dn1n`OKGz=W~=2rF-tA!iLP4G6Js=(CQ%*DqeZlw
z+G!naq|LOIZlG;+C+(o0(^K>u?V>m79oj>C>2owx#4502R<TuTRa&Q8)mDvFZ=I$0
z$cka#uz&VrhTqi7?T__mXM*9B=FlaY-Me(TtZKvS3~x4kgD&S?tv`o3%OFnpWW#lO
zeRz%GEt(@mhBq6&+VFeG45%O3qu7ponbSvmImhLc>UB9ahTC<WoI5o4F~``)Y%8}$
zFVCH6c%EUiFS#gZO+nwEP7~15^Qnni(asms6?7e1`7YW?PoRxorMKyQwD1>J$m(kq
zStp=<tE|!3Rwy}<?81G@o0Rb;XS^vHZ)(P?$#~N;UTwykp7H83-i(YlGvm$5c=Z`?
zcE+2N@#bc{c^R)E<IT@_3o_nW8Sm_jcTUDznDG{6yv54nT%3>p6n;7UGWvgi_yF0F
zvPe0FBBLUwQ&wb5WGs1+S&@2*M9zwwLwzEPB8w<5vLv#Ej)~kFxsCeu`(3{`DZl?|
z{YOw?|B3x4(XsvUW&n(58zVa6wR@|)4iEQByw%<sZ>_h^TaPssqQ;;ZT_#26QYWqU
za5KkS>Miq@d$LCvi>i?q`XDn5<z5T>_|zX~KpTqc>%F8tP4He;j8;@jUsa!Gdao%)
zJA#YxpRlcJY-Ixe+xU+?6eozmqF4x#6yFdhij&02q6BLW@8N!0;~ilS-Qn&CQR$9y
zPZz`7Gu>~xqunv?Sa+OT?T&XRx|2nf7%on8r@A%ym%7u$2r*KOa%<h0?sj*UTkqcO
z&a*qbM!VCUZ{O-J@Y>w7-NoW`d$oO=n{pf7rS^LJc6)>Stcr7nI1_P3x!)8VXRH{_
zQN$Q`q8N)v<J_sDT8u}G31Xs{<SuumyFyGBQ^ZvF1yLiWiCQsT)QK5lrkEw_#cVN0
z%oX$8m2R_W5c9<Xah5n+oFf*BMFPq|mesveOlKggSJT;4>`Zl1bf&YyxtQiSmpNOg
z&AHO~F0FE|bFQPb^AqPT^q@`LR!8V@krIufNh}dd#WJy6NU=h!6wRVVw2C&-E>?*S
zkrtg|wOAw8igjYW*dWgJE)?g9^Th?;MscCo=xuUa@-Oke?Oozs>TUKe@-7n>xvkz7
z?{c@zZ5J1N7mII+O)Ac}#U+SyE}~qDIL%_SigFp^Y(b>U5#<W;9mKd&d{=CBSGgVH
zDsi>AMto0PE3OmQiyOrE#f{=7akKb=n-)J5KN8!-kKImpwYWvxDsB_Ei#x=2ai{o+
zxa)t^RvT!fn`19<^W0<H{)L0>V*4Ds)Gc%e*o)mFyUO+5!G*WjV+)Jjr27rG#4Q!2
z_6&E3s#7M0xc%KB_BmoG>I`tpxrR6ebt>FSajH1gO^Py6E=t{Dg@3UZh@qm~tq>I`
zS&4nlQhiFQH+|Kc6{<Ifsoor}dh;}lfGU`Wd1N2VBV(B3omluE7)O(-rtoiyrx$*J
ztxYccE3l^UL*R7Ouu#I{`7G*UycT|h<#XX#)|g()_Xf*p4%Ynvsw<)?bROMD?^ykD
zCR}6P$zvI@eav5zR4VQ!+k05tLw0D4xEDB9+(&l7pTtjre-=A{|NfO4_p2KJqG~*#
zYV1@sex_<Xc!U}csTx05H6B(q9#J(ORW%+vLXF2&jVDx%CsmE7RE=M#8c!dg#xGTk
zXH<<}sT$9!8oyRGo;yN~-KxeLs>bhBjW<<|->VvbI6{r*RgD)^jTcpo->4cdsTwaI
zp~hRP#@njKA61QiRW<%i)p+L!HGZpV>{2yeQ8ivwHC|ISURO1sHs>$SUof@%tMfOq
zoPEwdazlMXeJLwc8Y-pif}I6Bp%j~%sp5ZYJoFq5q5`q_Y;XqliL;vTT<ctms~8Jc
zH8%2H0jriihCf7kpTL_2&&Jgk&rXu6R1BDfk+B&(N#TjA^quN6mo8RknqH-?0$!_7
zm9`2qrOOF31#Hhro|im7c>#PoOkvFb{1(53Khc>KOQw>I$)@CzSZ=Iua%pl|a(PlF
zS0q;^o0Bcc)?{0<J-I5`kxVB$ldF?!l53OelIxQjlINm!-*91g08#YT=xt<2--!N>
zLVm>0p)9}BA4Z<P%wJ9s|2qGA>f`^?e}?+{pZTBDF#}5mmQw$L3kNQuf`Qiz{2mP$
z`0IhsQPIFd1OJY3X`?lcNnVuPn7lA~aq?TqP04R3FG*gS+?>2Dxg~jd@`~hll2@Ws
zuJgF_INJMp=Xq%0We56m-gDj~$9dm*pF&W`2jn_`gF>>MPn}Q63)vx@heBDQEQ*A3
zL%Ea_DuG)16g*$>0&)WPlU>;EZc_bnGV+Fv-s|I(JC)99&V$ZF&d;6A&Q;F8INx-3
zI2id9b}F0-?7=W+81`U<GXi@s$~gmju+`ZLjb80sjo5cP_mJn@@7zxjXQ#6h*G0C<
zVj~d8!WFIq<jhvY^Ih0+KuayPFze^FyoBc&2nDln)ul_u;RhufG9`y{K~pjTkGGjX
zOxqjo4JX36bUl{wY^1-MF9q>WFlCQFVp)Cm{%YA1j!-tl^Db=bT>Q7a6y`Y&W?>Tg
zw=u7-jQ%Y8VDzEr&!Z1VABjF1eJuKT^oi(`(Wj!nh&~<tW%QZoucFUJe;s`;`h4_-
z=!?<cL|=-&9Q|!{SM-(WtI^k@uSa)#Z?V>*Z$^I~{X_Jv=-bghM*lVXZ_#(6??&H?
z{wezB=)Xtbk9P5%=@F^UOsp$J_s9Da{E7Y~f3iQtpX%56)BIY0x?ktd@Mrq7{Ca=3
zKgXZz&+{An`Thd`EdOl(9Dkv|$Y1QI{6@dYU*a!iUHj5s;ji?YF_K#SHox6p<#+gL
zztdmsukqLV>y8lpVmdQ6IW{FWHC7Xw7ORa-kJZIy#Ae23#p+|TV{>A2WAkDSu?4ZS
zVrR$Bi7kvRiY<;c#+qVFVoPJoV#{MPwj#DN)*NezwZ__F?Xgv{j#xU@8CxA&6I&Zw
z7h50O5IZ+^L2P5};^cReTVof-E{e^MogX_dmP%fgyc&BHQMpN<ql=s^m~oY<b96bf
z)pb;<&e2uQz0Q4fTKL8Ai!?I4E4+(F4JsQ{j%y>W+6L%`b*Vq`m6Syd_!OfY=<5h`
zTC59{_TQhq^Xz^Vl-hfS|MkjZjYsG<y2IQPtLkx2Y_z&3Hihqr;kx;lUiZXM4fnf9
zU88>08`|rR)`{wl)<|_nYqYwfRcY$#dS8cp6>QeQ;r-;hC||&A+`%F`fMp*OpASB@
ze}U`rr=2q7kMhtcvO=ea#*z~n7upa1fQymt+U^Tvxi4mg$;pa%ca!Da<NXHX>!tk9
z$;v;Ne~6s?zZZnaDsT&m$te&8@4|l%a~P-K{et)5cNOe~zpoJOP}r}qKRJc@g@1wn
zK_TW&h5L|NtO3@5zT^zZE5cl>C|uN!oTC0kI9nCf7R`h|s|a(eqPayY;Wrnxz;7+;
zgulAzYWUX_T?haAXg*odg6IHpqQ^peeD>2v57Mm-E>`V9HujXg&`>b$_+$+wBx?LS
zk49srcsjgXy1-fMTnNox;r!S=CF`L7L~Qe*gYm-np!oRswD{b3LwrH}?D+Zdo$+Vl
zuf^Yre-!^X{$-*mu_|$8;^xGYiM_{PUYsnRQj#vYw&dZG=Sp5J`Ka_jY4^~{r?!?~
zU;h1R-L*sR_|f+Jwm-DJ`|c%&vcAmw@|5m>C~a``1Z{IRIGYgtO6S(Bz5b5a#z8db
zP`oIfh);^wndl4S8{-egpN+o}|6_cA{L=&_mL@tATNB$7yN;*hw-%2sUR1KC<c5;R
zOI|4Xuyj%B!6EOM=uaW~=<SK^JGOsz_o;{IOZqa=eGt*D?oYb^)cth#Q{9hsKid6B
z_rw1<_`$e67w^g06WQbK$=VazWACx{P*-=?mtBAFI@I+=*XLcIb$!zHao2&a{at&z
zKI;0g>+P<Wx}NXa(REYT_q(p|`d-&HT^qV0UGDqh&(^!YfA`I2A9!|rYr5qC{_k9|
z$^YQkeaF5#ph))&cf$Y4zbu>Y{P9lki0S!{&s<6z279jS?dzHj)aGJVm5p<580yNw
z_{+uFJ`b6oAI^aJn41-<`<VJJ;Xq`vK{(^a(dWnG`eZOvDljAY2JV!fggf3Pn6VAP
zU4v6_*Srifyb9d?9)_!$;p$%XNE!vbo`HGQH=*4zG?vEU>@yyB1}0)gHyLw^shICg
zqgq_m)X@yg&t_3Q&BoQrT;$XS+<RI;XW`oT99oF`eT#8Gm(Znj8C_1-;Evx9=~lW$
zWx3mFJN<<2#=WU~=wA9Mu5WhG{qz9+4EL%Y#67`>=rMYf9;YX~eCojctR*D9Lfq5(
zG43F)^gg0Bv?6j6W|%jIyC@wQ5*bR%Xf1O7AHr`s>%$*o-h7^S0QVOkp^K=ITEl;`
z>LdNazoiyB--}WT_r|_W*W)f@p_k=ldwJe5UXIs?9?o4tzpzH)JaB_o>J2IUYvG4p
z0j>9Py?)+c+JyUQ-=go(7Wyvo@KtmrU5oo`MBk&E=?8QZ9k4gsKcrRmjrL9U&9uS(
zk^KYvvZI;c|9K|hvn6HS!-#+1(WH>aH{YRW<BX7iT>#@b@;1;~a0<Kub|GveY!hq?
zY&7f&V-vww!hQ^!1iO{UJq3Ig;_ihV#F+`#n*I*h6YviZ#Wun=qa5P$7Y2h+#>Mv?
zgANhJ@$Ens?%>BUpO0f@b^^>c9)1#x81ZTFYru7|x$tL#8?<H52QSc;&3v}DZ0t{b
zA?$pV=VjQ3_)hrefgglD1OI;Tv#{6TKLvgR_7?n?!GDB(1pjsLe%QzGyTG5qzJ&jQ
zZo)(pd>mt9DQp$47v_OGVQ3={>k?aGH^WDpCbq$zgpamN?1JrukG?vdV3)&x35@c^
zIPNfxuXr?U3ceabx#C4cC29DFz-wUF66NE&mXaG_55q?vlspc54*m@A3ov{Sm5*aD
z`4EO<$;UpHVmqbS-~1I|^h0Skd>qe^cZh~gCMrN*oZ70bppB^fdTj;m;O}cIz;RA{
z3WmA`*r(bd+6p>|?idaG5tctdv^@d4kEk#oyaV<SeCTESXE4+)yqoCmQ(;Tsqi=9%
zbSMk{2ZVDvED!!ZFt+pMDMSM-%nh;6-T#2!k1Tw&ENE)L0B|;}0)7-c9ESEEfNy84
zt+1Qm{}8-Q84b7#ybH$L!K~1J2ZrDSeot5o`vm?cWW56al_b%ze+8ce+e1`@Yfm(*
z_3C)|uafl|{MY8-svdKI*A~IhHqkb+ARFuTdiWQCF#~)Z8i>9D#(unx_VEXSZ&5}*
zu1sIQ9d-wnC%`{}K^OiB;QL_cUq1<cR2li@;KyOV#PSO8ugKbse)C6y(GI&K@XrP3
z!V2JD2u2(2j={eaj4R~bBj8^N#>{#5nefpjyGO&S;Ung5v>lB62f$Ncb?|qBXOi{C
z?eMWLZ`?`N?_R{%&I7*;L!S=9{_MrE?=6A91biy&8u(X%x51!?L1^2(_rspV<vV8I
zdoh#W`&;;!1@C<YhW0-W$BwSI_Vs~35sVr5zM=5z!Pw@$mGINxb{N{~xSxVCW8V)w
z9QPp@<@b-mSPg@5T>CkX;J(BDI@k>OXMz{OmcYmQ1Bmr0IxUXl{`4If#?0V>;JvWV
z;p1)*WNUqvhF=EW2t)b7=r^pkKF@*w1sHKZM~*Dc0wdPv4e$}`^F^>r;ZFi@h20Ck
zoh-=NI*7W(=!=7>dk}q5d?R=?tOow`U~K0gj<*>4Ik*vaJ^cOPr<9S1fOo;(ClWcB
zt8G+9;$85?FysjF9{5JsHuwj@_bS6wjq;r7$|z}39)?<80^=@;Z>AFclu@!j_(T}S
zU@{-P5Y_~LAb2UP4gT?z_ez5@N|u1rFq})0rId%UoX2B1SxI>qzj@t<;6rEs2}2;W
AoB#j-

diff --git a/documentation/src/docs/asciidoc/resources/themes/junit-pdf-theme.yml b/documentation/src/docs/asciidoc/resources/themes/junit-pdf-theme.yml
deleted file mode 100644
index 1cba8c427dee..000000000000
--- a/documentation/src/docs/asciidoc/resources/themes/junit-pdf-theme.yml
+++ /dev/null
@@ -1,6 +0,0 @@
-extends: default
-font:
-  catalog:
-    merge: true
-    Symbola: Symbola.ttf
-  fallbacks: [Symbola]
diff --git a/documentation/src/docs/asciidoc/resources/themes/rouge_junit.rb b/documentation/src/docs/asciidoc/resources/themes/rouge_junit.rb
deleted file mode 100644
index 003a88b51955..000000000000
--- a/documentation/src/docs/asciidoc/resources/themes/rouge_junit.rb
+++ /dev/null
@@ -1,148 +0,0 @@
-require 'rouge' unless defined? ::Rouge.version
-
-module Rouge; module Themes
-
-  class JUnit < CSSTheme
-    name 'junit'
-
-     # This is an extension of the official "github" theme to remove accessibility issues in code blocks
-     # Primer primitives (https://github.com/primer/primitives/tree/main/src/tokens)
-    P_RED_0        = {:light => '#ffebe9', :dark => '#ffdcd7'}
-    P_RED_3        = {:dark => '#ff7b72'}
-    P_RED_5        = {:light => '#cf222e'}
-    P_RED_7        = {:light => '#82071e', :dark => '#8e1519'}
-    P_RED_8        = {:dark => '#67060c'}
-    P_ORANGE_2     = {:dark => '#ffa657'}
-    P_ORANGE_6     = {:light => '#953800'}
-    P_GREEN_0      = {:light => '#dafbe1', :dark => '#aff5b4'}
-    P_GREEN_1      = {:dark => '#7ee787'}
-    P_GREEN_6      = {:light => '#116329'}
-    P_GREEN_8      = {:dark => '#033a16'}
-    P_BLUE_1       = {:dark => '#a5d6ff'}
-    P_BLUE_2       = {:dark => '#79c0ff'}
-    P_BLUE_5       = {:dark => '#1f6feb'}
-    P_BLUE_6       = {:light => '#0550ae'}
-    P_BLUE_7       = {:light => '#055099'}
-    P_BLUE_8       = {:light => '#0a3069'}
-    P_PURPLE_2     = {:dark => '#d2a8ff'}
-    P_PURPLE_5     = {:light => '#8250df'}
-    P_GRAY_0       = {:light => '#f6f8fa', :dark => '#f0f6fc'}
-    P_GRAY_1       = {:dark => '#c9d1d9'}
-    P_GRAY_3       = {:dark => '#8b949e'}
-    P_GRAY_5       = {:light => '#34383d'} # '#6e7781'
-    P_GRAY_8       = {:dark => '#161b22'}
-    P_GRAY_9       = {:light => '#24292f'}
-
-    extend HasModes
-
-    def self.light!
-     mode :dark # indicate that there is a dark variant
-     mode! :light
-    end
-
-    def self.dark!
-     mode :light # indicate that there is a light variant
-     mode! :dark
-    end
-
-    def self.make_dark!
-     palette :comment     => P_GRAY_3[@mode]
-     palette :constant    => P_BLUE_2[@mode]
-     palette :entity      => P_PURPLE_2[@mode]
-     palette :heading     => P_BLUE_5[@mode]
-     palette :keyword     => P_RED_3[@mode]
-     palette :string      => P_BLUE_1[@mode]
-     palette :tag         => P_GREEN_1[@mode]
-     palette :variable    => P_ORANGE_2[@mode]
-
-     palette :fgDefault   => P_GRAY_1[@mode]
-     palette :bgDefault   => P_GRAY_8[@mode]
-
-     palette :fgInserted  => P_GREEN_0[@mode]
-     palette :bgInserted  => P_GREEN_8[@mode]
-
-     palette :fgDeleted   => P_RED_0[@mode]
-     palette :bgDeleted   => P_RED_8[@mode]
-
-     palette :fgError     => P_GRAY_0[@mode]
-     palette :bgError     => P_RED_7[@mode]
-    end
-
-    def self.make_light!
-     palette :comment     => P_GREEN_6[@mode]
-     palette :constant    => P_BLUE_6[@mode]
-     palette :entity      => P_PURPLE_5[@mode]
-     palette :heading     => P_BLUE_6[@mode]
-     palette :keyword     => P_RED_5[@mode]
-     palette :string      => P_BLUE_8[@mode]
-     palette :tag         => P_BLUE_7[@mode]
-     palette :variable    => P_ORANGE_6[@mode]
-
-     palette :fgDefault   => P_GRAY_9[@mode]
-     palette :bgDefault   => P_GRAY_0[@mode]
-
-     palette :fgInserted  => P_GREEN_6[@mode]
-     palette :bgInserted  => P_GREEN_0[@mode]
-
-     palette :fgDeleted   => P_RED_7[@mode]
-     palette :bgDeleted   => P_RED_0[@mode]
-
-     palette :fgError     => P_GRAY_0[@mode]
-     palette :bgError     => P_RED_7[@mode]
-    end
-
-    light!
-
-    style Text,                       :fg => :fgDefault, :bg => :bgDefault
-
-    style Keyword,                    :fg => :keyword
-
-    style Generic::Error,             :fg => :fgError
-
-    style Generic::Deleted,           :fg => :fgDeleted, :bg => :bgDeleted
-
-    style Name::Builtin,
-         Name::Class,
-         Name::Constant,
-         Name::Namespace,            :fg => :variable
-
-    style Literal::String::Regex,
-         Name::Attribute,
-         Name::Tag,                  :fg => :tag
-
-    style Generic::Inserted,          :fg => :fgInserted, :bg => :bgInserted
-
-    style Keyword::Constant,
-         Literal,
-         Literal::String::Backtick,
-         Name::Builtin::Pseudo,
-         Name::Exception,
-         Name::Label,
-         Name::Property,
-         Name::Variable,
-         Operator,                   :fg => :constant
-
-    style Generic::Heading,
-         Generic::Subheading,        :fg => :heading, :bold => true
-
-    style Literal::String,            :fg => :string
-
-    style Name::Decorator,
-         Name::Function,             :fg => :entity
-
-    style Error,                      :fg => :fgError, :bg => :bgError
-
-    style Comment,
-         Generic::Lineno,
-         Generic::Traceback,         :fg => :comment
-
-    style Name::Entity,
-         Literal::String::Interpol,  :fg => :fgDefault
-
-    style Generic::Emph,              :fg => :fgDefault, :italic => true
-
-    style Generic::Strong,            :fg => :fgDefault, :bold => true
-
-  end
-end; end
-
diff --git a/documentation/src/docs/asciidoc/tocbot-3.0.2/styles.css b/documentation/src/docs/asciidoc/tocbot-3.0.2/styles.css
deleted file mode 100644
index 3fd131d89c5d..000000000000
--- a/documentation/src/docs/asciidoc/tocbot-3.0.2/styles.css
+++ /dev/null
@@ -1 +0,0 @@
-.transition--300{transition:all 300ms ease-in-out}.toc{height:100%;width:280px;transform:translateX(0)}.content h1:first-child,.content h2:first-child{padding-top:0;margin-top:0}.title{font-size:3em}.content{margin-bottom:95vh}.content ul,.content ol{list-style:inherit}.content a{color:#0977c3;text-decoration:none;border-bottom:1px solid #EEE;transition:all 300ms ease}.content a.no-decoration{border-bottom:0}.content a:hover{border-bottom:1px solid #0977c3}.content a:hover.no-decoration{border-bottom:0}a.toc-link{text-decoration:none}.try-it-container{transform:translateY(84%)}.try-it-container.is-open{transform:translateY(0%)}.page-content{display:block !important}.hljs{display:block;background:white;padding:0.5em;color:#333333;overflow-x:auto}.hljs-comment,.hljs-meta{color:#969896}.hljs-string,.hljs-variable,.hljs-template-variable,.hljs-strong,.hljs-emphasis,.hljs-quote{color:#df5000}.hljs-keyword,.hljs-selector-tag,.hljs-type{color:#a71d5d}.hljs-literal,.hljs-symbol,.hljs-bullet,.hljs-attribute{color:#0086b3}.hljs-section,.hljs-name{color:#63a35c}.hljs-tag{color:#333333}.hljs-title,.hljs-attr,.hljs-selector-id,.hljs-selector-class,.hljs-selector-attr,.hljs-selector-pseudo{color:#795da3}.hljs-addition{color:#55a532;background-color:#eaffea}.hljs-deletion{color:#bd2c00;background-color:#ffecec}.hljs-link{text-decoration:underline}.toc-icon{position:fixed;top:0;right:0}#toc:checked ~ .toc{box-shadow:0 0 5px #c8c8c8;transform:translateX(0)}.toc{background-color:rgba(255,255,255,0.9);transform:translateX(-100%)}.toc.toc-right{transform:translateX(100%);right:0}@media (min-width: 52em){.toc{transform:translateX(0)}.toc.toc-right{transform:translateX(0);right:calc((100% - 48rem - 4rem) / 2)}.toc-icon{display:none}.try-it-container{display:block}.content{margin-left:280px}.toc-right ~ .content{margin-left:0;margin-right:280px}}*{box-sizing:border-box}body{font-size:1.2rem;font-family:-apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif}h1,h2,h3,h4,h5,h6{padding-top:0.5em}p{margin-top:0.25rem}pre{display:block;background:#f7f7f7;border-radius:2px;border:1px solid #e0e0e0;padding:2px;line-height:1.2;margin-bottom:10px;overflow:auto;white-space:pre-wrap}code{display:inline;font-size:.8em;max-width:100%}
diff --git a/documentation/src/docs/asciidoc/tocbot-3.0.2/tocbot.css b/documentation/src/docs/asciidoc/tocbot-3.0.2/tocbot.css
deleted file mode 100644
index 6265223f15ad..000000000000
--- a/documentation/src/docs/asciidoc/tocbot-3.0.2/tocbot.css
+++ /dev/null
@@ -1 +0,0 @@
-.toc{overflow-y:auto}.toc>ul{overflow:hidden;position:relative}.toc>ul li{list-style:none}.toc-list{margin:0;padding-left:10px}a.toc-link{color:currentColor;height:100%}.is-collapsible{max-height:1000px;overflow:hidden;transition:all 300ms ease-in-out}.is-collapsed{max-height:0}.is-position-fixed{position:fixed !important;top:0}.is-active-link{font-weight:700}.toc-link::before{background-color:#EEE;content:' ';display:inline-block;height:inherit;left:0;margin-top:-1px;position:absolute;width:2px}.is-active-link::before{background-color:#54BC4B}
diff --git a/documentation/src/docs/asciidoc/tocbot-3.0.2/tocbot.js b/documentation/src/docs/asciidoc/tocbot-3.0.2/tocbot.js
deleted file mode 100644
index 52fe18378f4f..000000000000
--- a/documentation/src/docs/asciidoc/tocbot-3.0.2/tocbot.js
+++ /dev/null
@@ -1,136 +0,0 @@
-/******/ (function(modules) { // webpackBootstrap
-/******/ 	// The module cache
-/******/ 	var installedModules = {};
-/******/
-/******/ 	// The require function
-/******/ 	function __webpack_require__(moduleId) {
-/******/
-/******/ 		// Check if module is in cache
-/******/ 		if(installedModules[moduleId]) {
-/******/ 			return installedModules[moduleId].exports;
-/******/ 		}
-/******/ 		// Create a new module (and put it into the cache)
-/******/ 		var module = installedModules[moduleId] = {
-/******/ 			i: moduleId,
-/******/ 			l: false,
-/******/ 			exports: {}
-/******/ 		};
-/******/
-/******/ 		// Execute the module function
-/******/ 		modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
-/******/
-/******/ 		// Flag the module as loaded
-/******/ 		module.l = true;
-/******/
-/******/ 		// Return the exports of the module
-/******/ 		return module.exports;
-/******/ 	}
-/******/
-/******/
-/******/ 	// expose the modules object (__webpack_modules__)
-/******/ 	__webpack_require__.m = modules;
-/******/
-/******/ 	// expose the module cache
-/******/ 	__webpack_require__.c = installedModules;
-/******/
-/******/ 	// identity function for calling harmony imports with the correct context
-/******/ 	__webpack_require__.i = function(value) { return value; };
-/******/
-/******/ 	// define getter function for harmony exports
-/******/ 	__webpack_require__.d = function(exports, name, getter) {
-/******/ 		if(!__webpack_require__.o(exports, name)) {
-/******/ 			Object.defineProperty(exports, name, {
-/******/ 				configurable: false,
-/******/ 				enumerable: true,
-/******/ 				get: getter
-/******/ 			});
-/******/ 		}
-/******/ 	};
-/******/
-/******/ 	// getDefaultExport function for compatibility with non-harmony modules
-/******/ 	__webpack_require__.n = function(module) {
-/******/ 		var getter = module && module.__esModule ?
-/******/ 			function getDefault() { return module['default']; } :
-/******/ 			function getModuleExports() { return module; };
-/******/ 		__webpack_require__.d(getter, 'a', getter);
-/******/ 		return getter;
-/******/ 	};
-/******/
-/******/ 	// Object.prototype.hasOwnProperty.call
-/******/ 	__webpack_require__.o = function(object, property) { return Object.prototype.hasOwnProperty.call(object, property); };
-/******/
-/******/ 	// __webpack_public_path__
-/******/ 	__webpack_require__.p = "";
-/******/
-/******/ 	// Load entry module and return exports
-/******/ 	return __webpack_require__(__webpack_require__.s = 5);
-/******/ })
-/************************************************************************/
-/******/ ([
-/* 0 */
-/* unknown exports provided */
-/* all exports used */
-/*!***********************************!*\
-  !*** (webpack)/buildin/global.js ***!
-  \***********************************/
-/***/ (function(module, exports) {
-
-eval("var g;\r\n\r\n// This works in non-strict mode\r\ng = (function() {\r\n\treturn this;\r\n})();\r\n\r\ntry {\r\n\t// This works if eval is allowed (see CSP)\r\n\tg = g || Function(\"return this\")() || (1,eval)(\"this\");\r\n} catch(e) {\r\n\t// This works if the window reference is available\r\n\tif(typeof window === \"object\")\r\n\t\tg = window;\r\n}\r\n\r\n// g can still be undefined, but nothing to do about it...\r\n// We return undefined, instead of nothing here, so it's\r\n// easier to handle this case. if(!global) { ...}\r\n\r\nmodule.exports = g;\r\n//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiMC5qcyIsInNvdXJjZXMiOlsid2VicGFjazovLy8od2VicGFjaykvYnVpbGRpbi9nbG9iYWwuanM/MzY5OCJdLCJzb3VyY2VzQ29udGVudCI6WyJ2YXIgZztcclxuXHJcbi8vIFRoaXMgd29ya3MgaW4gbm9uLXN0cmljdCBtb2RlXHJcbmcgPSAoZnVuY3Rpb24oKSB7XHJcblx0cmV0dXJuIHRoaXM7XHJcbn0pKCk7XHJcblxyXG50cnkge1xyXG5cdC8vIFRoaXMgd29ya3MgaWYgZXZhbCBpcyBhbGxvd2VkIChzZWUgQ1NQKVxyXG5cdGcgPSBnIHx8IEZ1bmN0aW9uKFwicmV0dXJuIHRoaXNcIikoKSB8fCAoMSxldmFsKShcInRoaXNcIik7XHJcbn0gY2F0Y2goZSkge1xyXG5cdC8vIFRoaXMgd29ya3MgaWYgdGhlIHdpbmRvdyByZWZlcmVuY2UgaXMgYXZhaWxhYmxlXHJcblx0aWYodHlwZW9mIHdpbmRvdyA9PT0gXCJvYmplY3RcIilcclxuXHRcdGcgPSB3aW5kb3c7XHJcbn1cclxuXHJcbi8vIGcgY2FuIHN0aWxsIGJlIHVuZGVmaW5lZCwgYnV0IG5vdGhpbmcgdG8gZG8gYWJvdXQgaXQuLi5cclxuLy8gV2UgcmV0dXJuIHVuZGVmaW5lZCwgaW5zdGVhZCBvZiBub3RoaW5nIGhlcmUsIHNvIGl0J3NcclxuLy8gZWFzaWVyIHRvIGhhbmRsZSB0aGlzIGNhc2UuIGlmKCFnbG9iYWwpIHsgLi4ufVxyXG5cclxubW9kdWxlLmV4cG9ydHMgPSBnO1xyXG5cblxuXG4vLy8vLy8vLy8vLy8vLy8vLy9cbi8vIFdFQlBBQ0sgRk9PVEVSXG4vLyAod2VicGFjaykvYnVpbGRpbi9nbG9iYWwuanNcbi8vIG1vZHVsZSBpZCA9IDBcbi8vIG1vZHVsZSBjaHVua3MgPSAwIl0sIm1hcHBpbmdzIjoiQUFBQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7Iiwic291cmNlUm9vdCI6IiJ9");
-
-/***/ }),
-/* 1 */
-/* unknown exports provided */
-/* all exports used */
-/*!**********************************!*\
-  !*** ./~/zenscroll/zenscroll.js ***!
-  \**********************************/
-/***/ (function(module, exports, __webpack_require__) {
-
-eval("var __WEBPACK_AMD_DEFINE_FACTORY__, __WEBPACK_AMD_DEFINE_ARRAY__, __WEBPACK_AMD_DEFINE_RESULT__;/**\n * Zenscroll 4.0.0\n * https://github.com/zengabor/zenscroll/\n *\n * Copyright 2015–2017 Gabor Lenard\n *\n * This is free and unencumbered software released into the public domain.\n * \n * Anyone is free to copy, modify, publish, use, compile, sell, or\n * distribute this software, either in source code form or as a compiled\n * binary, for any purpose, commercial or non-commercial, and by any\n * means.\n * \n * In jurisdictions that recognize copyright laws, the author or authors\n * of this software dedicate any and all copyright interest in the\n * software to the public domain. We make this dedication for the benefit\n * of the public at large and to the detriment of our heirs and\n * successors. We intend this dedication to be an overt act of\n * relinquishment in perpetuity of all present and future rights to this\n * software under copyright law.\n * \n * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND,\n * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF\n * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.\n * IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR\n * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,\n * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR\n * OTHER DEALINGS IN THE SOFTWARE.\n * \n * For more information, please refer to <https://unlicense.org>\n * \n */\n\n/*jshint devel:true, asi:true */\n\n/*global define, module */\n\n\n(function (root, factory) {\n\tif (true) {\n\t\t!(__WEBPACK_AMD_DEFINE_ARRAY__ = [], __WEBPACK_AMD_DEFINE_FACTORY__ = (factory()),\n\t\t\t\t__WEBPACK_AMD_DEFINE_RESULT__ = (typeof __WEBPACK_AMD_DEFINE_FACTORY__ === 'function' ?\n\t\t\t\t(__WEBPACK_AMD_DEFINE_FACTORY__.apply(exports, __WEBPACK_AMD_DEFINE_ARRAY__)) : __WEBPACK_AMD_DEFINE_FACTORY__),\n\t\t\t\t__WEBPACK_AMD_DEFINE_RESULT__ !== undefined && (module.exports = __WEBPACK_AMD_DEFINE_RESULT__))\n\t} else if (typeof module === \"object\" && module.exports) {\n\t\tmodule.exports = factory()\n\t} else {\n\t\t(function install() {\n\t\t\t// To make sure Zenscroll can be referenced from the header, before `body` is available\n\t\t\tif (document && document.body) {\n\t\t\t\troot.zenscroll = factory()\n\t\t\t} else {\n\t\t\t\t// retry 9ms later\n\t\t\t\tsetTimeout(install, 9)\n\t\t\t}\n\t\t})()\n\t}\n}(this, function () {\n\t\"use strict\"\n\n\n\t// Detect if the browser already supports native smooth scrolling (e.g., Firefox 36+ and Chrome 49+) and it is enabled:\n\tvar isNativeSmoothScrollEnabledOn = function (elem) {\n\t\treturn (\"getComputedStyle\" in window) &&\n\t\t\twindow.getComputedStyle(elem)[\"scroll-behavior\"] === \"smooth\"\n\t}\n\n\n\t// Exit if it’s not a browser environment:\n\tif (typeof window === \"undefined\" || !(\"document\" in window)) {\n\t\treturn {}\n\t}\n\n\n\tvar makeScroller = function (container, defaultDuration, edgeOffset) {\n\n\t\t// Use defaults if not provided\n\t\tdefaultDuration = defaultDuration || 999 //ms\n\t\tif (!edgeOffset && edgeOffset !== 0) {\n\t\t\t// When scrolling, this amount of distance is kept from the edges of the container:\n\t\t\tedgeOffset = 9 //px\n\t\t}\n\n\t\t// Handling the life-cycle of the scroller\n\t\tvar scrollTimeoutId\n\t\tvar setScrollTimeoutId = function (newValue) {\n\t\t\tscrollTimeoutId = newValue\n\t\t}\n\n\t\t/**\n\t\t * Stop the current smooth scroll operation immediately\n\t\t */\n\t\tvar stopScroll = function () {\n\t\t\tclearTimeout(scrollTimeoutId)\n\t\t\tsetScrollTimeoutId(0)\n\t\t}\n\n\t\tvar getTopWithEdgeOffset = function (elem) {\n\t\t\treturn Math.max(0, container.getTopOf(elem) - edgeOffset)\n\t\t}\n\n\t\t/**\n\t\t * Scrolls to a specific vertical position in the document.\n\t\t *\n\t\t * @param {targetY} The vertical position within the document.\n\t\t * @param {duration} Optionally the duration of the scroll operation.\n\t\t *        If not provided the default duration is used.\n\t\t * @param {onDone} An optional callback function to be invoked once the scroll finished.\n\t\t */\n\t\tvar scrollToY = function (targetY, duration, onDone) {\n\t\t\tstopScroll()\n\t\t\tif (duration === 0 || (duration && duration < 0) || isNativeSmoothScrollEnabledOn(container.body)) {\n\t\t\t\tcontainer.toY(targetY)\n\t\t\t\tif (onDone) {\n\t\t\t\t\tonDone()\n\t\t\t\t}\n\t\t\t} else {\n\t\t\t\tvar startY = container.getY()\n\t\t\t\tvar distance = Math.max(0, targetY) - startY\n\t\t\t\tvar startTime = new Date().getTime()\n\t\t\t\tduration = duration || Math.min(Math.abs(distance), defaultDuration);\n\t\t\t\t(function loopScroll() {\n\t\t\t\t\tsetScrollTimeoutId(setTimeout(function () {\n\t\t\t\t\t\t// Calculate percentage:\n\t\t\t\t\t\tvar p = Math.min(1, (new Date().getTime() - startTime) / duration)\n\t\t\t\t\t\t// Calculate the absolute vertical position:\n\t\t\t\t\t\tvar y = Math.max(0, Math.floor(startY + distance*(p < 0.5 ? 2*p*p : p*(4 - p*2)-1)))\n\t\t\t\t\t\tcontainer.toY(y)\n\t\t\t\t\t\tif (p < 1 && (container.getHeight() + y) < container.body.scrollHeight) {\n\t\t\t\t\t\t\tloopScroll()\n\t\t\t\t\t\t} else {\n\t\t\t\t\t\t\tsetTimeout(stopScroll, 99) // with cooldown time\n\t\t\t\t\t\t\tif (onDone) {\n\t\t\t\t\t\t\t\tonDone()\n\t\t\t\t\t\t\t}\n\t\t\t\t\t\t}\n\t\t\t\t\t}, 9))\n\t\t\t\t})()\n\t\t\t}\n\t\t}\n\n\t\t/**\n\t\t * Scrolls to the top of a specific element.\n\t\t *\n\t\t * @param {elem} The element to scroll to.\n\t\t * @param {duration} Optionally the duration of the scroll operation.\n\t\t * @param {onDone} An optional callback function to be invoked once the scroll finished.\n\t\t */\n\t\tvar scrollToElem = function (elem, duration, onDone) {\n\t\t\tscrollToY(getTopWithEdgeOffset(elem), duration, onDone)\n\t\t}\n\n\t\t/**\n\t\t * Scrolls an element into view if necessary.\n\t\t *\n\t\t * @param {elem} The element.\n\t\t * @param {duration} Optionally the duration of the scroll operation.\n\t\t * @param {onDone} An optional callback function to be invoked once the scroll finished.\n\t\t */\n\t\tvar scrollIntoView = function (elem, duration, onDone) {\n\t\t\tvar elemHeight = elem.getBoundingClientRect().height\n\t\t\tvar elemBottom = container.getTopOf(elem) + elemHeight\n\t\t\tvar containerHeight = container.getHeight()\n\t\t\tvar y = container.getY()\n\t\t\tvar containerBottom = y + containerHeight\n\t\t\tif (getTopWithEdgeOffset(elem) < y || (elemHeight + edgeOffset) > containerHeight) {\n\t\t\t\t// Element is clipped at top or is higher than screen.\n\t\t\t\tscrollToElem(elem, duration, onDone)\n\t\t\t} else if ((elemBottom + edgeOffset) > containerBottom) {\n\t\t\t\t// Element is clipped at the bottom.\n\t\t\t\tscrollToY(elemBottom - containerHeight + edgeOffset, duration, onDone)\n\t\t\t} else if (onDone) {\n\t\t\t\tonDone()\n\t\t\t}\n\t\t}\n\n\t\t/**\n\t\t * Scrolls to the center of an element.\n\t\t *\n\t\t * @param {elem} The element.\n\t\t * @param {duration} Optionally the duration of the scroll operation.\n\t\t * @param {offset} Optionally the offset of the top of the element from the center of the screen.\n\t\t * @param {onDone} An optional callback function to be invoked once the scroll finished.\n\t\t */\n\t\tvar scrollToCenterOf = function (elem, duration, offset, onDone) {\n\t\t\tscrollToY(Math.max(0, container.getTopOf(elem) - container.getHeight()/2 + (offset || elem.getBoundingClientRect().height/2)), duration, onDone)\n\t\t}\n\n\t\t/**\n\t\t * Changes default settings for this scroller.\n\t\t *\n\t\t * @param {newDefaultDuration} Optionally a new value for default duration, used for each scroll method by default.\n\t\t *        Ignored if null or undefined.\n\t\t * @param {newEdgeOffset} Optionally a new value for the edge offset, used by each scroll method by default. Ignored if null or undefined.\n\t\t * @returns An object with the current values.\n\t\t */\n\t\tvar setup = function (newDefaultDuration, newEdgeOffset) {\n\t\t\tif (newDefaultDuration === 0 || newDefaultDuration) {\n\t\t\t\tdefaultDuration = newDefaultDuration\n\t\t\t}\n\t\t\tif (newEdgeOffset === 0 || newEdgeOffset) {\n\t\t\t\tedgeOffset = newEdgeOffset\n\t\t\t}\n\t\t\treturn {\n\t\t\t\tdefaultDuration: defaultDuration,\n\t\t\t\tedgeOffset: edgeOffset\n\t\t\t}\n\t\t}\n\n\t\treturn {\n\t\t\tsetup: setup,\n\t\t\tto: scrollToElem,\n\t\t\ttoY: scrollToY,\n\t\t\tintoView: scrollIntoView,\n\t\t\tcenter: scrollToCenterOf,\n\t\t\tstop: stopScroll,\n\t\t\tmoving: function () { return !!scrollTimeoutId },\n\t\t\tgetY: container.getY,\n\t\t\tgetTopOf: container.getTopOf\n\t\t}\n\n\t}\n\n\n\tvar docElem = document.documentElement\n\tvar getDocY = function () { return window.scrollY || docElem.scrollTop }\n\n\t// Create a scroller for the document:\n\tvar zenscroll = makeScroller({\n\t\tbody: document.scrollingElement || document.body,\n\t\ttoY: function (y) { window.scrollTo(0, y) },\n\t\tgetY: getDocY,\n\t\tgetHeight: function () { return window.innerHeight || docElem.clientHeight },\n\t\tgetTopOf: function (elem) { return elem.getBoundingClientRect().top + getDocY() - docElem.offsetTop }\n\t})\n\n\n\t/**\n\t * Creates a scroller from the provided container element (e.g., a DIV)\n\t *\n\t * @param {scrollContainer} The vertical position within the document.\n\t * @param {defaultDuration} Optionally a value for default duration, used for each scroll method by default.\n\t *        Ignored if 0 or null or undefined.\n\t * @param {edgeOffset} Optionally a value for the edge offset, used by each scroll method by default. \n\t *        Ignored if null or undefined.\n\t * @returns A scroller object, similar to `zenscroll` but controlling the provided element.\n\t */\n\tzenscroll.createScroller = function (scrollContainer, defaultDuration, edgeOffset) {\n\t\treturn makeScroller({\n\t\t\tbody: scrollContainer,\n\t\t\ttoY: function (y) { scrollContainer.scrollTop = y },\n\t\t\tgetY: function () { return scrollContainer.scrollTop },\n\t\t\tgetHeight: function () { return Math.min(scrollContainer.clientHeight, window.innerHeight || docElem.clientHeight) },\n\t\t\tgetTopOf: function (elem) { return elem.offsetTop }\n\t\t}, defaultDuration, edgeOffset)\n\t}\n\n\n\t// Automatic link-smoothing on achors\n\t// Exclude IE8- or when native is enabled or Zenscroll auto- is disabled\n\tif (\"addEventListener\" in window && !window.noZensmooth && !isNativeSmoothScrollEnabledOn(document.body)) {\n\n\n\t\tvar isScrollRestorationSupported = \"scrollRestoration\" in history\n\n\t\t// On first load & refresh make sure the browser restores the position first\n\t\tif (isScrollRestorationSupported) {\n\t\t\thistory.scrollRestoration = \"auto\"\n\t\t}\n\n\t\twindow.addEventListener(\"load\", function () {\n\n\t\t\tif (isScrollRestorationSupported) {\n\t\t\t\t// Set it to manual\n\t\t\t\tsetTimeout(function () { history.scrollRestoration = \"manual\" }, 9)\n\t\t\t\twindow.addEventListener(\"popstate\", function (event) {\n\t\t\t\t\tif (event.state && \"zenscrollY\" in event.state) {\n\t\t\t\t\t\tzenscroll.toY(event.state.zenscrollY)\n\t\t\t\t\t}\n\t\t\t\t}, false)\n\t\t\t}\n\n\t\t\t// Add edge offset on first load if necessary\n\t\t\t// This may not work on IE (or older computer?) as it requires more timeout, around 100 ms\n\t\t\tif (window.location.hash) {\n\t\t\t\tsetTimeout(function () {\n\t\t\t\t\t// Adjustment is only needed if there is an edge offset:\n\t\t\t\t\tvar edgeOffset = zenscroll.setup().edgeOffset\n\t\t\t\t\tif (edgeOffset) {\n\t\t\t\t\t\tvar targetElem = document.getElementById(window.location.href.split(\"#\")[1])\n\t\t\t\t\t\tif (targetElem) {\n\t\t\t\t\t\t\tvar targetY = Math.max(0, zenscroll.getTopOf(targetElem) - edgeOffset)\n\t\t\t\t\t\t\tvar diff = zenscroll.getY() - targetY\n\t\t\t\t\t\t\t// Only do the adjustment if the browser is very close to the element:\n\t\t\t\t\t\t\tif (0 <= diff && diff < 9 ) {\n\t\t\t\t\t\t\t\twindow.scrollTo(0, targetY)\n\t\t\t\t\t\t\t}\n\t\t\t\t\t\t}\n\t\t\t\t\t}\n\t\t\t\t}, 9)\n\t\t\t}\n\n\t\t}, false)\n\n\t\t// Handling clicks on anchors\n\t\tvar RE_noZensmooth = new RegExp(\"(^|\\\\s)noZensmooth(\\\\s|$)\")\n\t\twindow.addEventListener(\"click\", function (event) {\n\t\t\tvar anchor = event.target\n\t\t\twhile (anchor && anchor.tagName !== \"A\") {\n\t\t\t\tanchor = anchor.parentNode\n\t\t\t}\n\t\t\t// Let the browser handle the click if it wasn't with the primary button, or with some modifier keys:\n\t\t\tif (!anchor || event.which !== 1 || event.shiftKey || event.metaKey || event.ctrlKey || event.altKey) {\n\t\t\t\treturn\n\t\t\t}\n\t\t\t// Save the current scrolling position so it can be used for scroll restoration:\n\t\t\tif (isScrollRestorationSupported) {\n\t\t\t\ttry {\n\t\t\t\t\thistory.replaceState({ zenscrollY: zenscroll.getY() }, \"\")\n\t\t\t\t} catch (e) {\n\t\t\t\t\t// Avoid the Chrome Security exception on file protocol, e.g., file://index.html\n\t\t\t\t}\n\t\t\t}\n\t\t\t// Find the referenced ID:\n\t\t\tvar href = anchor.getAttribute(\"href\") || \"\"\n\t\t\tif (href.indexOf(\"#\") === 0 && !RE_noZensmooth.test(anchor.className)) {\n\t\t\t\tvar targetY = 0\n\t\t\t\tvar targetElem = document.getElementById(href.substring(1))\n\t\t\t\tif (href !== \"#\") {\n\t\t\t\t\tif (!targetElem) {\n\t\t\t\t\t\t// Let the browser handle the click if the target ID is not found.\n\t\t\t\t\t\treturn\n\t\t\t\t\t}\n\t\t\t\t\ttargetY = zenscroll.getTopOf(targetElem)\n\t\t\t\t}\n\t\t\t\tevent.preventDefault()\n\t\t\t\t// By default trigger the browser's `hashchange` event...\n\t\t\t\tvar onDone = function () { window.location = href }\n\t\t\t\t// ...unless there is an edge offset specified\n\t\t\t\tvar edgeOffset = zenscroll.setup().edgeOffset\n\t\t\t\tif (edgeOffset) {\n\t\t\t\t\ttargetY = Math.max(0, targetY - edgeOffset)\n\t\t\t\t\tonDone = function () { history.pushState(null, \"\", href) }\n\t\t\t\t}\n\t\t\t\tzenscroll.toY(targetY, null, onDone)\n\t\t\t}\n\t\t}, false)\n\n\t}\n\n\n\treturn zenscroll\n\n\n}));\n//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiMS5qcyIsInNvdXJjZXMiOlsid2VicGFjazovLy8uL34vemVuc2Nyb2xsL3plbnNjcm9sbC5qcz8yNzMyIl0sInNvdXJjZXNDb250ZW50IjpbIi8qKlxuICogWmVuc2Nyb2xsIDQuMC4wXG4gKiBodHRwczovL2dpdGh1Yi5jb20vemVuZ2Fib3IvemVuc2Nyb2xsL1xuICpcbiAqIENvcHlyaWdodCAyMDE14oCTMjAxNyBHYWJvciBMZW5hcmRcbiAqXG4gKiBUaGlzIGlzIGZyZWUgYW5kIHVuZW5jdW1iZXJlZCBzb2Z0d2FyZSByZWxlYXNlZCBpbnRvIHRoZSBwdWJsaWMgZG9tYWluLlxuICogXG4gKiBBbnlvbmUgaXMgZnJlZSB0byBjb3B5LCBtb2RpZnksIHB1Ymxpc2gsIHVzZSwgY29tcGlsZSwgc2VsbCwgb3JcbiAqIGRpc3RyaWJ1dGUgdGhpcyBzb2Z0d2FyZSwgZWl0aGVyIGluIHNvdXJjZSBjb2RlIGZvcm0gb3IgYXMgYSBjb21waWxlZFxuICogYmluYXJ5LCBmb3IgYW55IHB1cnBvc2UsIGNvbW1lcmNpYWwgb3Igbm9uLWNvbW1lcmNpYWwsIGFuZCBieSBhbnlcbiAqIG1lYW5zLlxuICogXG4gKiBJbiBqdXJpc2RpY3Rpb25zIHRoYXQgcmVjb2duaXplIGNvcHlyaWdodCBsYXdzLCB0aGUgYXV0aG9yIG9yIGF1dGhvcnNcbiAqIG9mIHRoaXMgc29mdHdhcmUgZGVkaWNhdGUgYW55IGFuZCBhbGwgY29weXJpZ2h0IGludGVyZXN0IGluIHRoZVxuICogc29mdHdhcmUgdG8gdGhlIHB1YmxpYyBkb21haW4uIFdlIG1ha2UgdGhpcyBkZWRpY2F0aW9uIGZvciB0aGUgYmVuZWZpdFxuICogb2YgdGhlIHB1YmxpYyBhdCBsYXJnZSBhbmQgdG8gdGhlIGRldHJpbWVudCBvZiBvdXIgaGVpcnMgYW5kXG4gKiBzdWNjZXNzb3JzLiBXZSBpbnRlbmQgdGhpcyBkZWRpY2F0aW9uIHRvIGJlIGFuIG92ZXJ0IGFjdCBvZlxuICogcmVsaW5xdWlzaG1lbnQgaW4gcGVycGV0dWl0eSBvZiBhbGwgcHJlc2VudCBhbmQgZnV0dXJlIHJpZ2h0cyB0byB0aGlzXG4gKiBzb2Z0d2FyZSB1bmRlciBjb3B5cmlnaHQgbGF3LlxuICogXG4gKiBUSEUgU09GVFdBUkUgSVMgUFJPVklERUQgXCJBUyBJU1wiLCBXSVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELFxuICogRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIFRIRSBXQVJSQU5USUVTIE9GXG4gKiBNRVJDSEFOVEFCSUxJVFksIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFORCBOT05JTkZSSU5HRU1FTlQuXG4gKiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SUyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFNQUdFUyBPUlxuICogT1RIRVIgTElBQklMSVRZLCBXSEVUSEVSIElOIEFOIEFDVElPTiBPRiBDT05UUkFDVCwgVE9SVCBPUiBPVEhFUldJU0UsXG4gKiBBUklTSU5HIEZST00sIE9VVCBPRiBPUiBJTiBDT05ORUNUSU9OIFdJVEggVEhFIFNPRlRXQVJFIE9SIFRIRSBVU0UgT1JcbiAqIE9USEVSIERFQUxJTkdTIElOIFRIRSBTT0ZUV0FSRS5cbiAqIFxuICogRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSByZWZlciB0byA8aHR0cDovL3VubGljZW5zZS5vcmc+XG4gKiBcbiAqL1xuXG4vKmpzaGludCBkZXZlbDp0cnVlLCBhc2k6dHJ1ZSAqL1xuXG4vKmdsb2JhbCBkZWZpbmUsIG1vZHVsZSAqL1xuXG5cbihmdW5jdGlvbiAocm9vdCwgZmFjdG9yeSkge1xuXHRpZiAodHlwZW9mIGRlZmluZSA9PT0gXCJmdW5jdGlvblwiICYmIGRlZmluZS5hbWQpIHtcblx0XHRkZWZpbmUoW10sIGZhY3RvcnkoKSlcblx0fSBlbHNlIGlmICh0eXBlb2YgbW9kdWxlID09PSBcIm9iamVjdFwiICYmIG1vZHVsZS5leHBvcnRzKSB7XG5cdFx0bW9kdWxlLmV4cG9ydHMgPSBmYWN0b3J5KClcblx0fSBlbHNlIHtcblx0XHQoZnVuY3Rpb24gaW5zdGFsbCgpIHtcblx0XHRcdC8vIFRvIG1ha2Ugc3VyZSBaZW5zY3JvbGwgY2FuIGJlIHJlZmVyZW5jZWQgZnJvbSB0aGUgaGVhZGVyLCBiZWZvcmUgYGJvZHlgIGlzIGF2YWlsYWJsZVxuXHRcdFx0aWYgKGRvY3VtZW50ICYmIGRvY3VtZW50LmJvZHkpIHtcblx0XHRcdFx0cm9vdC56ZW5zY3JvbGwgPSBmYWN0b3J5KClcblx0XHRcdH0gZWxzZSB7XG5cdFx0XHRcdC8vIHJldHJ5IDltcyBsYXRlclxuXHRcdFx0XHRzZXRUaW1lb3V0KGluc3RhbGwsIDkpXG5cdFx0XHR9XG5cdFx0fSkoKVxuXHR9XG59KHRoaXMsIGZ1bmN0aW9uICgpIHtcblx0XCJ1c2Ugc3RyaWN0XCJcblxuXG5cdC8vIERldGVjdCBpZiB0aGUgYnJvd3NlciBhbHJlYWR5IHN1cHBvcnRzIG5hdGl2ZSBzbW9vdGggc2Nyb2xsaW5nIChlLmcuLCBGaXJlZm94IDM2KyBhbmQgQ2hyb21lIDQ5KykgYW5kIGl0IGlzIGVuYWJsZWQ6XG5cdHZhciBpc05hdGl2ZVNtb290aFNjcm9sbEVuYWJsZWRPbiA9IGZ1bmN0aW9uIChlbGVtKSB7XG5cdFx0cmV0dXJuIChcImdldENvbXB1dGVkU3R5bGVcIiBpbiB3aW5kb3cpICYmXG5cdFx0XHR3aW5kb3cuZ2V0Q29tcHV0ZWRTdHlsZShlbGVtKVtcInNjcm9sbC1iZWhhdmlvclwiXSA9PT0gXCJzbW9vdGhcIlxuXHR9XG5cblxuXHQvLyBFeGl0IGlmIGl04oCZcyBub3QgYSBicm93c2VyIGVudmlyb25tZW50OlxuXHRpZiAodHlwZW9mIHdpbmRvdyA9PT0gXCJ1bmRlZmluZWRcIiB8fCAhKFwiZG9jdW1lbnRcIiBpbiB3aW5kb3cpKSB7XG5cdFx0cmV0dXJuIHt9XG5cdH1cblxuXG5cdHZhciBtYWtlU2Nyb2xsZXIgPSBmdW5jdGlvbiAoY29udGFpbmVyLCBkZWZhdWx0RHVyYXRpb24sIGVkZ2VPZmZzZXQpIHtcblxuXHRcdC8vIFVzZSBkZWZhdWx0cyBpZiBub3QgcHJvdmlkZWRcblx0XHRkZWZhdWx0RHVyYXRpb24gPSBkZWZhdWx0RHVyYXRpb24gfHwgOTk5IC8vbXNcblx0XHRpZiAoIWVkZ2VPZmZzZXQgJiYgZWRnZU9mZnNldCAhPT0gMCkge1xuXHRcdFx0Ly8gV2hlbiBzY3JvbGxpbmcsIHRoaXMgYW1vdW50IG9mIGRpc3RhbmNlIGlzIGtlcHQgZnJvbSB0aGUgZWRnZXMgb2YgdGhlIGNvbnRhaW5lcjpcblx0XHRcdGVkZ2VPZmZzZXQgPSA5IC8vcHhcblx0XHR9XG5cblx0XHQvLyBIYW5kbGluZyB0aGUgbGlmZS1jeWNsZSBvZiB0aGUgc2Nyb2xsZXJcblx0XHR2YXIgc2Nyb2xsVGltZW91dElkXG5cdFx0dmFyIHNldFNjcm9sbFRpbWVvdXRJZCA9IGZ1bmN0aW9uIChuZXdWYWx1ZSkge1xuXHRcdFx0c2Nyb2xsVGltZW91dElkID0gbmV3VmFsdWVcblx0XHR9XG5cblx0XHQvKipcblx0XHQgKiBTdG9wIHRoZSBjdXJyZW50IHNtb290aCBzY3JvbGwgb3BlcmF0aW9uIGltbWVkaWF0ZWx5XG5cdFx0ICovXG5cdFx0dmFyIHN0b3BTY3JvbGwgPSBmdW5jdGlvbiAoKSB7XG5cdFx0XHRjbGVhclRpbWVvdXQoc2Nyb2xsVGltZW91dElkKVxuXHRcdFx0c2V0U2Nyb2xsVGltZW91dElkKDApXG5cdFx0fVxuXG5cdFx0dmFyIGdldFRvcFdpdGhFZGdlT2Zmc2V0ID0gZnVuY3Rpb24gKGVsZW0pIHtcblx0XHRcdHJldHVybiBNYXRoLm1heCgwLCBjb250YWluZXIuZ2V0VG9wT2YoZWxlbSkgLSBlZGdlT2Zmc2V0KVxuXHRcdH1cblxuXHRcdC8qKlxuXHRcdCAqIFNjcm9sbHMgdG8gYSBzcGVjaWZpYyB2ZXJ0aWNhbCBwb3NpdGlvbiBpbiB0aGUgZG9jdW1lbnQuXG5cdFx0ICpcblx0XHQgKiBAcGFyYW0ge3RhcmdldFl9IFRoZSB2ZXJ0aWNhbCBwb3NpdGlvbiB3aXRoaW4gdGhlIGRvY3VtZW50LlxuXHRcdCAqIEBwYXJhbSB7ZHVyYXRpb259IE9wdGlvbmFsbHkgdGhlIGR1cmF0aW9uIG9mIHRoZSBzY3JvbGwgb3BlcmF0aW9uLlxuXHRcdCAqICAgICAgICBJZiBub3QgcHJvdmlkZWQgdGhlIGRlZmF1bHQgZHVyYXRpb24gaXMgdXNlZC5cblx0XHQgKiBAcGFyYW0ge29uRG9uZX0gQW4gb3B0aW9uYWwgY2FsbGJhY2sgZnVuY3Rpb24gdG8gYmUgaW52b2tlZCBvbmNlIHRoZSBzY3JvbGwgZmluaXNoZWQuXG5cdFx0ICovXG5cdFx0dmFyIHNjcm9sbFRvWSA9IGZ1bmN0aW9uICh0YXJnZXRZLCBkdXJhdGlvbiwgb25Eb25lKSB7XG5cdFx0XHRzdG9wU2Nyb2xsKClcblx0XHRcdGlmIChkdXJhdGlvbiA9PT0gMCB8fCAoZHVyYXRpb24gJiYgZHVyYXRpb24gPCAwKSB8fCBpc05hdGl2ZVNtb290aFNjcm9sbEVuYWJsZWRPbihjb250YWluZXIuYm9keSkpIHtcblx0XHRcdFx0Y29udGFpbmVyLnRvWSh0YXJnZXRZKVxuXHRcdFx0XHRpZiAob25Eb25lKSB7XG5cdFx0XHRcdFx0b25Eb25lKClcblx0XHRcdFx0fVxuXHRcdFx0fSBlbHNlIHtcblx0XHRcdFx0dmFyIHN0YXJ0WSA9IGNvbnRhaW5lci5nZXRZKClcblx0XHRcdFx0dmFyIGRpc3RhbmNlID0gTWF0aC5tYXgoMCwgdGFyZ2V0WSkgLSBzdGFydFlcblx0XHRcdFx0dmFyIHN0YXJ0VGltZSA9IG5ldyBEYXRlKCkuZ2V0VGltZSgpXG5cdFx0XHRcdGR1cmF0aW9uID0gZHVyYXRpb24gfHwgTWF0aC5taW4oTWF0aC5hYnMoZGlzdGFuY2UpLCBkZWZhdWx0RHVyYXRpb24pO1xuXHRcdFx0XHQoZnVuY3Rpb24gbG9vcFNjcm9sbCgpIHtcblx0XHRcdFx0XHRzZXRTY3JvbGxUaW1lb3V0SWQoc2V0VGltZW91dChmdW5jdGlvbiAoKSB7XG5cdFx0XHRcdFx0XHQvLyBDYWxjdWxhdGUgcGVyY2VudGFnZTpcblx0XHRcdFx0XHRcdHZhciBwID0gTWF0aC5taW4oMSwgKG5ldyBEYXRlKCkuZ2V0VGltZSgpIC0gc3RhcnRUaW1lKSAvIGR1cmF0aW9uKVxuXHRcdFx0XHRcdFx0Ly8gQ2FsY3VsYXRlIHRoZSBhYnNvbHV0ZSB2ZXJ0aWNhbCBwb3NpdGlvbjpcblx0XHRcdFx0XHRcdHZhciB5ID0gTWF0aC5tYXgoMCwgTWF0aC5mbG9vcihzdGFydFkgKyBkaXN0YW5jZSoocCA8IDAuNSA/IDIqcCpwIDogcCooNCAtIHAqMiktMSkpKVxuXHRcdFx0XHRcdFx0Y29udGFpbmVyLnRvWSh5KVxuXHRcdFx0XHRcdFx0aWYgKHAgPCAxICYmIChjb250YWluZXIuZ2V0SGVpZ2h0KCkgKyB5KSA8IGNvbnRhaW5lci5ib2R5LnNjcm9sbEhlaWdodCkge1xuXHRcdFx0XHRcdFx0XHRsb29wU2Nyb2xsKClcblx0XHRcdFx0XHRcdH0gZWxzZSB7XG5cdFx0XHRcdFx0XHRcdHNldFRpbWVvdXQoc3RvcFNjcm9sbCwgOTkpIC8vIHdpdGggY29vbGRvd24gdGltZVxuXHRcdFx0XHRcdFx0XHRpZiAob25Eb25lKSB7XG5cdFx0XHRcdFx0XHRcdFx0b25Eb25lKClcblx0XHRcdFx0XHRcdFx0fVxuXHRcdFx0XHRcdFx0fVxuXHRcdFx0XHRcdH0sIDkpKVxuXHRcdFx0XHR9KSgpXG5cdFx0XHR9XG5cdFx0fVxuXG5cdFx0LyoqXG5cdFx0ICogU2Nyb2xscyB0byB0aGUgdG9wIG9mIGEgc3BlY2lmaWMgZWxlbWVudC5cblx0XHQgKlxuXHRcdCAqIEBwYXJhbSB7ZWxlbX0gVGhlIGVsZW1lbnQgdG8gc2Nyb2xsIHRvLlxuXHRcdCAqIEBwYXJhbSB7ZHVyYXRpb259IE9wdGlvbmFsbHkgdGhlIGR1cmF0aW9uIG9mIHRoZSBzY3JvbGwgb3BlcmF0aW9uLlxuXHRcdCAqIEBwYXJhbSB7b25Eb25lfSBBbiBvcHRpb25hbCBjYWxsYmFjayBmdW5jdGlvbiB0byBiZSBpbnZva2VkIG9uY2UgdGhlIHNjcm9sbCBmaW5pc2hlZC5cblx0XHQgKi9cblx0XHR2YXIgc2Nyb2xsVG9FbGVtID0gZnVuY3Rpb24gKGVsZW0sIGR1cmF0aW9uLCBvbkRvbmUpIHtcblx0XHRcdHNjcm9sbFRvWShnZXRUb3BXaXRoRWRnZU9mZnNldChlbGVtKSwgZHVyYXRpb24sIG9uRG9uZSlcblx0XHR9XG5cblx0XHQvKipcblx0XHQgKiBTY3JvbGxzIGFuIGVsZW1lbnQgaW50byB2aWV3IGlmIG5lY2Vzc2FyeS5cblx0XHQgKlxuXHRcdCAqIEBwYXJhbSB7ZWxlbX0gVGhlIGVsZW1lbnQuXG5cdFx0ICogQHBhcmFtIHtkdXJhdGlvbn0gT3B0aW9uYWxseSB0aGUgZHVyYXRpb24gb2YgdGhlIHNjcm9sbCBvcGVyYXRpb24uXG5cdFx0ICogQHBhcmFtIHtvbkRvbmV9IEFuIG9wdGlvbmFsIGNhbGxiYWNrIGZ1bmN0aW9uIHRvIGJlIGludm9rZWQgb25jZSB0aGUgc2Nyb2xsIGZpbmlzaGVkLlxuXHRcdCAqL1xuXHRcdHZhciBzY3JvbGxJbnRvVmlldyA9IGZ1bmN0aW9uIChlbGVtLCBkdXJhdGlvbiwgb25Eb25lKSB7XG5cdFx0XHR2YXIgZWxlbUhlaWdodCA9IGVsZW0uZ2V0Qm91bmRpbmdDbGllbnRSZWN0KCkuaGVpZ2h0XG5cdFx0XHR2YXIgZWxlbUJvdHRvbSA9IGNvbnRhaW5lci5nZXRUb3BPZihlbGVtKSArIGVsZW1IZWlnaHRcblx0XHRcdHZhciBjb250YWluZXJIZWlnaHQgPSBjb250YWluZXIuZ2V0SGVpZ2h0KClcblx0XHRcdHZhciB5ID0gY29udGFpbmVyLmdldFkoKVxuXHRcdFx0dmFyIGNvbnRhaW5lckJvdHRvbSA9IHkgKyBjb250YWluZXJIZWlnaHRcblx0XHRcdGlmIChnZXRUb3BXaXRoRWRnZU9mZnNldChlbGVtKSA8IHkgfHwgKGVsZW1IZWlnaHQgKyBlZGdlT2Zmc2V0KSA+IGNvbnRhaW5lckhlaWdodCkge1xuXHRcdFx0XHQvLyBFbGVtZW50IGlzIGNsaXBwZWQgYXQgdG9wIG9yIGlzIGhpZ2hlciB0aGFuIHNjcmVlbi5cblx0XHRcdFx0c2Nyb2xsVG9FbGVtKGVsZW0sIGR1cmF0aW9uLCBvbkRvbmUpXG5cdFx0XHR9IGVsc2UgaWYgKChlbGVtQm90dG9tICsgZWRnZU9mZnNldCkgPiBjb250YWluZXJCb3R0b20pIHtcblx0XHRcdFx0Ly8gRWxlbWVudCBpcyBjbGlwcGVkIGF0IHRoZSBib3R0b20uXG5cdFx0XHRcdHNjcm9sbFRvWShlbGVtQm90dG9tIC0gY29udGFpbmVySGVpZ2h0ICsgZWRnZU9mZnNldCwgZHVyYXRpb24sIG9uRG9uZSlcblx0XHRcdH0gZWxzZSBpZiAob25Eb25lKSB7XG5cdFx0XHRcdG9uRG9uZSgpXG5cdFx0XHR9XG5cdFx0fVxuXG5cdFx0LyoqXG5cdFx0ICogU2Nyb2xscyB0byB0aGUgY2VudGVyIG9mIGFuIGVsZW1lbnQuXG5cdFx0ICpcblx0XHQgKiBAcGFyYW0ge2VsZW19IFRoZSBlbGVtZW50LlxuXHRcdCAqIEBwYXJhbSB7ZHVyYXRpb259IE9wdGlvbmFsbHkgdGhlIGR1cmF0aW9uIG9mIHRoZSBzY3JvbGwgb3BlcmF0aW9uLlxuXHRcdCAqIEBwYXJhbSB7b2Zmc2V0fSBPcHRpb25hbGx5IHRoZSBvZmZzZXQgb2YgdGhlIHRvcCBvZiB0aGUgZWxlbWVudCBmcm9tIHRoZSBjZW50ZXIgb2YgdGhlIHNjcmVlbi5cblx0XHQgKiBAcGFyYW0ge29uRG9uZX0gQW4gb3B0aW9uYWwgY2FsbGJhY2sgZnVuY3Rpb24gdG8gYmUgaW52b2tlZCBvbmNlIHRoZSBzY3JvbGwgZmluaXNoZWQuXG5cdFx0ICovXG5cdFx0dmFyIHNjcm9sbFRvQ2VudGVyT2YgPSBmdW5jdGlvbiAoZWxlbSwgZHVyYXRpb24sIG9mZnNldCwgb25Eb25lKSB7XG5cdFx0XHRzY3JvbGxUb1koTWF0aC5tYXgoMCwgY29udGFpbmVyLmdldFRvcE9mKGVsZW0pIC0gY29udGFpbmVyLmdldEhlaWdodCgpLzIgKyAob2Zmc2V0IHx8IGVsZW0uZ2V0Qm91bmRpbmdDbGllbnRSZWN0KCkuaGVpZ2h0LzIpKSwgZHVyYXRpb24sIG9uRG9uZSlcblx0XHR9XG5cblx0XHQvKipcblx0XHQgKiBDaGFuZ2VzIGRlZmF1bHQgc2V0dGluZ3MgZm9yIHRoaXMgc2Nyb2xsZXIuXG5cdFx0ICpcblx0XHQgKiBAcGFyYW0ge25ld0RlZmF1bHREdXJhdGlvbn0gT3B0aW9uYWxseSBhIG5ldyB2YWx1ZSBmb3IgZGVmYXVsdCBkdXJhdGlvbiwgdXNlZCBmb3IgZWFjaCBzY3JvbGwgbWV0aG9kIGJ5IGRlZmF1bHQuXG5cdFx0ICogICAgICAgIElnbm9yZWQgaWYgbnVsbCBvciB1bmRlZmluZWQuXG5cdFx0ICogQHBhcmFtIHtuZXdFZGdlT2Zmc2V0fSBPcHRpb25hbGx5IGEgbmV3IHZhbHVlIGZvciB0aGUgZWRnZSBvZmZzZXQsIHVzZWQgYnkgZWFjaCBzY3JvbGwgbWV0aG9kIGJ5IGRlZmF1bHQuIElnbm9yZWQgaWYgbnVsbCBvciB1bmRlZmluZWQuXG5cdFx0ICogQHJldHVybnMgQW4gb2JqZWN0IHdpdGggdGhlIGN1cnJlbnQgdmFsdWVzLlxuXHRcdCAqL1xuXHRcdHZhciBzZXR1cCA9IGZ1bmN0aW9uIChuZXdEZWZhdWx0RHVyYXRpb24sIG5ld0VkZ2VPZmZzZXQpIHtcblx0XHRcdGlmIChuZXdEZWZhdWx0RHVyYXRpb24gPT09IDAgfHwgbmV3RGVmYXVsdER1cmF0aW9uKSB7XG5cdFx0XHRcdGRlZmF1bHREdXJhdGlvbiA9IG5ld0RlZmF1bHREdXJhdGlvblxuXHRcdFx0fVxuXHRcdFx0aWYgKG5ld0VkZ2VPZmZzZXQgPT09IDAgfHwgbmV3RWRnZU9mZnNldCkge1xuXHRcdFx0XHRlZGdlT2Zmc2V0ID0gbmV3RWRnZU9mZnNldFxuXHRcdFx0fVxuXHRcdFx0cmV0dXJuIHtcblx0XHRcdFx0ZGVmYXVsdER1cmF0aW9uOiBkZWZhdWx0RHVyYXRpb24sXG5cdFx0XHRcdGVkZ2VPZmZzZXQ6IGVkZ2VPZmZzZXRcblx0XHRcdH1cblx0XHR9XG5cblx0XHRyZXR1cm4ge1xuXHRcdFx0c2V0dXA6IHNldHVwLFxuXHRcdFx0dG86IHNjcm9sbFRvRWxlbSxcblx0XHRcdHRvWTogc2Nyb2xsVG9ZLFxuXHRcdFx0aW50b1ZpZXc6IHNjcm9sbEludG9WaWV3LFxuXHRcdFx0Y2VudGVyOiBzY3JvbGxUb0NlbnRlck9mLFxuXHRcdFx0c3RvcDogc3RvcFNjcm9sbCxcblx0XHRcdG1vdmluZzogZnVuY3Rpb24gKCkgeyByZXR1cm4gISFzY3JvbGxUaW1lb3V0SWQgfSxcblx0XHRcdGdldFk6IGNvbnRhaW5lci5nZXRZLFxuXHRcdFx0Z2V0VG9wT2Y6IGNvbnRhaW5lci5nZXRUb3BPZlxuXHRcdH1cblxuXHR9XG5cblxuXHR2YXIgZG9jRWxlbSA9IGRvY3VtZW50LmRvY3VtZW50RWxlbWVudFxuXHR2YXIgZ2V0RG9jWSA9IGZ1bmN0aW9uICgpIHsgcmV0dXJuIHdpbmRvdy5zY3JvbGxZIHx8IGRvY0VsZW0uc2Nyb2xsVG9wIH1cblxuXHQvLyBDcmVhdGUgYSBzY3JvbGxlciBmb3IgdGhlIGRvY3VtZW50OlxuXHR2YXIgemVuc2Nyb2xsID0gbWFrZVNjcm9sbGVyKHtcblx0XHRib2R5OiBkb2N1bWVudC5zY3JvbGxpbmdFbGVtZW50IHx8IGRvY3VtZW50LmJvZHksXG5cdFx0dG9ZOiBmdW5jdGlvbiAoeSkgeyB3aW5kb3cuc2Nyb2xsVG8oMCwgeSkgfSxcblx0XHRnZXRZOiBnZXREb2NZLFxuXHRcdGdldEhlaWdodDogZnVuY3Rpb24gKCkgeyByZXR1cm4gd2luZG93LmlubmVySGVpZ2h0IHx8IGRvY0VsZW0uY2xpZW50SGVpZ2h0IH0sXG5cdFx0Z2V0VG9wT2Y6IGZ1bmN0aW9uIChlbGVtKSB7IHJldHVybiBlbGVtLmdldEJvdW5kaW5nQ2xpZW50UmVjdCgpLnRvcCArIGdldERvY1koKSAtIGRvY0VsZW0ub2Zmc2V0VG9wIH1cblx0fSlcblxuXG5cdC8qKlxuXHQgKiBDcmVhdGVzIGEgc2Nyb2xsZXIgZnJvbSB0aGUgcHJvdmlkZWQgY29udGFpbmVyIGVsZW1lbnQgKGUuZy4sIGEgRElWKVxuXHQgKlxuXHQgKiBAcGFyYW0ge3Njcm9sbENvbnRhaW5lcn0gVGhlIHZlcnRpY2FsIHBvc2l0aW9uIHdpdGhpbiB0aGUgZG9jdW1lbnQuXG5cdCAqIEBwYXJhbSB7ZGVmYXVsdER1cmF0aW9ufSBPcHRpb25hbGx5IGEgdmFsdWUgZm9yIGRlZmF1bHQgZHVyYXRpb24sIHVzZWQgZm9yIGVhY2ggc2Nyb2xsIG1ldGhvZCBieSBkZWZhdWx0LlxuXHQgKiAgICAgICAgSWdub3JlZCBpZiAwIG9yIG51bGwgb3IgdW5kZWZpbmVkLlxuXHQgKiBAcGFyYW0ge2VkZ2VPZmZzZXR9IE9wdGlvbmFsbHkgYSB2YWx1ZSBmb3IgdGhlIGVkZ2Ugb2Zmc2V0LCB1c2VkIGJ5IGVhY2ggc2Nyb2xsIG1ldGhvZCBieSBkZWZhdWx0LiBcblx0ICogICAgICAgIElnbm9yZWQgaWYgbnVsbCBvciB1bmRlZmluZWQuXG5cdCAqIEByZXR1cm5zIEEgc2Nyb2xsZXIgb2JqZWN0LCBzaW1pbGFyIHRvIGB6ZW5zY3JvbGxgIGJ1dCBjb250cm9sbGluZyB0aGUgcHJvdmlkZWQgZWxlbWVudC5cblx0ICovXG5cdHplbnNjcm9sbC5jcmVhdGVTY3JvbGxlciA9IGZ1bmN0aW9uIChzY3JvbGxDb250YWluZXIsIGRlZmF1bHREdXJhdGlvbiwgZWRnZU9mZnNldCkge1xuXHRcdHJldHVybiBtYWtlU2Nyb2xsZXIoe1xuXHRcdFx0Ym9keTogc2Nyb2xsQ29udGFpbmVyLFxuXHRcdFx0dG9ZOiBmdW5jdGlvbiAoeSkgeyBzY3JvbGxDb250YWluZXIuc2Nyb2xsVG9wID0geSB9LFxuXHRcdFx0Z2V0WTogZnVuY3Rpb24gKCkgeyByZXR1cm4gc2Nyb2xsQ29udGFpbmVyLnNjcm9sbFRvcCB9LFxuXHRcdFx0Z2V0SGVpZ2h0OiBmdW5jdGlvbiAoKSB7IHJldHVybiBNYXRoLm1pbihzY3JvbGxDb250YWluZXIuY2xpZW50SGVpZ2h0LCB3aW5kb3cuaW5uZXJIZWlnaHQgfHwgZG9jRWxlbS5jbGllbnRIZWlnaHQpIH0sXG5cdFx0XHRnZXRUb3BPZjogZnVuY3Rpb24gKGVsZW0pIHsgcmV0dXJuIGVsZW0ub2Zmc2V0VG9wIH1cblx0XHR9LCBkZWZhdWx0RHVyYXRpb24sIGVkZ2VPZmZzZXQpXG5cdH1cblxuXG5cdC8vIEF1dG9tYXRpYyBsaW5rLXNtb290aGluZyBvbiBhY2hvcnNcblx0Ly8gRXhjbHVkZSBJRTgtIG9yIHdoZW4gbmF0aXZlIGlzIGVuYWJsZWQgb3IgWmVuc2Nyb2xsIGF1dG8tIGlzIGRpc2FibGVkXG5cdGlmIChcImFkZEV2ZW50TGlzdGVuZXJcIiBpbiB3aW5kb3cgJiYgIXdpbmRvdy5ub1plbnNtb290aCAmJiAhaXNOYXRpdmVTbW9vdGhTY3JvbGxFbmFibGVkT24oZG9jdW1lbnQuYm9keSkpIHtcblxuXG5cdFx0dmFyIGlzU2Nyb2xsUmVzdG9yYXRpb25TdXBwb3J0ZWQgPSBcInNjcm9sbFJlc3RvcmF0aW9uXCIgaW4gaGlzdG9yeVxuXG5cdFx0Ly8gT24gZmlyc3QgbG9hZCAmIHJlZnJlc2ggbWFrZSBzdXJlIHRoZSBicm93c2VyIHJlc3RvcmVzIHRoZSBwb3NpdGlvbiBmaXJzdFxuXHRcdGlmIChpc1Njcm9sbFJlc3RvcmF0aW9uU3VwcG9ydGVkKSB7XG5cdFx0XHRoaXN0b3J5LnNjcm9sbFJlc3RvcmF0aW9uID0gXCJhdXRvXCJcblx0XHR9XG5cblx0XHR3aW5kb3cuYWRkRXZlbnRMaXN0ZW5lcihcImxvYWRcIiwgZnVuY3Rpb24gKCkge1xuXG5cdFx0XHRpZiAoaXNTY3JvbGxSZXN0b3JhdGlvblN1cHBvcnRlZCkge1xuXHRcdFx0XHQvLyBTZXQgaXQgdG8gbWFudWFsXG5cdFx0XHRcdHNldFRpbWVvdXQoZnVuY3Rpb24gKCkgeyBoaXN0b3J5LnNjcm9sbFJlc3RvcmF0aW9uID0gXCJtYW51YWxcIiB9LCA5KVxuXHRcdFx0XHR3aW5kb3cuYWRkRXZlbnRMaXN0ZW5lcihcInBvcHN0YXRlXCIsIGZ1bmN0aW9uIChldmVudCkge1xuXHRcdFx0XHRcdGlmIChldmVudC5zdGF0ZSAmJiBcInplbnNjcm9sbFlcIiBpbiBldmVudC5zdGF0ZSkge1xuXHRcdFx0XHRcdFx0emVuc2Nyb2xsLnRvWShldmVudC5zdGF0ZS56ZW5zY3JvbGxZKVxuXHRcdFx0XHRcdH1cblx0XHRcdFx0fSwgZmFsc2UpXG5cdFx0XHR9XG5cblx0XHRcdC8vIEFkZCBlZGdlIG9mZnNldCBvbiBmaXJzdCBsb2FkIGlmIG5lY2Vzc2FyeVxuXHRcdFx0Ly8gVGhpcyBtYXkgbm90IHdvcmsgb24gSUUgKG9yIG9sZGVyIGNvbXB1dGVyPykgYXMgaXQgcmVxdWlyZXMgbW9yZSB0aW1lb3V0LCBhcm91bmQgMTAwIG1zXG5cdFx0XHRpZiAod2luZG93LmxvY2F0aW9uLmhhc2gpIHtcblx0XHRcdFx0c2V0VGltZW91dChmdW5jdGlvbiAoKSB7XG5cdFx0XHRcdFx0Ly8gQWRqdXN0bWVudCBpcyBvbmx5IG5lZWRlZCBpZiB0aGVyZSBpcyBhbiBlZGdlIG9mZnNldDpcblx0XHRcdFx0XHR2YXIgZWRnZU9mZnNldCA9IHplbnNjcm9sbC5zZXR1cCgpLmVkZ2VPZmZzZXRcblx0XHRcdFx0XHRpZiAoZWRnZU9mZnNldCkge1xuXHRcdFx0XHRcdFx0dmFyIHRhcmdldEVsZW0gPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCh3aW5kb3cubG9jYXRpb24uaHJlZi5zcGxpdChcIiNcIilbMV0pXG5cdFx0XHRcdFx0XHRpZiAodGFyZ2V0RWxlbSkge1xuXHRcdFx0XHRcdFx0XHR2YXIgdGFyZ2V0WSA9IE1hdGgubWF4KDAsIHplbnNjcm9sbC5nZXRUb3BPZih0YXJnZXRFbGVtKSAtIGVkZ2VPZmZzZXQpXG5cdFx0XHRcdFx0XHRcdHZhciBkaWZmID0gemVuc2Nyb2xsLmdldFkoKSAtIHRhcmdldFlcblx0XHRcdFx0XHRcdFx0Ly8gT25seSBkbyB0aGUgYWRqdXN0bWVudCBpZiB0aGUgYnJvd3NlciBpcyB2ZXJ5IGNsb3NlIHRvIHRoZSBlbGVtZW50OlxuXHRcdFx0XHRcdFx0XHRpZiAoMCA8PSBkaWZmICYmIGRpZmYgPCA5ICkge1xuXHRcdFx0XHRcdFx0XHRcdHdpbmRvdy5zY3JvbGxUbygwLCB0YXJnZXRZKVxuXHRcdFx0XHRcdFx0XHR9XG5cdFx0XHRcdFx0XHR9XG5cdFx0XHRcdFx0fVxuXHRcdFx0XHR9LCA5KVxuXHRcdFx0fVxuXG5cdFx0fSwgZmFsc2UpXG5cblx0XHQvLyBIYW5kbGluZyBjbGlja3Mgb24gYW5jaG9yc1xuXHRcdHZhciBSRV9ub1plbnNtb290aCA9IG5ldyBSZWdFeHAoXCIoXnxcXFxccylub1plbnNtb290aChcXFxcc3wkKVwiKVxuXHRcdHdpbmRvdy5hZGRFdmVudExpc3RlbmVyKFwiY2xpY2tcIiwgZnVuY3Rpb24gKGV2ZW50KSB7XG5cdFx0XHR2YXIgYW5jaG9yID0gZXZlbnQudGFyZ2V0XG5cdFx0XHR3aGlsZSAoYW5jaG9yICYmIGFuY2hvci50YWdOYW1lICE9PSBcIkFcIikge1xuXHRcdFx0XHRhbmNob3IgPSBhbmNob3IucGFyZW50Tm9kZVxuXHRcdFx0fVxuXHRcdFx0Ly8gTGV0IHRoZSBicm93c2VyIGhhbmRsZSB0aGUgY2xpY2sgaWYgaXQgd2Fzbid0IHdpdGggdGhlIHByaW1hcnkgYnV0dG9uLCBvciB3aXRoIHNvbWUgbW9kaWZpZXIga2V5czpcblx0XHRcdGlmICghYW5jaG9yIHx8IGV2ZW50LndoaWNoICE9PSAxIHx8IGV2ZW50LnNoaWZ0S2V5IHx8IGV2ZW50Lm1ldGFLZXkgfHwgZXZlbnQuY3RybEtleSB8fCBldmVudC5hbHRLZXkpIHtcblx0XHRcdFx0cmV0dXJuXG5cdFx0XHR9XG5cdFx0XHQvLyBTYXZlIHRoZSBjdXJyZW50IHNjcm9sbGluZyBwb3NpdGlvbiBzbyBpdCBjYW4gYmUgdXNlZCBmb3Igc2Nyb2xsIHJlc3RvcmF0aW9uOlxuXHRcdFx0aWYgKGlzU2Nyb2xsUmVzdG9yYXRpb25TdXBwb3J0ZWQpIHtcblx0XHRcdFx0dHJ5IHtcblx0XHRcdFx0XHRoaXN0b3J5LnJlcGxhY2VTdGF0ZSh7IHplbnNjcm9sbFk6IHplbnNjcm9sbC5nZXRZKCkgfSwgXCJcIilcblx0XHRcdFx0fSBjYXRjaCAoZSkge1xuXHRcdFx0XHRcdC8vIEF2b2lkIHRoZSBDaHJvbWUgU2VjdXJpdHkgZXhjZXB0aW9uIG9uIGZpbGUgcHJvdG9jb2wsIGUuZy4sIGZpbGU6Ly9pbmRleC5odG1sXG5cdFx0XHRcdH1cblx0XHRcdH1cblx0XHRcdC8vIEZpbmQgdGhlIHJlZmVyZW5jZWQgSUQ6XG5cdFx0XHR2YXIgaHJlZiA9IGFuY2hvci5nZXRBdHRyaWJ1dGUoXCJocmVmXCIpIHx8IFwiXCJcblx0XHRcdGlmIChocmVmLmluZGV4T2YoXCIjXCIpID09PSAwICYmICFSRV9ub1plbnNtb290aC50ZXN0KGFuY2hvci5jbGFzc05hbWUpKSB7XG5cdFx0XHRcdHZhciB0YXJnZXRZID0gMFxuXHRcdFx0XHR2YXIgdGFyZ2V0RWxlbSA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKGhyZWYuc3Vic3RyaW5nKDEpKVxuXHRcdFx0XHRpZiAoaHJlZiAhPT0gXCIjXCIpIHtcblx0XHRcdFx0XHRpZiAoIXRhcmdldEVsZW0pIHtcblx0XHRcdFx0XHRcdC8vIExldCB0aGUgYnJvd3NlciBoYW5kbGUgdGhlIGNsaWNrIGlmIHRoZSB0YXJnZXQgSUQgaXMgbm90IGZvdW5kLlxuXHRcdFx0XHRcdFx0cmV0dXJuXG5cdFx0XHRcdFx0fVxuXHRcdFx0XHRcdHRhcmdldFkgPSB6ZW5zY3JvbGwuZ2V0VG9wT2YodGFyZ2V0RWxlbSlcblx0XHRcdFx0fVxuXHRcdFx0XHRldmVudC5wcmV2ZW50RGVmYXVsdCgpXG5cdFx0XHRcdC8vIEJ5IGRlZmF1bHQgdHJpZ2dlciB0aGUgYnJvd3NlcidzIGBoYXNoY2hhbmdlYCBldmVudC4uLlxuXHRcdFx0XHR2YXIgb25Eb25lID0gZnVuY3Rpb24gKCkgeyB3aW5kb3cubG9jYXRpb24gPSBocmVmIH1cblx0XHRcdFx0Ly8gLi4udW5sZXNzIHRoZXJlIGlzIGFuIGVkZ2Ugb2Zmc2V0IHNwZWNpZmllZFxuXHRcdFx0XHR2YXIgZWRnZU9mZnNldCA9IHplbnNjcm9sbC5zZXR1cCgpLmVkZ2VPZmZzZXRcblx0XHRcdFx0aWYgKGVkZ2VPZmZzZXQpIHtcblx0XHRcdFx0XHR0YXJnZXRZID0gTWF0aC5tYXgoMCwgdGFyZ2V0WSAtIGVkZ2VPZmZzZXQpXG5cdFx0XHRcdFx0b25Eb25lID0gZnVuY3Rpb24gKCkgeyBoaXN0b3J5LnB1c2hTdGF0ZShudWxsLCBcIlwiLCBocmVmKSB9XG5cdFx0XHRcdH1cblx0XHRcdFx0emVuc2Nyb2xsLnRvWSh0YXJnZXRZLCBudWxsLCBvbkRvbmUpXG5cdFx0XHR9XG5cdFx0fSwgZmFsc2UpXG5cblx0fVxuXG5cblx0cmV0dXJuIHplbnNjcm9sbFxuXG5cbn0pKTtcblxuXG5cbi8vLy8vLy8vLy8vLy8vLy8vL1xuLy8gV0VCUEFDSyBGT09URVJcbi8vIC4vfi96ZW5zY3JvbGwvemVuc2Nyb2xsLmpzXG4vLyBtb2R1bGUgaWQgPSAxXG4vLyBtb2R1bGUgY2h1bmtzID0gMCJdLCJtYXBwaW5ncyI6IkFBQUE7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUFBO0FBQUE7QUFBQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7Iiwic291cmNlUm9vdCI6IiJ9");
-
-/***/ }),
-/* 2 */
-/* unknown exports provided */
-/* all exports used */
-/*!******************************!*\
-  !*** ./src/js/build-html.js ***!
-  \******************************/
-/***/ (function(module, exports) {
-
-eval("/**\n * This file is responsible for building the DOM and updating DOM state.\n *\n * @author Tim Scanlin\n */\n\nmodule.exports = function (options) {\n  var forEach = [].forEach\n  var some = [].some\n  var body = document.body\n  var currentlyHighlighting = true\n  var SPACE_CHAR = ' '\n\n  /**\n   * Create link and list elements.\n   * @param {Object} d\n   * @param {HTMLElement} container\n   * @return {HTMLElement}\n   */\n  function createEl (d, container) {\n    var link = container.appendChild(createLink(d))\n    if (d.children.length) {\n      var list = createList(d.isCollapsed)\n      d.children.forEach(function (child) {\n        createEl(child, list)\n      })\n      link.appendChild(list)\n    }\n  }\n\n  /**\n   * Render nested heading array data into a given selector.\n   * @param {String} selector\n   * @param {Array} data\n   * @return {HTMLElement}\n   */\n  function render (selector, data) {\n    var collapsed = false\n    var container = createList(collapsed)\n\n    data.forEach(function (d) {\n      createEl(d, container)\n    })\n\n    var parent = document.querySelector(selector)\n\n    // Return if no parent is found.\n    if (parent === null) {\n      return\n    }\n\n    // Remove existing child if it exists.\n    if (parent.firstChild) {\n      parent.removeChild(parent.firstChild)\n    }\n\n    // Append the Elements that have been created;\n    return parent.appendChild(container)\n  }\n\n  /**\n   * Create link element.\n   * @param {Object} data\n   * @return {HTMLElement}\n   */\n  function createLink (data) {\n    var item = document.createElement('li')\n    var a = document.createElement('a')\n    if (options.listItemClass) {\n      item.setAttribute('class', options.listItemClass)\n    }\n    if (options.includeHtml && data.childNodes.length) {\n      forEach.call(data.childNodes, function (node) {\n        a.appendChild(node.cloneNode(true))\n      })\n    } else {\n      // Default behavior.\n      a.textContent = data.textContent\n    }\n    a.setAttribute('href', '#' + data.id)\n    a.setAttribute('class', options.linkClass +\n      SPACE_CHAR + 'node-name--' + data.nodeName +\n      SPACE_CHAR + options.extraLinkClasses)\n    item.appendChild(a)\n    return item\n  }\n\n  /**\n   * Create list element.\n   * @param {Boolean} isCollapsed\n   * @return {HTMLElement}\n   */\n  function createList (isCollapsed) {\n    var list = document.createElement('ul')\n    var classes = options.listClass +\n      SPACE_CHAR + options.extraListClasses\n    if (isCollapsed) {\n      classes += SPACE_CHAR + options.collapsibleClass\n      classes += SPACE_CHAR + options.isCollapsedClass\n    }\n    list.setAttribute('class', classes)\n    return list\n  }\n\n  /**\n   * Update fixed sidebar class.\n   * @return {HTMLElement}\n   */\n  function updateFixedSidebarClass () {\n    var top = document.documentElement.scrollTop || body.scrollTop\n    var posFixedEl = document.querySelector(options.positionFixedSelector)\n\n    if (options.fixedSidebarOffset === 'auto') {\n      options.fixedSidebarOffset = document.querySelector(options.tocSelector).offsetTop\n    }\n\n    if (top > options.fixedSidebarOffset) {\n      if (posFixedEl.className.indexOf(options.positionFixedClass) === -1) {\n        posFixedEl.className += SPACE_CHAR + options.positionFixedClass\n      }\n    } else {\n      posFixedEl.className = posFixedEl.className.split(SPACE_CHAR + options.positionFixedClass).join('')\n    }\n  }\n\n  /**\n   * Update TOC highlighting and collpased groupings.\n   */\n  function updateToc (headingsArray) {\n    var top = document.documentElement.scrollTop || body.scrollTop\n\n    // Add fixed class at offset;\n    if (options.positionFixedSelector) {\n      updateFixedSidebarClass()\n    }\n\n    // Get the top most heading currently visible on the page so we know what to highlight.\n    var headings = headingsArray\n    var topHeader\n    // Using some instead of each so that we can escape early.\n    if (currentlyHighlighting &&\n      document.querySelector(options.tocSelector) !== null &&\n      headings.length > 0) {\n      some.call(headings, function (heading, i) {\n        if (heading.offsetTop > top + options.headingsOffset + 10) {\n          // Don't allow negative index value.\n          var index = (i === 0) ? i : i - 1\n          topHeader = headings[index]\n          return true\n        } else if (i === headings.length - 1) {\n          // This allows scrolling for the last heading on the page.\n          topHeader = headings[headings.length - 1]\n          return true\n        }\n      })\n\n      // Remove the active class from the other tocLinks.\n      var tocLinks = document.querySelector(options.tocSelector)\n        .querySelectorAll('.' + options.linkClass)\n      forEach.call(tocLinks, function (tocLink) {\n        tocLink.className = tocLink.className.split(SPACE_CHAR + options.activeLinkClass).join('')\n      })\n\n      // Add the active class to the active tocLink.\n      var activeTocLink = document.querySelector(options.tocSelector)\n        .querySelector('.' + options.linkClass +\n          '.node-name--' + topHeader.nodeName +\n          '[href=\"#' + topHeader.id + '\"]')\n      activeTocLink.className += SPACE_CHAR + options.activeLinkClass\n\n      var tocLists = document.querySelector(options.tocSelector)\n        .querySelectorAll('.' + options.listClass + '.' + options.collapsibleClass)\n\n      // Collapse the other collapsible lists.\n      forEach.call(tocLists, function (list) {\n        var collapsedClass = SPACE_CHAR + options.isCollapsedClass\n        if (list.className.indexOf(collapsedClass) === -1) {\n          list.className += SPACE_CHAR + options.isCollapsedClass\n        }\n      })\n\n      // Expand the active link's collapsible list and its sibling if applicable.\n      if (activeTocLink.nextSibling) {\n        activeTocLink.nextSibling.className = activeTocLink.nextSibling.className.split(SPACE_CHAR + options.isCollapsedClass).join('')\n      }\n      removeCollapsedFromParents(activeTocLink.parentNode.parentNode)\n    }\n  }\n\n  /**\n   * Remove collpased class from parent elements.\n   * @param {HTMLElement} element\n   * @return {HTMLElement}\n   */\n  function removeCollapsedFromParents (element) {\n    if (element.className.indexOf(options.collapsibleClass) !== -1) {\n      element.className = element.className.split(SPACE_CHAR + options.isCollapsedClass).join('')\n      return removeCollapsedFromParents(element.parentNode.parentNode)\n    }\n    return element\n  }\n\n  /**\n   * Disable TOC Animation when a link is clicked.\n   * @param {Event} event\n   */\n  function disableTocAnimation (event) {\n    var target = event.target || event.srcElement\n    if (typeof target.className !== 'string' || target.className.indexOf(options.linkClass) === -1) {\n      return\n    }\n    // Bind to tocLink clicks to temporarily disable highlighting\n    // while smoothScroll is animating.\n    currentlyHighlighting = false\n  }\n\n  /**\n   * Enable TOC Animation.\n   */\n  function enableTocAnimation () {\n    currentlyHighlighting = true\n  }\n\n  return {\n    enableTocAnimation: enableTocAnimation,\n    disableTocAnimation: disableTocAnimation,\n    render: render,\n    updateToc: updateToc\n  }\n}\n//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiMi5qcyIsInNvdXJjZXMiOlsid2VicGFjazovLy8uL3NyYy9qcy9idWlsZC1odG1sLmpzPzdkMDEiXSwic291cmNlc0NvbnRlbnQiOlsiLyoqXG4gKiBUaGlzIGZpbGUgaXMgcmVzcG9uc2libGUgZm9yIGJ1aWxkaW5nIHRoZSBET00gYW5kIHVwZGF0aW5nIERPTSBzdGF0ZS5cbiAqXG4gKiBAYXV0aG9yIFRpbSBTY2FubGluXG4gKi9cblxubW9kdWxlLmV4cG9ydHMgPSBmdW5jdGlvbiAob3B0aW9ucykge1xuICB2YXIgZm9yRWFjaCA9IFtdLmZvckVhY2hcbiAgdmFyIHNvbWUgPSBbXS5zb21lXG4gIHZhciBib2R5ID0gZG9jdW1lbnQuYm9keVxuICB2YXIgY3VycmVudGx5SGlnaGxpZ2h0aW5nID0gdHJ1ZVxuICB2YXIgU1BBQ0VfQ0hBUiA9ICcgJ1xuXG4gIC8qKlxuICAgKiBDcmVhdGUgbGluayBhbmQgbGlzdCBlbGVtZW50cy5cbiAgICogQHBhcmFtIHtPYmplY3R9IGRcbiAgICogQHBhcmFtIHtIVE1MRWxlbWVudH0gY29udGFpbmVyXG4gICAqIEByZXR1cm4ge0hUTUxFbGVtZW50fVxuICAgKi9cbiAgZnVuY3Rpb24gY3JlYXRlRWwgKGQsIGNvbnRhaW5lcikge1xuICAgIHZhciBsaW5rID0gY29udGFpbmVyLmFwcGVuZENoaWxkKGNyZWF0ZUxpbmsoZCkpXG4gICAgaWYgKGQuY2hpbGRyZW4ubGVuZ3RoKSB7XG4gICAgICB2YXIgbGlzdCA9IGNyZWF0ZUxpc3QoZC5pc0NvbGxhcHNlZClcbiAgICAgIGQuY2hpbGRyZW4uZm9yRWFjaChmdW5jdGlvbiAoY2hpbGQpIHtcbiAgICAgICAgY3JlYXRlRWwoY2hpbGQsIGxpc3QpXG4gICAgICB9KVxuICAgICAgbGluay5hcHBlbmRDaGlsZChsaXN0KVxuICAgIH1cbiAgfVxuXG4gIC8qKlxuICAgKiBSZW5kZXIgbmVzdGVkIGhlYWRpbmcgYXJyYXkgZGF0YSBpbnRvIGEgZ2l2ZW4gc2VsZWN0b3IuXG4gICAqIEBwYXJhbSB7U3RyaW5nfSBzZWxlY3RvclxuICAgKiBAcGFyYW0ge0FycmF5fSBkYXRhXG4gICAqIEByZXR1cm4ge0hUTUxFbGVtZW50fVxuICAgKi9cbiAgZnVuY3Rpb24gcmVuZGVyIChzZWxlY3RvciwgZGF0YSkge1xuICAgIHZhciBjb2xsYXBzZWQgPSBmYWxzZVxuICAgIHZhciBjb250YWluZXIgPSBjcmVhdGVMaXN0KGNvbGxhcHNlZClcblxuICAgIGRhdGEuZm9yRWFjaChmdW5jdGlvbiAoZCkge1xuICAgICAgY3JlYXRlRWwoZCwgY29udGFpbmVyKVxuICAgIH0pXG5cbiAgICB2YXIgcGFyZW50ID0gZG9jdW1lbnQucXVlcnlTZWxlY3RvcihzZWxlY3RvcilcblxuICAgIC8vIFJldHVybiBpZiBubyBwYXJlbnQgaXMgZm91bmQuXG4gICAgaWYgKHBhcmVudCA9PT0gbnVsbCkge1xuICAgICAgcmV0dXJuXG4gICAgfVxuXG4gICAgLy8gUmVtb3ZlIGV4aXN0aW5nIGNoaWxkIGlmIGl0IGV4aXN0cy5cbiAgICBpZiAocGFyZW50LmZpcnN0Q2hpbGQpIHtcbiAgICAgIHBhcmVudC5yZW1vdmVDaGlsZChwYXJlbnQuZmlyc3RDaGlsZClcbiAgICB9XG5cbiAgICAvLyBBcHBlbmQgdGhlIEVsZW1lbnRzIHRoYXQgaGF2ZSBiZWVuIGNyZWF0ZWQ7XG4gICAgcmV0dXJuIHBhcmVudC5hcHBlbmRDaGlsZChjb250YWluZXIpXG4gIH1cblxuICAvKipcbiAgICogQ3JlYXRlIGxpbmsgZWxlbWVudC5cbiAgICogQHBhcmFtIHtPYmplY3R9IGRhdGFcbiAgICogQHJldHVybiB7SFRNTEVsZW1lbnR9XG4gICAqL1xuICBmdW5jdGlvbiBjcmVhdGVMaW5rIChkYXRhKSB7XG4gICAgdmFyIGl0ZW0gPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdsaScpXG4gICAgdmFyIGEgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdhJylcbiAgICBpZiAob3B0aW9ucy5saXN0SXRlbUNsYXNzKSB7XG4gICAgICBpdGVtLnNldEF0dHJpYnV0ZSgnY2xhc3MnLCBvcHRpb25zLmxpc3RJdGVtQ2xhc3MpXG4gICAgfVxuICAgIGlmIChvcHRpb25zLmluY2x1ZGVIdG1sICYmIGRhdGEuY2hpbGROb2Rlcy5sZW5ndGgpIHtcbiAgICAgIGZvckVhY2guY2FsbChkYXRhLmNoaWxkTm9kZXMsIGZ1bmN0aW9uIChub2RlKSB7XG4gICAgICAgIGEuYXBwZW5kQ2hpbGQobm9kZS5jbG9uZU5vZGUodHJ1ZSkpXG4gICAgICB9KVxuICAgIH0gZWxzZSB7XG4gICAgICAvLyBEZWZhdWx0IGJlaGF2aW9yLlxuICAgICAgYS50ZXh0Q29udGVudCA9IGRhdGEudGV4dENvbnRlbnRcbiAgICB9XG4gICAgYS5zZXRBdHRyaWJ1dGUoJ2hyZWYnLCAnIycgKyBkYXRhLmlkKVxuICAgIGEuc2V0QXR0cmlidXRlKCdjbGFzcycsIG9wdGlvbnMubGlua0NsYXNzICtcbiAgICAgIFNQQUNFX0NIQVIgKyAnbm9kZS1uYW1lLS0nICsgZGF0YS5ub2RlTmFtZSArXG4gICAgICBTUEFDRV9DSEFSICsgb3B0aW9ucy5leHRyYUxpbmtDbGFzc2VzKVxuICAgIGl0ZW0uYXBwZW5kQ2hpbGQoYSlcbiAgICByZXR1cm4gaXRlbVxuICB9XG5cbiAgLyoqXG4gICAqIENyZWF0ZSBsaXN0IGVsZW1lbnQuXG4gICAqIEBwYXJhbSB7Qm9vbGVhbn0gaXNDb2xsYXBzZWRcbiAgICogQHJldHVybiB7SFRNTEVsZW1lbnR9XG4gICAqL1xuICBmdW5jdGlvbiBjcmVhdGVMaXN0IChpc0NvbGxhcHNlZCkge1xuICAgIHZhciBsaXN0ID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgndWwnKVxuICAgIHZhciBjbGFzc2VzID0gb3B0aW9ucy5saXN0Q2xhc3MgK1xuICAgICAgU1BBQ0VfQ0hBUiArIG9wdGlvbnMuZXh0cmFMaXN0Q2xhc3Nlc1xuICAgIGlmIChpc0NvbGxhcHNlZCkge1xuICAgICAgY2xhc3NlcyArPSBTUEFDRV9DSEFSICsgb3B0aW9ucy5jb2xsYXBzaWJsZUNsYXNzXG4gICAgICBjbGFzc2VzICs9IFNQQUNFX0NIQVIgKyBvcHRpb25zLmlzQ29sbGFwc2VkQ2xhc3NcbiAgICB9XG4gICAgbGlzdC5zZXRBdHRyaWJ1dGUoJ2NsYXNzJywgY2xhc3NlcylcbiAgICByZXR1cm4gbGlzdFxuICB9XG5cbiAgLyoqXG4gICAqIFVwZGF0ZSBmaXhlZCBzaWRlYmFyIGNsYXNzLlxuICAgKiBAcmV0dXJuIHtIVE1MRWxlbWVudH1cbiAgICovXG4gIGZ1bmN0aW9uIHVwZGF0ZUZpeGVkU2lkZWJhckNsYXNzICgpIHtcbiAgICB2YXIgdG9wID0gZG9jdW1lbnQuZG9jdW1lbnRFbGVtZW50LnNjcm9sbFRvcCB8fCBib2R5LnNjcm9sbFRvcFxuICAgIHZhciBwb3NGaXhlZEVsID0gZG9jdW1lbnQucXVlcnlTZWxlY3RvcihvcHRpb25zLnBvc2l0aW9uRml4ZWRTZWxlY3RvcilcblxuICAgIGlmIChvcHRpb25zLmZpeGVkU2lkZWJhck9mZnNldCA9PT0gJ2F1dG8nKSB7XG4gICAgICBvcHRpb25zLmZpeGVkU2lkZWJhck9mZnNldCA9IGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3Iob3B0aW9ucy50b2NTZWxlY3Rvcikub2Zmc2V0VG9wXG4gICAgfVxuXG4gICAgaWYgKHRvcCA+IG9wdGlvbnMuZml4ZWRTaWRlYmFyT2Zmc2V0KSB7XG4gICAgICBpZiAocG9zRml4ZWRFbC5jbGFzc05hbWUuaW5kZXhPZihvcHRpb25zLnBvc2l0aW9uRml4ZWRDbGFzcykgPT09IC0xKSB7XG4gICAgICAgIHBvc0ZpeGVkRWwuY2xhc3NOYW1lICs9IFNQQUNFX0NIQVIgKyBvcHRpb25zLnBvc2l0aW9uRml4ZWRDbGFzc1xuICAgICAgfVxuICAgIH0gZWxzZSB7XG4gICAgICBwb3NGaXhlZEVsLmNsYXNzTmFtZSA9IHBvc0ZpeGVkRWwuY2xhc3NOYW1lLnNwbGl0KFNQQUNFX0NIQVIgKyBvcHRpb25zLnBvc2l0aW9uRml4ZWRDbGFzcykuam9pbignJylcbiAgICB9XG4gIH1cblxuICAvKipcbiAgICogVXBkYXRlIFRPQyBoaWdobGlnaHRpbmcgYW5kIGNvbGxwYXNlZCBncm91cGluZ3MuXG4gICAqL1xuICBmdW5jdGlvbiB1cGRhdGVUb2MgKGhlYWRpbmdzQXJyYXkpIHtcbiAgICB2YXIgdG9wID0gZG9jdW1lbnQuZG9jdW1lbnRFbGVtZW50LnNjcm9sbFRvcCB8fCBib2R5LnNjcm9sbFRvcFxuXG4gICAgLy8gQWRkIGZpeGVkIGNsYXNzIGF0IG9mZnNldDtcbiAgICBpZiAob3B0aW9ucy5wb3NpdGlvbkZpeGVkU2VsZWN0b3IpIHtcbiAgICAgIHVwZGF0ZUZpeGVkU2lkZWJhckNsYXNzKClcbiAgICB9XG5cbiAgICAvLyBHZXQgdGhlIHRvcCBtb3N0IGhlYWRpbmcgY3VycmVudGx5IHZpc2libGUgb24gdGhlIHBhZ2Ugc28gd2Uga25vdyB3aGF0IHRvIGhpZ2hsaWdodC5cbiAgICB2YXIgaGVhZGluZ3MgPSBoZWFkaW5nc0FycmF5XG4gICAgdmFyIHRvcEhlYWRlclxuICAgIC8vIFVzaW5nIHNvbWUgaW5zdGVhZCBvZiBlYWNoIHNvIHRoYXQgd2UgY2FuIGVzY2FwZSBlYXJseS5cbiAgICBpZiAoY3VycmVudGx5SGlnaGxpZ2h0aW5nICYmXG4gICAgICBkb2N1bWVudC5xdWVyeVNlbGVjdG9yKG9wdGlvbnMudG9jU2VsZWN0b3IpICE9PSBudWxsICYmXG4gICAgICBoZWFkaW5ncy5sZW5ndGggPiAwKSB7XG4gICAgICBzb21lLmNhbGwoaGVhZGluZ3MsIGZ1bmN0aW9uIChoZWFkaW5nLCBpKSB7XG4gICAgICAgIGlmIChoZWFkaW5nLm9mZnNldFRvcCA+IHRvcCArIG9wdGlvbnMuaGVhZGluZ3NPZmZzZXQgKyAxMCkge1xuICAgICAgICAgIC8vIERvbid0IGFsbG93IG5lZ2F0aXZlIGluZGV4IHZhbHVlLlxuICAgICAgICAgIHZhciBpbmRleCA9IChpID09PSAwKSA/IGkgOiBpIC0gMVxuICAgICAgICAgIHRvcEhlYWRlciA9IGhlYWRpbmdzW2luZGV4XVxuICAgICAgICAgIHJldHVybiB0cnVlXG4gICAgICAgIH0gZWxzZSBpZiAoaSA9PT0gaGVhZGluZ3MubGVuZ3RoIC0gMSkge1xuICAgICAgICAgIC8vIFRoaXMgYWxsb3dzIHNjcm9sbGluZyBmb3IgdGhlIGxhc3QgaGVhZGluZyBvbiB0aGUgcGFnZS5cbiAgICAgICAgICB0b3BIZWFkZXIgPSBoZWFkaW5nc1toZWFkaW5ncy5sZW5ndGggLSAxXVxuICAgICAgICAgIHJldHVybiB0cnVlXG4gICAgICAgIH1cbiAgICAgIH0pXG5cbiAgICAgIC8vIFJlbW92ZSB0aGUgYWN0aXZlIGNsYXNzIGZyb20gdGhlIG90aGVyIHRvY0xpbmtzLlxuICAgICAgdmFyIHRvY0xpbmtzID0gZG9jdW1lbnQucXVlcnlTZWxlY3RvcihvcHRpb25zLnRvY1NlbGVjdG9yKVxuICAgICAgICAucXVlcnlTZWxlY3RvckFsbCgnLicgKyBvcHRpb25zLmxpbmtDbGFzcylcbiAgICAgIGZvckVhY2guY2FsbCh0b2NMaW5rcywgZnVuY3Rpb24gKHRvY0xpbmspIHtcbiAgICAgICAgdG9jTGluay5jbGFzc05hbWUgPSB0b2NMaW5rLmNsYXNzTmFtZS5zcGxpdChTUEFDRV9DSEFSICsgb3B0aW9ucy5hY3RpdmVMaW5rQ2xhc3MpLmpvaW4oJycpXG4gICAgICB9KVxuXG4gICAgICAvLyBBZGQgdGhlIGFjdGl2ZSBjbGFzcyB0byB0aGUgYWN0aXZlIHRvY0xpbmsuXG4gICAgICB2YXIgYWN0aXZlVG9jTGluayA9IGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3Iob3B0aW9ucy50b2NTZWxlY3RvcilcbiAgICAgICAgLnF1ZXJ5U2VsZWN0b3IoJy4nICsgb3B0aW9ucy5saW5rQ2xhc3MgK1xuICAgICAgICAgICcubm9kZS1uYW1lLS0nICsgdG9wSGVhZGVyLm5vZGVOYW1lICtcbiAgICAgICAgICAnW2hyZWY9XCIjJyArIHRvcEhlYWRlci5pZCArICdcIl0nKVxuICAgICAgYWN0aXZlVG9jTGluay5jbGFzc05hbWUgKz0gU1BBQ0VfQ0hBUiArIG9wdGlvbnMuYWN0aXZlTGlua0NsYXNzXG5cbiAgICAgIHZhciB0b2NMaXN0cyA9IGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3Iob3B0aW9ucy50b2NTZWxlY3RvcilcbiAgICAgICAgLnF1ZXJ5U2VsZWN0b3JBbGwoJy4nICsgb3B0aW9ucy5saXN0Q2xhc3MgKyAnLicgKyBvcHRpb25zLmNvbGxhcHNpYmxlQ2xhc3MpXG5cbiAgICAgIC8vIENvbGxhcHNlIHRoZSBvdGhlciBjb2xsYXBzaWJsZSBsaXN0cy5cbiAgICAgIGZvckVhY2guY2FsbCh0b2NMaXN0cywgZnVuY3Rpb24gKGxpc3QpIHtcbiAgICAgICAgdmFyIGNvbGxhcHNlZENsYXNzID0gU1BBQ0VfQ0hBUiArIG9wdGlvbnMuaXNDb2xsYXBzZWRDbGFzc1xuICAgICAgICBpZiAobGlzdC5jbGFzc05hbWUuaW5kZXhPZihjb2xsYXBzZWRDbGFzcykgPT09IC0xKSB7XG4gICAgICAgICAgbGlzdC5jbGFzc05hbWUgKz0gU1BBQ0VfQ0hBUiArIG9wdGlvbnMuaXNDb2xsYXBzZWRDbGFzc1xuICAgICAgICB9XG4gICAgICB9KVxuXG4gICAgICAvLyBFeHBhbmQgdGhlIGFjdGl2ZSBsaW5rJ3MgY29sbGFwc2libGUgbGlzdCBhbmQgaXRzIHNpYmxpbmcgaWYgYXBwbGljYWJsZS5cbiAgICAgIGlmIChhY3RpdmVUb2NMaW5rLm5leHRTaWJsaW5nKSB7XG4gICAgICAgIGFjdGl2ZVRvY0xpbmsubmV4dFNpYmxpbmcuY2xhc3NOYW1lID0gYWN0aXZlVG9jTGluay5uZXh0U2libGluZy5jbGFzc05hbWUuc3BsaXQoU1BBQ0VfQ0hBUiArIG9wdGlvbnMuaXNDb2xsYXBzZWRDbGFzcykuam9pbignJylcbiAgICAgIH1cbiAgICAgIHJlbW92ZUNvbGxhcHNlZEZyb21QYXJlbnRzKGFjdGl2ZVRvY0xpbmsucGFyZW50Tm9kZS5wYXJlbnROb2RlKVxuICAgIH1cbiAgfVxuXG4gIC8qKlxuICAgKiBSZW1vdmUgY29sbHBhc2VkIGNsYXNzIGZyb20gcGFyZW50IGVsZW1lbnRzLlxuICAgKiBAcGFyYW0ge0hUTUxFbGVtZW50fSBlbGVtZW50XG4gICAqIEByZXR1cm4ge0hUTUxFbGVtZW50fVxuICAgKi9cbiAgZnVuY3Rpb24gcmVtb3ZlQ29sbGFwc2VkRnJvbVBhcmVudHMgKGVsZW1lbnQpIHtcbiAgICBpZiAoZWxlbWVudC5jbGFzc05hbWUuaW5kZXhPZihvcHRpb25zLmNvbGxhcHNpYmxlQ2xhc3MpICE9PSAtMSkge1xuICAgICAgZWxlbWVudC5jbGFzc05hbWUgPSBlbGVtZW50LmNsYXNzTmFtZS5zcGxpdChTUEFDRV9DSEFSICsgb3B0aW9ucy5pc0NvbGxhcHNlZENsYXNzKS5qb2luKCcnKVxuICAgICAgcmV0dXJuIHJlbW92ZUNvbGxhcHNlZEZyb21QYXJlbnRzKGVsZW1lbnQucGFyZW50Tm9kZS5wYXJlbnROb2RlKVxuICAgIH1cbiAgICByZXR1cm4gZWxlbWVudFxuICB9XG5cbiAgLyoqXG4gICAqIERpc2FibGUgVE9DIEFuaW1hdGlvbiB3aGVuIGEgbGluayBpcyBjbGlja2VkLlxuICAgKiBAcGFyYW0ge0V2ZW50fSBldmVudFxuICAgKi9cbiAgZnVuY3Rpb24gZGlzYWJsZVRvY0FuaW1hdGlvbiAoZXZlbnQpIHtcbiAgICB2YXIgdGFyZ2V0ID0gZXZlbnQudGFyZ2V0IHx8IGV2ZW50LnNyY0VsZW1lbnRcbiAgICBpZiAodHlwZW9mIHRhcmdldC5jbGFzc05hbWUgIT09ICdzdHJpbmcnIHx8IHRhcmdldC5jbGFzc05hbWUuaW5kZXhPZihvcHRpb25zLmxpbmtDbGFzcykgPT09IC0xKSB7XG4gICAgICByZXR1cm5cbiAgICB9XG4gICAgLy8gQmluZCB0byB0b2NMaW5rIGNsaWNrcyB0byB0ZW1wb3JhcmlseSBkaXNhYmxlIGhpZ2hsaWdodGluZ1xuICAgIC8vIHdoaWxlIHNtb290aFNjcm9sbCBpcyBhbmltYXRpbmcuXG4gICAgY3VycmVudGx5SGlnaGxpZ2h0aW5nID0gZmFsc2VcbiAgfVxuXG4gIC8qKlxuICAgKiBFbmFibGUgVE9DIEFuaW1hdGlvbi5cbiAgICovXG4gIGZ1bmN0aW9uIGVuYWJsZVRvY0FuaW1hdGlvbiAoKSB7XG4gICAgY3VycmVudGx5SGlnaGxpZ2h0aW5nID0gdHJ1ZVxuICB9XG5cbiAgcmV0dXJuIHtcbiAgICBlbmFibGVUb2NBbmltYXRpb246IGVuYWJsZVRvY0FuaW1hdGlvbixcbiAgICBkaXNhYmxlVG9jQW5pbWF0aW9uOiBkaXNhYmxlVG9jQW5pbWF0aW9uLFxuICAgIHJlbmRlcjogcmVuZGVyLFxuICAgIHVwZGF0ZVRvYzogdXBkYXRlVG9jXG4gIH1cbn1cblxuXG5cbi8vLy8vLy8vLy8vLy8vLy8vL1xuLy8gV0VCUEFDSyBGT09URVJcbi8vIC4vc3JjL2pzL2J1aWxkLWh0bWwuanNcbi8vIG1vZHVsZSBpZCA9IDJcbi8vIG1vZHVsZSBjaHVua3MgPSAwIl0sIm1hcHBpbmdzIjoiQUFBQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBOyIsInNvdXJjZVJvb3QiOiIifQ==");
-
-/***/ }),
-/* 3 */
-/* unknown exports provided */
-/* all exports used */
-/*!***********************************!*\
-  !*** ./src/js/default-options.js ***!
-  \***********************************/
-/***/ (function(module, exports) {
-
-eval("module.exports = {\n  // Where to render the table of contents.\n  tocSelector: '.js-toc',\n  // Where to grab the headings to build the table of contents.\n  contentSelector: '.js-toc-content',\n  // Which headings to grab inside of the contentSelector element.\n  headingSelector: 'h1, h2, h3',\n  // Headings that match the ignoreSelector will be skipped.\n  ignoreSelector: '.js-toc-ignore',\n  // Main class to add to links.\n  linkClass: 'toc-link',\n  // Extra classes to add to links.\n  extraLinkClasses: '',\n  // Class to add to active links,\n  // the link corresponding to the top most heading on the page.\n  activeLinkClass: 'is-active-link',\n  // Main class to add to lists.\n  listClass: 'toc-list',\n  // Extra classes to add to lists.\n  extraListClasses: '',\n  // Class that gets added when a list should be collapsed.\n  isCollapsedClass: 'is-collapsed',\n  // Class that gets added when a list should be able\n  // to be collapsed but isn't necessarily collpased.\n  collapsibleClass: 'is-collapsible',\n  // Class to add to list items.\n  listItemClass: 'toc-list-item',\n  // How many heading levels should not be collpased.\n  // For example, number 6 will show everything since\n  // there are only 6 heading levels and number 0 will collpase them all.\n  // The sections that are hidden will open\n  // and close as you scroll to headings within them.\n  collapseDepth: 0,\n  // Smooth scrolling enabled.\n  smoothScroll: true,\n  // Smooth scroll duration.\n  smoothScrollDuration: 420,\n  // Callback for scroll end (requires: smoothScroll).\n  scrollEndCallback: function (e) {},\n  // Headings offset between the headings and the top of the document.\n  headingsOffset: 0,\n  // Timeout between events firing to make sure it's\n  // not too rapid (for performance reasons).\n  throttleTimeout: 50,\n  // Element to add the positionFixedClass to.\n  positionFixedSelector: null,\n  // Fixed position class to add to make sidebar fixed after scrolling\n  // down past the fixedSidebarOffset.\n  positionFixedClass: 'is-position-fixed',\n  // fixedSidebarOffset can be any number but by default is set\n  // to auto which sets the fixedSidebarOffset to the sidebar\n  // element's offsetTop from the top of the document on init.\n  fixedSidebarOffset: 'auto',\n  // includeHtml can be set to true to include the HTML markup from the\n  // heading node instead of just including the textContent.\n  includeHtml: false\n}\n//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiMy5qcyIsInNvdXJjZXMiOlsid2VicGFjazovLy8uL3NyYy9qcy9kZWZhdWx0LW9wdGlvbnMuanM/MTg1MSJdLCJzb3VyY2VzQ29udGVudCI6WyJtb2R1bGUuZXhwb3J0cyA9IHtcbiAgLy8gV2hlcmUgdG8gcmVuZGVyIHRoZSB0YWJsZSBvZiBjb250ZW50cy5cbiAgdG9jU2VsZWN0b3I6ICcuanMtdG9jJyxcbiAgLy8gV2hlcmUgdG8gZ3JhYiB0aGUgaGVhZGluZ3MgdG8gYnVpbGQgdGhlIHRhYmxlIG9mIGNvbnRlbnRzLlxuICBjb250ZW50U2VsZWN0b3I6ICcuanMtdG9jLWNvbnRlbnQnLFxuICAvLyBXaGljaCBoZWFkaW5ncyB0byBncmFiIGluc2lkZSBvZiB0aGUgY29udGVudFNlbGVjdG9yIGVsZW1lbnQuXG4gIGhlYWRpbmdTZWxlY3RvcjogJ2gxLCBoMiwgaDMnLFxuICAvLyBIZWFkaW5ncyB0aGF0IG1hdGNoIHRoZSBpZ25vcmVTZWxlY3RvciB3aWxsIGJlIHNraXBwZWQuXG4gIGlnbm9yZVNlbGVjdG9yOiAnLmpzLXRvYy1pZ25vcmUnLFxuICAvLyBNYWluIGNsYXNzIHRvIGFkZCB0byBsaW5rcy5cbiAgbGlua0NsYXNzOiAndG9jLWxpbmsnLFxuICAvLyBFeHRyYSBjbGFzc2VzIHRvIGFkZCB0byBsaW5rcy5cbiAgZXh0cmFMaW5rQ2xhc3NlczogJycsXG4gIC8vIENsYXNzIHRvIGFkZCB0byBhY3RpdmUgbGlua3MsXG4gIC8vIHRoZSBsaW5rIGNvcnJlc3BvbmRpbmcgdG8gdGhlIHRvcCBtb3N0IGhlYWRpbmcgb24gdGhlIHBhZ2UuXG4gIGFjdGl2ZUxpbmtDbGFzczogJ2lzLWFjdGl2ZS1saW5rJyxcbiAgLy8gTWFpbiBjbGFzcyB0byBhZGQgdG8gbGlzdHMuXG4gIGxpc3RDbGFzczogJ3RvYy1saXN0JyxcbiAgLy8gRXh0cmEgY2xhc3NlcyB0byBhZGQgdG8gbGlzdHMuXG4gIGV4dHJhTGlzdENsYXNzZXM6ICcnLFxuICAvLyBDbGFzcyB0aGF0IGdldHMgYWRkZWQgd2hlbiBhIGxpc3Qgc2hvdWxkIGJlIGNvbGxhcHNlZC5cbiAgaXNDb2xsYXBzZWRDbGFzczogJ2lzLWNvbGxhcHNlZCcsXG4gIC8vIENsYXNzIHRoYXQgZ2V0cyBhZGRlZCB3aGVuIGEgbGlzdCBzaG91bGQgYmUgYWJsZVxuICAvLyB0byBiZSBjb2xsYXBzZWQgYnV0IGlzbid0IG5lY2Vzc2FyaWx5IGNvbGxwYXNlZC5cbiAgY29sbGFwc2libGVDbGFzczogJ2lzLWNvbGxhcHNpYmxlJyxcbiAgLy8gQ2xhc3MgdG8gYWRkIHRvIGxpc3QgaXRlbXMuXG4gIGxpc3RJdGVtQ2xhc3M6ICd0b2MtbGlzdC1pdGVtJyxcbiAgLy8gSG93IG1hbnkgaGVhZGluZyBsZXZlbHMgc2hvdWxkIG5vdCBiZSBjb2xscGFzZWQuXG4gIC8vIEZvciBleGFtcGxlLCBudW1iZXIgNiB3aWxsIHNob3cgZXZlcnl0aGluZyBzaW5jZVxuICAvLyB0aGVyZSBhcmUgb25seSA2IGhlYWRpbmcgbGV2ZWxzIGFuZCBudW1iZXIgMCB3aWxsIGNvbGxwYXNlIHRoZW0gYWxsLlxuICAvLyBUaGUgc2VjdGlvbnMgdGhhdCBhcmUgaGlkZGVuIHdpbGwgb3BlblxuICAvLyBhbmQgY2xvc2UgYXMgeW91IHNjcm9sbCB0byBoZWFkaW5ncyB3aXRoaW4gdGhlbS5cbiAgY29sbGFwc2VEZXB0aDogMCxcbiAgLy8gU21vb3RoIHNjcm9sbGluZyBlbmFibGVkLlxuICBzbW9vdGhTY3JvbGw6IHRydWUsXG4gIC8vIFNtb290aCBzY3JvbGwgZHVyYXRpb24uXG4gIHNtb290aFNjcm9sbER1cmF0aW9uOiA0MjAsXG4gIC8vIENhbGxiYWNrIGZvciBzY3JvbGwgZW5kIChyZXF1aXJlczogc21vb3RoU2Nyb2xsKS5cbiAgc2Nyb2xsRW5kQ2FsbGJhY2s6IGZ1bmN0aW9uIChlKSB7fSxcbiAgLy8gSGVhZGluZ3Mgb2Zmc2V0IGJldHdlZW4gdGhlIGhlYWRpbmdzIGFuZCB0aGUgdG9wIG9mIHRoZSBkb2N1bWVudC5cbiAgaGVhZGluZ3NPZmZzZXQ6IDAsXG4gIC8vIFRpbWVvdXQgYmV0d2VlbiBldmVudHMgZmlyaW5nIHRvIG1ha2Ugc3VyZSBpdCdzXG4gIC8vIG5vdCB0b28gcmFwaWQgKGZvciBwZXJmb3JtYW5jZSByZWFzb25zKS5cbiAgdGhyb3R0bGVUaW1lb3V0OiA1MCxcbiAgLy8gRWxlbWVudCB0byBhZGQgdGhlIHBvc2l0aW9uRml4ZWRDbGFzcyB0by5cbiAgcG9zaXRpb25GaXhlZFNlbGVjdG9yOiBudWxsLFxuICAvLyBGaXhlZCBwb3NpdGlvbiBjbGFzcyB0byBhZGQgdG8gbWFrZSBzaWRlYmFyIGZpeGVkIGFmdGVyIHNjcm9sbGluZ1xuICAvLyBkb3duIHBhc3QgdGhlIGZpeGVkU2lkZWJhck9mZnNldC5cbiAgcG9zaXRpb25GaXhlZENsYXNzOiAnaXMtcG9zaXRpb24tZml4ZWQnLFxuICAvLyBmaXhlZFNpZGViYXJPZmZzZXQgY2FuIGJlIGFueSBudW1iZXIgYnV0IGJ5IGRlZmF1bHQgaXMgc2V0XG4gIC8vIHRvIGF1dG8gd2hpY2ggc2V0cyB0aGUgZml4ZWRTaWRlYmFyT2Zmc2V0IHRvIHRoZSBzaWRlYmFyXG4gIC8vIGVsZW1lbnQncyBvZmZzZXRUb3AgZnJvbSB0aGUgdG9wIG9mIHRoZSBkb2N1bWVudCBvbiBpbml0LlxuICBmaXhlZFNpZGViYXJPZmZzZXQ6ICdhdXRvJyxcbiAgLy8gaW5jbHVkZUh0bWwgY2FuIGJlIHNldCB0byB0cnVlIHRvIGluY2x1ZGUgdGhlIEhUTUwgbWFya3VwIGZyb20gdGhlXG4gIC8vIGhlYWRpbmcgbm9kZSBpbnN0ZWFkIG9mIGp1c3QgaW5jbHVkaW5nIHRoZSB0ZXh0Q29udGVudC5cbiAgaW5jbHVkZUh0bWw6IGZhbHNlXG59XG5cblxuXG4vLy8vLy8vLy8vLy8vLy8vLy9cbi8vIFdFQlBBQ0sgRk9PVEVSXG4vLyAuL3NyYy9qcy9kZWZhdWx0LW9wdGlvbnMuanNcbi8vIG1vZHVsZSBpZCA9IDNcbi8vIG1vZHVsZSBjaHVua3MgPSAwIl0sIm1hcHBpbmdzIjoiQUFBQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7Iiwic291cmNlUm9vdCI6IiJ9");
-
-/***/ }),
-/* 4 */
-/* unknown exports provided */
-/* all exports used */
-/*!*********************************!*\
-  !*** ./src/js/parse-content.js ***!
-  \*********************************/
-/***/ (function(module, exports) {
-
-eval("/**\n * This file is responsible for parsing the content from the DOM and making\n * sure data is nested properly.\n *\n * @author Tim Scanlin\n */\n\nmodule.exports = function parseContent (options) {\n  var reduce = [].reduce\n\n  /**\n   * Get the last item in an array and return a reference to it.\n   * @param {Array} array\n   * @return {Object}\n   */\n  function getLastItem (array) {\n    return array[array.length - 1]\n  }\n\n  /**\n   * Get heading level for a heading dom node.\n   * @param {HTMLElement} heading\n   * @return {Number}\n   */\n  function getHeadingLevel (heading) {\n    return +heading.nodeName.split('H').join('')\n  }\n\n  /**\n   * Get important properties from a heading element and store in a plain object.\n   * @param {HTMLElement} heading\n   * @return {Object}\n   */\n  function getHeadingObject (heading) {\n    var obj = {\n      id: heading.id,\n      children: [],\n      nodeName: heading.nodeName,\n      headingLevel: getHeadingLevel(heading),\n      textContent: heading.textContent.trim()\n    }\n\n    if (options.includeHtml) {\n      obj.childNodes = heading.childNodes\n    }\n\n    return obj\n  }\n\n  /**\n   * Add a node to the nested array.\n   * @param {Object} node\n   * @param {Array} nest\n   * @return {Array}\n   */\n  function addNode (node, nest) {\n    var obj = getHeadingObject(node)\n    var level = getHeadingLevel(node)\n    var array = nest\n    var lastItem = getLastItem(array)\n    var lastItemLevel = lastItem\n      ? lastItem.headingLevel\n      : 0\n    var counter = level - lastItemLevel\n\n    while (counter > 0) {\n      lastItem = getLastItem(array)\n      if (lastItem && lastItem.children !== undefined) {\n        array = lastItem.children\n      }\n      counter--\n    }\n\n    if (level >= options.collapseDepth) {\n      obj.isCollapsed = true\n    }\n\n    array.push(obj)\n    return array\n  }\n\n  /**\n   * Select headings in content area, exclude any selector in options.ignoreSelector\n   * @param {String} contentSelector\n   * @param {Array} headingSelector\n   * @return {Array}\n   */\n  function selectHeadings (contentSelector, headingSelector) {\n    var selectors = headingSelector\n    if (options.ignoreSelector) {\n      selectors = headingSelector.split(',')\n        .map(function mapSelectors (selector) {\n          return selector.trim() + ':not(' + options.ignoreSelector + ')'\n        })\n    }\n    try {\n      return document.querySelector(contentSelector)\n        .querySelectorAll(selectors)\n    } catch (e) {\n      console.warn('Element not found: ' + contentSelector); // eslint-disable-line\n      return null\n    }\n  }\n\n  /**\n   * Nest headings array into nested arrays with 'children' property.\n   * @param {Array} headingsArray\n   * @return {Object}\n   */\n  function nestHeadingsArray (headingsArray) {\n    return reduce.call(headingsArray, function reducer (prev, curr) {\n      var currentHeading = getHeadingObject(curr)\n\n      addNode(currentHeading, prev.nest)\n      return prev\n    }, {\n      nest: []\n    })\n  }\n\n  return {\n    nestHeadingsArray: nestHeadingsArray,\n    selectHeadings: selectHeadings\n  }\n}\n//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiNC5qcyIsInNvdXJjZXMiOlsid2VicGFjazovLy8uL3NyYy9qcy9wYXJzZS1jb250ZW50LmpzPzg3ZjAiXSwic291cmNlc0NvbnRlbnQiOlsiLyoqXG4gKiBUaGlzIGZpbGUgaXMgcmVzcG9uc2libGUgZm9yIHBhcnNpbmcgdGhlIGNvbnRlbnQgZnJvbSB0aGUgRE9NIGFuZCBtYWtpbmdcbiAqIHN1cmUgZGF0YSBpcyBuZXN0ZWQgcHJvcGVybHkuXG4gKlxuICogQGF1dGhvciBUaW0gU2NhbmxpblxuICovXG5cbm1vZHVsZS5leHBvcnRzID0gZnVuY3Rpb24gcGFyc2VDb250ZW50IChvcHRpb25zKSB7XG4gIHZhciByZWR1Y2UgPSBbXS5yZWR1Y2VcblxuICAvKipcbiAgICogR2V0IHRoZSBsYXN0IGl0ZW0gaW4gYW4gYXJyYXkgYW5kIHJldHVybiBhIHJlZmVyZW5jZSB0byBpdC5cbiAgICogQHBhcmFtIHtBcnJheX0gYXJyYXlcbiAgICogQHJldHVybiB7T2JqZWN0fVxuICAgKi9cbiAgZnVuY3Rpb24gZ2V0TGFzdEl0ZW0gKGFycmF5KSB7XG4gICAgcmV0dXJuIGFycmF5W2FycmF5Lmxlbmd0aCAtIDFdXG4gIH1cblxuICAvKipcbiAgICogR2V0IGhlYWRpbmcgbGV2ZWwgZm9yIGEgaGVhZGluZyBkb20gbm9kZS5cbiAgICogQHBhcmFtIHtIVE1MRWxlbWVudH0gaGVhZGluZ1xuICAgKiBAcmV0dXJuIHtOdW1iZXJ9XG4gICAqL1xuICBmdW5jdGlvbiBnZXRIZWFkaW5nTGV2ZWwgKGhlYWRpbmcpIHtcbiAgICByZXR1cm4gK2hlYWRpbmcubm9kZU5hbWUuc3BsaXQoJ0gnKS5qb2luKCcnKVxuICB9XG5cbiAgLyoqXG4gICAqIEdldCBpbXBvcnRhbnQgcHJvcGVydGllcyBmcm9tIGEgaGVhZGluZyBlbGVtZW50IGFuZCBzdG9yZSBpbiBhIHBsYWluIG9iamVjdC5cbiAgICogQHBhcmFtIHtIVE1MRWxlbWVudH0gaGVhZGluZ1xuICAgKiBAcmV0dXJuIHtPYmplY3R9XG4gICAqL1xuICBmdW5jdGlvbiBnZXRIZWFkaW5nT2JqZWN0IChoZWFkaW5nKSB7XG4gICAgdmFyIG9iaiA9IHtcbiAgICAgIGlkOiBoZWFkaW5nLmlkLFxuICAgICAgY2hpbGRyZW46IFtdLFxuICAgICAgbm9kZU5hbWU6IGhlYWRpbmcubm9kZU5hbWUsXG4gICAgICBoZWFkaW5nTGV2ZWw6IGdldEhlYWRpbmdMZXZlbChoZWFkaW5nKSxcbiAgICAgIHRleHRDb250ZW50OiBoZWFkaW5nLnRleHRDb250ZW50LnRyaW0oKVxuICAgIH1cblxuICAgIGlmIChvcHRpb25zLmluY2x1ZGVIdG1sKSB7XG4gICAgICBvYmouY2hpbGROb2RlcyA9IGhlYWRpbmcuY2hpbGROb2Rlc1xuICAgIH1cblxuICAgIHJldHVybiBvYmpcbiAgfVxuXG4gIC8qKlxuICAgKiBBZGQgYSBub2RlIHRvIHRoZSBuZXN0ZWQgYXJyYXkuXG4gICAqIEBwYXJhbSB7T2JqZWN0fSBub2RlXG4gICAqIEBwYXJhbSB7QXJyYXl9IG5lc3RcbiAgICogQHJldHVybiB7QXJyYXl9XG4gICAqL1xuICBmdW5jdGlvbiBhZGROb2RlIChub2RlLCBuZXN0KSB7XG4gICAgdmFyIG9iaiA9IGdldEhlYWRpbmdPYmplY3Qobm9kZSlcbiAgICB2YXIgbGV2ZWwgPSBnZXRIZWFkaW5nTGV2ZWwobm9kZSlcbiAgICB2YXIgYXJyYXkgPSBuZXN0XG4gICAgdmFyIGxhc3RJdGVtID0gZ2V0TGFzdEl0ZW0oYXJyYXkpXG4gICAgdmFyIGxhc3RJdGVtTGV2ZWwgPSBsYXN0SXRlbVxuICAgICAgPyBsYXN0SXRlbS5oZWFkaW5nTGV2ZWxcbiAgICAgIDogMFxuICAgIHZhciBjb3VudGVyID0gbGV2ZWwgLSBsYXN0SXRlbUxldmVsXG5cbiAgICB3aGlsZSAoY291bnRlciA+IDApIHtcbiAgICAgIGxhc3RJdGVtID0gZ2V0TGFzdEl0ZW0oYXJyYXkpXG4gICAgICBpZiAobGFzdEl0ZW0gJiYgbGFzdEl0ZW0uY2hpbGRyZW4gIT09IHVuZGVmaW5lZCkge1xuICAgICAgICBhcnJheSA9IGxhc3RJdGVtLmNoaWxkcmVuXG4gICAgICB9XG4gICAgICBjb3VudGVyLS1cbiAgICB9XG5cbiAgICBpZiAobGV2ZWwgPj0gb3B0aW9ucy5jb2xsYXBzZURlcHRoKSB7XG4gICAgICBvYmouaXNDb2xsYXBzZWQgPSB0cnVlXG4gICAgfVxuXG4gICAgYXJyYXkucHVzaChvYmopXG4gICAgcmV0dXJuIGFycmF5XG4gIH1cblxuICAvKipcbiAgICogU2VsZWN0IGhlYWRpbmdzIGluIGNvbnRlbnQgYXJlYSwgZXhjbHVkZSBhbnkgc2VsZWN0b3IgaW4gb3B0aW9ucy5pZ25vcmVTZWxlY3RvclxuICAgKiBAcGFyYW0ge1N0cmluZ30gY29udGVudFNlbGVjdG9yXG4gICAqIEBwYXJhbSB7QXJyYXl9IGhlYWRpbmdTZWxlY3RvclxuICAgKiBAcmV0dXJuIHtBcnJheX1cbiAgICovXG4gIGZ1bmN0aW9uIHNlbGVjdEhlYWRpbmdzIChjb250ZW50U2VsZWN0b3IsIGhlYWRpbmdTZWxlY3Rvcikge1xuICAgIHZhciBzZWxlY3RvcnMgPSBoZWFkaW5nU2VsZWN0b3JcbiAgICBpZiAob3B0aW9ucy5pZ25vcmVTZWxlY3Rvcikge1xuICAgICAgc2VsZWN0b3JzID0gaGVhZGluZ1NlbGVjdG9yLnNwbGl0KCcsJylcbiAgICAgICAgLm1hcChmdW5jdGlvbiBtYXBTZWxlY3RvcnMgKHNlbGVjdG9yKSB7XG4gICAgICAgICAgcmV0dXJuIHNlbGVjdG9yLnRyaW0oKSArICc6bm90KCcgKyBvcHRpb25zLmlnbm9yZVNlbGVjdG9yICsgJyknXG4gICAgICAgIH0pXG4gICAgfVxuICAgIHRyeSB7XG4gICAgICByZXR1cm4gZG9jdW1lbnQucXVlcnlTZWxlY3Rvcihjb250ZW50U2VsZWN0b3IpXG4gICAgICAgIC5xdWVyeVNlbGVjdG9yQWxsKHNlbGVjdG9ycylcbiAgICB9IGNhdGNoIChlKSB7XG4gICAgICBjb25zb2xlLndhcm4oJ0VsZW1lbnQgbm90IGZvdW5kOiAnICsgY29udGVudFNlbGVjdG9yKTsgLy8gZXNsaW50LWRpc2FibGUtbGluZVxuICAgICAgcmV0dXJuIG51bGxcbiAgICB9XG4gIH1cblxuICAvKipcbiAgICogTmVzdCBoZWFkaW5ncyBhcnJheSBpbnRvIG5lc3RlZCBhcnJheXMgd2l0aCAnY2hpbGRyZW4nIHByb3BlcnR5LlxuICAgKiBAcGFyYW0ge0FycmF5fSBoZWFkaW5nc0FycmF5XG4gICAqIEByZXR1cm4ge09iamVjdH1cbiAgICovXG4gIGZ1bmN0aW9uIG5lc3RIZWFkaW5nc0FycmF5IChoZWFkaW5nc0FycmF5KSB7XG4gICAgcmV0dXJuIHJlZHVjZS5jYWxsKGhlYWRpbmdzQXJyYXksIGZ1bmN0aW9uIHJlZHVjZXIgKHByZXYsIGN1cnIpIHtcbiAgICAgIHZhciBjdXJyZW50SGVhZGluZyA9IGdldEhlYWRpbmdPYmplY3QoY3VycilcblxuICAgICAgYWRkTm9kZShjdXJyZW50SGVhZGluZywgcHJldi5uZXN0KVxuICAgICAgcmV0dXJuIHByZXZcbiAgICB9LCB7XG4gICAgICBuZXN0OiBbXVxuICAgIH0pXG4gIH1cblxuICByZXR1cm4ge1xuICAgIG5lc3RIZWFkaW5nc0FycmF5OiBuZXN0SGVhZGluZ3NBcnJheSxcbiAgICBzZWxlY3RIZWFkaW5nczogc2VsZWN0SGVhZGluZ3NcbiAgfVxufVxuXG5cblxuLy8vLy8vLy8vLy8vLy8vLy8vXG4vLyBXRUJQQUNLIEZPT1RFUlxuLy8gLi9zcmMvanMvcGFyc2UtY29udGVudC5qc1xuLy8gbW9kdWxlIGlkID0gNFxuLy8gbW9kdWxlIGNodW5rcyA9IDAiXSwibWFwcGluZ3MiOiJBQUFBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7Iiwic291cmNlUm9vdCI6IiJ9");
-
-/***/ }),
-/* 5 */
-/* unknown exports provided */
-/* all exports used */
-/*!*************************!*\
-  !*** ./src/js/index.js ***!
-  \*************************/
-/***/ (function(module, exports, __webpack_require__) {
-
-eval("/* WEBPACK VAR INJECTION */(function(global) {var __WEBPACK_AMD_DEFINE_FACTORY__, __WEBPACK_AMD_DEFINE_ARRAY__, __WEBPACK_AMD_DEFINE_RESULT__;/**\n * Tocbot\n * Tocbot creates a toble of contents based on HTML headings on a page,\n * this allows users to easily jump to different sections of the document.\n * Tocbot was inspired by tocify (https://gregfranko.com/jquery.tocify.js/).\n * The main differences are that it works natively without any need for jquery or jquery UI).\n *\n * @author Tim Scanlin\n */\n\n/* globals define */\n\n(function (root, factory) {\n  if (true) {\n    !(__WEBPACK_AMD_DEFINE_ARRAY__ = [], __WEBPACK_AMD_DEFINE_FACTORY__ = (factory(root)),\n\t\t\t\t__WEBPACK_AMD_DEFINE_RESULT__ = (typeof __WEBPACK_AMD_DEFINE_FACTORY__ === 'function' ?\n\t\t\t\t(__WEBPACK_AMD_DEFINE_FACTORY__.apply(exports, __WEBPACK_AMD_DEFINE_ARRAY__)) : __WEBPACK_AMD_DEFINE_FACTORY__),\n\t\t\t\t__WEBPACK_AMD_DEFINE_RESULT__ !== undefined && (module.exports = __WEBPACK_AMD_DEFINE_RESULT__))\n  } else if (typeof exports === 'object') {\n    module.exports = factory(root)\n  } else {\n    root.tocbot = factory(root)\n  }\n})(typeof global !== 'undefined' ? global : this.window || this.global, function (root) {\n  'use strict'\n\n  // Default options.\n  var defaultOptions = __webpack_require__(/*! ./default-options.js */ 3)\n  // Object to store current options.\n  var options = {}\n  // Object for public APIs.\n  var tocbot = {}\n\n  var BuildHtml = __webpack_require__(/*! ./build-html.js */ 2)\n  var ParseContent = __webpack_require__(/*! ./parse-content.js */ 4)\n  // Keep these variables at top scope once options are passed in.\n  var buildHtml\n  var parseContent\n\n  // Just return if its not a browser.\n  if (typeof window === 'undefined') {\n    return\n  }\n  var supports = !!root.document.querySelector && !!root.addEventListener // Feature test\n  var headingsArray\n\n  // From: https://github.com/Raynos/xtend\n  var hasOwnProperty = Object.prototype.hasOwnProperty\n  function extend () {\n    var target = {}\n    for (var i = 0; i < arguments.length; i++) {\n      var source = arguments[i]\n      for (var key in source) {\n        if (hasOwnProperty.call(source, key)) {\n          target[key] = source[key]\n        }\n      }\n    }\n    return target\n  }\n\n  // From: https://remysharp.com/2010/07/21/throttling-function-calls\n  function throttle (fn, threshhold, scope) {\n    threshhold || (threshhold = 250)\n    var last\n    var deferTimer\n    return function () {\n      var context = scope || this\n      var now = +new Date()\n      var args = arguments\n      if (last && now < last + threshhold) {\n        // hold on to it\n        clearTimeout(deferTimer)\n        deferTimer = setTimeout(function () {\n          last = now\n          fn.apply(context, args)\n        }, threshhold)\n      } else {\n        last = now\n        fn.apply(context, args)\n      }\n    }\n  }\n\n  /**\n   * Destroy tocbot.\n   */\n  tocbot.destroy = function () {\n    // Clear HTML.\n    try {\n      document.querySelector(options.tocSelector).innerHTML = ''\n    } catch (e) {\n      console.warn('Element not found: ' + options.tocSelector); // eslint-disable-line\n    }\n\n    // Remove event listeners.\n    document.removeEventListener('scroll', this._scrollListener, false)\n    document.removeEventListener('resize', this._scrollListener, false)\n    if (buildHtml) {\n      document.removeEventListener('click', this._clickListener, false)\n    }\n  }\n\n  /**\n   * Initialize tocbot.\n   * @param {object} customOptions\n   */\n  tocbot.init = function (customOptions) {\n    // feature test\n    if (!supports) {\n      return\n    }\n\n    // Merge defaults with user options.\n    // Set to options variable at the top.\n    options = extend(defaultOptions, customOptions || {})\n    this.options = options\n    this.state = {}\n\n    // Init smooth scroll if enabled (default).\n    if (options.smoothScroll) {\n      tocbot.zenscroll = __webpack_require__(/*! zenscroll */ 1)\n      tocbot.zenscroll.setup(options.smoothScrollDuration)\n    }\n\n    // Pass options to these modules.\n    buildHtml = BuildHtml(options)\n    parseContent = ParseContent(options)\n\n    // For testing purposes.\n    this._buildHtml = buildHtml\n    this._parseContent = parseContent\n\n    // Destroy it if it exists first.\n    tocbot.destroy()\n\n    // Get headings array.\n    headingsArray = parseContent.selectHeadings(options.contentSelector, options.headingSelector)\n    // Return if no headings are found.\n    if (headingsArray === null) {\n      return\n    }\n\n    // Build nested headings array.\n    var nestedHeadingsObj = parseContent.nestHeadingsArray(headingsArray)\n    var nestedHeadings = nestedHeadingsObj.nest\n\n    // Render.\n    buildHtml.render(options.tocSelector, nestedHeadings)\n\n    // Update Sidebar and bind listeners.\n    this._scrollListener = throttle(function (e) {\n      buildHtml.updateToc(headingsArray)\n      var isTop = e && e.target && e.target.scrollingElement && e.target.scrollingElement.scrollTop === 0\n      if ((e && e.eventPhase === 0) || isTop) {\n        buildHtml.enableTocAnimation()\n        buildHtml.updateToc(headingsArray)\n        if (options.scrollEndCallback) {\n          options.scrollEndCallback(e)\n        }\n      }\n    }, options.throttleTimeout)\n    this._scrollListener()\n    document.addEventListener('scroll', this._scrollListener, false)\n    document.addEventListener('resize', this._scrollListener, false)\n\n    // Bind click listeners to disable animation.\n    this._clickListener = throttle(function (event) {\n      if (options.smoothScroll) {\n        buildHtml.disableTocAnimation(event)\n      }\n      buildHtml.updateToc(headingsArray)\n    }, options.throttleTimeout)\n    document.addEventListener('click', this._clickListener, false)\n\n    return this\n  }\n\n  /**\n   * Refresh tocbot.\n   */\n  tocbot.refresh = function (customOptions) {\n    tocbot.destroy()\n    tocbot.init(customOptions || this.options)\n  }\n\n  // Make tocbot available globally.\n  root.tocbot = tocbot\n\n  return tocbot\n})\n\n/* WEBPACK VAR INJECTION */}.call(exports, __webpack_require__(/*! ./../../~/webpack/buildin/global.js */ 0)))//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiNS5qcyIsInNvdXJjZXMiOlsid2VicGFjazovLy8uL3NyYy9qcy9pbmRleC5qcz9iYzY2Il0sInNvdXJjZXNDb250ZW50IjpbIi8qKlxuICogVG9jYm90XG4gKiBUb2Nib3QgY3JlYXRlcyBhIHRvYmxlIG9mIGNvbnRlbnRzIGJhc2VkIG9uIEhUTUwgaGVhZGluZ3Mgb24gYSBwYWdlLFxuICogdGhpcyBhbGxvd3MgdXNlcnMgdG8gZWFzaWx5IGp1bXAgdG8gZGlmZmVyZW50IHNlY3Rpb25zIG9mIHRoZSBkb2N1bWVudC5cbiAqIFRvY2JvdCB3YXMgaW5zcGlyZWQgYnkgdG9jaWZ5IChodHRwOi8vZ3JlZ2ZyYW5rby5jb20vanF1ZXJ5LnRvY2lmeS5qcy8pLlxuICogVGhlIG1haW4gZGlmZmVyZW5jZXMgYXJlIHRoYXQgaXQgd29ya3MgbmF0aXZlbHkgd2l0aG91dCBhbnkgbmVlZCBmb3IganF1ZXJ5IG9yIGpxdWVyeSBVSSkuXG4gKlxuICogQGF1dGhvciBUaW0gU2NhbmxpblxuICovXG5cbi8qIGdsb2JhbHMgZGVmaW5lICovXG5cbihmdW5jdGlvbiAocm9vdCwgZmFjdG9yeSkge1xuICBpZiAodHlwZW9mIGRlZmluZSA9PT0gJ2Z1bmN0aW9uJyAmJiBkZWZpbmUuYW1kKSB7XG4gICAgZGVmaW5lKFtdLCBmYWN0b3J5KHJvb3QpKVxuICB9IGVsc2UgaWYgKHR5cGVvZiBleHBvcnRzID09PSAnb2JqZWN0Jykge1xuICAgIG1vZHVsZS5leHBvcnRzID0gZmFjdG9yeShyb290KVxuICB9IGVsc2Uge1xuICAgIHJvb3QudG9jYm90ID0gZmFjdG9yeShyb290KVxuICB9XG59KSh0eXBlb2YgZ2xvYmFsICE9PSAndW5kZWZpbmVkJyA/IGdsb2JhbCA6IHRoaXMud2luZG93IHx8IHRoaXMuZ2xvYmFsLCBmdW5jdGlvbiAocm9vdCkge1xuICAndXNlIHN0cmljdCdcblxuICAvLyBEZWZhdWx0IG9wdGlvbnMuXG4gIHZhciBkZWZhdWx0T3B0aW9ucyA9IHJlcXVpcmUoJy4vZGVmYXVsdC1vcHRpb25zLmpzJylcbiAgLy8gT2JqZWN0IHRvIHN0b3JlIGN1cnJlbnQgb3B0aW9ucy5cbiAgdmFyIG9wdGlvbnMgPSB7fVxuICAvLyBPYmplY3QgZm9yIHB1YmxpYyBBUElzLlxuICB2YXIgdG9jYm90ID0ge31cblxuICB2YXIgQnVpbGRIdG1sID0gcmVxdWlyZSgnLi9idWlsZC1odG1sLmpzJylcbiAgdmFyIFBhcnNlQ29udGVudCA9IHJlcXVpcmUoJy4vcGFyc2UtY29udGVudC5qcycpXG4gIC8vIEtlZXAgdGhlc2UgdmFyaWFibGVzIGF0IHRvcCBzY29wZSBvbmNlIG9wdGlvbnMgYXJlIHBhc3NlZCBpbi5cbiAgdmFyIGJ1aWxkSHRtbFxuICB2YXIgcGFyc2VDb250ZW50XG5cbiAgLy8gSnVzdCByZXR1cm4gaWYgaXRzIG5vdCBhIGJyb3dzZXIuXG4gIGlmICh0eXBlb2Ygd2luZG93ID09PSAndW5kZWZpbmVkJykge1xuICAgIHJldHVyblxuICB9XG4gIHZhciBzdXBwb3J0cyA9ICEhcm9vdC5kb2N1bWVudC5xdWVyeVNlbGVjdG9yICYmICEhcm9vdC5hZGRFdmVudExpc3RlbmVyIC8vIEZlYXR1cmUgdGVzdFxuICB2YXIgaGVhZGluZ3NBcnJheVxuXG4gIC8vIEZyb206IGh0dHBzOi8vZ2l0aHViLmNvbS9SYXlub3MveHRlbmRcbiAgdmFyIGhhc093blByb3BlcnR5ID0gT2JqZWN0LnByb3RvdHlwZS5oYXNPd25Qcm9wZXJ0eVxuICBmdW5jdGlvbiBleHRlbmQgKCkge1xuICAgIHZhciB0YXJnZXQgPSB7fVxuICAgIGZvciAodmFyIGkgPSAwOyBpIDwgYXJndW1lbnRzLmxlbmd0aDsgaSsrKSB7XG4gICAgICB2YXIgc291cmNlID0gYXJndW1lbnRzW2ldXG4gICAgICBmb3IgKHZhciBrZXkgaW4gc291cmNlKSB7XG4gICAgICAgIGlmIChoYXNPd25Qcm9wZXJ0eS5jYWxsKHNvdXJjZSwga2V5KSkge1xuICAgICAgICAgIHRhcmdldFtrZXldID0gc291cmNlW2tleV1cbiAgICAgICAgfVxuICAgICAgfVxuICAgIH1cbiAgICByZXR1cm4gdGFyZ2V0XG4gIH1cblxuICAvLyBGcm9tOiBodHRwczovL3JlbXlzaGFycC5jb20vMjAxMC8wNy8yMS90aHJvdHRsaW5nLWZ1bmN0aW9uLWNhbGxzXG4gIGZ1bmN0aW9uIHRocm90dGxlIChmbiwgdGhyZXNoaG9sZCwgc2NvcGUpIHtcbiAgICB0aHJlc2hob2xkIHx8ICh0aHJlc2hob2xkID0gMjUwKVxuICAgIHZhciBsYXN0XG4gICAgdmFyIGRlZmVyVGltZXJcbiAgICByZXR1cm4gZnVuY3Rpb24gKCkge1xuICAgICAgdmFyIGNvbnRleHQgPSBzY29wZSB8fCB0aGlzXG4gICAgICB2YXIgbm93ID0gK25ldyBEYXRlKClcbiAgICAgIHZhciBhcmdzID0gYXJndW1lbnRzXG4gICAgICBpZiAobGFzdCAmJiBub3cgPCBsYXN0ICsgdGhyZXNoaG9sZCkge1xuICAgICAgICAvLyBob2xkIG9uIHRvIGl0XG4gICAgICAgIGNsZWFyVGltZW91dChkZWZlclRpbWVyKVxuICAgICAgICBkZWZlclRpbWVyID0gc2V0VGltZW91dChmdW5jdGlvbiAoKSB7XG4gICAgICAgICAgbGFzdCA9IG5vd1xuICAgICAgICAgIGZuLmFwcGx5KGNvbnRleHQsIGFyZ3MpXG4gICAgICAgIH0sIHRocmVzaGhvbGQpXG4gICAgICB9IGVsc2Uge1xuICAgICAgICBsYXN0ID0gbm93XG4gICAgICAgIGZuLmFwcGx5KGNvbnRleHQsIGFyZ3MpXG4gICAgICB9XG4gICAgfVxuICB9XG5cbiAgLyoqXG4gICAqIERlc3Ryb3kgdG9jYm90LlxuICAgKi9cbiAgdG9jYm90LmRlc3Ryb3kgPSBmdW5jdGlvbiAoKSB7XG4gICAgLy8gQ2xlYXIgSFRNTC5cbiAgICB0cnkge1xuICAgICAgZG9jdW1lbnQucXVlcnlTZWxlY3RvcihvcHRpb25zLnRvY1NlbGVjdG9yKS5pbm5lckhUTUwgPSAnJ1xuICAgIH0gY2F0Y2ggKGUpIHtcbiAgICAgIGNvbnNvbGUud2FybignRWxlbWVudCBub3QgZm91bmQ6ICcgKyBvcHRpb25zLnRvY1NlbGVjdG9yKTsgLy8gZXNsaW50LWRpc2FibGUtbGluZVxuICAgIH1cblxuICAgIC8vIFJlbW92ZSBldmVudCBsaXN0ZW5lcnMuXG4gICAgZG9jdW1lbnQucmVtb3ZlRXZlbnRMaXN0ZW5lcignc2Nyb2xsJywgdGhpcy5fc2Nyb2xsTGlzdGVuZXIsIGZhbHNlKVxuICAgIGRvY3VtZW50LnJlbW92ZUV2ZW50TGlzdGVuZXIoJ3Jlc2l6ZScsIHRoaXMuX3Njcm9sbExpc3RlbmVyLCBmYWxzZSlcbiAgICBpZiAoYnVpbGRIdG1sKSB7XG4gICAgICBkb2N1bWVudC5yZW1vdmVFdmVudExpc3RlbmVyKCdjbGljaycsIHRoaXMuX2NsaWNrTGlzdGVuZXIsIGZhbHNlKVxuICAgIH1cbiAgfVxuXG4gIC8qKlxuICAgKiBJbml0aWFsaXplIHRvY2JvdC5cbiAgICogQHBhcmFtIHtvYmplY3R9IGN1c3RvbU9wdGlvbnNcbiAgICovXG4gIHRvY2JvdC5pbml0ID0gZnVuY3Rpb24gKGN1c3RvbU9wdGlvbnMpIHtcbiAgICAvLyBmZWF0dXJlIHRlc3RcbiAgICBpZiAoIXN1cHBvcnRzKSB7XG4gICAgICByZXR1cm5cbiAgICB9XG5cbiAgICAvLyBNZXJnZSBkZWZhdWx0cyB3aXRoIHVzZXIgb3B0aW9ucy5cbiAgICAvLyBTZXQgdG8gb3B0aW9ucyB2YXJpYWJsZSBhdCB0aGUgdG9wLlxuICAgIG9wdGlvbnMgPSBleHRlbmQoZGVmYXVsdE9wdGlvbnMsIGN1c3RvbU9wdGlvbnMgfHwge30pXG4gICAgdGhpcy5vcHRpb25zID0gb3B0aW9uc1xuICAgIHRoaXMuc3RhdGUgPSB7fVxuXG4gICAgLy8gSW5pdCBzbW9vdGggc2Nyb2xsIGlmIGVuYWJsZWQgKGRlZmF1bHQpLlxuICAgIGlmIChvcHRpb25zLnNtb290aFNjcm9sbCkge1xuICAgICAgdG9jYm90LnplbnNjcm9sbCA9IHJlcXVpcmUoJ3plbnNjcm9sbCcpXG4gICAgICB0b2Nib3QuemVuc2Nyb2xsLnNldHVwKG9wdGlvbnMuc21vb3RoU2Nyb2xsRHVyYXRpb24pXG4gICAgfVxuXG4gICAgLy8gUGFzcyBvcHRpb25zIHRvIHRoZXNlIG1vZHVsZXMuXG4gICAgYnVpbGRIdG1sID0gQnVpbGRIdG1sKG9wdGlvbnMpXG4gICAgcGFyc2VDb250ZW50ID0gUGFyc2VDb250ZW50KG9wdGlvbnMpXG5cbiAgICAvLyBGb3IgdGVzdGluZyBwdXJwb3Nlcy5cbiAgICB0aGlzLl9idWlsZEh0bWwgPSBidWlsZEh0bWxcbiAgICB0aGlzLl9wYXJzZUNvbnRlbnQgPSBwYXJzZUNvbnRlbnRcblxuICAgIC8vIERlc3Ryb3kgaXQgaWYgaXQgZXhpc3RzIGZpcnN0LlxuICAgIHRvY2JvdC5kZXN0cm95KClcblxuICAgIC8vIEdldCBoZWFkaW5ncyBhcnJheS5cbiAgICBoZWFkaW5nc0FycmF5ID0gcGFyc2VDb250ZW50LnNlbGVjdEhlYWRpbmdzKG9wdGlvbnMuY29udGVudFNlbGVjdG9yLCBvcHRpb25zLmhlYWRpbmdTZWxlY3RvcilcbiAgICAvLyBSZXR1cm4gaWYgbm8gaGVhZGluZ3MgYXJlIGZvdW5kLlxuICAgIGlmIChoZWFkaW5nc0FycmF5ID09PSBudWxsKSB7XG4gICAgICByZXR1cm5cbiAgICB9XG5cbiAgICAvLyBCdWlsZCBuZXN0ZWQgaGVhZGluZ3MgYXJyYXkuXG4gICAgdmFyIG5lc3RlZEhlYWRpbmdzT2JqID0gcGFyc2VDb250ZW50Lm5lc3RIZWFkaW5nc0FycmF5KGhlYWRpbmdzQXJyYXkpXG4gICAgdmFyIG5lc3RlZEhlYWRpbmdzID0gbmVzdGVkSGVhZGluZ3NPYmoubmVzdFxuXG4gICAgLy8gUmVuZGVyLlxuICAgIGJ1aWxkSHRtbC5yZW5kZXIob3B0aW9ucy50b2NTZWxlY3RvciwgbmVzdGVkSGVhZGluZ3MpXG5cbiAgICAvLyBVcGRhdGUgU2lkZWJhciBhbmQgYmluZCBsaXN0ZW5lcnMuXG4gICAgdGhpcy5fc2Nyb2xsTGlzdGVuZXIgPSB0aHJvdHRsZShmdW5jdGlvbiAoZSkge1xuICAgICAgYnVpbGRIdG1sLnVwZGF0ZVRvYyhoZWFkaW5nc0FycmF5KVxuICAgICAgdmFyIGlzVG9wID0gZSAmJiBlLnRhcmdldCAmJiBlLnRhcmdldC5zY3JvbGxpbmdFbGVtZW50ICYmIGUudGFyZ2V0LnNjcm9sbGluZ0VsZW1lbnQuc2Nyb2xsVG9wID09PSAwXG4gICAgICBpZiAoKGUgJiYgZS5ldmVudFBoYXNlID09PSAwKSB8fCBpc1RvcCkge1xuICAgICAgICBidWlsZEh0bWwuZW5hYmxlVG9jQW5pbWF0aW9uKClcbiAgICAgICAgYnVpbGRIdG1sLnVwZGF0ZVRvYyhoZWFkaW5nc0FycmF5KVxuICAgICAgICBpZiAob3B0aW9ucy5zY3JvbGxFbmRDYWxsYmFjaykge1xuICAgICAgICAgIG9wdGlvbnMuc2Nyb2xsRW5kQ2FsbGJhY2soZSlcbiAgICAgICAgfVxuICAgICAgfVxuICAgIH0sIG9wdGlvbnMudGhyb3R0bGVUaW1lb3V0KVxuICAgIHRoaXMuX3Njcm9sbExpc3RlbmVyKClcbiAgICBkb2N1bWVudC5hZGRFdmVudExpc3RlbmVyKCdzY3JvbGwnLCB0aGlzLl9zY3JvbGxMaXN0ZW5lciwgZmFsc2UpXG4gICAgZG9jdW1lbnQuYWRkRXZlbnRMaXN0ZW5lcigncmVzaXplJywgdGhpcy5fc2Nyb2xsTGlzdGVuZXIsIGZhbHNlKVxuXG4gICAgLy8gQmluZCBjbGljayBsaXN0ZW5lcnMgdG8gZGlzYWJsZSBhbmltYXRpb24uXG4gICAgdGhpcy5fY2xpY2tMaXN0ZW5lciA9IHRocm90dGxlKGZ1bmN0aW9uIChldmVudCkge1xuICAgICAgaWYgKG9wdGlvbnMuc21vb3RoU2Nyb2xsKSB7XG4gICAgICAgIGJ1aWxkSHRtbC5kaXNhYmxlVG9jQW5pbWF0aW9uKGV2ZW50KVxuICAgICAgfVxuICAgICAgYnVpbGRIdG1sLnVwZGF0ZVRvYyhoZWFkaW5nc0FycmF5KVxuICAgIH0sIG9wdGlvbnMudGhyb3R0bGVUaW1lb3V0KVxuICAgIGRvY3VtZW50LmFkZEV2ZW50TGlzdGVuZXIoJ2NsaWNrJywgdGhpcy5fY2xpY2tMaXN0ZW5lciwgZmFsc2UpXG5cbiAgICByZXR1cm4gdGhpc1xuICB9XG5cbiAgLyoqXG4gICAqIFJlZnJlc2ggdG9jYm90LlxuICAgKi9cbiAgdG9jYm90LnJlZnJlc2ggPSBmdW5jdGlvbiAoY3VzdG9tT3B0aW9ucykge1xuICAgIHRvY2JvdC5kZXN0cm95KClcbiAgICB0b2Nib3QuaW5pdChjdXN0b21PcHRpb25zIHx8IHRoaXMub3B0aW9ucylcbiAgfVxuXG4gIC8vIE1ha2UgdG9jYm90IGF2YWlsYWJsZSBnbG9iYWxseS5cbiAgcm9vdC50b2Nib3QgPSB0b2Nib3RcblxuICByZXR1cm4gdG9jYm90XG59KVxuXG5cblxuLy8vLy8vLy8vLy8vLy8vLy8vXG4vLyBXRUJQQUNLIEZPT1RFUlxuLy8gLi9zcmMvanMvaW5kZXguanNcbi8vIG1vZHVsZSBpZCA9IDVcbi8vIG1vZHVsZSBjaHVua3MgPSAwIl0sIm1hcHBpbmdzIjoiQUFBQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFBQTtBQUFBO0FBQUE7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBO0FBQ0E7QUFDQTtBQUNBOztBIiwic291cmNlUm9vdCI6IiJ9");
-
-/***/ })
-/******/ ]);
\ No newline at end of file
diff --git a/documentation/src/docs/asciidoc/tocbot-3.0.2/tocbot.min.js b/documentation/src/docs/asciidoc/tocbot-3.0.2/tocbot.min.js
deleted file mode 100644
index 4468ef4ee73c..000000000000
--- a/documentation/src/docs/asciidoc/tocbot-3.0.2/tocbot.min.js
+++ /dev/null
@@ -1 +0,0 @@
-!function(e){function t(o){if(n[o])return n[o].exports;var i=n[o]={i:o,l:!1,exports:{}};return e[o].call(i.exports,i,i.exports,t),i.l=!0,i.exports}var n={};t.m=e,t.c=n,t.i=function(e){return e},t.d=function(e,n,o){t.o(e,n)||Object.defineProperty(e,n,{configurable:!1,enumerable:!0,get:o})},t.n=function(e){var n=e&&e.__esModule?function(){return e.default}:function(){return e};return t.d(n,"a",n),n},t.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},t.p="",t(t.s=5)}([function(e,t){var n;n=function(){return this}();try{n=n||Function("return this")()||(0,eval)("this")}catch(e){"object"==typeof window&&(n=window)}e.exports=n},function(e,t,n){var o,i,r;!function(n,l){i=[],o=l(),void 0!==(r="function"==typeof o?o.apply(t,i):o)&&(e.exports=r)}(0,function(){"use strict";var e=function(e){return"getComputedStyle"in window&&"smooth"===window.getComputedStyle(e)["scroll-behavior"]};if("undefined"==typeof window||!("document"in window))return{};var t=function(t,n,o){n=n||999,o||0===o||(o=9);var i,r=function(e){i=e},l=function(){clearTimeout(i),r(0)},s=function(e){return Math.max(0,t.getTopOf(e)-o)},c=function(o,i,s){if(l(),0===i||i&&i<0||e(t.body))t.toY(o),s&&s();else{var c=t.getY(),a=Math.max(0,o)-c,u=(new Date).getTime();i=i||Math.min(Math.abs(a),n),function e(){r(setTimeout(function(){var n=Math.min(1,((new Date).getTime()-u)/i),o=Math.max(0,Math.floor(c+a*(n<.5?2*n*n:n*(4-2*n)-1)));t.toY(o),n<1&&t.getHeight()+o<t.body.scrollHeight?e():(setTimeout(l,99),s&&s())},9))}()}},a=function(e,t,n){c(s(e),t,n)},u=function(e,n,i){var r=e.getBoundingClientRect().height,l=t.getTopOf(e)+r,u=t.getHeight(),d=t.getY(),f=d+u;s(e)<d||r+o>u?a(e,n,i):l+o>f?c(l-u+o,n,i):i&&i()},d=function(e,n,o,i){c(Math.max(0,t.getTopOf(e)-t.getHeight()/2+(o||e.getBoundingClientRect().height/2)),n,i)};return{setup:function(e,t){return(0===e||e)&&(n=e),(0===t||t)&&(o=t),{defaultDuration:n,edgeOffset:o}},to:a,toY:c,intoView:u,center:d,stop:l,moving:function(){return!!i},getY:t.getY,getTopOf:t.getTopOf}},n=document.documentElement,o=function(){return window.scrollY||n.scrollTop},i=t({body:document.scrollingElement||document.body,toY:function(e){window.scrollTo(0,e)},getY:o,getHeight:function(){return window.innerHeight||n.clientHeight},getTopOf:function(e){return e.getBoundingClientRect().top+o()-n.offsetTop}});if(i.createScroller=function(e,o,i){return t({body:e,toY:function(t){e.scrollTop=t},getY:function(){return e.scrollTop},getHeight:function(){return Math.min(e.clientHeight,window.innerHeight||n.clientHeight)},getTopOf:function(e){return e.offsetTop}},o,i)},"addEventListener"in window&&!window.noZensmooth&&!e(document.body)){var r="scrollRestoration"in history;r&&(history.scrollRestoration="auto"),window.addEventListener("load",function(){r&&(setTimeout(function(){history.scrollRestoration="manual"},9),window.addEventListener("popstate",function(e){e.state&&"zenscrollY"in e.state&&i.toY(e.state.zenscrollY)},!1)),window.location.hash&&setTimeout(function(){var e=i.setup().edgeOffset;if(e){var t=document.getElementById(window.location.href.split("#")[1]);if(t){var n=Math.max(0,i.getTopOf(t)-e),o=i.getY()-n;0<=o&&o<9&&window.scrollTo(0,n)}}},9)},!1);var l=new RegExp("(^|\\s)noZensmooth(\\s|$)");window.addEventListener("click",function(e){for(var t=e.target;t&&"A"!==t.tagName;)t=t.parentNode;if(!(!t||1!==e.which||e.shiftKey||e.metaKey||e.ctrlKey||e.altKey)){if(r)try{history.replaceState({zenscrollY:i.getY()},"")}catch(e){}var n=t.getAttribute("href")||"";if(0===n.indexOf("#")&&!l.test(t.className)){var o=0,s=document.getElementById(n.substring(1));if("#"!==n){if(!s)return;o=i.getTopOf(s)}e.preventDefault();var c=function(){window.location=n},a=i.setup().edgeOffset;a&&(o=Math.max(0,o-a),c=function(){history.pushState(null,"",n)}),i.toY(o,null,c)}}},!1)}return i})},function(e,t){e.exports=function(e){function t(e,n){var r=n.appendChild(o(e));if(e.children.length){var l=i(e.isCollapsed);e.children.forEach(function(e){t(e,l)}),r.appendChild(l)}}function n(e,n){var o=i(!1);n.forEach(function(e){t(e,o)});var r=document.querySelector(e);if(null!==r)return r.firstChild&&r.removeChild(r.firstChild),r.appendChild(o)}function o(t){var n=document.createElement("li"),o=document.createElement("a");return e.listItemClass&&n.setAttribute("class",e.listItemClass),e.includeHtml&&t.childNodes.length?u.call(t.childNodes,function(e){o.appendChild(e.cloneNode(!0))}):o.textContent=t.textContent,o.setAttribute("href","#"+t.id),o.setAttribute("class",e.linkClass+p+"node-name--"+t.nodeName+p+e.extraLinkClasses),n.appendChild(o),n}function i(t){var n=document.createElement("ul"),o=e.listClass+p+e.extraListClasses;return t&&(o+=p+e.collapsibleClass,o+=p+e.isCollapsedClass),n.setAttribute("class",o),n}function r(){var t=document.documentElement.scrollTop||f.scrollTop,n=document.querySelector(e.positionFixedSelector);"auto"===e.fixedSidebarOffset&&(e.fixedSidebarOffset=document.querySelector(e.tocSelector).offsetTop),t>e.fixedSidebarOffset?-1===n.className.indexOf(e.positionFixedClass)&&(n.className+=p+e.positionFixedClass):n.className=n.className.split(p+e.positionFixedClass).join("")}function l(t){var n=document.documentElement.scrollTop||f.scrollTop;e.positionFixedSelector&&r();var o,i=t;if(m&&null!==document.querySelector(e.tocSelector)&&i.length>0){d.call(i,function(t,r){if(t.offsetTop>n+e.headingsOffset+10){return o=i[0===r?r:r-1],!0}if(r===i.length-1)return o=i[i.length-1],!0});var l=document.querySelector(e.tocSelector).querySelectorAll("."+e.linkClass);u.call(l,function(t){t.className=t.className.split(p+e.activeLinkClass).join("")});var c=document.querySelector(e.tocSelector).querySelector("."+e.linkClass+".node-name--"+o.nodeName+'[href="#'+o.id+'"]');c.className+=p+e.activeLinkClass;var a=document.querySelector(e.tocSelector).querySelectorAll("."+e.listClass+"."+e.collapsibleClass);u.call(a,function(t){var n=p+e.isCollapsedClass;-1===t.className.indexOf(n)&&(t.className+=p+e.isCollapsedClass)}),c.nextSibling&&(c.nextSibling.className=c.nextSibling.className.split(p+e.isCollapsedClass).join("")),s(c.parentNode.parentNode)}}function s(t){return-1!==t.className.indexOf(e.collapsibleClass)?(t.className=t.className.split(p+e.isCollapsedClass).join(""),s(t.parentNode.parentNode)):t}function c(t){var n=t.target||t.srcElement;"string"==typeof n.className&&-1!==n.className.indexOf(e.linkClass)&&(m=!1)}function a(){m=!0}var u=[].forEach,d=[].some,f=document.body,m=!0,p=" ";return{enableTocAnimation:a,disableTocAnimation:c,render:n,updateToc:l}}},function(e,t){e.exports={tocSelector:".js-toc",contentSelector:".js-toc-content",headingSelector:"h1, h2, h3",ignoreSelector:".js-toc-ignore",linkClass:"toc-link",extraLinkClasses:"",activeLinkClass:"is-active-link",listClass:"toc-list",extraListClasses:"",isCollapsedClass:"is-collapsed",collapsibleClass:"is-collapsible",listItemClass:"toc-list-item",collapseDepth:0,smoothScroll:!0,smoothScrollDuration:420,scrollEndCallback:function(e){},headingsOffset:0,throttleTimeout:50,positionFixedSelector:null,positionFixedClass:"is-position-fixed",fixedSidebarOffset:"auto",includeHtml:!1}},function(e,t){e.exports=function(e){function t(e){return e[e.length-1]}function n(e){return+e.nodeName.split("H").join("")}function o(t){var o={id:t.id,children:[],nodeName:t.nodeName,headingLevel:n(t),textContent:t.textContent.trim()};return e.includeHtml&&(o.childNodes=t.childNodes),o}function i(i,r){for(var l=o(i),s=n(i),c=r,a=t(c),u=a?a.headingLevel:0,d=s-u;d>0;)a=t(c),a&&void 0!==a.children&&(c=a.children),d--;return s>=e.collapseDepth&&(l.isCollapsed=!0),c.push(l),c}function r(t,n){var o=n;e.ignoreSelector&&(o=n.split(",").map(function(t){return t.trim()+":not("+e.ignoreSelector+")"}));try{return document.querySelector(t).querySelectorAll(o)}catch(e){return console.warn("Element not found: "+t),null}}function l(e){return s.call(e,function(e,t){return i(o(t),e.nest),e},{nest:[]})}var s=[].reduce;return{nestHeadingsArray:l,selectHeadings:r}}},function(e,t,n){(function(o){var i,r,l;!function(n,o){r=[],i=o(n),void 0!==(l="function"==typeof i?i.apply(t,r):i)&&(e.exports=l)}(void 0!==o?o:this.window||this.global,function(e){"use strict";function t(){for(var e={},t=0;t<arguments.length;t++){var n=arguments[t];for(var o in n)m.call(n,o)&&(e[o]=n[o])}return e}function o(e,t,n){t||(t=250);var o,i;return function(){var r=n||this,l=+new Date,s=arguments;o&&l<o+t?(clearTimeout(i),i=setTimeout(function(){o=l,e.apply(r,s)},t)):(o=l,e.apply(r,s))}}var i,r,l=n(3),s={},c={},a=n(2),u=n(4);if("undefined"!=typeof window){var d,f=!!e.document.querySelector&&!!e.addEventListener,m=Object.prototype.hasOwnProperty;return c.destroy=function(){try{document.querySelector(s.tocSelector).innerHTML=""}catch(e){console.warn("Element not found: "+s.tocSelector)}document.removeEventListener("scroll",this._scrollListener,!1),document.removeEventListener("resize",this._scrollListener,!1),i&&document.removeEventListener("click",this._clickListener,!1)},c.init=function(e){if(f&&(s=t(l,e||{}),this.options=s,this.state={},s.smoothScroll&&(c.zenscroll=n(1),c.zenscroll.setup(s.smoothScrollDuration)),i=a(s),r=u(s),this._buildHtml=i,this._parseContent=r,c.destroy(),null!==(d=r.selectHeadings(s.contentSelector,s.headingSelector)))){var m=r.nestHeadingsArray(d),p=m.nest;return i.render(s.tocSelector,p),this._scrollListener=o(function(e){i.updateToc(d);var t=e&&e.target&&e.target.scrollingElement&&0===e.target.scrollingElement.scrollTop;(e&&0===e.eventPhase||t)&&(i.enableTocAnimation(),i.updateToc(d),s.scrollEndCallback&&s.scrollEndCallback(e))},s.throttleTimeout),this._scrollListener(),document.addEventListener("scroll",this._scrollListener,!1),document.addEventListener("resize",this._scrollListener,!1),this._clickListener=o(function(e){s.smoothScroll&&i.disableTocAnimation(e),i.updateToc(d)},s.throttleTimeout),document.addEventListener("click",this._clickListener,!1),this}},c.refresh=function(e){c.destroy(),c.init(e||this.options)},e.tocbot=c,c}})}).call(t,n(0))}]);
\ No newline at end of file